story-kit: start 152_bug_ollama_not_running_kills_the_entire_web_ui

.story_kit/work/2_current/149_bug_web_ui_does_not_update_when_agents_are_started_or_stopped.md

@@ -0,0 +1,36 @@
+---
+name: "Web UI does not update when agents are started or stopped"
+---
+
+# Bug 149: Web UI does not update when agents are started or stopped
+
+## Description
+
+Agent start/stop changes are in-memory HashMap mutations in the agent pool. No WatcherEvent is emitted for these changes, so the WebSocket never pushes an update to the frontend. The agent panel only refreshes on its polling interval, meaning agent swaps and new agent starts are invisible until the next poll.
+
+Fix options:
+1. Emit a WatcherEvent (e.g. AgentStateChanged) when start_agent/stop_agent modifies the pool, and have the WebSocket handler forward it to the frontend
+2. Or have the frontend subscribe to a dedicated agent-state WebSocket message type
+
+Key files:
+- server/src/agents.rs: start_agent / stop_agent — where the state change happens
+- server/src/http/ws.rs: WebSocket handler that could forward agent state events
+- frontend/src/components/AgentPanel.tsx: polling-based agent list refresh
+
+## How to Reproduce
+
+1. Open the web UI and look at the Agents panel
+2. Start or stop an agent via MCP (e.g. start_agent or stop_agent)
+3. Observe the Agents panel
+
+## Actual Result
+
+Agent panel does not update until the next polling interval. Starting or stopping agents is invisible in real-time.
+
+## Expected Result
+
+Agent panel should update immediately when agents are started or stopped.
+
+## Acceptance Criteria
+
+- [ ] Bug is fixed and verified

.story_kit/work/2_current/150_bug_qa_2_agent_never_auto_assigned_because_pipeline_stage_only_matches_exact_qa.md

@@ -0,0 +1,63 @@
+---
+name: "qa-2 agent never auto-assigned because pipeline_stage only matches exact qa"
+---
+
+# Bug 150: qa-2 agent never auto-assigned because pipeline_stage only matches exact qa
+
+## Description
+
+The `pipeline_stage()` function in `server/src/agents.rs` (line 154) determines an agent's pipeline role by parsing its **name** — there's no structured `stage` field in the agent config. This means `qa-2` falls through to `PipelineStage::Other` because it doesn't exactly match `"qa"`.
+
+### Root Cause
+
+`project.toml` agent config has `name` and `role` (freetext description), but no `stage` or `pipeline_role` field. The code guesses the pipeline stage from the name:
+
+```rust
+match agent_name {
+    "qa" => PipelineStage::Qa,
+    "mergemaster" => PipelineStage::Mergemaster,
+    name if name.starts_with("coder") => PipelineStage::Coder,
+    _ => PipelineStage::Other,
+}
+```
+
+### The Fix
+
+1. Add a `stage` field to `[[agent]]` in `project.toml` config schema. Valid values: `"coder"`, `"qa"`, `"mergemaster"`, `"other"`.
+2. Update `ProjectConfig` / agent config deserialization in the server to parse the new field.
+3. Replace `pipeline_stage(agent_name)` with a lookup from the agent's config `stage` field.
+4. Update `project.toml` to add `stage` to all agents:
+   - supervisor: `stage = "other"`
+   - coder-1, coder-2, coder-opus: `stage = "coder"`
+   - qa, qa-2: `stage = "qa"`
+   - mergemaster: `stage = "mergemaster"`
+5. Remove the name-based `pipeline_stage()` function entirely. The `stage` field is required.
+
+### Key Files
+- `server/src/agents.rs` line 154: `pipeline_stage()` — name-based matching
+- `server/src/agents.rs` line 1728: `find_free_agent_for_stage()` — uses `pipeline_stage()`
+- `server/src/config.rs` (or wherever `ProjectConfig` is defined): agent config deserialization
+- `.story_kit/project.toml`: agent definitions
+
+## How to Reproduce
+
+1. Have multiple items in `3_qa/`
+2. `qa` agent gets assigned to one
+3. `qa-2` never gets assigned to the others
+
+## Actual Result
+
+`qa-2` is never auto-assigned. `pipeline_stage("qa-2")` returns `PipelineStage::Other`.
+
+## Expected Result
+
+`qa-2` should be recognized as a QA agent and auto-assigned to items in `3_qa/`.
+
+## Acceptance Criteria
+
+- [ ] Agent config in `project.toml` supports a `stage` field (`coder`, `qa`, `mergemaster`, `other`)
+- [ ] `find_free_agent_for_stage` uses the config `stage` field instead of name parsing
+- [ ] `qa-2` is correctly auto-assigned to QA work
+- [ ] `stage` is a required field — server refuses to start if any agent is missing it
+- [ ] The old name-based `pipeline_stage()` function is removed
+- [ ] All existing agents in `project.toml` have `stage` set

.story_kit/work/2_current/152_bug_ollama_not_running_kills_the_entire_web_ui.md

@@ -0,0 +1,29 @@
+---
+name: "Ollama not running kills the entire web UI"
+---
+
+# Bug 152: Ollama not running kills the entire web UI
+
+## Description
+
+The UI fetches Ollama models on load via /api/ollama/models (server/src/http/model.rs line 40). When Ollama is not running, the request fails and the error propagates in a way that kills the whole UI.
+
+The server endpoint at server/src/http/model.rs should return an empty list instead of an error when Ollama is unreachable. Or the frontend should catch the error gracefully and just show no Ollama models in the dropdown.
+
+## How to Reproduce
+
+1. Stop Ollama (or never start it)
+2. Open the web UI
+3. Observe error: Request failed: error sending request for url (http://localhost:11434/api/tags)
+
+## Actual Result
+
+The entire web UI is broken. Nothing works.
+
+## Expected Result
+
+Ollama model fetch should fail silently or show an empty model list. The rest of the UI should work normally with Claude Code or Anthropic providers.
+
+## Acceptance Criteria
+
+- [ ] Bug is fixed and verified