fix(orchestration): don't steal active-tab focus when a director spawns a worker via the CLI

[zaridan]

The bug (CLI→IPC focus-steal gap #29 missed)

An in-app Orcastrator (Smart director) spawns each worker by running orca worktree create --agent … from its own terminal. In the CLI create handler, any --agent forced activate: true:

activate: flags.get('activate') === true || flags.get('run-hooks') === true || Boolean(startupAgent),

That flowed activate: true → worktree.create RPC → createManagedWorktree's shouldActivate → notifyActivateWorktree → ui:activateWorktree IPC → renderer setActiveWorktree, switching the user's active tab to every new worker as the director created it.

#29 added suppressActivation to the in-app renderer launch functions, but never covered this CLI → IPC path.

The fix — auto-suppress when the create originates from a director worktree

When orca worktree create runs from within an Orcastrator/director worktree (the director spawning a worker), the agent/run-hooks-derived activation is suppressed: activate: false is sent, so notifyActivateWorktree is simply never called. The worktree is still created, its agent spawned, and revealed in the sidebar + Mission Control — only the active-tab switch is skipped.

• Normal (non-director) origin → still activates, exactly as today.
• Explicit --activate → overrides the suppression (still activates).

Which layer & why

CLI layer — the smallest change that reuses the existing main-side shouldActivate gate with no IPC/renderer changes and no focus-steal because notifyActivateWorktree isn't called. The CLI is also the only layer that can distinguish an explicit --activate from the derived --agent/--run-hooks activation, which is required for the override rule.

Director identity is the durable worktree displayName prefix "Orcastrator · " (the same restart-surviving marker the sidebar uses to reattach directors). It's moved to src/shared/orchestrator-identity.ts so the CLI and renderer share one constant. The CLI already resolves the originating worktree from cwd for lineage; that same lookup now also reports whether the origin is a director — no extra round-trip.

Tests (fail without the fix)

In src/cli/index.test.ts:

• Director origin + --agent → activate: false but still created/revealed (this one fails on main).
• Normal origin + --agent → activate: true (no regression).
• Director origin + --agent --activate → activate: true (explicit override wins).

Verification

typecheck ✓ · pnpm test (20504 passed; the only failures were 2 flaky node-pty-fd-leak native tests that pass in isolation, unrelated) ✓ · oxlint on changed files ✓ · build:cli + electron-vite build ✓

🤖 Generated with Claude Code

[zaridan]

Revision: close the --no-parent --repo coverage gap

The first pass computed originIsOrchestrator only inside the cwd parent/repo-inference block (gated by (!explicitParentWorktree && !explicitParentWorkspace && !noParent) || needsCwdRepoInference). The real /orcastrate pattern spawns workers parent-less (parent=None) with an explicit --repo, which skips that block — so originIsOrchestrator stayed false and the focus-steal still happened.

Fix: the suppression decision is now independent of the parent/repo gate. Whenever activation would be derived (--run-hooks / --agent) and --activate was not explicitly passed, the cwd worktree context is resolved to determine director-ness. It reuses the context already resolved by the gated block when that ran; otherwise it does one extra resolveCurrentWorktreeContext call — guarded so there's no extra RPC on the common non-agent create path.

Added tests: --no-parent --repo --agent from a director cwd → activate:false; the same from a normal cwd → activate:true. All existing CLI tests stay green (134 total).