Does an e2e test become an outer loop around /build's unit TDD loop for a new feature? #541

Activity

1. orioltf

   added

   app:unic-archon-dlc

   wayfinder:grillingWayfinder ticket: decide it by grillingWayfinder ticket: decide it by grilling

   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 blocked on Sep 23, 2026

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

   marked this as blocking on Sep 23, 2026

   • Which Box changes does v1 need, and in what order do they land? #542
5. orioltf commented on Sep 23, 2026

   

   orioltf

   on Sep 23, 2026

   MemberAuthor

   More actions

   Constraint from a closed decision

   Does v1 require resettable test data, or do generated tests own their data? decided that e2e tests are read-only by default, and that writing e2e tests first for a new feature requires a data mechanism the Consumer declares. A new feature has no published content in any environment until someone creates it, so a test written first has nothing to read.

   For this ticket: an outer e2e loop around /build applies only at a Consumer that declares a data mechanism. The second Consumer declares none today. Any Box change this ticket asks for is about the loop, not about data.
6. orioltf

   removed a parent issue on Sep 23, 2026

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

   added a parent issue on Sep 23, 2026

   • wayfinder: e2e specs from acceptance criteria, at a second Consumer #538
8. orioltf commented on Sep 24, 2026

   

   orioltf

   on Sep 24, 2026

   MemberAuthor

   More actions

   Constraint from Is an untestable acceptance criterion refused by context, or by a change to /specs and /tickets?, 2026-09-24

   • Every criterion in the PRD carries one of three classes: e2e-testable, not e2e-testable, or unverifiable. /specs assigns the class, and the developer confirms it at Halt 1. The terms are defined in apps/claude-code/unic-archon-dlc/CONTEXT.md, in a draft PR.
   • Only an e2e-testable criterion gets an e2e slice from /tickets. The other two classes are accepted gaps, by a Consumer ADR, so /build never receives one as an e2e test to write.
   • The criteria sit as Acceptance criteria: bullets under each PRD user story. Each bullet keeps its ID from the source page.
9. orioltf

   self-assigned this

   on Sep 25, 2026
