opencode-secrets-obfuscation 0.1.0 → 0.1.1

package/.editorconfig

@@ -1,12 +0,0 @@
-root = true
-
-[*]
-charset = utf-8
-end_of_line = lf
-insert_final_newline = true
-indent_style = space
-indent_size = 2
-trim_trailing_whitespace = true
-
-[*.md]
-trim_trailing_whitespace = false

package/.github/workflows/ci.yml

@@ -1,75 +0,0 @@
-name: CI
-
-on:
-  push:
-    branches: [main, master]
-  pull_request:
-    branches: [main, master]
-
-permissions:
-  contents: read
-
-jobs:
-  check:
-    name: Node ${{ matrix.node }} / ${{ matrix.os }}
-    runs-on: ${{ matrix.os }}
-    strategy:
-      fail-fast: true
-      matrix:
-        os: [ubuntu-24.04]
-        node: ['24.14.1']
-
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v5
-
-      - name: Setup Node
-        uses: actions/setup-node@v5
-        with:
-          node-version: ${{ matrix.node }}
-          cache: npm
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Check
-        run: npm run check
-
-      - name: Build plugin
-        run: npm run build
-
-      - name: Verify publication package
-        run: npm run verify:package
-
-      - name: List smoke inventory
-        run: npm run test:smoke:list
-
-  real-smoke-ubuntu:
-    name: Real-host smoke / Ubuntu
-    needs: check
-    runs-on: ubuntu-24.04
-    timeout-minutes: 30
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v5
-
-      - name: Setup Node
-        uses: actions/setup-node@v5
-        with:
-          node-version: '24.14.1'
-          cache: npm
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Build plugin
-        run: npm run build
-
-      - name: Verify publication package
-        run: npm run verify:package
-
-      - name: Install verified OpenCode host
-        run: bash scripts/install-opencode-ci.sh "$RUNNER_TEMP/opencode-host"
-
-      - name: Run real-host smoke
-        run: npm run test:smoke -- --run all

package/.github/workflows/release.yml

@@ -1,50 +0,0 @@
-name: Release plugin
-
-on:
-  push:
-    tags:
-      - 'v[0-9]+.[0-9]+.[0-9]+'
-      - 'v[0-9]+.[0-9]+.[0-9]+-*'
-
-permissions:
-  contents: read
-  id-token: write
-
-jobs:
-  publish:
-    name: Verify, smoke and publish npm package
-    runs-on: ubuntu-24.04
-    timeout-minutes: 45
-    steps:
-      - name: Checkout tag
-        uses: actions/checkout@v5
-
-      - name: Setup Node
-        uses: actions/setup-node@v5
-        with:
-          node-version: '24.14.1'
-          registry-url: https://registry.npmjs.org
-          cache: npm
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Check
-        run: npm run check
-
-      - name: Build tagged package
-        env:
-          PLUGIN_VERSION: ${{ github.ref_name }}
-        run: PLUGIN_VERSION="${PLUGIN_VERSION#v}" npm run build
-
-      - name: Verify package contents
-        run: npm run verify:package
-
-      - name: Install verified OpenCode host
-        run: bash scripts/install-opencode-ci.sh "$RUNNER_TEMP/opencode-host"
-
-      - name: Run real-host smoke
-        run: npm run test:smoke -- --run all
-
-      - name: Publish with npm provenance
-        run: npm publish ./dist --provenance --access public

package/.node-version

@@ -1 +0,0 @@
-24.14.1

package/AGENTS.md

@@ -1,23 +0,0 @@
-# Engineering rules
-
-## Where things live
-- `docs/spec/`: intent, design, implementation plan and release gates.
-- `docs/history/`: historical reviews; preserve findings and original context.
-- `docs/testing.md`: test-first workflow, isolation and evidence rules.
-- `src/`: implementation modules; currently placeholders.
-- `tests/`: unit, contract, integration and real-host smoke suites; shared harness in `support/`, synthetic fixtures in `fixtures/`.
-
-## Design and production values
-- Apply SOLID: one responsibility per module; extend through small source/transport adapters; preserve contracts; prefer narrow interfaces; inject filesystem, network, clock and runtime dependencies.
-- Keep policy, secret storage, sanitization and OpenCode integration separate. Avoid speculative abstractions and unrelated refactors.
-- Fail closed within the declared boundary. Never silently downgrade protection or label an uncovered path protected.
-- Keep secrets out of public arguments, state, logs and errors. Sanitize exact sink representations, not just string leaves. Bound allocations, concurrency, execution time and cleanup.
-- Use native V2 APIs and pinned, verified dependencies. Never guess hooks or treat documentation/source inspection as runtime qualification.
-
-## Mandatory gates
-- Write a meaningful failing test before implementing behavior. Build the isolated real-host smoke harness before **claiming host qualification**, but do not block pure plugin components on deferred host infrastructure; follow the plan's profile-specific gates.
-- Run `npm run check` for every change and relevant integration/smoke tests for affected boundaries. TODOs, skips and scaffold passes are not security evidence; missing required smoke coverage blocks qualification.
-- Use synthetic credentials and isolated services only. Never read user credentials/config, attach to the shared service, or publish raw captures. Follow `docs/testing.md` for cleanup and evidence.
-- Review `git diff --check`, changed files and staged content before committing. Record tests run, failures and unverified assumptions honestly.
-- Commit along the way: small, coherent, tested milestones with descriptive messages. Stage explicit task-owned paths; never include unrelated user changes or sensitive artifacts. Do not amend/rewrite history or push without an explicit request.
-- Update specs/tests with contract changes. Do not ship a no-op plugin, invented guarantee, or passing stub as completed functionality.

