@zhivex-ai/harness 1.3.0 → 1.4.0-rc.1

package/dist/zhx.js

@@ -2,7 +2,7 @@
 import {
   HARNESS_VERSION,
   shortCliHelp
-} from "./cli-entry-bx3vjw7h.js";
+} from "./cli-entry-645q3vwx.js";
 import {
   __require
 } from "./cli-entry-1bx83sw4.js";
@@ -16,6 +16,6 @@ if (argv.length === 1 && ["--version", "-v", "version"].includes(argv[0])) {
   process.stdout.write(`${shortCliHelp(HARNESS_VERSION)}
 `);
 } else {
-  const { runCli } = await import("./cli-etsmtst3.js");
+  const { runCli } = await import("./cli-mejgq79m.js");
   await runCli(argv);
 }

package/docs/CLI.md

@@ -795,3 +795,7 @@ An envelope link matches the recorded patch identifier; envelope integrity and
 expiry are checked separately. Patch bytes and producer authenticity remain
 unverified. No envelope v1 fields are added. Concurrent source changes and hard
 capacity limits reject export; bounded tree/history truncation is reported.
+
+## Experimental project memory (unreleased)
+
+`zhx memory` supports `remember`, `list`, `read`, `update`, `forget`, `suggest`, `accept`, `context`, `clear`, `enable` and `disable`. Content is one quoted argument. Updates, acceptance and forgetting require the current revision. `--source` supplies a provenance label; `--no-memory` disables curated retrieval and SDK memory loading/capture for a local run/chat/resume invocation. Existing workspace/tenant/user/namespace flags select scope. See [Project memory](PROJECT_MEMORY.md) for bounds, review, deletion semantics and next-release pairing.

package/docs/CODE_RELEASE.md

@@ -1,47 +1,87 @@
 # Code release procedure
 
-Code is released independently of Harness. The prepared stable release is
+## Current RC preparation: 2026-10-04
+
+This checkout prepares Harness `1.4.0-rc.1` and Code `0.3.0-rc.1`, both on
+`next`, with Code pinned exactly to the Harness candidate. npm currently reports
+Harness `1.3.0` and Code `0.2.0` on `latest`; those stable tags must not move.
+The candidates are not published. Review and integrate the preparation PR, then
+require the latest successful `ci.yml`, `codeql.yml`, `code-journey.yml` and
+`web.yml` main-push runs for the exact release SHA, including the separate CodeQL
+security result. Run Harness's existing preparation and protected release workflow
+for annotated `v1.4.0-rc.1` with `channel=next`. Its exact-artifact, OCI, live and
+representative gates remain mandatory. Paid certification requires separate
+campaign approval. After Harness registry integrity and provenance verification,
+run Code's protected OIDC workflow at annotated `code-v0.3.0-rc.1` on the same SHA,
+with `channel=next`, `mode=oidc` and publication confirmation. Code must resolve
+the real published engine without overrides and pass retained-artifact terminal
+and web acceptance, four-manager checks and provenance verification. Keep stable
+`latest` unchanged. The older publication records below are historical.
+
+
+Code is released independently of Harness. The verified stable release is
 `@zhivex-ai/code@0.1.0`, with the sole binary `zhivex-code`, npm tag `latest`,
