@zhivex-ai/harness 1.4.1 → 1.6.2

package/docs/AUTO_APPROVE.md

@@ -0,0 +1,51 @@
+# Opt-in auto-approve
+
+Manual is the default. Nothing is applied until a person decides.
+
+| Mode | What can proceed without a prompt |
+| --- | --- |
+| `manual` | Nothing. This is today's review. |
+| `auto-edits` | File edits whose paths stay inside the workspace root. |
+| `auto-limits` | Those edits, plus commands whose executable is on the allowlist. |
+
+## Always ask
+
+These wait for a person in every mode, including when the command is allowlisted:
+
+- Network or egress, including `curl`, `wget`, `ssh`, and any command that carries an `http` or `https` URL.
+- Deletes outside the workspace.
+- Writes outside the workspace root.
+- Secret or credential files (`.env`, `credentials`, `.npmrc`, `.pypirc`, `.netrc`, `id_rsa`, `id_ed25519`, `*.pem`, `*.key`, and a `secrets` or `credentials` directory).
+- `git push`.
+- Package publish (`npm`, `pnpm`, `yarn`, `bun`, `cargo`).
+- Any operation once a spend or token limit is already reached.
+
+There is no flag that skips this list. A batch that mixes a safe edit with one of these stays on the review screen. `--approval-mode auto` and `--yes` are the older approve-all switch used by non-interactive runs. They are not this feature. Tool policy and explicit host review still apply.
+
+## Where it is set
+
+The workspace file is `.zhivex-harness/approval.json`. That directory is already protected from workspace tools.
+
+```json
+{
+  "mode": "auto-limits",
+  "commandAllowlist": ["bun", "git"]
+}
+```
+
+Allowlist entries are exact executable names. Wildcards and paths are rejected. `git` on the list still does not allow `git push`.
+
+The CLI flag and a session command override the file for this process:
+
+```sh
+zhivex-code --auto-approve auto-edits
+zhivex-code --auto-approve auto-limits --auto-approve-allow bun --auto-approve-allow git
+```
+
+In the terminal, `/auto-approve` shows the mode, `/auto-approve manual` changes this session, and `/auto-approve workspace manual` writes the file. `m` during a review, or `/manual`, returns to Manual without rewriting the file. The status line names the mode.
+
+In the web workspace the header chip shows the same mode. The dialog can save it for this session or this workspace. `m`, while you are not typing, returns to Manual for the session.
+
+## Audit and undo
+
+Each auto-approved operation is appended to `.zhivex-harness/auto-approvals.jsonl` with the mode, the reason, and a bounded snapshot of the previous file text (256 KiB of UTF-8). `/undo` restores the latest snapshot when every file still matches the approved text. The web Approvals dialog does the same per change. A later edit, a binary file, or a snapshot that was too large is not reverted.

package/docs/AZURE_OPENAI.md

@@ -4,14 +4,14 @@ Azure OpenAI is a separate provider (`azure-openai`). It does not reuse
 `OPENAI_API_KEY` or `OPENAI_BASE_URL`. No live Harness certification has been
 run for this route. Prices are not copied from the public OpenAI catalog.
 
-Published `@zhivex-ai/azure-openai@0.7.8` is the adapter pinned by this tree.
-It requires Core `^1.34.0`, and this checkout pins `@zhivex-ai/core@1.34.0`.
+Published `@zhivex-ai/azure-openai@0.8.0` is the adapter pinned by this tree.
+It requires Core `^1.36.0`, and this checkout pins `@zhivex-ai/core@1.36.0`.
 Language models report Tier A. Hosted tool gates such as tool search follow
 the model id (`gpt-5.4` and `gpt-6-astra` in this adapter). An opaque
 deployment name does not receive those gates unless a deployment map names
 the base model.
 
-Published 0.7.8 accepts a deployments map and a token provider for Microsoft
+Published 0.8.0 accepts a deployments map and a token provider for Microsoft
 Entra ID. This route still authenticates with an API key and does not pass a
 token provider.
 
@@ -30,7 +30,7 @@ deployment name is not also sent as `model`. When it is omitted, requests use
 `AZURE_OPENAI_DEPLOYMENTS` is optional JSON, at most 8192 characters and 32
 entries. Each entry is `"name": "gpt-5.4"` or `"name": { "model": "gpt-5.4" }`.
 Deployment names and model ids are restricted to simple identifier characters.
-Harness passes the map to the adapter. Published 0.7.8 uses the base model for
+Harness passes the map to the adapter. Published 0.8.0 uses the base model for
 capabilities and request shape while the request still uses the deployment
 name. Harness also overlays those capability flags.
 

package/docs/BEDROCK.md

@@ -4,8 +4,8 @@ Bedrock is a separate provider (`bedrock`). It is not enabled by the Anthropic
 direct API route. No live Harness certification has been run for this route.
 Pricing and context limits are not inferred.
 
-Published `@zhivex-ai/bedrock@2.0.7` is the adapter pinned by this tree. It
-requires Core `^1.34.0`, and this checkout pins `@zhivex-ai/core@1.34.0`.
+Published `@zhivex-ai/bedrock@2.1.0` is the adapter pinned by this tree. It
+requires Core `^1.36.0`, and this checkout pins `@zhivex-ai/core@1.36.0`.
 This integration reports the installed adapter's labels and does not relabel
 them.
 
