OMP Integration Cheat Sheet

This proposal map distinguishes two OMP uses in the published owner/release deployment record: a dedicated subscription OAuth holder for native Deek model routes, and an isolated OMP 18.10.4 ACP child runtime. Their homes and credentials are independent. Subscription Provider Sign-in owns the holder’s policy and historical recovery flow; OMP and Hermes owns the historical installation/launch record and independent readiness prerequisites. This documentation comparison did not inspect /opt/deek/app, launch a child, select a child model, or verify delegated inference.

An installed executable is not a configured or authorized child model. Live projection, persistent ACP session management, and cross-system memory ingestion below remain research choices, not capabilities supplied by a fresh one-shot child. Separate owner processes described in Private Accounts and Service Publishing do not establish safe pooling of mutually untrusted users within one Harness process.

One-minute decision

Need	Choose	Status	Boundary
Run one isolated OMP task against the same server directory and receive a concise result	Phase 1 subagent-acp	Existing components; configuration required	Fresh process and fresh ACP session for every delegation; final text only
Watch one interactive OMP session inside Harness	OMP collab display projection	Proposed optional phase	Full transcript snapshot, then live entries and events from one authoritative OMP host
List, load, or resume OMP sessions from Harness	Persistent ACP Host bridge	Proposed advanced phase	A long-lived bridge owns remote session IDs and calls OMP session lifecycle methods
Recall durable facts in later sessions	Semantic memory pipeline	Proposed integration over existing Mnemopi	Normalized finalized events flow downstream after transport
Pool mutually untrusted people inside one Harness process	Do not share that process’s resource pool	Unsupported by the mechanisms described here	Identity-bound sessions, workspaces, projections, and memory are prerequisites; separate owner processes are a different deployment

Start with Phase 1. Add collab only when a live transcript is a real requirement. Add a persistent ACP Host only when continuation is a real requirement.

Keep the three planes separate

flowchart TD
  H[Harness runtime] --> T[Agent and session transport]
  T --> O[OMP runtime]
  H --> W[Shared server workspace]
  O --> W
  T --> F[Finalized event feed]
  F --> M[Semantic memory]

Plane	Authority	What crosses it	What it does not do
Shared server-side workspace	The filesystem at the resolved cwd	Ordinary file reads and writes by both processes	ACP and collab do not copy, merge, lock, or synchronize files
Agent and session transport	The active ACP child, persistent ACP Host, or OMP collab host, depending on the phase	Prompts, final text, lifecycle calls, transcript entries, and live events	It is not semantic memory and does not make two session logs identical
Semantic memory	A downstream memory store such as Mnemopi	Validated, normalized, finalized records and later recall results	It is not an ACP or collab hop and is not authoritative for a live transcript

A shared cwd gives two processes filesystem visibility. ACP carries agent protocol data. Collab carries a session projection. Memory stores derived knowledge later. None of those facts implies state synchronization between planes.

Phase 1: one-shot ACP delegation

The simplest integration adds no new bridge. Mount Harness subagent-acp and configure its child command to start OMP’s stdio ACP server.

subagent-acp setting	Phase 1 value
providerName	A distinct provider name such as omp
command	The pinned absolute path to the installed omp executable
args	['acp']
cwd	Omit to inherit each parent session’s resolved cwd; set only when every run must use one fixed directory
permission	Begin with reject; enable automatic approval only after reviewing the child tool boundary
env	Supply only the explicit environment OMP requires; do not assume parent credentials cross the subprocess boundary

flowchart LR
  H[Harness parent] --> A[Subagent ACP provider]
  A --> P[Fresh OMP ACP process]
  P --> N[Fresh ACP session]
  N --> C[OMP child run]
  C --> R[Final assistant text]
  R --> H

Every delegation follows this lifecycle:

1. Harness resolves the child cwd from provider configuration or the parent session.
2. subagent-acp spawns a fresh OMP process.
3. Harness sends ACP initialize, then session/new with that same cwd.
4. Harness sends one standalone task. The child receives no parent conversation.
5. Harness folds committed agent_message_chunk text into the result. Thoughts, tool traffic, plans, and the OMP history are not returned.
6. The run ends and the process is disposed. The provider does not retain the OMP session ID.

Current subagent-acp therefore cannot resume that child, mirror its OMP history, or expose its live trace. A retry is another process and another session.

Shared cwd is not workspace synchronization

flowchart TD
  H[Harness parent process] --> W[Resolved workspace directory]
  O[OMP child process] --> W
  H --> A[ACP prompt and result]
  A --> O

Both processes open the same server path with their own tools and permissions. ACP does not carry file bytes or workspace state. Files already written to disk can outlive the child, including partial work after a failure, so a retry must inspect the workspace before changing it again. Avoid concurrent ownership of the same file.

Choose ACP or collab by experience

