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

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: the bench has 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

The bench is a procedure and a frozen input, not a piece of software. The plugin is what goes
inside it.

Input	08e2523 on archon/task-unic-dlc-build-1789577744739, confirmed on origin 2026-09-17 21:12 CEST
Procedure	run unic-dlc-pr-review twice against one pull request without changing a byte between iterations
Correct answer	known by construction: fixed: 0. Nothing changed between the iterations
Subject	the plugin

Run 3 produced n=1 of this experiment by accident: fixed: 6 · still_present: 7 · new: 4 where the
truth was fixed: 0 · still_present: 13. That is the "before", and it is why no pre-fix baseline is
needed for the tickets whose correct answer is known a priori.

The bench covers 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 measurement is why run 4 is a full walk with the bench inside it rather than a
bench on its own.

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, posts, byte-identical commit)   ← the bench, exercises #482 #485 #486 #487
   ↓
the maintainer reads the posted threads on the pull request
   ↓
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:

• Not one byte changes between the two review iterations. Any fix commit lands after the second,
  never between them. Run 3 managed this by accident; here it is the experiment.
• 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. #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 #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

Class	Tickets	What it needs
Correct answer known a priori	#482 #483 #487 #488 #489	no baseline; fixed: 0 is true by construction
Plumbing upstream of #482	#486	the dedup destroys cross-iteration continuity, which is how a finding vanishes. Run 3's instance was rescued by the semantic fallback, by luck
Treatment visible only against a distribution	#485	a pre-fix baseline, or nobody can say whether variance fell or only moved

Seven are preconditions of the dispatch: #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
  six 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 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 #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, one codebase row _git/DXP-DesignSystem | repo | develop, bun 1.4.2, plugin
  unic-archon-dlc 0.28.0 at project scope, .archon/ clean.
• 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. Each ticket on this map that is real work gets a User Story under a new Feature, not
under Feature 42975, which is run 3's and would never close. Each mirror carries title, a link to its
GitHub issue, points and state — never a copy of the body, so nothing can drift. Tasks 43100, 43101
and 43102 stay where they are: they are Consumer work, and two of them belong to #495.

No tracker expresses the GitHub-to-ADO edge. 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. #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.
2. #499 — the claims list, because the seal
   cannot predict over a set nobody has written down.
3. #501 — the variance baseline, which runs
   in parallel with everything else and blocks only #486.
4. #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 #439 edits too, so whichever is grilled second says which
   lands first.
5. #482, then #483, #487, #488 — the four
   remaining precondition fixes.
6. #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 FZAG
├── #456  run 3's map (closed, adopted retroactively)
├── #498  THIS MAP
│   ├── #439  open-pr precedes its gate                    precondition · re-grill first
│   ├── #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 9
│   ├── #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; #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 #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.

(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 #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 #441 shipped and #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 — #491, #492, #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.
  #484 and #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 #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. #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 #486 changes synthesize.

Start with parent issue #373 and the six precondition tickets, then inspect the unic-archon-dlc plugin and the /specs, /tickets, /build and /qa entry points. Read docs/agents/agent-tool-traps.md alongside .claude/skills/archon/references/cli-commands.md before dispatch. Done means the frozen bench run, recorded claim derivations, merge to integration/dlc, and documented result are complete.