opencode-secrets-obfuscation 0.1.0 → 0.1.2

package/docs/history/10-p0-launch-prerequisites-review.md

@@ -1,186 +0,0 @@
-# P0 launch-prerequisites review: environment builder and runtime candidate
-
-Date: 2026-10-13
-Scope: `tests/support/opencode-environment.ts`,
-`tests/unit/opencode-environment.test.ts`,
-`tests/smoke/runtime-candidate.json`, and `docs/history/9-p0-launch-plan.md`,
-checked against `docs/history/2-p0-runtime-prerequisites.md`. The active Job
-Object/environment worker and all other helpers were excluded.
-
-## Verdict
-
-**No-go for launch as currently composed.** The pure builder is a sound
-synthetic allowlist/config-construction primitive, and the candidate pin is
-accurately unqualified. Before use in P0-BOOT, the launch contract must resolve
-the authentication/database mismatch below and select one exact command
-contract. Once the physical run-root/process containment boundary is separately
-qualified, the builder and candidate are suitable inputs for a controlled
-launch on a Windows x64 worker; they do not themselves prove startup
-isolation.
-
-## Verification
-
-- `node --test tests/unit/opencode-environment.test.ts`: **5 passed, 0 skipped**.
-- `npm.cmd exec -- tsc --noEmit --pretty false`: passed.
-- No OpenCode executable was launched. No user configuration, credentials,
-  shared service, or ambient environment was read.
-
-## What is correct
-
-### Environment builder
-
-- `buildOpenCodeEnvironment` does not read `process.env`; it accepts explicit
-  trusted OS values and copies only the fixed `ALLOWED_ENV` list
-  (`opencode-environment.ts:42-60,135-153`). The targeted test verifies that a
-  synthetic ambient marker and credential/proxy/plugin-like names are absent.
-- Derived data/cache/config/state/temp/database/cwd paths are rooted beneath
-  the resolved run root (`:114-132`). The path containment check correctly
-  handles the platform separator and rejects relative/escaping values.
-- Config is closed to the three intended values and rejects unknown, cyclic,
-  accessor-backed, or mismatched content (`:91-99`); serialization is of the
-  builder-owned frozen config, not caller content.
-- Runtime input validation uses own data descriptors and fixed fields
-  (`:74-89,101-111`), so the repaired malformed/getter cases return only the
-  fixed diagnostic. Returned environment, paths, and allowlist are frozen.
-- The names used here are supported by the pinned-source report: XDG roots,
-  `TEMP`/`TMP`, `ProgramData`, `OPENCODE_CONFIG_DIR`,
-  `OPENCODE_CONFIG_PROJECT_DISABLE`, `OPENCODE_CONFIG_CONTENT`, and
-  `OPENCODE_DB`. No unsupported service-discovery, proxy, plugin-path, or
-  credential-agent variable was invented in the builder.
-
-### Candidate and launch plan
-
-- `runtime-candidate.json` is explicitly `unqualified`, uses tag
-  `v2.0.28`/commit `026b106bc5d41b679ffc413264229c340871e4d3`, and records
-  distinct platform archive (`A5A212...FEAE2`) and extracted executable
-  (`9C59FC...FD3E3`) SHA-256 values. This agrees with the corrected source pin
-  report and does not confuse archive and member identity.
-- The candidate explicitly limits itself to Windows x64 and says ARM64 is not
-  qualified. It records source association without claiming reproducible-build
-  equality, and lists P0-BOOT/startup isolation as blockers.
-- The launch plan correctly forbids installed executable lookup, shared-service
-  discovery/control, user config, and ambient credentials. Its source-backed
-  `serve`/stdio/readiness and `/api/info` claims are bounded to the pinned tag
-  rather than presented as generic current-CLI behavior.
-
-## Must fix before using the composition
-
-### 1. Authentication contract is not representable by the builder
-
-The launch plan requires a synthetic `OPENCODE_PASSWORD` for the explicit
-foreground `serve` alternative (`docs/history/9-p0-launch-plan.md:22-27`), but
-`OPENCODE_PASSWORD` is absent from `ALLOWED_ENV` and the builder has no input
-for a per-run password (`opencode-environment.ts:42-60,135-153`). Passing that
-password by command-line, ambient inheritance, or an ad hoc environment merge
-would violate the stated launch contract.
-
-This is not a reason to add a general credential passthrough. Select exactly
-one supported mode: either use the source-verified standalone stdio contract
-whose child generates its own synthetic password, or extend the narrowly
-specified launch input/allowlist for a generated per-run password and ensure it
-never enters arguments, logs, public evidence, or the generic builder output.
-The readiness probe must authenticate using the corresponding private value.
-
-### 2. Candidate metadata disagrees with the builder's database mode
-
-`runtime-candidate.json:43-60` lists `OPENCODE_DB=:memory:`, while the builder
-sets `OPENCODE_DB` to the run-rooted file path `paths.database`
-(`opencode-environment.ts:126,152`). The launch plan also promises inspection
-of DB/state/log/temp files under the run root (`9-p0-launch-plan.md:66-72`).
-Choose and record one contract: a run-rooted file database for filesystem
-evidence, or `:memory:` with the corresponding loss of on-disk DB evidence.
-The candidate, launch plan, and first probe must assert the same value; a stale
-metadata value is a qualification false-pass risk.
-
-## Scoped limitations, not builder defects
-
-- The builder accepts a caller-supplied `root` and trusted OS values. It does
-  not inspect physical paths, symlinks/junctions, ACLs, ownership, or whether
-  the root is a private existing directory. That is correctly delegated to the
-  run-directory/containment boundary; the pure builder must not be credited
-  with proving it. The launch sequence must call it only after that boundary
-  returns a qualified root.
-- `trustedOs.path`, `systemRoot`, `comspec`, and `pathext` are intentionally
-  caller-supplied OS runtime values and are not required to be under the run
-  root. Their provenance and executable trust belong to the containment/launch
-  layer. The builder only validates type/length/no-control-character, not that
-  a caller supplied a genuine system binary or safe PATH.
-- Rooted strings do not prove that OpenCode will make no other reads. P0-BOOT
-  still must run the pinned executable and use synthetic marker files to verify
-  no user/system/ancestor config, shared service, inherited key, or unexpected
-  DB/cache/temp/log path is touched.
-- `OPENCODE_CONFIG_PROJECT_DISABLE=1` and the redirected `ProgramData` are
-  source-verified controls, not a universal sandbox. A later host release or
-  plugin/runtime path can change behavior; candidate identity and exact source
-  version must be asserted at runtime.
-- `snapshots: false`, `warming: false`, and `update: "disable"` constrain
-  behavior but do not establish service isolation or prevent every possible
-  network operation. They must not be used as startup-isolation evidence.
-- The candidate is Windows x64 only. The reviewed ARM64 worker cannot qualify
-  it merely by running under emulation or by passing the pure builder tests.
-
-## Required P0-BOOT prerequisites
-
-1. Resolve the password mode and database mode inconsistencies, update the
-   candidate/launch contract, and add a test that rejects any unapproved
-   environment merge.
-2. Materialize exactly `package/bin/opencode.exe`, verify its regular-file,
-   non-link, single-link identity and `9C59...FD3E3` hash after extraction, and
-   launch only after the separately qualified physical containment boundary is
-   active.
-3. Use the fixed environment and exact command from the pinned tag; parse only
-   bounded readiness output; authenticate `/api/info`; assert version `2.0.28`,
-   PID, run-owned URL, and run-rooted temporary/database paths without printing
-   passwords or raw responses.
-4. Prove zero shared-service attachment and inspect synthetic-marker state,
-   config, DB, cache, logs, and temp outputs. A successful API response alone is
-   insufficient.
-5. Stop only the contained owned process tree. Preserve raw evidence only in
-   the private run root and publish safe identity/status fields.
-6. Keep `runtime-candidate.json` status `unqualified` until those cases execute
-   on a Windows x64 worker and satisfy the qualification evidence contract.
-
-## Resolution review
-
-Date: 2026-10-13
-
-### Verification
-
-- `node --test tests/unit/opencode-environment.test.ts`: **6 passed, 0 skipped**.
-- No OpenCode host was launched; no user settings, credentials, shared service,
-  or ambient environment was read.
-
-### Must-reconcile items: resolved
-
-1. **Run-owned password:** `OpenCodeEnvironmentInput.password` is now required
-   (`tests/support/opencode-environment.ts:15-20`). The builder accepts only
-   exactly 64 lowercase hexadecimal characters (`:104-114`), includes
-   `OPENCODE_PASSWORD` in the immutable allowlist and immutable environment
-   (`:44-63,139-162`), and does not source it from `process.env`. The new test
-   rejects missing, empty, short, wrong-case/non-hex, and newline-containing
-   values (`tests/unit/opencode-environment.test.ts:92-101`). The launch plan
-   now requires the future caller to generate 32 CSPRNG bytes per run and pass
-   them through the private environment channel only
-   (`docs/history/9-p0-launch-plan.md:48-53`). This resolves the prior
-   composition mismatch without introducing a general credential passthrough.
-
-2. **Database mode:** the builder sets `OPENCODE_DB` to
-   `<private-root>/data/opencode.db` (`opencode-environment.ts:124-131,149-157`),
-   and the candidate metadata now records the same rooted file contract plus a
-   run-owned password placeholder (`tests/smoke/runtime-candidate.json:47-60`).
-   The new test asserts the exact rooted database path alongside the password
-   (`opencode-environment.test.ts:92-101`). The launch plan explicitly records
-   that this is a file database selected for inspectable sink evidence
-   (`docs/history/9-p0-launch-plan.md:48-53`). The prior metadata mismatch is
-   resolved.
-
-### Final verdict
-
-**The builder/candidate reconciliation is approved for the next launch-planning
-stage, conditional on the separately qualified containment boundary.** These
-changes establish a coherent private authentication/database input contract;
-they do not establish physical root safety, executable launch identity, process
-tree containment, filesystem/service isolation, or host qualification. The
-candidate remains `unqualified`, and actual P0-BOOT launch remains blocked
-until containment and runtime isolation evidence executes on a Windows x64
-worker. No claim is made from these six pure builder tests about a real host.

