# [CHECKLIST TYPE] Checklist: [FEATURE NAME]

**Purpose**: [Brief description of what this checklist covers]
**Created**: [DATE]
**Feature**: [Link to spec.md or relevant documentation]

**Note**: This checklist is generated by the `/speckit.checklist` command based on feature context and requirements.
If the checklist covers runtime behavior or test-surface changes, use it to reach one explicit outcome: `keep`, `split`, `document-in-feature`, `follow-up-spec`, or `reject-or-split`.
Low-impact docs-only or template-only work may mark runtime-only checks `N/A`, but should still leave one explicit outcome.

## Lane Fit

- [ ] CHK001 The chosen validation lane is the narrowest lane or lane mix that proves the change.
- [ ] CHK002 The test stays in the smallest honest family (`Unit`, `Feature`, `Heavy-Governance`, `Browser`) and does not hide broader purpose behind a narrow label.

## Breadth And Cost

- [ ] CHK003 The changed or added test is no broader than the behavior it proves.
- [ ] CHK004 Any database, Livewire, Filament, or browser surface is justified over a narrower alternative.
- [ ] CHK005 Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is explicit and locally justified.

## Validation And Drift

- [ ] CHK006 The minimal reviewer validation command is written explicitly and matches the declared lane.
- [ ] CHK007 Any material budget, baseline, trend, or runtime-drift note is recorded in the active spec or PR.

## Escalation Outcome

- [ ] CHK008 One explicit outcome is chosen: `keep`, `split`, `document-in-feature`, `follow-up-spec`, or `reject-or-split`.
- [ ] CHK009 New heavy families, new browser coverage, revived expensive defaults, or material lane-cost shifts are not left implicit.

## Notes

- `keep`: current lane, family, and setup are justified.
- `split`: scope is valid, but the test or helper spread should be narrowed before merge.
- `document-in-feature`: the change is acceptable, but the cost or drift must be recorded in the active spec or PR.
- `follow-up-spec`: recurring pain or structural lane or family changes need dedicated governance work.
- `reject-or-split`: hidden cost, wrong lane, or unjustified breadth blocks merge as proposed.
- Check items off as completed: `[x]`
- Add comments or findings inline
- Link to relevant resources or documentation
- Items are numbered sequentially for easy reference
- Reviewer-facing runtime checklists SHOULD stop merge when lane fit, hidden cost, heavy-family drift, or escalation handling is unclear.