[P0] Define product requirements and v0.1 scope #1

New issue

Closed

opened 2026-07-17 23:57:47 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-17 23:57:47 +00:00

(Migrated from github.com)

Goal

Establish the authoritative product and engineering requirements for Local Recall before implementation begins.

Product requirements

Local-first activity recall for Xorg desktop sessions.
Explicit capture states: off, paused, and recording.
Off means no screenshots, metadata collection, OCR, model calls, storage writes, or queued work.
Local models are the default; remote providers are optional and disabled by default.
Sensitive data must be filtered before persistence.
Persisted capture data must always be encrypted.
Wayland support is deferred until after the Xorg MVP.
Users must be able to ask time-scoped questions such as “What was I doing Saturday?”

Engineering invariants

Development is test-driven for the entire project: write a focused failing test first, verify the expected failure, implement the minimum behavior required to pass, then refactor while keeping the suite green.
Every implementation issue must add or update automated tests for its acceptance criteria before production behavior is considered complete.
A passing test run is valid only when the intended tests were discovered and executed.
Assertion failures, collection errors, fixture/setup/teardown failures, crashes, signals, timeouts, empty required test selections, and subprocess failures must produce a non-zero exit status.
No wrapper, script, task runner, CI setting, or exception handler may convert a failed test condition into exit status 0.
Required tests may not be disabled, skipped, marked expected-failure, or weakened merely to obtain a green build.
Bug fixes begin with a regression test that reproduces the defect.
Security and privacy invariants require unit, integration, and end-to-end coverage where their boundaries differ.

Deliverables

docs/requirements.md
Defined v0.1 use cases and explicit non-goals.
Functional and non-functional requirements.
Documented TDD workflow and test-integrity invariants.
Acceptance checklist for the MVP.

Acceptance criteria

Requirements are testable rather than aspirational.
Privacy and off-switch behavior are written as hard invariants.
The red → green → refactor workflow is mandatory for feature and bug work.
Test failure propagation and zero-test behavior are specified explicitly.
Future features are separated from v0.1 scope.

## Goal Establish the authoritative product and engineering requirements for Local Recall before implementation begins. ## Product requirements - Local-first activity recall for Xorg desktop sessions. - Explicit capture states: `off`, `paused`, and `recording`. - Off means no screenshots, metadata collection, OCR, model calls, storage writes, or queued work. - Local models are the default; remote providers are optional and disabled by default. - Sensitive data must be filtered before persistence. - Persisted capture data must always be encrypted. - Wayland support is deferred until after the Xorg MVP. - Users must be able to ask time-scoped questions such as “What was I doing Saturday?” ## Engineering invariants - Development is test-driven for the entire project: write a focused failing test first, verify the expected failure, implement the minimum behavior required to pass, then refactor while keeping the suite green. - Every implementation issue must add or update automated tests for its acceptance criteria before production behavior is considered complete. - A passing test run is valid only when the intended tests were discovered and executed. - Assertion failures, collection errors, fixture/setup/teardown failures, crashes, signals, timeouts, empty required test selections, and subprocess failures must produce a non-zero exit status. - No wrapper, script, task runner, CI setting, or exception handler may convert a failed test condition into exit status 0. - Required tests may not be disabled, skipped, marked expected-failure, or weakened merely to obtain a green build. - Bug fixes begin with a regression test that reproduces the defect. - Security and privacy invariants require unit, integration, and end-to-end coverage where their boundaries differ. ## Deliverables - `docs/requirements.md` - Defined v0.1 use cases and explicit non-goals. - Functional and non-functional requirements. - Documented TDD workflow and test-integrity invariants. - Acceptance checklist for the MVP. ## Acceptance criteria - Requirements are testable rather than aspirational. - Privacy and off-switch behavior are written as hard invariants. - The red → green → refactor workflow is mandatory for feature and bug work. - Test failure propagation and zero-test behavior are specified explicitly. - Future features are separated from v0.1 scope.