package/docs/history/11-p0-job-containment-review.md

@@ -1,188 +0,0 @@
-# P0 Windows job-containment primitive review
-
-Date: 2026-10-13  
-Scope: `tests/p0-host/windows-job.ps1`, its README, the six-case integration
-test, `tests/fixtures/job-child.mjs`, and `docs/history/7-p0-job-containment.md`.
-No OpenCode launch, code edit, commit, or Job Object worker work was included.
-
-## Decision
-
-**Narrow GO:** the supervisor is adequate as a scoped synthetic test primitive
-for the six trusted, generated-fixture cases exercised here: suspended launch,
-pre-resume assignment failure, direct-child/descendant timeout cleanup,
-bounded output overflow, explicit native empty-environment execution, and
-post-assignment supervisor cancellation. The targeted suite passed **6/6**.
-
-**NO-GO for launching the source-pinned OpenCode 2.0.28 candidate on the
-current Windows ARM64 worker.** The candidate is Windows x64 and remains
-unqualified; these tests execute the local Node/native `cmd.exe` fixtures, not
-the candidate. In addition, several concrete supervisor boundaries below must
-be closed or explicitly supplied by a trusted outer layer before this is used
-for P0-BOOT.
-
-## Verification
-
-Command run:
-
-```text
-node --test tests/integration/windows-job.test.ts
-```
-
-Result: **6 passed, 0 skipped**. No OpenCode executable, user configuration,
-credential, shared service, or live endpoint was accessed.
-
-## Native implementation review
-
-The basic Win32 sequencing is sound for the tested path:
-
-- `CreateProcess` is called with `CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT`
-  (`windows-job.ps1:25,30-31,35`), and the child is assigned before
-  `ResumeThread` (`:35`). The forced assignment-failure case leaves the
-  fixture's parent marker absent, so the child did not run.
-- The `JOBOBJECT_EXTENDED_LIMIT_INFORMATION` layout uses pointer-sized
-  `UIntPtr` fields and 64-bit `long` fields, and its size is passed to
-  `SetInformationJobObject` (`:29,35`). The job flags and limits correspond to
-  kill-on-job-close, per-process memory, and job memory. No obvious
-  x64/ARM64 pointer-width or field-order error was found in this static review.
-- The two pipe read handles are made non-inheritable, while the child receives
-  the write handles through `STARTF_USESTDHANDLES`; output is drained on
-  separate threads and capped at 262,144 bytes per stream (`:34-35`).
-- Normal and timeout paths close the job, wait for the direct process, join
-  both drainers, and then close process/thread/pipe handles in `finally`.
-  `SafeFileHandle(..., false)` does not double-close the explicit `CloseHandle`
-  on the normal drain path.
-
-These observations support the narrow synthetic GO only; they are not an ABI
-qualification for arbitrary ARM64/x64 OpenCode binaries.
-
-## Must-fix before source-pinned P0-BOOT
-
-### 1. The supervisor does not verify the executable identity
-
-`windows-job.ps1:12-13` checks only absolute path, existence, leaf type, and
-`.exe` extension. The request has no expected SHA-256, archive-member identity,
-single-link check, or post-materialization identity binding. A request can
-therefore launch an arbitrary existing executable under the owned root or an
-explicit path outside it. The README's “explicit verified `.exe`” is a caller
-assertion, not an invariant enforced by this supervisor.
-
-For the source-pinned candidate, the trusted launch layer must either bind the
-verified extracted `package/bin/opencode.exe` identity into the request and
-revalidate it immediately before `CreateProcess`, or keep this supervisor
-behind an already-qualified launcher that makes replacement impossible. The
-request must not be able to substitute a different `.exe` while retaining a
-passing P0 result.
-
-### 2. Arbitrary inheritable handles and supervisor stdin cross the boundary
-
-`CreateProcess(..., inherit=true, ...)` at `windows-job.ps1:30-35` allows all
-inheritable handles in the supervisor to enter the child. The code only clears
-inheritance on the two pipe read ends; it does not use an explicit handle list
-or otherwise disable unrelated inherited handles. `STARTUPINFO.input` is also
-set to `GetStdHandle(-10)`, so the child's stdin can be the supervisor's
-ambient stdin. This is especially significant for OpenCode's stdio mode and
-is not covered by the “explicit environment” tests.
-
-Use an explicit inherited-handle list (or an equivalent `bInheritHandles=false`
-construction with only controlled standard handles), and deliberately provide
-EOF/closed stdin unless the selected protocol requires a private controlled
-stdio channel. Add a test proving an ambient/inheritable sentinel handle is not
-visible to the child.
-
-### 3. No active-job-count barrier exists before return
-
-After `CloseHandle(j)`, the supervisor waits only on `pi.process` for 2 seconds
-(`windows-job.ps1:35`). It never calls `QueryInformationJobObject` and never
-proves `ActiveProcesses == 0`. Closing a kill-on-close job initiates termination
-asynchronously; a direct parent wait and pipe joins do not establish that every
-descendant has exited. The integration PID checks occur after return and can
-pass by timing rather than by a supervisor-owned zero-active-count barrier.
-
-Before reporting timeout/cancellation/overflow completion, query the job until
-active count is zero under a bounded deadline, or return a fixed teardown
-failure. Keep the external PID oracle as an independent check, not as the
-supervisor's only tree proof.
-
-### 4. Supervisor-death ownership has a pre-assignment orphan window
-
-`KILL_ON_JOB_CLOSE` correctly owns processes after `AssignProcessToJobObject`,
-but the child is created before assignment. Between `CreateProcess` and
-assignment (`windows-job.ps1:35`), a supervisor crash/kill leaves a suspended
-process that is not yet in the job. The cancellation test waits for the PID
-file and normally occurs after assignment, so it does not cover this race.
-
-For a hostile or crash-prone launch boundary, use atomic job-list process
-creation where supported, or add a trusted guardian/handshake that closes the
-pre-assignment orphan window and proves cleanup. At minimum, record this as an
-explicit unavailable failure rather than claiming parent-death containment
-for the entire launch interval.
-
-### 5. Request parsing and environment/argument bounds are incomplete
-
-`Get-Content -Raw | ConvertFrom-Json` (`:10`) has no input-size limit. Argument
-count/length, environment count/name/value length, and path lengths are not
-bounded. `[string[]]$r.arguments` and `[string]$p.Value` coerce malformed JSON
-types instead of rejecting them (`:17-19`). A .NET case-sensitive dictionary
-also permits both `PATH` and `path`; Windows environment lookup is
-case-insensitive and the resulting block is ambiguous. Environment values are
-not rejected for embedded NUL, and the generated block is not checked for
-size.
-
-Add strict JSON shape/size/count/length validation, reject duplicate names
-case-insensitively and invalid/NUL values, and bound the final UTF-16
-environment block and command line before native launch. The current 256 KiB
-stdout/stderr cap and 16/4096 MiB numeric limits do not bound request parsing
-or supervisor-side memory.
-
-### 6. Ownership and fixture paths are marker-presence, not ownership proof
-
-The supervisor checks only that `.owned-p0-job` exists
-(`windows-job.ps1:7-8`); it does not validate exact marker bytes, marker
-identity/link count, directory ACL/owner, or physical no-reparse containment.
-`Assert-OwnedPath` is lexical (`:9`) and permits a junction/reparse substitution
-after validation. The integration fixture itself creates `mkdtemp` below the
-ambient `TEMP` and writes a marker (`windows-job.test.ts:15-18`), but does not
-ACL-harden or independently verify that root.
-
-This is acceptable for the narrow generated test primitive when an outer
-run-directory boundary owns the root. It is not proof that request/stdout/
-stderr/PID files are private for a real host. Before P0-BOOT, pass a
-containment-qualified root and enforce exact marker/identity checks, or make
-the outer boundary's ownership contract explicit and independently tested.
-
-## Additional cleanup and oracle findings
-
-- There is no cleanup traversal in the supervisor. The integration `finally`
-  uses exact generated paths but invokes `cmd.exe /c rmdir /s /q`; this is
-  acceptable only for that generated synthetic root, not a general ownership
-  primitive. The supervisor should not be credited with safe recursive cleanup.
-- `Drain` closes its read handle only after successful stream construction and
-  loop completion (`windows-job.ps1:34`). Exceptions from `FileStream`/file
-  creation can bypass the explicit close because `SafeFileHandle` was created
-  with `ownsHandle=false`; the thread exception is not converted to a safe
-  supervisor result. Check all native return values, close on every exception,
-  and surface a bounded `DRAIN_FAILED`/teardown failure.
-- `SetHandleInformation`, `TerminateProcess`, `CloseHandle`, and native wait
-  return values are not consistently checked. In particular a `WAIT_FAILED`
-  result is not distinguished from a non-timeout wait before the job is closed.
-  Synthetic success does not prove those failure paths.
-- The PID oracle (`windows-job.test.ts:20-26`) proves only that the recorded
-  numeric PIDs are absent from `tasklist` at one instant. It does not verify
-  image identity, creation time, job membership, all descendants, or that an
-  unknown descendant was not spawned. It is an independent smoke signal, not
-  a proof that the supervisor waited for active count zero.
-- `job-child.mjs` creates the descendant with inherited process context and
-  writes paths supplied through environment variables. This is appropriate as
-  a synthetic tree fixture, but it does not test an OpenCode binary's actual
-  handles, stdio protocol, memory behavior, or startup filesystem accesses.
-
-## Final qualification boundary
-
-The six passing cases justify a **narrow GO for trusted synthetic test
-processes**, provided an already-owned private root is supplied and the caller
-accepts the documented direct primitive scope. They do not justify launching
-the source-pinned candidate on this ARM64 worker or claiming a private real
-host sandbox. The candidate remains unqualified. P0-BOOT remains blocked on
-Windows x64 artifact identity, controlled handle inheritance/stdin, active-job
-zero teardown, strict bounded request parsing, and the separate containment
-worker's physical root/process-death qualification.

