wayfinder: e2e specs from acceptance criteria, at a second Consumer #538

Destination

A spec clear enough to hand to /to-spec and /to-tickets for running the DLC's own line at the second Consumer to produce Playwright e2e tests: /specs, /tickets, /build, /pr-review, /qa, with CI running the suite afterwards.

It covers two cases. One is e2e tests for a feature that already exists. The other is e2e tests written first for a new feature that /build then implements across frontend, backend and API.

The map decides which parts are context in the Consumer, which belong in an e2e Practice Pack, and which need a change to a DLC Box. It is done when every design decision is closed and nothing is left to decide before someone builds it.

Notes

Seed. Generate an e2e suite from acceptance criteria, with the DLC's shape, at a second Consumer is the brief. This map supersedes two of its sections, and the brief will say so:

• § "Why this is not the /qa Box". It said nothing here extends unic-dlc-qa.yaml. The maintainer reframed the effort on 2026-09-23: the chain is the DLC's own line, adapted by context, and a Box change is allowed where context cannot do the job.
• § "Scope boundary". It said this effort does not edit the four Box YAMLs. Tickets that change a Box stay in this map. They carry a cross-map blocked_by edge to the tickets already editing the same file.

The NDA rule. The second Consumer is never named on GitHub, and neither is anything that identifies it, a stack plus a sector included. Every ticket and comment says "the second Consumer". The detail lives in the seat's notes, outside git. Write bodies with a file and publish with --body-file, so .claude/hooks/block-nda-terms.mjs reads them.

