Repository navigation
Reopen decision 14: is /setup retired, or is it the Consumer's installer? #402
Description
Question
Decision 14 retired /unic-archon-dlc:setup. Re-decide it, because three answers the maintainer gave on 2026-08-20 all assume the opposite, and everything downstream branches on which way this goes.
His words, grilled in-session while reviewing the 0.23.0 Consumer port (!5782 in DXP-DesignSystem):
.archon/unic-dlc.config.yamlshould be generated by/setup, not hand-written.docs/agents/issue-tracker.mdanddocs/agents/triage-labels.mdshould be generated too, from templates, the way Matt's own setup skill does it./setupshould detect the Consumer's formatter and exclude what it installs from it — see the note on Rewrite commands/setup.md from scratch as prose #383.- "I may have taken a wrong decision in decision 14. I think
/setupis needed."
That is not a retired command. It is the only thing that writes tenant-shaped files into a Consumer, which makes it the most load-bearing command in the plugin.
Why this gates rather than merely relates
#383 assumes the small version. Its framing is "rewrite as prose with no module behind it", and its four actions are copy workflows, copy Methods, write a config, patch a CLAUDE.md block. If /setup also generates the tracker contract from templates, detects the Consumer's toolchain, and owns re-runs after an upgrade, that ticket is materially bigger and its own open question — whether bundling the Methods stays right — changes answer with it.
And the Consumer-lifecycle map cannot be charted until this lands. The two branches need different destinations:
/setupstays retired → the effort is "how does a Consumer detect drift it must fix by hand"./setupreturns as the installer → the effort is "what does the Consumer lifecycle own, and how dosetupand an upgrade path divide it".
Charting before this is charting on fog that one session can clear.
What is measured, so this is not re-derived
Established on 2026-08-20 during the 0.23.0 port. Take these as facts:
- Distribution is already solved; installation is not.
autoUpdateon the marketplace entry puts the whole plugin on the machine at~/.claude/plugins/cache/<marketplace>/unic-archon-dlc/<version>/, and that directory carries.archon/workflows/(the four Boxes) andvendor/mattpocock-skills/(the eleven Methods). The bytes arrive. Nothing copies them into the repository. - The "hand-copy half" is two different things. The Boxes and the Methods are verbatim plugin output that should track the release exactly. The config and the two
docs/agents/files are tenant-authored and must never be overwritten. Lumping them is what makes this look structural. - Nothing carries a version marker.
grep -rl "0.2[23].0" .archon/in the Consumer returns nothing.CONTEXT.mdalready defines Generated header as where install provenance lives — and/setupis its only writer, so retiring/setupremoved the mechanism the vocabulary still describes. - A stale Box breaks nothing. Agreed in-session: a Box is self-contained (ADR-0023 §5), so a stale one misses an improvement and does no worse. Both real failures to date — Move the DLC's tracker contract from config into the repo docs #389's wrong parity claim, and the two rotted files this port found — were detection failures, which no updater would have fixed.
- PULL over PUSH, provisionally agreed: something notices drift and says so, rather than an unattended actor copying into a tracked tree. A push needs an actor at update time and can clobber; nobody is present when
autoUpdatefires.
The question this ticket must not dodge
autoUpdate: true is live in DXP-DesignSystem and nobody chose it — it came with the install. The maintainer's objection is the sharpest thing in the grilling and it has no answer yet:
I'm not sure consumers will want
autoUpdate. At an enterprise level, an update from the DLC may require an update from Archon too. What if the new version from the DLC and Archon includes breaking changes for a specific Consumer?
That is a three-way version coupling — plugin × Archon × Consumer — and the vocabulary has no word for it. Today the plugin holds one floor (Archon 0.7.0, now stated in prose since #381) and has no concept of a Consumer declining an upgrade or pinning a known-good set. Whatever /setup becomes, it either owns that or explicitly does not.
Acceptance criteria
- Decision 14 is either reaffirmed or reversed on wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373, in one passage, with the reason.
- The passage says which artefact classes
/setupowns and which it must never touch, using the four classes above rather than "the non-plugin half". - Whether
autoUpdatestays on for a Consumer is decided, or recorded as an open question with the reason it could not be decided here. - The Generated-header mechanism is either restored to a writer or removed from
CONTEXT.md, so the vocabulary and the code agree. - Rewrite commands/setup.md from scratch as prose #383 is re-scoped to match the outcome, or confirmed unaffected in writing.
- The grilling closes by listing what it did not decide. Every "either is acceptable" becomes an open question or gets decided here.
Activity
orioltf commentedon Aug 23, 2026
How to start this session
Posted 2026-08-23 at dispatch. First opener on this ticket.
Produces: a decision — decision 14 reaffirmed or reversed, recorded on #373
(#373) in one passage, plus the ticket's six
criteria. A conversation with the maintainer, not a publish. Invoke
/grilling, and/domain-modelingwhen the three-way version coupling needs words — it has none today. Do notinvoke
/implement, and do not start rewritingsetup.md— that is #383(#383), which this ticket re-scopes.
Read order
not spend the session re-deriving them. All four moving-part claims re-verified 2026-08-23:
Generated headeratapps/claude-code/unic-archon-dlc/CONTEXT.md:253; the Archon≥ 0.7.0floor in the plugin README;
autoUpdate: truelive in the Consumer's.claude/settings.json;Rewrite commands/setup.md from scratch as prose #383 open.
Consumer-lifecycle item there is what this decision unblocks or reshapes.
origin/develop(nevermain— it is behind):~/Sites/<customer>/DXP-DesignSystem/docs/agents/unic-archon-dlc.md— both install routes and whateach carries today.
The one trap
Dodging the autoUpdate question is a false close. The session can produce a clean
reaffirm-or-reverse passage and still leave
autoUpdate: truerunning at the Consumer with nobody havingchosen it, and the plugin×Archon×Consumer coupling wordless. Criterion 3 accepts "recorded as an
open question with the reason it could not be decided here" — the reason is the deliverable,
not the escape hatch.
The decision the ticket does not make
Where the passage lives. Advice: append it to #373's "Decisions so far" with the date, and edit
decision-table row 14 to a one-line pointer at it — never leave the table saying the opposite of
the passage.
Other traps
2 — "the non-plugin half" is the phrasing this ticket exists to kill.
Generated headerfromCONTEXT.md, that is a one-line plugin PR —DLC repo, draft first (
gh pr create --draft), flip whengh pr checksis green by exit code.If it restores a writer, the edit belongs to Rewrite commands/setup.md from scratch as prose #383's re-scope instead; do not ship it here.
charting on fog.
overturn.
The bar that proves it
Criterion 6: the grilling closes by listing what it did not decide. A false pass reads well and
hides an "either is acceptable" — every one of those becomes a named open question or gets decided
in-session. Second false pass: #383 untouched at the end; it gets re-scoped or "confirmed
unaffected" in writing on its ticket, never by silence.
On landing
CONTEXT.mdchanged: the plugin PR per the pipeline; no version bump decision withoutreading
plugin.jsonfirst (0.x rules).whether the Consumer-lifecycle work exists as one effort or two.
Report back
BEFORE YOU FINISH, AND WHENEVER YOU LEARN SOMETHING THAT WOULD HAVE CHANGED THIS PROMPT,
SendMessagetowayfinder-orchestratorwith four things and nothing else: what you expected,what happened, the command or file that proved it, and whether it changes only this ticket or
every session in this repo. Send it when you learn it, not only at the end.
orioltf commentedon Aug 23, 2026
Closed — decision 14 stands, and it was never a retirement
The decision passage is on #373, appended to
"Decisions so far". The line that claimed the retirement is rewritten in place, in the same body.
The premise was wrong, and that is the finding. Row 14 says
/setupbecomes prose with no module,rewritten from scratch. Decision 6 keeps
setupinside the 1.0 box set. Neither retires anything. Theword entered at one line of #373's Plugin → Consumer passage, citing decision 14 for something it does
not say, and spread from there to #389's
grounds for deleting config keys and to the Consumer doc. So there was nothing to reverse — there was a
sentence to kill and a scope to decide.
What was decided
/setupis the Consumer's installer. Row 14 unchangedautoUpdaterefpinning rejected.archon/methods/INSTALLED.md, not eleven stampedSKILL.mdfiles/setup --check— PULL stands, re-examined not inheritedCLAUDE.mdruleOne measured fact worth carrying forward.
autoUpdate: truedid not track everydevelopcommit.plugin.jsondeclares aversion, and a declared version pins the plugin, so Claude Code skipped theupdate while that string was unchanged — it carried a version bump. Under this repo's release flow a
bump merges to
developbefore the release PR tomain, so a Consumer received it at merge rather thanat tag.
autoUpdate's exact firing moment is not documented on the marketplaces page — unverified.Where the work went
six, under the one ownership rule. Its own open question — whether bundling the Methods stays right —
is answered above, so it no longer carries it. Two new open questions replace it.
--check,blocked by Rewrite commands/setup.md from scratch as prose #383, sub-issue of wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373. It carries ADR-0036's fourth amendment.
DXP-DesignSystem!5787 (draft, work item 42955):autoUpdate: false, and the doc's "retired andnever runs" corrected to unfinished-work.
What this grilling did not decide
/setupdetects. Prettier is the only measured case. Biome and dprint areunmeasured, and this repository itself runs both Biome and Prettier. On Rewrite commands/setup.md from scratch as prose #383.
setup.md. The twoanswers rot differently. On Rewrite commands/setup.md from scratch as prose #383.
--checkreport shape. Whole-file comparison, header-line comparison and a line diff arethree different answers, and an implementer will pick one and defend it. On Give /setup install provenance and a --check mode #408.
--check. The cure for "a hand-carried artefact nobody checks" is still acommand a human must remember. Naming the moment, as the root
AGENTS.mddoes for a vendored Bundleupgrade, is the cheapest honest answer and is not decided. On Give /setup install provenance and a --check mode #408.
--checkbelongs on/setupor on/archon-upgrade, which already reads versions andre-asserts the ADR-0011 schema traps by reading. The overlap is real. On Give /setup install provenance and a --check mode #408.
DXP-ProfileServicesandDXP-WebsitegetautoUpdate: falsewhen they install. Thesame default is assumed and was not decided; wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373's "Not yet specified" already holds those installs.
Nothing above is an "either is acceptable" — each one names the ticket that must settle it before
dispatch.