* Clarify Orca orchestration tool boundary and sidebar lineage
Add a "Tool Boundary" section to the orchestration skill, requiring
explicit Orca runtime state instead of generic subagent tools or
chat-only parallel workers. Also add tests to verify the tool boundary
and clarify sidebar lineage for same-worktree workers.
* Clarify worktree lineage guidance and parent-child boundaries
Update orchestration guidance and tests to clarify when to use child versus
top-level worktree lineages, and when to prefer same-worktree workers.
* Require stating the desired Orca lineage before creating a worktree from
an active feature branch.
* Limit child worktrees to conceptually stacked or dependent tasks.
* Prefer same-worktree workers unless isolated checkouts are explicitly
needed and do not require uncommitted changes.
- Instruct workers to stop and idle or exit immediately after sending
`worker_done`, rather than running a 10-minute polling loop.
- Distinguish instructions based on worker kind: prompt-returning
agents should remain idle for re-engagement, while bare-shell
workers should exit.
- Prevent infinite polling overhead since the coordinator re-engages
workers via fresh terminal input instead of inbox polling.
- Explain that `--no-parent` only controls Orca lineage, not the Git
base branch, and detail how to target independent top-level work.
- Define full handoffs as ownership transfer and forbid the use of
orchestration dispatch injection for them.
- Update CLI help text for `orca worktree create` to reflect the
lineage and base-branch guidance.
- Add tests to verify that these guidance patterns exist in the skill
markdown files.
- Document and update the CLI help, specs, and tests to explicitly guide
users toward `orca terminal create --worktree active --command <agent>`
to launch a fresh agent session in the current checkout.
- Update orchestration and orca-cli skills to prefer active-worktree
terminals when dependent on uncommitted files or active branch state,
distinguishing them from separate worktree creation.
Adds an RPM Linux package target and renames the Linux CLI command to orca-ide to avoid shadowing GNOME Orca, while preserving macOS and Windows CLI command behavior.\n\nFollow-up hardening keeps the Linux launcher executable, removes only old Orca-managed Linux/WSL orca launchers during migration, preserves AppImage/deb artifact names, and updates package/release tests for the RPM asset.
Sharpens the routing boundary so agents reliably pick the right skill:
orchestration owns agent-to-agent messaging (writes that target another
AI agent's terminal), while orca-cli owns worktrees, browser, and
non-agent terminal I/O — including reads and waits on agent terminals.
Validated against adversarial routing tests.
Co-authored-by: Orca <help@stably.ai>
Jinjing
Brennan Benson
Jinwoo Hong
Neil
Emad Fussi