add `z` to undo archive actions

[dexhorthy]

Problem to solve / Expected Behavior

Sometimes i accidentally archive a session with e and i want to undo it

Proposed solution

enable archiving recently archived sessions with z

open question - how long do we track "last action" - maybe like 60s?

out of scope

if any are relevant, other types of undo need a more thoughtful approach...e.g. I don't think we'll ever implement "unsend message"

[dexhorthy]

@smorin wanna grab this?

[smorin]

Research Published: Understanding Archive Functionality for Undo Feature

📋 TLDR

The system uses a simple boolean flag for archiving without history tracking. While no undo infrastructure exists, the codebase has strong patterns for optimistic updates, time-based state tracking, and keyboard shortcuts that can support implementing undo functionality with the 'z' key.

🔍 Key Findings

• Archive functionality uses a boolean flag without timestamps or history tracking
• The 'e' key handler is implemented in React with context-aware behavior and confirmation flows
• Existing optimistic update patterns with rollback provide a template for undo implementation
• Time-based state tracking patterns exist for automatic expiration (60-second window)
• The 'z' key is currently unused and keyboard infrastructure is ready for undo shortcuts

❓ Open Questions

1. How long should the system track "last action"? Issue suggests 60 seconds.
2. Should undo work across different UI contexts (list vs detail view)?
3. Should the system support undoing multiple archive operations or just the most recent?
4. Should undo capability survive page refresh or session restart?
5. How should undo work for bulk archive operations?
6. What UI patterns should indicate an action is undoable?
7. Should recent actions be stored in memory, localStorage, or database?

💡 Recommendations

1. Start with Memory-Based Undo Stack (Option 1) - simplest implementation using existing Zustand store
2. Implement 60-Second Undo Window - leverage existing time-based cleanup patterns
3. Support Single-Action Undo Initially - focus on most recent archive action only
4. Add Visual Feedback with Toast Notification - display "Undo" button for 5 seconds
5. Extend Optimistic Update Pattern - add manual trigger alongside automatic error rollback
6. Plan for Future Backend Enhancement - keep undo logic abstracted in store layer

📄 Full Research

View the complete research document: https://gist.github.com/smorin/de3f108e7e2e246e6178419d33a8e65e

---

Research conducted on 2025-08-22 | Commit: 2880cae

[dexhorthy]

Undo Window Duration: How long should the system track "last action"? Issue suggests 60 seconds.

60 seconds is fine

Undo Scope: Should undo work across different UI contexts (list vs detail view)?

yeah anywhere you can archive from, you can undo

Multiple Undo: Should the system support undoing multiple archive operations or just the most recent?

yeah if you archive a bunch in a row we should support undoing a bunch in a row (subject to 60s window)

Persistence: Should undo capability survive page refresh or session restart?

ehhh we can skip that for now I think? @balanceiskey do you think its worth pushing the undo stack into localstorage???

Bulk Operations: How should undo work for bulk archive operations?

one undo undoes the whole batch

User Feedback: What UI patterns should indicate an action is undoable?

we could do a "undo" button on the "session archived" toast

Storage Strategy: Should recent actions be stored in memory, localStorage, or database?

since only 60 seconds, it can just be stored in frontend memory for now...we can make this more sophisticated later I think? @balanceiskey wdyt

meta feedback - this PR comment is way too long - i did not read any of it, just opened and read the research. If you already have a long doc I'm not also gonna read a long comment. suggest adjusting prompts to encourage very terse comments ( a few bullets max) + link to doc. Leaving open questions verbatim on the comment probably useful for quoting purposes

[dexhorthy]

i think this is ready for plan but let me get sundeep eyes on it too

[balanceiskey]

Definitely down to just do in-memory zustand for now, tracking as a lastAction attribute of some kind makes sense, putting it in Zustand makes it more immediately testable.