feat(shadow-verify): merge forge-approved enhancements

[griffinwork40]

Summary

This PR merges forge-approved enhancements into the shadow-verify skill, generated by /forge from pattern card shadow-verify-should-be-invoked-as-a-structural-check and approved after 3 qualify iterations (SALVAGE → SALVAGE → APPROVE, 29/30 Stage 1, 24/24 Stage 2).

Changes

1. Claim normalization format

Before dispatching verifiers, the coordinating agent now normalizes each claim to a canonical form:

[CLAIM_ID] <subject> :: <predicate> :: <evidence_ref>

evidence_ref must be a concrete pointer (file path, line number, git ref, config key, or API endpoint). Claims that cannot be anchored to a concrete evidence_ref are immediately classified UNVERIFIABLE and removed from the verification queue, with a dedicated output section explaining why each could not be anchored.

2. Scale cap (50-item halt)

If the normalized claim list exceeds 50 items, the coordinating agent halts and asks the operator to scope the investigation before proceeding. Verification at scale degrades into noise; the cap prevents a finding flood from becoming an echo-chamber rubber-stamp.

3. STALE verdict tier

Added STALE as a first-class verifier verdict alongside CONFIRMED, REFUTED, and UNVERIFIABLE. A STALE verdict means the claim was true at some prior point but no longer holds. The verifier emits a corrected/updated finding, and the claim is surfaced with [was true, now stale] — it must not be forwarded downstream without re-investigation if currency matters for the decision.

4. PASS/WARN/FAIL gate verdict

After all verifier results are merged, the coordinating agent now emits a single aggregate gate verdict before surfacing findings downstream:

Verdict	Condition
PASS	All verifiable claims confirmed; findings may proceed downstream
WARN	One or more claims are STALE, UNVERIFIABLE, or composition/echo-chamber flagged; proceed with explicit caveats
FAIL	One or more claims REFUTED; findings must not be forwarded until re-investigated

A FAIL verdict hard-blocks downstream use. A WARN may proceed but must carry flagged claims and their tags — stripping caveats before forwarding is a protocol violation.

5. Gap-analysis coverage in trigger scope

The When to invoke section now explicitly includes gap analyses, audit findings, and issue lists that will be forwarded to a downstream session as trigger conditions, alongside the existing code reviews, audits, findings reports, and large refactors.

Provenance

• Source brief: ~/.afk/agent-framework/briefs/merge-pending/shadow-verify-2026-08-24T02-08-44Z.md
• Pattern card: shadow-verify-should-be-invoked-as-a-structural-check
• Forge qualify iterations: 3 (SALVAGE → SALVAGE → APPROVE)
• Stage 1 score: 29/30
• Stage 2 score: 24/24