package/INSTALL.md

@@ -1,104 +0,0 @@
-# Installation
-
-## Build
-
-```bash
-npm ci
-npm run check
-npm run build
-```
-
-The build produces `dist/plugin.mjs`. The current qualification target is
-OpenCode V2 (`@opencode/plugin` 2.0.28 / Effect 4.0.1).
-
-## Published distribution
-
-Release tags use the form `vMAJOR.MINOR.PATCH`. The release workflow derives the
-package version from the tag, verifies the generated package contents, runs the
-Ubuntu real-host smoke tests, and publishes only `dist/` to npm with provenance.
-
-After a release, install the exact package version with:
-
-```bash
-opencode plugin add opencode-secrets-obfuscation@1.2.3
-```
-
-The npm package contains only the bundled plugin, README, license and metadata.
-The repository root remains private and is not published. Git/local-directory
-plugin entries remain development/testing distribution methods.
-
-Before the first release, configure npm trusted publishing for this GitHub
-repository and `.github/workflows/release.yml`; no long-lived npm token belongs
-in GitHub Actions.
-
-## V2 configuration
-
-The V2 host loads a **directory** containing `index.js`. Copy the bundle into a
-private plugin directory and configure that directory with plugin options:
-
-```json
-{
-  "$schema": "https://opencode.ai/config.json",
-  "plugins": [
-    {
-      "package": "/absolute/path/to/opencode-secrets-obfuscation/plugin",
-      "options": {
-        "version": 1,
-        "sources": [
-          {
-            "id": "project",
-            "type": "file",
-            "format": "dotenv",
-            "path": ".env",
-            "required": true,
-            "keys": ["EXAMPLE_TOKEN"]
-          }
-        ],
-        "limits": {
-          "sourceBytes": 65536,
-          "totalSourceBytes": 131072,
-          "sourceCount": 2,
-          "secretCount": 50,
-          "secretBytes": 4096,
-          "indexBytes": 1048576,
-          "inputBytes": 32768,
-          "outputBytes": 65536,
-          "traversalDepth": 8,
-          "traversalNodes": 1000,
-          "activeSessions": 4,
-          "handlesPerSession": 64,
-          "activeCalls": 2,
-          "workingBytes": 1048576,
-          "callTimeoutMs": 5000,
-          "idleTimeoutMs": 1000
-        }
-      }
-    }
-  ]
-}
-```
-
-The source path is relative to the OpenCode location and must remain inside it.
-Use synthetic credentials while testing. The plugin loads the configured values
-privately, assigns opaque `secret-<uuid>` substitutions, and applies them to
-existing OpenCode session/model/http/tool surfaces. It does **not** register
-model-visible tools and does **not** make credential or other plugin-owned HTTP
-requests.
-
-## Verify
-
-Run the real-host sandbox proof instead of installing into a live user config:
-
-```bash
-npm run test:smoke -- --run P5-TRANSPARENT-ROUNDTRIP
-```
-
-The smoke case verifies that existing provider traffic contains an opaque
-replacement and never contains the raw synthetic value. A passing smoke case is
-not yet a release qualification; `tests/smoke/qualification.json` remains
-unqualified until the remaining sink, source-loader and host-boundary gates pass.
-
-## Uninstall
-
-Remove the plugin entry from the V2 config and delete the copied plugin directory.
-The plugin never changes the host's existing provider or credential endpoints.

package/docs/checkpoint.md

