Define v0.1 product requirements #42

Merged

lost-rob0t merged 2 commits from agent/issue-1-requirements into main

2026-07-18 01:14:46 +00:00

lost-rob0t commented

2026-07-18 00:43:39 +00:00

(Migrated from github.com)

What changed

Added docs/requirements.md as the authoritative v0.1 product specification.
Defined included scope and explicit non-goals.
Defined capture states, including hard-off semantics and the separate explicit query path.
Added functional requirements for capture, metadata, policy, OCR/redaction, encryption/storage, providers, retrieval, controls, retention, backup, and recovery.
Added privacy/security invariants, non-functional requirements, the required data lifecycle, and executable acceptance scenarios.
Made red → green → refactor and honest non-zero test failure propagation normative project requirements.
Linked the requirements document from README.md.

Why

Issue #1 requires a testable source of truth before the threat model, architecture, or implementation begins. This document fixes the boundaries early so later issues cannot silently weaken the off switch, plaintext prohibition, local-first routing, redaction ordering, or TDD rules.

Impact

This is specification-only. No runtime behavior is added. Issues #2 and #3 can now derive threats, controls, interfaces, and architecture from stable requirement IDs and acceptance scenarios.

Validation

Reviewed the branch diff against main.
Confirmed the branch changes only README.md and adds docs/requirements.md.
Confirmed requirement identifiers are unique.
Confirmed pure specification work precedes the executable test harness in issue #4; no production implementation was introduced.

Closes #1

## What changed - Added `docs/requirements.md` as the authoritative v0.1 product specification. - Defined included scope and explicit non-goals. - Defined capture states, including hard-off semantics and the separate explicit query path. - Added functional requirements for capture, metadata, policy, OCR/redaction, encryption/storage, providers, retrieval, controls, retention, backup, and recovery. - Added privacy/security invariants, non-functional requirements, the required data lifecycle, and executable acceptance scenarios. - Made red → green → refactor and honest non-zero test failure propagation normative project requirements. - Linked the requirements document from `README.md`. ## Why Issue #1 requires a testable source of truth before the threat model, architecture, or implementation begins. This document fixes the boundaries early so later issues cannot silently weaken the off switch, plaintext prohibition, local-first routing, redaction ordering, or TDD rules. ## Impact This is specification-only. No runtime behavior is added. Issues #2 and #3 can now derive threats, controls, interfaces, and architecture from stable requirement IDs and acceptance scenarios. ## Validation - Reviewed the branch diff against `main`. - Confirmed the branch changes only `README.md` and adds `docs/requirements.md`. - Confirmed requirement identifiers are unique. - Confirmed pure specification work precedes the executable test harness in issue #4; no production implementation was introduced. Closes #1