# [FEATURE-ID]: [Feature Title]

**Feature:** [ID] | **Type:** [Backend/Frontend/Fullstack]-[Feature/Bugfix/Refactor] | **Priority:** [High/Medium/Low]
**Status:** In Progress | **Branch:** feature/[FEATURE-ID]-[short-description]
<!-- Valid Status values: Spec | In Progress | Planning | Review | Ready for Merge | Done -->
**Created:** [YYYY-MM-DD] | **Dependencies:** [List or "None"]

---

## Spec

### Description

[What needs to be implemented and WHY. Functional requirements and context about the feature/fix and its purpose in the system.]

### API Changes (if applicable)

[Endpoints to add/modify. Reference specific sections in `docs/specs/api-spec.yaml`.]

### Data Model Changes (if applicable)

[Schema changes needed. Update Zod schemas in `shared/src/schemas/` if applicable.]

### UI Changes (if applicable)

[Components to add/modify. Reference `docs/specs/ui-components.md`.]

### Edge Cases & Error Handling

[Known edge cases, error scenarios, and boundary conditions to handle.]

---

## Implementation Plan

_Pending — to be generated by the planner agent in Step 2._

---

## Acceptance Criteria

- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
- [ ] Unit tests for new functionality
- [ ] All tests pass
- [ ] Build succeeds
- [ ] Specs updated (`api-spec.yaml` / `ui-components.md` / shared schemas)

---

## Definition of Done

- [ ] All acceptance criteria met
- [ ] Unit tests written and passing
- [ ] E2E tests updated (if applicable)
- [ ] Code follows project standards
- [ ] No linting errors
- [ ] Build succeeds
- [ ] Specs reflect final implementation

---

## Workflow Checklist

<!-- Auto-fill based on complexity tier. Remove steps that don't apply. -->

- [ ] Step 0: `spec-creator` executed, specs updated
- [ ] Step 1: Branch created, ticket generated, tracker updated
- [ ] Step 2: `{backend|frontend}-planner` executed, plan approved
- [ ] Step 3: `{backend|frontend}-developer` executed with TDD
- [ ] Step 4: `production-code-validator` executed, quality gates pass
- [ ] Step 5: `code-review-specialist` executed
- [ ] Step 5: `qa-engineer` executed (Standard/Complex)
- [ ] Step 6: Ticket updated with final metrics, branch deleted

---

## Completion Log

| Date | Action | Notes |
|------|--------|-------|
| | | |

<!-- After code review, add a row documenting which findings were accepted/rejected:
| YYYY-MM-DD | Review findings | Accepted: C1-C3, H1-H2. Rejected: M5 (reason). Systemic: C4 logged in bugs.md |
This creates a feedback loop for improving future reviews. -->

---

## Merge Checklist Evidence

> **MANDATORY before requesting merge approval.** Read `references/merge-checklist.md` and execute ALL actions. Record evidence below.

| Action | Done | Evidence |
|--------|:----:|----------|
| 0. Validate ticket structure | [ ] | Sections verified: (list) |
| 1. Mark all items | [ ] | AC: _/_, DoD: _/_, Workflow: _/_ |
| 2. Verify product tracker | [ ] | Active Session: step _/6, Features table: _/6 |
| 3. Update key_facts.md | [ ] | Updated: (list) / N/A |
| 4. Update decisions.md | [ ] | ADR-XXX added / N/A |
| 5. Commit documentation | [ ] | Commit: (hash) |
| 6. Verify clean working tree | [ ] | `git status`: clean |
| 7. Verify branch up to date | [ ] | merge-base: up to date / merged origin/<branch> |
| 9. Run `/audit-merge` | [ ] | See § "Audit Merge Output" below |

## Audit Merge Output

> Paste the FULL verbatim output of `/audit-merge` below. The block must include both tables
> (structural + drift), all rows, the combined verdict, AND the final self-verification line
> in the form `Structural: N/N PASS | Drift: K advisory | Verdict: <APPROVE|REVISE>`. Do NOT
> abbreviate, summarize, or omit failing rows. Required for the D1 structural check to PASS.

```text
<paste /audit-merge output here>
```

---

*Ticket created: [YYYY-MM-DD]*