flowchart TD
  Q[Choose the required experience] --> D[One isolated delegated task]
  Q --> L[One live OMP transcript]
  Q --> R[Managed session continuation]
  D --> A[Current subagent ACP]
  L --> C[Proposed collab projection]
  R --> P[Proposed persistent ACP Host]

Use ACP delegation for background work with a terminal answer. Use collab for a live display of an already-running OMP session. Use a persistent ACP Host for managed OMP session lifecycle. Do not overload collab as a job queue or describe current subagent-acp as persistent.

Optional live OMP display projection

A proposed Harness adapter can consume OMP collab as a display feed. The OMP host remains the sole execution and transcript authority.

flowchart LR
  O[Authoritative OMP host] --> S[Full transcript snapshot]
  S --> H[Harness display projection]
  O --> E[Live entries and events]
  E --> H
  H --> V[Disposable read model]

Connection order matters:

1. Bind to one OMP host and its current session.
2. Build the Harness projection from the complete transcript snapshot.
3. Apply later durable entries and ephemeral live events in order.
4. On a gap or reconnect, replace or repair the projection from a fresh host snapshot before accepting more live frames.

The adapter should be display-only at first. OMP continues to run the model and tools, own the session log, and access its workspace. The Harness projection must not become a second writable transcript, and collab must not be presented as workspace synchronization. Switching the OMP host to another session ends the existing collab projection.

Advanced persistent ACP Host bridge

This is a separate proposed component, not a mode hidden inside current subagent-acp.

flowchart LR
  B[Persistent ACP Host bridge] --> N[Session new]
  B --> L[Session list]
  B --> D[Session load]
  B --> R[Session resume]
  N --> O[Long lived OMP ACP server]
  L --> O
  D --> O
  R --> O

OMP’s ACP server advertises and implements session creation, listing, loading, and resumption. A Harness bridge could keep that server alive, persist a trusted host identifier plus remote session ID and exact cwd, and deliberately call those lifecycle operations. It must validate that mapping before load or resume and let OMP replay or resume its own history rather than synthesizing a Harness copy.

This bridge changes process ownership, authorization, cleanup, routing, and recovery. It should be built only after Phase 1, and it remains distinct from the collab display projection.

Semantic memory comes after transport

Mnemopi already provides remember, extraction, consolidation, storage, and recall primitives. The proposed cross-system integration is an adapter from authoritative finalized events, not a new transport between Harness and OMP.

flowchart LR
  E[Finalized session events] --> N[Normalize]
  N --> D[Deduplicate and validate]
  D --> X[Semantic extraction]
  X --> S[Memory store]
  S --> R[Later recall]

Normalize stable source metadata such as source host, session, event, workspace, role, timestamp, content, and terminal status. Accept only authoritative durable entries or completed turns; never write semantic memory directly from partial text chunks, tool-progress updates, or a disconnect. Use a stable source key so replay and reconnect are idempotent.

OMP’s current Mnemopi integration listens at agent_end, prepares a retention transcript, then extracts and consolidates it. A future shared feed should preserve the same finalized boundary. Recall may enrich a later prompt, but it does not rewrite the original transcript or decide whether a live turn completed.

Authoritative data map

Data	Authority	Harness copy or derivative
Workspace files	Shared server filesystem at the selected cwd	None transported by ACP or collab
Phase 1 OMP child session and history	Fresh OMP ACP process and session	No session mirror
Phase 1 returned answer	Harness subagent-acp result folded from committed assistant chunks	Final text only
Live transcript when enabled	The one OMP collab host and its session log	Disposable display projection
Persistent session when enabled	OMP ACP server	Bridge-owned mapping of trusted host, session ID, and cwd
Semantic memory when enabled	Scoped downstream memory bank	Derived records with source host/session/event identifiers, never transcript authority
Browser admission today	Authelia and nginx at the edge	Native DSH cookie authorizes the app but carries no person identity

Restart and recovery rules

Failure	Recovery	Invariant
Phase 1 child exits or its ACP stream fails	End that delegation; inspect the shared workspace; retry as a new delegation if safe	A retry creates a fresh process and fresh ACP session
Harness restarts after Phase 1	Treat previous children as non-resumable	Current subagent-acp stores no remote session ID and cannot recover child history
Collab connection drops	Stop applying deltas; obtain a fresh host snapshot; then resume live entries and events	The OMP host remains authoritative
OMP collab host exits or switches session	End the projection	Never promote the Harness read model into authority
Persistent ACP Host reconnects	Reconnect to the same trusted server and validate the stored session ID and exact cwd before load or resume	OMP owns persisted history and replay
Memory ingestion repeats an event	Normalize and deduplicate by stable source identity	Ingestion is idempotent and transport disconnect does not imply turn completion

Anti-patterns