package/docs/history/12-p0-api-client.md

@@ -1,15 +0,0 @@
-# P0 API identity client
-
-This test-only helper supports the future P0-BOOT probe; it does not launch or
-discover OpenCode. It accepts only an explicit `http://127.0.0.1:<port>` origin,
-caller-owned 64-character lowercase-hex authentication, an expected version, and
-a private temporary-root expectation. `expectedPID` is optional until supervisor
-identity is available; without it the helper cannot prove process ownership.
-
-The client performs one authenticated `GET /api/info` using Node's HTTP client,
-with no redirects, proxy handling, environment discovery, or alternate hosts. It
-limits headers, body, and deadline, destroys the request on failure, and exposes
-only `version`, `pid`, `urls`, and `paths.tmp`. Advertised URLs must remain on the
-explicit loopback origin and the temporary path must be contained by the expected
-private root. Failures use fixed safe codes and never include response, password,
-or transport details.

package/docs/history/13-p0-status-review.md

@@ -1,122 +0,0 @@
-# P0 status review — fresh-eyes assessment
-
-Date: 2026-10-13
-
-## Verdict
-
-**NO-GO for P0-BOOT and MVP qualification.** The repository has useful,
-fail-closed helper tests and a source-selected Windows x64 candidate, but no
-real-host smoke harness has executed the candidate. `src/` remains placeholders
-only, and the P0 hook, abort, source, quota, and compatibility evidence gates
-remain open.
-
-The current ARM64 Windows machine cannot qualify the selected candidate. The
-candidate is the Windows x64 `@opencode/cli@2.0.28` artifact; emulation or a
-passing ARM64 helper/native feasibility test is not x64 runtime qualification.
-Qualification requires a Windows x64 worker, the exact extracted executable
-and hash, and the complete isolated launch evidence.
-
-## Evidence inspected
-
-- `docs/spec/plan.md` still marks the P0 runtime selection as source-level only
-  and leaves parser/runtime, hook, active abort, reload, permission, source
-  opening, quota, matrix, and threat-model gates unchecked.
-- `tests/smoke/runtime-candidate.json` correctly remains `unqualified` and
-  identifies only `win32/x64` as the candidate platform.
-- `tests/smoke/qualification.json` remains an intentionally empty,
-  unqualified manifest. `tests/smoke/cases.json` keeps P0-BOOT/P0-HOOKS and
-  related cases `planned`.
-- `src/README.md` confirms there is no plugin entrypoint or implementation.
-  Contract and integration suites still contain named TODOs, including R1–R8
-  and V2 lifecycle/hook behavior.
-- `docs/history/2-p0-runtime-prerequisites.md` establishes artifact/source
-  identity only; startup isolation and runtime qualification are explicitly
-  pending.
-- `docs/history/4-p0-source-opening.md` reports Windows ARM64/NTFS **partial**
-  feasibility and Linux/ext4 entirely untested. It is not a loader or platform
-  qualification.
-- `docs/history/10-p0-launch-prerequisites-review.md` resolves the password and
-  database-contract mismatch, but explicitly leaves physical containment,
-  executable launch identity, runtime isolation, and x64 host qualification
-  blocked.
-- `docs/history/11-p0-job-containment-review.md` gives the supervisor only a
-  narrow synthetic six-case GO. It lists executable identity binding, handle
-  inheritance/stdin, active-job-zero teardown, pre-assignment orphaning,
-  bounded request parsing, and physical root ownership as blockers for P0-BOOT.
-- `docs/history/12-p0-api-client.md` describes a bounded `/api/info` client,
-  not proof that the responding PID is the owned process unless `expectedPID`
-  is supplied.
-
-## Safe checks run
-
-- `npm.cmd run typecheck`: passed.
-- `npm.cmd run test:unit`: 48 passed, 0 failed, 1 skipped (non-Windows), 11
-  TODOs. These are helper/contract scaffolding results, not host or security
-  qualification.
-- `npm.cmd run test:smoke:list`: listed all cases; no runtime was qualified.
-- `git diff --check`: no whitespace errors (only line-ending warnings from
-  existing modified files).
-
-`npm run check` was not run: its configured `npm test` includes the Windows job
-integration test, and this review was explicitly prohibited from running the
-in-flux job supervisor. No OpenCode executable, shared service, user config, or
-credentials were accessed.
-
-## Exact remaining blockers
-
-### P0-BOOT
-
-1. Implement the real pinned-host harness: explicit artifact materialization,
-   hash/regular-file/non-link/single-link checks, qualified private root,
-   controlled process tree, bounded readiness, authenticated `/api/info`, PID
-   binding, and safe teardown.
-2. Resolve the job-supervisor findings in history 11 or put it behind a
-   separately qualified outer launcher. The current six synthetic cases do not
-   prove host containment.
-3. Execute startup-isolation probes with synthetic markers proving no shared
-   service, user/system/ancestor config, inherited credential, or unexpected
-   DB/cache/state/log/temp path is used.
-4. Run the complete boot evidence on Windows x64. The current ARM64 host cannot
-   qualify this candidate.
-
-### P0-HOOKS / P0-ABORT and compatibility
-
-1. Install/test the pinned V2 runtime and probe `Plugin.define`, options,
-   typed failures, four request kinds, tool outcomes, defects/interruption,
-   Code Mode/MCP/metadata, ordering, and persistence/compaction paths.
-2. Prove active native HTTP abort-before-transmission for one exact route,
-   including no raw diagnostic/fallback. Separately record unload/late-overlay
-   behavior as an expected gap; it is not a pass.
-3. Produce the compatibility matrix with `verified`, `blocked`, and
-   `uncovered` states and record the active-only envelope.
-
-### P0-C / P0-QUOTAS
-
-1. Complete a reviewed Windows loader on the intended platform and a matching
-   Linux/ext4 loader, or remove unsupported platforms from claims. The current
-   ARM64 NTFS partial and absent Linux evidence do not satisfy R8.
-2. Prove shared quota ownership across reactivation/package instances, or
-   explicitly adopt and test the supervised single-Location/no-overlap MVP
-   envelope. No implementation or proof currently exists.
-
-## Incorrect or overstated gate claims
-
-No P0 qualification status is incorrectly marked as passed: the plan's
-source-level `[x]` candidate selection is explicitly limited, the candidate
-manifest is `unqualified`, and all smoke cases are `planned`.
-
-One supporting description is too broad for the evidence: `tests/p0-host/README.md`
-describes the supervisor as closing the job on supervisor death, while history
-11 documents a pre-assignment orphan window. This must be read as
-post-assignment behavior only until a guardian/atomic launch solution proves
-the entire interval. Likewise, the synthetic integration result must not be
-reported as P0-BOOT or real-host containment qualification.
-
-## Prioritized next action
-
-**First, qualify the launch boundary on a Windows x64 worker.** Reconcile the
-job supervisor's identity, handle, teardown, parsing, and physical-root gaps;
-then run P0-BOOT against the exact `2.0.28` x64 artifact and publish private
-evidence plus a safe manifest. Only after that should P0-HOOKS/P0-ABORT and the
-native loader/quota gates be evaluated. Do not change `runtime-candidate.json`
-to `qualified` based on the current ARM64 or helper-test results.

