Is an untestable acceptance criterion refused by context, or by a change to /specs and /tickets? #551

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

   • Where does /specs read acceptance criteria from when the ticket only links a specification page? #549
4. orioltf commented on Sep 23, 2026

   

   orioltf

   on Sep 23, 2026

   MemberAuthor

   More actions

   Constraint from Where does /specs read acceptance criteria from when the ticket only links a specification page?, 2026-09-23

   • Where criteria come from, and which source wins, is context each Consumer declares. When it is unclear, /specs grills the developer. This ticket decides only what happens to a criterion once /specs has it.
   • PRD.md keeps each criterion's ID from its source, the page it came from and the page version.
   • /tickets checks coverage of the PRD's acceptance criteria, but the default templates.prd has no acceptance-criteria heading (unverified). Where the criteria sit in the PRD, keyed by those IDs, is part of this ticket's decision.
5. orioltf

   self-assigned this

   on Sep 24, 2026
6. orioltf commented on Sep 24, 2026

   

   orioltf

   on Sep 24, 2026

   MemberAuthor

   More actions

   Resolution, 2026-09-24

   Nothing refuses a criterion. Context in the Consumer handles an untestable acceptance criterion, and neither /specs nor /tickets changes. /specs classifies each criterion, and the developer confirms the classification at Halt 1.

   Each decision names the layer that owns it: the DLC, a Practice Pack, or the Consumer. Every decision must hold for a Consumer that installs no Practice Pack.

   1. "Untestable" names two different things (glossary). An unverifiable criterion is one that nobody can check, because it is vague or subjective. It is a defect in the criterion. A not e2e-testable criterion is valid, and someone can check it, but not with a browser test in the Consumer's e2e environment. An e2e-testable criterion is one a browser test can check there. The three terms go into apps/claude-code/unic-archon-dlc/CONTEXT.md together with Practice Pack. docs(unic-archon-dlc): define Practice Pack and the three criterion classes adds them, as a draft.
   2. Nothing refuses a criterion. /specs classifies it, and the developer confirms at Halt 1 (DLC behaviour, no change). /specs never edits the source page, as Where does /specs read acceptance criteria from when the ticket only links a specification page? decides, so a refusal would stop the developer over a defect they do not own. An unverifiable criterion enters the PRD marked as such. /specs reports it at the end, for the page's author to fix, alongside any contradictions.
   3. Criteria sit as Acceptance criteria: bullets under each user story (Consumer, through its templates.prd). This is the only shape that all three readers see: /tickets Step 6 ("every acceptance criterion of every PRD user story"), the /build goals-check ("from the PRD user stories") and the /qa UAT preparation. A separate ## Acceptance Criteria section reaches only /qa. Each bullet carries the criterion's ID from its page, its text and its class. The page and its version are written once. A criterion that fits no story is a Halt 1 question: add a story, or leave the criterion out and give the reason.
   4. /tickets refuses nothing either (Consumer ADR, no command change). Step 6 already lets the user accept a gap explicitly. A Consumer ADR, which the /tickets ADR check reads, states that a not e2e-testable or unverifiable criterion without an e2e slice is an accepted gap by rule. Every e2e-testable criterion needs at least one slice. An accepted gap is never silent. The PRD records each not e2e-testable criterion with its class, and /specs and /tickets both list them for the developer at the end of their run.
   5. For now, a Practice Pack contributes knowledge only (Practice Pack, optional). This is where the concept stands today, not a limit on it: it may grow inside this map and outside it. It may carry the bar for what makes a criterion e2e-testable in its family. The Consumer declares everything else. Without a Practice Pack, the Consumer writes its own bar.
   6. What a Practice Pack may carry about acceptance criteria is fog, not this ticket. Examples are a template for how criteria are written, generic criteria such as accessibility or performance, and a default gap ADR. Generic criteria would be one more source that the Consumer's declared source precedence has to name, and a Practice Pack ADR would need a rule for which ADR wins. The map records this under Not yet specified.

   Measured on develop at 8765f29

   The default PRD scaffold in commands/specs.md, used when templates.prd is unset, has no place for acceptance criteria. Its User Stories comment asks only for "As an , I want…" lines. With that default, the /tickets coverage check can pass while it checks nothing. That affects any Consumer, with or without e2e, so it is filed as The /tickets coverage check passes on a PRD with no acceptance criteria and stays outside this map.
7. orioltf

   closed this as completedon Sep 24, 2026
8. orioltf

   added 2 commits that reference this issue on Sep 24, 2026

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

   ...

   762191d

   docs(unic-archon-dlc): the Practice Pack entry cites #551 only for th…

   ...

   1daa844
9. orioltf commented on Sep 24, 2026

   

   orioltf

   on Sep 24, 2026

   MemberAuthor

   More actions

   PR #557 is ready for a maintainer

   Verified by the e2e-suite seat orchestrator on 2026-09-24.

   • PR #557 targets develop and is still a draft. Its head is 1daa844, after three commits with no force-push.
   • The diff against the merge base 8765f29 is one file, apps/claude-code/unic-archon-dlc/CONTEXT.md, with 26 added lines. It adds four glossary entries: Practice Pack, E2e-testable criterion, Not e2e-testable criterion and Unverifiable criterion.
   • All CI checks pass on 1daa844. I re-ran pnpm ci:check locally on cf178a2 and it exited 0. The later commits change wording only, and CI covers them.
   • The seat that owns Practice Packs must stack read the Practice Pack entry twice. At 762191d it found that the entry settles none of that ticket's open questions. 1daa844 narrows one sentence to match this ticket's resolution, point 3.
   • The PR description matches the diff. The PR has no review threads and no review comments.

   The merge is the maintainer's, as a merge commit. The PR can leave draft first.