spec: bulk delete chat history (#10359)

[lonexreb]

Summary

Spec-only PR proposing multi-select and bulk-delete affordances for
the conversation list, with a 5-second undo window after each bulk
delete (matching macOS Finder's "Recover" semantics).

Resolves intent of #10359.

What's in this PR

• specs/GH10359/SPEC.md — full behavior contract, keyboard map,
  acceptance criteria, tests, telemetry plan, and open questions.

No code changes. This PR is for spec review only.

Highlights

• Selection mode entered via a "Select" header button or row
  context menu, with checkbox + Cmd-click + Shift-click semantics.
• Single confirmation for bulk delete that ALWAYS prompts —
  even when the per-row skip-confirmation preference is set —
  because the blast radius is larger.
• 5-second undo snackbar, modeled on macOS Finder's "Recover"
  pattern. Within the window, deletions are reversible; after, they
  are permanent.
• Full keyboard parity: Space, Shift+Arrow, Cmd/Ctrl+A,
  Cmd/Ctrl+Shift+A, Delete, Esc.
• Active-conversation refocus so deleting the active row in a
  batch lands cleanly on the next-most-recent conversation.
• No persisted selection across restarts; pending deletions
  commit on shutdown so there are no zombie undo affordances.

Telemetry

No new event. Extends the existing conversation.delete event with
count, bulk, and undone fields. Bulk events fire after the
undo window closes so undone is always known.

Triage request

Requesting ready-to-implement once Q1 (Preview-channel feature
flag) and Q4 (server-side batch endpoint vs client fan-out) are
resolved.

Test plan

• Spec reviewed by a conversation-list maintainer.
• Spec reviewed by a storage-layer maintainer to confirm the
  tombstone-window approach is acceptable.
• Open questions Q1–Q4 resolved before promoting to
  ready-to-implement.

[oz-for-oss]

@lonexreb

I'm starting a first review of this spec-only pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This spec proposes conversation-list multi-select, bulk delete, undo, keyboard coverage, storage changes, tests, and telemetry. The scope is appropriate for the issue, but several requirements remain ambiguous or unresolved enough to risk an incorrect or unsafe implementation.

Concerns

• The scope and implementation contract for Select all is ambiguous, especially with active filters/search and virtualized rows.
• The storage/API decision for bulk delete is still open and the client fan-out proposal does not define failure, retry, atomicity, or undo semantics.
• The skip-confirmation wording is internally inconsistent and the fixed 5-second undo window needs accessibility requirements.

Security

• Client-side fan-out for an unbounded bulk destructive action needs explicit limits or failure semantics so a single user action cannot create unbounded work or partially committed destructive state.

Verdict

Found: 0 critical, 2 important, 2 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] Define whether Select all means all conversations globally, all conversations matching the active filter/search, or all currently loaded conversations, and require how the exact count/IDs are computed before confirmation.

[oz-for-oss]

💡 [SUGGESTION] This says the skip-confirmation preference is respected and then ignored; rewrite to say single-row deletes keep the preference while bulk deletes always confirm.

[oz-for-oss]

💡 [SUGGESTION] If the undo window stays fixed at 5 seconds, add accessibility requirements for keyboard focus, screen-reader announcement, and whether users who miss the snackbar have any alternate recovery path.

[oz-for-oss]

⚠️ [IMPORTANT] [SECURITY] Client-side fan-out for bulk deletion leaves partial failure, retry, cancellation, and undo consistency undefined; resolve Q4 with bounded batch semantics or a server-side API contract before implementation.