During supervised pickup of origin89hq/firmware#150, the implementation worker created a child Run for the review panel. Launching a reviewer then failed with nested_worker_depth_exceeded (depth 2, max 1, effectsApplied=false). The top-level coordinator launched the panel successfully, but the implementation worker remained bound to its empty child Run.
Subsequent send --to dispatch:<implementation-dispatch> calls succeeded, while the worker repeatedly ran check --terminal <its-handle> --wait and received no guidance. Read-only orchestration inbox --terminal dispatch:<id> showed the messages still unread. Sending a recovery message to the known child Run restored contact; the worker explicitly replied confirming the pending review results and deadline. No second writer or authority takeover was used. Observed with Orca 1.4.211 and engineering snapshot 45507a1.
Update skills/origin89-orca and its supervised pickup guidance so a depth-1 implementation worker asks the parent coordinator to place required review workers before creating a child Run. Document how a worker that already created one reads and acknowledges parent Dispatch guidance without taking over the parent Run. Keep send receipts distinct from recipient replies, and require a communication check after a Run binding changes.
Acceptance: exercise an implementation worker plus review panel under max depth 1; parent guidance sent during review is read, replied to and acknowledged, and all review and implementation Dispatches settle with explicit release. Also exercise the rejected nested-launch recovery path without duplicate workers. This issue tracks the shared workflow correction; the underlying runtime inbox behavior should be reported upstream if its contract is meant to deliver parent Dispatch mail through the child coordinator inbox.
During supervised pickup of origin89hq/firmware#150, the implementation worker created a child Run for the review panel. Launching a reviewer then failed with
nested_worker_depth_exceeded(depth 2, max 1,effectsApplied=false). The top-level coordinator launched the panel successfully, but the implementation worker remained bound to its empty child Run.Subsequent
send --to dispatch:<implementation-dispatch>calls succeeded, while the worker repeatedly rancheck --terminal <its-handle> --waitand received no guidance. Read-onlyorchestration inbox --terminal dispatch:<id>showed the messages still unread. Sending a recovery message to the known child Run restored contact; the worker explicitly replied confirming the pending review results and deadline. No second writer or authority takeover was used. Observed with Orca 1.4.211 and engineering snapshot 45507a1.Update
skills/origin89-orcaand its supervised pickup guidance so a depth-1 implementation worker asks the parent coordinator to place required review workers before creating a child Run. Document how a worker that already created one reads and acknowledges parent Dispatch guidance without taking over the parent Run. Keep send receipts distinct from recipient replies, and require a communication check after a Run binding changes.Acceptance: exercise an implementation worker plus review panel under max depth 1; parent guidance sent during review is read, replied to and acknowledged, and all review and implementation Dispatches settle with explicit release. Also exercise the rejected nested-launch recovery path without duplicate workers. This issue tracks the shared workflow correction; the underlying runtime inbox behavior should be reported upstream if its contract is meant to deliver parent Dispatch mail through the child coordinator inbox.