Repository navigation
List every claim the chain makes about its own work, and what each one derives from #499
Description
Question
What are all the claims unic-archon-dlc makes about its own work, and which artefact does each one
derive from?
This is the map's third finish condition, and the one that makes run 4 a destination rather than eight
fixes. Six claims are already known and each has a ticket:
| Claim | Ticket | Derived from |
|---|---|---|
a prior finding is fixed |
#482 | nothing — the next reviewer's silence |
evidence.json says pass |
#483 | goals-check's count; the precheck's read never reaches it |
| "this review executed none of them" | #487 | the Box's instruction, not the sub-agents' tool calls |
| "nothing was flaky" | #488 | verification's single final run, which cannot see the slice loop |
| a check passed | #489 | nothing proves the check could have failed |
| a pull request is open | #439 | a verdict that never authorised it |
The list says whether there is a seventh. Without it, #482 is fixed and returns next year under another
number.
What resolving this produces
A document listing every such claim across the four Boxes and the four commands, each row naming:
- the surface the claim appears on (
report.md,evidence.json, a posted summary section, a node's
stdout, a gate message) - the node that writes it
- the artefact it is derived from, or
not derivablewith the reason
A row marked not derivable is a finding, not a gap in the research. It is the honest outcome for a
claim written from an instruction rather than from an observation, and naming it is how the seal's
arm 2 gets its predictions.
Where it lives
In the plugin, beside its ADRs, because it is a property of the plugin rather than of one run. The
alternative — a section of the findings register — ties it to run 4, and this list outlives run 4.
Decide which while resolving.
Why it comes before the seal
Run 4's seal predicts, per arm 2, which claims still are not derived after the six fixes land. It
cannot predict over a set nobody has written down. So this blocks
the seal, and the seal blocks the dispatch.
Activity
orioltf commentedon Sep 22, 2026
A candidate row, found while grilling #425
apps/claude-code/unic-archon-dlc/AGENTS.md:102states, as a measured fact:It is dated 2026-08-18 and was true on Archon 0.7.0. It is false on 0.10.1, measured on #425: a node with no
mcp:declaration sees zero MCP tools.This is exactly the shape this list exists to catch — a claim the chain makes about its own capability, derived from one run on one version, written in the present tense with no version beside it, and never re-measured. Worth a row of its own, and worth asking of every other row: what version was it true on, and what would falsify it now?
Found by the session grilling #425; verified here.
orioltf commentedon Sep 22, 2026
Another candidate row, and this one the chain asserts about every run: "the implementer applied the TDD Method".
unic-dlc-build.yamlStep 0 instructs the read and treats a missing file as fatal, but nothing checks that the read happened, and no node in any Box carries a field reporting it. A node that skips Step 0 proceeds from memory — the one thing that instruction forbids — and finishes as green as one that read all four files. Filed as #521.The general shape for this list: an instruction in a prompt is not a claim the run can support. Every "the node read X" in the Boxes' prose is derived from nothing today, and the same goes for the tracker contract read. Worth one pass over the Boxes asking which of their instructions produce an observable and which only produce prose.
orioltf commentedon Oct 30, 2026
Closed as superseded by #678's resolution, approved by the maintainer on 2026-10-30: run 4 is dropped and
unic-archon-dlcis frozen. Reason for this ticket: its table of six claims goes to #687 as input (decision 3).—
unic-sdlc-orchestrator-9