From 56c979c9508bc95f92f7fa4632994e38ea4407a2 Mon Sep 17 00:00:00 2001 From: dave Date: Mon, 27 Apr 2026 10:50:44 +0000 Subject: [PATCH] config: tell mergemaster to use 5-min sleeps between merge_agent_work polls MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Real cause of mergemaster turn-burnout: not merge conflicts, just polling overhead. The server-side tool_merge_agent_work IS designed to block until the merge completes, but the MCP client times out after 60s. The agent then polls get_merge_status, with 30-60s sleeps between polls — each poll cycle costs 2 turns (sleep + tool call). The merge takes 5-10 min for a clean run, so the agent burns 10-20 turns just waiting. Updated workflow tells mergemaster: - 'operation timed out' is normal, do NOT immediately re-call (would queue a duplicate merge) - Use Bash sleep 300 (one 5-min wait = 1 turn) between polls - Cap at 3 polls = 15 minutes total, plenty for any clean merge - Reserve turns for actual fix-up work if gates fail Combined with the earlier 30→60 turn / $5→$15 budget bump, this should land any merge with no real conflicts in 3-5 turns total. Plenty of headroom remaining for genuine gate-fix work. --- .huskies/agents.toml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/.huskies/agents.toml b/.huskies/agents.toml index 8d5715f9..c8fb0bc2 100644 --- a/.huskies/agents.toml +++ b/.huskies/agents.toml @@ -232,11 +232,12 @@ prompt = """You are the mergemaster agent for story {{story_id}}. Your job is to Read CLAUDE.md first, then .huskies/README.md for the dev process, .huskies/specs/00_CONTEXT.md for what this project does, and .huskies/specs/tech/STACK.md for the tech stack and source map. ## Your Workflow -1. Call merge_agent_work(story_id='{{story_id}}'). It blocks until the merge completes and returns the full result. -2. If success and gates passed: you're done. Exit. -3. If gates failed: read the gate_output carefully, fix the issues in the merge workspace at `.huskies/merge_workspace/`, run run_tests MCP tool to verify, recommit, and call merge_agent_work again. -4. If merge failed for any other reason: call report_merge_failure(story_id='{{story_id}}', reason='
') and exit. -5. After 3 failed fix attempts, call report_merge_failure and exit. +1. Call merge_agent_work(story_id='{{story_id}}'). The server-side tool blocks until the merge completes, BUT the MCP client times out after 60s. If you get "operation timed out" or status="running", that is normal — the server is still working in the background. Do NOT immediately re-call merge_agent_work; that just queues a duplicate. Instead, follow Step 2. +2. If the call timed out OR returned status="running": call Bash with `sleep 300` (one 5-minute sleep = one turn). Then call get_merge_status once. Repeat up to 3 times (15 minutes total). The merge pipeline takes 5-10 minutes for a clean merge (frontend npm build + cargo build + cargo test + clippy). DO NOT poll faster than every 5 minutes — short polls just burn your turn budget without giving the pipeline time to make progress. +3. If get_merge_status eventually returns success: you're done. Exit. +4. If gates failed: read the gate_output carefully, fix the issues in the merge workspace at `.huskies/merge_workspace/`, run run_tests MCP tool to verify, recommit, and call merge_agent_work again. +5. If merge failed for any other reason: call report_merge_failure(story_id='{{story_id}}', reason='
') and exit. +6. After 3 failed fix attempts, call report_merge_failure and exit. ## Fixing Gate Failures