Merge origin/main into docs/tess-ledger-sync-m1

Resolve tracking-doc divergence for the M4-sync PR (#741): - TASKS.md: keep the sole-writer ledger (strict superset — every row equal-or-more-advanced than main, plus the M4-W running log). - VERIFICATION-MATRIX.md: take main's newer baseline (evolved AC-TESS-04 native-port handoff / M4-001+M4-V gate) and re-apply the AC-TESS-05 TESS-MEM-001 operator-memory reachability mapping on top. - MISSION-MANIFEST.md: M4 in-progress (auto-merged). M4 remains in-progress/gate-pending — M4-V has NOT passed (2 gate FAILs; wave-2 linchpin #740 in review). No source changes; command-authz untouched.
2026-07-13 09:37:03 -05:00
parent d9cc2e9978 3378b857eb
commit 686291412c
89 changed files with 24084 additions and 53 deletions
--- a/docs/scratchpads/tess-20260712.md
+++ b/docs/scratchpads/tess-20260712.md
@@ -56,3 +56,11 @@
 **Final focused review:** PASS. Deterministic audit validated all task repository roots with zero missing paths; no planning placeholders remained; security prerequisites still gate Tess exposure; observability traceability is explicit.

 **Current gate:** planning PR must merge to `main` with terminal-green CI before any source-code worker starts.
+
+## 2026-07-13 — M3 cross-surface delivery
+
+**Branch:** `feat/tess-m3-integration` from `main` at `84d884b9`.
+
+**Delivered:** Stable Discord `conversationId` enrollment after a visible provider/runtime session is known; idempotent provider-session rebinding that preserves agent/tenant/owner scope; Discord approval/stop target resolution through the durable snapshot; SSE runtime streaming after CLI attach; denial/audit parity including provider authorization denials and HTTP 403 approval-denial mapping.
+
+**Evidence:** Gateway targeted suite: 37 tests passed; Mosaic CLI interaction test passed; agent durable-session test passed; gateway and CLI typechecks passed; changed-file format and whitespace checks passed. Codex security review found no confident vulnerability. Code review identified a Fastify exception-response mismatch and two UX/acknowledgement issues; all were corrected before the final validation run.
--- a/docs/scratchpads/tess-m2-001-pi-service.md
+++ b/docs/scratchpads/tess-m2-001-pi-service.md
@@ -0,0 +1,40 @@
+# TESS-M2-001 — Pi Interaction Service
+
+## Scope
+
+- Add a generic rostered/systemd Pi operator-interaction service in
+  `packages/mosaic/framework`.
+- Pin the service to `openai/gpt-5.6-sol`, high reasoning, and the
+  `operator-interaction` tool policy.
+- Keep identity as provisioning data; the product name appears only in the
+  committed example roster.
+
+## Security and Configuration Invariants
+
+1. The chosen display/roster name is supplied as data and must exactly match the
+   generic systemd instance.
+2. The service fails before launch if runtime, model, reasoning, or tool policy
+   differs from the pinned policy.
+3. Effective-policy output includes only name, runtime, model, reasoning, and
+   tool policy; it does not inspect or output credential variables.
+4. The default example is replaceable without a source change; the TDD suite
+   provisions `Nova` from the same profile.
+
+## Evidence
+
+- `src/fleet/tess-service-profile.test.ts` proves a `Nova` provisioning path,
+  roster parser/env serialization, effective-policy output, fail-fast drift
+  rejection, and absence of the product name from generic source/profile.
+- `test-fleet-units.sh` validates the generic interaction systemd unit requires
+  per-agent config and invokes fail-fast startup validation.
+- `test-start-agent-session.sh` proves the tool-policy value is exported into
+  the Pi pane; `compose-contract.spec.ts` proves it becomes an explicit
+  runtime contract block.
+- Fresh-worktree dependency install plus root `pnpm typecheck`, `pnpm lint`,
+  `pnpm format:check`, and `pnpm test` passed; package/full fleet suites passed.
+- Independent Codex code and security reviews passed with no remaining findings.
+
+## Delivery Notes
+
+- Branch starts from fresh `origin/main` at `86a50138`.
+- PR targets `main` and references issue `#708`.
--- a/docs/scratchpads/tess-m2-002-durable-state.md
+++ b/docs/scratchpads/tess-m2-002-durable-state.md
@@ -0,0 +1,63 @@
+# TESS-M2-002 — Durable Tess State
+
+- **Issue:** #708
+- **Task:** `TESS-M2-002` / `TESS-STA-001`, `TESS-SEC-007..008`
+- **Branch:** `feat/tess-durable-state`
+- **Base:** fresh `origin/main` at `e3b5113be21e51d015fa1ae54572929b2a4acd9f`
+- **Budget assumption:** 38K task estimate; no explicit cap. Use focused TDD plus workspace validation.
+
+## Objective
+
+Persist a Tess session's immutable identity, inbox/outbox idempotency state, checkpoints,
+handoffs, and approval bindings so a new service instance can recover it after a process
+restart or context compaction without replaying a completed message or applied side effect.
+
+## Plan
+
+1. Write recovery/idempotency tests first in `packages/agent/src/tess-durable-session.test.ts`.
+2. Add transport-neutral durable-state contracts/state machine in `packages/agent`.
+3. Add canonical PostgreSQL schema/migration and a gateway Drizzle repository adapter.
+4. Wire gateway service/module and reuse `tess:command-approval:*` durable approval semantics
+   for exact, actor/tenant/action-bound approval consumption.
+5. Test PGlite restart recovery with separate service instances sharing the same durable DB.
+6. Document the recovery/compaction operation and update Tess architecture evidence.
+7. Run focused, cold-cache, workspace, migration, review, commit, push, and open PR to `main`.
+
+## Required Evidence
+
+| Requirement | Primary evidence |
+| --- | --- |
+| Restart recovery | Test creates a second coordinator over unchanged durable store after simulated process death. |
+| No duplicate side effects | Duplicate ingress and post-restart dispatch assert one handler/effect invocation. |
+| Compaction survival | Checkpoint/handoff/reconstructed state preserve the same session identity and pending records. |
+| Durable approvals | Existing `tess:command-approval` record is consumed only once and survives a new authorization service instance. |
+| Handoff | Stored handoff is portable and reconstructed without live process state. |
+
+## Progress
+
+- Intake complete: PRD AC-TESS-06, threat TM-07/TM-08, and verification matrix reviewed.
+- Affected surfaces: `packages/agent`, `apps/gateway`, `packages/db`; auth/authorization and DB migration tests required.
+- TDD is required (security authorization and critical state mutation).
+
+## Risks
+
+- An external provider action cannot be atomically committed with the database. The outbox
+  gives the receiver a stable idempotency key; generic recovery never replays an ambiguous
+  `processing` effect, and completed effects are never redispatched.
+- PostgreSQL is canonical; PGlite is the local/restart test implementation.
+
+## Verification
+
+- TDD red: `pnpm --filter @mosaicstack/agent test src/tess-durable-session.test.ts`
+  initially failed because the durable-state module did not exist.
+- Focused green: 7 agent state-machine tests; 6 PGlite repository tests (including
+  close/reopen recovery and encrypted-at-rest redaction); 5 durable-approval tests; DB migration tests.
+- Full cold-cache green: `pnpm turbo run typecheck lint test --force` completed
+  88 tasks with zero cache hits; `pnpm format:check` and `git diff --check` passed.
+- Fresh worktree dependency install passed with
+  `pnpm install --frozen-lockfile --store-dir /home/jarvis/.local/share/pnpm/store`.
+  The default pnpm store path was inaccessible to this harness, so the explicit
+  user-owned store path was required.
+- Codex review identified plaintext durable payload risk; resolved by AES-256-GCM sealing
+  after redaction, with an at-rest ciphertext assertion in the PGlite suite.
+- Pending final clean review, commit, and PR.
--- a/docs/scratchpads/tess-m4-001-mos-coordination.md
+++ b/docs/scratchpads/tess-m4-001-mos-coordination.md
@@ -0,0 +1,46 @@
+# TESS-M4-001 — Mos Coordination
+
+- **Issue/task:** #710 / TESS-M4-001
+- **Branch/base:** `feat/tess-mos-coordination` rebased onto `origin/main` `f1c6b37b`
+- **Budget assumption:** task estimate 25K; design-first and TDD, with package contract plus gateway boundary only.
+
+## Objective
+
+Implement a transport-neutral coordination contract allowing a configured interaction agent to hand off Mos-owned work, observe activity, and receive results while preventing it from gaining coding/general orchestration authority.
+
+## Plan
+
+1. Document the contract and enforcement-point sketch; request Mos's decision on the initial concrete transport.
+2. Add `@mosaicstack/coord` typed handoff/observe/result contracts and denial errors.
+3. Add a gateway service which derives actor/tenant/requester identity from trusted context/configuration and validates authority.
+4. Add contract and gateway boundary tests for configurable identities, self-delegation, target drift, and cross-tenant read denial.
+5. Run focused, cold-cache, baseline tests; independent review; PR lifecycle.
+
+## Design checkpoint — 2026-07-12
+
+Created `docs/tess/MOS-COORDINATION.md`. Mos approved the design and selected the native in-process `InMemoryMosCoordinationPort` for M4. Fleet/tmux remains a documented M5 adapter seam; no Mos-side consumer is built in this task.
+
+## Progress checkpoint — 2026-07-13
+
+- Implemented `MosCoordinationPort` with handoff/observe/result only, an authority-checking client, and deterministic native adapter in `@mosaicstack/coord`.
+- Implemented the gateway `MosCoordinationService`, deriving requester identity from trusted configuration and actor/tenant/correlation from authenticated context.
+- Added contract and gateway boundary tests for configurable identities, native round-trip, unconfigured requester, self-delegation, target drift, and cross-tenant observe/result denial before adapter invocation.
+- Did not modify `apps/gateway/src/commands/command-authorization.service.ts`.
+
+## Verification
+
+- `pnpm --filter @mosaicstack/coord test` — PASS (16 tests after authority/idempotency remediation).
+- `pnpm --filter @mosaicstack/coord build` — PASS.
+- `pnpm --filter @mosaicstack/gateway test -- mos-coordination.service.test.ts` — PASS (7 tests after authority/idempotency remediation).
+- Standalone gateway typecheck initially reported missing built workspace packages after fresh worktree setup; root validation builds the workspace graph and passed.
+- `TURBO_FORCE=true pnpm typecheck` — PASS (42 tasks, 0 cached).
+- `TURBO_FORCE=true pnpm lint` — PASS (23 tasks, 0 cached after one import-type remediation).
+- `TURBO_FORCE=true pnpm format:check` — PASS.
+- `TURBO_FORCE=true pnpm test` — PASS (42 tasks, 0 cached; expected existing integration skips only).
+
+## Review checkpoint
+
+- Codex code review found idempotency keys needed actor scope and concurrent retries needed an in-flight reservation; both were remediated with regression coverage.
+- Codex security review found whitespace-equivalent self-delegation was accepted by the exported client; identities are now normalized before invariant checks, with regression coverage.
+- Re-review added immutable payload comparison for idempotency reuse, runtime string/size validation, bounded TTL/capacity tracking for gateway and native adapter state, and fresh-correlation follow-up reads; targeted tests pass (16 coord / 7 gateway).
+- Final Codex security review found no issues. PR #735 was opened from commit `7936e15d`; Woodpecker pipeline #1752 is green.
--- a/docs/scratchpads/tess-m4-003-operator-plugins.md
+++ b/docs/scratchpads/tess-m4-003-operator-plugins.md
@@ -0,0 +1,27 @@
+# TESS-M4-003 — Operator Plugin Foundations
+
+- **Task:** TESS-M4-003 / TESS-MEM-001
+- **Branch/base:** `feat/tess-operator-plugins` rebased on `origin/main` `76325ca3`
+- **Scope:** first leaf-package memory/retrieval slice only; no durable inbox ownership, gateway integration, or Mosaic catalog implementation.
+
+## Handoff
+
+Coder4's uncommitted implementation was preserved first in commit `5b99c821` before review. The completion pass corrected the contract so namespace is injected configuration rather than caller-selected scope data, storage keys include tenant/owner/session via collision-safe tuple encoding, and malformed runtime scope values fail closed.
+
+## Delivered boundary
+
+- `OperatorMemoryPlugin` exposes `capture`, `search`, `recent`, `stats`, and `startupContext` through `MemoryAdapter` only.
+- Scope is server-derived `{tenantId, ownerId, sessionId}`; adapter and namespace are configuration, not operation input.
+- Capture redacts before persistence and records configured instance/namespace/source provenance.
+- Wildcard retrieval is documented at the `MemoryAdapter` boundary and implemented by the keyword adapter.
+- Startup context uses a bounded 64-result candidate window, then prioritizes project and flat-file provenance before slicing the configured output limit.
+- No `Tess` identity is hardcoded in storage keys or defaults; tests use configured `Nova`.
+
+## Verification
+
+- `pnpm --filter @mosaicstack/memory test` — PASS (32 tests)
+- `pnpm --filter @mosaicstack/memory typecheck` — PASS
+- `pnpm --filter @mosaicstack/memory lint` — PASS
+- `pnpm --filter @mosaicstack/memory build` — PASS
+- Codex code review — APPROVE after remediation
+- Codex security review — no findings after runtime scope-validation remediation
--- a/docs/tess/ARCHITECTURE.md
+++ b/docs/tess/ARCHITECTURE.md
@@ -41,7 +41,7 @@ Every call receives an immutable, server-derived actor/tenant/channel scope and

 `@mosaicstack/agent` owns the explicit `AgentRuntimeProviderRegistry`; duplicate provider IDs are rejected rather than replaced. Gateway owns `RuntimeProviderService`, which creates a frozen `RuntimeScope` from authenticated `ActorTenantScope` and trusted ingress channel/correlation metadata before every provider call. The service checks the declared provider capability before invoking a side effect and records metadata-only audit events (`providerId`, operation, outcome, actor/tenant/channel, correlation, and resource ID). It never records message bodies, idempotency keys, or approval references.

-Termination is fail-closed: a runtime approval verifier must consume a one-time, exact action binding for the provider, session, actor, tenant, channel, and correlation ID before `terminate` reaches a provider. Until the durable verifier is wired, the default verifier denies termination. This internal service introduces no HTTP endpoint; later Discord, CLI, MCP, and provider adapters consume the same gateway boundary.
+Termination is fail-closed: a runtime approval verifier consumes a one-time, exact action binding for the provider, session, actor, tenant, channel, and correlation ID before `terminate` reaches a provider. The verifier reuses the Redis-backed `interaction:command-approval:*` store and its expiry/delete-on-consume semantics; it has no parallel approval store. This internal service introduces no HTTP endpoint; later Discord, CLI, MCP, and provider adapters consume the same gateway boundary.

 ## Authority Model

@@ -52,11 +52,49 @@ Termination is fail-closed: a runtime approval verifier must consume a one-time,
 | Destructive, privileged, external/customer-visible action                   | Human approval + policy | Propose, wait for durable one-time approval, then execute idempotently |
 | Provider-specific unsupported action                                        | None                    | Fail closed; never emulate silently                                    |

+### Mos Coordination Boundary
+
+`@mosaicstack/coord` exposes only the transport-neutral `MosCoordinationPort`
+verbs `handoff`, `observe`, and `result`. Gateway derives the actor, tenant,
+correlation, and interaction-agent identity from authenticated context plus
+trusted configuration; callers never provide an orchestration target. It
+rejects unconfigured identities, self-delegation, target/correlation drift, and
+cross-tenant handoff reads before an adapter call. No dispatch, assignment,
+review, merge, or cancellation API exists at this boundary.
+
+M4 uses a deterministic native in-process queue adapter to prove the handoff →
+observe → result flow without coupling the contract to tmux. A fleet/tmux
+adapter is deferred to the M5 live-deployment seam and must implement the same
+port.
+
 ## Session and State Model

 A Tess session has stable `sessionId`, `tenantId`, `ownerId`, provider/runtime identity, ingress bindings, cursor, checkpoint, inbox/outbox, and idempotency records. Discord and CLI bind to the same authorized session. Ownership is verified server-side on every list/read/attach/send/terminate operation.

-Valkey may hold ephemeral coordination state; PostgreSQL is canonical for durable session bindings, approvals, audit, checkpoints, inbox/outbox, and idempotency. Pi session files are replay sources, not cross-agent truth.
+Valkey holds the existing short-lived, one-time command-approval records; PostgreSQL is canonical for durable session bindings, checkpoints, inbox/outbox, and idempotency. Pi session files are replay sources, not cross-agent truth.
+
+### M2 Durable Recovery
+
+`@mosaicstack/agent` owns a transport-neutral state machine and `apps/gateway` provides its
+PostgreSQL adapter. `interaction_sessions` holds immutable identity; inbox/outbox records use a
+per-session unique idempotency key and transition `pending → processing → processed|delivered`.
+Checkpoints are immutable history scoped by session and checkpoint ID: the latest checkpoint
+supports compaction recovery, while a handoff always resolves the exact checkpoint it references.
+Recovery requeues only interrupted inbox work; an ambiguous `processing` outbox record is preserved
+until separately authorized reconciliation can establish its external delivery state.
+
+Provider sends travel through the existing `RuntimeProviderService` with the persisted outbox
+idempotency key. A normal dispatch claims exactly one outbox record and verifies its stored
+correlation and channel against the server-derived request scope; it never requeues or drains
+another live record. Inbox/outbox payloads and checkpoint cursor/summary pass through the existing
+secret/PII redactor and AES-256-GCM sealing before persistence; decryption occurs only in the
+scoped gateway repository path, and runtime audit remains metadata-only.
+
+An external effect cannot share a database transaction. If a process dies after an effect begins
+but before its terminal outbox transition, automatic recovery does not replay that ambiguous claim.
+It remains `processing` until separately authorized reconciliation can establish delivery state;
+completed effects are never redispatched. Operators can therefore restart the gateway/Pi service,
+reconstruct the session, and resume pending inbox work without relying on process-local state.

 ## Transport Strategy

@@ -81,3 +119,5 @@ The provider advertises list, tree, read-only attach, send, and terminate. List/
 ## Deployment

 Tess runs as a rostered, systemd-supervised Pi agent using GPT-5.6 Sol and high reasoning. Secrets are supplied through approved runtime secret mechanisms. Startup fails when required model, gateway identity, Discord binding, or durable-state dependencies are missing. Health reports effective model/reasoning/tool policy without credential material.
+
+The interaction-service identity is provisioning data, not a source identifier: the roster and per-agent environment carry the chosen display/roster name into a generic systemd instance. The service rejects a name mismatch or any drift from its pinned Pi/GPT-5.6 Sol/high/operator-interaction effective policy before launch. Its policy printer exposes only those resolved safe fields.
--- a/docs/tess/M4-003-OPERATOR-PLUGIN-SKETCH.md
+++ b/docs/tess/M4-003-OPERATOR-PLUGIN-SKETCH.md
@@ -0,0 +1,17 @@
+# TESS-M4-003 Operator Plugin Sketch
+
+## Memory/retrieval slice — TESS-MEM-001
+
+Introduce a transport-neutral `OperatorMemoryPlugin` in `packages/memory`. The plugin receives a server-derived `{tenantId, ownerId, sessionId}` scope and delegates to a registered `MemoryAdapter`; adapter and namespace are injected configuration, never caller input. Its operations are `capture`, `search`, `recent`, `stats`, and `startupContext`. Results carry configured instance, provenance, and namespace metadata. Capture/redaction occurs before adapter persistence; startup context uses a bounded candidate window ordered so project/flat-file truth takes precedence within returned material.
+
+Registration remains replaceable-adapter based: the existing `registerMemoryAdapter(kind, factory)` / `createMemoryAdapter(config)` seam supplies the injected adapter to `createOperatorMemoryPlugin(config)`. Identity and namespace are configuration data; no interaction-agent name is embedded in keys or defaults.
+
+## Remaining plugin foundations — TESS-PLG-001
+
+- `packages/agent`: capability descriptors for runtime bootstrap, durable inbox/state hooks, and read-only fleet diagnostics. Each capability advertises supported operations and fails closed when absent.
+- `packages/mosaic`: a catalog/registration surface for GitOps, fleet diagnostics, runtime bootstrap, Discord, and MCP/skill discovery. Catalog entries describe authority, input schema, and safe/read-only status; they do not invoke provider transports directly.
+- Gateway/channel adapters consume these contracts through server-derived actor/tenant context and durable session state, preserving the replaceable-adapter boundary.
+
+## First implementation boundary
+
+The first PR slice should add the operator-memory plugin contract, configuration-injected adapter seam, scope isolation, provenance-bearing retrieval, and tests for namespace isolation plus a differently named configured instance. Durable inbox/outbox remains owned by the existing `DurableSessionCoordinator`; this plugin only supplies bounded context/capture at lifecycle boundaries.
--- a/docs/tess/MOS-COORDINATION.md
+++ b/docs/tess/MOS-COORDINATION.md
@@ -0,0 +1,83 @@
+# Tess–Mos Coordination Contract Sketch
+
+**Task:** TESS-M4-001 · **PRD:** TESS-MOS-001 / AC-TESS-04
+
+## Boundary
+
+Agent identities are deployment data. A configured interaction agent may request
+Mos-owned work; the configured orchestration agent owns decomposition, worker
+assignment, reviews, and merge decisions. The interaction agent receives a
+correlated receipt, read-only activity projection, and terminal result. It has
+no dispatch, assignment, review, merge, or cancellation operation.
+
+## `@mosaicstack/coord` interface
+
+```ts
+interface CoordinationScope {
+  readonly actorId: string;
+  readonly tenantId: string;
+  readonly correlationId: string;
+  readonly requesterAgentId: string; // trusted gateway/configuration data
+}
+
+interface MosHandoffRequest {
+  readonly idempotencyKey: string;
+  readonly summary: string;
+  readonly context?: string;
+  readonly missionId?: string;
+}
+
+interface MosHandoffReceipt {
+  readonly handoffId: string;
+  readonly targetAgentId: string;
+  readonly status: 'accepted' | 'queued';
+  readonly correlationId: string;
+}
+
+interface MosHandoff {
+  readonly handoffId: string;
+  readonly targetAgentId: string;
+  readonly request: MosHandoffRequest;
+  readonly scope: CoordinationScope;
+}
+
+interface MosCoordinationPort {
+  handoff(handoff: MosHandoff): Promise<MosHandoffReceipt>;
+  observe(handoffId: string, scope: CoordinationScope): Promise<CoordinationObservation>;
+  result(handoffId: string, scope: CoordinationScope): Promise<CoordinationResult>;
+}
+```
+
+The port deliberately omits generic orchestrator verbs. It is tenant- and
+correlation-scoped; its gateway implementation obtains `actorId`, `tenantId`,
+and the requester agent from trusted authentication/configuration only.
+
+## Enforcement point
+
+`apps/gateway` owns a `MosCoordinationService` boundary that compares the
+trusted configured requester/target identities and rejects all of the following
+before calling a transport: unconfigured requester, self-delegation, target
+identity drift, cross-tenant observe/result lookup, and attempts to observe or
+receive a result for a handoff outside the originating tenant. The service exposes handoff, observe,
+and result only, and delegates delivery to an injected adapter.
+
+M4 ships a native in-process `InMemoryMosCoordinationPort` as the concrete,
+deterministic adapter. It preserves the immutable handoff ID, tenant, requester
+identity, and correlation ID while demonstrating the handoff → observe → result
+round trip. It is a queue/port adapter, not a Mos-side consumer.
+
+A future fleet/tmux adapter is a documented M5 deployment seam and must
+implement the same `MosCoordinationPort`; no channel client or interaction
+runtime calls a transport directly.
+
+## Required tests
+
+1. A configured non-default interaction identity can hand off work to a
+   configured non-default orchestration identity and receive its result.
+2. The gateway passes only server-derived scope/identity to the adapter.
+3. Self-targeting, target drift, and cross-tenant observe/result all fail closed
+   without invoking the adapter.
+4. The exported public contract has no worker-dispatch, assignment, review,
+   merge, or cancellation capability.
+5. The native adapter round-trips queued work, activity, and a host-recorded
+   terminal result without a live fleet dependency.
--- a/docs/tess/VERIFICATION-MATRIX.md
+++ b/docs/tess/VERIFICATION-MATRIX.md
@@ -5,7 +5,7 @@
 | AC-TESS-01           | TESS-PI-001, TESS-DSC-001, TESS-CLI-001  | Discord/CLI same-session integration and streaming E2E                                                                                                                                                                                                                                                                                                                                                                | M3-V             |
 | AC-TESS-02           | TESS-ARP-001, TESS-CLI-001, TESS-FLT-001 | CLI contract tests for status/sessions/tree/attach/send/stop, typed denial/error snapshots                                                                                                                                                                                                                                                                                                                            | M3-V             |
 | AC-TESS-03           | TESS-PI-001, TESS-OBS-001                | Clean service launch; status asserts GPT-5.6 Sol, high reasoning and effective tool policy with secret canaries absent                                                                                                                                                                                                                                                                                                | M2-V, M3-V       |
-| AC-TESS-04           | TESS-MOS-001, TESS-FLT-001               | Authority E2E: coding request creates Mos handoff; safe status runs in Tess; no competing worker claim                                                                                                                                                                                                                                                                                                                | M4-V             |
+| AC-TESS-04           | TESS-MOS-001, TESS-FLT-001               | M4 contract/gateway native-port handoff → observe → result round trip; configurable identity, target-drift and tenant-denial tests; M4-V fleet authority qualification                                                                                                                                                                                                                                                | M4-001, M4-V     |
 | AC-TESS-05           | TESS-HRM-001, TESS-MEM-001               | Hermes capability contract suite: sessions/stream/send/tree plus Kanban/skills/memory/tools/cron supported-or-denied matrix; operator-memory plugin (TESS-MEM-001) reachable end-to-end — env-configured plugin registered + AgentService session-bound server-derived {tenantId,ownerId,sessionId} scoped search/capture, cross-tenant reuse denied before plugin call (M4-W-001 spine: #736 plugin + #739 consumer) | M4-V             |
 | AC-TESS-06           | TESS-STA-001, TESS-SEC-008               | Kill/restart/compaction fault injection across inbox/outbox/checkpoint transitions; duplicate side-effect detector                                                                                                                                                                                                                                                                                                    | M2-V, M5-V       |
 | AC-TESS-07           | TESS-SEC-001..009                        | Threat-model abuse suite: authz, tenant isolation, forged identity/approval, injection, redaction, transport identity, GC scope                                                                                                                                                                                                                                                                                       | M1-V, M3-V, M5-V |
--- a/docs/tess/hermes-runtime-adapter-design.md
+++ b/docs/tess/hermes-runtime-adapter-design.md
@@ -0,0 +1,19 @@
+# TESS-HRM-001 — Hermes runtime adapter boundary
+
+## Normalized provider surface
+
+`HermesRuntimeProvider` implements the existing Mosaic-owned `AgentRuntimeProvider` unchanged. Its public surface is therefore `capabilities`, `health`, session list/tree, stream, send, attach/detach, and terminate, accepting only `RuntimeScope`, `RuntimeMessage`, `RuntimeSession`, `RuntimeStreamEvent`, and other types from `@mosaicstack/types`. Provider id is `runtime.hermes`.
+
+The provider receives a narrow injected `HermesRuntimeTransport`, whose method names and inputs may represent Hermes API operations but whose return values are explicitly private `HermesLegacy*` types defined only in `packages/agent/src/hermes-runtime-provider.ts`. Mapping functions convert those private values to Mosaic sessions, state, hierarchy, and stream events. Capability negotiation maps a supplied Hermes feature inventory onto the fixed Mosaic runtime capability vocabulary; no unknown/ambiguous legacy feature is advertised. Unsupported Mosaic operations throw the typed fail-closed `capability_unsupported` provider error before a transport call.
+
+## Boundary line
+
+**Hermes legacy schema ends at `HermesRuntimeTransport` and its private adapter-local `HermesLegacy*` definitions in `packages/agent`.** `packages/types` is never changed to contain a Hermes field, enum, identifier, session shape, status, or capability. `apps/gateway` registers/resolves the provider only through `AgentRuntimeProvider` and receives normalized values only. Identity remains server-derived `RuntimeScope` data and is passed to the injected transport as context, never reconstructed from a legacy response.
+
+## Initial mapping and safety posture
+
+- Hermes conversation/thread identifiers map to opaque Mosaic `RuntimeSession.id`; parent linkage maps only when a known parent exists.
+- Hermes status strings map through a closed lookup to `RuntimeSessionState`; unknown statuses become `failed`, never a permissive active state.
+- Legacy stream chunks map to `message.delta` / `message.complete`; malformed or unsupported events become a normalized `runtime.error` event.
+- Send, attach, and terminate require the normalized capability first. `terminate` continues to be approval-bound by the gateway service; the adapter does not weaken gateway authority.
+- Kanban, skills, memory, tools, and cron are capability-inventory entries for this transitional adapter, not additions to the core runtime contract. They are reported as explicitly unsupported until a Mosaic-owned capability contract exists.