Acceptance matrix validator deadlocks on out_of_scope contract items: rows rejected as 'unknown' regardless of status

[JRedeker]

Summary

When adv_contract_mint parses an agreement containing an ## Out of Scope section, it creates contract items with kind: out_of_scope, verificationRequired: false, evidencePolicy: not_applicable. The acceptance-gate readiness validator then makes the gate unsatisfiable: it demands row coverage for those items while classifying every row that references them as unknown.

Reproduction (observed on change fixDockSafeAreaStacking, pokeedge-web project, 2026-07-20)

1. Agreement with SC/AC/constraints + ## Out of Scope (2 bullets) → adv_contract_mint → 8 items incl. OOS1, OOS2 (verificationRequired: false).
2. All work done, reviewer READY, designer PASS.
3. adv_contract_review_matrix_set + adv_gate_complete gateId: acceptance fails with:

ACCEPTANCE_REVIEW_MATRIX_INVALID: Acceptance review matrix has invalid row coverage: unknown: OOS1, OOS2.
remediation: Provide exactly one passing review row for each required contract item before retrying acceptance.

Every matrix shape fails identically (each adv_contract_review_matrix_set returned success: true, failingRows: 0):

Attempt	OOS rows	Result
8 rows	status: respected, evidencePolicy: review	unknown: OOS1, OOS2
6 rows	omitted entirely	unknown: OOS1, OOS2
8 rows	status: not_applicable, evidencePolicy: not_applicable	unknown: OOS1, OOS2
8 rows	status: pass, evidencePolicy: review	unknown: OOS1, OOS2

The persisted acceptance.md renders the OOS rows as missing even when rows were submitted — suggesting rows with kind: out_of_scope are dropped or unmapped by the coverage classifier.

Notes:

• adv_temporal_diagnose: fully healthy (server/worker/STSL/workflow all reachable) — not an infra issue.
• adv_contract_review_matrix_set schema explicitly allows kind: out_of_scope and statuses not_applicable/pass/etc., so the write path accepts what the readiness validator cannot classify.

Workaround that unblocked the change

1. adv_change_update — rewrite agreement without the ## Out of Scope section (boundaries moved to proposal.md/design.md; one constraint bullet documents the workaround).
2. adv_contract_mint force: true → 7 items, no OOS.
3. Re-set matrix (7 rows) → first adv_gate_complete retry still failed with the stale OOS blocker (one-behind readiness — same signature as closed Stale readiness projection: gate_complete returns identical blockers one cycle after disposition/artifact writes clear them #243), second retry succeeded.

Expected behavior (pick one)

• A (preferred): verificationRequired: false items (incl. out_of_scope) are excluded from matrix coverage validation entirely — matrix over SC/AC/constraints/avoidances only.
• B: OOS rows are accepted with a designated status (e.g. not_applicable) and count as covered.

Either way, the validator must never simultaneously require and reject the same contract ID, and the remediation text should name the accepted row shape.

Related

• Stale readiness projection: gate_complete returns identical blockers one cycle after disposition/artifact writes clear them #243 (closed) — stale one-behind readiness evaluation reproduced here during the workaround: first retry after a corrective re-mint + matrix write still reported the previous blocker; identical second call succeeded.

[JRedeker]

Triage update 2026-07-23: Reproduced a sibling coverage-check bug on this exact surface while accepting fixAdvRunTestPipefailFalse.

Avoidance (DONT) rows are not recognized when status is respected. The acceptance-matrix coverage validator ( / ) rejected a DONT1 row set to status: "respected", repeatedly reporting missing: DONT1 even though adv_change_show showed the row present with respected + evidence. Setting the same row to status: "pass" cleared it instantly.

• Constraints (C*) accept respected (verified on fixDurableProofFallback acceptance).
• Avoidances (DONT*) appear to require pass — respected is silently not counted as coverage.

The Zod row schema allows both pass and respected, so this is a validator-coverage-check inconsistency, not a schema rejection. Likely the coverage check maps avoidance rows through a criteria-style pass-only gate. Suggest unifying: any of pass/respected should satisfy coverage for avoidances and constraints (mirror the constraint behavior). Repro: mint a contract with a DONT item, set the review row with status: respected, attempt acceptance → missing error; flip to pass → accepted.