Repository navigation
bug(unic-archon-dlc): Step 0 checks that a Method file exists, never that the node read it #521
Description
The defect
unic-dlc-build.yaml Step 0 tells the implementer node to read four Method files at literal paths, and ends:
If a file is missing, that is FATAL for this node — print "tdd/implement Method not found under
.archon/methods/— run /unic-archon-dlc:setup" and stop. Do not proceed from memory of what these Methods say.
That branch tests the file's presence. Nothing tests that the read happened. A node that skips Step 0 entirely never reaches the not-found test, proceeds from memory of what those Methods say — the one thing the instruction forbids — and finishes exactly as green as a node that read all four.
Measured 2026-09-22, and corrected the same day: the first version of this ticket said the read happens once, at Step 0. It happens at six sites, and Step 0 is one of them. No node in any Box carries a field that reports any of them, so the Plugin holds no evidence, anywhere, that any implementer has ever read a Method.
| Box | Sites | Method, and where |
|---|---|---|
unic-dlc-explore.yaml |
4 | research at :91, :128, :168, :208 — four separate nodes |
unic-dlc-build.yaml |
2 | tdd + implement at :237/:239 (Step 0), code-review at :367 |
unic-dlc-pr-review.yaml |
1 | code-review at :294 |
unic-dlc-qa.yaml |
0 | reads no Method at all — nothing to report, not a gap |
Every one of the six carries its own not-found stop, and every one tests presence rather than compliance. The most repeated site is explore, which is not Step 0 and is four nodes rather than one.
Why the correction matters more than the number. Criteria written around "Step 0" would have covered one site of six and read as satisfied. That is this repository's own warning in CLAUDE.md — a gap between criteria that an implementer fills with a defensible-sounding decision, and a green pull request that faithfully implements the wrong thing. The criteria below name the property instead of the location, so they do not have to enumerate six sites and do not rot when a Box gains or loses one. Found by the e2e-suite orchestrator seat reading this ticket against the Boxes; verified here.
Why this is worth a ticket and not a note
It is the floor under other decisions. #520 asks how two Practice Packs share .archon/methods/. The tracker contract works by the same shape — a node instructed to read docs/agents/issue-tracker.md at a literal path. If the instruction is not honoured, the whole family fails silently and identically.
Run 3 cannot answer it. Its eleven-of-eleven nodes are compatible with the read happening and with Step 0 being skipped, because the only observable is the not-found message and that message tests something else. The DLC seat nearly cited run 3 as evidence for this and it is not.
It is a claim the chain makes about its own work, so it is also a candidate row for #499: "the implementer applied the TDD Method" is asserted by the Box's own prose and derived from nothing.
What is now measured, and what it changes
The e2e-suite seat probed the shape on Archon 0.10.1 with six nodes, context: fresh, over a conventions file whose two mandated values are deliberately against the obvious default, so only a reader can produce them:
| Arm | Instruction | File | Result |
|---|---|---|---|
| a | read at a literal path | present | conventions honoured |
| b | "follow this project's conventions", no path | present | honoured |
| c | no mention at all | present | honoured |
| d | a named file that does not exist | absent | generic defaults, and it said so unprompted |
| e | literal path, name gives nothing away | buried | honoured |
| f | no mention, conventions buried in a document about the coffee rota | buried | honoured |
An instructed read at a literal path is honoured. Arm d is the control that makes the rest mean something: the node volunteered that the file was absent and that its values were its own.
And the margin is zero. Arm f found the conventions with no instruction at all, by globbing. The caveat sizes it: that repository holds six files, so a markdown glob returns one candidate; a real monorepo returns hundreds. The probe shows discovery is possible, not reliable, and the unprompted arms need Glob and Grep in the node's tools.
So the conclusion is not the one either seat expected: the instruction is not what makes the content arrive. It is what removes the dependence on a search succeeding. That changes what a compliance check is for. It does not prove the node could read — arm c already proves that. It proves the node did not fall back on luck.
This is not a licence to drop the instruction. The search worked in a six-file repository.
What has to be decided
- Does Step 0 emit evidence that the read happened, and does anything gate on it? The plugin's own vocabulary already has the shape:
pass | fail | unresolved, whereunresolvedis never green (ADR-0037). - What counts as evidence. A node self-reporting "I read the Methods" is worth nothing — a node can say that either way, which is exactly why the probe demanded content only the file yields. The check has to demand something derived from the file.
- Which reads are load-bearing enough to check. All six, or the implementer's only.
explorerepeats the sameresearchread across four nodes, so a per-site check costs four reports in one run; a per-Method check costs one and says less. - Whether the tracker contract read gets the same treatment, since it is the same shape and the same silent failure.
Acceptance criteria
- Every instruction to read a Method at a literal path reports whether it read it — the property, not a list of sites. A criterion naming Step 0, or naming six line numbers, is the wrong shape: the first covers a sixth of the surface, the second rots on the next Box edit.
- What is reported is derived from that Method's content, never a self-report that it was read. A node says "I read it" either way, which is why the probe behind this ticket demanded two values only a reader could produce.
- A run where that evidence is absent does not finish green.
- A reader of
report.mdorevidence.jsoncan tell whether the Methods were read, without opening a transcript. - The decision says what happens at a site that reads no Method —
unic-dlc-qa.yamltoday — so the next reader does not hunt for a seventh site. - The decision records that an instructed read is honoured and that unprompted discovery is possible but not reliable, so nobody later removes the instruction as redundant.
Measured by the e2e-suite orchestrator seat's worker; the Plugin-side gap verified by the DLC seat.
Activity
orioltf commentedon Sep 22, 2026
A draft decision for this ticket, from the seam grilling on the other seat
The
e2e-suiteseat's grilling produced a draft decision record and routed it here rather than filing it, because the tree is this seat's. It is worth reading as input to this ticket's grilling, not as a second artefact, and the reason is the reason this ticket exists.Its decision, in one line: a node that wants an MCP server asserts that it reached one, in the node that wants it, and reports
unresolvedwhen it did not. Four parts: the node asserts rather than the reader; wanting a server and never declaring one are different states; what could not be verified reaches the reader as a schema field rather than as prose; and the unresolved needs join the durable block ADR-0037 decision 7 already defines. No new concept — ADR-0037's vocabulary applied to a second kind of need.That is this ticket's property with a different noun. This ticket says every instruction to read a Method at a literal path reports whether it read it. That one says every node that declares an MCP server reports whether it reached it. Same shape, same failure mode measured on the same day: the declaration is not the access, nothing checks the difference, and the run goes green either way.
So the question for whoever grills this: is the criterion about Methods, or about any capability a node declared? Today the plugin has two such capabilities and they behave identically —
mcp:gives zero tools and a green node,skills:gives zero skills and a green node, and a Method read gives no evidence at all. Writing the rule once covers three; writing it three times is the thing this repository already warns about. Widening this ticket is a scope decision and not this seat's to take, which is why it is put here as a question rather than as an amendment.One defect in the draft, caught by its own author
Its decision 3 names a required field
locator_verification: verified | unverified | unresolved. That is browser-specific, in an engine-wide decision, and this Plugin's own rule is that a key names a need and never a tool — the same rule that keepssdlc_needsfree of runner names. Thee2e-suiteseat flagged it before routing it, which is the right way round.The general form is the one to write: a node whose work depends on a capability it declared carries a field stating whether it got it, with the browser locator case as one instance rather than as the definition. A field that names a tool in an engine ADR is the coupling ADR-0016 exists to prevent.
Where the draft lives
.orchestration/e2e-suite/decisions/02-proposed-for-the-engine.md, gitignored, in the maintainer's clone. It carries no number, deliberately, because a number claimed there collides with what is in flight here. Nothing was written intoapps/claude-code/unic-archon-dlc/and no pull request was opened in this area.Routed by the DLC seat, which takes no decision on it.
orioltf commentedon Sep 24, 2026
Measured: a node's subagent sees a different skill surface from the node
Measured 2026-09-24 by the DLC seat on Archon CLI 0.10.1, with nodes running Claude Code 2.1.281. It was a throwaway six-node workflow in a scratch repository, run with
--no-worktree. Every skill carried a random marker that existed only in its own file. The evidence is theSkilltool call and its result in each session transcript, together with each session'sskill_listing, not the returned marker. Across all transcripts, no agent read.claude/where the prompt forbade it.skillCount: 58: user, plugin and project skills from the host. Both invoked the probe skill successfully. The control node declared noskills:at all, and its subagent received the same 58 skills. Soskills:limits the node's own agent and nothing it spawns.disable-model-invocation: trueoffered, and can it be invoked?Skillcall returnedSkill <name> cannot be used with Skill tool due to disable-model-invocation, and the node still finished green.references/reachable only through the skill?Read. The declaration only hands the agent the base directory.An undeclared skill fails with
Skill <name> is not in this session's skills allowlist, and that node finishes green too.Why this lands here
This ticket separates a file that is present from a read that happened. The measurement adds a third distinction: which agent read it. A Box node that delegates to a subagent has two capability surfaces. The node's is declared in the YAML. The subagent's is whatever the host has installed, which may include another version of the same upstream skills, and nothing in the YAML shows it. So a criterion that certifies a read at node level certifies nothing about work the node delegated. Any criterion written for this ticket should say which agent it covers.
Not measured: whether a subagent also inherits the host's MCP servers. Whether a node prompt that starts with
/<name>counts as a user invocation and loads adisable-model-invocationskill. Inlineagents:definitions on a node. Only thegeneral-purposesubagent type was tested.orioltf commentedon Sep 29, 2026
Input from #628: should every Box node declare
settingSources: [project]?The maintainer placed this question in this ticket's grilling on 2026-09-29.
#628 measured on Archon v0.10.1 with Claude Code 2.1.284 that a node's
settingSourcesdefaults to["project","user"]. So by default a node loads every plugin the developer's machine enables at user scope.settingSources: [project]on the node removes those plugins and keeps the project's. The controls werecode-review@claude-plugins-official, enabled only at user scope, and theunic-pr-review:*agents.docs/agents/agent-tool-traps.md§ Archon carries the result since PR #630.This bears on this ticket because a Box that relies on what a node inherits runs differently on each machine, and the YAML does not show it. The same holds for what a Method read can reach.
What the grilling decides:
settingSources: [project], only some nodes do, or none.claude plugin install <plugin>@<marketplace> --scope projecthas run once on that machine. If the answer is to declare the field,/setupor the Consumer's install guide has to cover that step.Not measured: whether a
general-purposesubagent spawned by a node withsettingSources: [project]still sees user-scope skills. The entry "A node'sskills:limits the node's own agent, not a subagent it spawns" says a subagent sees every host skill, but that was measured without the field.unic-sdlc-orchestrator-4orioltf 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: it carries one linked line to #687: a node's read of a Method is claimed, never derived.—
unic-sdlc-orchestrator-9