wayfinder: run 4 — are the chain's claims about its own work derived from the work? #498

Destination

Run 4 has been dispatched against a seal written before the first dispatch, scored by
someone who did not run it, and written into the findings register. It ran on a chain
where no claim about its own work is believed unless it derives from the artefact that
claim names, and where no outward act happens before the claim that authorises it. It is
the first walk that ends in a merge, onto a long-lived integration branch, and the first
whose output the client has seen render.

The map is done when the answer is on record — not when the run finishes.

Notes

Domain. The plugin is unic-archon-dlc
in this repository; the Consumer is DXP-DesignSystem on Azure DevOps. The parent effort is
#373 — read its body for the destination this
one serves. Run 3's map is #456, closed.

This map carries execution, deliberately, the way #456 did. /wayfinder plans by default and its
tickets are decisions; an effort overrides that in these Notes, and this one does. Most of what gates
run 4 is work — six plugin fixes, a baseline measurement, a dispatch — and splitting the doing from the
deciding would leave the map unable to say what is left.

What run 3 settled, and what it opened

Run 3 answered the question runs 1 to 3 existed to ask: mechanisms reach the implementer where
documents did not. Four rules run 2 broke with the rule written in front of it were honoured once a
check stood in front of it. That line of enquiry is closed; nothing here reopens it.

What run 3 opened instead, unplanned: the review workflow cannot be trusted about what is fixed.
Two review iterations on a byte-identical commit, and the second did not mention six of the first
round's findings, so reconcile marked them fixed and post resolved their threads. Nothing checks
a fixed against the code. Eighteen findings about the instrument came out of that run, filed as
§ G of the findings register.

The destination's third condition

Two of the finish conditions are ordinary: run 4's three review iterations have run, and reconcile marks
nothing fixed that it cannot derive. The third is what makes this a destination rather than eight fixes:

A written list of every claim the chain makes about its own work, each carrying the artefact it
derives from, or marked as not derivable. The six we know are #482, #483, #487, #488, #489 and #439.
The list is what says whether there is a seventh. Without it we fix #482 and it returns next year
under another number.

The bench

Changed 2026-10-27 by the maintainer. The bench was two review iterations on a byte-identical
commit, with fixed: 0 known by construction. #482's
grilling decided that a fixed needs the finding's file to change between the two iterations' recorded
heads. On an identical head no file changes, so fixed: 0 now holds by construction and proves nothing
about #482. A byte-identical pair is also not how a review is used: the real flow is review, fix,
review again.

What stays true:

• A rerun on the same head is a real case, not a lab one. A post that fails halfway, a run killed by
  a lost connection or an OS update, and a /pr-review started without a push all produce one. Run 4
  tests it as a robustness case (below), not as the experiment.
• The variance measurement still needs identical code. It belongs to
  #501, on the frozen input below, separate from
  run 4. It is the input spike(unic-archon-dlc): the review Box is not deterministic across iterations on identical code #485 needs, and it now also answers a question bug(unic-archon-dlc): reconcile marks a finding fixed when the next review omits it, and post resolves the thread #482 raised: how often a
  review omits a finding whose file did not change. Each such omission becomes an unverified reply.

Run 3 produced n=1 by accident: fixed: 6 · still_present: 7 · new: 4 where the truth was
fixed: 0 · still_present: 13. That is the "before" for #482.

The review iterations in run 4 cover four of the eight tickets. #482, #485, #486 and #487 are
unic-dlc-pr-review; #483, #488, #489 and #439 are unic-dlc-build, /tickets and /qa, and no replay
of the review Box can reach them. That is why run 4 is a full walk with the review iterations inside it.

Run 4's shape

seal (both legs, three arms, both the green and the red branch — written before the first dispatch)
   ↓
/specs → /tickets → /build   (gates.build: afk)     exercises #483 #488 #489 #439
   ↓
pull request opened against integration/dlc
   ↓
review iteration 1   (afk, posts)
review iteration 2   (afk, same head, killed during post)   ← rerun after a complete run
rerun of iteration 2 (afk, same head, posts)                 ← rerun after a partial post
   ↓
