Delete receipts safely or move them to trash #2

Current status — 2026-10-12

Status: Partially implemented. Recoverable trash/restore is the implemented path, with transactional persistence and retained receipt/image evidence.

Completed work/tests: Destructive detail action, confirmation, history/trash separation, restoration, idempotency/revision guards, preserved items/audit/extraction references, and shared-image behavior are covered by persistence tests. PR #37 adds missing-image/trash/read regressions.

Automated evidence: Current main 538b70e passes pnpm check (143 tests in 15 files) and pnpm build; main CI confirms the same revision. Native tests simulate Capacitor boundaries and rendered tests use jsdom.

Remaining development and acceptance:

• Add merchant, date, and amount to the confirmation; the current generic dialog still omits the identifiers required by the original criteria.
• Complete keyboard/focus and German mobile interaction coverage for confirm, cancel, removal from overview/search, and restore. Detail fallback/trash read tests do not cover the full deletion interaction.
• Map transaction failure/rollback and present/missing/shared attachment evidence to every deletion-specific criterion; add missing targeted cases.
• Verify restart, trash/restore, and image retention on the physical Samsung installation.

Keep open. The code implements recoverable trash; no permanent-erasure acceptance is inferred.

Goal

As a user, I want to remove a saved receipt safely without accidental data loss or orphaned files.

Acceptance criteria

• The detail view offers a clearly destructive action.
• Confirmation identifies the merchant, date, and amount.
• Handle the receipt, items, adjustments, payments, attachments, and extraction data consistently.
• Removed receipts disappear from the overview and search.
• A failed operation never leaves a partially deleted record.
• Define and test behavior for images referenced by multiple records.
• Make the flow understandable on mobile and with a keyboard.

Product decision

The code uses recoverable trash. This resolves the earlier choice between permanent deletion and trash; the original confirmation, consistency, failure and interaction criteria still apply.

Constraints and verification

• Database changes must be atomic; schema changes need an explicit SQLite migration.
• Do not trigger material deletion through a generic Save button.
• Test complete deletion or trash state, transaction rollback, and present or missing attachments.

Related follow-up

#39 adds selection and recoverable bulk trash from the overview. It reuses this issue's single-receipt safeguards; it does not replace or waive the outstanding confirmation, consistency and acceptance criteria here.