feat(runtime): add Pi through ACP

[Yevanchen]

Area

Runtime

Problem

Mosoo currently exposes Claude Agent SDK, OpenAI Runtime, and OpenCode, but not Pi. Builders who prefer Pi's coding harness cannot select it for Preview or published Agent workloads even though Mosoo already has a reusable ACP Driver backend.

Pointing MOSOO_ACP_FALLBACK_COMMAND at Pi is not a product integration: the public acp-fallback runtime is labeled and configured as OpenCode, and the Driver image currently selects OpenCode globally. Replacing that command would remove OpenCode and make persisted runtime identity, capability reporting, and UI labels inaccurate.

Pi is available to ACP clients through the pi-acp adapter, which bridges ACP JSON-RPC over stdio to Pi's RPC mode. The missing work is therefore runtime admission and configuration, not another ACP protocol implementation.

References:

• Pi ACP adapter
• Pi in the ACP agent catalog
• Current Mosoo runtime catalog: pkgs/runtime-catalog/catalog/runtime-catalog.jsonc
• Current shared ACP backend: apps/driver/src/runtimes/acp/

Proposal

Add Pi as a separate public runtime backed by pi-acp, while reusing the existing ACP Driver backend and event translation.

Keep the first version narrow:

• Preserve acp-fallback as the existing OpenCode runtime; give Pi its own stable runtime identity and selectable Driver descriptor.
• Let each ACP-backed runtime select its executable and arguments through the Driver registry/start configuration instead of the current process-global fallback command.
• Pin a compatible pi-acp + Pi version pair in the Driver image and verify both binaries during image build.
• Render Pi's provider/model configuration non-interactively from the frozen Mosoo execution spec. Provider calls must continue through Mosoo's model-bound LLM proxy; raw provider credentials must not enter the Sandbox.
• Declare an evidence-based Pi capability profile. Do not advertise MCP execution, separate thinking streams, usage, resume, or other capabilities until the pinned adapter proves them. Unsupported Agent configurations should fail readiness with an actionable blocker, not during the first prompt.
• Surface Pi as a distinct runtime in the catalog and Web runtime/model availability flow.

Do not add a Pi-specific event translator unless the shared ACP backend has a measured contract gap that cannot be fixed once at the ACP boundary.

Acceptance criteria

• An App Owner with a supported provider credential can choose Pi, create an Agent, run Preview, and publish it.
• The same image continues to run OpenCode unchanged; selecting Pi never repoints or relabels acp-fallback.
• Pi passes contract coverage for session startup, text streaming, tool activity/file changes, permission handling, cancellation, terminal success/failure, and stop cleanup.
• Pi native session refs are scoped to the Pi runtime and cannot be resumed by OpenCode (or vice versa).
• Provider/model selection is deterministic and all model traffic uses the existing expiring LLM proxy grant path.
• The published capability profile matches fixture evidence; unavailable MCP/thinking/usage/resume behavior is blocked or visibly degraded rather than silently claimed.
• At least one live provider path passes the public runtime E2E gate, alongside a credential-free ACP fixture/contract test.
• Runtime catalog, architecture/current-availability docs, Driver image pins, and release-gate tests are updated together.

Alternatives considered

• Reuse acp-fallback by changing its command: rejected because it replaces OpenCode instead of adding Pi and breaks the meaning of existing runtime IDs.
• Integrate Pi's private RPC mode directly: defer unless pi-acp cannot satisfy Mosoo's production contract; it would create a second protocol/event adapter to maintain.
• Embed the Pi SDK in the Driver: larger dependency and lifecycle surface than launching the existing ACP adapter.

Compatibility and migration

This should be additive. Existing Agents and Sessions keep their current runtime IDs and native resume refs. No existing OpenCode identity should be renamed or migrated. The adapter and Pi versions must be exact-pinned because pi-acp currently warns that minor breaking changes are possible.

Contribution

I can provide product feedback.

Checklist

• I searched existing issues before opening this request.
• I described the problem before the proposed solution.
• I kept this request focused on one improvement.