@zhivex-ai/harness 1.4.1 → 1.5.0

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` or `zhivex-code` with Harness 1.5.0 (Code 0.4.0), pending publication. 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

@@ -62,7 +62,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/adr/0002-isolated-mcp-stdio.md

@@ -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,8 @@
     "v1.4.0-rc.7",
     "v1.4.0-rc.8",
     "v1.4.0",
-    "v1.4.1"
+    "v1.4.1",
+    "v1.5.0"
   ],
   "expectedModels": [
     {
@@ -561,6 +562,14 @@
         "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"
+      }
     }
   ],
   "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.5.0 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.5.0
 ./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.5.0`; 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.5.0",
   "description": "Governed, provider-portable runtime for coding agents with durable approvals and isolated repository execution.",
   "type": "module",
   "license": "MIT",