Checklists

requirements.md

Specification Quality Checklist: CLI Acceptance Scenarios & Cucumber-JVM Nightly

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-10-11 Mission: spec.md

Content Quality

this mission (per the ADR), not incidental implementation choices — the mission's purpose is to stand up that specific toolchain. Kept in Constraints/NFRs, out of Success Criteria.

  • ✅ No implementation details (languages, frameworks, APIs)
  • Note: Gradle/Cucumber-JVM/uv build are named because they are the governed subject of
  • ✅ Focused on user value and business needs (maintainer can verify promised CLI behaviour nightly cross-OS)
  • ✅ Written for non-technical stakeholders (overview + user stories are plain-language)
  • ✅ All mandatory sections completed

Requirement Completeness

  • ✅ No [NEEDS CLARIFICATION] markers remain (decision verify: clean)
  • ✅ Requirements are testable and unambiguous
  • ✅ Requirement types are separated (Functional / Non-Functional / Constraints)
  • ✅ IDs are unique across FR-### (001–014), NFR-### (001–005), C-### (001–006), SC-### (001–004) and match the grammar
  • ✅ All requirement rows include a non-empty Status value (Open)
  • ✅ Non-functional requirements include measurable thresholds (3 OS legs, 0 real-home contact, 100% pinned deps, 0 JDK per-PR jobs, 0 retries)
  • ✅ Every FR row and success criterion carries a delivery label and no-op mark
  • ✅ Success criteria are measurable
  • ✅ Success criteria are technology-agnostic (no framework names in SC-001..004)
  • ✅ All acceptance scenarios are defined (Given/When/Then per user story)
  • ✅ Edge cases are identified
  • ✅ Scope is clearly bounded (promise machinery explicitly out of core scope; QA consumption out of scope)
  • ✅ Dependencies and assumptions identified

Mission Readiness

  • ✅ All functional requirements have clear acceptance criteria
  • ✅ User scenarios cover primary flows (P1 verify loop, P2 wip/defect, P3 QA handoff)
  • ✅ Mission meets measurable outcomes defined in Success Criteria
  • ✅ No implementation details leak into specification (beyond the governed toolchain subject above)

Notes

(DM-01M4NZV51YAVWX0WHNCZGTB0CS): seed init scenarios land bound+untagged; @manual is reserved for heavy/on-demand scenarios.

same-fixture positive control, per tactic acceptance-criteria-non-vacuity.

  • @manual was added to the allowed/filtered tag set per the operator's seed-tag decision
  • Ratchet rows FR-003/FR-004 and absence-assertion rows FR-008/FR-012/FR-013/FR-014 each name a
  • Items marked incomplete require spec updates before /spec-kitty.plan. None are incomplete.