T-12HH-sweep-acs-state-exclusions-inline
Status: closed/superseded · Impact: medium · Complexity: small
AUTO-DEFINED: this spec was best-effort machine-authored by /sdlc:task-auto-define on 2026-07-19 because the task is autonomy: autonomous/pr. Review the Goal, Approach, Today, Files-to-touch, and Acceptance-criteria carefully before trusting it.
Sweep- or grep-style acceptance criteria that assert a pattern “returns
nothing” are unverifiable when legitimate matches survive in
planning-prose or git history — the verifier cannot tell an intended
exclusion from a real failure and has to defer a judgment call to the
user. This task closes that gap by updating the task entity’s
acceptance-criteria authoring guidance so future sweep-style ACs state
their exclusions inline, giving the verifier a clean pass/fail. It
originates from T-NLKF-converge-obsidian-bases in
https://github.com/sksizer/dev:
During T-NLKF, AC-1 (‘grep … returns nothing’) as written conflicted with the task’s own
## Proposed‘(deps or imports)’ scoping and with planning-prose references that had to survive, forcing a deferred-user judgment call at verification instead of a clean pass/fail. Update the task acceptance-criteria authoring guidance (the task entity’s implementation-ready contract and/or task template under apps/sdlc/lib/model/entities/task/) so future sweep- or grep-style acceptance criteria state their exclusions INLINE — e.g. ‘grep … returns nothing outsidedocs/planning/and git history’ — rather than an unqualified ‘returns nothing’ that later needs interpretation.
| Location | Role today |
|---|---|
apps/sdlc/lib/model/entities/task/implementation-ready.md | The implementation-ready contract. Its ## Required body sections “Acceptance criteria” bullet requires each AC be objectively verifiable but gives no guidance on scoping a sweep-/grep-style “returns nothing” AC’s legitimate exclusions. |
apps/sdlc/lib/model/entities/task/body-template.eta | The task body template rendered into new task instances. Its ## Acceptance criteria guidance block tells authors to pick something observable but never mentions naming the exclusion set of a sweep-/grep-style AC. |
Proposed
Section titled “Proposed”Both files’ AC authoring guidance instruct authors that a sweep- or
grep-style AC asserting a pattern “returns nothing” must name its
legitimate exclusions inline — the directories, file classes, and git
history the pattern may still legitimately match — e.g. “grep …
returns nothing outside docs/planning/ and git history”. The verifier
then gets a clean pass/fail instead of a deferred user judgment call.
Absorbed from T-XC32-task-acs-phrase-against-clean-fixtures
(closed/superseded into this task 2026-08-01): the same two guidance
blocks also cover corpus-dependent sweep ACs — an AC asserted against
the ambient live corpus (e.g. “exit 0 against the live entities tree”)
is named a disqualifier, with the two acceptable rephrasings: (a) assert
against a clean fixture tree the task ships, or (b) carve out the known
pre-existing drift explicitly in the AC text (“no NEW match beyond the N
pre-existing sites, enumerated in Out of scope”). The check_entities
port post-mortem’s two caveated ACs are the worked example to cite.
Approach
Section titled “Approach”- In
apps/sdlc/lib/model/entities/task/implementation-ready.md, extend the “Acceptance criteria” bullet under## Required body sections: after the existing “objectively verifiable” sentence, add that a sweep-/grep-style AC asserting a pattern “returns nothing” (or “has no matches”) must state its legitimate exclusions inline — naming the directories, file classes, and git history the pattern may still legitimately match — and give the concrete examplegrep ... returns nothing outside docs/planning/ and git history. - In
apps/sdlc/lib/model/entities/task/body-template.eta, extend the## Acceptance criteriaguidance comment block with the same instruction, so newly-scaffolded tasks carry the guidance at authoring time. - In the same two guidance blocks, add the absorbed T-XC32 rule: a
corpus-dependent AC (asserted against the live entities tree) is a
disqualifier; prescribe fixture-tree or explicit-carve-out
rephrasings and cite the
check_entitiespost-mortem’s caveated ACs as the worked example. - Keep both edits prose-only: no schema, op, verifier, or claim-resolver changes — this ships authoring guidance, not a new mechanical gate.
- Confirm the new wording is consistent with the surrounding
“objectively verifiable” guidance and renders cleanly (re-scaffold a
throwaway task via
sdlc task createto eyeball the rendered## Acceptance criteriaguidance).
Files to touch
Section titled “Files to touch”| Location | Kind | Change |
|---|---|---|
apps/sdlc/lib/model/entities/task/implementation-ready.md | modify | Extend the ## Required body sections “Acceptance criteria” bullet to require sweep-/grep-style ACs state their exclusions inline, with a concrete example. |
apps/sdlc/lib/model/entities/task/body-template.eta | modify | Extend the ## Acceptance criteria guidance block with the same inline-exclusion instruction so new tasks carry it at authoring time. |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: The “Acceptance criteria” bullet under
## Required body sectionsinapps/sdlc/lib/model/entities/task/implementation-ready.mdstates that a sweep- or grep-style AC asserting a pattern “returns nothing” must name its legitimate exclusions inline, and includes at least one concrete inline-exclusion example. - AC-2: The
## Acceptance criteriaguidance block inapps/sdlc/lib/model/entities/task/body-template.etacarries the same inline-exclusion instruction. - AC-3: A task freshly scaffolded from the template (e.g. via
sdlc task create) renders## Acceptance criteriaauthoring guidance that includes the inline-exclusion instruction. - AC-4: Both guidance blocks also name the corpus-dependent AC as a
disqualifier with the two acceptable rephrasings (clean fixture tree /
explicit carve-out), citing the
check_entitiesworked example (absorbed T-XC32-task-acs-phrase-against-clean-fixtures scope).
Out of scope
Section titled “Out of scope”- Adding a new mechanical disqualifier or claim-resolver that auto-detects unqualified sweep-style ACs — this task ships authoring guidance only, not a new gate.
- Retro-fitting existing task files whose ACs use unqualified “returns nothing” phrasing.
- Any change to the verifier,
gap-report, or the originating T-NLKF task.
Dependencies
Section titled “Dependencies”- none
Discovery context
Section titled “Discovery context”Spawned by /sdlc:spawn-task-pr on 2026-07-19 UTC from
T-NLKF-converge-obsidian-bases in https://github.com/sksizer/dev.