feat(tess): add Mos coordination boundary

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.