# Native OMP TUI hosts the SPT extension

## Status

superseded by ADR-0009 (2026-07-14) — the native OMP TUI decision remains; the retained RPC-bridge topology does not.

## Context

Issue #2 requires `spt endpoint run --adapter omp-spt ...` to expose the harness PTY. The shipped session command instead made `omp-spt bridge` the PTY leader and launched `omp --mode rpc` behind pipes. Attaching therefore showed bridge logs, while standalone `omp` showed the expected native terminal UI. No attach flag can recover a UI that the hosted process never created.

## Decision

Run native interactive `omp` as `[session.self]` and `[session.resume]`. Load a packaged OMP extension that binds the OMP session to the SPT endpoint, listens for SPT messages, submits each message through `sendUserMessage`, tracks busy/idle state, and dispatches outbound peer messages only through explicit CLI or shortform use.

The former RPC bridge is not a supported endpoint topology; every omp-spt endpoint runs native OMP in a broker-held terminal that remains attachable even while unattended.

<!-- [doc->REQ-OMP-NATIVE-TUI] -->

## Consequences

- `spt rc <id>` and attach-default endpoint bringup display the same native TUI as standalone `omp`.
- SPT delivery is serialized so two inbound messages cannot collapse into one OMP turn; ordinary assistant output remains local.
- Extension code ships under the already-packaged `strings/` directory, avoiding a new archive layout or dependency.
- OMP profile/model flags belong directly on the manifest's `omp` command instead of after the bridge's `--` separator.