Skip to content

DESIGN — Migrate OMP Native Chat from terminal/transcript to ACP #20

Description

@44madfire

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:

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.

Target architecture

Existing
========
OMP terminal process
    ├── PTY input injection
    ├── status hooks
    └── local transcript reader
             ↓
        Native Chat UI

Target
======
StructuredAgentSessionHost
        ↓
registered structured-agent runtime
        ↓
shared managed provider process
        ↓
shared Orca ACP client
        ↓
      omp acp
        ↓
OMP AgentSession/runtime
        ↓
shared ACP → timeline translation
        ↓
Orca journal / Native Chat UI

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:

  • initialize + capability negotiation;
  • authentication methods;
  • session new/load/list/resume/fork/close;
  • replay of stored session history;
  • prompt/cancel lifecycle;
  • images;
  • MCP server configuration;
  • session modes;
  • model/thinking/config options;
  • available slash commands;
  • extension UI via ACP elicitations;
  • Pi/OMP AgentSession event → ACP update mapping.

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:

  1. current terminal/transcript source;
  2. current guarantee;
  3. ACP source/equivalent;
  4. migration test proving equal-or-stronger semantics;
  5. fallback behavior if ACP is unavailable.

Examples of guarantees to inventory include:

  • transcript/history rendering and ordering;
  • reasoning visibility;
  • tool lifecycle and edit cards;
  • model/provider/usage metadata;
  • compaction boundaries;
  • model switching;
  • thinking/session options;
  • slash-command behavior;
  • skills/autocomplete behavior;
  • images/attachments;
  • questions/approvals/interactions;
  • local command behavior such as /usage;
  • turn/status settlement;
  • session resume/restart;
  • mobile projection;
  • supported local/runtime ownership cases;
  • error/failure presentation;
  • no duplicate messages across reconnect/replay.

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:

  • inventory every OMP-specific ACP notification/request/config surface that Orca's generic translator does not yet consume;
  • receive forward-compatible unknown/extension messages through the ACP client's extension boundary;
  • translate useful OMP semantics into existing Orca timeline/control models;
  • add generic Orca ACP primitives upstream where the concept is provider-neutral;
  • keep OMP-only behavior in a narrow OMP ACP dialect.

Do not bypass ACP and fall back to omp --mode rpc merely 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:

standard ACP message
    → generic ACP translator

unknown / OMP extension
    → OMP ACP dialect
         ├── normalize to existing Orca event/control
         ├── expose bounded provider-specific metadata if useful
         └── safely ignore unsupported future extensions

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.

Capability routing should choose:

OMP ACP structured path
        if supported
else
existing terminal/transcript Native Chat path

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

  • 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.

Activity

  1. 44madfire commented on Sep 16, 2026

    @44madfire
    OwnerAuthor

    Implementation epic: #21

    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.

  2. changed the title [-]DESIGN — Native Pi structured sessions directly over upstream `pi --mode rpc`[/-] [+]DESIGN — Native Pi-family structured sessions over Pi/OMP RPC[/+] on Sep 22, 2026
  3. 44madfire commented on Sep 23, 2026

    @44madfire
    OwnerAuthor

    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.

  4. 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
  5. 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
  6. 44madfire commented on Oct 7, 2026

    @44madfire
    OwnerAuthor

    Clean re-plan filed: tracking issue #67, project https://github.com/users/44madfire/projects/3. Work targets the acp-migration branch in each fork (seeded from stablyai/orca@76d1b7b and can1357/oh-my-pi@53f253f). The earlier child issues (#21, #52–#59) and 44madfire/oh-my-pi#8 are superseded by this plan but left open for reference.

  7. 44madfire commented on Oct 7, 2026

    @44madfire
    OwnerAuthor

    The v2 re-plan is applied: execution tracker #67 (project https://github.com/users/44madfire/projects/3). The ## Child issues section above now lists every v2 unit; #21 and #52–#59 are closed as superseded.

  8. 44madfire commented on Oct 8, 2026

    @44madfire
    OwnerAuthor

    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.

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions