[Feature] Add OMP (Oh My Pi) as a runtime + LLM backend

[noizbuster]

Problem

Ouroboros supports Pi (pi) as a runtime + LLM backend, but users of OMP (Oh My Pi, the omp CLI) — a Pi-family coding agent speaking the same JSON event protocol — cannot select their installed CLI as an execution or LLM backend. ouroboros setup --runtime omp and ouroboros config backend omp do not exist, and omp users must install a second agent CLI (pi) just to drive Ouroboros workflows.

Why now

OMP v18 exposes a stable headless JSON surface (omp --mode json) with the same event family as Pi (session / message_update / message_end / turn_end / agent_end), plus native --append-system-prompt, --tools, --no-tools, --resume, and --model flags — everything the existing Pi runtime/adapter contract needs, with only small surface differences.

User / persona

Developers who use Oh My Pi as their daily coding agent and want Ouroboros interviews, Seed execution, and evaluation to run on the same CLI/model configuration they already have.

Current behavior

• orchestrator.runtime_backend: omp is rejected by config validation.
• --llm-backend omp is not an accepted choice for init / mcp serve.
• The installer and setup --runtime enumeration have no omp entry.
• Interactive omp sessions have no managed ooo ... bridge.

Desired behavior

omp is a selectable runtime and LLM backend with the same first-class treatment as Pi: setup wiring, config switching, managed interactive bridge, installer menu entry, docs, and tests.

Proposed solution

Mirror the Pi backend implementation with the omp-specific surface verified against the installed CLI:

• OmpRuntime: omp --mode json <prompt> subprocess runtime — targeted resume via --resume <id> (Pi uses --session), native system-prompt/tool delivery (no capability probe needed; the flags are documented omp CLI surface), tool vocabulary mapping to omp's built-ins (Glob maps to glob as canonical rather than Pi's find; LS maps to glob because omp has no ls built-in), and omission of the generic default model sentinel (omp's --model does fuzzy matching and picks its own configured model).
• OmpLLMAdapter: LLM-only completion over the same JSON mode with cooperative structured-output enforcement, mirroring PiLLMAdapter.
• Managed ooo bridge extension installed to ~/.omp/agent/extensions/ouroboros-ooo-bridge.ts (omp auto-discovers that directory, same layout as Pi's ~/.pi).
• Config/env plumbing: orchestrator.omp_cli_path, OUROBOROS_OMP_CLI_PATH, omp/omp_cli aliases across the registries.

Constraints

• Module-size ratchet: cli/commands/setup.py and config/loader.py are grandfathered and may not grow — omp setup/bridge code lands in new modules.
• omp's --tools validates names at startup (hard CLI error on unknown names), so the tool mapping must only emit documented omp built-ins.
• Untrusted repo .env must not be able to redirect a spawned omp via its agent-dir env (PI_CODING_AGENT_DIR).

Non-goals

• No omp-specific MCP host mode, subagent fan-out, or approval-mode mapping (omp runs headless in JSON mode; permission mode is ignored exactly as for Pi).
• No changes to the Pi backend's behavior.

Alternatives considered

• Reusing the Pi runtime with a config flag: rejected because the resume flag and tool vocabulary differ, and divergent flags behind one class would make both backends harder to reason about.
• Waiting for omp to add --session/find compatibility aliases: rejected — the native omp surface is stable and verifiable today.

Acceptance criteria

• ouroboros setup --runtime omp writes runtime_backend: omp + omp_cli_path and installs the managed bridge into ~/.omp/agent/extensions/.
• ouroboros config backend omp switches backends with omp-specific not-found guidance.
• OmpRuntime executes a task via real omp --mode json, enforces tools=[] with --no-tools, passes system prompt and tool allow-list natively, and resumes via --resume <id>.
• --llm-backend omp works for init / mcp serve, with structured output enforced cooperatively.
• Interactive omp session input ooo ... dispatches through the managed bridge into Ouroboros' shared dispatcher.
• ruff, mypy, module-size gate, and the full pytest suite stay green; omp backend is documented (runtime guide, config reference, capability matrix, READMEs).

References

• Pi backend implementation: src/ouroboros/orchestrator/pi_runtime.py, src/ouroboros/providers/pi_llm_adapter.py, docs/runtime-guides/pi.md
• omp CLI verified surface: omp --help (v18), JSON-mode event stream, --tools validation error's valid-tool list

Checklist

• I searched existing issues and discussions first.
• I explained the problem, not just the solution.
• I included clear scope boundaries and non-goals.
• I listed concrete acceptance criteria.

[ouroboros-agent]

There's already an open PR addressing this: #2299. Review is in progress.

ouroboros-agent[bot]