feat: add oh-my-pi (omp) as a supported harness - #236
Conversation
omp (omp.sh) is a coding-focused fork of Pi with a diverged extension
surface.
- config: new `omp` harness descriptor mirroring pi — InnerCmd `omp`,
BridgeDir `.omp/extensions`, SkillsBase `omp`, UserConfigHome
`.omp/agent`, HomeEnv PI_CODING_AGENT_DIR, SandboxDirs `~/.omp`,
SessionListPi. Paths derive to ~/.omp/agent/{extensions,skills,sessions}.
- bridge: adapted .omp/extensions/omac-bridge.ts for omp's surface —
discovery root `.omp` (not `.pi`), cwd read from the handler ctx
(events carry none), before_agent_start returns systemPrompt as a
string[], and the control-plane fetch is bounded to fit omp's 30s
per-handler cap.
- test: TestOmpHarnessDescriptor + path/session/sandbox derivations, and
TestOmpBridgeInjectsExactlyOneSystemBlock guarding the single
system-block invariant on the omp bridge.
- docs: list omp in HARNESSES.md, MULTI_DIR_DESKTOP.md, README.md and
INSTALLATION.md (launch/resume/bridge/skills tables).
Signed-off-by: Ludwig Kunz <ludwig.kunz@tngtech.com>
94ba4ae to
4d99cec
Compare
|
It would be cool if you could try to make it work via |
I tested this approach and it works. I share the config files I used below. With those omp runs successfully in the omac sandbox. The bridge extension included in this PR is still needed to let omp know about omac for proper integration, but can be included in the local omp installation directly. |
Issue: Closes #235
What
Why
omp is a coding-focused fork of Pi with a diverged extension surface, a different discovery root and event/handler shapes. The existing pi descriptor and .pi/extensions/omac-bridge.ts don't cover it.
How
(internal/bridge/bridge_test.go) guarding the single-system-block invariant on the omp bridge.
Verification
omac start ompstarts correctly.