TenantAtlas/.specify/templates/checklist-template.md

[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.