Three separate traps hit during one dispatch wave on 2026-08-01. All present as opaque failures that cost a worker seat its budget or an operator a debugging cycle. Grouped because each fix is a better error message plus a guard.
1. brigade creates an outcome ledger in a nested subdirectory without complaint
Run 20260801-184731-c3c933c1 dispatched the grok seat to do Go work under stations/notify/. The seat timed out after 900s, and its changes.patch contains exactly two new files, both wrong:
stations/notify/memory/outcome/.records.lock
stations/notify/memory/outcome/records.jsonl
The seat ran brigade commands with cwd inside stations/notify/, and brigade initialized a fresh outcome ledger there rather than resolving to the repo root or refusing. A ledger inside a Go station directory is never correct. Requested: resolve the outcome ledger to the target/repo root, or refuse with a bounded error naming the resolved root, when invoked from a nested directory that is not itself a configured target.
2. A missing interpreter is reported as a rejected receipt, not a missing interpreter
brigade work verify run --command "python -m pytest ..." is rejected before pytest starts on any machine that has only python3 on PATH. The result reads as an infrastructure/rejected receipt with no obvious cause. In run 20260801-182926-facaecff this contributed directly to a seat's confusion and the loss of the run (receipt 20260801-190656). Requested: name the missing interpreter in the error and suggest the available one (python3).
3. repo-metadata CI fails with a bare exit code when the command inventory is stale
Adding a CLI subcommand without regenerating docs/command-inventory.md fails the repo-metadata job with ##[error]Process completed with exit code 1. The actual cause (roadmap_command_inventory_current: docs/command-inventory.md missing or stale) is buried in the step log. This hit two independent PRs in one day (#645 adding outcome repair, #649 adding runs audit). Requested: surface the stale-file name and the regeneration command in the job's failure output.
Also worth checking
Every run in this wave logged warning: dag scheduler: plan not fully covered; falling back to wave scheduler. Either plan coverage is genuinely incomplete for ordinary plans or the coverage check is too strict; the fallback is silent enough that nobody would notice the DAG scheduler is effectively never used.
Context and evidence: .claude/memory-handoffs/2026-08-01-orchestration-failure-record.md.
Three separate traps hit during one dispatch wave on 2026-08-01. All present as opaque failures that cost a worker seat its budget or an operator a debugging cycle. Grouped because each fix is a better error message plus a guard.
1.
brigadecreates an outcome ledger in a nested subdirectory without complaintRun
20260801-184731-c3c933c1dispatched thegrokseat to do Go work understations/notify/. The seat timed out after 900s, and itschanges.patchcontains exactly two new files, both wrong:The seat ran brigade commands with cwd inside
stations/notify/, and brigade initialized a fresh outcome ledger there rather than resolving to the repo root or refusing. A ledger inside a Go station directory is never correct. Requested: resolve the outcome ledger to the target/repo root, or refuse with a bounded error naming the resolved root, when invoked from a nested directory that is not itself a configured target.2. A missing interpreter is reported as a rejected receipt, not a missing interpreter
brigade work verify run --command "python -m pytest ..."is rejected before pytest starts on any machine that has onlypython3on PATH. The result reads as an infrastructure/rejected receipt with no obvious cause. In run20260801-182926-facaecffthis contributed directly to a seat's confusion and the loss of the run (receipt20260801-190656). Requested: name the missing interpreter in the error and suggest the available one (python3).3.
repo-metadataCI fails with a bare exit code when the command inventory is staleAdding a CLI subcommand without regenerating
docs/command-inventory.mdfails therepo-metadatajob with##[error]Process completed with exit code 1. The actual cause (roadmap_command_inventory_current: docs/command-inventory.md missing or stale) is buried in the step log. This hit two independent PRs in one day (#645 addingoutcome repair, #649 addingruns audit). Requested: surface the stale-file name and the regeneration command in the job's failure output.Also worth checking
Every run in this wave logged
warning: dag scheduler: plan not fully covered; falling back to wave scheduler. Either plan coverage is genuinely incomplete for ordinary plans or the coverage check is too strict; the fallback is silent enough that nobody would notice the DAG scheduler is effectively never used.Context and evidence:
.claude/memory-handoffs/2026-08-01-orchestration-failure-record.md.