diff --git a/.storkit/work/1_backlog/368_story_web_ui_oauth_flow_for_claude_authentication.md b/.storkit/work/1_backlog/368_story_web_ui_oauth_flow_for_claude_authentication.md
deleted file mode 100644
index 75d3705..0000000
--- a/.storkit/work/1_backlog/368_story_web_ui_oauth_flow_for_claude_authentication.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-name: "Web UI OAuth flow for Claude authentication"
-agent: coder-opus
-retry_count: 2
-blocked: true
----
-
-# Story 368: Web UI OAuth flow for Claude authentication
-
-## User Story
-
-As a new user running storkit in Docker, I want to authenticate Claude through the web UI instead of running `claude login` in a terminal inside the container, so that the entire setup experience stays in the browser after `docker compose up`.
-
-## Acceptance Criteria
-
-- [ ] Backend exposes /auth/start endpoint that generates the Claude OAuth URL with redirect_uri pointing to localhost:3001
-- [ ] Backend exposes /auth/callback endpoint that receives the OAuth token and stores it where Claude Code expects it
-- [ ] Backend exposes /auth/status endpoint that reports whether valid Claude credentials exist
-- [ ] Frontend shows a setup screen when no Claude auth is detected on first visit
-- [ ] Setup screen has a 'Connect Claude Account' button that initiates the OAuth flow
-- [ ] OAuth redirect returns to the web UI which confirms success and dismisses the setup screen
-- [ ] Credentials are persisted in the claude-state Docker volume so they survive container restarts
-- [ ] The entire flow works without any terminal interaction after docker compose up
-
-## Out of Scope
-
-- TBD
diff --git a/.storkit/work/1_backlog/379_bug_start_agent_ignores_story_front_matter_agent_assignment.md b/.storkit/work/1_backlog/379_bug_start_agent_ignores_story_front_matter_agent_assignment.md
new file mode 100644
index 0000000..d58e002
--- /dev/null
+++ b/.storkit/work/1_backlog/379_bug_start_agent_ignores_story_front_matter_agent_assignment.md
@@ -0,0 +1,34 @@
+---
+name: "start_agent ignores story front matter agent assignment"
+---
+
+# Bug 379: start_agent ignores story front matter agent assignment
+
+## Description
+
+When a model is pre-assigned to a story via the `assign` command (which writes `agent: coder-opus` to the story's YAML front matter), the MCP `start_agent` tool ignores this field. It only looks at the `agent_name` argument passed directly in the tool call. If none is passed, it auto-selects the first idle coder (usually sonnet), bypassing the user's assignment.
+
+The auto-assign pipeline (`auto_assign.rs`) correctly reads and respects the front matter `agent` field, but the direct `tool_start_agent` path in `agent_tools.rs` does not.
+
+Additionally, the `show` (whatsup/triage) command should display the assigned agent from the story's front matter so users can verify their assignment took effect.
+
+## How to Reproduce
+
+1. Run `assign 368 opus` — this writes `agent: coder-opus` to story 368's front matter
+2. Run `start 368` (without specifying a model)
+3. Observe that a sonnet coder is assigned, not coder-opus
+4. Run `show 368` — the assigned agent is not displayed
+
+## Actual Result
+
+The `start_agent` MCP tool ignores the `agent` field in the story's front matter and picks the first idle coder. The `show` command does not display the pre-assigned agent.
+
+## Expected Result
+
+When no explicit `agent_name` is passed to `start_agent`, it should read the story's front matter `agent` field and use that agent if it's available. The `show` command should display the assigned agent from front matter.
+
+## Acceptance Criteria
+
+- [ ] start_agent without an explicit agent_name reads the story's front matter `agent` field and uses it if the agent is idle
+- [ ] If the preferred agent from front matter is busy, start_agent either waits or falls back to auto-selection (matching auto_assign behavior)
+- [ ] The show/triage command displays the assigned agent from story front matter when present