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

Question

How do several Practice Packs stack in one Consumer beside the DLC, so that no installer removes or silently overrides what another one wrote?

Grilled with the maintainer on 2026-10-20 and 2026-10-21. The original five questions, written on 2026-09-22 before the comments, are answered under Decisions. The Archon facts below come from research against coleam00/Archon at v0.12.1, the newest release on 2026-10-21, with two include measurements on 0.10.1: the research note, merged in #646.

Decisions

A Practice Pack ships context artefacts and config values. It never ships a Box or a Method. This holds for v1. It was decided on the e2e pack, which has nothing to override, and has not been tested against a pack that must replace implement.
The DLC alone owns .archon/methods/. /setup's wholesale replace of that tree stays correct.
A skill under .claude/skills/ is a context artefact, not a Method, including when a node declares it in skills:. On Archon 0.12 and later a node reaches a project skill only when it names it in skills:, and a Claude Code plugin only when it names it in plugins:. v1 Boxes declare neither for a pack.
A pack reaches a Box run through its own managed block in the Consumer's CLAUDE.md, which points at the pack's conventions. A node receives CLAUDE.md without declaring it. Whether a node follows such a pointer is unmeasured, so criterion 1 measures it before anything rests on it.
Ownership is decided by prefix, with no manifest. Each pack has a unique prefix, and unic-dlc is the DLC's. An installer reads, writes, overwrites or removes only what carries its prefix: .claude/skills/<prefix>-*/, a <prefix>:begin / <prefix>:end block in CLAUDE.md and in each line-based formatter ignore file, and .archon/packs/<prefix>.config.yaml. It assumes nothing about anything else. If its prefix is already held by another pack, it stops and asks. Each pack brings its own installer, and the DLC's /setup installs no pack in v1. The DLC follows the same rule, so its markers move from unic-archon-dlc:begin / unic-archon-dlc:end to unic-dlc:begin / unic-dlc:end. /setup recognises a block under the old markers and rewrites it in place under the new ones, so a Consumer never holds both. No pack may take unic-dlc or unic-archon-dlc as its prefix.
Config is layered, and the Consumer's file holds only the Consumer's choices. The order is .archon/packs/unic-dlc.config.yaml, then each .archon/packs/<prefix>.config.yaml, then .archon/unic-dlc.config.yaml. Each installer replaces its own defaults file on every run, and no installer writes a default into the Consumer's file. So the Consumer's value wins, and it survives a re-run of /setup and a pack upgrade. On a re-run, /setup reports every key in the Consumer's file whose value equals the current default, as a candidate to remove, and changes nothing. Building this is a separate ticket, Build the layered Practice Pack config, not this one.
Replacing a Box step is a future route, decided and not built. A Box may declare an include: slot that ships with a DLC default block, and a pack may replace the block. Archon resolves an include target by filename across bundled, ~/.archon and repository scope, and gives no precedence inside one scope. The DLC and every pack install into repository scope, so the installer has to decide who wins. One slot holds one occupant. When a second pack claims an occupied slot, its installer detects the collision, names both packs and offers a resolution. The Consumer's choice is written to .archon/unic-dlc.config.yaml as a Consumer override. Nothing resolves silently. This is the route for a pack that must replace implement. It is built in its own ticket, when the first pack needs it.
This does not wait for #425. Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425 substitutes a value inside a file the DLC owns, such as a node's mcp:. Decision 7 replaces a whole file that another owner occupies. They share the moment, install time, but not the mechanism.

Acceptance criteria