-and the exact dependency `@zhivex-ai/harness@1.3.0`. Harness must first be
-published and verified through its protected release workflow. Code RC2 is
-already published on `next` and RC1 is still on `latest`; trusted
-publishing succeeded in [run 36902929707](https://github.com/Zhivex/zhivex-harness/actions/runs/36902929707).
-The stable release uses that existing OIDC path; no new credentials or publisher
-configuration are part of preparation. This document records preparation, not
-successful stable publication.
+and the exact dependency `@zhivex-ai/harness@1.3.0`. Harness was published and
+verified first in [run 37031040747](https://github.com/Zhivex/zhivex-harness/actions/runs/37031040747). Code passed real registry
+resolution, four-manager installed acceptance and source-bound provenance in
+[run 37036369187](https://github.com/Zhivex/zhivex-harness/actions/runs/37036369187) at `aa86de8d700f893253559b00c1f7191e7dab48b9`.
+Attempt 1 accepted publication but failed while registry metadata still reported
+the version absent. Attempt 2 recovered only the failed publish job using the
+retained artifact; identical bytes skipped npm publication and verification passed.
+Code RC2 remains on `next`; RC1 is historical. The existing OIDC publisher and
+protected environment were preserved. See [publication evidence](https://github.com/Zhivex/zhivex-harness/blob/main/docs/reports/evidence/stable-publication-2026-10-02.json).
+
+## Code 0.2.0 candidate
+
+This checkout prepares `@zhivex-ai/code@0.2.0` with the same exact published
+Harness `1.3.0` dependency. Code `0.1.0` remains the verified npm `latest` release
+until a separately approved publication succeeds. The candidate adds guided
+approval diffs, reviewed checkpoints, per-run estimated budgets and the offline
+first-use tutorial. See the [candidate changelog](https://github.com/Zhivex/zhivex-harness/blob/main/packages/code/CHANGELOG.md)
+and [release readiness](https://github.com/Zhivex/zhivex-harness/blob/main/docs/reports/CODE_0_2_0_READINESS_2026-10-03.md).
+
+This is a Code-only release: no Harness version change or new paid six-provider
+certification campaign is required. Engine API tiers and provisional provider
+support remain unchanged; estimated budgets are not guaranteed financial caps.
 
 ## Release preparation
 
 1. Merge the Code release PR after required review and successful checks.
-2. Wait for the latest `ci.yml` and `codeql.yml` **push runs on main** to succeed
+2. Wait for the latest `ci.yml`, `codeql.yml` and `code-journey.yml` **push runs on main** to succeed
    for the exact commit. Keep the Code manifest, version and engine pin unchanged
    after selecting that commit.
 3. Wait for Harness `1.3.0` publication and successful registry/provenance
    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.1.0` tag and push it. Never move or overwrite release tags.
+   `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.
 
 ```sh
-gh workflow run release-code.yml --ref code-v0.1.0 \
-  -f tag=code-v0.1.0 -f channel=latest -f mode=oidc -f confirm_publication=true
+gh workflow run release-code.yml --ref code-v0.2.0 \
+  -f tag=code-v0.2.0 -f channel=latest -f mode=oidc -f confirm_publication=true
 ```
 
-The workflow validates tag identity, main ancestry, exact CI/CodeQL, Code source
+The workflow validates tag identity, main ancestry, exact CI/CodeQL/installed journeys, Code source
 and package boundaries. It downloads the pinned Harness version from npm and
 verifies its integrity and SLSA artifact/workflow/tag/source binding; missing
 publication or provenance stops the release.
-It builds Code once, inspects package contents, installs it against the actual
+It builds Code once, admits only metadata, flat built JavaScript and the two
+named tutorial modules, and installs it against the actual
 registry dependency without overrides, and tests the retained Code and Harness
 artifacts with npm, pnpm, Yarn and Bun. The paired matrix uses explicit engine
 artifact overrides; the separate standalone installation proves npm resolution.
-This does not claim every future engine version or installation order is certified.
+The retained Code tarball also passes offline installed PTY journeys without
+repacking. The separate `code-journey.yml` workflow runs on every PR and main
+push on Linux/macOS with Node 22.13.0/24, retaining the tested tarball, digest,
+report and transcript. Removing path filters ensures each selected main SHA can
+produce its own journey evidence. This does not claim every future engine
+version or installation order is certified.
 
 The workflow generates genuine npm/Sigstore provenance using pinned npm 11.6.1
 inside the GitHub-hosted build job. It retains `code.tgz`, `code.sigstore.json`,
-`SHA512SUMS`, and installed acceptance in `code-release-<full-source-sha>`.
+`SHA512SUMS`, installed acceptance, and the offline PTY report/transcript in `code-release-<full-source-sha>`.
 Bootstrap mode **does not publish**. No npm token is copied into GitHub.
 
 ## Historical first publication / future package bootstrap
@@ -64,7 +104,7 @@ commit SHA. Install npm 11.6.1 into an isolated tools directory and set
 ```sh
 (cd release-code-artifacts && shasum -a 512 -c SHA512SUMS)
 bun run scripts/code-release.ts inspect release-code-artifacts/code.tgz
-CODE_EXPECTED_SHA="$(git rev-list -n 1 code-v0.1.0)" \
+CODE_EXPECTED_SHA="$(git rev-list -n 1 code-v0.2.0)" \
   node scripts/code-bootstrap-provenance.cjs verify \
   release-code-artifacts/code.tgz release-code-artifacts/code.sigstore.json
 node "$CODE_PROVENANCE_NPM_ROOT/bin/npm-cli.js" publish \

package/docs/CONTEXT_ENGINEERING.md

@@ -426,3 +426,5 @@ that `endLine` is an absolute line number, not a count. The runtime does not
 execute, rename or silently repair malformed calls. Durable error receipts stay
 unchanged; the model must issue a corrected request, and edits still require
 current read evidence and approval.
+
+Project memory is a separate kind of explicit operator context in the existing durable memory table. It is projected per request as untrusted data, with revision-based review and hard byte/entry budgets. It does not become project instructions or skills. See [Project memory](PROJECT_MEMORY.md).

package/docs/DURABLE_OPERATIONS.md

@@ -218,3 +218,5 @@ To disable cumulative token ceilings explicitly, use `--no-token-budget` (librar
 through resume. Token accounting and compaction continue; cost, time, steps, tools,
 approvals, and provider per-request limits remain enforced. Stored numeric token
 ceilings are inactive until `unlimitedTokens` is set back to `false`.
+
+Next-version [project memory](PROJECT_MEMORY.md) reuses the existing SDK memory table and state export records. Historical state is not harvested into curated memory. Forget/clear remove current memory content, while backups, run histories and SQLite WAL retention remain separate. Older importers reject the new reserved memory key safely.

package/docs/ENGINE_API.md

@@ -1,9 +1,9 @@
 # Engine API and Code integration
 
 This checkout adds terminal-independent package entrypoints for
-Harness 1.3.0 (prepared for `latest`). They are not present in the previously published Harness 1.2.0.
-Stable publication is pending the protected workflow; use the documented
-local candidate smoke to validate these bytes. Do not install registry 1.2.0 and
+Harness 1.3.0 (published and verified on `latest`). They are not present in the previously published 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.
 
 ## Entry points
@@ -68,9 +68,9 @@ switching presentation does not migrate state or authorize new effects.
 ## Terminal product
 
 `packages/code` is the independently built terminal product. Its current version
-is `0.1.0`, prepared for independent publication to `latest` with the exact
-engine dependency `@zhivex-ai/harness@1.3.0`. Publication remains gated by
-reviewed main, CI and registry evidence in the [Code release procedure](CODE_RELEASE.md).
+is `0.1.0`, independently published and verified on `latest` with the exact
+engine dependency `@zhivex-ai/harness@1.3.0`. Reviewed main, CI and registry
+evidence are recorded in the [Code release procedure](CODE_RELEASE.md).
 Code imports declared package APIs, never Harness source paths. Its build leaves
 Harness external.
 
@@ -115,7 +115,7 @@ The new subpaths were introduced after RC3 and are published in RC7. Stable
 1.3.0 retains their declared tiers.
 Desktop migration and packaged acceptance are documented in
 the repository-only report `docs/reports/HAR_HU_39_2026-09-29.md`. Its dependency is pinned to the
-exact prepared engine version and checked for required contracts/artifact identity; this does
+exact engine version and checked for required contracts/artifact identity; this does
 not claim compatibility with the earlier published RC3 bytes or a broader range.
 
 ```sh
@@ -318,3 +318,7 @@ input/output/cache tokens and terminal completion for the current invocation.
 It retains at most 128 requests plus an omitted count and contains no prompt or
 result text. Missing usage is null, including an interrupted paid request; these
 measurements do not claim invoice accuracy or provider tokenizer equivalence.
+
+## Experimental project memory
+
+The `/engine` surface exports `openHarnessProjectMemory`, `executeHarnessMemoryCommand`, `HARNESS_MEMORY_COMMANDS`, `HARNESS_PROJECT_MEMORY_SCHEMA_VERSION`, `HARNESS_PROJECT_MEMORY_LIMITS` and their memory types. `createHarness` accepts the experimental `projectMemory: true` host opt-in option. These additions use existing local persistence; no client protocol change is required. See [Project memory](PROJECT_MEMORY.md) for contracts and release implications.

package/docs/FIRST_USE.md

@@ -1,13 +1,13 @@
 # First use
 
-This guide targets the prepared stable `1.3.0` release. These exact-version commands become available after protected publication to npm `latest`; currently latest resolves to 1.2.0.
+This guide targets candidate `1.4.0-rc.1`, pending publication to npm `next`. The versioned install commands below become available only after protected publication. npm `latest` remains stable 1.3.0.
 
 ## Install and start
 
 Install Node.js 22.13.0 or newer and Git. Then:
 
 ```sh
-npm install -g @zhivex-ai/harness@1.3.0
+npm install -g @zhivex-ai/harness@1.4.0-rc.1
 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.3.0
+bun add --global @zhivex-ai/harness@1.4.0-rc.1
 zhx
 ```
 
 For a disposable version/help/environment check without a global installation:
 
 ```sh
-bunx @zhivex-ai/harness@1.3.0 --version
-bunx @zhivex-ai/harness@1.3.0 --help
-bunx @zhivex-ai/harness@1.3.0 doctor
+bunx @zhivex-ai/harness@1.4.0-rc.1 --version
+bunx @zhivex-ai/harness@1.4.0-rc.1 --help
+bunx @zhivex-ai/harness@1.4.0-rc.1 doctor
 ```
 
 For source development, use the [contributor guide](https://github.com/Zhivex/zhivex-harness/blob/main/CONTRIBUTING.md).

package/docs/PROJECT_MEMORY.md

@@ -0,0 +1,157 @@
+# Project memory (experimental, RC candidate)
+
+Project memory keeps explicit operator notes across separate sessions. It is
+local, inspectable and correctable. No provider calls, external database,
+credentials or integrations are needed to manage it. Suggestions are never
+generated automatically; hosts may submit a suggestion for operator review.
+
+## CLI
+
+Use `zhx` or `zhivex-code` with Harness 1.4.0-rc.1 (Code 0.3.0-rc.1), 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.
+
+```sh
+zhx memory remember "Database migrations use SQLite" --source "Operator decision"
+zhx memory list
+zhx memory read <id>
+zhx memory update <id> <revision> "Database migrations need explicit review"
+zhx memory forget <id> <revision>
+zhx memory suggest "Candidate database convention" --source "Model suggestion, reviewed separately"
+zhx memory read <suggestion-id>
+zhx memory accept <suggestion-id> <reviewed-revision>
+zhx memory context "database migrations"
+zhx memory disable
+zhx memory enable
+zhx memory clear
+zhx run --no-memory "Inspect database migrations"
+```
+
+`remember` and `update` are explicit operator writes. `suggest` creates a pending
+record; editing it leaves it pending. `accept` requires the exact revision that
+the operator reviewed. No model tool can remember, update, accept or forget a
+record. Host applications must keep these write operations behind their own
+operator interface; an API call is not proof of human consent. `--source` is a
+user-supplied provenance label, not a verified citation or execution receipt.
+Records retain origin, creation/update/review timestamps and revision. API writes
+can specify `expiresAt`; expired entries remain inspectable but are not retrieved.
+
+`disable` persists opt-out for this project and scope and blocks writes/acceptance.
+Read, list, forget and clear remain available. `clear` removes all pending and
+accepted entries while preserving the opt-out setting. `--no-memory` disables
+curated retrieval and SDK memory loading/capture for one local run/chat/resume
+invocation. It does not remove messages already in a resumed run's history.
+Service mode does not accept this flag: the service host owns runtime configuration.
+
+## Scope and bounds
+
+Scope always includes the canonical workspace directory and the existing
+tenant/user/namespace fields. Existing `--workspace`, `--state-dir`, `--tenant`,
+`--user` and `--namespace` flags select it explicitly. The default namespace is
+already workspace-derived. Even with a shared state directory and the same
+explicit namespace, separate workspace directories remain isolated. A renamed
+or copied project gets a different binding; there is no automatic merge, global
+scope, Git-remote identity inference or cross-user permission inference. Directory
+symlink aliases of the same canonical workspace use the same project. These
+scope labels are host-owned selectors, not authentication: users with access to
+the same OS-owned database can edit it directly.
+
+| Bound | Limit |
+| --- | --- |
+| Accepted and pending entries together | 128 |
+| Entry content | 4,096 UTF-8 bytes |
+| Provenance label | 512 UTF-8 bytes |
+| Current document | 256 KiB |
+| Retrieved entries per model request | 3 |
+| Complete rendered context, including metadata | 6,000 UTF-8 bytes |
+| Freshness review interval | 30 days |
+
+Retrieval ranks literal, case-insensitive query terms against content; ties use
+update time and ID. It has no embeddings or semantic recall guarantee. Short
+terms and a small English stop list are ignored. Only matching accepted entries
+are selected. Entire entries that exceed the remaining budget are skipped.
+`memory context "query"` exposes exactly that projection and its byte count.
+Stale entries are labelled; expiry excludes them. Updating a reviewed entry
+refreshes its review time. Byte limits are hard bounds, not exact model token
+counts; the existing overall runtime token budget still applies. Empty memory
+adds no model context.
+
+## Engine API and trust boundary
+
+```ts
+import { openHarnessProjectMemory } from "@zhivex-ai/harness/engine";
+const memory = await openHarnessProjectMemory({ workspace, stateDirectory, scope });
+try {
+  const note = memory.remember({ content: "Use reviewed migrations", source: "Operator" });
+  memory.update(note.id, note.revision, { content: "Review SQLite migrations", source: "Operator correction" });
+  console.log(memory.list(), memory.retrieve("SQLite migrations"));
+} finally { memory.close(); }
+```
+
+`openHarnessProjectMemory`, its types, constants and the host command dispatcher
+are experimental `/engine` additions. No client protocol commands or remote
+service endpoints are added. Local CLI hosts explicitly enable curated project memory and project relevant
+notes on every model request, including resumed runs. Engine hosts opt in with
+`createHarness({ projectMemory: true, ... })`. Omitting the option preserves the
+historical SDK memory integration and opens no curated store. Explicit `false`
+disables both curated and SDK memory, including caller-supplied `memory`.
+These rules also apply to caller-supplied run stores. With `true` or omission,
+caller-supplied SDK `memory` remains an explicit host integration.
+
+Memory reaches the model in a labelled user-context message before the current
+user request, never as system instructions. The projection is ephemeral and is
+not appended to durable run messages. It cannot grant approvals, change execution
+or filesystem permissions, bypass tool policy, certify checks, or create skills.
+Runtime approval checks still apply even when a remembered note claims authority.
+This is an enforced separation of permission state; a model can still be influenced
+by malicious text and must not be assumed immune to prompt injection.
+
+Only explicit content is persisted. Tool output, repository files, conversation
+summaries and model responses are not silently converted into curated memory.
+Known secret patterns are rejected and the existing host secret guard still
+applies. Pattern checks are best effort: they can miss secrets or reject innocent
+text. Do not store credentials or private material you do not want retained.
+
+## Storage, deletion and compatibility
+
+Memory reuses `operations.sqlite` and the SDK's existing `zhivex_agent_memory`
+table with a fully project/scope-bound key outside the SDK's scoped run/agent key
+namespace. Its leading colon cannot match a nonempty URI-encoded SDK namespace,
+regardless of the run or agent ID. A versioned envelope in the existing row format
+holds current records and the enabled setting. There is no
+second memory database or vector store. File-backed run hosts use the same SQLite
+state index that already serves sessions. Writes use SQLite transactions and
+expected revisions so concurrent edits cannot silently replace newer records.
+
+Forget and clear remove content from the active row; earlier revisions and
+deleted-content tombstones are not retained by this feature. SQLite secure-delete
+is enabled for writes, but WAL pages, filesystem snapshots and previous backups
+can still retain bytes. This is not forensic erasure. Existing run histories,
+legacy SDK memory rows, exported state, host logs and model/provider transcripts
+have separate retention. If a model quotes a memory in its response, that quote
+may enter run history. Deleting a memory does not rewrite those histories.
+Explicitly importing an older backup can restore a previously forgotten note.
+
+New state exports include the bound project document using the existing memory
+record shape. Imports validate the envelope/binding, preserve opt-out, and reject
+different destination content; identical imports remain idempotent. Historical
+v1 backups without project memory still import. Older importers reject a backup
+with the new reserved record because it is not a run-bound SDK memory record;
+use the next-version engine to restore such backups. Whole-database host snapshots
+already include the row. There is no configuration or SQL table schema migration.
+
+Legacy automatic last-assistant SDK records are not promoted into curated memory.
+The stable engine default preserves its historical SDK memory integration.
+Explicit curated mode, including local CLI hosts, stops automatic last-assistant
+capture; caller-provided SDK memory remains supported unless memory is explicitly
+disabled. The API additions can ship in a future Harness minor release with a
+matched next Code release and
+updated exact engine dependency. Any broader removal of the stable SDK memory
+default would require a major release under [API stability](STABILITY.md). Candidate package versions remain Harness
+1.3.0 / Code 0.2.0 for development only: they are not publishable replacements for
+the already released artifacts. Release preparation must select new versions,
+update the Code pin and rerun the release gates. Nothing in this change publishes
+a version.
+
+No terminal layout, menu or visual design changes are included. A future `/memory`
+console flow needs coordination with the separate TUI audit/proposals task.

package/docs/README.md

@@ -40,3 +40,5 @@ Primary guides are maintained in English. Historical reports preserve their orig
 language and evidence. Maintainer procedures and reports remain in the repository
 and are excluded from the npm package. Published validation applies to the exact
 release artifact, not automatically to later source changes.
+
+- [Project memory](PROJECT_MEMORY.md): experimental explicit notes, review, retrieval budgets and deletion semantics.

package/docs/STABILITY.md

@@ -4,7 +4,7 @@ The additive [engine entrypoints](ENGINE_API.md) are enumerated in
 [`../contracts/engine-api.json`](../contracts/engine-api.json). Aliases preserve
 their existing root tiers; newly exposed helpers have explicit tiers. The root
 compatibility surface remains unchanged. These entrypoints are source changes
-for the prepared 1.3.0 release and are available in the published RC7; they are absent from registry 1.2.0. Stable package numbering does not upgrade any export tier.
+for the published 1.3.0 release and were available in the published RC7; they are absent from registry 1.2.0. Stable package numbering does not upgrade any export tier.
 
 [`../contracts/public-api.json`](../contracts/public-api.json) is the machine-checked 1.0 baseline for the package root, binaries, CLI commands/subcommands, exit codes, and document schemas. Every runtime and type export is present in the snapshot and belongs to exactly one explicit tier. Exports listed as stable form the intended 1.x compatibility surface; Time-to-Safe-Fix exports are experimental; the explicitly listed beta exports may evolve under the policy below.
 

package/docs/WORKSPACE_CHECKPOINTS.md

@@ -24,4 +24,14 @@ After interruption in `applying`, retry checks every captured file. If all have
 
 There is no single transaction spanning SQLite and filesystem updates. Journaling exposes that boundary and makes recovery conservative. An interrupted partial filesystem update is detected, not automatically rolled back.
 
-Snapshot storage is bounded to 100 records per workspace/scope (captures and restores combined), 2 MiB per record. There is currently no automatic eviction or checkpoint deletion API. Portable state export/import preserves captures and completed restore records with workspace/scope and conversation lineage validation. Unfinished restore operations block export and import because their filesystem recovery state and reviewed authorization are local to the original database. Older bundles without checkpoint records remain readable. Close the checkpoint store before state maintenance or update operations.
+## Reviewed retention
+
+Snapshot storage is bounded to 100 records per workspace/scope (captures and restores combined), 2 MiB per record. There is no automatic eviction. The existing host API supports explicit reviewed removal of stored checkpoint records and completed restore records:
+
+1. Call `prepareRetention({ checkpointIds, completedRestoreIds })` with the exact selected record IDs. It returns the normalized `selection`, affected `records`, record counts, serialized bytes removed and a `planId` bound to the complete scoped inventory.
+2. Present that plan to the operator and enforce explicit review in the integrating host. Possession of the plan ID does not itself grant authorization.
+3. Call `applyRetention(plan.selection, plan.planId)` to revalidate the inventory and remove the reviewed records in one SQLite transaction under the workspace mutation lock.
+
+Pending or unknown restore evidence cannot be removed. A checkpoint referenced by a retained restore operation cannot be removed; completed referencing operations must be included in the reviewed selection or removed first. Inventory changes invalidate the plan, and a failure rolls back the entire selected database removal. Retention changes neither workspace files nor conversation sessions. It does not provide general filesystem deletion or repository rollback.
+
+Portable state export/import preserves captures and completed restore records with workspace/scope and conversation lineage validation. Unfinished restore operations block export and import because their filesystem recovery state and reviewed authorization are local to the original database. Older bundles without checkpoint records remain readable. Close the checkpoint store before state maintenance or update operations.

package/evaluations/representative-assembly-matrix.json

@@ -53,7 +53,8 @@
     "v1.3.0-rc.5",
     "v1.3.0-rc.6",
     "v1.3.0-rc.7",
-    "v1.3.0"
+    "v1.3.0",
+    "v1.4.0-rc.1"
   ],
   "expectedModels": [
     {
@@ -471,6 +472,14 @@
         "qwen": "qwen3.8-flash",
         "openai": "gpt-6-luna"
       }
+    },
+    {
+      "releaseTag": "v1.4.0-rc.1",
+      "models": {
+        "meta": "muse-spark-1.3-contributor",
+        "qwen": "qwen3.8-flash",
+        "openai": "gpt-6-luna"
+      }
     }
   ],
   "expectedCases": [

package/examples/README.md

@@ -1,20 +1,20 @@
-# Examples for Zhivex Harness 1.2
+# Examples for Zhivex Harness 1.3
 
 ## Isolated Bun installation
 
-Requirements: Bun 1.4.0+, Node.js 22.13.0+, and Git on macOS or Linux. After protected 1.3.0 publication, this installs the stable 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 RC publication, this installs the 1.4.0-rc.1 candidate 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.3.0
+bun add --exact --ignore-scripts @zhivex-ai/harness@1.4.0-rc.1
 ./node_modules/.bin/zhx --version
 ./node_modules/.bin/zhx --help
 ./node_modules/.bin/zhx doctor --provider openai --json
 ```
 
-Version must print `1.3.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.
+Version must print `1.4.0-rc.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.
 
 To continue in your actual project, use the [global installation and credential setup](../README.md#installation), 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.3.0",
+  "version": "1.4.0-rc.1",
   "description": "Governed, provider-portable runtime for coding agents with durable approvals and isolated repository execution.",
   "type": "module",
   "license": "MIT",
@@ -135,7 +135,8 @@
     "docs/adr/0002-isolated-mcp-stdio.md",
     "docs/VERTEX.md",
     "docs/TOOL_POLICY.md",
-    "docs/fixtures/mcp-stdio-contract-v1.json"
+    "docs/fixtures/mcp-stdio-contract-v1.json",
+    "docs/PROJECT_MEMORY.md"
   ],
   "scripts": {
     "models:check": "bun run scripts/validate-model-catalog.ts",