storkit: delete 398_bug_whatsapp_and_slack_missing_async_command_handlers_for_start_rebuild_reset_rmtree_assign

.storkit/work/1_backlog/398_bug_whatsapp_and_slack_missing_async_command_handlers_for_start_rebuild_reset_rmtree_assign.md

@@ -1,33 +0,0 @@
----
-name: "WhatsApp and Slack missing async command handlers for start, rebuild, reset, rmtree, assign"
----
-
-# Bug 398: WhatsApp and Slack missing async command handlers for start, rebuild, reset, rmtree, assign
-
-## Description
-
-The WhatsApp and Slack transports are missing async handlers for several bot commands: start, rebuild, reset, rmtree, and assign. These commands have fallback handlers in chat/commands/mod.rs that return None, with comments stating they are "detected and handled before try_handle_command is invoked". This is only true for the Matrix transport. On WhatsApp and Slack, the fallback returns None, causing the message to fall through to the LLM path instead of executing the intended command.
-
-The reset command is the most impactful — it's supposed to clear the Claude Code session_id so the bot starts a fresh conversation, but on WhatsApp it silently forwards "reset" to the LLM instead. This caused a real outage when switching from Docker to bare-metal: stale session IDs persisted in .storkit/whatsapp_history.json could not be cleared via the bot.
-
-## How to Reproduce
-
-1. Configure the bot with transport = "whatsapp" (Twilio) or "slack".
-2. Send "reset" to the bot via WhatsApp.
-3. Observe the server logs.
-
-## Actual Result
-
-Log shows "No command matched, forwarding to LLM" — the reset command is sent to the LLM as a conversational message instead of clearing the session.
-
-## Expected Result
-
-The bot should clear the sender's session_id from conversation history and reply with a 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
-- [ ] WhatsApp transport handles start, rebuild, rmtree, and assign commands (or returns a meaningful response)
-- [ ] Slack transport handles start, rebuild, rmtree, and assign commands (or returns a meaningful response)
-- [ ] Fallback handlers in chat/commands/mod.rs no longer silently swallow these commands

.storkit/work/1_backlog/399_story_cli_port_flag_with_project_toml_persistence.md

@@ -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.