A bug was found mid-session on Maestro's own codebase. The LEAD hand-applied a fix in five minutes. A Maestro crew independently fixed the same bug. The crew's version was more robust — and came with tests.
Maestro's human review gate (mso review approve) has two paths: archive a standalone planning order as COMPLETE, or advance an intra-order review to the next role and re-queue it.
The intra-order path advanced targetRole in the order JSON — but never wrote an ADVANCED event to the runtime ledger (.mso/state/order-ledger.jsonl).
After any mso cleanup or fresh dispatcher session, the ledger still recorded the order at the old role (PLN). Maestro's BUG-0248 advance-loss guard detected the mismatch and reset the order back — re-dispatching PLN instead of BLD. Every cleanup meant another PLN crew rerun.
Under time pressure to unblock a PR, the LEAD (interactive Claude session) hand-applied a fix directly to the voyage branch. Meanwhile, a Maestro crew was dispatched to fix the same bug properly on its own voyage.
Derive from_role from roleSucceededBy.role — the field fleet_runner writes when a role completes. Guard the call with if _prev_role: and skip if absent.
roleSucceededBy absentDerive from_role from roleSequence by finding the predecessor of next_role. Always writes the ledger event — no conditional skip.
roleSucceededByThis isn't about the LEAD being less capable. Under deadline pressure — wanting to unblock a PR — the LEAD made a pragmatic call. The crew, dispatched specifically to fix the bug without the same pressure, had time to reason about data sources, edge cases, and test coverage.
| Dimension | LEAD (solo) | Crew (orchestrated) |
|---|---|---|
| Source for from_role | roleSucceededBy.role | roleSequence index lookup |
| Edge case — field absent | Silently skips write (bug persists) | Always writes event |
| Import style | Top-of-module (clean) | Inline in function (less diff noise) |
| Tests | None | Leopard (TST) writing now |
| Time to implement | ~5 minutes | ~20 minutes |
| Edge case coverage | Partial | Full |
BLD doesn't context-switch into "we need this in 5 minutes" mode. It has one job: implement the fix correctly. That focus consistently surfaces better solutions.
The LEAD skipped tests — not maliciously, but because time pressure pushed coverage aside. The crew's TST role (Leopard) exists specifically to close that gap. It runs whether or not the developer remembered.
Maestro is orchestrated by Maestro. Every improvement to the framework goes through the same PLN → BLD → TST pipeline the framework ships to customers. That's not incidental — it's the validation loop.
The LEAD got something working fast. The crew got something right. With Maestro running in the background, you don't have to choose — the structured pipeline delivers the thorough version while you move on to the next problem.
The test coverage Leopard is writing right now? That's coverage that will catch the next edge case before it ships. The LEAD didn't have time for it. The fleet does.