Practice Packs must stack: /setup replaces .archon/methods/ wholesale, and the override tier was deleted

Read commands/setup.md around lines 205–220, ADR-0031, and the setup and command files containing the literal Method paths. Compare the existing workflow ownership rule with the methods installation behavior, then review issue #425 for the related install-time decision. Done means the ownership, collision, precedence, installer assumptions, ADR status, and matching /setup documentation are recorded and consistent.

What the maintainer asked for

Several independently installable units in one Consumer at the same time: the DLC, an e2e unit, a design-system-integration unit, a .NET development unit, and product logic after those. Working term for such a unit: Practice Pack — a family-level unit carrying both a reference architecture and a procedure. Not Method Bundle, which is the vendored Matt Pocock set pinned to a tag.

Raised in the e2e-suite seat's grilling and routed here, because the decision is about this engine and not about that chain.

Why this is a ticket and not a design note

A Practice Pack is not installable today. commands/setup.md line 205:

Copy clean: replace .archon/methods/ wholesale, so a Method dropped from a later Plugin version cannot linger. One exception […] Never delete a LICENSE file.

So any Method a second unit installs is deleted by the next /unic-archon-dlc:setup. A unit whose content the neighbouring unit's installer removes is not a unit.

The precedent that answers it is fifteen lines below, at line 220, about the adjacent tree:

Install is name-scoped, never a whole-directory replace: .archon/workflows/ is shared with the Consumer's own workflows, so only names matching unic-dlc-*.yaml are read, written, overwritten or swept. A file named outside that pattern stays untouched whatever it contains.

One tree already solves ownership by name. The other takes the whole directory. Nothing records why they differ.

Stacking is two needs wearing one face

Additive is easy and may already work: a pack ships e2e-generate, a name nobody else uses. Only the wholesale replace stands in the way.

Overriding is the hard one: a .NET pack wants its own implement, or its own code-review. That is not an edge case — it is the obvious reason to build such a pack.

Measured: every Box and command reads a Method at a literal, flat, one-level path. .archon/methods/research eight times in unic-dlc-explore.yaml; .archon/methods/{tdd,code-review} in unic-dlc-build.yaml; .archon/methods/code-review in unic-dlc-pr-review.yaml; and {triage,grilling,domain-modeling,to-tickets,to-spec} across five command files. The names are generic, so two packs collide by default rather than by accident.

The mechanism for overriding was deleted, and the stated reason does not cover this case. ADR-0031 retired the config tier (methods.<name>.source) and the local tier (.archon/methods.local/) in #381, because resolveMethod in the plugin's lib/ could never run inside an Archon node. That argument is about a run-time resolver module, not about the idea of an override. /setup still reports both paths "once, as retired", and changes neither.

The observation this ticket exists to make

Two unrelated problems are arriving at the same mechanism, and it is install time.

• A node's mcp: field takes no interpolation of any kind, so a config value can reach it only if something substitutes at install time. That is the fourth option on #425.
• A Box reads a Method at a literal path, so an override needs no run-time resolver at all. It needs whoever writes .archon/methods/ to write the winning file there.

Run time cannot resolve. Install time can. #425 is being grilled right now and will settle the first half; whoever settles it should know the second half is coming to the same door, because a rule invented twice is a rule invented differently twice.

What has to be decided

1. Does .archon/methods/ become name-scoped like .archon/workflows/? If so, by what name rule — a prefix per pack, a manifest each installer owns, or something else. A pack's Methods must survive a neighbour's /setup.
2. Is overriding allowed at all, or only additive stacking? "Only additive" is a defensible answer and it is cheap: it needs a naming convention and nothing else. It also means a .NET pack cannot replace implement, which is what such a pack is for.
3. If overriding is allowed, who wins, and where is that written? Order of install, an explicit precedence key, or a refusal to install on collision. A silent last-writer-wins is the outcome nobody chooses and everybody gets.
4. Does a unit declare what it installs? Today /setup knows what it ships because it reads its own tree. A second installer cannot know what the first one left unless something says so.
5. What retires with this. ADR-0031 retired two override paths for a reason that was about a deleted module. If overriding returns in another shape, that ADR needs amending rather than contradicting, and /setup's "report as retired" step needs to say something else.

Not in scope

The e2e chain's own shape. That seat decides whether its "how" is a Practice Pack and what constraints that imposes; it explicitly does not decide the stacking model. This ticket is the engine half.

Acceptance criteria

• A decision record states whether .archon/methods/ is name-scoped, and if so the exact rule by which a file's owner is decided.
• It states whether a pack may override a Method the DLC ships, and if not, what a pack does instead when it needs a different implement.
• If overriding is allowed, it names the winner deterministically and says where a reader sees which file won. A collision that resolves silently is a defect, not a default.
• It says what a second installer may assume about a tree the first one wrote, and what it must ask.
• It amends or supersedes ADR-0031 explicitly, rather than leaving a retired tier and a live override in the same repository.
• /setup's Methods step and its "two override paths … retired" step both match whatever is decided.
• The decision is taken beside #425's, or states why install-time substitution and install-time override are different mechanisms.

Measured 2026-09-22 by the dlc-fzag orchestrator seat, from a finding by the e2e-suite seat's worker.