98 lines
4.8 KiB
Markdown
98 lines
4.8 KiB
Markdown
---
|
|
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?
|