@@ -14,7 +14,7 @@ them.
 `BEDROCK_RUNTIME` is optional. An empty value or `converse` selects the Converse
 API. `openai` selects the OpenAI-compatible runtime. Any other value is rejected.
 
-Converse reports Tier B on the published 2.0.7 adapter: reasoning is supported
+Converse reports Tier B on the published 2.1.0 adapter: reasoning is supported
 and `toolChoiceNone` is true. Approval requests stay false on that runtime.
 Harness reports that installed label.
 
@@ -28,7 +28,7 @@ not read `OPENAI_API_KEY` or `OPENAI_BASE_URL` for this route.
 Converse uses the AWS SDK default credential chain: instance roles, SSO,
 shared config, and environment credentials. Set `AWS_REGION` or
 `AWS_DEFAULT_REGION` to a region such as `us-east-1`. `AWS_PROFILE` is part of
-the transport fingerprint. Published 2.0.7 accepts a profile and static
+the transport fingerprint. Published 2.1.0 accepts a profile and static
 credentials on the adapter. This route does not pass `AWS_PROFILE`. When
 `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are both set, and no bearer
 token is set, Converse uses that static pair and an optional

package/docs/CLI.md

@@ -549,6 +549,19 @@ model with a small billable request. See [credentials](CREDENTIALS.md).
 `/approvals` opens the mode picker; `/approvals ask`, `/approvals auto`, and
 `/approvals restricted` switch directly. The composer and `/status` show the active
 mode. Auto approves gated actions within existing workspace and execution policies.
+
+Opt-in auto-approve is separate from `--yes`. `--auto-approve manual` is the default.
+`--auto-approve auto-edits` applies file edits inside the workspace root.
+`--auto-approve auto-limits` also runs commands whose executable is passed with
+repeatable `--auto-approve-allow`. The same choice can live in
+`.zhivex-harness/approval.json`, which tools cannot rewrite. A session choice from
+`/auto-approve` or the `m` key wins until the process exits and does not rewrite the
+file. Network or egress, deletes outside the workspace, writes outside the root,
+secret or credential files, `git push`, package publish, and any operation already
+over a spend or token limit always wait for a person. Allowlisting `git` or `npm`
+does not bypass those. Every auto-approved edit is appended to
+`.zhivex-harness/auto-approvals.jsonl`. `/undo` restores that edit when the file
+still matches the approved text. See [auto-approve](AUTO_APPROVE.md).
 Bounded dependency inspection runs without a separate approval in every mode.
 Restricted denies gated actions. Mode changes apply only to this CLI process and are blocked
 while work is active or awaiting approval; use `/pending`, `/approve`, or `/deny`

package/docs/CODE_RELEASE.md

@@ -1,5 +1,24 @@
 # Code release procedure
 
+## Harness 1.6.2 does not release Code
+
+Harness source is `1.6.2`, pending publication to `latest`. Installed
+acceptance requires the Code source pin to equal that candidate, so
+`@zhivex-ai/code` stays version `0.4.0` and pins `@zhivex-ai/harness` to
+`1.6.2`. Published npm Code `0.4.0` remains pinned to Harness `1.5.0`. Do not
+republish `0.4.0` and do not create a `code-v*` tag for this engine bump.
+
+## Pending patch: 2026-10-16
+
+The source version is `1.5.0`, pending publication to `latest`. This checkout
+prepares Harness `1.5.0` and Code `0.4.0` for npm `latest`, with Code pinned
+exactly to the engine and private Desktop bound to the same Harness version.
+Published `latest` is Harness `1.4.1` and Code `0.3.2`. It adds the `v1.5.0`
+representative mapping with the same Meta, Qwen and OpenAI models as `v1.4.1`
+and does not change provider/API tiers. Annotated `v1.5.0` then `code-v0.4.0`
+on the same reviewed main SHA, `channel=latest`, run through the unchanged
+protected workflows and their environment approvals.
+
 ## Pending patch: 2026-10-14
 
 This checkout prepares Code `0.3.1`, pinned exactly to Harness `1.4.1`, for npm
@@ -278,9 +297,17 @@ support remain unchanged; estimated budgets are not guaranteed financial caps.
    verification as ordered in [the Harness release procedure](https://github.com/Zhivex/zhivex-harness/blob/main/docs/RELEASE.md).
    From a clean checkout of that main commit, create an annotated
    `code-v0.2.0` tag and push it. Never move or overwrite release tags.
-4. Dispatch `release-code.yml` **at that tag**, with input `tag` matching it and
-   `channel=latest`, `mode=oidc`, and `confirm_publication=true`. Dispatching
-   main while supplying a different tag is rejected.
+4. Dispatch `release-code.yml` **from that exact tag ref**, with input `tag`
+   matching it and `channel=latest`, `mode=oidc`, and `confirm_publication=true`.
+   A no-permission job is defense in depth, not the trust boundary, because
+   GitHub loads it from the dispatched ref. When it still runs, it requires
+   `GITHUB_REF` to be exactly `refs/tags/code-v0.2.0`, resolves that annotated
+   tag to the workflow commit, and requires the commit to be reachable from
+   `main` before provenance OIDC, provider-free validation, or npm publication
+   starts. Dispatch from `main` or any other ref is rejected, including when
+   the commit matches the tag. Publication still depends on the `npm`
+   environment allowing only selected `v*` and `code-v*` tags, and on the tag
+   ruleset in [Public repository security](PUBLIC_SECURITY.md).
 
 ```sh
 gh workflow run release-code.yml --ref code-v0.2.0 \
