Rewrite commands/setup.md from scratch as prose

Question

Rewrite commands/setup.md from scratch, as prose with no module behind it.

Re-scoped 2026-08-24 by #402. Two things
changed. /setup was never retired — decision 14 said it becomes prose, and decision 6 keeps setup
inside the 1.0 box set — so this file is the Consumer's installer and the most load-bearing command in
the plugin. And the write actions went from four to six, under one ownership rule. The decision passage
on #373 carries the reasoning.

The history still matters. /setup began as a copy of Matt's setup skill, storing the picked choices
in a YAML file instead of whatever his skill used. Then an upstream Method rename and an Archon release
both broke migration, which is why the Methods got bundled into the plugin rather than installed by the
Consumer — a decision that bought reliability and cost a 468-line installer that #371 says produces
most of the plugin's defects. An agent does every action below with Read, Write and Bash. The hand
install from the Consumer ticket is the sequence to start from, and it has now been run against a real
Consumer.

The six actions, and the one rule that governs all of them

Four artefact classes, two treatments. The Boxes and the Methods are verbatim plugin output: /setup
owns them and replaces them silently, as
ADR-0036 D3
already says. The config and the two tracker docs are tenant-authored: /setup writes each one only
when it is absent, and on a re-run it reads, reports what differs, and changes nothing. Amended
2026-08-25: that is two of three treatments, not one rule stated twice. A marker block is a
plugin-owned region inside a tenant-owned file, so actions 5 and 6 are tenant class and still get
replacement. The three: a plugin-owned tree is replaced; a tenant-owned file is written on the first run
and reported on after that; a plugin-owned block inside a tenant file is replaced in place, with
everything outside it preserved verbatim.

#	Action	Class	Treatment
1	Copy the Boxes into `.archon/workflows/`	plugin	replace, name-scoped (ADR-0036 D3)
2	Copy the Methods into `.archon/methods/`	plugin	replace, directory-owned (ADR-0036 D1)
3	Write `.archon/unic-dlc.config.yaml`	tenant	first write only; re-run reports
4	Write `docs/agents/issue-tracker.md` and `docs/agents/triage-labels.md` from templates	tenant	first write only; re-run reports
5	Patch the marker-delimited block in the Consumer's `CLAUDE.md`	tenant	block replaced in place
6	Patch a marker-delimited block in the Consumer's formatter ignore file	tenant	block replaced in place

Action 6 is new. .archon/methods/ needs the exclusion because the Method Bundle is full of .md and
pnpm format was rewriting thirteen files.

Amended 2026-08-25 — the block excludes the Boxes too. This passage used to forbid that entry, on the
argument that a Markdown glob cannot reach a .yaml and an entry would claim it can. DXP-DesignSystem
wrote it by hand anyway, with a reason the argument does not answer: the Boxes are hand-copied and must
stay byte-identical to the release they came from, and a format run rewraps their prompt prose with
nothing to show it happened. An extra ignore line costs nothing; a glob that later reaches .yaml costs a
silently forked Box. Evidence and the full grilling record: the 2026-08-25 comment on this ticket.

Action 6 also names no formatter. The rewrite finds every tool this project uses to format or lint,
whatever the language, works out how each excludes paths from that tool's own documentation, and asks the
operator where the mechanism is unclear. Where that mechanism cannot hold a comment marker — a JSON or
TOML exclude array — /setup installs everything, prints the exact entry the operator must add, and
reports it in the summary as an open hole.

Two things this ticket does not own. Bundling the Methods is settled — it stays, decided on #402,
because /setup copies out of the plugin and can only copy what the plugin ships. And install
provenance beyond what ADR-0036 D3 already requires — the Archon-version line, the Methods record, and
a --check mode — belongs to #408. Keep
stamping the header ADR-0036 D3 asks for; do not invent the rest of it here.

Acceptance criteria

