What happened
/specs wrote a PRD requirement that the chain's own gate topology forbids.
User story 26 asks for each component's design contract to ship in the same pull request as the component. The chain cannot do that: /specs merges the contracts at its own gate, and /build merges the component later, in a different pull request. Any requirement of the form "X ships with the component" is unsatisfiable by construction.
Run 1 had the same shape — contracts in PR 5804, components in PR 5807 — so it is a property of the chain and not of one run's merge order.
It was found three legs later, at the tickets gate, after the PRD had already been approved and merged. The slices carry a weaker criterion — the pull request links its contract — accepted knowingly by the maintainer and recorded as not satisfying the original.
Why it is worth its own issue
The PRD that stated it was written by /specs in the same run. So the command produced a requirement its own leg structure rules out, and nothing between writing it and approving it noticed.
The open question
At what point can a requirement be checked against the chain's own topology — while the PRD is being written, at its gate, or when /tickets tries to give it a criterion?
Related
Blocked by #441 — the native edge exists and this line now carries its number. This is a specific instance of a command not checking its own claims.
One thing #441's grilling settled about the boundary, 2026-09-02: #441's absence-claim criterion does not cover this bug. That criterion makes a claim of absence carry the method that established it. User story 26 is a false positive claim — a requirement stated as satisfiable that the topology forbids — so catching it needs a reader asking what the artefact promises that it does not deliver, which is #441's review criterion rather than its absence-claim one.
Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.
What happened
/specswrote a PRD requirement that the chain's own gate topology forbids.User story 26 asks for each component's design contract to ship in the same pull request as the component. The chain cannot do that:
/specsmerges the contracts at its own gate, and/buildmerges the component later, in a different pull request. Any requirement of the form "X ships with the component" is unsatisfiable by construction.Run 1 had the same shape — contracts in PR 5804, components in PR 5807 — so it is a property of the chain and not of one run's merge order.
It was found three legs later, at the tickets gate, after the PRD had already been approved and merged. The slices carry a weaker criterion — the pull request links its contract — accepted knowingly by the maintainer and recorded as not satisfying the original.
Why it is worth its own issue
The PRD that stated it was written by
/specsin the same run. So the command produced a requirement its own leg structure rules out, and nothing between writing it and approving it noticed.The open question
At what point can a requirement be checked against the chain's own topology — while the PRD is being written, at its gate, or when
/ticketstries to give it a criterion?Related
Blocked by #441 — the native edge exists and this line now carries its number. This is a specific instance of a command not checking its own claims.
One thing #441's grilling settled about the boundary, 2026-09-02: #441's absence-claim criterion does not cover this bug. That criterion makes a claim of absence carry the method that established it. User story 26 is a false positive claim — a requirement stated as satisfiable that the topology forbids — so catching it needs a reader asking what the artefact promises that it does not deliver, which is #441's review criterion rather than its absence-claim one.
Full evidence:
docs/research/2026-08-31-dlc-run-2-findings.md.