• Treating a shared cwd as file synchronization, conflict resolution, or a distributed workspace.
• Expecting current subagent-acp to resume an OMP child or mirror OMP history.
• Using collab for one-shot background delegation when final text is sufficient.
• Making the Harness live projection writable or authoritative.
• Running Harness and OMP as competing authorities over one live transcript.
• Writing memory from streaming chunks or unfinished tool events.
• Putting semantic memory between Harness and OMP as a transport hop.
• Treating recalled memory as canonical session history.
• Assuming a transport disconnect means a turn finalized.
• Sharing one process’s authority-only browser cookie, session pool, workspace, projection, or memory among mutually untrusted people.

Shared-process security boundary

One trust domain per shared process

In the documented authority-cookie design, Authelia and nginx check Remote-User during proxy bootstrap, but the native DSH cookie is bound to the Harness authority and its validity window, not to Remote-User. That cookie alone cannot enforce per-person ownership when sessions, workspaces, projections, or memory are pooled inside one Harness process.

Do not expose one shared process’s integrations as identity-isolated merely because Authelia authenticated multiple people. Private Accounts and Service Publishing describes separate owner processes, homes, and kernel UIDs; this is not a claim that the shared-process pooling problem has been solved, nor a new live verification of those deployments.

flowchart TD
  I[Verified identity] --> C[Identity bound app session]
  C --> W[Identity workspace]
  C --> S[Identity session index]
  C --> P[Identity live projection]
  C --> M[Identity memory bank]

A design that pools mutually untrusted users must bind app credentials to stable verified identities, scope every session lifecycle operation to the identity, isolate workspace access, authorize collab projection subscriptions, partition memory writes and recall, and audit cross-identity administration. Until those controls exist, retain one trust domain per process/resource pool. Separately provisioned owner processes are not permission to merge their resources.

Phased implementation checklist

Phase 1: one-shot OMP delegation

• Pin and install the OMP executable on the Harness host.
• Mount @deepseek-ai/dsh-subagent-acp with command set to that executable and args set to ['acp'].
• Inherit the parent cwd unless a deliberately fixed workspace is required.
• Supply an explicit minimal child environment and begin with permission rejection.
• Route one delegation through the named provider and confirm the parent receives final text only.
• Treat any workspace changes as filesystem effects and every retry as a new OMP session.

Phase 2: optional live display

• Keep one OMP collab host authoritative for one active session.
• Build a read-only Harness projection from the full snapshot before applying live entries and events.
• Define ordering, duplicate, gap, reconnect, host-exit, and session-switch handling.
• Keep workspace access and synchronization outside this adapter.

Phase 3: optional persistent ACP Host

• Introduce a separately owned long-lived OMP ACP process.
• Persist and authorize the trusted host, remote session ID, and exact cwd mapping.
• Implement explicit new, list, load, resume, cancel, close, and teardown behavior.
• Use OMP’s lifecycle and history replay rather than a Harness transcript clone.

Phase 4: semantic memory

• Define one normalized finalized-event schema with source host/session/event identifiers.
• Add validation and idempotent deduplication before extraction.
• Feed accepted records into scoped Mnemopi storage and consolidation.
• Retrieve memory only for later context; never use it as transport or live-session authority.

Phase 5: multi-user gate

• Bind the native application session to a verified identity.
• Enforce that identity across session discovery, ACP lifecycle, workspace access, collab projections, and memory.
• Add cross-identity administration and audit rules before admitting mutually untrusted users.

Source anchors

Pinned links and revisions are collected in private page (sign-in required). The paths below identify the behavior each decision relies on.

Repository path	Grounded behavior
deepseek-harness/packages/subagent/subagent-acp/README.md	Fresh process and session per run, inherited cwd, final text only, no current continuation
deepseek-harness/packages/subagent/subagent-acp/src/index.ts	Parent workspace cwd is the only parent-session field consumed by the provider
deepseek-harness/packages/subagent/subagent-acp/src/run.ts	Spawn, ACP initialize and new-session sequence, committed assistant-text fold, prompt, and disposal
deepseek-harness/packages/workspace/workspace/README.md	Canonical server-side workspace and working-directory boundary
deepseek-harness/packages/api/session-controller/src/history.ts and packages/api/gateway/src/client/journal-stream.ts	Existing Harness snapshot and ordered-event projection primitives; not an OMP adapter
deepseek-harness/packages/client/connection/src/browser-auth.ts	Authority-bound cookie payload and proxy-bootstrap identity check
oh-my-pi/packages/coding-agent/src/commands/acp.ts	omp acp stdio server entry point
oh-my-pi/packages/coding-agent/src/modes/acp/acp-agent.ts	OMP ACP new, list, load, and resume session operations
oh-my-pi/docs/collab.md and packages/coding-agent/src/collab/protocol.ts	Host-authoritative collab model and snapshot, entry, event, and state frames
oh-my-pi/packages/coding-agent/src/collab/host.ts	One hosted session, snapshot-before-live flow, and host-owned execution
oh-my-pi/packages/coding-agent/src/mnemopi/state.ts and packages/mnemopi/README.md	Final-turn retention, extraction, consolidation, storage, and later recall