[Gastown] Convoy dependency enforcement bypassed: beads dispatched despite failed merge requests #2014
Description
What happened?
Convoy "Create Shared Base Image for Code-Capable Agents" (4abd175d) has 4 beads with dependency edges: bead 3 depends on beads 1 and 2, bead 4 depends on all previous beads.
Beads 1 and 2 both had FAILED merge requests, yet beads 3 and 4 were still dispatched and marked as closed/in_progress. The dependency system should have held beads 3 and 4 until their dependencies successfully merged into the convoy's feature branch.
Evidence:
- Bead 1 (f3358fca): marked "closed" but no branch exists locally or remotely, no Dockerfile.dev file exists anywhere
- Bead 2 (94f86f24): marked "closed" but merge request failed
- Bead 3 (19411e57): dispatched and committed despite depending on failed beads 1 and 2
- Bead 4 (a6449eb0): currently in_progress despite depending on failed beads
- Convoy head branch does not exist on remote — nothing was integrated
- Merge mode is "review-then-land" which requires successful review/merge of each bead before proceeding
The convoy proceeded as if all beads succeeded, leaving the feature branch in a broken state with missing files.
Area
Convoys
Context
- Town ID: cdcd4cc2-55b1-423c-80e4-4c773c86cd2b
- Agent: Mayor (270ecf9c-958b-4c15-8df3-4c836a119e2a)
- Rig ID: cb113c7e-be44-42bc-b0cc-1765156962ea
Filed automatically by the Mayor via gt_report_bug.