Main Confidence / confidence (push) Failing after 48s

Details

docs: add Spec 212 test authoring guardrails (#245 )

## 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

2026-04-18 10:08:00 +00:00

2.5 KiB

Raw Blame History

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

2.5 KiB Raw Blame History