diff --git a/.storkit/work/1_backlog/400_bug_whatsapp_and_slack_missing_reset_command_handler.md b/.storkit/work/1_backlog/400_bug_whatsapp_and_slack_missing_reset_command_handler.md deleted file mode 100644 index 0fc8931c..00000000 --- a/.storkit/work/1_backlog/400_bug_whatsapp_and_slack_missing_reset_command_handler.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -name: "WhatsApp and Slack missing reset command handler" ---- - -# Bug 400: WhatsApp and Slack missing reset command handler - -## Description - -The reset command has a fallback handler in chat/commands/mod.rs that returns None with a comment saying it's handled before try_handle_command. This is only true for Matrix. WhatsApp and Slack don't have pre-dispatch handling, so None causes fallthrough to LLM. This caused a real outage when stale session IDs couldn't be cleared via the bot after switching from Docker to bare-metal. - -## Implementation Note - -Follow the **rebuild pattern** established in story 402, with one complication: `handle_reset` in `server/src/chat/transport/matrix/reset.rs` takes a Matrix-specific `ConversationHistory` (`Arc>>`), so it cannot be called directly from WhatsApp or Slack. - -**WhatsApp session storage** (`server/src/chat/transport/whatsapp.rs`): -- Type: `WhatsAppConversationHistory = Arc>>` (key = sender phone number) -- Persisted to `.storkit/whatsapp_history.json` via `save_whatsapp_history` - -**Slack session storage** (`server/src/chat/transport/slack.rs`): -- Type: `SlackConversationHistory = Arc>>` (key = channel ID) -- Persisted to `.storkit/slack_history.json` via `save_slack_history` - -**Approach:** -- Use `extract_reset_command` from `server/src/chat/transport/matrix/reset.rs` to detect the command (it works transport-agnostically) -- Implement the reset inline in each transport's async message handler: clear `session_id` and `entries` for the sender/channel key, call the transport's own `save_*_history`, reply with confirmation -- Add async intercepts in `whatsapp.rs` (~line 1107, after the rebuild intercept) and `slack.rs` (~line 845, after the rebuild intercept) -- The fallback handler in `chat/commands/mod.rs` (`handle_reset_fallback`) stays as-is - -## How to Reproduce - -1. Configure bot with transport = "whatsapp" or "slack"\n2. Send "reset" to the bot\n3. Check server logs - -## Actual Result - -Log shows "No command matched, forwarding to LLM" — reset is sent to the LLM as a conversational message instead of clearing the session. - -## Expected Result - -The bot clears the sender's session_id from conversation history and replies with confirmation like "Session cleared." - -## Acceptance Criteria - -- [ ] WhatsApp transport handles reset command: clears sender session_id and replies with confirmation -- [ ] Slack transport handles reset command: clears channel session_id and replies with confirmation -- [ ] Fallback handler in chat/commands/mod.rs no longer silently swallows the reset command