story-kit: start 255_story_show_agent_logs_in_expanded_story_popup

.story_kit/work/2_current/250_bug_merge_pipeline_cherry_pick_fails_with_bad_revision_on_merge_queue_branch.md

@@ -0,0 +1,34 @@
+---
+name: "Merge pipeline cherry-pick fails with bad revision on merge-queue branch"
+---
+
+## Rejection Notes
+
+**2026-03-16:** Previous coder (coder-opus) produced zero code changes. The feature branch had no diff against master. Actually fix the bug this time.
+
+# Bug 250: Merge pipeline cherry-pick fails with bad revision on merge-queue branch
+
+## Description
+
+The mergemaster merge pipeline consistently fails at the cherry-pick step with: fatal: bad revision merge-queue/{story_id}. The merge-queue branch is created and the squash commit succeeds, but the branch reference is not accessible during the subsequent cherry-pick onto master. This affects every story that reaches the merge stage — no stories can be automatically merged. The issue is in the git reference handling within the merge pipeline, not a code conflict.
+
+## How to Reproduce
+
+1. Have a completed story in 4_merge/ with a feature branch containing commits ahead of master
+2. Trigger merge_agent_work via MCP or let the mergemaster agent run
+3. Observe the cherry-pick failure
+
+## Actual Result
+
+Cherry-pick fails with fatal: bad revision merge-queue/{story_id}. The merge-queue branch was created and squash commit succeeded, but the branch reference is not found during cherry-pick. Master is untouched.
+
+## Expected Result
+
+The merge pipeline should successfully squash-merge the feature branch into master, run quality gates, move the story to done, and clean up the worktree and branch.
+
+## Acceptance Criteria
+
+- [ ] Use git bisect or git log to find when the merge pipeline broke
+- [ ] Fix the root cause — do not layer on a workaround
+- [ ] Merge pipeline successfully merges a story from 4_merge to master end-to-end
+- [ ] Quality gates run and pass before the merge commits to master

.story_kit/work/2_current/253_bug_watcher_and_auto_assign_do_not_reinitialize_when_project_root_changes.md

@@ -0,0 +1,35 @@
+---
+name: "Watcher and auto-assign do not reinitialize when project root changes"
+---
+
+# Bug 253: Watcher and auto-assign do not reinitialize when project root changes
+
+## Description
+
+When the server starts, if the frontend opens the project at the wrong path (e.g. server/ subdirectory instead of project root), the filesystem watcher and auto-assign run against that wrong path. When the frontend corrects itself by calling DELETE /project then open_project with the right path, the watcher and auto-assign do not reinitialize. This means:
+
+1. The filesystem watcher watches the wrong directory for the entire session
+2. Auto-assign only runs once at startup (against the wrong root) and never re-runs
+3. Stories placed in 2_current/ are never auto-assigned to coders
+4. The archive sweep never fires (same watcher thread)
+
+This is likely the root cause of bug 251 (archive sweep not working) and explains why coders are not being auto-assigned.
+
+## How to Reproduce
+
+1. Start the Story Kit server\n2. Open a project in the frontend — note the first open_project sets project_root to the wrong subdirectory\n3. Frontend corrects by calling DELETE /project then open_project with the correct path\n4. Move a story into 2_current/\n5. Observe that no coder is auto-assigned
+
+## Actual Result
+
+Watcher and auto-assign remain bound to the initial (wrong) project root. No filesystem events are detected for the correct project directory. Stories in 2_current/ are never picked up.
+
+## Expected Result
+
+When project_root changes via open_project, the watcher thread should be stopped and restarted against the new root, and auto_assign_available_work() should re-run.
+
+## Acceptance Criteria
+
+- [ ] When open_project is called with a new path, the filesystem watcher restarts watching the new project root
+- [ ] auto_assign_available_work() re-runs after a project root change
+- [ ] If DELETE /project is called, the watcher stops (no zombie watcher on a stale path)
+- [ ] Stories in 2_current/ are auto-assigned after the project root is corrected

.story_kit/work/2_current/254_story_add_refactor_work_item_type.md

@@ -0,0 +1,22 @@
+---
+name: "Add refactor work item type"
+---
+
+# Story 254: Add refactor work item type
+
+## User Story
+
+As a project owner, I want a refactor work item type so that I can track and assign code restructuring tasks separately from features and bugs.
+
+## Acceptance Criteria
+
+- [ ] create_refactor MCP tool creates a refactor file in work/1_upcoming/ with deterministic filename (e.g. 254_refactor_split_agents_rs.md)
+- [ ] Refactor files use the naming convention {id}_refactor_{slug}.md
+- [ ] Refactor items flow through the same pipeline as stories and bugs (upcoming → current → qa → merge → done → archived)
+- [ ] list_refactors MCP tool lists open refactors in upcoming
+- [ ] Frontend displays refactor items distinctly from stories and bugs (different label/color)
+- [ ] Watcher recognizes refactor files and auto-commits moves like stories and bugs
+
+## Out of Scope
+
+- TBD

.story_kit/work/2_current/255_story_show_agent_logs_in_expanded_story_popup.md

@@ -0,0 +1,15 @@
+---
+name: "Show agent logs in expanded story popup"
+---
+
+# Story 255: Show agent logs in expanded story popup
+
+## Description
+
+The expanded story popup has an "Agent Logs" tab that currently shows "No output". Implement the frontend and any necessary API wiring to display agent output in this tab. This is new functionality — agent logs have never been shown here before.
+
+## Acceptance Criteria
+
+- [ ] Agent Logs tab shows real-time output from running agents
+- [ ] Agent Logs tab shows historical output from completed/failed agents
+- [ ] Logs are associated with the correct story