Checklists

requirements.md

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

Content Quality

  • ✅ No implementation details (languages, frameworks, or internal algorithms)
  • ✅ Focused on user value and business needs
  • ✅ Written for non-technical stakeholders, with storage and transport terms limited to observable safety boundaries
  • ✅ 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
  • ✅ Success criteria are measurable
  • ✅ Success criteria are technology-agnostic
  • ✅ All acceptance scenarios are defined
  • ✅ Edge cases are identified
  • ✅ Scope is clearly bounded
  • ✅ 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 internal implementation design leaks into specification

Notes

  • Physical store boundaries, sender names, and the canonical SaaS refusal are observable acceptance surfaces required to prove the privacy property; the specification does not choose internal modules or algorithms.
  • Pre-spec adversarial review required one canonical consent authority, deny-only global control, exclusive migration cutover, revocation-race evidence, and a separate SaaS write-time boundary; all are explicit.
  • Post-spec adversarial review required one-database transactional coherence, capture epochs, exact-target admission, truthful in-flight settlement, narrowing-only daemon hints, retired legacy writers, old-daemon cutover protocol, split six-project proof, and reproducible benchmarks; all are explicit.
  • Post-plan adversarial review required a connection-owning unit of work, durable admission operations, explicit history disclosure capability, migration-generation writer participation, crash-aware transport attempts, stable admission audience, and monotonic capture sequence; all are explicit.
  • Validation iteration 3: all items pass.