[Gastown] Polecats fail to execute in rig (0 commits across 22 dispatch attempts) — worktrees not provisioned for freshly-created rigs? #4139

What happened?

Polecats cannot execute in rig — zero output across 22 dispatch attempts

Town a219e417-ca4c-4365-814c-052ee9629495, rig 1b7e72d6-9b16-4c14-a164-e1f405bf55a1 (repo markusdi/hongelong_cyclebeacon).

What's happening

Every polecat dispatch in this rig fails silently — agents are dispatched, briefly flip beads to in_progress, then release them back to open (or the bead is marked failed after 5 attempts) without producing any work. No commits, no branches, no checkpoints, no PRs.

Evidence

• Agent dispatch_attempts: Toast=11, Maple=6, Birch=5 → 22 total dispatch attempts.
• Output produced: ZERO. git ls-remote --heads origin shows only 4 branches, all pre-existing (master + 3 claude/* from prior merged PRs). No convoy/crosseval/feature branch was ever created. No new PRs.
• No checkpoints on any agent (none got far enough to persist state).
• A 5-bead convoy ("KryssCase — issue App Builder - Add session-based message pagination #3", convoy 5de245a3) had 4 of 5 beads fail after 5 dispatch attempts each; the 5th was force-closed. All failed beads have dispatch_attempts: 5, last_dispatch_attempt_at ~13:53–14:06, marked failed ~14:07.
• A fresh standalone probe re-sling (bead 4554c4f3, assigned to Toast) dispatched once at 14:07:57, flipped to in_progress, reverted to open within ~90s — same failure pattern.

Likely cause / context

• Both rigs in this town were created today (2026-06-20). The rig's checked-out working tree was empty (only .git, 0 files) until I manually ran git checkout master from the mayor context. This suggests the polecat worktree/container may not be properly provisioned/checked out, so polecats start but cannot establish a working repo state.
• Tooling IS present in the mayor context (bun 1.3.14, node, gh authenticated) — so it's not a global tooling outage; it appears specific to polecat execution/provisioning in this rig.
• I cannot see polecat stdout/stderr (the failure reason is not surfaced in bead/agent state), so the root cause isn't directly observable from the mayor side.

What I tried (recovery)

1. Attempted to reopen a failed bead via gt_bead_update status=open → rejected (bead stayed failed). Confirmed re-sling is the recovery path.
2. Force-closed the dead convoy and re-slung the foundation as a standalone probe → failed identically.
3. Re-slingging is the documented recovery, but it has now failed 22 times — this is beyond what re-slinging can fix.

Impact

No code work can be delegated or executed in this rig. The entire issue-#3 implementation (and any future work) is blocked until polecat execution works.

Expected behavior

Polecats should be able to dispatch, establish a working checkout of the rig's repo on a feature branch, do the work, commit, and call gt_done — instead of silently failing with zero output.

Suggested investigation

• Verify polecat worktree/container provisioning for freshly-created rigs (the empty working tree on first inspection is a red flag).
• Surface polecat dispatch/run errors in bead or agent state so the mayor (and user) can see why a dispatch failed, not just that it did.

Area

Agent Dispatch / Scheduling

Context

• Town ID: a219e417-ca4c-4365-814c-052ee9629495
• Agent: Mayor (42ac5ab5-9f77-44d2-8550-b9e5150c1e35)
• Rig ID: 1b7e72d6-9b16-4c14-a164-e1f405bf55a1

Recent Errors

22 total dispatch_attempts across 3 polecats (Toast=11, Maple=6, Birch=5), 0 commits/branches/PRs/checkpoints produced. Beads flip open→in_progress→open (or fail after 5 attempts). Failed beads cannot be reopened via gt_bead_update. Rig created today (2026-06-20); working tree was empty until manual checkout.

Filed automatically by the Mayor via gt_report_bug.