story-kit: accept 230_story_prevent_duplicate_stage_agents_on_same_story

.story_kit/work/6_archived/225_story_surface_merge_conflicts_and_failures_in_the_web_ui.md

@@ -0,0 +1,21 @@
+---
+name: "Surface merge conflicts and failures in the web UI"
+---
+
+# Story 225: Surface merge conflicts and failures in the web UI
+
+## User Story
+
+As a user, I want to see merge conflicts and failures surfaced in the web UI, so that I can understand why a story is stuck in the merge stage without having to check server logs or agent output.
+
+## Acceptance Criteria
+
+- [ ] When mergemaster fails to merge a story, the work item in the merge stage shows a visual failure indicator (e.g. red border or error icon)
+- [ ] The failure reason from MergeReport (conflicts, gate failures) is displayed on the work item card or in a detail view
+- [ ] Conflict details (file names, conflict type) are shown when available
+- [ ] Gate output (clippy/test failures) is shown when the merge failed due to quality gates
+- [ ] The failure state persists until the story is retried or moved back to a previous stage
+
+## Out of Scope
+
+- TBD

.story_kit/work/6_archived/226_bug_mergemaster_accepts_stories_without_squash_merging_code.md

@@ -0,0 +1,30 @@
+---
+name: "Mergemaster accepts stories without squash-merging code"
+---
+
+# Bug 226: Mergemaster accepts stories without squash-merging code
+
+## Description
+
+The mergemaster agent moves stories through the pipeline (current → QA → merge → done → accepted) without actually squash-merging the feature branch code into master. Stories 98 and 218 both have code on their feature branches but were accepted with only .md file moves — zero code changes landed on master.
+
+## How to Reproduce
+
+1. Start an agent on a story, let it write code on its feature branch
+2. Move the story through QA → merge stages
+3. Mergemaster runs and "completes" the merge
+4. Check git log — only .md pipeline moves, no squash-merge commit with actual code
+
+## Actual Result
+
+Story is accepted and archived but the feature branch code never lands on master. The mergemaster only commits .md file moves between pipeline directories.
+
+## Expected Result
+
+Mergemaster should squash-merge the feature branch into master, landing all code changes, before moving the story to done/accepted.
+
+## Acceptance Criteria
+
+- [ ] Stories cannot be moved to done unless a squash-merge commit with code changes exists on master
+- [ ] merge_agent_work correctly runs git merge --squash and commits the result
+- [ ] If the feature branch has no code changes (only .md moves), the merge should either fail or warn rather than silently accepting

.story_kit/work/6_archived/229_story_coder_agents_should_check_off_acceptance_criteria_as_they_fulfill_them.md

@@ -0,0 +1,20 @@
+---
+name: "Coder agents should check off acceptance criteria as they fulfill them"
+---
+
+# Story 229: Coder agents should check off acceptance criteria as they fulfill them
+
+## User Story
+
+As a user watching agent progress, I want coder agents to check off acceptance criteria in the story file as they write tests and code to fulfill them, so that I can see real-time progress on the story without reading agent logs.
+
+## Acceptance Criteria
+
+- [ ] Coder agent prompt instructs the agent to use the check_criterion MCP tool after fulfilling each acceptance criterion
+- [ ] Acceptance criteria are checked off individually as work progresses, not all at once at the end
+- [ ] The agent reads the story's acceptance criteria at the start of work via get_story_todos
+- [ ] Checked-off criteria are visible in the web UI pipeline board in real time
+
+## Out of Scope
+
+- TBD

.story_kit/work/6_archived/230_story_prevent_duplicate_stage_agents_on_same_story.md

@@ -0,0 +1,22 @@
+---
+name: "Prevent duplicate stage agents on same story"
+---
+
+# Story 230: Prevent duplicate stage agents on same story
+
+## User Story
+
+As a supervisor, I want start_agent to reject a second coder (or QA, or mergemaster) on a story that already has one running, so that two agents don't operate in the same worktree and corrupt each other's work.
+
+## Acceptance Criteria
+
+- [ ] start_agent rejects a second coder-stage agent on a story that already has a Running or Pending coder, with a clear error message naming both agents
+- [ ] The check covers all non-Other pipeline stages (Coder, Qa, Mergemaster), not just Coder
+- [ ] The check fires for both explicit agent_name requests and auto-selected agents
+- [ ] Auto-assign (auto_assign_available_work) is unaffected — it already has its own is_story_assigned_for_stage guard
+- [ ] Regression test: concurrent start_agent calls with two different coder names on the same story — exactly one succeeds
+- [ ] Regression test: two coders on different stories still works fine
+
+## Out of Scope
+
+- TBD

.story_kit/work/6_archived/231_bug_agent_silently_disappears_when_worktree_creation_fails.md

@@ -0,0 +1,31 @@
+---
+name: "Agent silently disappears when worktree creation fails"
+---
+
+# Bug 231: Agent silently disappears when worktree creation fails
+
+## Description
+
+When `start_agent` spawns its background task and worktree creation fails (e.g. stale branch conflict from a previous worktree at a different path), the agent entry is silently removed from the pool. No ERROR log is written, the UI just shows the agent as idle, and the story sits in current with no agent. The failure is only observable by noticing the agent never appeared.
+
+## How to Reproduce
+
+1. Have a story (e.g. 218) with a branch that's already checked out in a worktree outside .story_kit/worktrees/ (e.g. /private/tmp/story-218-worktree)
+2. Call start_agent for that story
+3. start_agent returns pending successfully
+4. Background task tries to create worktree, git fails with "branch already used by worktree at ..."
+5. PendingGuard or the error handler removes the agent from the pool
+
+## Actual Result
+
+Agent silently disappears from the pool. No ERROR log line. UI shows agent as idle. Story stuck in current with no agent.
+
+## Expected Result
+
+Worktree creation failure should: 1) Log an ERROR with the git error message, 2) Surface the failure in the UI (agent card shows error state), 3) Ideally attempt to recover (e.g. prune stale worktrees or force-checkout)
+
+## Acceptance Criteria
+
+- [ ] Worktree creation failures are logged at ERROR level with the full error message
+- [ ] The agent shows a failed/error state in the UI instead of disappearing
+- [ ] The AgentEvent::Error broadcast is persisted in the agent's event_log so the UI can display it

.story_kit/work/6_archived/232_story_fix_incorrect_bug_tool_descriptions_in_mcp_tools_list.md

@@ -0,0 +1,20 @@
+---
+name: "Fix incorrect bug tool descriptions in MCP tools/list"
+---
+
+# Story 232: Fix incorrect bug tool descriptions in MCP tools/list
+
+## User Story
+
+As an LLM agent consuming the MCP tools/list response, I want the create_bug, list_bugs, and close_bug tool descriptions to reference the correct paths (work/1_upcoming/, work/2_current/, work/5_done/) so that I don't hallucinate a nonexistent .story_kit/bugs/ directory.
+
+## Acceptance Criteria
+
+- [ ] create_bug description says 'Create a bug file in work/1_upcoming/' instead of '.story_kit/bugs/'
+- [ ] list_bugs description says 'List all open bugs in work/1_upcoming/' instead of 'files in .story_kit/bugs/ excluding archive/'
+- [ ] close_bug description says 'Archive a bug from work/2_current/ or work/1_upcoming/ to the done archive' instead of referencing .story_kit/bugs/archive/
+- [ ] Existing MCP tool tests still pass
+
+## Out of Scope
+
+- TBD