@@ -1,68 +0,0 @@
-# Resume checkpoint — transparent substitution E2E
-
-Updated: 2026-10-16.
-
-## Product boundary
-
-The plugin is a transparent OpenCode V2 hook layer. It loads configured dotenv
-values privately, maps each value to an opaque `secret-<uuid>` replacement, and
-sanitizes existing OpenCode session/model/http/tool/error surfaces.
-
-It does **not** register model-visible tools, perform credential or other
-plugin-owned network requests, broker GitHub/resource operations, or expose
-authorization/capability/tool-broker options. The earlier owned-tool
-implementation was removed as a product correction; its history documents
-remain historical only.
-
-## Current state
-
-- `P5-TRANSPARENT-ROUNDTRIP` passes against real opencode 2.0.28 with one CLI
-  prompt and a loopback provider.
-- Evidence: two existing provider posts, raw canary absent, opaque
-  `secret-<uuid>` replacement present, no plugin-owned request.
-- `npm run check`: green, 139 tests, 111 pass, 0 fail, 2 skipped, 26 TODO.
-- `tests/smoke/qualification.json` remains intentionally `unqualified` with
-  null pins/evidence.
-- Live config remains untouched with `"plugins": []`.
-- Correction work is currently uncommitted; run `git diff --check` and commit
-  after final verification.
-
-## Corrected configuration
-
-Options now contain only `version`, relative dotenv `sources`, and bounded
-`limits`. There is no authorization, capabilities, `credentials_read`,
-`credential_http`, owned transport or endpoint override.
-
-## E2E command
-
-```text
-npm run build
-npm run test:smoke -- --run P5-TRANSPARENT-ROUNDTRIP
-```
-
-The smoke copies the built artifact into an isolated host, creates a synthetic
-`.env`, sends a base64 representation in the prompt (the host logs argv before
-plugin hooks), and verifies provider bytes contain an opaque handle rather than
-the raw canary. The recorder is provider-only; it is not a credential verifier.
-
-## Remaining backlog
-
-1. Expand E2E sink coverage: context, compaction, title, generate, tool results,
-   errors, logs, persisted state and forced cross-part/structured serialization.
-2. Prove unsupported routes and ordinary tools are accurately scoped; do not
-   claim protection for paths the plugin cannot intercept.
-3. Qualify source opening on intended filesystems and test replacement/link/ACL
-   races before making source-integrity claims.
-4. Exercise budgets, expansion, cancellation and concurrency.
-5. Refresh release docs and compatibility manifest; populate qualification pins
-   only after the declared active-only envelope is covered.
-
-DNS pinning, proxy policy and authenticated transport qualification are not MVP
-items because the plugin does not own credential requests.
-
-## Safety invariants
-
-- Synthetic credentials only; no user config or credentials are read.
-- No raw secret in public args, provider bodies, stdout/stderr or evidence.
-- Fail closed on invalid options/source/admission/budget conditions.
-- Do not reinstall into the live host or push without explicit user request.

package/docs/history/1-spec-review.md

