PR Architecture Summary: Edit and Regenerate Message History (Issue #511)

*Disclaimer: This Pull Request and summary were structurally generated and organized by an AI Assistant.

---

High-Level Objective

This PR implements the "Edit and Regenerate" feature for message history, allowing users to modify an existing message mid-thread and seamlessly rewind the conversational context to branch off from that point.

Explicit Architectural Choices

1. State Isolation (useMessageEdit.ts) Instead of ballooning useMainAppLayoutSurfaces or useThreads with transient UI state for hovering, editing, and prompt validations, we created a dedicated hook useMessageEdit.ts. This encapsulates text mutation, image retention, UI transition states (idle, editing, confirming, regenerating), and validation guards natively.

2. Frontend Reducer Action (truncateThreadItems) Truncation of orphaned thread items (any downstream context succeeding the edited turn ID) was explicitly wired into useThreadsReducer.ts. The UI optimistically and cleanly prunes these items leveraging afterItemId immediately following a successful network rollback, prior to sending the new generation request. It utilizes the existing thread hierarchy invariants safely.

3. Backend / Daemon Parity Following backend routing rules, the new rollback_thread command traverses all necessary stacks cleanly:

   • Added rollback_thread_core in src-tauri/src/shared/codex_core.rs.
   • Wired the tauri endpoint using the frontend IPC standard src/services/tauri.ts.
   • Covered JSON-RPC proxy endpoints for the headless Daemon in src-tauri/src/bin/codex_monitor_daemon/rpc/codex.rs.
   • Handles the remote_backend remote switch logic properly within src-tauri/src/codex/mod.rs.

4. UI/UX Aesthetics & Design System Reuse Rather than introducing a global top-level modal for editing logic, the message edit menu and confirmation warning inject conditionally via MessageRows.tsx. All CSS builds purely upon existing tokenized primitives (--surface-accent, --cm-surface-panel-strong, etc.) avoiding drift and duplicated components as outlined in the AGENTS.md guidelines.

Areas of Consideration / Potential Concerns

• Concurrent Execution / Double Submit Guards: The useMessageEdit disables interactable elements via an isRegenerating state guard. In addition, the controller (useThreadMessaging.ts) double-checks threadStatusById[threadId]?.isProcessing to prevent an incoming rollback while a background thought is actively polling.
• Rollback Failures: Currently, if rollbackThreadService(...) throws an error on the Rust backend, the subsequent truncateThreadItems action is bypassed, and the UI will push a standard generic Error Message into the chat stream via pushThreadErrorMessage. This prevents local desync where the UI wipes out items but the database retains them, guaranteeing server authority.
• Image handling over edits: Images present in previous prompts are automatically extracted, buffered in EditState, and re-attached dynamically into the new regenerated payload without requiring the user to manually re-upload them.
• Legacy "any" Cleanups: Addressed implicit/explicit typing where applicable. For example, rollback_thread and archive_thread IPC services return strictly typed invoke<void> instead of invoke<any>.