Golden test cases

Turn acceptance criteria into a concrete, reviewable test suite — the "golden" cases that define correct behavior. These guide QA and engineering and double as the acceptance bar.

Prerequisite. You need the user stories / acceptance criteria (ideally backed by a PRD). If they don't exist yet for this item, don't guess the behavior — tell your manager what's missing and offer to produce the stories (and PRD) first.

Coverage to aim for

• Happy paths — the primary success scenarios for each story.
• Edge cases — boundaries, empty/maximal inputs, permissions, concurrency.
• Negative cases — invalid input, failures, timeouts; assert the graceful behavior.
• Regression-sensitive — anything historically fragile or high-risk.
• Non-functional where relevant — performance/latency, accessibility, security checks stated as pass/fail.

Format

Number each case and use Given/When/Then. Group by user story / area.

## <area or story>

GT-1  <short title>            [happy path]
  Preconditions: …
  Steps:
    1. Given <state>
    2. When <action>
    3. Then <expected result>
  Expected: <observable outcome>      Priority: P0 | P1 | P2

GT-2  <short title>            [edge case]
  …

Also provide a compact traceability note: which story / acceptance criterion each GT covers, so nothing is untested.

Rules:

• Each case is deterministic and independently runnable, with a single clear expected result.
• Prefer observable outcomes over implementation details.
• Mark priority (P0 = must pass to ship).
• Call out any case you can't specify yet because the behavior is undefined — that's a question for the PRD, not a guess.

Save with start_draft as "<feature> — Golden Tests", link it to the ledger item, and flag any undefined behavior to your manager.