Before the ADR in criterion 2 is written, the ticket records a measurement made on Archon 0.12.1: does a Claude node read a file that the project's CLAUDE.md points at, without the prompt naming that file? The measurement runs in a scratch repository outside every clone, under the three spike conditions on #542. It runs the v0.12.1 release binary by its path inside the scratch directory, with ARCHON_HOME pointed at a scratch folder, so the machine's own Archon install is never changed, and the comment states that this install still reports its earlier version afterwards. If that binary cannot run in isolation, the worker measures on the installed Archon instead, says so on the ticket, and #648 re-runs the measurement on run 4's Archon version before it relies on the result. The comment states the Archon and Claude Code versions the measurement ran on. If the node does not read the file, implementation stops and the ticket returns to grilling.
A new plugin ADR records decisions 1 to 8. A reader can learn from it alone the prefix rule, the files a pack may write, the config order, which file wins on a collision and where the reader sees it, and why decision 8 does not wait on #425. Each Archon fact in it names the version it was read or measured on.
ADR-0031 is revised inline, as docs/adr/README.md § Two additions requires: its Status line and its index row gain revised 2026-10-21, and it adds no amendment block. Its existing amendment blocks are carried forward into the body where still true and then deleted, as docs/adr/README.md § The amendment blocks that already exist requires. The revised ADR keeps both retired tiers retired, states that the DLC alone writes .archon/methods/ and that a pack never ships a Method, and points at the new ADR for the route to replace a step.
commands/setup.md states that /setup touches no name carrying another prefix, in .claude/skills/, .archon/packs/, CLAUDE.md or a formatter ignore file. The Methods step states that the DLC alone owns .archon/methods/. The step that reports the two override paths as retired also says where the route to replace a step is now recorded.
CONTEXT.md states the Practice Pack model as decided, no longer as a working model open on this ticket, and the Method entry says that a skill under .claude/skills/ is not a Method.
The pull request names every diagram under apps/claude-code/unic-archon-dlc/docs/architecture/ that shows a step this ticket changed, and each one has its JSON updated and both PNGs exported again. If none shows a changed step, the pull request says so.
commands/setup.md writes the DLC's blocks under unic-dlc:begin / unic-dlc:end, in CLAUDE.md and in every formatter ignore file. It states how a block under the old unic-archon-dlc markers is found and rewritten in place, and that a re-run leaves one block, never two. The plugin's AGENTS.md names the new markers. ADR-0013 and ADR-0024 are each revised inline in the same way as ADR-0031 in criterion 3, and each names the new markers and points at the new ADR. The CHANGELOG's released entries and archived PRDs under docs/issues/ keep the old markers, because they record what was. The new CHANGELOG entry says the markers changed and that /setup migrates an old block.

Split out of this ticket

Build the layered Practice Pack config: build the layered config of decision 6, including the report of default-valued keys. It blocks the first pack that sets a default.
/pr-review and /build gather standards from CLAUDE.md: /pr-review and /build gather standards from CLAUDE.md and every file it points at, from #547. It edits Box files, so it waits for #502 as #542 orders, and for criterion 1 of this ticket.
The include-slot route of decision 7 goes to the map's Not yet specified.

Not decided here

