Repository navigation
Bug: Bug: Two coexisting acceptance-criteria numbering schemes in one spec cause miscounts #899
Description
Activity
Premise correction — this issue as filed is factually wrong
I filed this issue. The core claim is incorrect and should not be acted on as written.
What I claimed: that
docs/features/active/2026-09-11-ci-coverage-threshold-and-pester-gates-869/spec.mdcarries two competing numbering schemes — 15(#869)-prefixed criteria coexisting with a separate 31-entry## Acceptance Criteriasection.What is actually there: one
## Acceptance Criteriasection at lines 239-271 holding 31 checkbox entries, all 31 of which carry a(#NNN)issue-attribution prefix — 7 for#561, 9 for#562, 15 for#869. The "15" I cited is the#869subset of that same 31-entry list, not a competing scheme. Item 869 consolidated three issues, so the prefix is attribution within one list, which is correct behaviour rather than a defect.The
(#NNN)form appears in exactly 1 of 86 active specs.The miscounts were real; the explanation was not
The two measured miscounts cited in the body did happen. But they are explained by the genuine defect below, not by dual numbering schemes. I inferred a mechanism from the symptom instead of measuring it — the same error pattern corrected on #895 during the same run.
The genuine defects, measured across all 86 active specs
- Stray checkboxes outside the acceptance-criteria section. 869 has 4 such lines at lines 24-27. Repository-wide, 52 of 86 active
spec.mdfiles carry checkbox lines outside their acceptance-criteria section. These are injected by the promotion scaffold. This is what makes a whole-file checkbox count disagree with a section-scoped count — the actual cause of both miscounts. - 5 specs have zero in-section criteria at all, because the feature template ships a
## Definition of Doneheading instead of## Acceptance Criteria. - A third label scheme exists.
AC<n>is in use in 41 files, and is what the executor greps for — so three conventions are live simultaneously.
Ownership — this is push-down-owned, measured not inferred
- Authoring contract:
.claude/skills/acceptance-criteria-tracking/SKILL.mdlines 43-50. Line 44 permissively allows three different acceptance-criteria headings for every non-minor-auditwork mode; line 50 forbids reformatting non-checkbox criteria. - The only authoring-time gate parsing criteria out of a
spec.md:.claude/hooks/validate-prd-feature-output.ps1line 66, bound to theprd-featureagent by.claude/agents/prd-feature.mdline 20. - The scaffold injecting the stray checkboxes is not in this repository at all — it lives in the drm-copilot MCP resources bundle.
Both
.claudefiles were verified byte-identical to their drm-copilot copies.Disposition
Routed upstream to drm-copilot; this issue stays open as a TaskMaster tracker, following the precedent set by #691.
Cleaning the 52 local specs without fixing the scaffold would not hold — the scaffold reinjects on every promotion. The scheme declaration, the authoring-time gate and the scaffold templates all need to be fixed upstream first. A repo-local cleanup slice would survive push-down afterwards, because the push-down engine overwrites payload paths and never deletes destination-only files.
Re-scope this issue to that local slice only after the upstream fix lands, and only if the cleanup is still wanted.
- Stray checkboxes outside the acceptance-criteria section. 869 has 4 such lines at lines 24-27. Repository-wide, 52 of 86 active
Summary
A single
spec.mdcan carry two different acceptance-criteria numbering schemes at once - a setof
(#<issue>)-prefixed criteria scattered through the document, and a separate numbered## Acceptance Criteriasection. The counts do not agree, and neither scheme announces that theother exists.
On item 869: 15
(#869)-prefixed criteria coexist with a 31-entry## Acceptance Criteriasection.
The section-scoped count is the authoritative one. Nothing in the document says so.
Environment
(not provided in potential file)
Steps to Reproduce
(not provided in potential file)
Expected Behavior
(not provided in potential file)
Actual Behavior
(not provided in potential file)
Logs / Screenshots
(not provided in potential file)
Impact / Severity
(not provided in potential file)
Source
From: docs/features/potential/2026-09-14-spec-dual-numbering-schemes-cause-ac-miscounts.md