comms: usc 20260715T194752Z

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?