package/docs/history/14-p0-containment-final-review.md

@@ -1,84 +0,0 @@
-# P0 containment final review
-
-Date: 2026-10-13  
-Scope: `tests/p0-host/windows-job.ps1`, `tests/integration/windows-job.test.ts`,
-`tests/fixtures/job-child.mjs`, `docs/history/7-p0-job-containment.md`,
-`docs/history/11-p0-job-containment-review.md`, and
-`docs/history/13-p0-status-review.md`. No OpenCode launch, product edit, or
-commit was performed.
-
-## Decision
-
-**NO-GO on this Windows ARM64 worker.** The candidate remains unqualified.
-The exact next action is: obtain a Windows x64 runner, rerun the targeted job
-test there, and only then assess the candidate launch boundary. ARM64 cannot
-qualify the Windows x64 candidate.
-
-## Checks run
-
-- `npm.cmd run typecheck`: passed.
-- `node --test tests/integration/windows-job.test.ts`: 1 passed, 5 failed.
-  The five failures all stop with `ATOMIC_JOB_LIST_UNSUPPORTED`; the one pass
-  is the deliberate pre-launch denial case. This is the expected ARM64
-  platform blocker, not evidence of successful containment.
-
-The test uses only the synthetic Node/native `cmd.exe` fixtures and generated
-private roots. It does not launch OpenCode or qualify a real host.
-
-## Atomic job-list review
-
-The launcher creates the job and configures limits, then constructs a
-`STARTUPINFOEX` attribute list with both:
-
-- `PROC_THREAD_ATTRIBUTE_JOB_LIST` (`0x2000D`), containing the job handle; and
-- `PROC_THREAD_ATTRIBUTE_HANDLE_LIST` (`0x20002`), containing only private
-  stdin/stdout/stderr handles.
-
-`CreateProcessW` is called suspended with the attribute list. If it returns
-Win32 error **87 (`ERROR_INVALID_PARAMETER`)**, the code throws the explicit
-`ATOMIC_JOB_LIST_UNSUPPORTED` result. This occurs before `made=true`, before a
-PID file is written, and before any child can resume. The `finally` path only
-closes the newly created job; it does not invoke a suspended-create/
-`AssignProcessToJobObject` fallback. The current ARM64 observation therefore
-proves the intended fail-closed behavior: no child creation and no fallback.
-
-The native layouts are sufficient for accepting this as a platform blocker in
-static review: `STARTUPINFOEX` embeds `STARTUPINFO` and a pointer-sized
-attribute-list pointer; attribute values and sizes use `IntPtr`/`UIntPtr`; and
-`JOBOBJECT_EXTENDED_LIMIT_INFORMATION` uses pointer-sized memory and affinity
-fields with explicit alignment padding. The accounting query also uses the
-expected pointer-independent 64-bit time and 32-bit process-count fields.
-This is not ABI qualification on ARM64 or x64; rerun on x64 is still required.
-
-One test naming limitation remains: `forceAssignmentFailure` deliberately
-throws before `CreateProcessW`, so that case proves no-resume/no-child for the
-requested denial but is not a native post-create assignment-failure test. That
-does not weaken the observed atomic attribute blocker.
-
-## Documentation overclaims
-
-`tests/p0-host/README.md` line 6 says the supervisor “closes the job on
-supervisor death.” History 11 correctly identifies the pre-assignment orphan
-window, and the current atomic path is unsupported on this ARM64 host. The
-README statement must be read narrowly as post-atomic-assignment behavior; it
-must not claim protection over the entire launch interval or ARM64
-qualification.
-
-The README's “explicit verified `.exe`” wording is also broader than the
-supervisor invariant: history 11 notes that the current request validation
-checks an absolute existing `.exe`, while identity binding is a separate
-caller/outer-layer requirement. The README should not be used to claim
-source-pinned executable identity or P0-BOOT qualification.
-
-The repository root README and `docs/spec/plan.md` remain appropriately
-bounded: they state that the product and real-host smoke harness are not
-complete, and the candidate manifest remains `unqualified`. No status change
-is justified by this ARM64 run.
-
-## Required next action
-
-Run the same targeted test on a **Windows x64 runner** supporting
-`PROC_THREAD_ATTRIBUTE_JOB_LIST`. Verify the exact atomic success path and
-then rerun the remaining P0-BOOT evidence against the pinned Windows x64
-artifact. Until that happens, ARM64 is blocked and cannot qualify the
-candidate.

