docs(plans): plan offloading the harness to another device

[jonathanKingston]

Summary

• add docs/plans/cross-device-harness-offload.md, a plan for running the harness on a second machine while the desktop stays in charge and the laptop is free to close
• reconcile it with thread-in-container.md, which landed the loop-in-guest half while this was open
• correct two plan statuses that no longer matched main, and register the new plan in the index

What changed since this was opened

main moved 197 commits and merged the container work, which falsified this plan's central qualification. It said "the runtime is portable and unused"; src/main/services/container-runtime/worker-entry.ts now calls runHeadlessAgent inside a guest container, so main-process code drives the portable runtime off the desktop today. The plan says that instead of the original claim.

The honest position is that this plan is partly overtaken:

Phase	Status
O0 worker entry	Delivered for a disposable local container
O3 unattended + deferral	Delivered — unattended ledger, zero prompts, git push deferred
O4 leased credentials + egress	Delivered, and more strictly than proposed here: --network none plus a per-origin unix-socket broker is execution-runtime-security.md R3's broker-only egress, met for that runtime
O1 fenced writer lease	Unbuilt — thread-in-container.md parks it as T2
O2 attach / detach / reattach	Unbuilt — same T2

So the remaining value here is the ownership half. O1/O2 and T2 name the same mechanism (the per-thread writer lease from acp-session-continuity.md), and should be one piece of work rather than two. Where the two plans disagree, the shipped prototype wins — stated in the document.

Why the plan still earns its place

The argument it makes is that offloading is an ownership problem, not a transport one: the thread store's mutual exclusion is an in-process mutex rather than a file lock, so two processes over one workspace have no mutual exclusion at all. A fenced lease therefore comes before any second worker. That is unaddressed on main, and it is the exit gate thread-in-container.md sets for T2 ("close the desktop mid-run, reopen, and observe one converged thread").

It also records the measurement (30 of 517 non-test src/main files name electron, 13 for types only, so 17 at runtime; none on the agent, tool, hook, sandbox or thread-store path), the execution table including the container column, and nine binding decisions. Two of those now have a shipped prototype agreeing with them: Decision 7 (containment must be proven before unattended) matches the attestation, and Decision 8 (one leased credential in the worker) matches the narrowing of unattended-runs.md Decision 3.

Boundary with the other plans

• library-splits.md did the extraction that makes the question worth asking.
• client-server-split.md (#2312) owns the mechanism; step 4's copse-core daemon is this plan's worker.
• thread-in-container.md owns the runtime, the contained-effect gate, the egress broker and the credential narrowing. It is the senior sibling and landed first.
• This plan settles neither how the packages are cut, nor how the protocol is versioned, nor how the container is hardened.

Status corrections

Both verified against the tree, not inferred:

• Headless automation contract — the doc said Phases 0–1 were "not yet on main". The contract module, its published JSON Schema, gen:headless-schema, and the bench consumer are all on main. Restated as Phase 0 landed.
• Deferred approvals — the index said D0 only, while the doc says D0–D1 landed; deferral-mode.ts and deferred-approval-store.ts are on main. Index aligned to the doc.

The index's "Last audited" date is deliberately unchanged: this corrects three rows, it is not a full audit.

Validation

Documentation only; no source, schema, or fixture changes.

• rebased onto current main (a288035), no conflicts
• oxfmt --check passes across all 77 files in docs/plans/
• every relative link resolves, including the new thread-in-container.md references
• the index note is kept under the table's existing column width so the formatter does not re-pad every row; the index diff stays confined to the three rows this PR owns
• the last full run with ci-full was green end to end, including all 8 e2e shards and screenshot-artifacts; CI re-runs on this head

Review note

The ci-full label is still applied. Now that this is out of draft it is only needed to defeat the oracle's docs-only thinning, which zeroes the e2e shards — remove it if you would rather this PR stop running the heavy tier on every push.

🤖 Generated with Claude Code

https://claude.ai/code/session_011i4xR3bwms6hEJDdd449qo

[github-actions]

🖥️ PR preview

• Marketing site
• Browser demo
  Interactive, with a mocked backend — jump to a scenario:
• Builds a cupcake site
• Agent-proposed edits open the Changes panel
• Markdown list indentation
• Unattended container run
• Responsive composer footer
• Subagent display visual reference
• Subagent stays ungrouped beside reading tools
• Semantic search subagent markdown
• Light-theme approval with a bright accent
• Light-theme syntax, fills, and selection
• Grouped outside-sandbox command approval
• Remote desktop discovered-port list with one selected
• Settings scroll + sticky footer geometry
• Per-model reasoning / temperature / top-p
• Thread switch hydration notice
• Thread switch hydration failure
• Chat layout styling
  _{Static demo of the renderer against a mock API — the browser pane, terminal, and all main-process IPC are stubbed, so it never proves main-process behaviour. Rebuilt whenever a push changes the demo bundle; these links go live once the queued deploy lands, shortly after this comment. Removed when the PR closes.}

[jonathanKingston]

Audit result: the documentation diff is internally consistent, git diff --check is clean, GitHub reports it mergeable, and its CI gate is green. It is two main commits behind, but there is no source/runtime validation gap to investigate in this docs-only proposal.

I would not open another implementation issue yet. The Proposed plan is the decision artifact; if Decisions 7/8 are accepted and work is scheduled, create one implementation tracker then (or convert/link an existing roadmap issue) rather than duplicating the unresolved design discussion now. Keep draft until that decision review is complete.