@@ -350,10 +377,13 @@ In npm package settings, configure GitHub Actions with organization `Zhivex`,
 repository `zhivex-harness`, workflow filename `release-code.yml`, and environment
 `npm`. Enable the allowed action `npm publish`; the OIDC job uses direct
 publishing after GitHub approval, not `npm stage publish`. Preserve the GitHub
-environment's required human approval. Then prepare a
+environment's required human approval and the selected-tag deployment rule in
+[Public repository security](PUBLIC_SECURITY.md). That environment rule, with
+the maintainer-only tag ruleset, is the trust boundary. The in-repo resolver is
+defense in depth, not the trust boundary. Then prepare a
 new Code stable or RC version and annotated tag through the same PR and main CI process.
-Dispatch its tag with the matching channel, `mode=oidc` and
-`confirm_publication=true`. Stable versions require `latest` and a stable exact
+Dispatch the workflow from that exact tag ref, with the matching channel, `mode=oidc` and
+`confirm_publication=true`. A dispatch from `main` is rejected. Stable versions require `latest` and a stable exact
 Harness dependency; canonical RC versions require `next`. Version/channel drift
 fails before engine downloads. An RC may pin a stable engine. Stable publication
 does not upgrade beta/experimental APIs, provisional providers or Desktop alpha.

package/docs/CODE_WEB_TASKS.md

@@ -11,7 +11,7 @@ action on a fresh review ticket; model prose and a completed run are not accepta
 
 ## Operator flow
 
-1. Open `zhivex-code web`, select an allowed workspace and create an empty session.
+1. Open `zhivex-code web`, open Sessions, choose an allowed project and create an empty session.
    Choose **Define task**. Enter the goal, exact existing editable files, package
    checks and explicit input/output/total token limits for the entire task.
 2. Review each proposed edit or check through the existing exact approval controls.

package/docs/CREDENTIALS.md

@@ -86,7 +86,7 @@ Set an https `AZURE_OPENAI_ENDPOINT` before saving a key. Optional
 `AZURE_OPENAI_API_VERSION` and `AZURE_OPENAI_DEPLOYMENTS` stay in the
 environment and are not written to the keychain. A managed
 `AZURE_OPENAI_API_KEY` is allowed together with that endpoint. Published
-`@zhivex-ai/azure-openai@0.7.8` accepts a token provider, and this route still
+`@zhivex-ai/azure-openai@0.8.0` accepts a token provider, and this route still
 stores and sends the API key. See [Azure OpenAI](AZURE_OPENAI.md).
 
 ## Qwen interactive setup

package/docs/DURABLE_OPERATIONS.md

@@ -70,7 +70,7 @@ Loading a run reconstructs its complete state for compatibility with approvals,
 
 Logical backups contain hydrated history rather than database references, so restoration does not require the original artifact tables. Exports up to 64 MiB retain the legacy JSON format; larger exports use the versioned `ZHIVEX-STATE-SEGMENTS-1` transport with bounded frames, including split strings. RC13 reads both formats and verifies the same logical checksum before import. Older versions cannot read segmented exports. File I/O and checksum serialization are incremental; the public backup/import APIs still hydrate the complete logical bundle in memory. Segmented files have no aggregate 64 MiB ceiling. A state-limit failure records a bounded terminal diagnostic on the last durable checkpoint; the unsaved payload is not claimed as preserved. Use `/status` to inspect the failed run before `/continue`. Recovery retains tool journal receipts and never re-executes an operation itself.
 
-The current source pins Core 1.34.0 and Agents 1.11.0. New stores require no
+The current source pins Core 1.36.0 and Agents 1.12.0. New stores require no
 conversion. Before upgrading an existing shared SDK store, stop its workers and
 upgrade them together with a complete backup. Verified legacy runs retain their
 physical keys and remain readable; new runs use canonical keys that distinguish

package/docs/ENGINE_API.md

@@ -1,7 +1,7 @@
 # Engine API and Code integration
 
 The terminal-independent package entrypoints shipped in Harness 1.3.0 and remain
-in published Harness 1.4.0 (npm `latest`). This checkout is Harness 1.4.1, pending publication. They are not present in Harness 1.2.0.
+in published Harness 1.4.0 (npm `latest`). This checkout is Harness 1.6.2, pending publication. They are not present in Harness 1.2.0.
 The protected workflow validated the exact stable tarball, live gates and
 registry integrity/provenance; local candidate smoke remains contributor evidence. Do not install registry 1.2.0 and
 expect the new entrypoints to exist.

package/docs/EXTENSIBILITY.md

@@ -8,7 +8,7 @@ Built-in registrations are Meta, Qwen, OpenAI, Gemini, Anthropic, Vertex, Amazon
 
 Library callers can use `DEFAULT_PROVIDER_REGISTRY`, `BUILTIN_PROVIDER_REGISTRATIONS`, `createProviderRegistry`, or `DEFAULT_PROVIDER_REGISTRY.extend(...)`, then pass the registry to `resolveHarnessConfig`, `createProviderModel`, provider diagnostics, or `createHarness({ providerRegistry })`. Registration IDs, environment-variable names, defaults, diagnostics, and factories are validated before they become selectable.
 
