Can the DLC's own line, adapted by context, produce a reviewed e2e suite? #539

Activity

1. orioltf

   added

   app:unic-archon-dlc

   wayfinder:researchWayfinder ticket: investigate against primary sourcesWayfinder ticket: investigate against primary sources

   on Sep 23, 2026
2. orioltf

   added a parent issue on Sep 23, 2026

   • wayfinder: e2e specs from acceptance criteria, at a second Consumer #538
3. orioltf

   marked this as blocking 3 issues on Sep 23, 2026

   • What replaces RED in /build when an e2e test for an existing feature should pass first time? #540
   • Does an e2e test become an outer loop around /build's unit TDD loop for a new feature? #541
   • Which Box changes does v1 need, and in what order do they land? #542
4. orioltf

   self-assigned this

   on Sep 23, 2026
5. orioltf commented on Sep 23, 2026

   

   orioltf

   on Sep 23, 2026

   Last edited by orioltf

   MemberAuthor

   More actions

   Resolution

   Classes: 1 works with config and docs/agents/ context, 2 needs a Practice Pack skill or Method, 3 needs a Box change.

   Step	Case A: existing feature	Case B: test first, new feature
   /specs	1	1
   /tickets	1, and 3 only if testability must be refused rather than asked	1, and 3 only if testability must be refused rather than asked
   /build	3, unavoidable	2, and 3 only if a browser MCP server must reach the RED node
   /pr-review	1	1
   /qa	1, and 3 only if an AFK e2e failure must file a finding	1, and 3 only if an AFK e2e failure must file a finding

   One Box change is unavoidable. In unic-dlc-build.yaml, node run-build, a test for an existing feature passes on the first run. RED step 4 then sets red_unexpected_pass, and Step 2 blocks the whole build. ADR 0023-build-generic-red-green-refactor-loop § 3 makes this deliberate, and test_command_planned slices "follow the same exit-code gate". Case A needs a characterisation path with its own proof that the test can fail. A Consumer-owned variant Box under another name avoids a plugin edit, but it is still a Box fork.

   Case B works mechanically. It is class 2 because run-build reads only tdd and implement by literal path, and neither covers browser tests. One context channel reaches RED: the Consumer's testing bar in CLAUDE.md, then /specs Halt 2, then PRD § Testing Decisions, which run-build Step 0 reads. RED also accepts any non-zero exit, so a spec that fails because the server did not start still counts as a valid RED.

   Where testability can sit. It can sit in context today: the CLAUDE.md testing bar, a templates.prd heading that /specs Step 7 enforces as present, and a Consumer ADR that /tickets Step 6 checks for decision coverage. Refusing an untestable criterion, or forbidding test_command_planned on a user-facing slice, would need a change to /specs Step 5 or /tickets Steps 5 and 6.

   Also verified: /setup replaces .archon/methods/ wholesale (#520), and no Box carries an mcp: line (#425).

   Full findings, evidence and source map: docs/research/2026-09-23-dlc-e2e-fit-gap.md on develop, merged in #552
6. orioltf

   closed this as completedon Sep 23, 2026
7. orioltf

   added a commit that references this issue on Sep 23, 2026

   Merge pull request #552 from unic/feature/unic-archon-dlc/539-dlc-e2e…

   ...

   7839d44