bug(unic-archon-dlc): /specs wrote a PRD requirement the chain's own gates forbid

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.

Read docs/research/2026-08-31-dlc-run-2-findings.md, then trace the /specs, /build, and /tickets gates described in the issue. Compare the boundary with #441 and the Run 1 evidence; done should be an agreed validation point and recorded criterion for detecting unsatisfiable requirements before approval.