Where does /specs read acceptance criteria from when the ticket only links a specification page? #549

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

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

   self-assigned this

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

   

   orioltf

   on Sep 23, 2026

   MemberAuthor

   More actions

   Resolution, 2026-09-23

   /specs can do this today. It needs context in the Consumer, not a config key and not a change to commands/specs.md.

   /specs is a command, not a Box, so it runs with the session's MCP servers and Archon 0.9.0 stops workflow nodes inheriting MCP servers does not apply. It already accepts a specification URL, a tracker reference, or both, and reads them through docs.access and docs/agents/issue-tracker.md § Access. What it lacks is an instruction to follow a link it finds in a ticket body.

   Each decision names the layer that owns it: the DLC, the Practice Pack, or the Consumer.

   1. Source precedence is Consumer context (Consumer). Consumers differ. Some write criteria on the ticket and generate documentation at the end, some use the ticket only as a pointer to a specification page, and some mix the two. The DLC sets no default. When a Consumer declares no precedence, or when the ticket and the page disagree, /specs grills the developer. It does so already, through the grilling Method that the bundle installs.
   2. The declaration is an instructed read (Consumer). The Consumer states it in docs/agents/issue-tracker.md § Work-item scope: where a work item's criteria live, which link to follow, and which source wins. Passing the page URL to /specs as an argument stays valid, but the rule must not depend on the person who runs the command remembering it. The second Consumer's own authoring skill already states that the specification page wins over the ticket, so its declaration is that rule.
   3. A wrong link stops at Halt 1 (DLC behaviour, no change). /specs compares the ticket's subject with the page's subject. If they do not match, it asks the developer and does not go on without an answer. It never picks another page itself and never writes to the Consumer's tracker. The Consumer's team fixes the link.
   4. A contradiction on one page becomes a Halt 1 question (DLC behaviour, no change). The question names both criterion IDs. The developer decides what goes into PRD.md, and the PRD records the decision. /specs never edits the page. At the end it reports each contradiction for the page's author to fix.
   5. The PRD keeps the page's criterion IDs, the page it read and the page version (Pack). The IDs carry through to the test title, as Does v1 require resettable test data, or do generated tests own their data? decides. If a link pins an older version of the page, /specs reads the current one and asks at Halt 1.
   6. No sync when the page changes after the PRD (v1). Downstream steps read only PRD.md. A changed page means running /specs again by hand, and the recorded version shows the drift. A version check in /build would be a Box change and is not needed for v1.

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

   /tickets checks coverage of the PRD's acceptance criteria, but the default templates.prd has no acceptance-criteria heading, so the criteria may exist only inside the user stories (unverified). Where the criteria sit in the PRD, keyed by the page's IDs, is part of that ticket's decision.
6. orioltf

   closed this as completedon Sep 23, 2026