How a slot records that a pack occupies it, so that the DLC's next /setup leaves it alone. Also whether the DLC's /setup should run each installed pack's installer.
Whether Archon 0.12.x still treats include slots as measured on 0.10.1. Source at v0.12.1 shows the same logic, but it was not measured.
Whether a SessionStart hook or .claude/rules/*.md reach a node. Both are unmeasured, and neither is used here.
How a pack picks a prefix that no other pack holds. Decision 5 detects a collision, and no registry prevents one.
Whether one prefix may begin another. A pack prefixed unic would claim every unic-dlc-* name, so the prefix rule needs a boundary.

From the e2e seat: the e2e pack needs no override, and that is weak evidence for question 2

Asked for by this ticket's author, because one fact from the e2e side decides question 2. Here is the fact, its condition, and the reason it should not carry more weight than it deserves.

The fact: additive suffices for e2e

Mapped #508's chain against the eleven Methods in README § Dependencies:

Chain step	Shipped Method covering it	Needs
testability gate on acceptance criteria	none — `to-tickets` writes criteria, it does not gate them for testability	a new name
generate specs from criteria	none — `implement` is product code	a new name
verify the test against the criteria	none	a new name
review the generated test code	`code-review`, read by `/pr-review` and `/build`	see below
run the suite, findings to tickets	none, and out of scope for #508	—

Four of five want names nobody uses. code-review is the only contested one, and overriding it is not merely unnecessary, it is harmful: the same Consumer reviews product code through /build and /pr-review with that Method, so replacing it with test-automation criteria degrades both. The right shape is a second name beside it — reviewing a generated Playwright spec for brittle locators, hardcoded waits and weak assertions is a different job from reviewing application code, which is a distinction the existing QA tooling at Unic already draws between two separate agents.

So: the e2e pack ships new verbs. It replaces none.

The condition, which is not free

Additive suffices only if the e2e chain brings its own Box for any step whose Method differs. unic-dlc-pr-review.yaml reads .archon/methods/code-review/SKILL.md at a literal path, so an e2e chain that reuses that Box unchanged gets the product-code Method whether it wants it or not. #508 already plans a new Box, so the condition holds — but if anyone later proposes reusing an existing Box for an e2e step, the override question comes straight back.

Stated as a rule the ticket can use: a pack avoids overriding by bringing the Box that reads its Method. A pack that wants to change what an existing Box reads is asking for an override, whatever it calls it.

The limit: do not generalise from this

The e2e pack is the easy case and it should not be read as a vote. e2e adds verbs to a lifecycle. The .NET pack named in this ticket replaces them — its whole reason to exist is that implement and code-review should mean something different in a .NET repository. Those are different requirements, and the e2e pack's silence on overriding is evidence about e2e, not about packs.

Put plainly, because it is the trap: "additive suffices for the first pack we build" is not "additive suffices". If question 2 is answered additive-only on this evidence, the answer should say it was decided on a pack that had nothing to override, so the next reader knows what it was not tested against.

One thing this seat is not saying

Nothing here about how a pack's Methods survive a neighbour's /setup, or what happens when two packs ship the same name. Those are this ticket's, and the e2e seat's grilling has been told to point here rather than write them.

A packaging option this ticket did not have when it was filed

Measured 2026-09-22 on Archon 0.10.1, routed here by the e2e seat because it bears on stacking and is not ours to decide.

The measurement

A project skill in a Consumer's .claude/skills/ is reachable from a workflow node. It needs declaring, exactly like an MCP server.

skills: [zebra-probe]   →  {"skills_offered":["zebra-probe"],"zebra_marker":"BRAVO9"}
no declaration          →  {"skills_offered":[],"skill_file_on_disk":"present"}

Same repository, same committed skill, two nodes differing only in that line. BRAVO9 is content only a loader of the skill file yields, so this is a positive on content rather than a node reporting that it read something.

Confirmed against the 0.10.1 binary: skills is a real node-level field, skills: 'all' is its documented all-form, and the bundle carries the verbatim warning "an unknown name is ignored rather than loaded".

An earlier report from the e2e seat said project skills were invisible to a node. That was wrong: it measured the default and read the default as a limit. The correction is stated here rather than left in a thread, because the wrong version reached two seats' notes.

Why it matters to this ticket

A Practice Pack that ships .claude/skills/<pack>/ does not touch .archon/methods/. So it neither dies in that tree's wholesale replace on the next /setup run, nor collides in the flat one-level Method namespace that makes implement and code-review contested names.

That is a third shape beside the two this ticket weighs, and it was not available when the ticket was filed. It is not free — at least these follow, and none is decided here:

It is an additive route, not an overriding one. A pack shipping a skill sits beside the Methods; it does not replace one. So it may narrow question 2 rather than answer it: a pack that only needs to add can use this and never contest a name, while a pack that must replace implement still needs whatever this ticket decides.
The declaration is per node, in the Box's YAML. So a pack's skill reaching a run depends on a Box naming it, which is the same coupling the mcp: field has and lands in the same place — install time, or a Box that ships knowing the pack's names.
Undeclared is silent. A node with no skills: line runs green with zero skills, exactly as a node with no mcp: line runs green with zero tools. Whatever this ticket decides, a pack whose skills did not load and a pack that had none look identical from outside.
Two schema defects sit on this path. skills: all cannot be expressed at node level — the DAG schema rejects the bare string and the SDK rejects the array form, so the two contradict each other. And a misspelt name loads nothing and the node continues.

What is not measured

Whether a skill loaded this way can read its own references/ sub-files from inside a node, and what happens when two declared skills share a name. The second is directly a stacking question and cheap to settle; neither was needed for the question in front of the e2e seat, so neither was run.

No decision proposed. Placing the option and its costs on the ticket that owns them.

A glossary question that changes this ticket's surface

Raised by the e2e-suite seat's grilling, routed here rather than edited into CONTEXT.md.

CONTEXT.md glosses Method as the skill text a Box reads at .archon/methods/<name>/SKILL.md. Measured today, there is a second route to the same thing: a project skill in .claude/skills/<name>/, reached when a node declares skills: [<name>]. Confirmed against the Archon 0.10.1 binary — skills: t.array(t.string().min(1)).optional() is a node field, a resolver exists, and a declared name that does not resolve warns and continues.

Both are procedure a node reads. They arrive by different routes, and both carry companion files.

Why it lands on this ticket rather than on a glossary chore. This ticket is about .archon/methods/ — that /setup replaces it wholesale, that the names are flat and generic, and that two packs collide there. A declared skill does not live in that directory. So a pack that ships .claude/skills/<pack>/ neither dies in the wholesale replace nor collides in the flat namespace, which is a third packaging shape that did not exist when this ticket was filed.

It is not a free win. It is additive-only, so it may narrow question 2 rather than answer it; an undeclared skill is silent in exactly the way an undeclared mcp: is; and the e2e-suite seat measured two schema defects on that path — skills: all cannot be expressed at node level, because the DAG schema rejects the bare string and the SDK rejects the array form, and a misspelt name loads nothing while the node runs on.

So the question for the grilling, before the packaging one: is a declared skill a second kind of Method, a different term, or does the existing term widen to cover it? Answer it first, because question 1 of this ticket — whether .archon/methods/ becomes name-scoped — is about a directory that one of the two routes does not use.

Routed by the DLC seat, which takes no decision on it.

Two working answers from the maintainer, relayed second-hand

The maintainer gave these on 2026-09-24 in the e2e-suite seat's session. e2e-orchestrator-4 relayed them to this seat. They are recorded here as relayed and have not been confirmed first-hand, so confirm them at this ticket's grilling before a criterion rests on them.

Stacking. A Practice Pack packs context artefacts only, never Boxes or Methods. The maintainer calls this a working model and does not yet promise it will hold if later work needs a change.
Who owns .archon/methods/. The DLC does. Neither orchestrator seat owns it.

Question 3 is still open. The maintainer asked what "a skill listed in a node's skills:" means.

What this does to the questions above, if it holds

Questions 1, 3 and 4 fall away for Methods. A pack that ships no Method cannot die in /setup's wholesale replace or collide in the flat namespace, so that replace stays correct as written.
Question 2 is answered "neither". A pack neither adds Methods nor overrides one. A .NET pack that wants a different implement then has no route, and a ticket has to say whether that is accepted.
Question 5 has nothing to amend. ADR-0031 stays as written.

A tension to settle at grilling

"Never Boxes" conflicts with the rule in the comment of 2026-09-22 above: "a pack avoids overriding by bringing the Box that reads its Method."

It lands on one live option, the second option of #540 on #538: Case A as a separate Box rather than a declared /build mode. If a pack ships no Box, that Box belongs to the DLC. #508 no longer plans a Box of its own, because #538 superseded it on 2026-09-23. A skill under .claude/skills/<pack>/ probably counts as a context artefact. That reading is unconfirmed, and it is exactly question 3.

Edited 2026-09-24: corrected. The first version said #508 plans a new Box, and #538 superseded that plan.

Posted by unic-sdlc-orchestrator-3, the DLC seat.

docs(unic-archon-dlc): keep the Practice Pack entry to what is settled

Constraint from Does an e2e test become an outer loop around /build's unit TDD loop for a new feature?, 2026-09-28

That ticket needs a Practice Pack to set default config values in .archon/unic-dlc.config.yaml, such as how many Acceptance Slices a user story gets. The Consumer can override each value. How the Practice Pack writes the value is left to this ticket. Two options came up, and neither was chosen:

A. /setup merges the values. A Practice Pack declares values, and /setup merges them as one more layer: defaults, then the Practice Pack, then what is on disk, then the answers of the run. The file keeps one writer, and a Practice Pack that is added later is picked up by running /setup again. The cost is that /setup must know the structure a Practice Pack declares, which moves responsibility up the chain.
B. The Practice Pack writes the file. This gives a Practice Pack more freedom and more responsibility, and the maintainer leans slightly this way. The cost is a second writer, which raises the minimum work needed to make a Practice Pack.

There is also a problem that both options share as /setup is written today. /setup writes the merged result to disk, defaults included, and treats a value on disk as the Consumer's. So once a Practice Pack's default reaches disk, by either route, it looks the same as a Consumer override, and a later version of the Practice Pack cannot update its default without overwriting a choice the Consumer made. Option A avoids this only if /setup writes back just the values the Consumer set, or records where each value came from.

Whatever this ticket decides, the Consumer's override must win over the Practice Pack's default, and it must survive a re-run of /setup and an upgrade of the Practice Pack.

Input from #547: the Standards axis reads four root files only

Found while resolving #547, 2026-09-29. The maintainer wants this fixed for every Consumer, not only for e2e, and asked that it be grilled here rather than on its own.

Step 3 of the review node in unic-dlc-pr-review.yaml gathers the repository's standards from CLAUDE.md, AGENTS.md, CONTRIBUTING.md and CODING_STANDARDS.md, whichever exist. It reads nothing else.

So a standard that lives anywhere else reaches the Standards axis only if one of those four files points at it. That includes a Practice Pack's conventions and a Consumer's own conventions under .claude/skills/<name>/references/. Whether the model follows such a pointer is unmeasured. AGENTS.md is itself one of the four only through the node's own Read. A node gets CLAUDE.md and nothing else by default (docs/agents/agent-tool-traps.md § Archon, measured on v0.10.1, 2026-09-22). This is the presence-versus-read question of #521.

This bears on the question this ticket already holds: where a Practice Pack declares its standards, and how each Box that judges against them finds them. /build's implement-review-precheck follows the code-review Method's step 3, which takes anything in the repository that documents how code should be written. So the list of four files is /pr-review's own narrowing, and the two Boxes gather standards differently.

For v1 of the e2e map, #543 carries a narrower constraint: the e2e conventions live where step 3 reads, or one of those four files points at them.

#629 may replace the review node, and waits for #501 and #502. Whatever this ticket decides about where standards live has to hold for the node that ships, so name the Box behaviour, not the current step number.

Stale — do not follow. Superseded on 2026-10-21 by the implementation opener below.

Opener — How to start this session (written 2026-10-20 by unic-sdlc-orchestrator-5, at dispatch)

What this session produces

Approved acceptance criteria in this ticket's body, then the label ready-for-agent. Nothing else. The decision record and the /setup edits are implemented afterwards under /afk-loop, not here.

Start: the maintainer types /wayfinder 373 #520. When the grilling starts, the maintainer types /grill-with-docs. Both carry disable-model-invocation, so the session cannot invoke them itself.

Do not close this ticket. This overrides /wayfinder step 4, which closes a decision ticket. This stream grills a ticket into its own criteria and implements it under the same number (maintainer, 2026-09-29). Do not invoke /implement, /tdd or /to-tickets.

Read in this order

Comment 5811498202 comes before the body. It holds two working answers from the maintainer, relayed second-hand: a Practice Pack ships context artefacts only, never Boxes or Methods, and the DLC owns .archon/methods/. Confirm both with the maintainer first. If they hold, questions 1, 3 and 4 of the body fall away for .archon/methods/, and the tension the comment names with the "bring your own Box" rule has to be settled.
The body: five questions and seven criteria, written before the comments.
Comment 5776612724: the e2e pack needs no override, and why that is weak evidence for question 2.
Comment 5782143318 and comment 5783221235: a project skill in .claude/skills/ reaches a node through skills:, measured on Archon 0.10.1, and the open glossary question of whether that is a Method.
Comment 5878319638: from #541, a pack sets default config values, with options A and B and a provenance problem common to both.
Comment 5888515573: from #547, the Standards axis reads four root files only. The maintainer wants it fixed for every Consumer and grilled here.
#545, body and comment 5928278130. This ticket is Where does the e2e Practice Pack live, and what name prefix does it own? #545's only blocker. Where does the e2e Practice Pack live, and what name prefix does it own? #545 picks a location and a name prefix in .claude/skills/ within whatever this ticket decides, and it asks whether a pack writes a managed block into the Consumer's CLAUDE.md.
#544's resolution: decision (c), the pack copies nothing and writes its own verdicts and severity scale.
In this repository: ADR-0031, apps/claude-code/unic-archon-dlc/commands/setup.md (its Methods step, its workflows step and its "retired" step), and the Method entry in apps/claude-code/unic-archon-dlc/CONTEXT.md.

The trap that costs an hour

Closing on "packs ship no Methods, so .archon/methods/ stays as it is and ADR-0031 needs no change", and calling that the answer. If the working model holds, the stacking problem does not go away. It moves to three other places that a pack does write: .claude/skills/, which #545 needs a rule for; .archon/unic-dlc.config.yaml, from #541; and the Consumer's CLAUDE.md, from #545's comment. A criteria set that speaks only about .archon/methods/ leaves #545 with nothing to choose within, and #542 and #545 stay blocked. The ticket's title says packs must stack, not that one directory survives.

What this ticket does not decide yet

Each of these is a question for the maintainer. None is yours to settle with a plausible default.

Whether a skill listed in a node's skills: is a Method, a context artefact or a new term (question 3 in comment 5811498202). Answer it first, because it decides which tree the stacking rule covers.
How a pack's default config values reach .archon/unic-dlc.config.yaml (option A or B), and how a Consumer's override survives a re-run of /setup and a pack upgrade.
Who writes the CLAUDE.md pointer to a pack's conventions, and whether it is a managed block.
Whether a pack that needs a different implement has a route at all, or whether that gap is accepted. If it is accepted, the criteria say so and say that the decision was taken on a pack with nothing to override.
Criterion 7 asks for this decision to be taken beside #425. Archon 0.9.0 stops workflow nodes inheriting MCP servers — every Box loses its tracker/docs/design access on upgrade #425 is on hold. Decide whether to wait, or to state why install-time substitution and install-time override are different mechanisms.
Where the Standards axis reads a pack's conventions from. Name the Box behaviour, not a step number, because #629 may replace the review node.

Other traps

This repository is public, and its issues are too. Name no client, no Consumer repository, no city, sector or product. Write "the Consumer" or "a second Consumer". The NDA hook refuses listed terms, and it does not catch a paraphrase.
If a criterion makes a Box declare skills: per node, that edits Box YAML. Name which Boxes, and say how it is ordered against #521 (settingSources) and What replaces RED in /build when an e2e test for an existing feature should pass first time? #540's coming unic-dlc-build.yaml tickets, which edit the same files.
When the criteria change commands/setup.md or a Box YAML, they name the diagram under apps/claude-code/unic-archon-dlc/docs/architecture/ that the change makes stale, and require its JSON updated and both PNGs exported again.
Two facts are unmeasured: what happens when two declared skills share a name, and whether a declared skill can read its own references/ files. Both bear on stacking. If a criterion depends on one, measure it in a scratch repository outside every clone, or write the criterion so that it does not depend on it.
The skills: measurements were taken on Archon 0.10.1. Run 4 now targets the newest release at freeze time (#502 amendment). A criterion that rests on a node field states the version it was measured on.
Ask one question at a time while the answers still branch. Once they no longer depend on each other, ask them together.
Links, never bare ids, in everything you write on the tracker.

The bar that proves it

Before the label goes on, run the four reads from docs/agents/dispatching-and-learning.md § Before you post one on the criteria as a set. Then check three things:

Where does the e2e Practice Pack live, and what name prefix does it own? #545 can pick a location and a prefix by reading only these criteria.
Does an e2e test become an outer loop around /build's unit TDD loop for a new feature? #541's constraint has an answer: the Consumer's override wins and survives both a re-run of /setup and a pack upgrade.
No criterion is satisfied by changing nothing.

A false pass is a set that reads complete because each criterion is reasonable on its own, while all of them speak about .archon/methods/ only.

On landing

Rewrite this ticket's body with the approved criteria, and post a comment saying the body was amended and what changed.
Before you apply any label, report to unic-sdlc-orchestrator-5 with the link to the amended body. The orchestrator reads the criteria as one set and replies.
Then replace needs-specs with ready-for-agent, and unassign the ticket so /afk-loop can take it. If the maintainer wants to hold it back, leave it assigned and say so in the comment.
Post a short comment on #545 that names what it can now choose within.
Change no file in the repository.

Report back

BEFORE YOU FINISH, AND WHENEVER YOU LEARN SOMETHING THAT WOULD HAVE CHANGED THIS PROMPT,
report to unic-sdlc-orchestrator-5 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-5. Do not message another orchestrator or its
sessions; tell unic-sdlc-orchestrator-5, who relays it.

Review and handover

There is no pull request. The maintainer approves the criteria in the session. The orchestrator reads them as one set before the label goes on. Implementation runs later under /afk-loop, which this seat records as unproven in the Consumer until a Consumer run reads it.

feat(unic-archon-dlc)!: move the managed-block markers to unic-dlc

docs(unic-archon-dlc): mark the Practice Pack design as decided in th…

fix(unic-archon-dlc): make the /setup prefix rule and Step 7 agree

docs(unic-archon-dlc): correct ADR-0038 claims on unbuilt work and scope

Body amended, 2026-10-21, during implementation

Criteria 3 and 7 asked for dated amendments on ADR-0031, ADR-0013 and ADR-0024. docs/adr/README.md retired amendment blocks on 2026-09-02: a decision that still stands is revised inline, with the revision date on its Status line, and an ADR's old blocks are carried forward and deleted the first time someone revises it. Review of #649 found the conflict. The maintainer chose the README's rule on 2026-10-21, so both criteria now ask for inline revision. No other criterion changed.

docs(unic-archon-dlc): revise ADR-0024 and ADR-0031 inline

fix(unic-archon-dlc): close Step 7 marker gaps and correct ADR-0038

docs(unic-archon-dlc): leave the order of two packs' defaults open in…

docs(unic-archon-dlc): fix the last ADR claims from the #649 review

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

Description

Question

Decisions

Acceptance criteria

Split out of this ticket

Not decided here

Activity

orioltf commented on Sep 22, 2026

From the e2e seat: the e2e pack needs no override, and that is weak evidence for question 2

The fact: additive suffices for e2e

The condition, which is not free

The limit: do not generalise from this

One thing this seat is not saying

orioltf commented on Sep 22, 2026

A packaging option this ticket did not have when it was filed

The measurement

Why it matters to this ticket

What is not measured

orioltf commented on Sep 22, 2026

A glossary question that changes this ticket's surface

orioltf commented on Sep 24, 2026

Two working answers from the maintainer, relayed second-hand

What this does to the questions above, if it holds

A tension to settle at grilling

orioltf commented on Sep 28, 2026

Constraint from Does an e2e test become an outer loop around /build's unit TDD loop for a new feature?, 2026-09-28

orioltf commented on Sep 29, 2026

Input from #547: the Standards axis reads four root files only

orioltf commented on Oct 20, 2026

What this session produces

Read in this order

The trap that costs an hour

What this ticket does not decide yet

Other traps

The bar that proves it

On landing

Report back

Review and handover

11 remaining items

orioltf commented on Oct 21, 2026

Body amended, 2026-10-21, during implementation

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions