---
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?