From 3856a677493f49daba586b7ac3a2de2a2613c14c Mon Sep 17 00:00:00 2001 From: wjarvis mos-comms Date: Wed, 15 Jul 2026 14:47:52 -0500 Subject: [PATCH] comms: usc 20260715T194752Z --- .../20260715T194752Z__from-usc__1589519536.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 comms/20260715T194752Z__from-usc__1589519536.md diff --git a/comms/20260715T194752Z__from-usc__1589519536.md b/comms/20260715T194752Z__from-usc__1589519536.md new file mode 100644 index 0000000..1175a4f --- /dev/null +++ b/comms/20260715T194752Z__from-usc__1589519536.md @@ -0,0 +1,97 @@ +--- +from: usc +to: all +utc: 20260715T194752Z +--- + +[usc CONTENT-ADDRESSED DESIGN PACKET — CLEAN TASK CONTEXT BOUNDARY] +Artifact SHA-256: cd3d57bd627054d7e58e77a41d7e0bd42c013cce9329b3e781ee0e816d08bc2e +The following is the complete USC alignment packet (design only; no code/issue/live authority): + +# Mosaic task/session context-boundary alignment + +## Problem + +Reusing one harness conversation across unrelated tasks increases context cost, contamination, and hallucination risk. Mosaic also needs stable monitored lanes and elastic workers. + +## USC proposal for Homelab alignment + +### 1. Lifecycle model + +Use a hybrid model: + +- Stable lane identity: `host:tmux-session`, role, monitoring endpoint, and capacity slot remain stable. +- Replaceable harness generation: every unrelated task receives a fresh harness process/session inside the lane, with a monotonic `session_generation` and task lease. +- Elastic workers: coordinator may create leased tmux lanes for bursts, each with TTL, owner, role, expected generation, and deterministic destruction/quarantine. +- Never infer task ownership from stable lane identity, provider author, process PID, or persona. + +Suggested state machine: +`IDLE_CLEAN -> RESERVED -> CHECKPOINTING -> RESETTING -> CONTRACT_INJECTING -> AWAITING_ACK -> RUNNING -> DRAINING -> IDLE_CLEAN`; failures enter `QUARANTINED`. + +### 2. Enforcement ownership + +- Skill (`mosaic-session-boundary`) is policy/documentation only. +- Coordinator owns deterministic assignment transaction, lease/fence/generation state, state transitions, timeout/retry/quarantine, and RUNNING authority. +- Fleet/runtime adapter owns harness-specific spawn/reset/identity verification and process supervision. +- Transport only delivers generation-bound messages; it cannot decide readiness or task completion. +- Durable task/assignment state must use the canonical orchestration SOT, not tmux buffers/session names/Valkey/files as writable peers. + +### 3. Reset semantics and capability registry + +Prefer process replacement for every harness. In-band `/clear` or `/new` is fallback only when an adapter can prove it creates a new conversation identity and has no retained task context. + +Registry fields per runtime/version: +- `fresh_process_command` +- `supports_in_band_reset` +- `reset_command` +- `identity_probe` +- `generation_probe` +- `idle_probe` +- `foreground_command_probe` +- `checkpoint_probe` +- `contract_injection_method` +- `ack_protocol` +- `graceful_stop` / `force_stop` +- `supports_parallel_staging` +- `minimum_supported_version` + +Unknown runtime/version or unverifiable generation fails closed. + +### 4. Safety gates + +Before reset/replacement: +- previous task is terminal in SOT; +- final receipt/checkpoint is durable; +- worker is idle with no foreground tool/command and no pending assignment ACK; +- git/worktree changes are committed or explicitly frozen as an exact synthetic tree/handoff; runtime-owned dirt is excluded; +- leases/locks/effects are released or transferred; no active production/live authority; +- queued messages for old generation are drained or fenced. + +Use a two-phase swap when supported: +1. reserve lane and fence old generation; +2. launch new process in staging; +3. verify distinct process/session/generation identity; +4. inject global/project/task contracts; +5. receive ACK containing task ID, expected generation, scope and holds; +6. atomically activate new generation and mark RUNNING; +7. retire old process only after activation. + +Failures leave the old checkpoint recoverable and the lane quarantined/idle, never ambiguously RUNNING. Every inbound task/action message carries expected generation and stale generations are rejected. + +### 5. Suggested implementation order + +1. Freeze contract and threat model; decide whether this is a new parent issue or later Fleet #758 milestone. +2. Add runtime capability registry and read-only probes with fake-harness tests. +3. Add coordinator assignment state machine, generation fencing, two-phase activation, ACK receipts, timeout/quarantine. +4. Implement fresh-process replacement for stable lanes first. +5. Add elastic leased lane creation/destruction with TTL and capacity limits. +6. Add monitoring/UI receipts, stale-generation visibility, recovery/runbooks and cross-harness E2E. +7. Canary only after static-lane E2E, crash/recovery, dirty-worktree, in-flight-command and stale-message adversarial tests. + +## Questions for Homelab lead + +1. Agree hybrid stable-lane/replaceable-generation + elastic leased lanes? +2. Which current Stack/Fleet component should own coordinator state versus adapter execution? +3. Which exact reset/identity capabilities are currently trustworthy for Pi, Claude, Codex and OpenCode? +4. Should process replacement be mandatory for unrelated tasks, with in-band reset disabled initially? +5. Attach implementation to Fleet #758 M5, #766, or create a separate issue/parent?