-The coordinated stable SDK batch pins `@zhivex-ai/agents@1.11.0`, `@zhivex-ai/core@1.34.0`, `@zhivex-ai/meta@0.2.9`, `@zhivex-ai/qwen@0.16.4`, `@zhivex-ai/openai@0.16.0`, `@zhivex-ai/gemini@0.13.0`, `@zhivex-ai/anthropic@0.14.0`, `@zhivex-ai/vertex@1.2.7`, `@zhivex-ai/bedrock@2.0.7`, and `@zhivex-ai/azure-openai@0.7.8`. Qwen 0.16.2 types malformed Responses tool arguments and malformed SSE events; Core 1.34.0 satisfies Agents, OpenAI and Vertex `^1.31.0`, Anthropic `^1.30.0`, Qwen `^1.29.0`, and the provisional Bedrock and Azure OpenAI `^1.34.0` ranges. These exact versions are pinned in the lockfile. Stable SDK publication does not replace Harness release-bound certification. Qwen `0.11.x` normalizes missing, placeholder, and continuation tool-call identifiers inside the adapter; Harness retains its deterministic provider-boundary normalizer as defense in depth until the exact candidate passes the complete release-bound representative matrix. A Core override keeps one runtime contract identity across every adapter, while Core `1.13.0` corrects compaction usage accounting and interaction-group retention. OpenAI `0.11.2` preserves synthetic assistant history in Responses, so the harness no longer requires its compaction transport or accounting workarounds.
+The coordinated stable SDK batch pins `@zhivex-ai/agents@1.12.0`, `@zhivex-ai/core@1.36.0`, `@zhivex-ai/meta@0.3.0`, `@zhivex-ai/qwen@0.18.0`, `@zhivex-ai/openai@0.17.0`, `@zhivex-ai/gemini@0.14.0`, `@zhivex-ai/anthropic@0.15.0`, `@zhivex-ai/vertex@1.3.0`, `@zhivex-ai/bedrock@2.1.0`, and `@zhivex-ai/azure-openai@0.8.0`. Qwen 0.16.2 types malformed Responses tool arguments and malformed SSE events; Core 1.36.0 satisfies Agents `^1.34.0` and the provider adapters' `^1.36.0` floors. Vertex 1.3.0 requires OpenAI `^0.17.0`, Anthropic `^0.15.0`, and Gemini `^0.14.0`. These exact versions are pinned in the lockfile. Stable SDK publication does not replace Harness release-bound certification. Qwen `0.11.x` normalizes missing, placeholder, and continuation tool-call identifiers inside the adapter; Harness retains its deterministic provider-boundary normalizer as defense in depth until the exact candidate passes the complete release-bound representative matrix. A Core override keeps one runtime contract identity across every adapter, while Core `1.13.0` corrects compaction usage accounting and interaction-group retention. OpenAI `0.11.2` preserves synthetic assistant history in Responses, so the harness no longer requires its compaction transport or accounting workarounds.
 
 OpenAI is based on the GPT-5.6 family: `gpt-5.6-luna` is the default, with `gpt-5.6-terra` and `gpt-5.6-sol` available through `--model`. Availability remains organization-dependent while the upstream family is in limited preview, and the adapter uses the Responses API by default.
 
@@ -81,14 +81,18 @@ Library callers can inject a custom `McpClient`. Trusted read-only annotations a
 
 ## MCP result boundary
 
-MCP descriptions and results are untrusted. The harness:
+MCP descriptions and results are untrusted data, including text that looks like an identifier, digest, or configuration value. The harness:
 
 - bounds discovery pages, discovered tools, time, and response bytes;
 - validates declared input and structured-output schemas through the SDK MCP registry;
 - propagates abort signals, timeout intent, and idempotency keys;
 - rejects common prompt-injection directives before they enter model context;
 - records server permissions and risk in tool metadata;
-- promotes network, write, or external-side-effect calls to durable interrupt approval.
+- promotes network, write, or external-side-effect calls to durable interrupt approval;
+- removes exact secret values before a result is published;
+- when a server was admitted with secret references, flags known encodings of those secrets and other high-entropy encoded tokens in tool results.
+
+That flagging is optional and incomplete. Split, encrypted, or low-entropy encodings can still appear. Discovery schemas are rejected rather than rewritten when they contain an exact secret. Treat every MCP result as data, not as instructions and not as proof that a credential is absent.
 
 The injection filter is deliberately conservative and may reject legitimate security documentation containing imperative attack text. Use a separate trusted preprocessing boundary if that content must be analyzed; do not disable the harness boundary for an untrusted server.
 

package/docs/FIRST_USE.md

@@ -1,13 +1,13 @@
 # First use
 
-This guide targets stable `1.4.1`, pending publication to npm `latest`. The versioned install commands below become available only after protected publication. npm `latest` remains stable 1.3.0 until that publication.
+This guide targets stable `1.6.2`, pending publication to npm `latest`. The versioned install commands below become available only after protected publication. npm `latest` remains stable 1.5.0 until that publication.
 
 ## Install and start
 
 Install Node.js 22.13.0 or newer and Git. Then:
 
 ```sh
-npm install -g @zhivex-ai/harness@1.4.1
+npm install -g @zhivex-ai/harness@1.6.2
 cd /path/to/your/project
 zhx
 ```
