Repository navigation
Dispatch run 4, end it in a merge, and score the seal #502
Description
Question
Does the chain, with the six fixes in it, make claims about its own work that derive from the work?
This is run 4. The map's § Notes holds its shape, its rules and the class rule that put six tickets in
front of it and two behind it; this ticket is the dispatch and the scoring.
What resolving this produces
- The run, dispatched on a frozen plugin version, both legs, ending in a merge to
integration/dlc. - The seal scored, by someone who did not run it, against the diff, the posted threads and the node
artefacts — never against a leg's own report. - A run record and the harvested artefacts, parked the way run 3's were (
~/Desktop/run3-parked/, 44 MB:
the run record, every node's artefacts, every run's events, and the sub-session transcripts that hold
the runner output the Archon database does not keep). - A new section of the findings register, and one ticket per finding that is owed one.
Setup this ticket owns
- Create
integration/dlcand point the build's pull request at it. Offdevelopat the commit the
run starts from, named in the run record so the baseline is a commit rather than "develop is empty". - Re-measure the environment rather than transcribe it. The map's § Measured environment carries what
was true on 2026-09-17 21:10 CEST. Run 3's lesson from
#414 is that a transcribed measurement was
false by lunchtime: the design file moved four times while one ticket was open. Stamp each fact with a
time, not a date. - Settle
--branchversus--fromby running it.docs/agents/agent-tool-traps.mdand
.claude/skills/archon/references/cli-commands.mddisagree; one is measured and the other documented,
and no dispatch has settled it. This one will. Record which document was wrong.
Rules this dispatch cannot lose
Each is in the map's § Notes with its reason. Repeated here because a session reads the ticket:
- Not one byte changes between the two review iterations. Fix commits land after the second, never
between them. This is the bench, and run 3 achieved it by accident. gates.build: afkand the review gateafk. Ahitlreview gate lets a human filter findings
before they post, andreconcilewould then compare against what the human let through. The
maintainer reviews afterwards, on the pull request, as its sole human reviewer.- A red verdict is a result. If the build comes out red, #439
criterion 4 means no pull request opens and the run endscancelled. Score it, fix what failed,
re-dispatch as run 4b on the same frozen version. Do not build an escape hatch around the gate this
map exists to build. - Pin
refs/rescue/*before any Archon cleanup verb.archon complete <branch> --forcedeletes the
branch onoriginsilently — #491. Measure
withgit ls-remote --heads originbefore and after. - Count from the node's artefact, never from
node_output. It is an abridged rendering with no sign
that it was cut — #490.
Not decided
- Whether the plugin version for run 4 is a released tag or a branch build, and who bumps it.
- Whether
/specsreruns its grilling from scratch or reuses run 3's PRD. Reusing makes the legs
incomparable; rerunning costs a human turn and moves a second variable. - What the run does if the two review iterations disagree so much that the maintainer cannot read the
threads as one set. Run 3's 0-of-13 hash reproduction is the reason to ask.
Activity
reconcilemarks a finding fixed when the next review omits it, andpostresolves the thread #482goals-checkcounts, the precheck reads, and only the counter reachesevidence.json#483synthesizededupes before identity is assigned and merged across two files against its own rule #486report.mdsays "nothing was flaky" fromverification's single final run #488runtime: bunand nothing declares the dependency #484doctorpasses it #49211 remaining items
orioltf commentedon Oct 21, 2026
Two checks for run 4's precondition list, from the review of PR #650 (#505).
The spike on #505 measured
--baseand the review Box's$BASE_BRANCHfallback on Archon 0.12.1. Two claims that PR #650'sCHANGELOG.mdand its ADR-0038 make are not measured anywhere yet:/builddispatched with--base integration/dlcopens its PR againstintegration/dlc./qawhose$BASE_BRANCHdiffers from the PR's target refuses to merge, and with matching bases it merges intointegration/dlc.Both need the Consumer and a real PR, so they belong next to the review's PR-target path that #505 already hands to this ticket.
A third fact for act 1:
commands/specs.mdandcommands/tickets.mdstill open their gate PRs againstdevelopby hard-coded name. They are command Boxes, so$BASE_BRANCHdoes not reach them, and #505 left them out of scope. If act 1 runs either command againstintegration/dlc, its PR targetsdevelop.docs(unic-archon-dlc): revise ADR-0024 and ADR-0031 inline
docs(unic-archon-dlc): mark the guard path unmeasured and correct the…
orioltf commentedon Oct 26, 2026
Dispatch fact: Box nodes reach no MCP server on this machine today
Measured by another session on 2026-10-23 and relayed by
unic-sdlc-orchestrator-6. The Consumer's Boxes declare nomcp:, and the machine that dispatches runs Archon 0.10.1. On Archon 0.9 and later a node inherits no MCP server unless its Box declares one (#425). So every Box run from this machine today runs without MCP, the tracker included.Nothing runs now, so nothing is broken yet. But any trial run before run 4, and run 4 itself on 0.12.1, meets this until #425 lands. #425 is already one of this ticket's blockers. The Consumer doc still tells sessions to hold Archon at 0.7.0; #657 criterion 11 rewrites that line.
orioltf commentedon Oct 27, 2026
Run 4 coverage note from the
/afk-loop 498review of PR #661 (fix for #482, 2026-10-28)Round 2 of the review walked #482's four cases against the Box and found that they hold. It also found branches of the new
unic-dlc-pr-reviewbehaviour that run 4's shape, as #482 places the cases, never exercises. If run 4 is meant to prove them, it needs these steps:reconcilemarks a finding fixed when the next review omits it, andpostresolves the thread #482 decision 7). Resolve one thread whose finding the next review reports again, and check thatpostreopens it with one reply. This is the only new status changepostmakes on the tracker.fixedmust stayretired, and its thread must get no "check by hand" reply.prepreads that from the thread's reply marker, and only a later iteration reads it.A scoped finding that turns
unverifiedis exercised only if the reviewer happens to emit one.orioltf commentedon Oct 28, 2026
#657 now installs Archon 0.13.0 or later on the machine before the Consumer's
/setupruns (its criterion 12, decided 2026-10-28). Run 4's Archon freeze can start from that version. A reading of the release notes from 0.11.0 to 0.13.0 found no change that stops the four Boxes ondevelopfrom loading. Three machine steps are required after the upgrade:archon provider add claude, a resolvable default provider, and a passingarchon doctor.orioltf commentedon Oct 30, 2026
Run 4 is on hold. Is run 4 still worth running on Archon, now that the plugin is being replaced? now blocks this ticket. It follows Does the DLC stay on Archon, or move to a new plugin that does not run on it?
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: run 4 is dropped (decision 1).—
unic-sdlc-orchestrator-9