Part of the fork v2 worker-lifecycle redesign. Depends on #2 (lifecycle states); the isolated-report fields arrive with #4.
Context
The orchestrator currently holds all chunk state in its own context: which children are running, which await review, which iteration each is on. That's bookkeeping prompts are bad at, and it doesn't survive context compaction. Practitioner evidence: Chacon found "having some shared task list that several or dozens of long running agents can hack away at is very difficult," and community parallel-agent users report logging agent actions to a database because "you lose track of what happened fast." Beads builds a full dependency-graph issue tracker for this — deliberately out of scope here; a single orchestrator needs a ledger, not a work graph.
Iteration count doubles as a churn signal: a child on its fourth revision usually means the chunk was mis-drawn, not that the child is slow.
Proposal
- Persist a small JSON state sidecar per task (alongside the existing task files): id, slug/title, status (
running | awaiting-review | closed), iteration count, branch, worktree path, spawned-at, configured checks.
- New parent tool
list_agents returning the ledger — readable by the orchestrator mid-orchestration and by the user for debugging.
- Result payload enrichment (when isolated): branch name, worktree path, and
git diff --stat <base>...HEAD — the orchestrator's review starts from mechanics, not the child's self-description.
Acceptance criteria
Sources
Part of the fork v2 worker-lifecycle redesign. Depends on #2 (lifecycle states); the isolated-report fields arrive with #4.
Context
The orchestrator currently holds all chunk state in its own context: which children are running, which await review, which iteration each is on. That's bookkeeping prompts are bad at, and it doesn't survive context compaction. Practitioner evidence: Chacon found "having some shared task list that several or dozens of long running agents can hack away at is very difficult," and community parallel-agent users report logging agent actions to a database because "you lose track of what happened fast." Beads builds a full dependency-graph issue tracker for this — deliberately out of scope here; a single orchestrator needs a ledger, not a work graph.
Iteration count doubles as a churn signal: a child on its fourth revision usually means the chunk was mis-drawn, not that the child is slow.
Proposal
running|awaiting-review|closed), iteration count, branch, worktree path, spawned-at, configured checks.list_agentsreturning the ledger — readable by the orchestrator mid-orchestration and by the user for debugging.git diff --stat <base>...HEAD— the orchestrator's review starts from mechanics, not the child's self-description.Acceptance criteria
list_agentsreflects live status transitions, including iteration increments per reportSources