diff --git a/.storkit/work/1_backlog/397_bug_selection_screen_directory_picker_unreadable_in_dark_mode.md b/.storkit/work/1_backlog/397_bug_selection_screen_directory_picker_unreadable_in_dark_mode.md
deleted file mode 100644
index d66608a2..00000000
--- a/.storkit/work/1_backlog/397_bug_selection_screen_directory_picker_unreadable_in_dark_mode.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-name: "Selection screen directory picker unreadable in dark mode"
----
-
-# Bug 397: Selection screen directory picker unreadable in dark mode
-
-## Description
-
-The ProjectPathInput component in the selection screen uses hardcoded light-theme inline styles (white backgrounds, dark borders, dark text highlights) that don't adapt to dark mode. When the browser/OS uses dark mode, the global CSS sets text color to #f6f6f6 (white) but the dropdown keeps background: #fff — resulting in white text on a white background, making the directory picker completely unreadable.
-
-## How to Reproduce
-
-1. Run storkit under Docker (or locally) with a browser set to dark mode (prefers-color-scheme: dark).
-2. Open http://localhost:3001 in the browser.
-3. Click into the project path input and start typing a path to trigger the autocomplete dropdown.
-
-## Actual Result
-
-The suggestion dropdown has white background with white/light text inherited from the dark-mode global styles. Match highlights use color: #222 which is barely visible. The close button and header bar also use light-only colors. The entire directory picker is effectively unreadable.
-
-## Expected Result
-
-The directory picker dropdown should be readable in both light and dark mode. Colors for background, text, borders, and highlights should adapt to the active color scheme.
-
-## Acceptance Criteria
-
-- [ ] ProjectPathInput dropdown is readable in dark mode (prefers-color-scheme: dark)
-- [ ] ProjectPathInput dropdown remains readable in light mode
-- [ ] Suggestion highlight text is visible against the dropdown background in both themes
-- [ ] No hardcoded light-only colors remain in ProjectPathInput inline styles
diff --git a/.storkit/work/1_backlog/399_story_cli_port_flag_with_project_toml_persistence.md b/.storkit/work/1_backlog/399_story_cli_port_flag_with_project_toml_persistence.md
deleted file mode 100644
index 36953010..00000000
--- a/.storkit/work/1_backlog/399_story_cli_port_flag_with_project_toml_persistence.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-name: "CLI --port flag with project.toml persistence"
----
-
-# Story 399: CLI --port flag with project.toml persistence
-
-## User Story
-
-As a developer, I want to set the server port via a --port CLI flag that persists to project.toml, so that I don't have to remember an environment variable on every run.
-
-## Acceptance Criteria
-
-- [ ] `storkit --help` shows a `--port` option
-- [ ] `storkit --port 4000` starts the server on port 4000
-- [ ] After first run with `--port`, the port is saved to `project.toml`
-- [ ] On subsequent runs without `--port`, the port from `project.toml` is used
-- [ ] CLI `--port` overrides the value in `project.toml`
-- [ ] Default port is 3001 when neither `--port` nor `project.toml` port is set
-- [ ] `STORKIT_PORT` env var is removed — no longer read or respected
-- [ ] `.storkit_port` lock file mechanism is removed (`write_port_file` / `remove_port_file`)
-
-## Out of Scope
-
-- Docker compose changes (can update `STORKIT_PORT` references separately)
-- Adding other CLI flags beyond `--port`
-
-## Technical Notes
-
-Port resolution priority: `--port` flag > `project.toml` `port` field > default 3001
-
-The port should be written to `project.toml` on startup so subsequent runs remember it. Use the existing `config.rs` / `ProjectConfig` struct — add a `port` field.
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
new file mode 100644
index 00000000..3fd015c5
--- /dev/null
+++ b/.storkit/work/1_backlog/400_bug_whatsapp_and_slack_missing_reset_command_handler.md
@@ -0,0 +1,27 @@
+---
+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.
+
+## 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