Adaptation is context first. An existing Consumer already runs the DLC for another kind of output. It adapts the Boxes through .archon/unic-dlc.config.yaml and docs/agents/*.md and leaves .archon/methods/ byte-identical to the bundle. /setup replaces .archon/methods/ wholesale on every run, so a Method edited inside a Consumer loses the edit on the next /setup. That is Practice Packs must stack's problem, not a local fix.

Box files have another owner. The four unic-dlc-*.yaml files belong to the seat driving the map that proves unic-archon-dlc at a Consumer. No ticket that edits a Box file is dispatched before that seat hears of it. A cross-map blocked_by edge records the order. Any ticket that edits unic-dlc-build.yaml is blocked by open-pr precedes its gate and No Box can target a base branch that is not the trunk. Any ticket that needs a browser inside a node waits on Archon 0.9.0 stops workflow nodes inheriting MCP servers.

Cite by step, not by line. A criterion names the step or the ADR slug. ADRs here are plugin-local, under apps/claude-code/unic-archon-dlc/docs/adr/, so cite them by slug.

Two environments. Generation runs on a developer's machine, with agents and MCP servers. CI runs the suite and nothing else. A generated test that depends on anything agent-side passes where it was written and cannot run where it lives.

Skills. grilling and domain-modeling for grilling tickets, research for research tickets, unslop on every piece of prose that ships.

Proving value needs the Consumer's QA Baseline. The Consumer measures it, in its own tracker, before the first generated test merges to its integration branch. A work item in the Consumer's tracker carries that work; nothing on GitHub mirrors it. See the #548 resolution.

Settled while charting (2026-09-23)

1. The map is a new issue, a sub-issue of the seed. The seed keeps its body as the brief.
2. Running the suite is in scope, locally through /qa's e2e node, then in CI. The CI pipeline itself belongs to the Consumer. This map adds one rule to it: a generated test depends on nothing agent-side.
3. The Practice Pack is in scope as decisions: where its repository lives, what it reuses, what name prefix it owns. Building it is out of scope, as building the chain is.
4. /pr-review reviews e2e tests on both axes, Standards and Spec, as it reviews any other code. No axis change.
5. The testability gate is not a step of its own. It becomes a demand on /specs and /tickets.
6. The existing gates vocabulary covers the human gate. /build, /pr-review and /qa already carry hitl and afk gates, and the fit-gap found no Box change needed for them. No new gate.

Decisions so far

• Can the DLC's own line, adapted by context, produce a reviewed e2e suite?: yes for /specs, /tickets, /pr-review and /qa; /build for an existing feature needs a Box change, because a first-run pass blocks the whole build. The rest is conditional on later decisions.
• Are the second Consumer's acceptance criteria machine-usable, and is its test data resettable?: no criteria sit on the tickets themselves; 65 of 116 on linked specification pages can become a browser test, and no run can reset test data today.
• Does v1 require resettable test data, or do generated tests own their data?: no. The Practice Pack defaults to read-only tests; a data mechanism, the e2e environment and what content is stable are context the Consumer declares. This knowingly relaxes the data precondition of the sketch behind the seed.
• Where does /specs read acceptance criteria from when the ticket only links a specification page?: through Consumer context, with no change to /specs. Each Consumer declares where criteria live and which source wins; when it is unclear, /specs grills the developer. A wrong link or a contradiction stops at Halt 1, and the PRD keeps each criterion's ID, page and version.
• Is an untestable acceptance criterion refused by context, or by a change to /specs and /tickets?: nothing refuses; context in the Consumer, no command change. /specs classifies each criterion as e2e-testable, not e2e-testable or unverifiable, and the developer confirms at Halt 1. Criteria sit as bullets under each user story. A Consumer ADR makes the non-e2e classes accepted gaps, which the PRD records and both commands report.
• Does an e2e test become an outer loop around /build's unit TDD loop for a new feature?: yes, as an Acceptance Slice whose RED runs first and whose GREEN runs last, which needs a change to unic-dlc-build.yaml. A fresh context classifies each failure by the QA plugin's verdicts and defect severity scale. An attempt cap, a severity cut and where a deferred failure goes are Consumer config. A readiness check in bootstrap cancels the build when the e2e environment is down. How the app runs stays open until a Consumer declares a data mechanism.
• Does /pr-review sit beside or replace the second Consumer's existing reviewer?: beside. The team keeps its reviewer and runs it before a pull request opens; /pr-review runs on the chain's pull requests, with a hitl gate. It needs no PRD, and e2e changes only its context.
• What baseline does the second Consumer measure before the first run?: the Consumer owns it and keeps every number in its own tracker. This map proposes the metrics (manual QA effort per sprint, automated coverage of acceptance criteria, the key metrics of Unic's software quality management process) and requires every generated test to name its criterion ID. The baseline is a precondition of the first merge of a generated test.
• What do Archon releases after 0.7.0 offer for running one loop phase with its own tools and rules?: a loop_group body node keeps its own tool list and sandbox on 0.7.0, so one phase of an iteration can run with its own rules. No release blocks Read, Grep and Glob by path in a measured way. A Sub-run fans out over runtime data from 0.8.0, but not inside a loop.
• What replaces RED in /build when an e2e test for an existing feature should pass first time?: a Characterisation Slice, a slice kind of its own, run before every other slice. run-build becomes a loop_group, so the test writer's node can deny reads of the application source (enforcement still to be measured). A separate context proves the test can fail by three runs around a sabotage the Practice Pack supplies. A genuine bug is always deferred, so the verdict stays pass and the finding reaches review. It amends both build ADRs; no new Box.
• Which conventions of the existing e2e suite become tenant conventions, and who owns its directory?: the conventions stay in the suite's README, which /build reads, and the Consumer's CLAUDE.md points at it for /pr-review. /build writes only tests and Page Objects, plus one fixture entry per new Page Object; the suite's author owns the rest, and every pull request touching the suite gets a human review. A generated acceptance test is tagged @feature, never @smoke.
• Where do acceptance criteria come from for an existing feature with no specification?: through /specs as usual, with no third input value; the run writes the feature's PRD after the fact. Criteria come from the developer, the running app or a design, never from the application source. /specs tells the developer so up front, and each criterion records its source. The developer confirms at Halt 1, and a Consumer ADR accepts the gap when nobody holds product authority. The rule goes into commands/specs.md, after unic-archon-dlc: ADR links in commands/*.md resolve against the Consumer's repository #556.
• Is the internal QA plugin's content reused in the e2e Practice Pack, and on what terms?: no file is copied. The internal QA plugin is now licensed for Unic-internal use only, and this repository is public. The Practice Pack writes its own three failure verdicts and its Blocker-to-Trivial severity scale, and names the defect management step of Unic's software quality management process and the internal QA plugin as their origin.

Not yet specified

• The numbers. How many attempts before the Acceptance Slice's GREEN stops, and what share of review findings is acceptable at the pull-request gate. These are two thresholds on two scales: the QA defect scale for e2e failures, and /pr-review's scale for review findings. The same cap also bounds the sabotage proof of #540. One measured chain run took over half an hour, so the cap is a wall-clock question too.
• What /qa does with a failing e2e test, and where the finding lands in the Consumer's tracker. Its e2e node also has no readiness check: a down environment reads as a failing suite.
• How the e2e environment runs on the generation side. What /build's readiness check probes, and what starts the app. It stays open until a Consumer declares a data mechanism. The QA plugin leaves both to Playwright's webServer block.
• The Consumer's PostToolUse hook. It fires on every Write and Edit in that repository, including a generated spec. What it does with a file outside its own domain is unmeasured.
• The NDA guard inside an Archon node. Probably absent. Measure it before dispatching any Box that could publish.
• Which testable criteria are worth automating. The sketch behind the seed ranks them by criticality and impact before any test is written. This map decides only whether a criterion is testable.
• Where an ambiguous criterion goes back to. The sketch sends it from verification back to the testability gate, never to regeneration. This map has no path from /build back to /specs.
• Tests that already exist. The sketch skips what the suite already covers. Nothing here says how /build learns what is covered.
• Hand-offs to the QA process. The sketch takes its input from the analysis and design step of Unic's software quality management process and hands results to its defect management and completion steps. This map names neither hand-off.
• Test-case items on the Consumer's tracker. The suite's author suggested an agent could also create the tracker items that document each automated test, with its scenario and linked bugs (#543). No ticket on this map covers it.
• What a Practice Pack may carry about acceptance criteria. A template for how criteria are written, generic criteria such as accessibility or performance, general expectations for a kind of feature (ruled out of the chain by #631), a default gap ADR. Each raises a rule this map has not set: generic criteria are one more source the Consumer's precedence must name, and two gap ADRs need a rule for which wins.
• The proposal to the second Consumer's team. What the team is asked about the DLC, /pr-review, a Practice Pack, and the QA Baseline proposal from #548. Whether a Practice Pack carries a generic QA Baseline template waits on Is the internal QA plugin's content reused in the e2e Practice Pack, and on what terms? #544 and Where does the e2e Practice Pack live, and what name prefix does it own? #545. It waits until there is something to hand over (Does /pr-review sit beside or replace the second Consumer's existing reviewer?).
• Which of two Playwright artefacts survives. The e2e Practice Pack copies nothing from the internal QA plugin, but that plugin stays a separate, changing plugin that does a similar job, so two artefacts can drift apart. The plugin's authors know it and accept it for now (#544). Which one survives, and when, bears on #545.

Out of scope

• Operating the suite in CI: the pipeline, its schedule, and what the Consumer does with a CI failure. The Consumer owns it.
• Writing data provisioning through the chain: allowed later by Does v1 require resettable test data, or do generated tests own their data?, parked for v1 as the sketch behind the seed parks test data generation.
• Suite maintenance: retiring obsolete tests and re-enabling stale skips (the completion step of Unic's software quality management process). The sketch parks it as follow-up work.
• Broadening /pr-review toward the aspects of pr-review-toolkit. It is not about e2e, and it edits a Box file another map owns. The discussion and what is measured are in the #547 resolution; the owning seat filed the spike #628 and the broadening #629, which waits for spike(unic-archon-dlc): can an Archon node reach a plugin agent, command or skill? #628, Take the reviewer's variance baseline on 0.28.0, before any fix lands #501 and Dispatch run 4, end it in a merge, and score the seal #502.