ahmido
ea9ef9cb38
Some checks failed
Main Confidence / confidence (push) Failing after 48s
## Summary - add Spec 212 planning artifacts for test authoring constitution and review guardrails - expand `TEST-GOV-001` and sync the SpecKit spec/plan/tasks/checklist templates plus contributor guidance - define the canonical review checklist outcomes and record low-impact and higher-cost validation examples ## Validation - docs/workflow only; no runtime Pest or Sail test lanes were run - validation is recorded in `specs/212-test-authoring-guardrails/spec.md` and `specs/212-test-authoring-guardrails/quickstart.md` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #245
44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
# [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.
|