You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DESIGN — Migrate OMP Native Chat from terminal/transcript to ACP #20
Migrate OMP Native Chat from the existing terminal/transcript-backed implementation to Orca's now-merged structured ACP stack.
This is a migration project, not a new generic-provider project.
The governing invariant is:
For every environment and workflow migrated from legacy OMP Chat to ACP, ACP must preserve or strengthen all existing user-visible and reliability guarantees. Workflows not yet at parity remain explicitly routed to the legacy implementation.
Only after parity is proven do we expand beyond the old feature set by consuming OMP-specific ACP extensions / unknown ACP messages through Orca's extension-message boundary.
Upstream foundation status
The generic infrastructure this project depends on has landed in stablyai/orca/main:
The composed Grok PR stablyai#25225 is still open, but OMP no longer needs to build on that branch: the generic ACP/provider primitives we need are already in upstream main.
Do not let arbitrary extension payloads flow directly into renderer code.
Session identity and migration
A major parity requirement is continuity for existing OMP sessions.
Determine whether the ACP session id/load semantics map directly to the same persisted OMP session store used by the current transcript path.
For an existing OMP Chat session:
preserve the conversation identity;
load the same OMP session through ACP when possible;
replay history exactly once;
preserve current branch/session state supported by ACP;
never fabricate a new conversation merely because Chat transport changed.
If some legacy terminal session cannot be safely adopted by ACP, keep the old path available and report the limitation explicitly.
Reliability
ACP migration must preserve or improve:
one writer per live provider session;
fail-closed process ownership;
no automatic resend of ambiguous user input;
generation-safe cancellation;
exactly-once interaction responses;
replay/live boundary without duplicates;
correct interrupted/stopped tools;
correct session settlement;
provider crash → explicit failed/stopped state;
no stale process/event mutation after replacement.
Remote/mobile scope
Existing support is the floor.
If the current terminal/transcript path works only for a subset of local/runtime cases, ACP may expand support, but must not silently remove a supported path.
If migration reveals an OMP ACP server bug or missing provider semantic, track/fix it in 44madfire/oh-my-pi, linked from the relevant Orca issue. Do not patch provider semantics inside Orca when the bug belongs to OMP.
A provider-side tracking issue exists in the OMP fork for discovered gaps.
Non-goals
no direct OMP RPC structured transport in Orca;
no same-session Terminal↔Chat hot handoff requirement beyond safe persisted-session migration;
no removal of ordinary OMP terminal functionality;
no Pi work in this epic;
no provider-specific renderer plugin surface;
no extension feature expansion before parity is proven.
Acceptance criteria
Every existing terminal/transcript OMP Native Chat guarantee is inventoried.
Native omp acp is registered through the merged generic provider stack.
ACP matches or exceeds the existing Chat path on every required parity row.
Existing OMP sessions migrate/load safely or fall back explicitly.
ACP becomes the default only after parity and reliability gates pass.
OMP-specific ACP extensions are added only after parity.
No direct OMP RPC transport exists in Orca.
Provider-side bugs are fixed in OMP, not papered over in Orca.
Final implementation is suitable for a focused upstream Orca contribution.
The epic is now the execution tracker for this design, with one PR-sized issue per implementation boundary (#22–#30). Each child issue links back here and carries explicit non-goals, dependencies, acceptance criteria, and required tests.
Architecture status update: canonical OMP upstream now contains the compatibility primitives validated by #41 via can1357/oh-my-pi#12900 (6f2233877756b5553ce520756dd90315d2ff6ee3). The shared Pi-family adapter is no longer contingent on a downstream OMP fork.
changed the title [-]DESIGN — Native Pi-family structured sessions over Pi/OMP RPC[/-][+]DESIGN — ACP-first structured Native Chat for OMP and Pi[/+]on Oct 5, 2026
changed the title [-]DESIGN — ACP-first structured Native Chat for OMP and Pi[/-][+]DESIGN — Migrate OMP Native Chat from terminal/transcript to ACP[/+]on Oct 6, 2026
v3 plan applied on #67: existing legacy sessions stay legacy; new OMP chats move to ACP once the provider satisfies orca-native-chat-v1; adoption/handoff moved post-cutover (#69, #84). The ## Child issues section above now lists every v3 unit and the governing invariant is restated.
Decision
Migrate OMP Native Chat from the existing terminal/transcript-backed implementation to Orca's now-merged structured ACP stack.
This is a migration project, not a new generic-provider project.
The governing invariant is:
Only after parity is proven do we expand beyond the old feature set by consuming OMP-specific ACP extensions / unknown ACP messages through Orca's extension-message boundary.
Upstream foundation status
The generic infrastructure this project depends on has landed in
stablyai/orca/main:The composed Grok PR stablyai#25225 is still open, but OMP no longer needs to build on that branch: the generic ACP/provider primitives we need are already in upstream
main.Target architecture
The terminal remains available as an ordinary OMP TUI. The goal is to replace the Chat UI transport, not remove terminal use.
Current OMP ACP capabilities
Current OMP ACP already exposes first-class support for, among other things:
OMP also has provider-specific behaviors/extensions beyond the baseline ACP surface. Those are phase 2, after migration parity.
Parity principle
ACP must not regress behavior merely because the source of truth changes from PTY/transcript to structured protocol.
For every existing OMP Chat behavior, document:
Examples of guarantees to inventory include:
/usage;The parity inventory in #52 is authoritative. Features omitted from that inventory are not implicitly allowed to regress.
Migration policy
Phase A — parity baseline
Add OMP as a registered ACP structured provider, but keep the existing terminal/transcript Chat path as a fallback.
Use feature/capability/version gating so unsupported OMP builds remain on the old path.
Phase B — parity completion
Move each existing behavior onto the ACP path and pin it with regression tests.
ACP becomes default only after all required parity gates pass.
Phase C — ACP-only extensions
After parity:
Do not bypass ACP and fall back to
omp --mode rpcmerely to access a richer provider event.Unknown ACP / extension handling
The merged ACP client already has a forward-compatible extension-message boundary.
Use that boundary deliberately:
Do not let arbitrary extension payloads flow directly into renderer code.
Session identity and migration
A major parity requirement is continuity for existing OMP sessions.
Determine whether the ACP session id/load semantics map directly to the same persisted OMP session store used by the current transcript path.
For an existing OMP Chat session:
If some legacy terminal session cannot be safely adopted by ACP, keep the old path available and report the limitation explicitly.
Reliability
ACP migration must preserve or improve:
Remote/mobile scope
Existing support is the floor.
If the current terminal/transcript path works only for a subset of local/runtime cases, ACP may expand support, but must not silently remove a supported path.
Capability routing should choose:
until the fallback is explicitly retired.
Child issues
Execution tracker: #67 (v3 plan).
Superseded (closed): #21, #52–#59.
Cross-repo boundary
Most work belongs in
44madfire/orca.If migration reveals an OMP ACP server bug or missing provider semantic, track/fix it in
44madfire/oh-my-pi, linked from the relevant Orca issue. Do not patch provider semantics inside Orca when the bug belongs to OMP.A provider-side tracking issue exists in the OMP fork for discovered gaps.
Non-goals
Acceptance criteria
omp acpis registered through the merged generic provider stack.