Refresh the Consumer's DLC install before run 4

Why

Run 4 (#502) runs the Boxes the Consumer has installed. On 2026-10-22 the Consumer's develop at 7f8fedd5 carries the Boxes and Methods of the 0.29.0 release, under a 0.28.0 header. unic-archon-dlc 0.31.0 is on this repository's develop, and two of its changes are breaking:

0.30.0 (#520) moves the managed blocks to unic-dlc:begin / unic-dlc:end. /setup migrates them in place.
0.31.0 (#505) takes a run's base branch from Archon's $BASE_BRANCH.

A review of the install on 2026-10-22 also found leftovers that /setup does not clean up. This ticket refreshes the install and removes them in one Consumer pull request, because /setup rewrites the same files. The same pull request records five facts run 3 measured, because they go into the Consumer doc that criterion 7 edits (amended 2026-10-22).

Five other install differences are tracked on the Consumer's board. The tracker label mapping is out of scope here: the Consumer's tracker is being unified or redefined, and a mapping fixed now would likely change.

Blocked by

#556, so the install carries its ADR-link fix. It ships as 0.36.1. (Amended 2026-10-28: the release to main is no longer a blocker. The marketplace has no ref pinned, so it reads this repository's default branch, which is develop, not main. main stays at 0.29.0 on purpose.)

Acceptance criteria

All paths are in the Consumer repository. The work lands through one Consumer pull request to develop, on a branch that follows the Consumer's convention, feature/<work item>_<slug>, with work item 43344. The pull request links Story 43344 and Task 43100, which covers criterion 9.

The Consumer's installed plugin is 0.36.1 or later, the newest version on this repository's develop at install time, at project scope (claude plugin update --scope project). The Consumer's marketplace entry pins "ref": "develop" in its GitHub source, so the install no longer depends on this repository's default branch. The pull request names the installed version and the gitCommitSha that installed_plugins.json recorded for it. (Amended 2026-10-28.)
/unic-archon-dlc:setup was run after the update, from the installed version's cache directory, and the pull request commits what it wrote. Every Box and Method header names the installed version, and the managed blocks use the unic-dlc:begin / unic-dlc:end markers. (Amended 2026-10-28.)
.archon/unic-dlc.config.yaml holds no methods key. Neither the plugin's README configuration reference nor /setup reads one.
.prettierignore names .archon/methods/ and .archon/workflows/ once each, inside the managed block. The hand-written copies above the block, with their comments, are gone. Any other entry stays.
The Consumer's CLAUDE.md has one ## unic-archon-dlc heading, the managed block's. The hand-written section is renamed and keeps its rules in CLAUDE.md. Only reference detail moves to docs/agents/unic-archon-dlc.md, and a pointer stays in its place. (Amended 2026-10-28.)
Every § pointer from CLAUDE.md into docs/agents/unic-archon-dlc.md names a heading that exists there.
The install record in docs/agents/unic-archon-dlc.md keeps the installed version and drops the commit and file hashes. The Box headers already name the version, and the hashes go stale on the next /setup run.
The pull request reports the base branch line that /setup printed, and it is develop. If it is not, the pull request sets worktree.baseBranch: develop in .archon/config.yaml, nested under worktree:, reruns /setup, and reports both lines. (Amended 2026-10-28.)
docs/agents/unic-archon-dlc.md states the facts below, five that run 3 measured and one added since, that an agent cannot infer, one entry each with the measurement that proved it and the Archon version it was measured on, which is the version criterion 12 installs. A fact that no longer holds on that version is dropped or rewritten, and the pull request says which:
1. Two Box nodes declare runtime: bun, and the machine must provide it. Run 3's first dispatch died on ENOENT without it.
2. Before the first dispatch on a new machine, check Archon's codebase row (kind, default_cwd, default_branch). A folder project on a parent directory removes worktree isolation, and archon doctor passes it.
3. archon complete --force deletes the branch on origin without saying so. Pin refs/rescue/* first, or clean up with git.
4. The Archon database keeps tool inputs, not their output. The runner's output lives in ~/.claude/projects/<worktree-path>/*.jsonl, a live directory that a worktree with the same name reuses.
5. The Box commits and posts under the machine's git and tracker identity. Only the message shape, the branch name and the HTML markers tell its work apart.
6. Added 2026-10-28, not measured yet: from Archon 0.12.0 a run that completes removes its own clean worktree when every commit is on a remote, and keeps the branch. Criterion 13's node run measures where that run's artefacts live and whether they and the worktree survive completion. Rewrite the doc's procedure for recovering a killed run if the answer changes it.
The underlying defects have their own tickets in this repository. This criterion records the facts for the Consumer's sessions; it fixes none of them. A reading of Archon's release notes on 2026-10-28 suggests that 9.3 and 9.4 no longer hold on 0.13.0 and that 9.2 changed. Measure them; do not copy this note. (Amended 2026-10-28.)
sdlc_needs.format in .archon/unic-dlc.config.yaml names a command that exits non-zero on unformatted files and writes nothing, as the comment above the key already asks. Today it names pnpm format, which rewrites the tree and exits 0. The pull request shows the command run twice: on a tree with one file deliberately unformatted, where it exits non-zero and leaves the file unchanged, and on a clean tree, where it exits 0. (Added 2026-10-26, amended 2026-10-28.)
The Consumer doc's section on the Archon version no longer tells sessions to hold Archon at 0.7.0. It names the version criterion 12 installs. It states that from Archon 0.9 a Box node reaches no MCP server until the Boxes declare mcp:, and that from 0.12 it loads no plugin, and so none of a plugin's skills, until the Boxes declare plugins: (#425). It records criterion 13's result. It states that every Box load warns that workflow-level interactive: has no effect, and that the warning is expected. The doc's other 0.7.0 statements agree with it. (Added 2026-10-26, amended 2026-10-28.)
Archon on the machine is 0.13.0 or later (archon --version), upgraded before /setup runs. archon provider add claude has run after the upgrade, a default provider resolves, and archon doctor passes. The pull request names the version. (Added 2026-10-28.)
The tracker contract's § Access names an MCP server or a skill. The pull request states which one, and whether a Box node on the criterion 12 version reaches it, measured by running one node, not inferred. The same run measures criterion 9.6. The result is also posted on #425, whose fix it feeds. (Added 2026-10-28.)

Out of scope

The tracker label mapping in docs/agents/triage-labels.md.
The install differences tracked on the Consumer's board.
Creating integration/dlc and dispatching run 4: #502.
The Box changes #425 needs: declaring mcp: or plugins:, and removing interactive:. This ticket measures; Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425 fixes.

Opener for #657, written at dispatch on 2026-10-28 by unic-sdlc-orchestrator-9. Edited in place the same day, before dispatch, twice: the start condition no longer waits for a release to main, and the opener follows the criteria the grilling amended (comments 6477313356 and 6477376311, which adds criterion 9.6).

What it produces

One Consumer pull request to develop that refreshes the installed unic-archon-dlc and meets all thirteen criteria in this ticket's body. This is implementation, not a grilling. Do not start it with /wayfinder: that skill's "work through the map" mode resolves a ticket by closing it, and this ticket stays open until the Consumer pull request merges. No skill is needed. /unic-archon-dlc:setup is the one command the criteria require.

Where the session runs. The plugin is installed at project scope, so /unic-archon-dlc:setup exists only in a session rooted in the Consumer repository. A session rooted in this repository cannot do the work either: its NDA hook refuses every command whose path names the Consumer's folder. Work in a Consumer worktree outside the clone, on a branch made from a freshly fetched origin/develop. The branch follows the body's convention with work item 43344. Link the pull request to Story 43344 and Task 43100.

Order. The criteria land in three steps. This replaces every earlier split.

Now: criterion 10.
After the Archon upgrade: criteria 9, 11, 12 and 13. Ask the maintainer before you upgrade. Archon is one binary for the whole machine, so the upgrade changes it for every session that runs a Box here, other seats included. Before the upgrade, keep a way back (maintainer, 2026-10-28):
- Copy the current binary. On this machine archon is a Homebrew link, so copy the file it points at (realpath "$(which archon)") to a path outside Homebrew, and record its archon --version.
- Back up the database with sqlite3 ~/.archon/archon.db ".backup '<path>'", not with cp. The database runs in WAL mode, with -wal and -shm files beside it, so a plain copy can miss writes.
- Whether 0.13.0 migrates the database so that 0.10.1 no longer opens it is not measured. Record what happens. Do not try a rollback unless the maintainer asks for one.
After unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556 merges (this ticket is blocked_by it): criteria 1 to 8. unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556 ships as 0.36.1. No release to main is needed, and main stays at 0.29.0 on purpose. Before installing, confirm what develop carries:

gh api 'repos/unic/unic-agents-plugins/contents/apps/claude-code/unic-archon-dlc/.claude-plugin/plugin.json?ref=develop' --jq .content | base64 --decode | grep '"version"'

Read order

This ticket's body. The grilling amended it on 2026-10-28: criteria 1, 2, 5, 8, 9, 10 and 11 changed, and 12 and 13 are new. Then comment 6477313356, which says why, and comment 6477376311, which adds criterion 9.6.
Archon's release notes from the version this machine runs (0.10.1 on 2026-10-28) up to the one you install, before the upgrade. The 0.12.0 notes are Breaking.
The plugin's CHANGELOG.md, every ### Breaking section from 0.29.0 up to the version you install. The Consumer runs 0.28.0 today, so 0.29.0 is the first one it has not read, read from the installed plugin cache after the update. Every version from 0.30.0 to 0.36.0 has a Breaking section. /setup migrates the managed blocks, but a Breaking entry can still ask the Consumer for a step /setup does not take. List each Breaking entry in the pull request and say whether /setup handled it, you handled it, or it does not apply.
The Consumer's docs/agents/unic-archon-dlc.md, all of it. Criteria 7, 9, 11 and 13 edit it. A version refresh re-reads the whole document, not only the version rows: four claims in it were true when written and false later, and a row-only edit is how they survived.
The Consumer's CLAUDE.md, both ## unic-archon-dlc sections. Measured on the local origin/develop ref on 2026-10-28, they are at lines 80 and 496. The orchestrator could not fetch, so the ref may be stale.

The one trap: running the old `/setup`

A Claude Code session loads its plugins when it starts. If you run claude plugin update --scope project inside a running session and then call /unic-archon-dlc:setup in the same session, you may run the old command against the new cache, or the old command against the old cache. The run looks normal and writes 0.29.0 Boxes and the old unic-archon-dlc:begin markers again.

This machine makes it worse. It also has the plugin installed at user scope (0.36.0 on 2026-10-28), beside the project-scope 0.28.0 the Consumer uses. Which one a Consumer session loads is not measured. Update the plugin from a shell before you start the session, or restart the session after the update. Then confirm that the command you are about to run comes from the installed version's cache directory, as criterion 2 requires. After /setup, the bar below catches a stale run. If you only notice it at review time, you will have spent an hour.

Decisions this ticket does not make

The grilling settled the version, the pin, the rename and the base branch. One small point remains, and the orchestrator settled it on 2026-10-28. Report back if it is wrong for what you find.

Criterion 3 and /setup's report. /setup prints a methods: line in its final report. That line is output built from the Methods it installed, not a read of a methods config key, so it does not contradict criterion 3. The Consumer config is a tenant-owned file that /setup reports on and never rewrites, so removing methods: {} is a hand edit.

Other traps

The project-scope install is registered to the main clone's path, not to your worktree's. Claude Code's install record for this plugin in the Consumer names the registered clone as its projectPath. A claude plugin update --scope project run from the worktree may therefore find no install to update, or create a second one. Not measured. Run the update from the registered clone, then check the version that the record and /setup report.
From Archon 0.12.0 a node loads plugins only by name. No Box on develop declares plugins: or mcp:. Read Archon's own documentation for what a node does when a plugin it did not name is installed at user scope, as this machine's are. Criterion 13 runs one node: do it early, because a node that fails before its first turn changes the plan for run 4. The same run measures criterion 9.6. State in the result whether a plugin the node did not name loaded, and whether the node then failed before its first turn. Post that line on Refresh the Consumer's DLC install before run 4 #657 as well as Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425, because wayfinder: e2e specs from acceptance criteria, at a second Consumer #538's Box edits rely on it. Every Box load also warns that workflow-level interactive: has no effect. That warning is expected (criterion 11).
The Consumer remote may need credentials that a non-interactive shell cannot give. On 2026-10-28 the orchestrator's git fetch failed with could not read Password ... Device not configured. If yours does too, ask the maintainer. Never work from a stale origin/develop.
The Consumer's own pre-push refuses develop and main from any worktree. A branch made with git worktree add -b <branch> <path> origin/develop tracks develop. Add --no-track, then push with -u origin <branch>.
The managed blocks today use the old markers. .prettierignore carries unic-archon-dlc:begin / unic-archon-dlc:end (measured on the local ref). /setup reports migrated from unic-archon-dlc markers for a block it moved. Criterion 4 also removes the hand-written copies above the block, which /setup does not touch.
Criterion 10's command must be checked both ways. Run it on a tree with one file deliberately unformatted and expect a non-zero exit and an unchanged file. Then run it on a clean tree and expect exit 0. A command that has never failed in front of you does not count as proven.
Criterion 9.1 still holds on develop. Two nodes in unic-dlc-build.yaml declare runtime: bun (measured 2026-10-28). Measure the other four on the upgraded Archon. The body's note that 9.2, 9.3 and 9.4 changed comes from release notes, not from a run.
Harvest before cleanup, and from 0.12.0 cleanup can happen with nobody acting. By the release notes, a completed run removes its own clean worktree once every commit is on a remote (criterion 9.6). So for criterion 13's node run, find where its artefacts live and copy them out before the run completes. Then record whether the worktree survived, and whether uncommitted files kept it. Before 0.12.0, harvesting before you complete a run was enough. The Consumer doc § Three Archon defects that land here → § Recovering a killed run holds the procedure.
Name no client in anything that reaches GitHub, including your reports on this ticket. The Consumer pull request is private, so this rule covers only what you post here.

The bar that proves it

Every Box header in .archon/workflows/ and every Method header names the installed version, and grep -r 'unic-archon-dlc:begin' over the Consumer tree finds nothing.
The pull request quotes the archon base: line /setup printed (criterion 8), the version line from the gh api check above, the gitCommitSha from installed_plugins.json (criterion 1), and archon --version with a passing archon doctor (criterion 12).
Criterion 13's node run is quoted from its own output, and the same result is posted on Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425.
pnpm typecheck and the six checks under checks/ pass in the Consumer worktree after the final commit, judged by exit code.

A false pass looks like this: every file is edited and every criterion reads satisfied, but the Box headers still say 0.29.0 or 0.28.0, because /setup ran from the old cache. Another: criterion 13 answered from the Box YAML or the release notes instead of a node that ran. Another: criterion 10's command exits non-zero on a clean tree too, or never exits non-zero at all.

Review and handover

Open the Consumer pull request to develop, linked to 43344 and 43100.
Review it with archon workflow run unic-dlc-pr-review "<slug>" --from <your branch>. Invoke Archon from the Consumer's registered clone, never from your worktree. Archon pins one source path per repository and refuses a second with exit 0. Approve the review-gate from the terminal and never reject: the gate has no on_reject, so a reject destroys every finding with no record. Record which version header the reviewing Box carried, because this pull request changes the Boxes the review runs. That is evidence for the release.
Fix the verified findings. Record refutations with evidence. A fixed from iteration 2 or later is not evidence: read it against the diff. Re-run the bar after the final fix.
After the last commit, re-read the pull request description against the final diff.
Report readiness on this ticket with the pull request link. Do not merge. A Consumer maintainer merges.

BEFORE YOU FINISH, AND WHENEVER YOU LEARN SOMETHING THAT WOULD HAVE CHANGED THIS PROMPT,
report to unic-sdlc-orchestrator-9 with four things and nothing else:
  1. what you expected
  2. what happened
  3. the command or file that proved it
  4. whether it changes only this ticket, or every session in this repo
Send it when you learn it, not only at the end — a session that dies unreported
takes its learnings with it.
Talk only to unic-sdlc-orchestrator-9. Do not message another orchestrator or its
sessions; tell unic-sdlc-orchestrator-9, who relays it.

Amended 2026-10-28, approved by the maintainer

Blocked by no longer names a release to main. It names #556, now a native blocked_by edge. The install should carry unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556's ADR-link fix.
Criterion 1 said "the newest release on main". It now says "the newest version on develop, one that carries unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556".

Why: the premise was wrong. The Consumer's marketplace entry pins no ref, so Claude Code reads this repository's default branch, which is develop. main stays at 0.29.0 on purpose, as the version other teams are told to install. Measured with gh repo view --json defaultBranchRef and on the local marketplace checkout, which sits on develop at f83bbf6.

The opener above was edited in place to match. It had not been dispatched.

— unic-sdlc-orchestrator-9

Dispatched before #556 merged, 2026-10-28

The maintainer asked to start now. #556 is open, and its PR #673 is in review under /afk-loop 373. So the work splits in two:

Now: criteria 9, 10 and 11. They edit docs/agents/unic-archon-dlc.md and .archon/unic-dlc.config.yaml. /setup treats both as tenant-owned files: it reports on them and never rewrites them. So nothing done now is overwritten later. Commit them to the feature branch.
After unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556 merges: criteria 1 to 8. That means the plugin update, /setup, and the edits that depend on what /setup writes. Re-read the opener's start condition at that point. Do not install a version without unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556.

If criterion 9 or 11 needs the installed Boxes to settle a fact, measure it on develop's Boxes, not the Consumer's old copy, and say so in the entry.

— unic-sdlc-orchestrator-9

Criteria amended 2026-10-28, approved by the maintainer in a grilling session

The body above is edited in place. What changed and why:

Archon 0.13.0. The maintainer chose the newest Archon, not 0.10.1. New criterion 12 installs it on the machine before /setup, with archon provider add claude, a default provider and a passing archon doctor, which 0.12.0 made required. Criteria 9 and 11 measure on that version. A reading of the Archon release notes from 0.11.0 to 0.13.0 found no change that stops the four Boxes on develop from loading. It ran no Archon binary.
Criterion 1. The floor is 0.36.1, the version unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556 ships as. A Consumer cannot pin a commit, only a branch or tag, so any later develop merge is included. The marketplace entry now pins "ref": "develop". Without a ref, a change to this repository's default branch would move the Consumer to main in silence. The install records gitCommitSha in installed_plugins.json, measured on this machine.
Criterion 2 names the cache directory, because this machine also has the plugin installed at user scope.
Criterion 5 renames only. Criterion 8 says what to do when the base is not develop. Criterion 10 must be seen failing once.
Criterion 13, new: which MCP server or skill the tracker contract's § Access names, and whether a Box node on 0.13.0 reaches it. That is the fact #425 needs. The Box changes stay in Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425.
Branch. The Consumer's convention, with work item 43344.

What can start now

This replaces the split in the comment above.

Now: criterion 10.
After the Archon upgrade: criteria 9, 11, 12 and 13.
After unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556 merges: criteria 1 to 8.

— grilling session for this ticket

Amended again 2026-10-28, approved by the maintainer: criterion 9.6 added. From Archon 0.12.0 a completed run removes its own clean worktree when every commit is on a remote, so a run's artefacts may be gone before anyone harvests them. Criterion 13's node run also measures where the artefacts live and whether they survive completion. The Consumer doc's recovery procedure is rewritten if the answer changes it.

Measured on Archon 0.13.0 (git commit 0d39c1f2), 2026-10-28, for #657 criteria 13 and 9.6.

One node with no `plugins:`, `mcp:` or `skills:` declaration

I ran a one-node workflow from ~/.archon/workflows/ against the Consumer's registered clone. The node used the default worktree isolation and claude/opus. Its prompt asked it to list its own tools, skills and slash commands, and to read one work item through the tracker's MCP server if it could.

The node reached its first turn and completed in 15.3 s with exit 0. It did not fail as misconfigured.
It had no mcp__ tool, so it could not reach the tracker's MCP server that the Consumer's .mcp.json registers at project scope. A ToolSearch for the server's tools found none.
It saw no skill and no slash command. The Skill tool was present, but nothing was listed under it. The user scope on this machine has 36 Claude Code plugins installed, unic-archon-dlc among them, and none of them loaded.

So a Box node on 0.13.0 that declares neither mcp: nor plugins: reaches neither the tracker's MCP server nor any plugin skill. It does not fail when plugins are installed at user scope. It loads none of them. This corrects the note in this repository that says such a node fails before its first turn.

The node's own report:

## 1. Tools whose name starts with `mcp__`
none
## 2. `<tracker server>` MCP server
no <tracker server> tool
## 3. Skills and slash commands
none
The `Skill` tool is present, but no skill listing reached this session, so I see no skill or slash-command names. That includes none from `unic-archon-dlc`.

Worktree cleanup on completion (9.6)

Run	Worktree state at completion	Worktree after	Local branch after	Branch on `origin`
the node above	clean, no commits beyond `develop`	removed	kept	none, never pushed
a one-node `bash` run that wrote one untracked file	one untracked file	kept	kept	none

For the second run Archon printed: ⚠️ Kept worktree <path>: it has uncommitted changes. It stays listed by archon isolation list.

The node's artefact sat in $ARTIFACTS_DIR, at ~/.archon/workspaces/<owner>/<repo>/artifacts/runs/<run id>/. That folder is outside the worktree, and the artefact was still there after the worktree was removed. The run transcript is in ~/.archon/workspaces/<owner>/<repo>/logs/<run id>.jsonl.

Ready for review: the Consumer pull request for #657 is open, reviewed once, and its findings are answered. The pull request is private, so this comment names it only by its number, !5972.

Installed: unic-archon-dlc 0.36.1 at project scope, gitCommitSha 2c55bc60, and Archon 0.13.0. archon doctor passes.
All 13 criteria are addressed. Two facts in criterion 9 are open, and the Consumer doc names both: 9.2 (a folder project on a parent directory) and 9.5 (the Box identity) were not re-measured on 0.13.0. 9.2 needs a parent-directory folder project registered in the machine's Archon database, and 9.5 needs a Box that commits and posts.
The review ran unic-dlc-pr-review from the registered clone. Archon discovers workflows there, so the reviewing Box carried the 0.28.0 header from develop, not the 0.36.1 Box under review. It declares no mcp:, so it posted through the tracker's CLI, the fallback the tracker contract names. Its gate was skipped, because gates.pr-review is not hitl.
Iteration 1 raised six minor findings. The two in the diff are fixed. The four about work-item text are answered on the pull request, and none of them changes the diff.
After the last commit, check-types exits 0 and pnpm test passes 6 files and 69 tests.

A Consumer maintainer merges. This session does not.

Correction to my 2026-10-28 measurement comment (#425 comment 6478282144, #657 comment 6478282779). A fact-check against the Archon 0.13.0 docs found two errors in it. The measurement itself stands.

The plugin count was wrong. The comment says 36 plugins are installed at user scope. That number counted every plugin in installed_plugins.json. 30 of them are at user scope. The result is the same: the node loaded none of them.
"None of them loaded" needs one exception. On 0.13.0 a node with no plugins: declaration loads none of the installed plugins, except the ones built into Claude Code (@builtin). Archon docs, reference/workflow-language, § Plugins: "Your own settings, hooks, permissions and CLAUDE.md still load, and so do the plugins built into Claude Code (@builtin)."

What this changes for #425. Declaring plugins: is not enough for a Box to reach a plugin's skills. The same section says: "A named plugin brings its agents, hooks, LSP servers and commands. Its skills reach the node only when skills: names them, and its MCP servers only through mcp:." A Box node that needs a unic-archon-dlc skill therefore declares the plugin in plugins: and each skill in skills:. A node that needs the tracker's MCP server declares that server in mcp:.

One more measurement from the same day. With no mcp: declaration, a unic-dlc-pr-review run of the 0.28.0 Box on Archon 0.13.0 still read its pull request and posted its review. It used the tracker's CLI, which is the fallback that the Consumer's tracker contract names.

Merged and verified, 2026-10-28. The Consumer pull request !5972 is merged into the Consumer's develop as merge commit 56a002b. Its first parent is the old develop tip 7f8fedd, its second parent is the pull request head 6608fe8, and its tree is identical to that head. The Consumer's registered clone is on develop at 56a002b, so Archon now discovers the 0.36.1 Boxes there.

Still open, and not part of this ticket:

Criterion 9.2 and 9.5 were not re-measured on Archon 0.13.0. The Consumer doc says so. Run 4 measures both.
A Box node reaches no MCP server and no plugin skill until the Boxes declare mcp:, plugins: and skills: (#425). Until then, Box nodes fall back to the tracker's CLI.
The 0.36.1 Boxes have not run in the Consumer yet. The pull request was reviewed by the 0.28.0 Box.

Closing as completed.

— unic-sdlc-orchestrator-9

Navigation Menu

Repository navigation

Refresh the Consumer's DLC install before run 4 #657

Why

Blocked by

Acceptance criteria

Out of scope

What it produces

Read order

The one trap: running the old `/setup`

Decisions this ticket does not make

Other traps

The bar that proves it

Review and handover

Amended 2026-10-28, approved by the maintainer

Dispatched before #556 merged, 2026-10-28

Criteria amended 2026-10-28, approved by the maintainer in a grilling session

What can start now

One node with no `plugins:`, `mcp:` or `skills:` declaration

Worktree cleanup on completion (9.6)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Refresh the Consumer's DLC install before run 4 #657

Description

Why

Blocked by

Acceptance criteria

Out of scope

Activity

orioltf commented on Oct 28, 2026

What it produces

Read order

The one trap: running the old /setup

Decisions this ticket does not make

Other traps

The bar that proves it

Review and handover

orioltf commented on Oct 28, 2026

Amended 2026-10-28, approved by the maintainer

orioltf commented on Oct 28, 2026

Dispatched before #556 merged, 2026-10-28

orioltf commented on Oct 28, 2026

Criteria amended 2026-10-28, approved by the maintainer in a grilling session

What can start now

orioltf commented on Oct 28, 2026

orioltf commented on Oct 28, 2026

One node with no plugins:, mcp: or skills: declaration

Worktree cleanup on completion (9.6)

orioltf commented on Oct 28, 2026

orioltf commented on Oct 28, 2026

orioltf commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

The one trap: running the old `/setup`

One node with no `plugins:`, `mcp:` or `skills:` declaration