Before submitting
Problem
During multi-agent work, the parent Pi session can lose its orchestrator role and execute substantive implementation work inline instead of delegating it to the agent assigned to the relevant branch and Git worktree. This can make the parent write in main, the coordinator worktree, or another agent's worktree, even when independent Herdr worktrees already exist.
This is a coordination-safety bug: the system allows the parent to cross from coordination into implementation without an enforceable ownership boundary.
Steps to reproduce
- Start a Pi session as the parent coordinator in a repository with multiple Herdr workspaces or delegated agents.
- Create or select an independent branch/worktree for a substantive task and delegate that task to a child agent.
- Leave the child agent working or make its status/output temporarily unavailable.
- Continue the parent session with a follow-up implementation request related to the delegated task.
- Observe that the parent can edit files directly from its current working directory instead of routing the work to the delegated branch/worktree.
- Repeat with more than one active worktree or session to observe ownership ambiguity and possible cross-worktree writes.
Expected and actual behavior
Expected:
- The parent remains a coordinator after delegation.
- Every substantive task is bound to one owner, branch, and canonical worktree before implementation.
- Parent writes are limited to coordination artifacts or explicitly parent-owned work.
- The system warns or blocks when a parent attempts to write in
main or in a worktree owned by another agent.
- Cross-worktree path resolution and duplicate writers are detected before changes are made.
Actual:
- The parent can continue with inline implementation after delegation should have occurred.
- This can duplicate work, create changes on the wrong branch, produce concurrent writers, and lose change provenance.
- The failure is especially easy to trigger when several Herdr workspaces are active and the parent has enough context to perform the task directly.
gentle-pi version
3.7.0
Pi version
0.87.1
Operating system
macOS
Relevant logs or error output (optional)
Runtime context observed during investigation:
- Herdr 0.9.0, gentle-shell 3.1.0.
- Multiple Herdr workspaces were active with Pi agents in
idle, working, done, and unknown states.
- Related BC3-Suite history records duplicate sessions and overlapping ownership, cross-worktree autofix behavior, and an explicit requirement that the parent remain coordinator-only.
- The intended lifecycle is:
ticket -> branch -> worktree -> delegated implementation -> work-unit commit -> verification -> PR -> cleanup.
Suggested acceptance criteria:
- Require an explicit delegation record before substantive parent implementation.
- Bind each task to an owner, branch, and canonical worktree.
- Detect and report parent writes outside the assigned worktree.
- Surface duplicate or overlapping writers before changes are made.
- Add regression coverage for parent-versus-delegated worktree ownership, multiple delegated worktrees, stale agent status, and wrong-current-directory resolution.
Before submitting
Problem
During multi-agent work, the parent Pi session can lose its orchestrator role and execute substantive implementation work inline instead of delegating it to the agent assigned to the relevant branch and Git worktree. This can make the parent write in
main, the coordinator worktree, or another agent's worktree, even when independent Herdr worktrees already exist.This is a coordination-safety bug: the system allows the parent to cross from coordination into implementation without an enforceable ownership boundary.
Steps to reproduce
Expected and actual behavior
Expected:
mainor in a worktree owned by another agent.Actual:
gentle-pi version
3.7.0
Pi version
0.87.1
Operating system
macOS
Relevant logs or error output (optional)
Runtime context observed during investigation:
idle,working,done, andunknownstates.ticket -> branch -> worktree -> delegated implementation -> work-unit commit -> verification -> PR -> cleanup.Suggested acceptance criteria: