[SUPERSEDED by #45] docs: plan TRUST-001 experiment on stock OpenCode

docs/experiments/trust-001/ARCHITECTURE-RECOMMENDATION.md

@@ -0,0 +1,92 @@
+# Architect recommendation — stock OpenCode TRUST-001 candidate
+
+Status: **Gate 1 PASS; recommended experiment candidate, not selected architecture**.
+
+## Recommendation
+
+Following independent Gate-1 review, the owner may consider a separate Authorization A to investigate:
+
+> A runner-owned trusted bridge plugin loaded by **stock OpenCode v2.0.23**, proxying the bounded Loom plugin API to an isolated Loom execution domain, while host-side runner code owns evidence collection, safety, scope accounting, and persistence.
+
+No OpenCode modification is permitted.
+
+## Why this candidate
+
+It preserves the existing normal runner entrypoint and stock OpenCode Tool/Session semantics while moving evaluated Loom module execution out of the trusted OpenCode process.
+
+It reuses a natural supported extension point—the stock plugin API—without requiring a new workflow engine, state API, permission engine, or OpenCode fork.
+
+## Important revision from the earlier candidate
+
+The candidate is **not** simply "put Loom in another process."
+
+The trust design must separately address:
+
+- stock shell subprocesses executing under the OpenCode runtime's OS authority;
+- project/config plugin-loading escape paths;
+- capability/evidence channel authority;
+- synchronous transform fidelity;
+- Code Mode inner finality.
+
+Process topology alone is not evidence of TRUST-001.
+
+## Proposed boundary
+
+### Trusted
+
+- host runner launcher/verifier;
+- host collector/scope/safety/writer;
+- stock OpenCode v2.0.23 core;
+- runner bridge plugin;
+- reviewed protocol/correlation implementation;
+- kernel/OCI enforcement assumptions.
+
+### Untrusted for evidence authority
+
+- Loom module/dependencies;
+- Loom callbacks/handlers/policy logic;
+- Loom children;
+- model/product data;
+- built-in shell subprocesses;
+- writable workspace;
+- arbitrary external plugins.
+
+## No OpenCode patch fallback
+
+If stock OpenCode's supported APIs cannot establish a Loom contract requirement, the only valid outcomes are:
+
+- supported by runner-owned wrapping;
+- `UNPROVEN`;
+- `UNSUPPORTED`.
+
+"Patch OpenCode" is not an allowed resolution.
+
+## Why v2.0.23
+
+Compared with v2.0.18 it exposes more Session lifecycle API, including parent Session creation, removal, compaction, and metadata updates.
+
+However the plugin loader, plugin hooks, Tool execution path, Tool runtime, and plugin supervisor relevant to TRUST-001 remain unchanged. v2.0.23 does not itself isolate plugins.
+
+## Candidate strengths
+
+- pinned Loom needs only a bounded subset of PluginHost;
+- Loom moves most normal state to its own SQLite after setup, reducing capability-broker state surface, while bounded stock plugin-storage `get/set/scan` remains available for pinned Loom's lazy legacy-compatibility path;
+- stock live Session events provide strong native ancestry/called/terminal facts;
+- runner proxy Loom tools can allocate trustworthy child correlation without changing tool inputs;
+- Loom semantics remain executed by Loom.
+
+## Candidate risks
+
+1. **Code Mode inner finality** — stock public metadata does not expose each inner final script-visible result/error.
+2. **Mixed OS trust** — shell subprocesses share the OpenCode runtime domain.
+3. **Plugin loading** — evaluated paths must not cause new in-process plugin imports.
+4. **Synchronous transforms** — stock transform callbacks are synchronous/replayable.
+5. **Callback/cancellation fidelity** — RPC separation must preserve shared mutable event behavior and late-response rules.
+6. **First-sink confidentiality** — new bridge/capability/collector paths must not persist secrets before projection.
+7. **Scope sealing** — apparent quiescence is not complete evidence until trusted admission is closed and the collector has drained a generation-scoped final sequence.
+
+## Recommendation status
+
+**Gate 1: PASS.** The corrected planning package is coherent and bounded enough for the owner to consider a separate Authorization A for construction and explicitly named provider-free preflights.
+
+This review does not grant Authorization A, prove feasibility, or authorize semantic/adversarial/model-backed execution.

docs/experiments/trust-001/AUTHORITY-MANIFEST.md

@@ -0,0 +1,115 @@
+# Effective-authority manifest
+
+Status: **proposed Wave-1 boundary; not yet experimentally verified**.
+
+## Principle
+
+Different processes/containers do not automatically create TRUST-001. Effective write/control authority is the criterion.
+
+## Proposed filesystem and mount authority
+
+| Resource | Host collector | Stock OpenCode domain | Isolated Loom domain | Requirement |
+|---|---|---|---|---|
+| evaluated workspace | no direct execution | requested RO/RW | same requested RO/RW where Loom semantics require it | product state only |
+| runner/bridge source | host-owned | read-only | none | never workspace-writable |
+| stock OpenCode executable/root | no mutation | read-only image | none | immutable stock v2.0.23 |
+| Loom source/dependencies | provenance only | **not imported/executed** | read-only | module boundary begins before evaluation |
+| OpenCode disposable HOME/XDG | no | private tmpfs/state | none | invocation-local |
+| Loom HOME/XDG/state | no | none | private | invocation-local; Loom owns its local runtime state |
+| collector/evidence storage | read/write | **not mounted** | **not mounted** | evaluated code cannot modify evidence |
+| safety policy/inventory | host-private | delivered only to trusted bridge/collector through reviewed private path | no raw policy | no credential-policy disclosure |
+| container-engine socket | host runner only if required | none | none | never exposed |
+| evidence-channel bootstrap endpoint | host-created private runtime dir | bridge bootstrap only | **not mounted/reachable** | never under workspace; removed after admitted connection |
+| capability-channel bootstrap endpoint | host-created private runtime dir | bridge endpoint only | Loom endpoint only | separate from evidence channel; removed after admitted connection |
+
+## Channel authority and bootstrap
+
+The design requires **two distinct channels with different authority**:
+
+1. **evidence channel** — trusted runner bridge → host collector. This is the only channel allowed to introduce candidate runtime observations into evidence authority.
+2. **capability channel** — runner bridge ↔ isolated Loom. This transports product callbacks, requests, mutations, and results only. It is untrusted for evidence authority.
+
+The channels MUST NOT share an accepted descriptor, listener path, authentication material, or message type that the collector could interpret as evidence. The capability channel has no direct evidence-write authority, but its transport admission/correlation must bind every accepted response to the admitted Loom generation. Loss of that authenticity/integrity makes affected evidence ineligible.
+
+The candidate should avoid a reusable credential in `process.env`, because stock shell inherits `process.env` when no Session-specific environment overrides it.
+
+### Evidence-channel bootstrap
+
+1. runner creates a private Unix-domain endpoint outside the workspace;
+2. only the stock OpenCode domain receives bootstrap reachability; the isolated Loom domain never receives the collector endpoint;
+3. the bridge connects during activation **before inference/tool execution**;
+4. host admits only the expected stock OpenCode process hosting the reviewed bridge, using runner-owned process/container identity plus kernel peer identity where available;
+5. the listener is closed/unlinked immediately after the expected connection is admitted;
+6. the established descriptor is close-on-exec and must not be inherited or duplicated by stock shell subprocesses;
+7. reconnect is unsupported in the bounded experiment.
+
+### Capability-channel bootstrap
+
+1. runner creates a separate private endpoint outside the workspace;
+2. only the expected bridge side and isolated Loom generation may establish it;
+3. the listener is closed/unlinked after the expected peers are admitted;
+4. this channel has no collector credential, evidence framing authority, or evidence-write capability;
+5. duplication, impersonation, or integrity loss makes affected product work failed/unresolved and affected evidence ineligible; an unadmitted process may never be silently accepted as the Loom peer.
+
+Both bootstraps remain **UNPROVEN** until provider-free construction/preflight. They are specified here so Gate 1 reviews concrete authority separation rather than process topology alone.
+
+## Process authority
+
+Required candidate controls:
+
+- read-only container roots;
+- non-root execution;
+- dropped Linux capabilities;
+- no-new-privileges;
+- default or stricter seccomp;
+- no host PID namespace;
+- no Docker/Podman control socket;
+- no evidence volume in evaluated domains;
+- no bridge secret in process environment;
+- core dumps disabled or guaranteed non-persistent/unavailable to evaluated code.
+
+The provider-free preflight must specifically test whether evaluated shell/Loom children can:
+
+- ptrace or use `process_vm_readv/writev` against the trusted OpenCode process;
+- use `pidfd_getfd` or `/proc/<pid>/fd` to duplicate bridge descriptors;
+- access `/proc/<pid>/mem`;
+- discover a still-connectable collector listener;
+- signal/kill trusted work.
+
+Killing/suppressing trusted work is not by itself a false-evidence violation: it must become incomplete/non-evidence. Reading/duplicating the trusted channel or creating eligible records is a rejection.
+
+## Plugin-loading authority
+
+Stock OpenCode builds an effective plugin-source operation set from configuration documents, configuration roots, auto-discovered `plugin/` and `plugins/` entries, configured package/local targets, and watched source/config changes. Protecting only the final plugin file is therefore insufficient.
+
+Before activation the candidate MUST build a **plugin-source closure manifest** that:
+
+1. records the exact effective plugin add/remove operation set;
+2. enumerates every configuration document/root, discovery directory, configured local source, package declaration, symlink target, and watched input that can change that operation set for the tested profile;
+3. admits only runner-owned trusted bridge code for in-process execution;
+4. makes every operation-set input runner-owned and read-only/unreachable to evaluated write authority for the generation;
+5. preserves required non-plugin project inputs separately;
+6. treats any post-activation operation-set change, newly discovered source, or changed admitted source identity as a checkpoint stop/rejection, not a hot reload.
+
+A practical runner-owned approach may use read-only submounts/overlays for the exact source/config closure while leaving the requested workspace mode unchanged elsewhere. Authorization A must name the concrete paths and operation set for its checkpoint.
+
+If stock OpenCode cannot keep this source closure immutable without changing required Loom behavior, the tested profile is **UNSUPPORTED**.
+
+## Network authority
+
+- Collector endpoint is not a general network service.
+- Loom capability channel exposes only the reviewed typed capability protocol.
+- Evaluated network access cannot provide an alternate route to collector, runner, container engine, or another trusted service.
+- Any network mode needed by Loom/provider behavior is reported separately from capability/evidence-channel reachability.
+
+## Credentials
+
+- Provider credentials are product inputs, not evidence authority.
+- Evidence-channel/capability-channel admission material, if ultimately required, is not carried in argv, process environment, workspace, project config, Loom state, or mounted readable files.
+- A product credential can never authenticate evidence.
+
+## Current verdict
+
+Effective-authority separation: **UNPROVEN**.
+
+This is expected before candidate construction. The Gate 1 PASS means only that these proposed controls are coherent enough for the owner to consider a separately authorized provider-free prototype; it does not mark them experimentally proven.