red-verify

/red-verify - Adversarial semantic verification

/verify owns functional evidence. /red-verify owns semantic evidence and one exact SEMANTIC_VERDICT: semantic-pass|semantic-concern|semantic-fail. Zero reportable findings is a normal result of sufficient adversarial coverage.

<input_contract> Expected $ARGUMENTS:

• TASK-NNN-TN-FT-NNN-WN: per-task semantic verification;
• --feature FT-<ID>: T2 feature-completion semantic verification.

Reject --feature FT-000. Foundation closes through normal FT-000 tasks and the final gate.

Load .memory-bank/workflows/tier-policy.md#tier-obligations and #closure-authority for permitted modes, required gates, and lifecycle ownership. Apparent scope growth also loads #tier-classification-and-escalation and routes through tier rebuild before semantic verification.

Require indexed task/feature identity, tier policy, task/feature intent and mapped REQ/AC, successful functional verification evidence, actual diff/change surface, tests/runtime artifacts, tier-selected protocol, direct task-linked canonical SDD specs for T2/T3, and only the additional provenance-linked context needed to assess system impact.

For per-task T2/T3, feature links and spec-index.md alone do not replace direct task links. Missing direct applicable coverage is a blocker, not a basis for semantic-pass. </input_contract>

<hard_invariants>

• Before the semantic verdict, load and apply this installed skill's references/finding-adjudication.md semantic pack.
• Use an independent verifier context; do not trust task prose, writer claims, or VERDICT: PASS as proof of semantic correctness.
• Route only by task tier and the loaded tier-policy sections; never use legacy risk.
• Scheduler mode: /red-verify never closes/fails/blocks/reopens tasks, promotes dependents, or writes scheduler status. It returns verdict/evidence and a recommended owner action.
• Manual lifecycle or BUG/follow-up mutation is allowed only under explicit standalone ownership and canonical tier policy.
• T3 semantic-pass does not replace functional PASS.
• T2 feature semantic-pass must be recorded in the matching feature document; per-task evidence is not a substitute.
• Do not invent a separate failure artifact, status, task schema, or lifecycle. </hard_invariants>

<operator_decisions> If the semantic verdict depends on an ambiguous product/spec interpretation, canonical identity, acceptance meaning, architecture/contract/state/data/ storage/security/compatibility decision, task boundary, tier, dependency, or verification policy, the verifier does not pick a favorable reading.

• Return semantic-concern when an unresolved operator-owned decision is necessary to judge the accepted outcome or a proved realistic material risk.
• Return semantic-fail only when evidence proves a material break of an unambiguous accepted outcome.
• State the exact operator question, competing interpretations, affected closure/dependents, and repair owner.
• Do not manufacture an operator question from a speculative, unreachable, or immaterial candidate.
• Interactive flow asks the operator; recommendation/default/silence is not an accepted decision. The answer must be durably applied by /feature-doctor, /feature-to-tasks, or /spec-redesign, then functional and semantic gates rerun as applicable.
• Unattended flow returns the blocker to the scheduler for HALT_CLARIFICATION_REQUIRED or HALT_BLOCKING_QUESTIONS and names the exact resume route. </operator_decisions>

<finding_admission> Generate and assess hostile hypotheses privately. Do not write hypotheses, admission notes, rejected candidates, scorecards, or a target finding count to protocols, reports, task records, specs, or tests.