story-kit: start 210_bug_pipeline_moves_story_to_done_even_when_mergemaster_reports_merge_failure

.story_kit/work/2_current/210_bug_pipeline_moves_story_to_done_even_when_mergemaster_reports_merge_failure.md

@@ -0,0 +1,58 @@
+---
+name: "Pipeline moves story to done even when mergemaster reports merge failure"
+---
+
+# Bug 210: Pipeline moves story to done even when mergemaster reports merge failure
+
+## Description
+
+The pipeline advancement logic ignores the mergemaster agent's `report_merge_failure` call and blindly trusts the server-owned completion's `gates_passed` result. This causes stories to be moved to `5_done/` without their code actually being squash-merged onto master.
+
+## Root Cause
+
+There are two separate gate checks that fire when a mergemaster agent exits, and they check different things:
+
+1. **Server-owned completion** (`agents.rs` ~line 2009-2026): When the agent process exits, the server runs `run_acceptance_gates` in the **agent's worktree**. For the mergemaster, this is the *story worktree* (feature branch), NOT the merge workspace or master. The feature branch code compiles fine, so `gates_passed=true`.
+
+2. **Pipeline advance** (`agents.rs` ~line 1025-1066): The `PipelineStage::Mergemaster` handler sees `gates_passed=true` from the server-owned completion, then runs `script/test` on master. Since the code was never actually merged to master, the existing tests pass. The story is moved to `5_done/`.
+
+The mergemaster agent's `report_merge_failure` MCP call only writes a log line — it has no effect on the pipeline advancement decision. The pipeline never checks whether `merge_agent_work` actually returned `success: true`.
+
+## Impact
+
+Stories 206, 207, 208, and 209 all ended up in `5_done/` or `6_archived/` without their code on master. In the case of 209, the mergemaster explicitly reported that pnpm install failed in the merge worktree, but the pipeline moved the story to done anyway.
+
+## Observed Sequence (story 209)
+
+```
+15:09:06 [mergemaster] Merge failure reported for '209...': pnpm install failed in merge worktree
+15:09:13 [agent:209:mergemaster] Done. Session: Some("7b8931f5-...")
+15:09:23 [agents] Server-owned completion for '209:mergemaster': gates_passed=true   ← WRONG
+15:09:23 [pipeline] Mergemaster completed for '209'. Running post-merge tests on master.
+15:09:38 [pipeline] Post-merge tests passed for '209'. Moving to done.               ← WRONG
+15:09:38 [pipeline] Story '209' done. Worktree preserved for inspection.
+```
+
+## How to Reproduce
+
+1. Have a story in `4_merge/` with a valid feature branch
+2. Cause `merge_agent_work` to fail (e.g. pnpm store corruption, disk space issue, or a complex merge conflict)
+3. The mergemaster agent calls `report_merge_failure` and exits
+4. The server-owned completion runs gates in the story worktree (not master), gets `gates_passed=true`
+5. The pipeline handler runs post-merge tests on master (which pass because no code was merged)
+6. The story is moved to `5_done/` without its code on master
+
+## Actual Result
+
+Story is moved to `5_done/` and the feature branch/worktree are candidates for cleanup, even though the code was never squash-merged onto master. The `report_merge_failure` call is effectively ignored by the pipeline.
+
+## Expected Result
+
+When the mergemaster reports a merge failure via `report_merge_failure`, the pipeline should NOT advance the story to `5_done/`. The pipeline advancement logic for the mergemaster stage should check whether the merge actually succeeded (e.g. by checking for a `report_merge_failure` flag, or by verifying that master HEAD changed, or by skipping server-owned gate checks entirely for mergemaster agents since `merge_agent_work` runs its own gates).
+
+## Acceptance Criteria
+
+- [ ] Server-owned completion gates_passed is not used to advance the pipeline for mergemaster agents when report_merge_failure has been called
+- [ ] A story whose mergemaster reports failure stays in 4_merge/ (not moved to 5_done/)
+- [ ] The report_merge_failure MCP tool sets a flag that the pipeline advancement logic checks before moving a story to done
+- [ ] Add logging that clearly shows when pipeline advancement is blocked due to a reported merge failure