Install the DLC's command Boxes in DXP-DesignSystem #390

Activity

1. orioltf

   added

   app:unic-archon-dlc

   p0Critical priorityCritical priority

   wayfinder:taskWayfinder ticket: do the thingWayfinder ticket: do the thing

   on Aug 18, 2026
2. orioltf

   added a parent issue on Aug 18, 2026

   • wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373
3. orioltf

   marked this as blocking on Aug 18, 2026

   • Land a rendering component on develop, so the client sees the walk's output #379
4. orioltf commented on Aug 18, 2026

   

   orioltf

   on Aug 18, 2026

   MemberAuthor

   More actions

   Finding from #389: a hand-copied install has no freshness signal, and this ticket doubles the count

   #389 moved the DLC's tracker contract out of .archon/unic-dlc.config.yaml. Before deleting those
   keys from the Consumer I checked what its installed Boxes actually read, and found this:

   .archon/workflows/unic-dlc-build.yaml       clean copy of the pre-#389 plugin
   .archon/workflows/unic-dlc-explore.yaml     clean copy of the pre-#389 plugin
   .archon/workflows/unic-dlc-pr-review.yaml   clean copy of the pre-#389 plugin
   .archon/workflows/unic-dlc-qa.yaml          clean copy of the pre-#389 plugin
   

   Nothing local had been edited, so nothing was lost — but stripping the config keys alone would have
   left four Boxes reading a file that no longer answers them. #389 re-copied all four and re-checked
   archon workflow list: errorCount: 0.

   The install has no version marker. .archon/ holds workflows/, methods/ and the config, and
   nothing records which plugin version any of it came from. So nothing detects that a copy is stale. I
   caught this by grepping the Consumer for the keys I was about to delete, which is not a procedure
   anybody would run twice.

   What that means for this ticket

   #389 changed all three command Boxes this ticket installs. Measured against develop:

   commands/triage.md    109 lines changed
   commands/tickets.md   115 lines changed
   commands/specs.md      55 lines changed
   

   So two things:

   1. Copy the post-#389 versions, and record the commit you copied from. Otherwise this ticket
      installs three more artefacts with no freshness signal, and the next contract change repeats the
      near-miss above on a bigger surface. The install sequence AC-2 asks for is the right home for that
      line.

   2. AC-3 is now satisfiable, and its expected values have changed. /triage reads
      docs/agents/triage-labels.md since #389 — the rule that forbade that read is dead. But the role
      table is not what #388 wrote. Every state role now carries a value, five of the eight are tags,
      and needs-triage is one of them:

      Role	Axis	Holds	Value	On the board today
      needs-triage	Tag	many	TriageNeeded	34 uses
      needs-info	Tag	many	needs-info	new
      needs-specs	Tag	many	Specification	186 uses
      ready-for-agent	Tag	many	readyForImplementation	13 uses
      ready-for-human	Tag	many	needs-human	new

   One thing to expect on the first /triage run

   Writing needs-info or needs-human is the first test of a permission nobody has exercised. Azure
   DevOps creates a tag on first use, but that needs the project-level Create tag definition
   permission — security namespace Tagging, action Create. Contributors hold it by default, and
   Stakeholder access cannot create a tag even where the permission reads Allow.

   So the failure is asymmetric and misleading: whichever identity runs the Box writes Specification and
   TriageNeeded without trouble, then fails only on the two new names. That reads as a bug in the role
   and is a permission on the identity. If it happens, record the identity, not the role.

   Tagging permissions are also collection level, scoped to the project only in the user interface.

   Not affected

   The twelve Methods at .archon/methods/ are vendored upstream text and #389 touched none of them. The
   drift above is the Boxes alone.
5. orioltf

   self-assigned this

   on Aug 19, 2026
