Dispatch run 4, end it in a merge, and score the seal

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/dlc and point the build's pull request at it. Off develop at 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 --branch versus --from by running it. docs/agents/agent-tool-traps.md and
  .claude/skills/archon/references/cli-commands.md disagree; 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:

1. 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.
2. gates.build: afk and the review gate afk. A hitl review gate lets a human filter findings
   before they post, and reconcile would then compare against what the human let through. The
   maintainer reviews afterwards, on the pull request, as its sole human reviewer.
3. A red verdict is a result. If the build comes out red, #439
   criterion 4 means no pull request opens and the run ends cancelled. 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.
4. Pin refs/rescue/* before any Archon cleanup verb. archon complete <branch> --force deletes the
   branch on origin silently — #491. Measure
   with git ls-remote --heads origin before and after.
5. 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 /specs reruns 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.

Start with the map’s § Notes, then read docs/agents/agent-tool-traps.md and .claude/skills/archon/references/cli-commands.md before measuring the --branch versus --from behavior. Review the linked issues and run 3’s parked artefacts for the required safeguards. Done means a frozen-version run reaches a merge or records its cancellation, with the run record, artefacts, scored seal, findings register section, and owed tickets produced.