setup.md is rewritten as prose and imports no plugin module.
It states the six actions above and stays idempotent by the rule that matches each class: a
re-run replaces a plugin-owned artefact, and for a tenant-owned one it reports and changes
nothing.
The CLAUDE.md marker-block rules survive — the block is replaced in place, markers included,
and everything outside it is preserved verbatim. The formatter-ignore block follows the same
rules and carries an exclusion for both .archon/methods/ and .archon/workflows/, plus one
name-based rule covering generated artefacts. It creates the ignore file when the Consumer has
none.
/setup writes the two contract files a Consumer needs — docs/agents/issue-tracker.md and
docs/agents/triage-labels.md. Write the tracker contract files in DXP-DesignSystem #388 wrote them by hand for DXP-DesignSystem; that pair is the
worked example of the output, and Move the DLC's tracker contract from config into the repo docs #389 makes the Boxes read them.
setup.md states how it locates the plugin's own installed directory, given that
$CLAUDE_PLUGIN_ROOT is not set inside the Bash tool, and it stops rather than guessing.
ADR-0036's 2026-08-20 amendment assigns this mechanism here, and Give /setup install provenance and a --check mode #408 cannot start without it.
A run against a scratch Consumer clone installs a working set, proven by archon workflow list.
The rewrite asks for none of the keys Move the DLC's tracker contract from config into the repo docs #389 deletes, and writes none of them: the whole tracker
block, classification.labels and project.pr_strategy. Today setup.md collects all three —
including the seventeen-role question — and Move the DLC's tracker contract from config into the repo docs #389 deliberately leaves this file alone. The grounds
Move the DLC's tracker contract from config into the repo docs #389 gave were that this command is retired; that turned out to be wrong, which makes the
exception more fragile, not less: the command will run again. This is the one criterion that
must not be dropped when the rest are re-scoped.
```
**Amended 2026-08-25:** the seventeen roles moved, they did not disappear. They are collected once
and written to `docs/agents/triage-labels.md` — never to the config. Read against criterion 4 alone,
this criterion otherwise produces a tracker doc with no vocabulary.
```
The rewrite declares no closed list of tool names for docs.type or design.type. Lines 109–110 of
today's file are where What does a component design contract contain, and what does /specs write? #404 AC 5 is unmet, and this rewrite is where it is met. Whether a config enum
should enumerate tools at all is parked on wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373's Not-yet-specified and is not decided here.
setup.md no longer carries the legacy .archon/unic-dlc.config.json migration. A legacy file found
is reported, and the run stops.

Open questions — all settled 2026-08-25

Thirteen decisions, with their evidence, are in the grilling record comment on this ticket. The two that
amend the criteria above are the Boxes exclusion and the roles' destination. Two more worth reading before
touching the file: the plugin's own directory comes from ~/.claude/plugins/installed_plugins.json
(installPath, matched on projectPath), never from a glob of the version cache — which holds nine
versions of this plugin today; and the tracker vocabulary is measured on the board and proposed, never
defaulted.

STALE (2026-08-25): superseded by the newest "How to start this session" comment below. Kept for history only.

How to start this session

Produces: commands/setup.md rewritten as prose with no module behind it, and the bundling question
settled.

Run /wayfinder 373 #383. It claims this ticket.
Read the install sequence Install unic-archon-dlc into DXP-DesignSystem by hand, on day 1 #376 recorded. It ran against a real Consumer on Azure DevOps, so it is
evidence rather than a guess.
Invoke /grilling on the open question this ticket must settle: does bundling the Methods stay the
right call now that resolution is one tier, read by path?
Write it with /writing-for-agents.
Prove it against a scratch Consumer clone: archon workflow list shows a working set.

Traps

Idempotency is the hard part. A re-run reports and patches; it never clobbers.
The Consumer's CLAUDE.md block is replaced in place, markers included, and everything outside
the markers is preserved verbatim. Nothing detects a hand-edit between the markers, so the block
never presents itself as a managed document.
Never create, copy or delete a LICENSE file.
Record the bundling outcome in the relevant ADR, which Prune the ADRs aggressively #384 then keeps consistent.

Two things the Consumer install proved that this rewrite has to carry

