---
id: "{epic}.{story}"
slug: {kebab-case-slug}
title: "{One line, imperative or descriptive — becomes the spec title}"
epic: {epic-file-stem}
status: draft
priority: P2
workflow_type: feature
story_type: feature
estimate: M
services: []
files_to_modify: []
files_to_reference: []
depends_on: []
requirements: []
constitution:
  status: pending
  version: null
  checked_at: null
  waivers: []
implementation:
  manifest: null
  completed_at: null
---

## Story

{As a <role>, I want <capability> so that <outcome>. One paragraph. The "so that" is the
part that matters — it is what lets an implementer make good judgment calls.}

## Rationale

{Why this story exists now, and what it unblocks. Reference the epic and the PRD
requirements it satisfies. This becomes the spec's Overview, so write it for someone who
has not read the PRD.}

## Acceptance Criteria

- **AC-1**: GIVEN {precondition} WHEN {action} THEN {observable result}
- **AC-2**: GIVEN {precondition} WHEN {action} THEN {observable result}

Each criterion must be observable from outside the implementation. "The service is
performant" is not a criterion; "responds within 200ms at p95" is.

## Scope

### In Scope

- {Specific change this story makes}

### Out of Scope

- {What is deliberately excluded, and where it lives instead if it is coming later}

## Technical Notes

- {Existing pattern to follow, with the file that demonstrates it}
- {Utility or module to reuse rather than reimplement}
- {Constraint the implementer would not otherwise know}

## Dependencies

- {Story, service, or external system this depends on. State what would happen if it is
  not ready.}

## Verification

- `{runnable command}` — {what passing looks like}
- Manual: {steps, if any part cannot be automated}

## Open Questions

- [ ] {Anything unresolved. A story with open blocking questions stays `draft`.}