one fix commit (see the rules below)
   ↓
review iteration 3   (afk, posts)              ← fixed vs unverified; exercises #482 #486 #487
   ↓
the maintainer reads the posted threads on the pull request
   ↓
further fix commits, if any
   ↓
/qa merges to integration/dlc                        closes the grouping ticket, #439 criterion 18
   ↓
demo to Jessi on a shared screen, from a local Storybook
   ↓
integration/dlc → develop, an ordinary pull request, a human act outside the run

Rules this shape depends on, each of which is easy to lose:

• The head does not move from iteration 1 to the rerun of iteration 2. Iteration 2 is a rerun after
  a complete run. Expected: nothing is resolved, and each finding it omits gets one unverified reply.
• Iteration 2 is killed on purpose during post, after post has written at least one reply and
  before it finishes. The run record says how and when. Expected from the rerun: it finishes what post
  left undone and repeats no reply that already exists.
• Exactly one fix commit lands before iteration 3. It changes the file of at least one iteration-1
  finding and leaves the file of at least one other finding untouched. Without both, iteration 3 cannot
  tell fixed from unverified. The correct answer for each prior finding is derivable from
  git diff --name-only between the two recorded heads.
• The names above are the map's, not the pull request's. post writes the summary, with its
  iteration number, before the threads, so the killed iteration 2 keeps its number and the rerun is
  numbered 3 on the pull request. The map's iteration 3 is iteration 4 there
  (#482, rerun case).
• The review gate runs afk. A hitl gate would let a human filter the findings before they post,
  and reconcile would then compare against what the human let through rather than what the Box
  produced. The maintainer's review happens afterwards, on the pull request, as its sole human reviewer.
• gates.build runs afk. A pause inside /build puts the maintainer's judgement in the middle of
  what is being measured. The cost is recorded rather than hidden: build-pr-gate goes unexercised for
  a second consecutive run (register § G row G14).
• The seal is written before the first dispatch, and it covers both legs. Run 3's arm 3 was written
  at 16:30 with /specs already dispatched, and the register marks it a weakened seal. It also predicts
  both branches: what holds if the build comes out green, and what holds if it comes out red.
• A red verdict is a result, not an accident. bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439 criterion 4 makes a red build open no pull
  request and end the run cancelled. If run 4 goes red, that is the demonstration that bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439 works. It
  is scored, fixed, and re-dispatched as run 4b on the same frozen version. No escape hatch is built
  into the gate this map exists to build.

The class rule, and why the eight tickets are not one class

Eight are preconditions of the dispatch: #425, #439, #482, #483, #486, #487, #488 and #505. Two land after the
run: #485's Standards-axis seeding, because reducing variance is a different subject from deriving a
claim; and #489's controls node, because run 3 ran the four positive controls by hand and the ritual
survives one more run.

Standing constraints

• Predictions are sealed before dispatch and scored afterwards by someone who did not run it. Held
  for run 3 and stays.
• The plugin is held at one version for the length of a run, so the run measures one version. The
  precondition fixes land first, then the version is frozen, then the run is dispatched.
• No dependency upgrade until phase 1 ships its first stable release. Archon is held; #425 gates any
  upgrade. The hold was overtaken on one machine: the maintainer's macOS machine runs Archon
  0.10.1, so "held at 0.8.0" is now a property of a machine, not of the project. Which Archon
  version run 4 is dispatched on is a decision the grilling of #425 has to take,
  because the Boxes carry no floor of their own.
• The maintainer types the planning skills. An agent cannot invoke /wayfinder, /grill-with-docs,
  /to-spec or /to-tickets — all four carry disable-model-invocation, measured 2026-09-17.
• Links, never bare ids, inherited from wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373: in prose, a GitHub issue number or an ADO work item
  always carries its URL.

Delivery, in two acts

Decided while charting, 2026-09-17. Runs 2 and 3 each wiped the previous run's artefacts so the next run
started from an empty develop (d09feff, 5e39db6). Run 4 merges instead, which would make every
future run start from a tree that carries a component — a different question from the one three runs
have asked.

So the merge is split. Act 1, inside run 4: /qa merges to integration/dlc, a long-lived branch.
develop stays as it is, comparability survives, and the branch is resettable. Act 2, outside run 4:
after the demo, if Jessi agrees, integration/dlc reaches develop through an ordinary pull request.
develop then receives the component by a human decision rather than as a side effect of a measurement.

Two costs, recorded so neither arrives as a surprise: a push --force with a reset on integration/dlc
destroys the baseline run 5 would use, so a reset is a decision and not a tidy-up; and integration/dlc
diverges from develop while act 2 waits, so a slow act 2 leaves run 5 building on a stale base.

The merge is a demo, not a code review

The maintainer and Jessi decide the merge together on a shared screen, from a locally-run Storybook.
Jessi does not review code she does not understand, and the Consumer has no CI to publish Storybook —
giving it one stays out of scope, on #373. So "Storybook runs locally and shows the component" is a
precondition of the demo, not a detail.

For the pull request itself the maintainer is the sole human reviewer.

Measured environment, as of 2026-09-17 21:10 CEST

Facts, not assumptions. Each is owed a re-measure before dispatch rather than a transcription — run 3's
lesson from #414 was that a transcribed measurement goes stale within hours.

• The Consumer runs Node 24.15.0. nodeVersion: 24.20.0 in pnpm-workspace.yaml is a dead pin under
  pnpm 11 (it governs the engines check only) and package.json carries no devEngines.runtime.
  Consumer PR 5876 replaced one dead pin with another. Any run 4 check that depends on the Node version
  runs on 24.15.0. ADO 43102 is the Consumer's ticket for it.
• Archon CLI v0.8.0 on the Omarchy machine, bun 1.4.2. The macOS machine runs Archon v0.10.1 and
  bun 1.3.14, measured 2026-09-22 — two machines, two versions, and the measurements below were
  taken on whichever one was in front of the session. One codebase row
  _git/DXP-DesignSystem | repo | develop, plugin unic-archon-dlc 0.28.0 at project scope,
  .archon/ clean, gates build: afk / qa: hitl / pr-review: afk / explore: hitl.
• A workflow node reaches no MCP server unless the node declares one. Measured on 0.10.1,
  2026-09-22: a node with no mcp: field sees zero mcp__ tools, while the same Claude binary in
  the same directory outside a workflow sees them. See #425. A node with
  mcp: .mcp.json sees 118 tools across atlassian, azure-devops and figma, authenticated.
  Dispatching run 4 before this lands runs every Box with no tracker, no Confluence and no Figma,
  silently, with the prompts still telling each node to use them.
• DXP-DesignSystem develop = 7f8fedd. Run 3's branch (08e2523) and run 2's (b8bb0332) both
  survive on origin. PR 5881 is abandoned with its source branch intact and fifteen threads attached;
  ADO reactivates an abandoned pull request, and a fresh one can be opened from the same branch with no
  thread history.
• Unsettled and it will bite a dispatch: docs/agents/agent-tool-traps.md and
  .claude/skills/archon/references/cli-commands.md disagree about what --branch does versus --from.
  One is measured, the other documented, and nobody has run the dispatch that settles it.
• Unverified: whether SendMessage reaches an Archon-spawned worker. No worker has been live to
  measure against.

How the tracker is organised, and why

Decided while charting, 2026-09-17, because the maintainer needs to read dependencies and groupings in
the tools rather than in prose.

Parenthood groups; dependency blocks. GitHub allows one parent per issue (POST /sub_issues takes
replace_parent, which is the proof) and up to eight levels of nesting. So a ticket cannot belong to a
stream and to a map at once, and the map wins: a stream with no children is closed, and a gate that
crosses the map's boundary is drawn as a native blocked_by edge, which the GitHub UI renders anyway.

#494 was closed by this charting: its seven
children moved to this map and its body was a pointer to register § G, which now lives in these Notes.

The Azure DevOps mirror, so the client sees this work. The client has no GitHub access and the daily
runs off ADO. This map is mirrored as two Features under Epic 42980, each holding one User Story per
ticket. Each Story carries title, a link to its GitHub issue, story points, hours and state — never a
copy of the body, so nothing can drift. The Features carry no points of their own; the board rolls the
Stories up, so nothing is counted twice. Tasks 43100, 43101 and 43102 stay where they are: they are
Consumer work, and two of them belong to #495.

Two Features rather than one, cut at the dispatch. 43124 holds everything that gates and
performs the run, and closes when the seal is scored. 43125 holds what the map places after
the run: act 2 of the delivery, and the two instrument stories that seed the next run. One Feature would
have stayed open months past the point where run 4's question was answered, which is the same reason
this map refused to hang off Feature 42975.

#439 moved. Its mirror 43036 left Feature 42975 for 43124. It was already a User
Story, so the move was a change of parent and nothing else. This settles the question this map's
#504 left open, and the answer is "it moves".

Hours are the maintainer's own time — reading, grilling, deciding, reviewing — not the agent's
elapsed time. Both estimates were made on 2026-09-21, before any grilling closed. Created 2026-09-21,
recut into two Features 2026-09-22.

43124 — DLC - Run 4: are the chain's claims about its own work derived from the work?
Twenty-four Stories, 114 points, 69 hours, read from Azure DevOps on 2026-10-28. The points and hours of #657, #652, #660, #658, #484, #492 and the follow-ups #662, #664, #666, #667 and #670 were proposed by unic-sdlc-orchestrator-8 and approved by the maintainer on 2026-10-28. The follow-ups are mirrored at needs-triage, because triage is work too, whatever its outcome. #484 and #492 are children of #495, not of this map, and sit here because they block #502. #439's points went from 13 to 8 in Azure DevOps, and #483's from 5 to 8 on 2026-10-28.

43125 — DLC - Deliver the component, and what run 4 leaves open.
Four Stories, 21 points, 10 hours.

Every Azure DevOps Story title starts with DLC #NNN -, NNN the GitHub issue, and each GitHub blocked_by edge between two mirrored tickets is a Predecessor link (2026-10-28). No tracker expresses the GitHub-to-ADO edge itself. It is hand-maintained, and that residue is the price of two
trackers, not a defect to fix here.

Ticket order, and what the frontier offers first

The frontier is the open, unassigned, unblocked children, and first in map order wins. That order:

1. #425 — a workflow node reaches no MCP server unless it declares one. Measured
   on Archon 0.10.1 on 2026-09-22, after this map was charted. Every Box routes its tracker, docs and
   design access through an MCP server, so a run dispatched before this lands produces artefacts the
   seal would score as the chain's claims about work it did without any of them. The fix is one line
   per node and the file it points at is already tracked in the Consumer; what is not decided is who
   owns that file and what a Box does in a repository that has none. This is the first grilling
   under the two-ticket shape: the decision ticket closes on approval and the implementation is
   filed as its own ticket with its own Azure DevOps Story.
2. #439 — re-grilled before anything is
   dispatched from it. It has carried ready-for-agent since 2026-09-04 and has waited twelve days.
   That label means its criteria were settled, not that it may be dispatched, and the root AGENTS.md
   says a ticket that has sat more than a few days is re-grilled rather than trusted. Nineteen criteria,
   written against the tree #430 left.
3. #499 — the claims list, because the seal
   cannot predict over a set nobody has written down.
4. #501 — the variance baseline, which runs
   in parallel with everything else and blocks only bug(unic-archon-dlc): synthesize dedupes before identity is assigned and merged across two files against its own rule #486.
5. #505 — no Box can target a base
   branch that is not the trunk, so act 1 has nowhere to merge. Measured after this map was charted;
   it edits unic-dlc-build.yaml, which bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439 edits too, so whichever is grilled second says which
   lands first.
6. #482, then bug(unic-archon-dlc): goals-check counts, the precheck reads, and only the counter reaches evidence.json #483, bug(unic-archon-dlc): the summary's § "Checks this review did not run" is false when a sub-agent ran a declared command #487, bug(unic-archon-dlc): report.md says "nothing was flaky" from verification's single final run #488 — the four
   remaining precondition fixes.
7. #504 — the ADO mirror, whenever; it
   blocks nothing and the client reads the board daily.

Then #500 (the seal), then #502 (the dispatch), then #503 (the demo and act 2), then #379, #485 and #489.

The tree, as it stands

#373  wayfinder: unic-archon-dlc is prose, and proven at the Consumer
├── #456  run 3's map (closed, adopted retroactively)
├── #498  THIS MAP
│   ├── #425  nodes lose their MCP servers on 0.9+         precondition · grill first
│   ├── #439  open-pr precedes its gate                    precondition · re-grill
│   ├── #482  reconcile marks fixed on omission            precondition
│   ├── #483  goals-check counts, the precheck reads       precondition
│   ├── #486  synthesize dedupes before identity           precondition · blocked by #501
│   ├── #487  "this review executed none of them"          precondition
│   ├── #488  "nothing was flaky"                          precondition
│   ├── #505  no Box can target a non-trunk base          precondition
│   ├── #499  the claims list
│   ├── #500  the seal                                     blocked by #499
│   ├── #501  the variance baseline                        parallel
│   ├── #502  dispatch run 4 and score it                  blocked by 11
│   ├── #503  demo to Jessi, act 2                         blocked by #502
│   ├── #504  the ADO mirror
│   ├── #379  land a rendering component                   blocked by #503
│   ├── #485  seed the Standards axis                      after the run · blocked by #502
│   └── #489  a controls node in /build                    after the run · blocked by #502
├── #382 #384 #385 #408
└── (16 closed)

#495  stream: Archon and the machine underneath            out of scope, a candidate map of its own
├── #484  runtime: bun, undeclared                         → blocks #502
├── #492  folder project swallows child clones             → blocks #502
└── #490 #491 #493

Skills

/grill-with-docs for a ticket whose criteria are not settled — typed by the maintainer, never
/grilling alone, which has nowhere for a decision to land. /writing-for-agents for anything an agent
reads. /code-review before any pull request, and its four reads run twice: once on the criteria, once
on the diff. /domain-modeling when a term is in play.

Two plugin conventions a ticket on this map will trip over. The ADR convention since
#452 is inline revision —
Accepted (YYYY-MM-DD, revised YYYY-MM-DD), no amendment block
(apps/claude-code/unic-archon-dlc/docs/adr/README.md:18). And
#460 has not landed, so the baton is still
issues.json across 22 plugin files; #439 criterion 13 turns it into an object without renaming it.

A measured tracker trap. issue_dependencies_summary.blocked_by, which the frontier query in
docs/agents/issue-tracker.md compares against 0, lags a dependency write by seconds. Measured
2026-09-17 23:02 CEST: immediately after a tenth blocker was added to #502 the summary read 9 while
GET /dependencies/blocked_by listed 10, and it agreed on a later read. A session that wires edges and
then runs the frontier query in the same breath can be offered a blocked ticket. Read the list endpoint
when it matters.

Every ticket carries a session opener — a comment titled "How to start this session". When a ticket
carries more than one, the newest is authoritative and older ones are marked stale. Read it before
starting; it is not a restatement of the body.

Start a session with /wayfinder <this map> to take the next frontier ticket, or
/wayfinder <this map> #<n> to take a named one. One ticket per session, except research, which runs in
parallel.

Decisions so far

• Act 1 keeps integration/dlc; No Box can target a base branch that is not the trunk, so run 4 cannot merge to integration/dlc #505 stays a precondition — decided by the maintainer 2026-09-17 23:35 CEST, "mantener, aunque sea una excepción, al menos de momento": the two-act split stands, comparability with runs 1 to 3 is the reason, and No Box can target a base branch that is not the trunk, so run 4 cannot merge to integration/dlc #505 is grilled as the seventh precondition of #502. Recorded as an exception for now; nothing on the map depends on it becoming permanent. The trade-off it closed is in this body's history.

• Can an Archon node reach a plugin agent, command or skill?: yes, on v0.10.1, once the plugin is installed on the machine. An agent reaches a node by subagent_type with no declaration. A command reaches a node as the whole prompt, or through skills:. A skill reaches a node only through skills:. settingSources: [project] removes user-scope plugins. Committed settings alone reach nothing.

• The pr-review summary's § "Checks this review did not run" is false when a sub-agent ran a declared command: keep the instruction and make the block true to it. It no longer claims nothing ran. A sub-agent's reported check is attributed, named by need, and kept out of "What's good". ADR-0037 §8 is amended. Implemented by the pr-review summary states what the Box instructed.

• Archon 0.9.0 stops workflow nodes inheriting MCP servers: no Box-level fix inside Archon, because the measured facts on 0.13.0 rule it out. The maintainer decided to leave Archon for a new plugin: Does the DLC stay on Archon, or move to a new plugin that does not run on it?. Run 4 is on hold until Is run 4 still worth running on Archon, now that the plugin is being replaced? closes.

• Is run 4 still worth running on Archon, now that the plugin is being replaced?: no. Run 4 is dropped, Dispatch run 4, end it in a merge, and score the seal #502 and this map close, unic-archon-dlc is frozen, and every open child closes as superseded. The claim-derivation principle and a list of the failures that broke it go to Product spec for the DLC successor plugin #687 as the successor's requirement.

(what was decided before this map was charted is in #373
and #456, each § Decisions so far)

Not yet specified

• Run 5, as a contingency only. Run 4 ends in a merge, so the delivery question Land a rendering component on develop, so the client sees the walk's output #379 carried is
  answered inside it. Run 5 exists if run 4's output turns out not to be mergeable after the demo, and
  its question would then be what delivers instead. Nothing is charted for it until that is known.
• When act 2 happens, and what divergence it can tolerate. integration/dlc drifts from develop
  while the demo waits. Nobody has said how long is too long, and the answer probably depends on what
  else lands on develop in the meantime.
• Whether build-pr-gate is ever exercised. Two consecutive runs will have skipped it by running
  afk. A gate nothing has ever fired is indistinguishable from a gate that cannot fire — the same
  shape fix(unic-archon-dlc): /specs skips the grilling its config requires and reports halts that never fired #441 shipped and bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439 criterion 7 caught. It is not run 4's subject and it is not nothing.
• Whether /qa's three unrecorded node outputs matter — #458.
  /qa is on run 4's path for the first time, because run 4 merges. Ruled outside run 3 when /qa was
  not on the path; that reason has expired and nobody has looked again.
• Whether the three upstream-Archon tickets are filed on Archon's own tracker — bug(unic-archon-dlc, upstream: Archon): archon complete <branch> --force deletes the branch on origin, silently #491, bug(unic-archon-dlc, upstream: Archon): a folder project registered on a parent directory swallows every child clone, and doctor passes it #492, bug(unic-archon-dlc, upstream: Archon): a loop node reports its last iteration's duration as the node's #493. The
  maintainer's call, as with #425. Two of them
  gate this map's dispatch regardless of where they are filed.

Out of scope

• /qa's and Archon's machine defects — #495
  and its five children. None of them is about a verdict: they are the workflow runner and the machine.
  bug(unic-archon-dlc): two Box nodes declare runtime: bun and nothing declares the dependency #484 and bug(unic-archon-dlc, upstream: Archon): a folder project registered on a parent directory swallows every child clone, and doctor passes it #492 stay out as tickets and come back as blocked_by edges on the dispatch, because they are
  gates on a dispatch rather than members of this effort.
• Giving DXP-DesignSystem a pipeline, or publishing Storybook. It has no CI of any kind; the demo is
  a local Storybook on a shared screen, by design. Recorded on wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373, not this map's job.
• Whether mechanisms carry knowledge where documents did not. Answered by run 3, scored in the
  register § "The sealed prediction, scored — run 3". Nothing here reopens it.
• Reducing the reviewer's variance. spike(unic-archon-dlc): the review Box is not deterministic across iterations on identical code #485's Standards-axis seeding is a treatment for a different
  subject and lands after this run. The pre-fix baseline is taken now because it stops being observable
  once bug(unic-archon-dlc): synthesize dedupes before identity is assigned and merged across two files against its own rule #486 changes synthesize.