feat(agent-org): support per-member mixed execution runtimes #1588

Problem / Motivation

Agent Org already supports independent provider/model/account selection for each Rust-native Member, but it cannot currently mix execution runtimes per Member.

The desired configuration is:

• Implementer → Codex CLI
• Reviewer → Claude Code CLI
• Tester → Rust-native SDE with its own provider/model/account
• Coordinator → Rust-native in the first delivery phase

Provider selection and execution runtime are different concerns. A provider chooses which model/account a Rust-native agent calls; a CLI choice changes the process and lifecycle that executes the Member. The codebase recognizes references such as cli:codex and cli:claude_code, but Agent Org deliberately hides and rejects them because external CLI Sessions do not yet participate in the complete team inbox, Task, wake, intervention, and recovery lifecycle.

Simply exposing the existing CLI options would create Members that appear to launch but cannot reliably claim, acknowledge, or settle Agent Org work. It would also overload agentId with both role identity and runtime identity, causing an Implementer switched to Codex CLI to lose its Agent Definition prompt, tool policy, and role semantics.

Proposed Solution

Deliver mixed-runtime Agent Org as a phased architectural feature, separate from the direct Member routing bug fix in #1580.

1. Separate Member role identity from execution runtime:
   • Keep the Agent Definition as the source of role prompt, capabilities, and policy.
   • Add an explicit runtime kind such as Rust-native or external CLI.
   • For external CLI, persist the CLI agent type such as Codex or Claude Code.
2. Initially support external CLI Workers while keeping the Coordinator Rust-native.
3. Materialize CLI Member Sessions with the stable Session ID reserved by Agent Org so launch retry and application restart converge without duplicate Members.
4. Add a server-owned Agent Org bridge for CLI Members:
   • Derive run, Session, and Member identity from trusted backend context.
   • Do not trust a model-supplied Member ID.
   • Expose the required Task, team messaging, completion, and approval operations with the same authorization rules as Rust-native Members.
5. Connect formal wakes, team inbox delivery, exact receipt acknowledgement, and Task input materialization to CLI turns.
6. Make CLI Members participate in the complete lifecycle:
   • Formal Task claim/start/complete/fail
   • Direct user intervention and Return
   • Failed-message retry
   • Stop/cancel and late-event fencing
   • Crash/restart recovery without duplicate settlement
7. Only expose Codex CLI and Claude Code in the Agent Org Member runtime picker after their backend capability is available.
8. Preserve existing Agent Org definitions by defaulting legacy Members to Rust-native execution.

Alternatives Considered

• Reuse agentId = cli:codex or cli:claude_code: rejected because it conflates the Member's role with its execution engine and loses the selected Agent Definition's prompt and policy.
• Treat CLI as another provider: rejected because provider choice does not supply external-process lifecycle, inbox consumption, Task tools, or recovery.
• Enable CLI for Coordinator and Workers together: deferred because Coordinator authority and team orchestration increase the first delivery slice substantially. A Rust-native Coordinator with CLI Workers is a safer first complete state.
• Unhide the existing frontend selector and remove backend guards: rejected because it would expose a knowingly incomplete and unsafe execution path.

Acceptance Criteria

• Agent Org Member definitions store role identity and execution runtime as separate concepts.
• Existing definitions remain compatible and continue to launch as Rust-native Members without migration surprises.
• A single Agent Org can run a Codex CLI Implementer, Claude Code Reviewer, and Rust-native SDE Tester concurrently.
• Selecting a CLI runtime preserves the Member's Agent Definition prompt, role, capability, and tool policy.
• CLI Member creation is idempotent and uses the stable Session ID reserved by Agent Org.
• CLI Member launch retry and application restart do not create duplicate Sessions or duplicate Task attempts.
• Formal team inbox messages and Task inputs wake and materialize into the intended CLI Member exactly once.
• Task and team tools invoked by a CLI Member use backend-bound run/Session/Member identity and cannot impersonate another Member.
• CLI Members can claim, start, complete, fail, and report formal Tasks with the same receipt guarantees as Rust-native Members.
• Direct user work remains on the selected CLI Member, waits for explicit Return, and then resumes the exact formal Task continuation once.
• Failed direct-message retry remains owned by the original CLI Member and never falls through to the Coordinator.
• Stop, cancel, provider/CLI failure, late events, and restart converge without duplicate acknowledgement or settlement.
• Root canonical chat, Group Chat, @mention, and Rust-native-only Agent Orgs retain their existing behavior.
• Deterministic tests cover identity authority, inbox/receipt semantics, Task lifecycle, retry, intervention/Return, cancellation, and restart recovery.
• A rendered packaged-app E2E proves a real mixed team using actual Codex CLI, Claude Code CLI, and a real-provider Rust-native SDE Member.

Additional Context

This gap was identified while fixing direct Member model/account ownership and routing in #1580. It should remain a separate stack because it introduces new runtime modeling, trusted tool authority, cross-session scheduling, and lifecycle/recovery contracts.

Relevant current code areas include:

• Agent Org definition validation and runtime references
• Agent Org launch/materialization
• CLI Session creation and finalization
• Agent Org wake and inbox drain
• CLI-to-Agent-Core tool bridge
• Member runtime selector

Recommended delivery sequence:

1. Runtime model and backward-compatible definition contract
2. Stable CLI Member materialization plus trusted inbox/Task bridge
3. Intervention, retry, cancellation, and restart convergence
4. UI enablement and real mixed-runtime E2E