6. orioltf commented on Aug 19, 2026

   

   orioltf

   on Aug 19, 2026

   Last edited by orioltf

   MemberAuthor

   More actions

   Resolved: the commands are installed through the marketplace, and every one of them stops at Step 1

   The install route is the marketplace entry, not a file copy. DXP-DesignSystem !5778 carries it
   (work item 42948, branch feature/42948_install-dlc-command-boxes, commit 70b5cb0).

   The decision the body did not make

   Copying commands/*.md into the Consumer cannot work, and rewriting the Step 1 blocks to make it work
   would be thrown away. All three commands import lib/config-schema.mjs and lib/methods-resolver.mjs
   through $CLAUDE_PLUGIN_ROOT, and #381 deletes lib/. So the plugin installs as a plugin:

   claude plugin marketplace add https://github.com/unic/unic-agents-plugins.git
   claude plugin install unic-archon-dlc@unic-agent-plugins --scope project

   Step 2 writes enabledPlugins into the Consumer's tracked .claude/settings.json, and the commit adds
   extraKnownMarketplaces beside it so the next clone needs nothing. The full sequence, both halves of the
   install and the traps, is now in DXP-DesignSystem docs/agents/unic-archon-dlc.md — AC-2.

   The freshness signal exists on both halves now. That file records unic-archon-dlc 0.22.0 at
   marketplace commit 624de9e1a87992246727213eaef5fdf5aa7bf86b, and I verified the four copied Boxes are
   byte-identical to that commit. Nothing in the repository recorded either before. The command half also
   carries a signal outside the repository — Claude Code writes the version and the commit into
   ~/.claude/plugins/installed_plugins.json — and, because nothing is copied, nothing there can go stale
   in the Consumer at all. The Boxes still can.

   AC-1: available, and halted

   Seven commands load in a session on DXP-DesignSystem, /specs, /tickets and /triage among them.
   Measured with claude -p in that repository.

   They name the repository from docs/agents/issue-tracker.md § Addressing — organisation <org>, project
   dxp, repository DXP-DesignSystem. That is the tracker contract answering, not the command's own flow:
   no command reaches its own Step 2.

   AC-3: the role resolved, the command did not resolve it

   ready-for-human → Tag needs-human, written to work item 42948 as oriol.torrent@unic.com. The tag
   did not exist on the board and Azure DevOps created it on first use, so the Create tag definition
   permission holds for this identity with no change. No other state role sat on the item, so nothing was
   retracted; AI Engineering, Frontend and P: DesignSystem map to no role and were left alone.

   I resolved it by reading docs/agents/triage-labels.md. /triage could not, for the two defects
   below. AC-3 as written is not met.

   AC-4: what the command Boxes assume that this Consumer does not provide

   Two of these are the plugin's and they block every command. Both are measured on 0.22.0, 2026-08-19.

   1. $CLAUDE_PLUGIN_ROOT is not set inside the Bash tool. commands/specs.md Step 1,
      tickets.md Step 1, triage.md Step 1, improve-architecture.md Step 1 and cleanup.md all read
      it from process.env. The guard then stops with "Run this as a /unic-archon-dlc: slash command",
      which is what the operator already did — the message sends them nowhere. The Claude Code binary's own
      strings scope that placeholder to hook and MCP-server configuration, and
      ADR-0023 §5
      already records the variable as unreliable, exempting the Archon nodes alone. The commands were never
      held to the same finding.
   2. The plugin imports the yaml package and an installed plugin ships no node_modules.
      lib/config-schema.mjs:4, lib/methods-bundle.mjs:5 and lib/schema-traps.mjs:3 import bare
      yaml, and package.json declares it as a runtime dependency. That resolves through this
      monorepo's workspace node_modules and nowhere else, so the module cannot load from
      ~/.claude/plugins/cache/… whatever $CLAUDE_PLUGIN_ROOT says. Setting the variable by hand moves
      the failure from the guard to Cannot find package 'yaml'. The root CLAUDE.md bar is zero external
      runtime dependencies in a plugin; this one is invisible in the repository that hosts it and fatal
      everywhere else.
   3. claude plugin install reformats the Consumer's tracked settings file. It expanded every object
      in deniedMcpServers while adding enabledPlugins. Harmless here — pnpm format covers ts,tsx,md
      only — and worth one line in the sequence, which it has.
   4. The install carries /setup, which decision 14 retires. A Consumer session now offers
      /unic-archon-dlc:setup in its command list. Nothing warns the operator, and the plugin cannot
      withhold one command from its own install. Until Rewrite commands/setup.md from scratch as prose #383 rewrites it, the only guard is prose.
   5. The marketplace follows develop. The plugin repository's default branch is develop and the
      entry carries autoUpdate, so the command half tracks unreleased plugin work. That is what the
      port obligation in wayfinder: unic-archon-dlc is prose, and proven at a Consumer #373 wants during this sprint, and it is a hazard after it. Recorded in the
      Consumer doc rather than pinned, because a pin is a second thing to refresh by hand.

   The plugin needs a change, and #381 is it

   Findings 1 and 2 are one fix: a command that reads its own config in prose needs neither the variable nor
   the package. That is #381 — lib/ and test/
   deleted — which now blocks a live Consumer rather than tidying this repository. Noted there.

   Nothing here needs a plugin edit ahead of #381, and nobody should patch Step 1 in place: the fix and the
   deletion are the same edit, and doing it twice is how the last rewrite grew.
7. orioltf commented on Aug 19, 2026

   

   orioltf

   on Aug 19, 2026

   MemberAuthor

   More actions

   Closed. The route is decided, recorded and live in DXP-DesignSystem (!5778, work item 42948). AC-1, AC-2 and AC-4 are met. AC-3 is met in substance and not in form: the state role resolved through docs/agents/triage-labels.md and reached the board, but I resolved it, not /triage, because every command halts at Step 1. That remainder rides on #381, which now blocks #379 as well.
8. orioltf

   closed this as completedon Aug 19, 2026