Development record
2026-07-24 — iss-122 design: the crosscheck gate gets a committed input
2026-07-24 — iss-122 design: the crosscheck gate gets a committed input manifest (doc list, directions, checker count, prompt hash) with TIERED depth — full depth for feature/breaking releases, Direction-B-only shallow pass for patch. The receipt must echo the manifest hash AND the tier; receipt_gate refuses a receipt whose tier mismatches the release's declared impact. Automated refusal is PROCEDURAL ONLY (manifest/tier mismatch, undispositioned findings); confirmed findings go to the maintainer, whose PROMOTE with recorded dispositions is the gate (verifier-selects-gates- decide). Rejected: hard-blocking on confirmed majors (a stochastic LLM triage could block a release); never-worse ratchet (drift persists; tiers make counts incomparable).
Frontmatter
| id | dcn-2607240000000002 |
|---|---|
| type | decision |
| date | 2026-07-24 |
.abcd/work/decisions/dcn-2607240000000002-iss-122-design-the-crosscheck-gate-gets.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-122The iss35 crosscheck's scope and depth are unpinned, so the gate is not reproducible: v0.3.0's receipt records zero findings four days ago while a full-depth run (17 brief docs, both directions, 22 checkers) returns 102 discrepancies, and the receipt's own promptHash field is the literal 'no-pinned-prompt' admission. The maintainer choosing briefDocs per run means two honest runs of the same gate can disagree by two orders of magnitude; the gate needs a pinned input manifest and depth so a PROMOTE means the same thing every release.