Both found while installing the DLC by hand into DXP-DesignSystem (#376, #388) and running a Box
against a live Azure DevOps pull request on 2026-08-18.

1. A Consumer's formatter silently forks the Method Bundle

DXP-DesignSystem runs prettier --write "**/*.{ts,tsx,md}". Nothing excluded .archon/methods/,
so one pnpm format rewrote thirteen Method files. They are upstream text pinned to one
mattpocock/skills version, so the fork is invisible until the next update conflicts against the
Consumer's own whitespace.

Any Consumer whose formatter globs Markdown has this, and the DLC installs the Bundle without saying
so. Whatever this rewrite produces as install guidance must tell the operator to exclude
.archon/methods/ from every formatter, and say why. The Consumer's fix is one entry in .prettierignore.

2. The install record belongs in the Consumer, not only in a ticket

#376 recorded the install sequence as a comment on a GitHub issue. The Consumer repository then had
nothing: neither its README.md nor its CLAUDE.md mentioned archon or the DLC, and a developer
cloning it could not repeat the install. #388 fixed that with
docs/agents/unic-archon-dlc.md plus two rows in the README's existing table.

That file is the worked example of what /setup should leave behind. It states what is installed,
what is not — the Claude Code commands are a different Container, so a file copy never reaches
them, which surprised us — and the two Archon defects that land on a Consumer.

One fact for the docs

The MCP server registered in a Consumer's .mcp.json does load inside an Archon worktree, at a
path no human approved. Every Box that says "compose the system-skill the team registered under
tracker.access" depends on this, and nothing had tested it until now.

Two criteria here disagree about how many actions `/setup` has

Found while shipping #389.

It states the same four actions and stays idempotent …

/setup writes the two contract files a Consumer needs — docs/agents/issue-tracker.md and
docs/agents/triage-labels.md.

Writing those two files is a fifth action. So an implementer reading the criteria as a set has to pick
one, and the defensible choice — "four actions, as stated" — drops the criterion this ticket cannot lose.

Worth amending to name five: copy the workflow YAMLs, copy the Methods, write the config, write the
tracker contract, patch the CLAUDE.md marker block.

Why the contract criterion is now load-bearing

#389 merged the tracker contract into those two files and dropped MANDATORY_PATHS to
project.branching alone. Traced through the current setup.md:

:127-129   STATE comes from MISSING
:150       STATE = 'full' + MODE = 'default' → skip Step 5 entirely

A config with branching set now reads full. For the retired keys that is the point — nothing reads
tracker, classification.labels or project.pr_strategy any more. For the contract files it means
nothing creates them, and every Box then prints
BLOCKED: this repository has no tracker contract at docs/agents/issue-tracker.md.

DXP-DesignSystem is unaffected: #388 wrote both files by hand, and decision 14 says never run
/setup there. The hole opens on the next Consumer, which is this ticket's own scope.

Surfaced by a Copilot review on #393 reading
MANDATORY_PATHS and asking what stops collecting. The answer was "nothing was collecting the contract
in the first place".

The install has two halves now, and only one of them is a copy

#390 installed the command Boxes in DXP-DesignSystem through the marketplace entry, so the README's
install section this ticket writes covers two routes, not one:

The Archon Boxes are a file copy into .archon/ — Install unic-archon-dlc into DXP-DesignSystem by hand, on day 1 #376's sequence, unchanged.
The commands are claude plugin marketplace add plus
claude plugin install unic-archon-dlc@unic-agent-plugins --scope project, with
extraKnownMarketplaces and enabledPlugins committed to the Consumer's .claude/settings.json so the
next clone needs neither command. Copying commands/*.md cannot work: Step 1 imports plugin lib/
through $CLAUDE_PLUGIN_ROOT.

Both sequences, with their traps, are in DXP-DesignSystem docs/agents/unic-archon-dlc.md (!5778). Read
that file as the source rather than #376's comment, which covers the Box half alone.

One thing for /setup itself: the marketplace install carries all seven commands, /setup among them, so
a Consumer session offers a command decision 14 retires. A rewritten /setup that refuses to run is the
only place that can say so.

What #381 changed in this file, and the open question it hands you

PR #398 deleted lib/, so commands/setup.md could not keep importing archon-check, config-schema, methods-bundle, methods-manifest, methods-resolver and artefact-install. It got the minimum change that makes it run — not the rewrite this ticket owns. The conversation flow, the questions and the step structure are untouched.

Four blocks became prose:

Step 1 runs archon --version and compares it against the 0.7.0 floor stated in the file.
Step 2 reads the config (.yaml, else the legacy .json for migration), runs git remote with its three refusals in the same order, reads Archon's own .archon/config.yaml verify-only, and infers the repo layout. STATE still resolves to fresh / partial / full, now keyed on project.branching alone.
Step 5 merges defaults → disk → answers deeply and writes the YAML. Both refusals survive: an unreadable config stops the step rather than being clobbered, and a legacy .json is left exactly where it is.
Step 6 states the install rules in prose — bundle integrity by reading, .archon/methods/ clean-replaced, unic-dlc-*.yaml name-scoped with the stale sweep, the generated header read for PREVIOUS_VERSION. ADR-0036 is amended to say those decisions stand while the module that held them does not.

Also: allowed-tools was ['Bash'], which would have blocked every read the new prose needs. It now carries Read, Write, Edit, Glob.

Your open question moved. This ticket asks whether bundling the Methods stays the right call now resolution is one tier. Resolution is now one path — .archon/methods/<name>/SKILL.md, both override tiers retired (ADR-0031, amended) — and the manifest that recorded the bundle's pin is deleted. So the bundling case now rests on vendor/mattpocock-skills/README.md alone, and the pinned licence hash and upstreamPath closure check are gone with no replacement. Decide bundling knowing the pin is prose.

And a new one, which #381 did not decide and this ticket should. Step 6 copies files out of the Plugin's own installed directory, so it is the one step that needs to know where that is — and $CLAUDE_PLUGIN_ROOT is not set inside the Bash tool. The stopgap I wrote finds the directory (observed layout: ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/, one directory per installed version), confirms the path with the operator, and stops rather than guessing. That is a stopgap, not a mechanism: it hardcodes an internal Claude Code layout into a shipped command, and an install that copies from the wrong version is worse than no install. Settle it here.

The #389 criterion this ticket must not drop is unaffected: nothing in the minimum change asks for or writes the tracker block, classification.labels or project.pr_strategy.

Two inputs from #381's grilling (2026-08-20), routed here

A stopgap inside this ticket's scope now exists. The rewritten /setup Step 6 must copy the Method Bundle out of the plugin's own directory, and $CLAUDE_PLUGIN_ROOT is unreliable (ADR-0023 §5). Delete lib/ and test/ — take the plugin to zero code #381 shipped interim prose: find the directory at ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ (observed layout, version-scoped, verified on one machine), confirm it with the operator, stop rather than guess. That is a stopgap, not a decision — this ticket owns the real answer.
The bundling question's ground moved. Delete lib/ and test/ — take the plugin to zero code #381 deleted lib/methods-manifest.mjs, so the pin now rests on vendor/mattpocock-skills/README.md alone (repo, tag v1.1.0, commit). The licence sha256 and the upstreamPath closure check are gone with no replacement; the root AGENTS.md quality-bar passage names the manual check that replaces them (diff the vendored tree against the new upstream tag in the commit that moves the pin). Whether bundling stays right is still this ticket's open question — decide it against that thinner ground.

The 0.23.0 state of setup.md, for whoever takes this ticket

#398 gave setup.md the minimum change to run (prose Step 1, verify-by-reading Step 6, corrected allowed-tools). It did not change what the command asks for. At tag unic-archon-dlc@0.23.0, Step 4 still collects as mandatory: tracker.type + tracker.coords (line 108), all seventeen classification.labels entries (lines 111–121), project.pr_strategy (line 107) — the keys #389 deleted from the config design. Step 7 still stamps a CLAUDE.md block naming classification.labels and /setup reconfigure (line 241).

So the retirement holds: running /setup in a Consumer today writes tracker facts into a config designed to hold none. Caught 2026-08-20 when the orchestrator wrongly dispatched a /setup run as the Box-refresh step; the worker held and cited this ticket's own criterion ("That exception is only safe if this ticket honours it").

The general lesson, from the same day's allowed-tools finding one level up: a criterion about what a command no longer imports says nothing about what it still does. This rewrite's criteria should say what /setup asks for and writes, not only what it no longer reads.

A finding for the rewrite, and a dependency you now have

Both came out of grilling the Consumer-update problem with the maintainer on 2026-08-20, while reviewing the 0.23.0 port (DXP-DesignSystem !5782).

`/setup` should detect the Consumer's toolchain, not know about Prettier

The unic-dlc-pr-review Box found that pnpm format in DXP-DesignSystem had once forked the Method Bundle, and that .archon/methods/ sits in .prettierignore because of it. So a Consumer-side formatter can fight anything /setup installs, and today the fix is a line a human remembered to add.

The maintainer's answer is a rule this ticket should implement, in his words:

No code, prose: agents are more than capable to scan the project and see if they use prettier, eslint, biome or any other from any other technology that we don't need to know in advance (the WHAT, not the HOW).

That is ADR-0016's doctrine applied to a surface nobody had applied it to. /setup should read the Consumer for whatever formats or lints it, and exclude what it installs from that tool — never name Prettier, never name a config filename it expects to find. The plugin knowing the word .prettierignore is the same defect as a Box carrying a host CLI flag.

Worth stating in the rewrite as its own step, because the failure it prevents is silent: a formatter that reflows an installed Method or Box does not error, it just makes the file stop matching the release it was copied from — and after #381 that byte-identity is the only provenance a Consumer has.

One measured detail so the step is written against reality rather than a guess: in DXP-DesignSystem the glob is **/*.{ts,tsx,md}. That is why .archon/methods/ needed the exclusion — the Bundle is full of .md — and why the four Box YAMLs did not, since a .yaml is never matched. So the step is "find what the tool actually reaches", not "exclude everything we install".

This ticket now waits on #402

#402 reopens decision 14, because the maintainer's answers in that same grilling all assume /setup is needed rather than retired — generating the config, generating docs/agents/issue-tracker.md and docs/agents/triage-labels.md from templates, and detecting the toolchain above.

If decision 14 reverses, this ticket's framing changes materially. "Rewrite as prose with no module behind it" and its four actions — copy workflows, copy Methods, write a config, patch the CLAUDE.md block — describe the small version. The large version also generates the tracker contract, reads the Consumer's toolchain, and owns what a re-run does after an upgrade. Do not start this rewrite until #402 lands, or it gets written twice.

Your own open question moves with it too: whether bundling the Methods stays the right call is a different question when /setup is the thing that keeps a Consumer current, versus when it is a retired command nobody runs.

From #396's verification run (#396, PR #410): commands/setup.md names worktree.remote at three lines. Left untouched there — this rewrite replaces the file anyway. What the rewrite needs to know: on Archon 0.7.0 the key IS read, and it governs base-branch resolution ONLY — the workspace path still derives from origin, so it is not a fix for the shared _git/ directory defect. Measured by behavioural probe, matrix on #396.

From #404: the formatter ignore block must cover the design contract glob

#404 decided that /specs writes a component design contract — a generated Markdown file inside the
Consumer's tree, at a path the Consumer's design-conventions doc declares (DXP-DesignSystem:
packages/ui-react/src/<figma-name>/contract.generated.md).

The Consumer formats it. pnpm format in DXP-DesignSystem is prettier --write "**/*.{ts,tsx,md}" —
every .md at any depth, so no location escapes it. Prettier repads a whole Markdown table on any change
inside it, so an unprotected contract is rewritten by every pnpm format and rewritten back by every
/specs run: churn on every run, and a diff that reads as "the design changed" when nothing did.

What #404 handled, so this ticket does not have to. Two layers need nothing from /setup: the file
name carries .generated., which lands inside DXP-DesignSystem's existing *.generated.* ignore rule;
and the contract uses lists and no tables anywhere, so Prettier is close to a no-op on it even unignored.

What is owed here. The durable fix is the marker-delimited block this ticket owns in the Consumer's
formatter ignore file: it should cover the contract glob the design-conventions doc declares, so a future
Consumer with no *.generated.* convention is protected without anyone remembering. /specs warns when
it finds no covering rule — that is #416's work — but a warning is the pattern that already failed here:
#402 rejected report-and-refuse on the evidence
that pnpm format rewrote thirteen Methods before anyone noticed.

One question this raises for the rewrite. The contract path is declared by the Consumer's
design-conventions doc, and /setup may run before that doc exists. Decide whether /setup reads the
doc for the glob, or whether the Consumer maintains that line itself outside the marker block —
/setup preserves everything outside its markers verbatim, so the second option costs nothing and is
the lazier answer. Either way it is a decision, not a detail: leaving it unstated is exactly the gap an
implementer fills silently.

How to start this session (2026-08-25 — supersedes the 2026-08-14 opener, which is stale)

This is the newest opener and the only current one. The ticket is a grilling first: the maintainer is in the room. Grill the open questions, then decide with him whether the rewrite happens in this session or dispatches AFK after — the criteria below govern either way.

What it produces

The three open questions decided, then commands/setup.md rewritten from scratch as prose — six actions, two ownership treatments, no module — proven by a run against a scratch Consumer clone (archon workflow list is the bar). Invoke /grilling for the questions and /writing-for-agents for the rewrite. Do not invoke /implement (routes to /tdd; this plugin ships no code and no tests by decision, #381). /setup-matt-pocock-skills must never run.

Read order

This ticket's body — re-scoped 2026-08-24 by Reopen decision 14: is /setup retired, or is it the Consumer's installer? #402; it is authoritative. The six-action table and the one ownership rule (replace what the plugin owns; refuse what the tenant owns) are settled — do not re-grill them.
The ticket's comments, newest first — they are inputs, not history: 2026-08-25 (the design-contract glob joins action 6's ignore block), 2026-08-23 (worktree.remote is read on Archon 0.7.0, base-branch resolution only), 2026-08-20 ×3 (toolchain detection over Prettier-knowledge; the 0.23.0 state of what Step 4 still collects; the ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ stopgap for locating the plugin), 2026-08-19 ×3, 2026-08-18 (the formatter silently forked the Method Bundle — action 6's origin). The 2026-08-14 opener is stale; ignore it.
apps/claude-code/unic-archon-dlc/docs/adr/0036-setup-owns-a-named-install-set.md — D1/D3 and the 2026-08-20 amendment this ticket implements.
The Consumer's docs/agents/unic-archon-dlc.md via git show origin/develop:docs/agents/unic-archon-dlc.md — the two install routes and the "/setup must not run here yet" passage this ticket makes false.
docs/agents/issue-tracker.md + triage-labels.md in DXP-DesignSystem — the worked example of action 4's output (Write the tracker contract files in DXP-DesignSystem #388 wrote them by hand).

The one trap that costs an hour

Scope bleed into #408. Provenance is split by ADR: this ticket stamps the Generated header ADR-0036 D3 already requires, and nothing more — the Archon-version line, the Methods INSTALLED.md, and the whole --check mode belong to #408, which is blocked on this ticket and starts from what you ship. The temptation is real because #408's criteria are already written; inventing half of them here makes both tickets wrong. Same family: Method bundling is settled (#402) — do not re-open it.

The decisions the ticket does not make — the grilling's agenda

Where the tracker-doc templates live: files in the plugin, or prose inside setup.md. The Write the tracker contract files in DXP-DesignSystem #388 pair is the worked example either way; the two answers rot differently — grill on which rot is cheaper to catch.
Which formatters action 6 detects. Prettier is the only measured case. The 2026-08-20 comment reframes it: detect the Consumer's toolchain rather than know about Prettier — decide what "detect" means when the toolchain is none of the measured ones (stop and ask beats guess).
The ignore-block ownership question from What does a component design contract contain, and what does /specs write? #404 (recorded on this ticket 2026-08-25): does /setup read the Consumer's design-conventions doc for the contract glob, or does the Consumer keep that line outside the marker block? A reader needs a writer — whichever half owns the line must be named as its writer.

Other traps

Criterion 7 is the one that must not be dropped: the rewrite asks for and writes none of the Move the DLC's tracker contract from config into the repo docs #389-deleted keys (tracker.*, seventeen classification.labels, project.pr_strategy). Today's setup.md still collects all three as mandatory. Verify by grepping the rewritten file for each key, not by reading the diff.
Action 6's asymmetry is deliberate: .archon/methods/ gets an exclusion, the Boxes do not (a Markdown glob cannot reach .yaml, and an entry would claim it can). Reproduce it; do not tidy it.
The marker-block rules (CLAUDE.md and the formatter-ignore block): replace the block in place, markers included, preserve everything outside verbatim, no AUTO-GENERATED banner.
Locating the plugin's own directory: $CLAUDE_PLUGIN_ROOT is unset in the Bash tool; the cache path is an observed layout, version-fragile — the command states how it locates the directory and stops rather than guesses.
Read the criteria as one set before the rewrite: this ticket has already had two criteria disagree once (four vs five actions, caught 2026-08-19).
Read the Consumer on origin/develop only.

The bar that proves it

Criterion 6 — a run against a scratch Consumer clone installs a working set, proven by archon workflow list. This is the one able-to-act criterion; the rest are readable. False passes to refuse: prose that reads correctly but was never executed; a scratch run that skips the marketplace half (the commands install via the marketplace entry — a bare file copy of commands/*.md cannot work and is the defect #390 measured); "criterion 7 holds" asserted from the diff instead of a grep of the final file.

On landing

Bump minor (0.x: the installer's behaviour changes; nothing here is the 1.0 release), changelog entry with the — YYYY-MM-DD header format.
Pipeline as standard: draft PR → /code-review (merge-base with develop, Spec axis gets this ticket) → one summary comment with the "what both axes agreed on" section → gh pr ready only on green checks by exit code. When a review finding is fixed, reply with the fixing commit and resolve the thread in the same pass.
Name this command's own ADRs among the repointed surfaces: ADR-0036 (implemented — amend per the plugin's dated-blockquote convention), ADR-0019, and any ADR the deleted installer's behaviour is still described by.
The Consumer's docs/agents/unic-archon-dlc.md "must not run yet" passage becomes false when this merges — flag it for the next Consumer PR (do not open one just for it), and tell Give /setup install provenance and a --check mode #408 it is unblocked.
On close: move the state label to resolved.

Before you finish, and whenever you learn something that would have changed this prompt

SendMessage to wayfinder-orchestrator with four things and nothing else:

what you expected
what happened
the command, file, or answer that proved it
whether it changes only this ticket, or other tickets and sessions

Send it when you learn it, not only at the end.

The grilling record — thirteen decisions, 2026-08-25

Worked with the maintainer in session wayfinder-383. Three rounds. Every recommendation below was put
to him and agreed; the evidence line is what the decision was checked against, not what suggested it.

Two of these contradict a criterion the body calls settled, so the body is amended in the same pass.

The three questions the ticket owned

1 — Tracker-doc templates: prose in setup.md, no template files. The #388 pair is roughly nine
parts tenant fact to one part shape: the Consumer's area path, the
organisation/project/repository table, the MCP server's name, and label counts measured on dxp
project-wide. A template file would be mostly placeholder, and it adds a fifth artefact class the
four-class ownership rule does not cover — plugin-owned input that is never copied verbatim. The rewrite
names the required sections, carries the seventeen role names, and links the #388 pair as the worked
example.

2 — Detect the toolchain; name no tool. The prose says: find every tool this project uses to format
or lint, whatever the language; work out how each one excludes paths from that tool's own documentation;
ask the operator where the mechanism is unclear. No tool name, no config filename, no list to fall
behind. The maintainer's framing: JS is two formatters, and C#, Python and PHP are more — the plugin
cannot hold the list, and an agent can read the project.

3 — The generated-artefact rule is name-based. #404's contract sits at a path the Consumer's
design-conventions doc declares, and /setup may run before that doc exists. So the block carries one
name-based rule for generated artefacts rather than a path read out of a Consumer document. #404 already
decided the filename carries .generated.; DXP-DesignSystem has such a rule already.

The two amendments

4 — The ignore block excludes the Boxes too. Criterion 3 forbade it, on the argument that a Markdown
glob cannot reach a .yaml and an entry would claim it can. DXP-DesignSystem wrote that entry anyway,
by hand, with a reason the ticket does not answer:

# Hand-copied Boxes — the same constraint. docs/agents/unic-archon-dlc.md records the
# release or commit each one was copied from, and the copy has to stay byte-identical to it.
# A format run rewraps the prompt prose and breaks that with nothing to show it happened.
.archon/workflows/

Evidence: git show origin/develop:.prettierignore in DXP-DesignSystem. An extra ignore line costs
nothing; a glob that grows to reach .yaml costs a silently forked Box. The asymmetry argument is
aesthetic, and the one operator who met the problem voted against it in prose.

5 — The seventeen roles did not disappear; they moved. Criterion 7 forbids writing
classification.labels, and action 4 writes docs/agents/triage-labels.md, whose whole content is
the role mapping. Read alone, each criterion produces a different wrong file: one drops the role
conversation and writes a tracker doc with no vocabulary, the other writes the labels back into the
config. Stated once, in the rewrite and in the criteria: the roles are collected once and written to
docs/agents/triage-labels.md, never to the config.

And the body's "one rule stated twice" is three. Actions 5 and 6 are both tenant class and both get
replacement, because a marker block is a plugin-owned region inside a tenant-owned file. Three
treatments: a plugin-owned tree is replaced; a tenant-owned file is written on first run and reported on
after that; a plugin-owned block inside a tenant file is replaced in place with everything outside it
verbatim.

What the environment settled

6 — No closed tool list. docs.type and design.type are asked open and written through. Takes
#417's README wording. commands/setup.md
lines 109–110 are where the closed lists live today, so this file is where #404 AC 5 is met. Whether a
config enum should enumerate tools at all is parked on #373's Not yet specified and is not decided
here.

7 — The plugin's own directory comes from the registry, never from a glob. Claude Code keeps
~/.claude/plugins/installed_plugins.json, and for this plugin it records:

"unic-archon-dlc@unic-agent-plugins": [{
   scope: "project",
   projectPath: "/Users/…/Sites/<customer>/DXP-DesignSystem",
   installPath: "…/cache/unic-agent-plugins/unic-archon-dlc/0.24.1",
   version: "0.24.1", gitCommitSha: "147465e…" }]

installPath is the answer, and projectPath matches a project-scope install to the Consumer's own
repository root — which a glob cannot do. The stopgap globbed
~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/; that directory currently holds nine
versions of this plugin and one is installed. So the glob had nine candidates and picked by luck.

/setup reads the entry, takes installPath, then verifies before copying: .claude-plugin/plugin.json
names unic-archon-dlc at the entry's version, vendor/mattpocock-skills/ is present, and
.archon/workflows/ holds at least one unic-dlc-*.yaml. It stops, printing what it found, on a missing
entry, a registry version other than 2, a failed check, or a version that disagrees with the running
copy. No operator prompt on the happy path — the confirmation existed to cover a guess, and this is not
one.

8 — No ignore file yet: create it. Marker block only, first write. The ignore file is tenant-owned,
so creating it is the same act as writing the config on a fresh Consumer. Print-and-remind is the pattern
that forked thirteen Methods.

9 — Measure the tracker's vocabulary; offer no defaults. Today's Step 4 shows a default label string
per role and forbids probing the tracker outright. The #388 pair was built the other way — measured on
dxp, Specification 186 uses, TriageNeeded 34, readyForImplementation 13 — and that counting is
why the mapping adopted names the board already carried. So: probe through the composed MCP or CLI,
propose a mapping, confirm, and drop the default column. Three rules from today's prose survive: the role
names on the left are the plugin's and never the tenant's; nothing creates a label on the tracker; a role
the board has no name for is mapped onto a name that exists, never onto an invented one. No tracker access
yet → write the file with the roles, leave the value column empty, and say a Box will refuse until a human
fills it.

10 — The Axis/Holds contract is README.md's. § The tracker contract already carries it, with the
"a row with no axis writes nothing" rule and a worked table. The rewrite points at it and restates
nothing.

11 — An exclusion mechanism that cannot hold a marker block. A line-based ignore file takes comment
markers; a JSON or TOML exclude array does not. /setup installs everything, prints the exact entry the
operator must add, and reports it in the summary as an open hole — named in the terms that make it real,
an installed file that stops matching the release it came from with no error and no diff. Stopping the run
instead would refuse to install into most Consumers outside JS; editing the config anyway leaves a line
the next run cannot tell from a hand-written one.

12 — reconfigure survives, with a job. It is the one explicit override that rewrites a tenant-owned
file: show what would change, ask once per file, write only what is confirmed. Without it a bad first run
is correctable only by deleting a file.

13 — The legacy .json migration is deleted. No Consumer is on that shape — DXP-DesignSystem was
configured by hand onto the YAML — so it is a path nothing has ever walked, and a from-scratch rewrite is
where such a path gets deleted rather than copied. A legacy file found: report it and stop. Ignoring it
would read the project as fresh and write a second config beside the first.

Decided in the same session: the rewrite happens in this session, not AFK

The proving criterion is a run against a scratch Consumer clone, which cannot be asserted from a diff and
is the criterion an AFK worker has historically faked.

fix(unic-archon-dlc): the review findings both axes raised on the rew…

Resolution — the rewrite is up as #420, eight checks green

The thirteen decisions are in the grilling record
and the criteria above were amended to match before the branch existed. What the implementation added to
them:

The scratch-Consumer run found a defect no read could. The Method Bundle groups by category, so a
Method sits at vendor/mattpocock-skills/skills/<category>/<name>/. My prose said "copy the bundle into
.archon/methods/", and a literal copy lands .archon/methods/skills/engineering/tdd/SKILL.md — while
every Box reads .archon/methods/<name>/SKILL.md. The install would have reported success and left every
Box unable to find every Method. Fixed in df030bb; the copy now flattens, and stops on two Methods
sharing a name across categories. This is the clearest vindication yet of the run-in-a-Consumer bar: a
criterion-by-criterion read passes this prose.

Two more things the run established, both by measurement:

A real prettier --write "**/*.{ts,tsx,md}" in the scratch clone left both installed trees
byte-identical with the block in place, and rewrote 11 Method files with the block removed. The
failure the sixth action exists for reproduces on demand.
The generated header does not break Archon's discovery: archon workflow list returns all four Boxes
with the comment line prepended.

/code-review then found nine Standards defects and two Spec defects, all fixed in 9ed4e01 — the
summary is on the PR. Two
are worth carrying off this ticket:

Both axes independently found the same rot: reordering the run left seven cross-references pointing
at "Step 6" for what is now Step 5, across README.md, CONTEXT.md and three ADRs. A step number
restated outside the file that numbers it is a mirror. The fix removes the class — a cross-reference now
names the step by what it does.
An unexecutable stop condition survived my own read: "stop on a version that disagrees with the copy
of this file you are running from", where the command file carries no version. The lesson generalises: a
refusal is only as good as the value it can compare, and prose hides a missing value the way code does
not.

One criterion is knowingly partial, and stays so. The scratch-clone run exercised the registry lookup
against a fake plugin root rather than the machine's real installed_plugins.json: writing a project-scope
entry into a file another session and the running app both write is not worth the risk. The real file's
shape is quoted in the grilling record.

One decision the implementation corrected. Decision 1 asked the rewrite to carry the seventeen role
names and link the #388 pair. It does neither, on purpose: README.md § The tracker contract already lists
all seventeen and restating them is the defect the one-source rule exists to stop, and DXP-DesignSystem is
a private client repository — a link most readers cannot open is worse than no link. The decision record
overstated what the prose should carry.

What this unblocks, and what it makes false

#408 is unblocked and starts from what
#420 ships: the Generated header is one comment line on each installed Box, written by the install step
and read back as a prefix of the first line. The Archon-version line, the Methods record and the whole
--check mode are still that ticket's, untouched here.
The Consumer's docs/agents/unic-archon-dlc.md says /setup must not run there yet. That becomes
false when #420 merges. Flagged for the next DXP-DesignSystem PR rather than a PR of its own.
#422 carries the same locate defect in
/archon-upgrade, which reads its bundled YAMLs through $CLAUDE_PLUGIN_ROOT (ADR-0035:91) and should
read the registry instead.

Closing waits on the merge — the ticket is answered, but nothing is on develop yet.

fix(unic-archon-dlc): the MEDIUM and LOW findings, and the four run g…

Rewrite commands/setup.md from scratch as prose #383

Description

Question

The six actions, and the one rule that governs all of them

Acceptance criteria

Open questions — all settled 2026-08-25

Activity

orioltf commented on Aug 14, 2026

How to start this session

orioltf commented on Aug 18, 2026

Two things the Consumer install proved that this rewrite has to carry

1. A Consumer's formatter silently forks the Method Bundle

2. The install record belongs in the Consumer, not only in a ticket

One fact for the docs

orioltf commented on Aug 19, 2026

Two criteria here disagree about how many actions /setup has

Why the contract criterion is now load-bearing

orioltf commented on Aug 19, 2026

The install has two halves now, and only one of them is a copy

orioltf commented on Aug 19, 2026

What #381 changed in this file, and the open question it hands you

orioltf commented on Aug 19, 2026

Two inputs from #381's grilling (2026-08-20), routed here

orioltf commented on Aug 20, 2026

The 0.23.0 state of setup.md, for whoever takes this ticket

orioltf commented on Aug 20, 2026

A finding for the rewrite, and a dependency you now have

/setup should detect the Consumer's toolchain, not know about Prettier

This ticket now waits on #402

orioltf commented on Aug 23, 2026

orioltf commented on Aug 25, 2026

From #404: the formatter ignore block must cover the design contract glob

orioltf commented on Aug 25, 2026

How to start this session (2026-08-25 — supersedes the 2026-08-14 opener, which is stale)

What it produces

Read order

The one trap that costs an hour

The decisions the ticket does not make — the grilling's agenda

Other traps

The bar that proves it

On landing

Before you finish, and whenever you learn something that would have changed this prompt

orioltf commented on Aug 25, 2026

The grilling record — thirteen decisions, 2026-08-25

The three questions the ticket owned

The two amendments

What the environment settled

Decided in the same session: the rewrite happens in this session, not AFK

orioltf commented on Aug 25, 2026

Resolution — the rewrite is up as #420, eight checks green

What this unblocks, and what it makes false

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Two criteria here disagree about how many actions `/setup` has

`/setup` should detect the Consumer's toolchain, not know about Prettier