diff --git a/.storkit/work/1_backlog/401_bug_whatsapp_and_slack_missing_start_command_handler.md b/.storkit/work/1_backlog/401_bug_whatsapp_and_slack_missing_start_command_handler.md
deleted file mode 100644
index 0b09f2c0..00000000
--- a/.storkit/work/1_backlog/401_bug_whatsapp_and_slack_missing_start_command_handler.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-name: "WhatsApp and Slack missing start command handler"
----
-
-# Bug 401: WhatsApp and Slack missing start command handler
-
-## Description
-
-The start command has a fallback handler in chat/commands/mod.rs that returns None. Only Matrix has pre-dispatch handling for this command. On WhatsApp and Slack, the command falls through to the LLM path.
-
-## Implementation Note
-
-Follow the **rebuild pattern** established in story 402.
-
-- `extract_start_command` and `handle_start` already exist in `server/src/chat/transport/matrix/start.rs`
-- Add an async intercept in `server/src/chat/transport/whatsapp.rs` (see rebuild intercept ~line 1107) and `server/src/chat/transport/slack.rs` (see rebuild intercept ~line 845)
-- Call `crate::chat::transport::matrix::start::extract_start_command` to detect the command, then `crate::chat::transport::matrix::start::handle_start` to execute it
-- The fallback handler in `chat/commands/mod.rs` (`handle_start_fallback`) stays as-is — it exists only so `help` lists the command
-
-## How to Reproduce
-
-1. Configure bot with transport = "whatsapp" or "slack"\n2. Send "start <story_id>" to the bot\n3. Check server logs
-
-## Actual Result
-
-Command falls through to LLM instead of starting an agent.
-
-## Expected Result
-
-The bot starts an agent for the specified story and replies with confirmation.
-
-## Acceptance Criteria
-
-- [ ] WhatsApp transport handles start command: starts agent and replies with confirmation
-- [ ] Slack transport handles start command: starts agent and replies with confirmation
diff --git a/.storkit/work/5_done/399_story_cli_port_flag_with_project_toml_persistence.md b/.storkit/work/5_done/399_story_cli_port_flag_with_project_toml_persistence.md
new file mode 100644
index 00000000..36953010
--- /dev/null
+++ b/.storkit/work/5_done/399_story_cli_port_flag_with_project_toml_persistence.md
@@ -0,0 +1,31 @@
+---
+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.