2.1 KiB
Batch Orchestrator — Future Improvements
Improvements identified during design but explicitly out of scope for the initial implementation.
Live Subagent Streaming
What: Real-time visibility into subagent work as it happens, not just after completion.
Why deferred: Claude Code subagents currently return results only on completion. Live streaming would require changes to the Agent tool or a workaround (e.g., file-watching with periodic reads).
Possible approaches:
- Subagent writes incremental progress to a
.progressfile; orchestrator polls periodically - Future Claude Code feature: streaming subagent output to parent
Cross-Wave Parallelization
What: When Wave 3 Module A completes, start Wave 4 work for Module A while Wave 3 Module B is still running.
Why deferred: Creates complex dependency graphs and merge conflicts on shared output files. The sequential group model is simpler and sufficient for current needs.
Prerequisite: Clear per-module output isolation across phases, not just within a phase.
Automatic Retry on Subagent Failure
What: If a subagent fails (context overflow, tool error), automatically retry with adjusted parameters.
Why deferred: Failure modes need to be observed in practice first before designing retry logic. Current approach: orchestrator reports failure, user decides.
Batch Resume After Interruption
What: If a batch is interrupted (crash, user closes VS Code), resume from where it left off.
Why deferred: task.md checkboxes already track completion. A partial batch leaves some items [x] and others [ ]. Restarting /project:run-batch naturally picks up remaining items. Explicit resume logic adds complexity with little benefit over this natural behavior.
Dynamic Parallelization Hints
What: Allow task.md to contain explicit parallelization overrides beyond the heading-based grouping (e.g., <!-- parallel: false --> to force sequential within a group).
Why deferred: Heading-based grouping covers known use cases. Override syntax adds complexity that may never be needed.