Checklists

requirements.md

Specification Quality Checklist: Terminus Integrity Follow-ups

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-09-24 Feature: spec.md

Content Quality

  • ✅ No implementation details (languages, frameworks, APIs) — FRs are behavior-level (observable merge/verdict outcomes); the HOW (blob attribution, MergeState fields, resolver wiring) is deferred to plan. Internal module/test names appear only as trace anchors in Key Entities / Success Criteria, not as requirements.
  • ✅ Focused on user value and business needs — every story is framed as operator-observable data-safety.
  • ✅ Written for non-technical stakeholders — the operator-facing consequences (silent data loss, wrong tree, clobbered rows) lead each story.
  • ✅ All mandatory sections completed — User Scenarios, Requirements, Success Criteria present.

Requirement Completeness

  • ✅ No [NEEDS CLARIFICATION] markers remain — none; scope confirmed via Decision Moments.
  • ✅ Requirements are testable and unambiguous — each FR maps to an acceptance scenario and a named tests/terminus/ repro.
  • ✅ 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 (Open).
  • ✅ Non-functional requirements include measurable thresholds — 100% pre-existing green, zero new ruff/mypy/format, McCabe ≤15, literal-repeat ≥3 hoisted.
  • ✅ Success criteria are measurable — repro marker flips, exit-code + tree-presence assertions, suite-green.
  • ✅ Success criteria are technology-agnostic — phrased as observable outcomes (removed file absent, commit reachable, rows survive); test-suite references are verification anchors, acceptable for an internal-tooling mission.
  • ✅ All acceptance scenarios are defined — 3 stories, 10 scenarios total.
  • ✅ Edge cases are identified — squash-loses-SHAs, 3-way merge-resolution residual, git-probe error, resume window base, strategy flip, first-write vs stale head.
  • ✅ Scope is clearly bounded — 3 workstreams in; #4990 / #4972 explicitly out (C-002).
  • ✅ Dependencies and assumptions identified — builds on the #5012 spine on fix/terminus-merge-integrity.

Feature Readiness

  • ✅ All functional requirements have clear acceptance criteria.
  • ✅ User scenarios cover primary flows — default merge, resume, verdict write.
  • ✅ Feature meets measurable outcomes defined in Success Criteria.
  • ✅ No implementation details leak into specification (see Content Quality note).

Notes

  • This is a brownfield bug-fix mission on internal terminus/merge machinery; per the specify guidance for internal-tooling work, Success Criteria cite the tests/terminus/ red-first harness as the verification surface. That is a verification anchor, not an implementation requirement — the FRs remain behavior-level and the design (blob-attribution algorithm, MergeState fields, resolver reroute) is owned by /spec-kitty.plan.
  • All checklist items pass on the first iteration.