Checklists

requirements.md

Specification Quality Checklist: Drift-Proof Architectural Ratchet Allow-lists

Purpose: Validate specification completeness and quality before /spec-kitty.plan Feature: spec.md

Content Quality

  • ✅ No implementation details leak into user-facing outcomes (mechanism named only where it IS the domain — this is a test-infra refactor)
  • ✅ Focused on the maintainer value (no false-red tax) and CI-integrity need
  • ✅ Written so a reviewer can judge scope without reading the gate code
  • ✅ All mandatory sections completed

Requirement Completeness

  • ✅ No [NEEDS CLARIFICATION] markers remain
  • ✅ Requirements are testable and unambiguous
  • ✅ Requirement types separated (FR / NFR / C)
  • ✅ IDs unique across FR-###, NFR-###, C-###
  • ✅ All requirement rows carry a Status value
  • ✅ Non-functional requirements include measurable thresholds (0 false reds; 100% bite; 0 line anchors; 869/0 baseline)
  • ✅ Success criteria measurable + technology-agnostic
  • ✅ Acceptance scenarios defined (happy path, bite-preserved exception, motion battery)
  • ✅ Edge cases identified (relocation, multi-line insert, cross-lane rebase, enclosing rename residual)
  • ✅ Scope bounded (Out of Scope names vulture-replace + the 10 KEEP tests)
  • ✅ Dependencies + assumptions identified (PR #2545 coordination; anchoring substrate)

Feature Readiness

  • ✅ Every FR has clear acceptance criteria (via the SC/NFR battery + FR-013 plant-and-catch)
  • ✅ User scenarios cover primary flows (motion → green; offender → red)
  • ✅ Feature meets the measurable Success Criteria
  • ✅ No implementation leak beyond the intrinsic test-infra domain

Notes

  • WS2 (FR-007/008) flagged C-004 as higher-risk / sequence-or-split at planning.
  • FR-014 + ticket hygiene (matrix + claims + tracker comments) executed alongside the spec commit.