acceptance-criteria-genlisted

## What It Does Turns a scoped request into testable acceptance criteria that describe observable behavior, guardrails, and failure handling without relying on implied implementation details. ## Use This When Use this when a request is entering planning or solutioning and the current brief has goals but not enough precise behavior to verify. It is especially important before stories, test mapping, or handoff artifacts are written. ## Inputs - Read the active request, tracker entry, or plan summary first. - Read the canonical module docs or feature spec that defines the current behavior. - Read `references/criteria-template.md` before drafting criteria so wording stays consistent. ## Procedure 1. Run `scripts/extract-ac-ids.sh <spec-file>` to get the set of AC ids already taken; never reuse a removed id. 2. For each new criterion, run `scripts/next-ac-id.sh <spec-file> [fr-number]` to allocate the next free id. 3. List the user-visible outcomes and constraints; convert each into observable Given/When/Then prose using `assets/output.template.md` as the shape. 4. Add negative, empty, stale, retry, or permission criteria only when the request changes those paths. Drop criteria that describe implementation choices instead of behavior. 5. Validate the draft with `scripts/lint-ac-output.sh <draft-file>` — exit 0 means the structural contract is met; non-zero means fix and re-lint before returning. ## Output Contract - Match `assets/output.template.md` exactly: `## Acceptanc