@@ -82,16 +82,16 @@ For command execution, configure [OCI isolation](EXECUTION_ENVIRONMENTS.md).
 With Bun 1.4.0 or newer and a supported Node runtime:
 
 ```sh
-bun add --global @zhivex-ai/harness@1.4.1
+bun add --global @zhivex-ai/harness@1.6.2
 zhx
 ```
 
 For a disposable version/help/environment check without a global installation:
 
 ```sh
-bunx @zhivex-ai/harness@1.4.1 --version
-bunx @zhivex-ai/harness@1.4.1 --help
-bunx @zhivex-ai/harness@1.4.1 doctor
+bunx @zhivex-ai/harness@1.6.2 --version
+bunx @zhivex-ai/harness@1.6.2 --help
+bunx @zhivex-ai/harness@1.6.2 doctor
 ```
 
 For source development, use the [contributor guide](https://github.com/Zhivex/zhivex-harness/blob/main/CONTRIBUTING.md).

package/docs/MINIMUM_TASK_AUTHORITY.md

@@ -52,11 +52,11 @@ dispatch/cap behavior, not provider billing guarantees or model quality.
 
 | Route | Direct guided task | Verified wire cap and dispatch boundary |
 | --- | --- | --- |
-| Built-in OpenAI (`@zhivex-ai/openai` 0.16.0) | Supported | Responses `max_output_tokens`; Chat `max_tokens` without reasoning or `max_completion_tokens` with reasoning; `maxRetries=0`, `maxProviderRequests=1` |
-| Built-in Anthropic API key (`@zhivex-ai/anthropic` 0.14.0) | Supported | Messages `max_tokens`; non-refreshable built-in credentials; `maxRetries=0` |
-| Built-in Gemini (`@zhivex-ai/gemini` 0.13.0) | Supported | `generationConfig.maxOutputTokens`; `maxRetries=0` |
-| Built-in Vertex (`@zhivex-ai/vertex` 1.2.7) | Supported | `generationConfig.maxOutputTokens`; real ADC callback, synthetic credential source in tests; `maxRetries=0` |
-| Qwen (`@zhivex-ai/qwen` 0.16.4) | Blocked as Code primary | Explicit Chat-mode middleware tested with capped `max_tokens`; Code has no explicit mode selector and Responses rejects `maxTokens` |
+| Built-in OpenAI (`@zhivex-ai/openai` 0.17.0) | Supported | Responses `max_output_tokens`; Chat `max_tokens` without reasoning or `max_completion_tokens` with reasoning; `maxRetries=0`, `maxProviderRequests=1` |
+| Built-in Anthropic API key (`@zhivex-ai/anthropic` 0.15.0) | Supported | Messages `max_tokens`; non-refreshable built-in credentials; `maxRetries=0` |
+| Built-in Gemini (`@zhivex-ai/gemini` 0.14.0) | Supported | `generationConfig.maxOutputTokens`; `maxRetries=0` |
+| Built-in Vertex (`@zhivex-ai/vertex` 1.3.0) | Supported | `generationConfig.maxOutputTokens`; real ADC callback, synthetic credential source in tests; `maxRetries=0` |
+| Qwen (`@zhivex-ai/qwen` 0.18.0) | Blocked as Code primary | Explicit Chat-mode middleware tested with capped `max_tokens`; Code has no explicit mode selector and Responses rejects `maxTokens` |
 | Meta | Blocked | Harness continuation fetch can replay a 400 response outside SDK retry admission |
 | Injected/custom adapters, refreshable Anthropic OAuth | Blocked | No vetted transport provenance; OAuth transport can replay a 401 after refresh outside ordinary retry admission |
 | Mock | Offline tests only | Synthetic usage is never billing evidence |

package/docs/PROJECT_MEMORY.md

@@ -7,7 +7,7 @@ generated automatically; hosts may submit a suggestion for operator review.
 
 ## CLI
 
-Use `zhx` or `zhivex-code` with Harness 1.4.1 (Code 0.3.1), pending publication. Commands
+Use `zhx` with Harness 1.6.2, pending publication. `zhivex-code` stays on Code 0.4.0. Its source pin is Harness 1.6.2; published Code 0.4.0 remains pinned to Harness 1.5.0. Commands
 print bounded JSON, including the selected workspace/scope hashes. Quote content
 as one argument. Memory commands do not start a model or read credentials.
 

package/docs/PUBLIC_SECURITY.md

@@ -13,7 +13,9 @@ The repository is public. GitHub documents the following controls as available w
 - CodeQL code scanning on standard GitHub-hosted runners; and
 - standard GitHub-hosted Actions runners.
 
-The repository additionally uses a `main` ruleset with pull-request review, review-thread resolution, linear history, and required CI checks. Repository Actions default to read-only permissions; individual jobs must request any narrower write capability explicitly. The npm publication job is the only workflow path that requests `id-token: write`, and it uses the protected `npm` environment.
+The repository additionally uses a `main` ruleset with pull-request review, review-thread resolution, linear history, and required CI checks. Repository Actions default to read-only permissions; individual jobs must request any narrower write capability explicitly. CI lints `.github/workflows` with actionlint 1.7.12 and shellcheck. The checksum and the shellcheck exceptions for quoted node/bun programs are pinned in `.github/workflows/ci.yml`.
+
+Harness release, Code release, and live certification each call `.github/workflows/resolve-protected-release-ref.yml` from a job with empty permissions and no secrets. The call uses a relative `./` path, so GitHub loads that file from the same commit as the dispatched workflow. An off-main tag or branch can rewrite the resolver or omit the call. The resolver is defense in depth, not the trust boundary. The boundary is external: the `npm` and `live-certification` environments accept deployments only from the selected tag patterns below, and a tag ruleset lets only maintainers create matching tags and blocks updates and deletions. When the dispatched workflow still contains the resolver, it requires `GITHUB_REF` to be exactly `refs/tags/<tag>` for both Harness and Code. It then accepts only an annotated `vX.Y.Z`, `vX.Y.Z-rc.N`, `code-vX.Y.Z`, or `code-vX.Y.Z-rc.N` tag, peels it to a full commit SHA, and continues only when that commit is the workflow commit and an ancestor of `main`. Later jobs check out that SHA. `id-token: write` is requested only on those later jobs: Harness and Code publication on the `npm` environment, Code provenance generation, and Vertex workload identity on the `live-certification` environment. The environment still withholds that token unless the workflow ref is an allowed deployment tag. npm provenance, the Rekor HTTP 409 reuse for an identical DSSE entry, and the registry verification step are unchanged. Pinning `uses:` to a commit SHA in this repository or in another repository does not replace the environment rules or the tag ruleset: the workflow file selected by the dispatched ref still chooses the `uses:` value and can delete the call.
 
 References:
 
@@ -37,3 +39,14 @@ If the repository becomes private or internal, treat every security feature and
 The `live-certification` GitHub environment is the only workflow scope authorized to hold provider credentials. Whether credentials are currently configured is mutable repository state and is intentionally not asserted by this document; maintainers must verify it at dispatch time. Adding or rotating credentials transfers sensitive provider keys into GitHub and requires an explicit maintainer decision.
 
 The release workflow fails closed when those credentials are absent: npm publication depends on the base, orchestration, routing, and model-directed OCI live gates running against the exact annotated release tag and source commit. When credentials are configured, they are exposed only to the final provider-call step; checkout, runtime setup, dependency installation, tag verification, and deterministic OCI validation do not receive them. Local credentials are never copied to GitHub automatically.
+
+## Environment protection to confirm manually
+
+The workflow file cannot create GitHub environment rules or rulesets. Before the next npm publication or live certification, set these repository settings. They are the trust boundary.
+
+- `npm`: required reviewers. Deployment branches and tags must be **Selected tags** with patterns `v*` and `code-v*` only. Do not include `main`, all branches, or any other pattern. This environment remains the Trusted Publishing environment for `release.yml` and `release-code.yml`.
+- `live-certification`: required reviewers. Deployment branches and tags must be **Selected tags** with pattern `v*` only. Do not include `main`, any branch, or `code-v*`. Provider secrets and Vertex variables stay in this environment.
+- Tag ruleset for patterns `v*` and `code-v*`: enable **Restrict creations**, **Restrict updates**, and **Restrict deletions**. Put only the Maintain role on the bypass list, so only maintainers can create matching tags and nobody can update or delete them. Repository admins can still bypass a ruleset unless the organization disables bypass; do not add a broader bypass list.
+- Dispatch Harness release, Code release, and live certification from the exact tag ref (`refs/tags/vX.Y.Z`, `refs/tags/vX.Y.Z-rc.N`, `refs/tags/code-vX.Y.Z`, or `refs/tags/code-vX.Y.Z-rc.N`). A dispatch from `main` or any other ref is not a deployment tag, so these environments do not grant secrets or `id-token: write`. The resolver rejects that ref as well when the dispatched workflow still contains the check, including when the branch commit equals the tag.
+- Approve a deployment only after the resolve job log shows `resolved <tag> to <sha>` and that SHA equals the workflow commit (`github.sha`).
+- Environment patterns are coarse `fnmatch` globs. The resolver's regular expression is stricter, but it runs only when the workflow file on the dispatched ref still calls it. A ref the ruleset and the environment exclude never receives secrets or `id-token: write`, even if its workflow omits the resolver.

package/docs/REPOSITORY_EDITING.md

@@ -72,7 +72,7 @@ The terminal prints the complete `apply_patch` approval arguments rather than tr
 
 `quarantine_file` requires the current digest and moves the file into harness-owned state. The result includes a `quarantineId` used for recovery. The model has no permanent-delete tool.
 
-`restore_file` accepts a quarantine identifier and an optional workspace destination. Restore is conflict-safe: it never overwrites an existing destination, and an optional expected digest can bind the operation to the quarantined bytes the operator reviewed. A successful restore is recorded independently from the quarantine operation.
+`restore_file` requires a quarantine identifier, the destination path, and the expected digest of the quarantined bytes. It does not fall back to the original path or restore bytes the operator did not pin. Restore is conflict-safe: it never overwrites an existing destination. The approval preview shows that destination and the quarantined text for the pinned digest. A successful restore is recorded independently from the quarantine operation.
 
 Quarantine is a recovery boundary, not a backup system. Retention and permanent cleanup remain operator responsibilities. Do not manually edit quarantine manifests or payloads while a run is active.
 

package/docs/TOOL_POLICY.md

@@ -32,6 +32,9 @@ The strongest matching decision wins: deny, then ask_user, then allow. Allow
 does not grant filesystem permissions or remove an existing approval. ask_user
 uses the current approval mechanism, including its configured automatic mode;
 it does not independently require a human. Human-only review is separate work.
+Opt-in auto-approve (`manual`, `auto-edits`, `auto-limits`) never bypasses a deny,
+an explicit host review, or the always-ask list (network, secrets, git push,
+package publish, paths outside the workspace, and an already reached spend or token limit).
 
 Built-in file resolvers cover read_file, read_files, propose_edits, apply_patch,
 apply_reviewed_edits, apply_reviewed_replacement, move_file and quarantine_file.
@@ -62,7 +65,10 @@ channels without compatible review evidence receive EXPLICIT_REVIEW_REQUIRED and
 leave the operation pending. The local CLI in ask mode displays a complete bounded
 payload and issues host evidence after explicit confirmation, without cached session
 grants. With this policy, `resume --approve` also requires interactive review;
-noninteractive invocation remains pending. Desktop accepts the operator-owned
+noninteractive invocation remains pending. `zhivex-code web --tool-policy` applies that file only when a single
+`--workspace` is set. More than one workspace with a shared policy is a usage
+error, so projects cannot inherit each other's approvals. `zhivex-code project add
+--tool-policy <path>` records a policy for that folder alone. Desktop accepts the operator-owned
 policy through its `--tool-policy` startup argument. Its main process consumes a
 bounded, expiring review ticket and sends the exact decision to the runtime through
 their private process channel. The renderer cannot issue review evidence, and the

package/docs/VERTEX.md

@@ -44,7 +44,7 @@ Errors expose bounded categories for authentication, permission, unavailable
 model/route, rate limit and server failures. Raw Google payloads, token values,
 credential paths and service-account identities are not retained in errors.
 
-The integration pins `@zhivex-ai/vertex@1.2.7` with Core 1.34.0 and
-`google-auth-library@11.1.0`. Deterministic tests exercise the installed SDK's
+The integration pins `@zhivex-ai/vertex@1.3.0` with Core 1.36.0 and
+`google-auth-library@11.3.1`. Deterministic tests exercise the installed SDK's
 transport, streaming, signed continuation, approval/reopen and route mismatch.
 They are not evidence of a live project, renewable ADC or IAM authorization.

package/docs/WEB_LIMITS.md

@@ -3,8 +3,8 @@
 New interactive Web/terminal tasks have no accumulated spend, token, step,
 tool-call or duration cap unless configured. This change uses the published SDK contract from
 Zhivex/zhivex-ai-sdk PR 142 (Core/SDK 1.31.0, Agents 1.11.0). Direct Harness, Code
-and the root Core override now pin Core 1.34.0; Agents stays 1.11.0.
-Provider package pins are Anthropic 0.14.0, OpenAI 0.16.0 and Vertex 1.2.7.
+and the root Core override now pin Core 1.36.0; Agents is 1.12.0.
+Provider package pins are Anthropic 0.15.0, OpenAI 0.17.0 and Vertex 1.3.0.
 Headless policies and release gates remain unchanged.
 
 The Web header opens the approved gradual configuration modal. Next task settings

package/docs/adr/0002-isolated-mcp-stdio.md

@@ -20,7 +20,7 @@ activate stdio, change configuration schema 1, or claim isolated execution passe
   options with abort, timeout/idempotency key, and an HTTP transport; no executable
   stdio factory was found in that dependency. The control-plane transport enum is
   not an executor.
-- The current pin is `@zhivex-ai/core` 1.34.0, which includes an experimental
+- The current pin is `@zhivex-ai/core` 1.36.0, which includes an experimental
   stdio client. Harness still does not treat that factory as the OCI boundary.
 
 MCP stdio uses UTF-8 newline-delimited JSON-RPC on stdin/stdout; stderr is a
@@ -120,7 +120,7 @@ host spawn from `createHarnessMcpTools` or by buffering a never-ending `run`.
 | --- | --- |
 | Client commands run during session creation | Reject before admission; zero host/container processes and zero discovery calls. |
 | TOCTOU, swapped image/argv or replayed admission | Digest/identity recheck at launch; receipt scope/expiry/single-use tests. |
-| Secret/environment exfiltration | Empty inherited environment, restricted references, network denial, redacted audit; canary checks inside/outside boundary. |
+| Secret/environment exfiltration | Empty inherited environment, restricted references, network denial, redacted audit, and optional flagging of high-entropy or encoded strings from credential-bearing servers. Output stays untrusted data. Canary checks inside and outside the boundary. |
 | Filesystem escape and host mutation | No bind mounts, no-follow snapshot/import rules, resource limits and reviewed publication; symlink/traversal fixtures. |
 | Tool metadata or prompt injection escalates authority | Independent host policy and per-call approvals; untrusted descriptions/results remain data. |
 | Hung/forking/noisy process | Absolute deadlines, frame/queue/stderr/resource bounds and whole-boundary cleanup. |

package/evaluations/representative-assembly-matrix.json

@@ -63,7 +63,11 @@
     "v1.4.0-rc.7",
     "v1.4.0-rc.8",
     "v1.4.0",
-    "v1.4.1"
+    "v1.4.1",
+    "v1.5.0",
+    "v1.6.0",
+    "v1.6.1",
+    "v1.6.2"
   ],
   "expectedModels": [
     {
@@ -561,6 +565,38 @@
         "qwen": "qwen3.8-flash",
         "openai": "gpt-6-luna"
       }
+    },
+    {
+      "releaseTag": "v1.5.0",
+      "models": {
+        "meta": "muse-spark-1.3-contributor",
+        "qwen": "qwen3.8-flash",
+        "openai": "gpt-6-luna"
+      }
+    },
+    {
+      "releaseTag": "v1.6.0",
+      "models": {
+        "meta": "muse-spark-1.3-contributor",
+        "qwen": "qwen3.8-flash",
+        "openai": "gpt-6-luna"
+      }
+    },
+    {
+      "releaseTag": "v1.6.1",
+      "models": {
+        "meta": "muse-spark-1.3-contributor",
+        "qwen": "qwen3.8-flash",
+        "openai": "gpt-6-luna"
+      }
+    },
+    {
+      "releaseTag": "v1.6.2",
+      "models": {
+        "meta": "muse-spark-1.3-contributor",
+        "qwen": "qwen3.8-flash",
+        "openai": "gpt-6-luna"
+      }
     }
   ],
   "expectedCases": [

package/examples/README.md

@@ -2,19 +2,19 @@
 
 ## Isolated Bun installation
 
-Requirements: Bun 1.4.0+, Node.js 22.13.0+, and Git on macOS or Linux. After protected stable publication, this installs the 1.4.1 artifact in a temporary consumer, without building the source checkout or changing global tools:
+Requirements: Bun 1.4.0+, Node.js 22.13.0+, and Git on macOS or Linux. After protected stable publication, this installs the 1.6.2 artifact in a temporary consumer, without building the source checkout or changing global tools:
 
 ```bash
 harness_demo_dir=$(mktemp -d)
 cd "$harness_demo_dir"
 printf '{"name":"harness-first-run","private":true}\n' > package.json
-bun add --exact --ignore-scripts @zhivex-ai/harness@1.4.1
+bun add --exact --ignore-scripts @zhivex-ai/harness@1.6.2
 ./node_modules/.bin/zhx --version
 ./node_modules/.bin/zhx --help
 ./node_modules/.bin/zhx doctor --provider openai --json
 ```
 
-Version must print `1.4.1`; help lists commands. Doctor does not contact a provider. Without `OPENAI_API_KEY`, it reports the missing credential and exits with code `3`; inspect the JSON checks before proceeding. A directory without Git initialization can also produce a diagnostic warning. No paid model call is required for these checks. Both `zhx` and `zhivex-harness` are installed aliases; Bun manages installation, and their shebang runs Node.
+Version must print `1.6.2`; help lists commands. Doctor does not contact a provider. Without `OPENAI_API_KEY`, it reports the missing credential and exits with code `3`; inspect the JSON checks before proceeding. A directory without Git initialization can also produce a diagnostic warning. No paid model call is required for these checks. Both `zhx` and `zhivex-harness` are installed aliases; Bun manages installation, and their shebang runs Node.
 
 To continue in your actual project, use the [global installation and credential setup](../README.md#quick-start), then `zhx init --profile daily --provider openai` and `zhx doctor --profile daily`. Real tasks require the selected provider credential in the process environment. Profiles store provider/model choices, never credentials. See [CLI](../docs/CLI.md) and [support](../SUPPORT.md).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zhivex-ai/harness",
-  "version": "1.4.1",
+  "version": "1.6.2",
   "description": "Governed, provider-portable runtime for coding agents with durable approvals and isolated repository execution.",
   "type": "module",
   "license": "MIT",
@@ -100,6 +100,7 @@
     "LICENSE",
     "docs/CHANGE_ENVELOPES.md",
     "docs/CLI.md",
+    "docs/AUTO_APPROVE.md",
     "docs/WEB_LIMITS.md",
     "docs/CODE_RELEASE.md",
     "docs/CODE_WEB_TASKS.md",
@@ -216,26 +217,26 @@
     "smoke:mcp:installed": "bun run build && bun scripts/mcp-installed-smoke.ts"
   },
   "dependencies": {
-    "@zhivex-ai/agents": "1.11.0",
-    "@zhivex-ai/anthropic": "0.14.0",
-    "@zhivex-ai/azure-openai": "0.7.8",
-    "@zhivex-ai/bedrock": "2.0.7",
-    "@zhivex-ai/core": "1.34.0",
-    "@zhivex-ai/gemini": "0.13.0",
-    "@zhivex-ai/meta": "0.2.9",
-    "@zhivex-ai/openai": "0.16.0",
-    "@zhivex-ai/qwen": "0.16.4",
-    "@zhivex-ai/vertex": "1.2.7",
-    "google-auth-library": "11.1.0",
-    "zod": "4.6.5"
+    "@zhivex-ai/agents": "1.12.0",
+    "@zhivex-ai/anthropic": "0.15.0",
+    "@zhivex-ai/azure-openai": "0.8.0",
+    "@zhivex-ai/bedrock": "2.1.0",
+    "@zhivex-ai/core": "1.36.0",
+    "@zhivex-ai/gemini": "0.14.0",
+    "@zhivex-ai/meta": "0.3.0",
+    "@zhivex-ai/openai": "0.17.0",
+    "@zhivex-ai/qwen": "0.18.0",
+    "@zhivex-ai/vertex": "1.3.0",
+    "google-auth-library": "11.3.1",
+    "zod": "4.6.7"
   },
   "overrides": {
-    "@zhivex-ai/core": "1.34.0"
+    "@zhivex-ai/core": "1.36.0"
   },
   "devDependencies": {
     "@agentclientprotocol/sdk": "1.8.0",
     "@modelcontextprotocol/server": "2.3.1",
-    "@types/bun": "1.4.2",
+    "@types/bun": "1.4.3",
     "@types/node": "^26.6.5",
     "typescript": "7.0.2",
     "typescript-compiler-api": "npm:typescript@6.0.3"