{
  "summary": "# Decision ledger\n\n## Executive finding\n\nThe repository does not yet have a coherent OMP-native decision system. `docs/adr/0007-native-omp-tui-hosts-spt-extension.md` is the only accepted ADR that directly governs the current OMP architecture. `CONTEXT.md`, `SCOPE.md`, ADRs 0001–0006, most of `docs/KNOWN-HAZARDS.md`, and all but one requirement in `traceable-reqs.toml` still describe the source `claude-spt` product. Some of that lineage is reusable, but the documents do not distinguish inherited history from current omp-spt commitments. As a result, old Claude decisions can be mistaken for live OMP requirements, while implemented OMP behaviors have no decision or traceability record.\n\nThe highest-order live decision is: **is `plugin/omps` an intentional Claude Code control surface for the OMP adapter, or inherited residue that should leave an OMP-only product?** This must be answered before grilling naming, hooks, setup, hazards, tests, or distribution, because it changes the applicability of most inherited commitments.\n\n---\n\n# LOCKED — do not re-ask\n\n1. **Public-contract-only development is a hard constraint.** `SCOPE.md:20-23` says the adapter is built from `SaberMage/spt-releases` and published pages, never spt-core source. `OMP-ADAPTER-PLAN.md` carries that discipline into its validation section. This is still applicable.\n\n2. **Interactive hosted endpoints must run native OMP as the PTY leader.** Accepted ADR-0007, especially `docs/adr/0007-native-omp-tui-hosts-spt-extension.md:5,13-15`, decides that `[session.self]` and `[session.resume]` run `omp`, not the RPC bridge. `adapter/omp-spt.toml` symbols `[session.self]` and `[session.resume]` implement this with `omp --extension …/omp-spt.mjs` and `omp -r {session_id} --extension …`. Do not re-open “bridge logs versus native TUI.”\n\n3. **The packaged OMP extension, not a terminal proxy, supplies SPT integration for interactive endpoints.** ADR-0007 locks bind/listen/state/reply through OMP’s public extension API while OMP owns rendering. `adapter/strings/omp-spt.mjs::ompSpt` is the implementation.\n\n4. **RPC remains a headless integration surface, not the interactive endpoint host.** ADR-0007:15 explicitly retains the old bridge for explicitly headless callers. `OMP-ADAPTER-PLAN.md:47-72` now states the same split: Style A headless, Style B interactive.\n\n5. **Inbound interactive delivery is serialized.** ADR-0007:22 locks that two inbound messages cannot collapse into one OMP turn or receive the wrong reply. `omp-spt.mjs` realizes this with `queue`, `current`, `agentActive`, and `dispatchNext`.\n\n6. **OpenRouter billing is OMP configuration, not adapter code.** `OMP-ADAPTER-PLAN.md:132-153` and `docs/OMP-OPENROUTER.md:1-6` lock the boundary: document `models.yml`, `.env`, role routing, and fallback behavior; do not add provider logic to the adapter.\n\n7. **OMP’s transcript is adapted to the neutral SPT digest record contract.** `OMP-ADAPTER-PLAN.md:90-102` fixes the source and output model; `tools/claude-spt/src/digest_omp.rs` implements `digest-omp`; `[digest].extractor` invokes it. The exact old Claude extractor design should not be re-litigated.\n\n8. **The OMP adapter currently has no shipped ccs profile overlay.** This is explicitly enforced by `tests/manifest-shortcut.sh` (“no shipped profile overlays”) and explained in `adapter/omp-spt.toml` immediately before `[strings]`: ccs was Claude-specific and OMP uses native provider/profile configuration. This is consistent with the OMP plan and should be treated as a completed port decision unless the root product-boundary question intentionally retains a separate Claude surface.\n\n9. **Current concrete identity values are implemented and regression-guarded:** adapter/release identity `omp-spt`, executable `omp-spt`, update repo `BigscreenVR/omp-spt`, host binaries `omp` and `omp-spt`, shortcut basename `omp`. Evidence: `adapter/omp-spt.toml` `[adapter]`/`[update]`, `tools/claude-spt/Cargo.toml` `[[bin]]`, `ci/publish/package-adapter.sh`, and `tests/manifest-shortcut.sh`. The values are not all supported by an OMP naming ADR, so their *rationale* needs documentation, but asking “what does the code currently call this?” is unnecessary.\n\n10. **Bridge startup must complete OMP `ready` + `get_state` before binding.** `tools/claude-spt/src/bridge.rs::run_argv` enforces that order and bounded waits. This closes the “bind before a failed handshake poisons the ledger” alternative.\n\n---\n\n# SUPERSEDED — preserve as history, do not ask in original form\n\n1. **RPC bridge as `[session.self]` / `[session.resume]`.** Superseded explicitly by ADR-0007. Remaining old statements in `OMP-ADAPTER-PLAN.md` slices S1/S2, `tools/claude-spt/src/bridge.rs` module docs (“hosted harness process” / `[session.self]`), the top of `adapter/omp-spt.toml` (“integration is an RPC bridge”), and `docs/OMP-BRIDGE-FIELD-ISSUES.md` must be read as pre-0.1.3 history.\n\n2. **The full `spt-claude-code`/`claude-spt` naming-domain decision.** ADR-0005 was accepted for the sister product, then operationally superseded by the fork’s `omp-spt`/`omps`/`omp` names. It remains valid lineage, not the active OMP naming ADR.\n\n3. **The `cc` launcher decision.** `SCOPE.md`, ADR-0001, and `traceable-reqs.toml::REQ-DIST-SHORTCUT-BASENAME` lock `cc-<id>` for Claude. Current OMP code and tests lock `shortcut_basename = \"omp\"`. Do not ask whether omp-spt should use `cc`; ask only whether `omp` is the right final OMP shortcut token.\n\n4. **ccs profile work and `claude-spt:deep`.** `SCOPE.md` already locks `deep` removal and originally locks ccs for Claude. For OMP, the manifest says no shipped profiles and tests enforce it. `traceable-reqs.toml::REQ-CCS-PROFILES` and `REQ-SETUP-CCS` are stale rather than live OMP requirements.\n\n5. **The OMP plan’s exact directory-encoding open question.** `tools/claude-spt/src/digest_omp.rs` documents that the implementation locates by session id under the sessions root, so it does not need to reproduce the directory encoding. Ask whether locate-by-id is acceptable only if a concrete ambiguity/collision is found; do not re-ask how to clone OMP’s encoding.\n\n6. **The original single-sequence checkpoint macro in proposed ADR-0004.** `docs/KNOWN-HAZARDS.md` §2.4 and `traceable-reqs.toml::REQ-HAZARD-CHECKPOINT-CLEAR-RACE` supersede it with ARM/FIRE split sequencing, then a one-sequence post-clear rename+wake. If checkpoint remains in scope at all, the later hazard invariant is authoritative.\n\n7. **Several SCOPE grill items are already resolved in the same file or later ADRs.** `SCOPE.md:135` locks the post-push signal trigger, while `SCOPE.md:211` still lists “git-hook signal vs polling” as open. `SCOPE.md:182-190` resolves the docs/template split, while lines 212-214 still list it as open. ADR-0001 confirms UPS slash-command behavior, so `SCOPE.md:54-55` is stale. These should not be re-grilled.\n\n8. **Field issue HIGH-1 and interactive HIGH-3.** HIGH-1’s executable collision is implemented as `omp-spt` (`Cargo.toml`, packer, manifest, tests). The interactive “READY only” UX is structurally superseded by ADR-0007 because interactive hosting no longer uses the bridge; bridge logging remains relevant only to headless use.\n\n---\n\n# UNRESOLVED — live design decisions\n\n## Product/domain boundary\n\n1. **Is the Claude Code plugin an intentional supported surface?** The plan says the OMP hook plugin is removed (`OMP-ADAPTER-PLAN.md:87`), yet `plugin/omps` is actively packaged and tested, `[update.post]` still runs plugin reconciliation, the manifest carries `[hooks.*]`, UPS strings, hints, CC inject configuration, and `tools/claude-spt/src/hook.rs` remains active. If “yes,” define this as an explicit cross-harness control surface. If “no,” most Claude-specific ADRs, hazards, requirements, tests, and code are out of scope and should be retired cleanly.\n\n2. **What does `omps` mean and is it final?** `OMP-ADAPTER-PLAN.md:78` still says “`omps` (or keep `sptc`? decide),” while `plugin/omps/.claude-plugin/plugin.json`, skill paths, hints, and tests enforce `omps`. The implementation choice needs ratification and an OMP naming ADR; the old `sptc→spt` succession is not automatically applicable.\n\n3. **What are the canonical topologies and users of the retained headless bridge?** ADR-0007 says “explicitly headless callers,” but does not define who invokes `omp-spt bridge`, whether it is a supported public CLI, whether it serves ReadyAgent only or LiveAgent too, or whether resume/psyche paths count as bridge consumers.\n\n## Capability truth\n\n4. **Worker support is unresolved and currently overclaimed.** `adapter/omp-spt.toml` advertises `hostable_types = [\"LiveAgent\", \"ReadyAgent\", \"Worker\"]`; the OMP plan’s diagram mentions `worker-*`; but `adapter/strings/omp-spt.mjs` handles only session/agent lifecycle and `bridge.rs` never calls worker-start/worker-stop. Existing worker requirements/tests point to Claude hooks. Decide either to implement OMP worker lifecycle or remove Worker from advertised capability.\n\n5. **ReadyAgent versus LiveAgent semantics need an OMP-native statement.** The current skill prose describes upgrading a *Claude Code* session and a Monitor-based relay; the native extension always starts `spt ready`, while the manifest also declares OMP psyche roles. The precise user-visible transition that creates a live OMP agent versus a ready OMP endpoint is not documented in OMP terms.\n\n6. **Session-owned file locations are not decided in OMP language.** `[session].commune_dir` and `signoff_dir` are still `.claude`; OMP skills still tell agents to write `.claude/<id>-commune.md`. Decide whether `.claude` is intentionally adapter-owned compatibility state, should become `.omp`, or should be a harness-neutral project directory. This affects migration and resume semantics.\n\n## Reliability and recovery\n\n7. **RPC bridge mid-turn behavior remains unresolved.** The plan promises `steer` / `follow_up`; field issue MEDIUM-1 requires decoupled delivery and steer; `bridge.rs::drive_turn` instead buffers later messages until `agent_end`. This is safe serialization but not the promised mid-turn control surface. Ratify serialization-only or implement steering.\n\n8. **Clean adapter switch/unbind remains unresolved.** Field issue MEDIUM-4 asks for an operator-supported switch without ledger surgery. Current bridge and extension call `session-end` on graceful shutdown, but there is no documented switch procedure and no requirement/test proving an omp-spt session can be stopped and relaunched under another adapter.\n\n9. **Cross-platform hard-kill child cleanup remains partial.** Windows Job Object cleanup exists. `bridge.rs::teardown::arm_kill_on_close` explicitly returns a no-op error on non-Windows and says Unix process-group teardown is a follow-on. Decide whether headless Linux support requires the same invariant; current packaging ships Linux, so [INFERENCE] it likely should.\n\n10. **Native extension delivery failure policy is undefined.** If `pi.sendUserMessage` throws, `omp-spt.mjs::dispatchNext` logs locally and drops `current` without notifying the sender. If the `spt ready` listener exits, the extension marks the UI offline but does not re-arm, tear down the perch, or create an SPT-visible failure. Decide retry, explicit failure reply, offline transition, or terminal teardown.\n\n11. **The honest minimum spt-core floor is still open.** `OMP-ADAPTER-PLAN.md:174-176` asks for the verbs actually used. The manifest pins `0.27.0` with a long inherited Claude floor narrative. The OMP-specific required floor has not been derived or recorded.\n\n12. **OpenRouter role/model selection remains intentionally unfinished.** `docs/OMP-OPENROUTER.md:57-59` verifies OpenRouter routing and says the remaining choice is model/role assignment. This is a product configuration decision, not an adapter implementation defect.\n\n13. **ACP supersession criterion is only a strategic statement.** `OMP-ADAPTER-PLAN.md:10-13` says an ACP client may supersede this bridge, but gives no decision trigger or migration boundary. Leave it as a future condition unless current roadmap planning needs a formal sunset criterion.\n\n---\n\n# CONTRADICTED BY CODE OR CURRENT ARTIFACTS — factual defects, not taste questions\n\n1. **Setup is functionally pointed at the wrong adapter.** `adapter/strings/skills/setup.md` and `plugin/omps/skills/setup/SKILL.md` repeatedly activate `claude-spt`, use `adapter/claude-spt.toml`, fetch `SaberMage/claude-spt`, select `claude-spt:ccs`, and describe Claude Code. The actual manifest is `adapter/omp-spt.toml`, adapter is `omp-spt`, repo is `BigscreenVR/omp-spt`, and no ccs profile exists.\n\n2. **Plugin identity is stale.** `plugin/omps/.claude-plugin/plugin.json` describes “adapter for Claude Code” and includes keyword `claude-spt`. That may be correct only if the root product-boundary decision intentionally retains a Claude control plugin; otherwise it contradicts the target.\n\n3. **The manifest says hooks are the delivery surface while the accepted interactive architecture uses the OMP extension.** `[inject]` says activity/idle `hook`, top-level comments say RPC bridge, and `[hooks.*]` are CC-specific. ADR-0007 and `[session.self]/[session.resume]` use native OMP + extension. These claims need either a topology qualifier or removal.\n\n4. **The manifest still captures `CLAUDE_CONFIG_DIR` even though its own comments call it inert for OMP.** `[env.CLAUDE_CONFIG_DIR]` is active data, but `digest-omp` locates under OMP sessions. An inert Claude read-var should not remain an unexplained current contract.\n\n5. **CC echo verification is active but explicitly called inert on OMP.** `[env.SPT_INJECT_VERIFY_ECHO] = 1` and `traceable-reqs.toml::REQ-INJECT-VERIFY-ECHO` are Claude-TUI commitments; `tests/manifest-shortcut.sh` says the declaration is “inert on omp.” This should be removed or justified for a retained Claude topology.\n\n6. **Integration tests use the OMP manifest but assert Claude adapter outcomes.** `ci/manifest/registration-int.sh` adds `adapter/omp-spt.toml` then looks for/removes `claude-spt`, requires `claude-spt:ccs`, expects “Claude Code (spt),” fetches `/sptc:*` strings, and invokes capability as `claude-spt`. `ci/setup/activate-int.sh` has the same wrong identity/profile assumptions. These are demonstrably stale test contracts.\n\n7. **Digest integration is not an OMP digest proof.** `ci/digest/digest-proof-int.sh` points at `adapter/omp-spt.toml` but checks for a built `claude-spt` executable, creates a Claude `projects/<slug>/<sid>.jsonl` tree from a CC-shaped sample, and runs `digest-proof claude-spt`. It does not demonstrate `digest-omp` against OMP JSONL.\n\n8. **Acceptance remains a real-Claude hook test, not OMP acceptance.** `ci/acceptance/run-acceptance.sh`, `ci/acceptance/lib.sh`, and `tests/acceptance-harness.sh` create `.claude` hook fixtures and spawn `claude -p`. This may remain sister-lineage testing only if the Claude plugin is deliberately supported; it cannot satisfy an omp-spt acceptance requirement.\n\n9. **Psyche integration remains Claude-specific.** `ci/psyche/live-relay-int.sh` sets `A=claude-spt`, describes a resident `claude-spt-psyche`, and tests the retired resident model, while current OMP uses `psyche-omp` as an ephemeral per-event shim.\n\n10. **`traceable-reqs.toml` is largely false-domain metadata.** Header says `spt-claude-code`; titles and evidence paths name `adapter/claude-spt.toml`, `plugin/sptc`, `/sptc:*`, ccs, Claude hooks, CC remote control, and Claude hazards. The registry has only one OMP-specific requirement, `REQ-OMP-NATIVE-TUI`. A green trace check can therefore certify retained Claude evidence while leaving OMP capabilities untraced.\n\n11. **`REQ-DIST-SHORTCUT-BASENAME` says `cc`; its test enforces `omp`.** The test carries `[unit->REQ-DIST-SHORTCUT-BASENAME]` but verifies a different observable contract than the requirement title.\n\n12. **`REQ-DIST-MANIFEST-SCHEMA`, `REQ-DIST-DIGEST-EXTRACTOR`, `REQ-DIST-SESSION-RESUME`, `REQ-SKILL-LIVE`, and many others have Claude-specific titles but are being reused as tags around OMP artifacts.** This is semantic trace corruption: the evidence may be real code, but it does not prove the stated requirement.\n\n13. **The RPC bridge’s `spt_call` still does not evaluate child exit status.** `tools/claude-spt/src/bridge.rs::spt_call` returns merged stdout/stderr regardless of `out.status`; bind then logs `bound:` even if `spt api bind` exits nonzero and returns no token. This means field issue LOW-1 (“errors universally swallowed”) is only partially closed despite manifest changelog claims.\n\n14. **The OMP plan says hook plugin removed, but the repository actively ships and validates `plugin/omps`.** This is the concrete contradiction underlying the root design question.\n\n15. **`REQ-OMP-NATIVE-TUI` overstates its unit evidence.** Its title requires native TUI *and* bind/listen/state/reply behavior. `tests/manifest-shortcut.sh` only checks command strings/existence, and `tests/omp-extension.mjs` only tests `decodeBody`, `drainEvents`, and `extractReply`. Neither drives `ompSpt(pi)` through session_start, agent_start/end, listener failure, queue serialization, state auth, reply send, or shutdown.\n\n16. **`ci/run-gates.sh` can appear green while live OMP proofs skip.** `tests/bridge-acceptance.sh` exits 0 unless `OMP_SPT_ACCEPTANCE=1`; native OMP PTY acceptance is not automated; stale real-Claude acceptance is separately gated. The default gate is therefore not evidence of end-to-end OMP behavior.\n\n---\n\n# KNOWN FIELD ISSUES — demonstrable closure status\n\n- **HIGH-1 executable collision: implemented.** `tools/claude-spt/Cargo.toml` names the shipped binary `omp-spt`; packer/tests enforce it. Field document itself still reads as open historical advice.\n- **HIGH-2 child teardown: partial.** Windows Job Object + explicit graceful kills exist and `tests/bridge-acceptance.sh` has a Windows orphan check. Unix hard-kill cleanup and signal/process-group handling remain absent; the code says so explicitly. No dedicated trace requirement exists.\n- **HIGH-3 visibility: implemented for headless bridge.** Always-on `oplog!` and heartbeat exist; acceptance asserts message/reply/bind log lines, but not heartbeat/error variants. Interactive visibility is superseded by native TUI.\n- **HIGH-4 bounded waits: substantially implemented.** `await_frame`, reader threads, env-configurable deadlines, and turn-failure notice exist. Unit tests cover await timeout/EOF; gated bridge acceptance covers a hung turn. Startup/get_state deadline E2E is not demonstrated.\n- **MEDIUM-1 head-of-line / steer: unresolved.** Later messages are queued FIFO, but no `steer` or `follow_up` implementation exists.\n- **MEDIUM-2 dead child detection: implemented.** Reader EOF and heartbeat `try_wait` cover idle detection.\n- **MEDIUM-3 binary collision: mitigated, not eliminated.** Known install paths precede PATH and the ready deadline fails loudly, but there is no explicit version probe. This matches one of the field document’s proposed alternatives.\n- **MEDIUM-4 clean adapter switch: unresolved as an operator contract.** Graceful `session-end` exists, but no documented/tested switch/unbind flow exists.\n- **LOW-1 swallowed SPT errors: partial/factually defective.** Logging improved, but `spt_call` ignores process status and bind can be announced after failure.\n- **LOW-2 silent empty failed reply: implemented for timeout/EOF.** Failures send an explicit notice. A successful `agent_end` with no assistant text still produces an empty bridge reply; the native extension instead uses a non-empty fallback string.\n\n---\n\n# GLOSSARY UPDATES NEEDED\n\n`CONTEXT.md` should cease presenting the sister adapter as the current product. Required canonical entries:\n\n1. **`omp-spt`** — repository, adapter id, and consolidated executable identity; distinguish executable invocation `omp-spt <subcommand>` from adapter id.\n2. **OMP / oh-my-pi** — the interactive terminal agent, including the exact capitalization rule (“OMP” product/UI versus `omp` executable).\n3. **native OMP endpoint** — an spt-hosted endpoint where `omp` owns the PTY and loads the SPT extension.\n4. **OMP SPT extension** — packaged `adapter/strings/omp-spt.mjs`; owns interactive bind/listen/state/reply, not terminal rendering.\n5. **headless RPC bridge** — `omp-spt bridge`; retained for callers without an operator terminal, explicitly not `[session.self]`.\n6. **interactive versus headless topology** — make the split first-class so “bridge,” “host,” and “endpoint” are not used interchangeably.\n7. **OMP session id / OMP session file / OMP transcript root** — separate OMP’s session identity from SPT endpoint id and from Claude’s transcript terminology.\n8. **OMP Psyche turn** — current ephemeral `psyche-omp` model, not the obsolete “detached resident claude companion” definition.\n9. **Librarian** — if it is a real product role rather than plan-only motivation, define it and distinguish the role from the generic adapter.\n10. **`omps` plugin namespace** — only if deliberately retained; define why a Claude Code plugin belongs in omp-spt and whether `/omps:*` is temporary or final.\n11. **ACP supersession** — define only if there is a concrete trigger; otherwise leave it as plan rationale, not glossary truth.\n\nExisting entries requiring correction or historical qualification:\n\n- `spt-claude-code`, `claude-spt`, `naming-domains`, `legacy spt`, `skeleton plugin`, `fetch-stub skill`, `ccs profile`, `cc launcher`, `psyche sandbox`, `tagged-input round-trip`, `interrupt marker`, and `boundary rename` are Claude/sister lineage, not unqualified OMP terms.\n- The current Psyche definition says “detached companion process” and `claude-spt-psyche`; current OMP manifest uses a captured, run-to-completion `psyche-omp` role.\n- The current `ccs profile` examples (`glm`, `kimi`) are already stale even for the sister adapter, whose later ruling chose bare `ccs`; they are doubly stale for OMP.\n- “bridge” currently names both the former interactive PTY leader and the retained headless command. Qualify it every time.\n- “hook” needs qualification: Claude Code command hooks (`plugin/omps/hooks`) versus OMP extension events (`pi.on(...)`). They are different integration surfaces.\n- Use canonical SPT nomenclature consistently (`Psyche`, live agent, ready agent, endpoint, perch, node, subnet); avoid CONTEXT’s unqualified “companion” where release guidance explicitly says not to substitute that softer synonym.\n\n---\n\n# REQUIREMENTS / TEST GAPS\n\nThe OMP port needs explicit OMP requirements rather than attaching OMP evidence to Claude titles. Minimum missing requirement set:\n\n- OMP native extension lifecycle: bind, auth, ready listener, busy/idle, serialized dispatch, reply correlation, shutdown.\n- Native PTY visibility/attach acceptance (separate from extension protocol behavior).\n- Headless RPC bridge contract and supported caller/topology.\n- Bridge child-lifetime invariant per supported OS.\n- Bridge ready/get_state/turn deadlines and failure reporting.\n- Clean stop/unbind/adapter-switch recovery.\n- OMP digest extractor and locate behavior.\n- OMP history fetcher.\n- OMP ephemeral Psyche turn/reseed behavior.\n- OMP echo-commune behavior.\n- OMP native resume.\n- OMP distribution/setup/update identity.\n- OMP provider/OpenRouter documentation boundary.\n- OMP Worker lifecycle, or an explicit “Worker intentionally unsupported” decision and capability removal.\n- Native listener-death and `sendUserMessage`-failure no-silent-loss hazard.\n\nTests needed to satisfy those contracts:\n\n- A mocked/fake `pi` lifecycle test for `ompSpt(pi)` that asserts event registration, bind args/token auth, state transitions, queue serialization, one reply per sender, fallback reply, listener close behavior, and session_shutdown teardown.\n- A real or stable-fake native endpoint-run/attach proof for the PTY/TUI requirement; current helper tests cannot prove a TUI exists.\n- OMP JSONL samples for `digest-omp` and `history-omp`, invoked through `spt adapter digest-proof omp-spt` rather than Claude-shaped fixtures.\n- `psyche-omp` and `echo-commune-omp` integration proofs using their current ephemeral contracts.\n- Bridge startup ready timeout, get_state timeout, dead-child idle detection, bind failure, state/send failure, and Unix hard-kill tests where supported.\n- Stop/unbind/relaunch-under-other-adapter acceptance.\n- Capability assertion matching actual ReadyAgent/LiveAgent/Worker support.\n- Update/registration/setup tests rewritten to `omp-spt`, `BigscreenVR/omp-spt`, `/omps:*`, and no ccs overlay—or removed if the plugin is retired.\n\nTraceability defects are structural: add `OMP-ADAPTER-PLAN.md` to scan roots if it remains requirement-bearing; rename/generalize inherited requirements only when their observable contract genuinely survives; retire inapplicable Claude requirements instead of leaving active stages; do not use one tag to mean “same rough seam” when its title specifies another harness.\n",
  "files": [
    {
      "path": "CONTEXT.md",
      "description": "Authoritative glossary is entirely the claude-spt glossary. It lacks omp-spt, native OMP endpoint, OMP extension, headless RPC bridge, OMP session/transcript, and OMP Psyche terms; multiple definitions contradict the current fork."
    },
    {
      "path": "SCOPE.md",
      "description": "Locked Claude product ledger. Contains reusable public-surface discipline but also stale CC distribution, ccs, cc launcher, setup, CI, and parity decisions. Its open queue contradicts decisions already locked/resolved earlier in the same file."
    },
    {
      "path": "OMP-ADAPTER-PLAN.md",
      "description": "Primary OMP port plan. Correctly states the native-TUI/RPC split and OpenRouter boundary, but retains stale slice wording, unresolved namespace/floor/capability questions, and an explicit claim that the hook plugin is removed despite active plugin/omps code."
    },
    {
      "path": "docs/adr/0001-distribution-splits-by-volatility.md",
      "description": "Accepted Claude-specific thin-plugin decision. Applicability to omp-spt depends entirely on whether plugin/omps is an intentional supported Claude surface."
    },
    {
      "path": "docs/adr/0002-hook-wiring-hand-written-hooks-json-shells-spt-api.md",
      "description": "Accepted Claude hook architecture. It is not an OMP extension decision and should be topology-qualified or retired for an OMP-only product."
    },
    {
      "path": "docs/adr/0003-psyche-is-a-constrained-auto-approving-companion.md",
      "description": "Accepted resident Claude Psyche sandbox decision. Current OMP uses psyche-omp with different process/model behavior; this ADR is sister lineage, not an OMP Psyche contract."
    },
    {
      "path": "docs/adr/0004-checkpoint-via-self-send-loopback.md",
      "description": "Still marked proposed despite implementation, and its original single-sequence mechanics are superseded by later checkpoint hazards. It is also Claude-hook/translation-specific."
    },
    {
      "path": "docs/adr/0005-name-unification.md",
      "description": "Accepted and executed for claude-spt, then operationally superseded by the omp-spt fork. No replacement OMP naming ADR records omp-spt/omps/omp rationale."
    },
    {
      "path": "docs/adr/0006-one-command-update-and-consolidated-binary.md",
      "description": "Single-binary concept survives as omp-spt, but the ADR’s plugin, binary names, update instructions, and open asks are Claude-specific or stale."
    },
    {
      "path": "docs/adr/0007-native-omp-tui-hosts-spt-extension.md",
      "description": "Only accepted OMP-native ADR. Definitively locks native OMP as PTY leader, public extension integration, serialized delivery, and RPC bridge relegation to headless callers."
    },
    {
      "path": "docs/KNOWN-HAZARDS.md",
      "description": "Conformance checklist remains almost entirely Claude-specific. Some hazards may apply only if plugin/omps is retained. It does not contain the OMP bridge incident invariants or native-extension no-silent-loss/recovery hazards."
    },
    {
      "path": "docs/OMP-BRIDGE-FIELD-ISSUES.md",
      "description": "Historical incident report with no per-item closure status. HIGH-1/3 and most HIGH-4/MED-2/LOW-2 are implemented; HIGH-2 is Windows-only, MED-1 and MED-4 remain open, and LOW-1 is only partially fixed."
    },
    {
      "path": "traceable-reqs.toml",
      "description": "Registry header and nearly all requirement titles/evidence are claude-spt-specific. Only REQ-OMP-NATIVE-TUI is OMP-native, and even that requirement’s bind/listen/state/reply behavior is not exercised by its claimed unit tests. OMP-ADAPTER-PLAN.md is absent from scan roots."
    },
    {
      "path": "adapter/omp-spt.toml",
      "description": "Current implementation truth for adapter/repo/binary/shortcut, native self/resume, OMP digest/history/psyche, and extension packaging. Also carries large contradictory Claude hook/inject/env/skills commentary and active tables, including inert CLAUDE_CONFIG_DIR and CC echo-verify declarations."
    },
    {
      "path": "adapter/strings/omp-spt.mjs",
      "description": "Native OMP extension implementation. Pure helper tests exist, but lifecycle, queue, auth/state/reply, failure recovery, and shutdown are untested. sendUserMessage failure can silently drop a taken message from the sender’s perspective; listener death is only local UI state."
    },
    {
      "path": "plugin/omps/.claude-plugin/plugin.json",
      "description": "Enforces plugin name omps but describes a Claude Code adapter and includes claude-spt lineage. This is either evidence of an intentional cross-harness surface needing a decision, or stale product identity."
    },
    {
      "path": "adapter/strings/skills/setup.md",
      "description": "Broken/stale OMP setup instructions: activates claude-spt, uses the old manifest/repo, and offers a nonexistent ccs overlay."
    },
    {
      "path": "plugin/omps/skills/setup/SKILL.md",
      "description": "Self-contained setup fallback repeats the wrong claude-spt paths/repo/profile and therefore cannot be dismissed as harmless comments."
    },
    {
      "path": "tools/claude-spt/src/bridge.rs",
      "description": "Headless RPC bridge with Windows Job Object, reader threads, deadlines, logging, and explicit failure replies. Still serializes rather than steers, lacks Unix hard-kill cleanup, has no clean switch contract, and ignores spt child exit status in spt_call."
    },
    {
      "path": "tools/claude-spt/Cargo.toml",
      "description": "Shipped executable is correctly renamed omp-spt, closing the basename collision on current builds."
    },
    {
      "path": "tests/omp-extension.mjs",
      "description": "Tests only decodeBody, drainEvents, and extractReply; does not exercise the exported extension lifecycle required by REQ-OMP-NATIVE-TUI."
    },
    {
      "path": "tests/manifest-shortcut.sh",
      "description": "Useful current manifest assertions for omp identity/native self+resume/no ccs, but tags them to several Claude-specific generic requirements, creating trace semantic mismatch."
    },
    {
      "path": "tests/bridge-acceptance.sh",
      "description": "Gated headless bridge E2E covers message/reply/bind, hung-turn deadline/failure notice, and Windows orphan cleanup. It is incorrectly tagged as impl evidence for Claude REQ-SKILL-LIVE and skips by default."
    },
    {
      "path": "ci/manifest/registration-int.sh",
      "description": "Adds the OMP manifest but asserts/removes claude-spt, requires claude-spt:ccs, and resolves /sptc bodies. It is stale and cannot be valid OMP registration evidence."
    },
    {
      "path": "ci/setup/activate-int.sh",
      "description": "Adds the OMP manifest but drives the claude-spt deregister/reactivate/profile/string contract. Stale acceptance."
    },
    {
      "path": "ci/digest/digest-proof-int.sh",
      "description": "Uses OMP manifest path but Claude binary name, Claude session layout/sample, and adapter id claude-spt; does not test digest-omp."
    },
    {
      "path": "ci/acceptance/run-acceptance.sh",
      "description": "Real-Claude UserPromptSubmit hook acceptance, not OMP acceptance. Retain only if the Claude plugin is intentionally supported and classify separately."
    },
    {
      "path": "ci/psyche/live-relay-int.sh",
      "description": "Tests the obsolete resident claude-spt-psyche model and claude-spt adapter id, not current psyche-omp ephemeral behavior."
    },
    {
      "path": "ci/run-gates.sh",
      "description": "Default gates run shell/unit/build/trace checks but gated OMP E2E skips as success; native TUI acceptance is absent, so default green is not OMP end-to-end proof."
    }
  ],
  "architecture": "# One-question-at-a-time grill dependency order\n\nAsk exactly one question at each stage; do not descend until its parent is settled.\n\n1. **Product boundary (highest dependency):** “Is `plugin/omps` a deliberately supported Claude Code control surface for omp-spt, or should omp-spt be OMP-native only?”\n   - If OMP-only: retire plugin/update-post/hook/UPS/CC hazards/CC tests cleanly.\n   - If retained: define it as a separate topology with its own applicability labels; do not call Claude hook behavior OMP behavior.\n\n2. **Supported topology matrix:** “Which topologies are product-supported: native interactive OMP, headless `omp-spt bridge`, retained Claude plugin (if yes), and daemon-driven OMP Psyche?”\n   - This fixes the domain boundary for every later requirement and term.\n\n3. **Canonical naming:** “Ratify or change the implemented OMP tokens: repo/adapter/binary `omp-spt`, shortcut `omp`, and—only if retained—Claude plugin prefix `omps`.”\n   - Record a new OMP naming ADR; explicitly supersede ADR-0005 for this fork.\n\n4. **Capability truth:** “For each supported topology, which SPT types are honest: ReadyAgent, LiveAgent, Worker?”\n   - In particular, decide Worker implementation versus removing the advertised capability.\n\n5. **Native extension lifecycle contract:** “When a bound native extension loses its listener or cannot submit an inbound message, must it retry, reply with failure, mark offline, or terminate the endpoint?”\n   - Lock no-silent-loss and recovery before writing tests.\n\n6. **Headless bridge turn policy:** “Does the headless bridge intentionally serialize later messages until `agent_end`, or must it implement OMP `steer`/`follow_up` for mid-turn delivery?”\n   - This disposes MEDIUM-1 and corrects the plan promise.\n\n7. **Headless bridge shutdown/switch policy:** “What operator-visible stop/unbind/switch contract must work on every supported OS?”\n   - Then decide whether Unix process-group cleanup is required and define the cross-adapter recovery acceptance.\n\n8. **Session/context ownership:** “What OMP-native locations and identity rules govern commune/signoff files, resume, transcript lookup, and Psyche state?”\n   - Resolve `.claude` versus `.omp`/adapter-owned state and align skill prose, manifest, digest/history, and Psyche.\n\n9. **Provider configuration:** “Which OMP profile/model roles should the Librarian use by default, if any, while keeping OpenRouter setup outside adapter code?”\n   - The billing boundary itself is already locked and must not be re-asked.\n\n10. **Minimum public contract:** “Given the final topology/capability matrix, what is the lowest published spt-core version that supports every actually used verb and manifest field?”\n    - Derive the floor from published artifacts only; delete the inherited floor narrative that no longer applies.\n\n11. **Traceability migration:** “Do we clean-cut the registry to OMP requirement titles, or preserve Claude lineage in a separately labeled historical registry/document?”\n    - Recommendation: clean-cut current requirements; preserve lineage in docs/changelog, not active trace entries.\n\n12. **Acceptance bar:** “Which live proofs are release-blocking for native OMP, headless RPC, Psyche, resume, digest/history, and cross-adapter recovery?”\n    - Only after contracts are fixed should required stages and tests be assigned.\n\n13. **Documentation supersession pass:** “Which inherited ADRs/hazards remain applicable to a retained Claude topology, and which become historical/superseded?”\n    - Update CONTEXT last so its glossary reflects all upstream answers rather than steering them.\n\n## Recommended document authority after the grill\n\n- `CONTEXT.md`: OMP-native glossary only, with explicitly qualified sister/legacy terms.\n- `SCOPE.md`: replace the Claude scoping ledger with the final omp-spt product/capability boundary; archive the old ledger as lineage if needed.\n- OMP ADRs: one naming/product-boundary ADR, one topology/capability ADR, ADR-0007 retained, one bridge reliability/recovery ADR if headless remains supported.\n- `docs/KNOWN-HAZARDS.md`: only current invariants, grouped by topology; retain historical incidents with explicit resolved/superseded status.\n- `docs/OMP-BRIDGE-FIELD-ISSUES.md`: add per-finding status and evidence, or fold still-live invariants into KNOWN-HAZARDS and mark the report historical.\n- `traceable-reqs.toml`: OMP-observable contracts only; no OMP evidence attached to a requirement whose title says Claude/ccs/sptc/cc launcher.\n- Tests: separate `native-extension`, `headless-bridge`, `omp-session`, and optional `claude-control-plugin` lanes so one topology cannot accidentally certify another."
}