Checklists

requirements.md

Specification Quality Checklist: CLI Widen Mode & Decision Write-Back

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

Content Quality

  • ✅ No implementation details (languages, frameworks, APIs) beyond contract references
  • ✅ Focused on user value and business needs
  • ✅ Written for non-technical stakeholders
  • ✅ All mandatory sections completed

Notes on contract references: CLI prompt option labels ([w], [a/e/d], [b/c]) and cross-repo endpoint references (#110's POST /decision-points/{id}/widen, #111's Slack discussion fetch surface) are required to define the scope boundary between repos. They are contract-level, not implementation-level.

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 (NFR-001: 300ms, NFR-002: 3s, NFR-003: 30s, NFR-004: 60min reminder)
  • ✅ Success criteria are measurable
  • ✅ Success criteria are technology-agnostic
  • ✅ All acceptance scenarios are defined (primary happy path, continue-on-widen, local-answer-closes-Slack, 10 edge cases)
  • ✅ Edge cases are identified
  • ✅ Scope is clearly bounded (explicit Out of Scope section)
  • ✅ Dependencies and assumptions identified

Feature Readiness

  • ✅ All functional requirements have clear acceptance criteria
  • ✅ User scenarios cover primary flows
  • ✅ Feature meets measurable outcomes defined in Success Criteria
  • ✅ No implementation details leak into specification (beyond required contract references)

Notes

All 22 FRs, 6 NFRs, and 11 Cs are testable and carry status. Discovery resolved:

  • Q1: entry mechanism (D — inline [w], LLM may nudge, human confirms)
  • Q2: pause semantics (C with b default — per-question block/continue choice) + Slack closure (ii — CLI resolves via existing path; SaaS observes terminal state; #111 posts closure)
  • Q3: write-back UX (B refined to [a/e/d]) + architecture correction (local LLM produces candidate, SaaS stores discussion only, provenance tracked in summary.source)

Key architectural rule documented explicitly: SaaS does NOT perform inference in V1. The active CLI LLM session produces candidate summary + candidate answer from SaaS-fetched discussion data. summary_json.source tracks provenance (slack_extraction, mission_owner_override, manual).