Research: global undo and redo for reversible app actions #330

Why

Pasted has several local safety mechanisms—Trash, clip revisions, reset previews, recovery backups, and transactional mutations—but no single way to reverse an ordinary action. Adding isolated Undo behavior to individual screens would produce inconsistent rules and duplicate state management.

A global Undo and Redo model could make experimentation safer across clips, Bins, Settings, and other user-authored state while preserving familiar desktop shortcuts.

Research question

What shared mutation contract would let Pasted safely undo and redo explicit user actions without pretending that background capture, external side effects, or destructive recovery operations are ordinary reversible edits?

Scope to evaluate

• Inventory meaningful mutations across clips, revisions, Bins, Settings, transformations, and organization.
• Classify each mutation as directly reversible, reversible through retained state or a snapshot, or intentionally irreversible.
• Define action grouping, labels such as “Undo Move to Bin,” coalescing, redo invalidation after a new action, and behavior across windows.
• Decide whether history is session-scoped or durably bounded across relaunches, including crash recovery and schema migration.
• Define Command/Ctrl-Z and Command/Ctrl-Shift-Z precedence so native text-editing history wins while editing a field.
• Separate database state from operating-system integration, files, clipboard writes, imports, restores, asynchronous analysis, and other external effects that must not be replayed accidentally.
• Determine how the shared Rust service and data contract apply to the GUI and CLI, including any intentional live-app boundary.
• Bound storage and ensure history, Activity, logs, and errors do not expose clipboard contents, credentials, sensitive paths, or private values.

Expected outcome

• A recommended architecture and mutation contract, including transaction and failure semantics.
• A supported-action matrix with explicit exclusions.
• A recommendation for session-only versus durable history and an appropriate retention bound.
• Focused implementation issues ordered from a small useful first slice toward broader coverage.

Constraints

• Undo and Redo must use the same domain mutations and validation as the original actions, not parallel GUI-only behavior.
• Background clipboard capture is not an implicit user edit and must not unexpectedly enter the stack.
• Permanent deletion, Full Restore, factory reset, and similar recovery boundaries retain explicit confirmation and recovery semantics unless research proves a safe integration.
• Imported or replayed history must never repeat external actions.
• A failed undo or redo must leave durable state transactionally unchanged and keep the history understandable.

Follow-up to #251.