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
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.--configYAML overlay and--[no-]prewalk.OhMyPiDriver.ts,OhMyPiAcpSupport.ts,OhMyPiSessionOptions.ts,OhMyPiSkillDispatch.ts, andOhMyPiAdapter.ts. These are written against V1 orchestration (ProviderCommandReactor), so they are a reference, not something to cherry-pick.Why upstream does not cover it
pi-acpbut not omp.PiAdapterV2) cannot drive omp 18.4.6. The protocols diverged in five places:session_settled, neveragent_settled, so turns andPiTextGenerationhang.get_available_commandsinstead ofget_commands.branchinstead offork.auto_compaction_*events.queuedMessageCountinstead ofpendingMessageCount.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:planSelectionTransition, which is hardcoded inAcpAdapterV2.ts, so toggle changes can returnrestart_session.modelSelectionor launch args passed intomakeRuntimeInput, so the per-thread overlay and--[no-]prewalkreach the process.message.dispatchwithstart_immediatelydoes not consultplanSelectionTransition, so a toggle changed between turns is ignored. An in-adapter relaunch would also work./computer statusreach 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.TraitsPicker'shasAnyControlsignoresbooleanDescriptors(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
buildPiRpcLaunchfor--configand--prewalk, and returnsrestart_sessionfromplanSelectionTransition.PiDriver.snapshotForCwd.sourceInfo.Revisit when reviving
omp skill list <cwd> --jsonnow exists and returns real file paths. A revived ADR should say that skills come fromomp skill listand commands from session reports, which removes the throwaway probe session.--advisoron-flag, but no off flag. Upstream omp could be asked for a--no-advisor/--computerflag pair, or ACP config options, which would make the YAML overlay and the restarts unnecessary.CONTEXT.md(Provider option: "OhMyPi's advisor"; Skill: "OhMyPi's/skill:name") if they still fit.Acceptance
$and/menus