package/docs/history/15-config-source-implementation.md

@@ -1,27 +0,0 @@
-# Config and source implementation (MVP pure components)
-
-This milestone implements only pure configuration validation and dotenv parsing.
-`parseOptions` accepts the explicit-session, plugin-preauthorized MVP envelope,
-the fixed GitHub repository-access operation/resource shape, and bounded source
-descriptors. It rejects unknown fields, unsafe object graphs, substitutions,
-unsupported policies, invalid paths, and raised limits with fixed diagnostics.
-
-`parseDotenv` is non-executing and does not read `process.env`: it handles
-comments, `export`, quoted values, CRLF, and quoted multiline values while
-retaining semantic and lexical representations. Duplicate keys, malformed
-assignments, and size/count violations reject the complete snapshot.
-
-The native source opener is intentionally not implemented here. No filesystem
-is opened, and no regular-file, symlink/reparse, link-count, ownership, ACL,
-ancestor-replacement, or opened-object identity guarantee is made. Those checks
-remain the deferred P0 native qualification gate described in `docs/spec/plan.md`.
-Non-dotenv source formats and vault adapters are also unsupported and rejected.
-
-Evidence: the red-first unit tests in `tests/unit/config.test.ts` and
-`tests/unit/dotenv.test.ts` initially failed because the owned modules were
-absent; after implementation, the focused suite passes. `npm run typecheck`
-passes. This is not host or filesystem qualification.
-
-Options are normalized as plain data-only records inside the fixed parse-error boundary;
-unknown fields, accessors, proxy traps, and non-positive/non-finite/unsafe limits are
-rejected as `SOURCE_INVALID`.