ADR-0001: InboxItem Data Model and Capture Flow

Context

Phase 1 of LocusFlow establishes the core capture mechanism—the foundation upon which all other features are built. Users need a frictionless way to capture thoughts, tasks, notes, and reflections without friction or cognitive overhead. The inbox must serve as a raw input buffer, not a task management system.

Key constraints:

• Local-first architecture with Room database persistence
• Privacy by design (zero network calls)
• Must support future processing and transformation flows
• Balance simplicity (MVP) with extensibility (future phases)

Decision

We will implement InboxItem as a lightweight domain model representing unprocessed user input, stored in a dedicated inbox_items table, with create/read/delete operations exposed through an InboxRepository.

Scope:

• InboxItem contains: ID, content (text), timestamp
• Inbox is ephemeral: items are consumed during processing (Phase 2) and not preserved long-term
• No built-in categorization, prioritization, or status fields—these belong to ProcessedItem
• UI consists of two screens: capture (single input) and list (chronological display)

What is explicitly not covered:

• Item editing (Phase 1 is create/delete only)
• Item archiving or history
• Search or filtering capabilities
• Batch operations

Rationale

• Separation of concerns: InboxItem represents unprocessed input; ProcessedItem (Phase 2) handles clarified, actionable data. This prevents scope creep and maintains clean boundaries.
• Frictionless capture: Minimal required fields (only content) removes barriers to entry. Optional metadata supports richer context without mandating it.
• Optimizing for speed: A simple text field with timestamp allows sub-second capture, critical for ubiquitous capture habits.
• Future-proof transformation: By keeping InboxItem minimal, we avoid premature decisions about processing logic and maintain flexibility for Phase 2's clarification flow.
• Privacy-first: Local persistence with Room ensures