Skip to content

Re-add the OhMyPi provider on Orchestrator V2 #51

Description

@Fryuni

The reset onto upstream Orchestrator V2 dropped the fork's OhMyPi (omp) provider, and its two ADRs went with it because they described code that no longer exists. This issue keeps the decisions and the findings so the provider can come back later.

What was removed

The last fork release before the reset, v0.0.44-fork.20261004.1 (25402caf7), has the full implementation: about 2.4k production lines and 1.4k test lines.

Why upstream does not cover it

  • omp is not in the ACP registry, which lists pi-acp but not omp.
  • Upstream's Pi RPC adapter (PiAdapterV2) cannot drive omp 18.4.6. The protocols diverged in five places:
    • omp emits session_settled, never agent_settled, so turns and PiTextGeneration hang.
    • omp has get_available_commands instead of get_commands.
    • omp has branch instead of fork.
    • omp emits auto_compaction_* events.
    • omp reports queuedMessageCount instead of pendingMessageCount.
  • Pi launch args are static per instance (PiAdapterV2.ts), so ADR 0005's per-thread launch toggles do not fit.

Routes

(a) A dedicated ACP flavor on makeAcpAdapterV2, like Grok and Antigravity. Estimated at 1.5–2k lines. It needs:

  • A flavor hook for planSelectionTransition, which is hardcoded in AcpAdapterV2.ts, so toggle changes can return restart_session.
  • modelSelection or launch args passed into makeRuntimeInput, so the per-thread overlay and --[no-]prewalk reach the process.
  • A fix for the idle-dispatch gap. The Orchestrator's same-instance message.dispatch with start_immediately does not consult planSelectionTransition, so a toggle changed between turns is ignored. An in-adapter relaunch would also work.
  • A prompt-preparation hook for builtin commands. Without it, commands such as /computer status reach omp with the runtime-instructions block appended and print usage instead of running. That finding is from 18.2.7 and was not re-verified.
  • A web fix: TraitsPicker's hasAnyControls ignores booleanDescriptors (TraitsPicker.tsx), so a model with only boolean options shows no traits control.

(b) An omp compatibility variant of upstream's Pi RPC adapter. It aliases the five protocol differences above, adds a per-thread launch hook in buildPiRpcLaunch for --config and --prewalk, and returns restart_session from planSelectionTransition.

  • The fork diff may be smaller, and omp is a Pi fork.
  • The same idle-dispatch gap remains.
  • Pi discovery is machine-level, so project-local omp skills need a new PiDriver.snapshotForCwd.
  • omp skills carry no sourceInfo.
  • Builtin commands are not sent bare.
  • There is drift risk on both the Pi side and the omp side.

Revisit when reviving

  • ADR 0006's premise is obsolete: omp skill list <cwd> --json now exists and returns real file paths. A revived ADR should say that skills come from omp skill list and commands from session reports, which removes the throwaway probe session.
  • omp now ships an --advisor on-flag, but no off flag. Upstream omp could be asked for a --no-advisor / --computer flag pair, or ACP config options, which would make the YAML overlay and the restarts unnecessary.
  • Restore the OhMyPi examples in CONTEXT.md (Provider option: "OhMyPi's advisor"; Skill: "OhMyPi's /skill:name") if they still fit.

Acceptance

  • Choose route (a) or (b) and record it in a new ADR that supersedes 0005 and 0006
  • omp threads start, settle, fork and compact on V2
  • Advisor, computer use and prewalk persist per thread and apply when a session starts
  • Workspace skills and commands appear in the $ and / menus
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-triageMaintainer needs to evaluate this issue

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions