comms: usc 20260715T194752Z
This commit is contained in:
wjarvis mos-comms
97
comms/20260715T194752Z__from-usc__1589519536.md
Normal file
97
comms/20260715T194752Z__from-usc__1589519536.md
Normal file
@@ -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?
|
||||
Reference in New Issue
Block a user