@@ -1,233 +0,0 @@
-# Adversarial specification review
-
-Date: 2026-10-13
-
-Reviewed: `spec/intent.md`, `spec/design.md`, `spec/plan.md`, and necessary OpenCode V2 source/documentation.
-
-Relocation note: the specifications now live under [`docs/spec/`](../spec/intent.md). Paths and line numbers below refer to the original reviewed snapshot. Subsequent specification decisions and still-pending proof gates are tracked in [the remediation table](../spec/plan.md#review-remediation-gates).
-
-**This is a specification/source review, not an executed implementation security audit.** This repository has no implementation, package manifest, lockfile, or executable qualification fixture. Counterexamples below are analytical; no plugin, provider, filesystem-race, or security integration tests were executed.
-
-## Executive verdict
-
-**Proceed with the P0 feasibility spike, but do not freeze this specification or approve a guarantee-qualified MVP release yet.** A native V2 plugin can implement the proposed private, constrained authenticated round trip. The selected plugin APIs are substantially correct. The remaining blockers are security-contract defects, not a need to revert to V1 or substitute credentials into shared tool arguments.
-
-The highest-priority issues are:
-
-1. Sanitizing individual strings does not make their later serialization/concatenation safe; the pinned host can reconstruct a credential in its generic spill writer.
-2. Leftmost-longest replacement does not meet the promised overlapping-secret suffix protection, and unrestricted short values conflict with placeholder preservation and literal-absence assertions.
-3. The generic HTTP tool has no concrete response classifier capable of enforcing its derived-credential promise.
-4. Capability preauthorization and host permission rules are separate authorities, but the required approval mode is not represented in the configuration contract.
-5. Failed reload can run the old policy in a **new** activation. Invalidating old handles does not prevent renewed authority under a revoked policy.
-6. MVP protected-route rejection relies on enforcement the plan assigns to production. A live HTTP hook is not a durable readiness gate.
-
-The narrow adapter-only MVP is feasible after these contracts are resolved. Universal model/state confidentiality is not achievable with the specified stock-plugin deployment, and the specifications correctly recognize much of that limitation. Several acceptance statements nevertheless exceed that narrower boundary.
-
-### Priority summary
-
-| ID | Severity | Release impact |
-| --- | --- | --- |
-| R1 | High | Blocks claimed structured-output and generic-spill confidentiality. |
-| R2 | High | Blocks sanitizer correctness contract and its property-test oracle. |
-| R3 | High | Blocks safe-result guarantee for a configurable generic HTTP adapter. |
-| R4 | High | Blocks deployments requiring host resource denial/approval semantics. |
-| R5 | High | Blocks lifecycle claim that revoked authority cannot return after failed replacement. |
-| R6 | High | Blocks the protected-route designation; a narrower active-plugin-only release is possible. |
-| R7 | Medium | Resource bounds are insufficiently defined for an untrusted-input service. |
-| R8 | Medium | Source-file portability/security feasibility has not been included in the initial proof gate. |
-
-“High” means a concrete disclosure/authorization failure or an unresolved condition necessary for an advertised guarantee. It does not mean an exploit was reproduced against an implementation.
-
-## Evidence and verification
-
-### Materials examined
-
-- Read the supplied global instructions and checked the project/ancestor paths for applicable `AGENTS.md`; no additional project instructions were present. Read applicable instructions in the external OpenCode checkout used for source inspection.
-- Read all three specifications and the two-line README. The specs were already untracked user work; they were not modified.
-- Checked that this report did not exist before creating it.
-- Loaded the OpenCode skill and fetched official **V2** pages: [plugin framework](https://opencode.ai/v2/docs/build/plugins), [Effect API](https://opencode.ai/v2/docs/build/plugins/effect), [plugin loading/reload](https://opencode.ai/v2/docs/plugins), [permissions](https://opencode.ai/v2/docs/permissions), and [configuration](https://opencode.ai/v2/docs/config).
-- Independently inspected the local OpenCode checkout at `C:\Users\jfomh\source\deleteme\opencode`. `git rev-parse HEAD` returned `e9def88a7790efc6abace15b67f3625ff4d66237`; its working tree was clean. This matches the research commit in the specs, **not an independently qualified published release**.
-- No changes were made to that checkout, the specifications, or other project files.
-
-### Pinned source references
-
-All source references below use commit `e9def88a7790efc6abace15b67f3625ff4d66237`:
-
-| Ref | Source and verified fact |
-| --- | --- |
-| S1 | [`packages/plugin/src/effect/tool.ts:20–59`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/plugin/src/effect/tool.ts#L20-L59): before-hook can fail with `Tool.Error`; after-hook handles completed/error outcomes and has failure type `never`. |
-| S2 | [`packages/plugin/src/effect/session.ts:14–172`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/plugin/src/effect/session.ts#L14-L172): prompt, four request kinds, HTTP and WebSocket events exist with distinct shapes. |
-| S3 | [`packages/core/src/tool.ts:103–155,225–295`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/tool.ts#L103-L155): before/after ordering, post-hook normalization, direct and nested Code Mode dispatch, and whole-tool permission filtering. |
-| S4 | [`packages/core/src/tool/runtime.ts:29–60,88–132,261–273`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/tool/runtime.ts#L29-L60): host schema processing and content normalization surround the executor; missing content can be synthesized with `JSON.stringify(output)`. |
-| S5 | [`packages/core/src/tool-output.ts:67–116`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/tool-output.ts#L67-L116): generic truncation joins text parts with a newline and writes the joined text to disk. |
-| S6 | [`packages/core/src/session/runner/step.ts:95–137`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/session/runner/step.ts#L95-L137): provider event publication precedes local execution; provider-executed tool calls skip local execution; generic truncation follows execution. |
-| S7 | [`packages/core/src/plugin.ts:47–86,125–169`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/plugin.ts#L125-L169): reload closes earlier scopes and may call `load(fallback.plugin)` after replacement failure; load errors can log their causes. |
-| S8 | [`packages/core/src/plugin/hooks.ts:69–103`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/plugin/hooks.ts#L69-L103): scope cleanup removes hook registrations; trigger uses the current callback collection and later callbacks can edit the same event. |
-| S9 | [`packages/core/src/session/model-request.ts:304–399`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/session/model-request.ts#L304-L399): HTTP guard precedes `handler(sent)` on this route; HTTP-hook presence is checked during preparation; WebSocket has a separate binding. |
-| S10 | [`packages/schema/src/tool.ts:14–20,27–30,61–101`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/schema/src/tool.ts#L14-L101) and [`packages/plugin/src/effect/permission.ts:7–24`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/plugin/src/effect/permission.ts#L7-L24): Effect tool context has no `ask` or `signal`; permission domain hooks evaluation and manages existing requests. |
-| S11 | [`packages/core/src/session/move.ts:119–157`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/session/move.ts#L119-L157) and [`packages/core/src/session/runner/llm.ts:79–111`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/core/src/session/runner/llm.ts#L79-L111): ordinary moves are admitted controls applied at runner boundaries; exceptional unavailable-source recovery can publish a move directly. |
-| S12 | [`packages/plugin/src/effect/aisdk.ts:5–22`](https://github.com/anomalyco/opencode/blob/e9def88a7790efc6abace15b67f3625ff4d66237/packages/plugin/src/effect/aisdk.ts#L5-L22): SDK/language hooks are construction hooks with model identity, not session identity. |
-
-Documentation is mutable. Source ordering above is verified at the pinned commit; compatibility with any released artifact and end-to-end failure behavior remain unverified.
-
-## Prioritized findings
-
-### R1 — Safe string leaves can become unsafe serialized output
-
-**Severity:** High. **Evidence:** source-backed counterexample; implementation behavior untested.
-
-**Spec references:** `spec/design.md:254–264`, `spec/design.md:344–346`, `spec/design.md:401–406`; `spec/plan.md:84–88`, `spec/plan.md:119`.
-
-**Failure scenario:** Register the multiline secret `alpha\nbeta` (an actual newline). A normal tool returns two text parts, the first ending in `alpha` and the second beginning with `beta`. Neither part individually contains the secret. A recursive string sanitizer can therefore approve both. The pinned generic truncator then computes `content.flatMap(...).join("\n")` (S5), recreating the exact credential. With sufficient harmless padding, that credential is written to a generic spill file. This is precisely a path the MVP says its after-hook protects, not the already-excluded shell capture path.
-
-A related omission is non-string scalar output. A registered dotenv value `123456` may return as JSON number `123456`, or a value `true` as a boolean. Filtering string values and keys does not sanitize the independently persisted structured `output`/metadata. S3–S4 also show that host normalization can generate text from structured output. Sanitizing the existing display text does not make the structured copy safe.
-
-**Consequence:** An implementation following the traversal description can pass leaf-level tests and still disclose full registered values in claimed protected artifacts.
-
-**Recommended fix:** Define safety at each concrete sink representation. For generic text results, canonicalize/join using the host's exact rules before matching, and return a safe representation that cannot reintroduce matches during subsequent normalization. Explicitly classify numeric/boolean/null values and serialized keys/punctuation; omit/block an object if preserving its required shape would disclose a value. Keep `content`, `output`, and metadata safe independently. Do not invoke arbitrary user serialization to do this.
-
-**Required gate:** In the real host, force a spill with a credential spanning text-part boundaries; inspect the actual file, structured session output, and provider payload. Add scalar echoes and normalization after an after-hook replaces content. Assert sink bytes, not only sanitizer leaf outputs.
-
-### R2 — The matching contract has incompatible requirements
-
-**Severity:** High. **Evidence:** deterministic algorithmic counterexamples.
-
-**Spec references:** `spec/design.md:119`, `spec/design.md:198`, `spec/design.md:224–227`, `spec/design.md:244–258`; `spec/plan.md:81–88`.
-
-**Failure scenario A — overlapping suffixes:** With registered values `abc` and `bcdef`, the input `abcdef` is processed by ordinary leftmost-longest matching as `[handle-for-abc]def`. The suffix `def` of the second registered credential is exposed. Longest-at-the-same-start handles prefixes, not overlapping intervals with different starts. The design explicitly says overlaps must not leak suffixes (`design.md:246`).
-
-**Failure scenario B — short values and reserved output:** A source containing `TOKEN=e` is required to be registered, but every `secret-<UUID>` contains `e`. Preserving issued placeholders leaves a registered literal in output; replacing it breaks placeholder preservation/idempotence. The reserved-value rejection clause might be intended to reject this source, but it does not define the conflict predicate and contradicts an unqualified expectation that every short value is supported. Structural fields and fixed error codes introduce similar unavoidable collisions.
-
-**Consequence:** The proposed P3 property “supported representations do not remain in safe outputs” has no unambiguous oracle. Implementers must silently choose which requirement to violate. A whole-token absence scan also misses the expressly forbidden overlapping suffix disclosure.
-
-**Recommended fix:** Specify a replacement rule covering the union of all overlapping match intervals; overlapping unions can use a redaction-only identity rather than a resolvable entry handle. Define a precise admissible-value/conflict rule covering generated placeholders, fixed protocol fields, and safe errors. Explicit safe source rejection is acceptable; silently excluding short values is not. Define whether safety means absence of secret-origin bytes or absence of coincidentally equal literals, and make claims/tests consistent with that choice. Check replacement boundaries for newly formed matches without recursively interpreting handles.
-
-**Required gate:** Include the two counterexamples, overlapping chains, input adjacent to an issued placeholder, and collisions with protocol/error text. Test union coverage and the chosen admissible-value rules, not just full-string absence.
-
-### R3 — Generic HTTP success lacks an enforceable result-classification contract
-
-**Severity:** High. **Evidence:** specification gap; response scenarios are hypothetical and service-dependent.
-
-**Spec references:** `spec/design.md:82–95`, `spec/design.md:121`, `spec/design.md:278–303`, `spec/design.md:389–393`; `spec/intent.md:68`; `spec/plan.md:96–100`.
-
-**Failure scenario:** An operator allowlists an exact HTTPS GET resource that returns an object with a download URL or a nested stored credential. The URL's signature is unrelated to the original bearer token. This can be an ordinary read endpoint rather than a token-issuing operation. The response is valid bounded JSON and contains none of the registered literals. The generic adapter returns the new capability into the transcript/model.
-
-The design requires service-specific classification and rejection of unknown semantics, but its tool/configuration describes arbitrary exact origins/paths with no classifier, response schema, or approved output projection. A MIME type and a denylist of known issuing operations cannot establish those semantics.
-
-**Consequence:** Either the implementation returns unsafe unknown data, or it correctly rejects essentially all configurable endpoints and cannot provide the promised useful generic round trip. Trusting an endpoint to receive a credential does not make every value it returns safe for the model; remote responses are explicitly untrusted (`intent.md:76`).
-
-**Recommended fix:** Make the first adapter genuinely service-specific: select a reviewed operation ID and versioned response schema, return an allowlisted projection, and reject unknown fields/types where necessary. Alternatively make the MVP status-only, with an explicitly public result such as authentication success. Add reviewed text-echo handling as a distinct fixture contract. Do not expose arbitrary text/JSON bodies until an actual classification mechanism is specified. Derived bearer values should be withheld or registered privately before any public result is built.
-
-**Required gate:** The service fixture returns a signed URL, a new token under a benign nested key, a token in an error body, and a public boolean. Only the explicitly public projection may pass. Verify the released configuration cannot select an unreviewed classifier/operation.
-
-### R4 — Required host approval is not a configuration or execution decision
-
-**Severity:** High for host-policy/approval deployments. **Evidence:** verified public API and registry behavior; missing specification branch.
-
-**Spec references:** `spec/design.md:124`, `spec/design.md:293–295`, `spec/design.md:348`; `spec/plan.md:43`, `spec/plan.md:53–54`, `spec/plan.md:99`.
-
-**Failure scenario:** A deployment sets a resource-specific host `deny`, or `ask`, for the action assigned to `credential_http`, while plugin options grant that endpoint. The pinned registry's `whollyDisabled` checks whether the last action-matching rule is `resource: "*", effect: "deny"` (S3, `tool.ts:292–295`). A resource-specific denial/ask leaves the tool visible. The custom executor has no automatic permission assertion (S10) and can execute using only its plugin grant.
-
-The specifications correctly say visibility is not approval. However, “a deployment requiring per-call host approval must block” is not implementable from the described options: there is no authorization-mode field, required-approval policy input, approved request adapter, or specified detection of incompatible effective host policy. This also affects captured tools after host policy changes; a prior visibility check is not a fresh authorization decision.
-
-**Consequence:** Users can believe their host denial/approval rules constrain the credential tool when the specified executable policy does not evaluate them. This is not a claim that explicit plugin preauthorization is inherently wrong; it is an undefined interaction between two policy systems.
-
-**Recommended fix:** Specify one explicit MVP authorization mode and its authority. If plugin grants are preauthorization, require an explicit configuration declaration and document the exact host-rule limitations; reject a requested host-approval mode until the public integration exists. If host rules must remain authoritative, prove a supported evaluation/approval path or block release for that profile. Define how agent/session restrictions are intersected at execution, not just how the tool appears in the catalog.
-
-**Required gate:** Test whole-tool deny, resource-specific deny, ask, a host policy change after tool snapshot capture, and a plugin grant without the required approval mode. Assert no network connection or credential resolution for denied/unapproved operations.
-
-### R5 — Invalidating old handles does not prevent policy rollback on failed reload
-
-**Severity:** High. **Evidence:** verified source behavior plus contradictory lifecycle acceptance scope.
-
-**Spec references:** `spec/intent.md:42`, `spec/intent.md:93–95`; `spec/design.md:125`, `spec/design.md:234–237`, `spec/design.md:363–365`, `spec/design.md:403–405`; `spec/plan.md:73`, `spec/plan.md:120`, `spec/plan.md:134–135`.
-
-**Failure scenario:** Generation A allows an endpoint. The operator changes configuration/package revision to B to remove that grant, but B fails activation. OpenCode closes A and then calls `load(fallback.plugin)` (S7). That is a **fresh activation of the old definition**, not reuse of the invalidated closure. The old definition can reload the source and issue new handles under A's permission policy.
-
-The proposed live-validity flag correctly denies captured executors from A. It does not tell the newly created fallback activation that A's policy has been revoked. No activation-local memory can independently provide that monotonic knowledge across destruction/recreation. Expected source-validation errors may be caught as unavailable, but package/setup/transform failures remain required scenarios.
-
-**Consequence:** Tests that only retry an old handle can pass while the model obtains a fresh handle and regains revoked authority. P2 defers prevention of policy rollback to the enforced profile, while P5 broadly requires no credential authority to survive invalidation. Those are different guarantees.
-
-**Recommended fix:** Separate “old references never resolve” from “superseded policy never authorizes again.” For the latter, move a required policy-generation/readiness check into a host-controlled component available in the MVP, or explicitly remove that claim from the plugin-only release. A nonsecret desired revision may be durable; that does not require persisting the secret map. Explain which component owns the authoritative revision and how it is consulted immediately before resolution.
-
-**Required gate:** After deliberately failing a revoking replacement, call `credentials_read` again and attempt the revoked operation with a **new** handle. Also exercise transform failure and reordering/replacement of preceding plugins. Inspect active versus requested revisions, not just presence of the plugin ID.
-
-### R6 — Protected-route refusal and required readiness have different milestone owners
-
-**Severity:** High for the protected-route claim. **Evidence:** verified hook removal/dispatch structure; complete runtime race behavior remains a P0 validation requirement.
-
-**Spec references:** `spec/intent.md:36–40`, `spec/intent.md:68–72`; `spec/design.md:353–357`, `spec/design.md:363–365`, `spec/design.md:381–385`; `spec/plan.md:11–12`, `spec/plan.md:41–47`, `spec/plan.md:105–106`, `spec/plan.md:134–146`.
-
-**Failure scenario:** The user switches from the qualified native HTTP route to an unqualified SDK/WebSocket route, or configuration disables/unloads the plugin while work is pending. MVP language requires unverified protected routes to be rejected before dispatch. Yet required-plugin readiness, mandatory egress ordering, and downgrade protection are assigned to P6.
-
-At the pinned source, hook cleanup removes the callback (S8). HTTP preparation determines whether to install a wrapper; the wrapper triggers the currently registered callbacks and then calls the handler (S9). There is no security-plugin liveness assertion in that code. Prepared requests and raw body overlays therefore need explicit qualification across unload/reload, not an assumption that the earlier `context` hook or `http.request` registration remains enforcing. S6 also confirms provider-executed calls do not pass through the local tool guard, despite the unqualified “every tool dispatch” language.
-
-**Consequence:** “Unsupported” is only a documentation status unless something refuses the route. The specs currently allow the same feature to be a mandatory MVP protection and a production-only host requirement. A passing HTTP happy-path test cannot resolve this.
-
-**Recommended fix:** Define an exact MVP deployment envelope: provider package/protocol/version, allowed transports/features, plugin ordering, readiness lifetime, and the owner of route rejection. Bring the smallest necessary mandatory-readiness/egress integration forward if the release is to be called protected. Otherwise limit the claim to filtering while a particular activation is active and to the owned executor's outputs; do not label unmediated routes as blocked. Exclude provider-executed tools and opaque checkpoints/uploads unless independently qualified.
-
-**Required gate:** Pause immediately before transmission, unload/replace the plugin, and resume; repeat with a late body overlay containing a synthetic credential. Attempt an unqualified route, HTTP fallback, provider-executed tool, and sessionless generation. Observe the network and diagnostics. P0 must prove safe abort behavior or record a blocking host dependency. Source inspection proves the normal hook position, not absence of every retry/fallback leak.
-
-### R7 — Per-input limits do not bound aggregate or post-redaction memory
-
-**Severity:** Medium. **Evidence:** missing resource contract and straightforward expansion scenario.
-
-**Spec references:** `spec/design.md:97–103`, `spec/design.md:198–200`, `spec/design.md:249–262`; `spec/plan.md:70`, `spec/plan.md:86–89`, `spec/plan.md:100`.
-
-**Failure scenario:** Register the valid short value `!`. A permitted 1 MiB text response consisting of that byte expands to approximately 43 MiB when each match becomes `secret-<UUIDv4>`. Concurrent calls multiply that allocation before generic truncation. Likewise, many sessions/Locations can create maps and concurrent response buffers; the configuration contains no explicit aggregate source/index/session/concurrency limits or behavior at those limits.
-
-**Consequence:** An endpoint can exhaust the shared service without exceeding `resultBytes`. An implementation can be locally bounded yet unbounded at service scale. Resource exhaustion then exercises the very defect/cleanup paths on which confidentiality depends.
-
-**Recommended fix:** Define pre- and post-transformation byte budgets, aggregate index/source budgets, bounded traversal depth/node count, active-call and session-handle quotas, and allocation/queue behavior. Enforce expansion bounds while constructing output rather than after allocating it. Define safe denial/eviction semantics and which quotas are Location-local versus service-wide. Count decompressed bytes for any supported compression.
-
-**Required gate:** Maximum-expansion responses, deeply nested JSON, many concurrent sessions/calls, slow bodies, and cancellation while at the quota. Measure peak allocation and verify safe denial without partial publication.
-
-### R8 — Cross-platform opened-file security needs an early feasibility proof
-
-**Severity:** Medium. **Evidence:** specification implementation gap; no OS bypass was executed.
-
-**Spec references:** `spec/design.md:122`, `spec/design.md:190–201`; `spec/plan.md:36–47`, `spec/plan.md:65–66`, `spec/plan.md:121`, `spec/plan.md:219`.
-
-**Failure scenario:** A loader checks a path/ACL, then opens it after a directory junction or file replacement. A path-only preflight is not the opened-object identity/ACL guarantee the design requires. Windows inherited ACLs, owner identity, ancestor traversal/replacement rights, reparse points, and hard-link aliases require explicit semantics. The plan promises Linux and Windows qualification but does not choose the necessary runtime/OS facilities before package implementation begins.
-
-This is not an objection that same-user ACLs should sandbox generated code: the specs correctly defer that to isolation. It is a separate question of whether the loader actually validates the object it consumes under the stated source trust policy.
-
-**Consequence:** The project can build most of P1–P4 before discovering that its chosen filesystem API/dependency cannot enforce P2 on a supported OS. Accepting an approximation would silently weaken the source guarantee.
-
-**Recommended fix:** Add a small source-opening feasibility fixture to P0. Choose the supported OS/filesystem matrix and a concrete opened-handle validation strategy; decide whether a narrowly scoped native helper is needed. Specify acceptable ACL principals and ancestor permissions, handling of hard links, and whether unsupported filesystems are safely rejected. Keep this independent from the later generated-code sandbox.
-
-**Required gate:** An opened-handle test on Windows and Linux covering file/directory swaps, inherited broad grants, ACL changes, reparse/symlink traversal, and aliases. Verify with synthetic files and safe diagnostics; do not infer Windows ACL protection from POSIX mode bits.
-
-## Additional unresolved questions and validation requirements
-
-These are explicit design decisions or source/runtime investigations still needed, not established vulnerabilities:
-
-1. **Exact artifacts:** P0 must identify an actually published V2 release, its source commit, host Effect version, and compatible plugin package. The pinned checkout alone does not establish distribution compatibility. Current documentation examples must not substitute for testing the packed package.
-2. **Who receives a session grant?** `design.md:225–230,272–274` describes session-specific handles and an “authorized” catalog, but the policy has no enrollment rule. Does every session in a Location receive every configured capability by calling `credentials_read`? If yes, say that precisely: cross-session handle rejection prevents replay, not independent reacquisition. Define parent/child/fork/import and agent-change behavior. If no, specify the trusted granting event and state owner.
-3. **Move semantics:** Verify actual placement through the public session API, including its response envelope. Normal movement is a step-boundary control (S11), so do not assume every move is a mid-executor race. Test A→B→A, delayed/lost cleanup-event observation, unavailable-source recovery, and queued work. Current Location equality alone cannot prove that a grant was never revoked during an intervening move. Specify the authoritative move epoch or synchronization used for that promise.
-4. **Source rotation and old redaction state:** `design.md:201,234–237` retains old matching state only until old calls drain. What protects a queued prompt, later synthetic notification, imported result, or request already assembled with the previous value? Either retain bounded redaction generations with explicit ownership or reject affected work. This is already a production concern; state exactly which queued/resumed flows the MVP excludes.
-5. **HTTP mechanics:** Select the real HTTP client and prove DNS validation applies to the address actually connected to, including multiple DNS answers, IPv4-mapped IPv6, TLS hostname verification, connection reuse, proxy environment, and redirects. Define URL normalization and response decompression/content-type handling. “Constrain DNS” is a requirement, not yet an algorithm. Also define which status/header fields may be public.
-6. **Runnable test services:** The planned synthetic service and recording provider need a concrete transport fixture. A default localhost HTTP server conflicts with the owned tool's HTTPS/public-address-only policy. Use a test-only connector/controlled HTTPS setup that keeps authorization and production defaults intact, plus a real network test of the address policy. Do not solve the fixture by shipping a permissive production exception.
-7. **Defects, schemas, and cancellation:** S4 shows host input validation, output encoding, and normalization outside the executor's catch block; input validation errors can quote the entire input. Verify sanitizer failure, output-schema mismatch, raw public-argument rejection, cancellation, and captured executors after hook removal separately. Ensure scoped finalizer order invalidates authority before resources/guards disappear and retains matchers until raw buffers are discarded. No secure-zeroization claim should be added.
-8. **Evidence quality:** P5 should require a per-case table linking each claimed guarantee to actual provider bytes, event/DB/log/spill captures, and authorization/network assertions. Mark known-gap tests as expected gaps, never as successful protection cases. Include independent oracles for overlap coverage, source isolation, policy revocation, and destination binding. Canary scans alone cannot prove those properties. Restrict failing captures; use synthetic credentials only.
-
-## Sound choices to preserve
-
-- Private resolution inside a plugin-owned executor, with immutable public arguments, is the right boundary. Unrestricted string substitution would undermine the entire design.
-- Activation-local secret ownership, no durable map/indexes, CSPRNG handles, and separate redaction-only versus capability handles correctly avoid accidental persistence and permission union for duplicate values.
-- Native Effect registration, typed before-hook denial, four distinct request hooks, and separation of HTTP/WebSocket/SDK surfaces align with the inspected V2 APIs. No nonexistent `context.ask`, V1 result envelope, or identity-free shell injection is required.
-- The specifications correctly distinguish normal after-hook/generic spill protection from shell captures, earlier progress, provider output publication, imports, and independent generation. Filesystem/process isolation is rightly required for stronger claims.
-- Immutable generations, old-executor rechecks, bounded owned-tool buffering, safe replacement errors, exact HTTP audiences, and refusal of redirects are strong foundations. Keep them while fixing the gaps above.
-
-## Recommended remediation order
-
-1. **Make the release contract executable.** Decide authorization mode, session enrollment, active-only versus mandatory protection, and behavior on failed replacement. Resolve R4–R6 before claiming a protected MVP.
-2. **Run P0 against exact artifacts.** Include safe HTTP abortion, unload/fallback behavior, captured execution, and the Windows/Linux source-opening feasibility fixture. Record unresolved host integrations as blocking dependencies.
-3. **Replace the sanitizer oracle with sink-level rules.** Resolve R1–R2 and specify scalar handling, overlapping intervals, reserved-output conflicts, and final serialization. Add aggregate/expansion bounds from R7 before choosing the indexing implementation.
-4. **Reduce the authenticated MVP to one reviewed operation.** Add a concrete response projection/classifier, pinned transport behavior, and runnable fixtures. Close R3 rather than implementing an apparently generic safe HTTP client.
-5. **Implement and qualify the packaged plugin.** Exercise the exact negative cases above alongside successful authentication; include fresh-handle acquisition after failed revocation, cross-part spill reconstruction, and unsupported-route attempts.
-6. **Keep production enforcement separately gated.** Broker ownership, isolation, inbound streaming, complete publication mediation, historical rotation coverage, and every enabled transport still require P6–P9. Passing the smaller release must not automatically satisfy those gates.
-
-## Review outcome
-
-The V2 integration approach is credible, and the specification has already avoided several serious architectural mistakes. It is not yet precise enough to make its strongest MVP assertions testable or true. Resolve the six high-priority findings or explicitly narrow the affected release claims, prove the listed P0 dependencies, and then proceed with implementation.