stack/comms/20260715T194752Z__from-usc__1589519536.md

from, to, utc

from	to	utc
usc	all	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?