10. orioltf commented on Sep 28, 2026

    

    orioltf

    on Sep 28, 2026

    Last edited by orioltf

    MemberAuthor

    More actions

    Resolution, 2026-09-28

    Yes. The e2e test becomes an Acceptance Slice, which is a slice of its own. Its RED runs first and its GREEN runs last. A validation step before the loop keeps a broken environment from counting as RED. This ticket decides the shape of the loop only. How the app runs on the generation side stays open until a Consumer declares a data mechanism, as Does v1 require resettable test data, or do generated tests own their data? requires. The second Consumer declares none today.

    Where the e2e test is written

    1. An Acceptance Slice holds one browser test for each e2e-testable criterion, with the criterion's ID in the test title. The other slices of the feature stay plain slices.
    2. The Acceptance Slice's RED runs before every other slice of the feature. Its GREEN runs after all of them reach green-done. Today blocked_by blocks a whole slice, so an e2e slice that depends on the other slices writes its test after the code. The test then passes at once, sets red_unexpected_pass and blocks the build. So unic-dlc-build.yaml must let a slice block its GREEN phase alone. This change revises build-generic-red-green-refactor-loop. It leaves fresh-context-red-green-separation unchanged.
    3. The default is one Acceptance Slice per user story. A Practice Pack sets this default in .archon/unic-dlc.config.yaml, and the Consumer overrides it there. /setup merges the config key by key and keeps the values on disk, so an override survives a re-run. How a Practice Pack writes a config value goes to Practice Packs must stack.

    What closes the loop

    4. The Acceptance Slice's GREEN is an ordinary GREEN. It may change production code in any layer until the test passes.
    5. When a test in the Acceptance Slice fails, a fresh context classifies the failure. That context is separate from the GREEN agent. It reads the test output and any guidance the Practice Pack or the Consumer supplies, and it does not read the diff. The guidance is optional. The context gives each failure one of three verdicts, taken from the QA plugin behind Is the internal QA plugin's content reused in the e2e Practice Pack, and on what terms?:
       • environment issue: the build cancels, as the validation step does.
       • broken or stale test: GREEN fixes the test, not the code.
       • genuine bug: the failure gets a severity.
    6. Severity uses the scale of the QA process's defect step: Blocker, Critical, Major, Minor, Trivial. It is not the scale /pr-review uses. An e2e failure is a QA defect, not a review finding.
    7. The Acceptance Slice's GREEN has an attempt cap of its own. At the cap, a high-severity failure stops the build for a human, and a low-severity failure is deferred. The default puts Blocker and Critical high and Major, Minor and Trivial low. The Consumer can move the cut. A Consumer whose process is mature can switch the cap off and rely on the loop's max_iterations alone.
    8. The Consumer chooses where a deferred failure goes:
       • back into the build's issues.json as a new slice: a longer build that also fixes minor failures, or
       • to a new item on the Consumer's tracker, with the test marked test.fixme and linked to that item: a shorter build that leaves the gap visible in the suite and the pull request.

    The validation step

    9. bootstrap in unic-dlc-build.yaml checks that the e2e environment is ready whenever sdlc_needs.e2e is declared. If it is not ready, guard-not-ready cancels the build. This applies whether or not issues.json holds an Acceptance Slice, because verification runs sdlc_needs.e2e at the end of every build. RED keeps its current rule: a non-zero exit.

    Settled elsewhere or left open

    • The value of the attempt cap goes to the map's "The numbers". The map now has two thresholds, one on the QA defect scale and one on the /pr-review scale.
    • What the validation step probes, such as a URL or a health command, and how the app runs, stays open with the environment. The QA plugin leaves this to Playwright's webServer block.
    • The new config values need a single block, not separate top-level keys. /to-spec names it.
    • The Box change is an implementation item for /to-tickets. It edits unic-dlc-build.yaml, so it carries blocked_by edges to open-pr precedes its gate and No Box can target a base branch that is not the trunk. The seat that owns the Box files hears of it first. The build diagram under apps/claude-code/unic-archon-dlc/docs/architecture/ needs a redraw in the same pull request or in a follow-up.
    • The term Acceptance Slice enters apps/claude-code/unic-archon-dlc/CONTEXT.md. The Practice Pack entry now reads "context artefacts and config values".
11. orioltf

    closed this as completedon Sep 28, 2026
12. orioltf

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

    docs(unic-archon-dlc): cite #541 for the Practice Pack override

    ...

    262c131
13. orioltf commented on Sep 28, 2026

    

    orioltf

    on Sep 28, 2026

    MemberAuthor

    More actions

    PR #626 is ready to merge, 2026-09-28

    Verified by the e2e seat orchestrator on head 262c1315514fc85e7c31e4489e68a6428207feed:

    • The base is develop. The PR is out of draft, and mergeable is MERGEABLE.
    • All 15 checks concluded SUCCESS: root checks, the NDA guards and the unic-archon-dlc tests, each on three OSes with Node 22 and 24, plus license/cla and change detection.
    • The diff changes only apps/claude-code/unic-archon-dlc/CONTEXT.md. It adds the Acceptance Slice entry and widens the Practice Pack working model to "context artefacts and config values". The maintainer confirmed that wording on 2026-09-28.
    • The seat that owns Practice Packs must stack: /setup replaces .archon/methods/ wholesale, and the override tier was deleted #520 read the Practice Pack change and found that it settles none of Practice Packs must stack: /setup replaces .archon/methods/ wholesale, and the override tier was deleted #520's open questions. The Does an e2e test become an outer loop around /build's unit TDD loop for a new feature? #541 citation it asked for is in the head.
    • There are no reviews and no open threads. The description now matches the final diff.

    Merge with a merge commit. That is left to a maintainer.