ADR-0010: Deletion vs Archival of InboxItem

Context

• During processing we must decide whether the original InboxItem is deleted, archived, or left unchanged.
• Users expect both recoverability (undo) and a clean inbox for workflow.

Decision

We will adopt an immediate-deletion policy for the InboxItem when it is processed. The inbox store is intended to be a short-lived capture buffer; once an item has been transformed into a canonical ProcessedItem (or acted upon with Do), the originating InboxItem is removed to keep storage bounded and the inbox minimal.

Rules:

• Processing: after successful creation of any required ProcessedItem (or immediate execution for Do), the corresponding InboxItem MUST be deleted from the inbox store.
• Explicit user Trash performed from the inbox will also delete the InboxItem immediately.
• There is no long-term archival of InboxItem records in the DB; if the product later needs an audit trail, it should be implemented at the ProcessedItem level or via optional export features rather than retaining every raw capture.

Implementation notes:

• InboxItem should remain minimal: id, rawText, capturedAt.
• Undo/recovery for accidental deletions should be provided by a transient UI-level undo stack (ephemeral) rather than persisting archived inbox rows. If a longer retention/undo window is required in future, implement a separate historic-store or opt-in backup/export feature.

Rationale

• Keep storage and schema minimal: the inbox is a transient capture buffer, not an audit log.
• Reduce implementation and operational complexity by avoiding retention/cleanup jobs and archived rows.
• Treat ProcessedItem as the canonical persisted record; if raw capture audit is required later, provide an explicit export or opt-in backup.

Consequences

• Positive:

  • Bounded storage and simpler schema: no archived inbox rows to manage.
  • Simpler processing pipeline and fewer edge-cases in persistence/migrations.
  • Faster inbox queries and smaller local database footprint.

• Downsides:

  • No DB-level archival of raw captures; accidental deletions cannot be recovered from the database after the UI-level undo window expires.
  • Reduced auditability of original raw captures unless additional export/backup features are implemented.

Alternatives Considered

• Soft-archive (keep InboxItem rows with archivedAt) — rejected because it increases storage, requires a cleanup/retention system, and complicates the inbox model.
• Soft-archive with short retention window (e.g., 30 days) — rejected to avoid implementing retention/cleanup and to keep the app storage predictable for users.
• Immediate hard delete without creating a ProcessedItem for Do outcomes — partially acceptable for Do, but for other processed outcomes we still create ProcessedItem and delete the inbox row (this ADR requires deletion after any processing).