Checklists
requirements.md
Specification Quality Checklist: Primary & Merge Vocabulary Disambiguation
Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-07-16 Feature: spec.md
Content Quality
- ✅ No implementation details (languages, frameworks, APIs) — spec names surfaces/terms, not implementation
- ✅ Focused on user value and business needs (readers/maintainers stop misreading "primary"/"merge")
- ✅ Written for non-technical stakeholders (sense tables + plain-language scenarios)
- ✅ All mandatory sections completed
Requirement Completeness
- ✅ No [NEEDS CLARIFICATION] markers remain
- ✅ Requirements are testable and unambiguous
- ✅ Requirement types are separated (Functional / Non-Functional / Constraints)
- ✅ IDs are unique across FR-###, NFR-###, and C-### entries
- ✅ All requirement rows include a non-empty Status value
- ✅ Non-functional requirements include measurable thresholds (100% invariance, gates exit 0, all 8 categories)
- ✅ Success criteria are measurable (0 exempt tokens changed, exactly 1 resolver, 0 dead links)
- ✅ Success criteria are technology-agnostic
- ✅ All acceptance scenarios are defined
- ✅ Edge cases are identified (ambiguous occurrence, exempt substring, UNRELATED, Sense-C defer, docs-move gates)
- ✅ Scope is clearly bounded (Track 1 vs Track 2 vs #2727 stated explicitly)
- ✅ Dependencies and assumptions identified
Feature Readiness
- ✅ All functional requirements have clear acceptance criteria
- ✅ User scenarios cover primary flows (read one term/sense; safe code dedup+rename; one glossary home)
- ✅ Feature meets measurable outcomes defined in Success Criteria
- ✅ No implementation details leak into specification
Notes
- Boundary is load-bearing: Sense-C code rename is Track 2 (C-002);
src/glossary/removal is #2727 (C-003). A reviewer must confirm no WP pulls those in. change_mode: bulk_edit— the plan phase MUST produceoccurrence_map.yamlwith all 8 categories (NFR-004 / C-005) before implement.- Ready for
spec-kitty plan.