mindforge-cc 11.9.3 → 11.9.5

package/changelogs/v11.9.4.md

@@ -0,0 +1,178 @@
+# Changelog
+
+## [11.9.4] — 2026-08-22 — Delivery: the gates register, the tarball matches its tag
+
+Patch release. 11.9.3 argued that an instrument must not report success while doing
+nothing. 11.9.4 is what an adversarial audit of the **published** 11.9.3 artifact found
+when that standard was applied to the delivery itself: **enforcement that installed and
+then declined to register, a tarball that could not be reproduced from its own tag, and a
+README that understated what shipped.**
+
+Every finding here came from measuring the published package in a confined environment —
+not from reading the repository. That distinction is the whole content of this release.
+
+### BREAKING
+
+- **The installer now registers hooks on projects where it previously declined.** If you
+  install into a project that has an ancestor directory containing a `.claude`, MindForge
+  now writes `.claude/settings.json` (merging append-only into any existing file) instead
+  of skipping. On a machine that has ever run Claude Code, `~/.claude` makes that
+  essentially every project — so most installs go from **0 registered hooks to 8**. Three
+  of them can block a tool call. If you were relying on the installer being inert here,
+  it no longer is; `.mindforge/hook-registration.json` records exactly what was written,
+  and the previous settings file is backed up under `.mindforge/backups/`. (#224)
+
+### Fixed
+
+**Hook registration — the gates shipped installed but inert**
+
+- **`register()` skipped whenever any ancestor held a `.claude` directory.** Measured
+  against the published 11.9.3 tarball, confined HOME, `~/.claude` as the only ancestor:
+  **11 hook scripts installed, 0 registered, no settings file written.** The gates that
+  the shipped `CLAUDE.md` calls MANDATORY were copied in and left unreachable. Same
+  sandbox on 11.9.4: **8 registered, installer preflight executed 7 of 8 and verified all
+  3 deny-class hooks returning exit 2** before keeping the file. (#224)
+
+  The reason it printed — *"the harness will read `<ancestor>/.claude/settings.json`, not
+  this directory"* — was wrong three separate ways:
+
+  1. `~/.claude/settings.json` is the **user tier**, applied in addition to the project
+     tier. Its existence carries no information about whether a project file is read, so
+     the condition that suppressed the gates was satisfied by an ordinary laptop.
+  2. For a genuine project ancestor the claim is false too — that file is not read
+     either. Verified with a natural experiment: an ancestor two levels up carried a
+     `PreToolUse` Bash hook appending a marker to a log; across a dozen tool calls with
+     the inner directory as the project root, the log was never created. Skipping did not
+     deliver the gates elsewhere. It delivered them nowhere.
+  3. The git-boundary guard was **dead code**. `stop` was the git toplevel while the walk
+     began at `dirname(projectRoot)`, so when toplevel equalled projectRoot the stop
+     condition could never be true and the walk ran to the filesystem root every time.
+     The boundary meant to keep the check local is why it reached `$HOME`.
+
+  It now warns and registers anyway: a registration that turns out inert costs nothing and
+  becomes live when the harness is launched there, whereas a skip is guaranteed inert. The
+  check additionally requires a real `settings.json` **file** — the old one accepted any
+  directory named `.claude`, and the one it hit in practice held only markdown. (#224)
+
+- **The installer's only failure-path pointer led nowhere.** It told anyone whose hooks
+  were not registered to "see `docs/troubleshooting.md`", where the word *hook* appeared
+  **0** times. That file now carries the section the message names, separating "not
+  registered" from "registered but not live", and including a copy-paste payload that
+  drives a hook directly so a broken hook can be told apart from an unwired one. (#224)
+
+**Release artifacts**
+
+- **The published tarball could not be reproduced from its tag.**
+  `.mindforge/memory/sync-manifest.json` — gitignored, written at runtime by
+  `bin/memory/semantic-hub.js` — was **1 of 1979** shipped files not tracked at
+  `v11.9.3`, so provenance attested to a tree containing a file the repository does not
+  contain. With a `files[]` allowlist, a **directory** entry ships its contents regardless
+  of `.gitignore`; `files[]` already carried a negation for `pattern-library.jsonl` for
+  exactly this reason, and the manifest's entire content is the sync record *for that
+  already-excluded file*. (#225)
+
+- **`mindforge-sdk` was NOT published in this release. It remains at 11.8.0.** This entry
+  originally claimed it shipped with provenance; that claim was false and is corrected here
+  rather than quietly deleted, because a release arguing for measured claims does not get to
+  misstate a supply-chain property.
+
+  What happened: the SDK sat at **11.8.0** on npm while `sync-version.js` kept
+  `sdk/package.json` at canonical — seven releases of disagreement (11.8.1 through 11.9.3,
+  none published) that nothing detected, because `version:check` verifies the tracked file
+  and not what the registry serves. It was also the only one of the three packages with **no
+  attestation**. A publish step was added for it, and the registry rejected it:
+
+  ```
+  npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/mindforge-sdk
+    Error verifying sigstore provenance bundle: Failed to validate repository information:
+    package.json: "repository.url" is "", expected to match
+    "https://github.com/sairam0424/MindForge" from provenance
+  ```
+
+  `sdk/package.json` carried no `repository` field. The other two packages both do, which is
+  exactly why they published and it did not. That field is validated **registry-side at PUT**,
+  after two irreversible publishes have already succeeded — `npm publish --dry-run` does not
+  check it and neither did any gate here. Both are fixed for 11.9.5: the field, and an offline
+  preflight gate that refuses to reach a publish without it.
+
+  The step was also badly placed. It ran **before** `Create GitHub Release` and the `stable`
+  dist-tag move, so its failure skipped both — which is the precise harm the placement comment
+  claimed to prevent. `mindforge-cc@11.9.4` and `mindforge-mcp-server@11.9.4` published
+  correctly with provenance attesting commit 353e8d41; the release page and the `stable` tag
+  were completed by hand afterwards. The finishing steps now run ahead of the additive
+  publishes, so no optional package can strand a release again.
+
+- **The Homebrew formula carries the real 11.9.3 digest.** Verified against an independent
+  measurement rather than the tool's own output, and explicitly confirmed not to be the
+  SHA-256 of npm's 21-byte `{"error":"Not found"}` body — the constant #203 used to write
+  for every unpublished version. (#223)
+
+**Honesty about what is enforced**
+
+- **The README understated the product.** "What is actually enforced" still declared that
+  **no install channel registers hooks**, with a `No / No` table, and stated that the
+  plugin channel's dispatcher crashes on every fire. Measured: the plugin's
+  `scripts/lib/` exists, all **14** path tokens in `plugins/mindforge/hooks/hooks.json`
+  resolve under the plugin root, and driving the dispatcher by hand returns **exit 2** for
+  `mindforge-block-no-verify` and `mindforge-config-protection`. A document that
+  under-claims a security capability is the same defect as one that over-claims it —
+  either way it describes a system that is not the one shipped. Now stated per channel,
+  with the four cases that remain deliberately unenforced and the three liveness
+  preconditions outside MindForge's control. (#225)
+
+**Defects the published-artifact audit found (#222)**
+
+- The **v11.9.3 release page shipped empty**: `changelog-fetcher.js --latest` exits 0
+  while writing zero bytes, so the `||` fallback never fired and a 195-line changelog
+  reached nobody. The step now prefers the in-tree changelog and fails on an empty body.
+- A **shipped CI snippet told users to `npx` a package we do not own**.
+  `npx mindforge …` resolves to an unrelated third-party package; in a fresh runner it is
+  fetched and unpacked, install scripts and all, inside a job holding `MINDFORGE_TOKEN`.
+  Now pinned with `--package=mindforge-cc`.
+- The **version-source gate missed a live defect twice**. `mindforge health` printed
+  `RELEASE v0.4.2` and `Current : v11.9.3` twenty-six lines apart in a project declaring
+  0.4.2, and produced `Unexpected end of JSON input` with no manifest at all — the verb
+  whose job is verifying installation integrity misreporting the installation. Widening
+  the gate surfaced two more of the same shape, one of which bound the **wrong** version
+  silently into approval records, which is worse than no binding because the check still
+  returns a verdict.
+- `mindforge approve` died with ENOENT on any non-Node project. Absent values are now
+  recorded as `null` rather than invented.
+
+**Test infrastructure**
+
+- `tests/production.test.js` carried the uncommitted diff into its clone with
+  `git diff HEAD` (which includes staged files) but committed it with `commit -a` (which
+  stages only modified and deleted **tracked** files). So any commit **adding** a file
+  under `bin/` or `tests/` left the clone dirty and failed the gate's own cleanliness
+  assertion — reintroducing precisely the `--no-verify` pressure that carry exists to
+  avoid, for the one case it did not cover.
+
+### Added
+
+New regression gates, each falsified by reinstating the exact defect and confirming RED,
+with every touched file restored byte-exact afterwards:
+
+- `tests/hook-registration-ancestor.test.js` — six properties, the first of which asserts
+  the ancestor detector fires at all, so the other five cannot pass by never triggering.
+- `every shipped file is tracked in git` — property-based, no name list. It cannot fail on
+  a clean clone, which is how the real leak survived CI, so it is paired with a second
+  test that plants the runtime state in a throwaway clone and then packs.
+- `all three published packages publish with provenance` — counts the `npm publish`
+  invocations rather than matching one, because a single-match regex was satisfied by
+  either of the two packages that already had an attestation while the SDK had none. Also
+  asserts the SDK step is idempotent and ordered after the proven publishes.
+
+### Notes for operators
+
+- **These fixes change installer behaviour on almost every project.** After upgrading,
+  check `.mindforge/hook-registration.json` to see what was registered, and restart the
+  harness — hooks are snapshotted at session start.
+- A registered hook is only *live* if the harness has been restarted, the project is
+  trusted in the harness, and `CLAUDE_PROJECT_DIR` is set with `node` on the hook PATH.
+  None of those three are in MindForge's control; the last is a deliberate trade against a
+  fail-closed shell tail that was measured denying benign commands on a fresh clone.
+- Two gaps remain that require repository settings rather than code, and are recorded
+  rather than claimed fixed: there is no `v*` **tag ruleset** restricting who may create
+  the ref that triggers publishing, and `NPM_TOKEN` is a long-lived repository secret with
+  no GitHub environment in front of it.

package/changelogs/v11.9.5.md

@@ -0,0 +1,104 @@
+# Changelog
+
+## [11.9.5] — 2026-08-22 — The release path can no longer strand itself, and the SDK ships
+
+Patch release, and the shortest one in a while. It exists because 11.9.4 published two
+packages and then failed on the third, and that failure took the release page and the
+`stable` dist-tag with it. Both causes are fixed here, and one of them is the reason this
+release is worth cutting rather than waiting: **`mindforge-sdk` publishes for the first
+time in seven versions, with provenance.**
+
+### Fixed
+
+**A publish that cannot finish the release it started**
+
+- **`sdk/package.json` had no `repository` field.** npm's provenance verification compares
+  that field against the attestation **server-side, at PUT** — so the publish was rejected
+  with `422 Unprocessable Entity … "repository.url" is ""` *after* `mindforge-cc` and
+  `mindforge-mcp-server` had already published irreversibly. `npm publish --dry-run` does
+  not perform that comparison, and nothing in this repository read `repository` at all: all
+  six preflight gates passed on a manifest the registry was guaranteed to reject. The field
+  is added, matching the spelling the other two packages use.
+
+- **`scripts/ci/verify-provenance-metadata.js` makes that failure reachable before the
+  point of no return.** It runs in the release **preflight** job, ahead of every publish,
+  and it does not carry a list of packages: it discovers them from the workflow — every
+  step whose `run` contains both `npm publish` and `--provenance`, resolved through its
+  `working-directory` — so a fourth package is covered without editing the gate.
+  Discovering zero targets is a hard failure rather than a pass, on the principle that a
+  check which examined nothing must not report success.
+
+  Verified the only way that means anything: run against a git worktree at tag `v11.9.4` —
+  the exact tree that the registry rejected — it exits 1 and names `sdk/package.json` and
+  the missing field. It would have stopped that release before anything reached npm.
+
+- **The release steps were ordered so that an optional package could strand the release.**
+  The SDK publish sat *before* `Create GitHub Release` and the `stable` dist-tag move.
+  A failing step fails the job, so both were skipped — which is precisely the harm the
+  placement comment claimed to prevent. The same mode had already fired on **v11.5.1** and
+  **v11.8.3** from the MCP publish; v11.9.4 was its third occurrence.
+
+  Reordered to: `Publish to npm` → `Create GitHub Release` → `stable` dist-tag →
+  `mcp-server` → `sdk`. The rule now encoded in `tests/action-pinning.test.js`: **no step
+  whose failure leaves no residue may be able to skip a step that finishes an irreversible
+  one.** That test previously asserted the opposite and had to be inverted in the same
+  commit — because `Run Full Test Suite` is the release job's first step, a reorder shipped
+  alone would have failed the release at its own gate.
+
+  The two finishers carry guards on their own inputs rather than a bare `!cancelled()`,
+  which would publish a release with a 0-byte body and an unmatched `.tgz` glob when
+  `Build Package` fails — the `bodyBytes=0` defect already seen on v11.9.0, .1 and .2. And
+  deliberately not `continue-on-error`: a tolerated failure makes the run conclude
+  **green**, which is the blindness that let the SDK sit seven versions behind, unattested,
+  with nothing noticing.
+
+**Prose surfaces that shipped stale twice running**
+
+- `bin/utils/readiness-gate.js` scored `RELEASENOTES.md` on `fileExists` while its
+  changelog sibling three lines away checked that the version appeared *in* the file. That
+  asymmetry is why the immutable 11.9.3 tarball's README said "Latest release v11.9.2" and
+  the immutable 11.9.4 tarball shipped with no 11.9.4 entry at all — while `README.md`
+  offers that file as the human-readable route to the BREAKING notes. Both are now checked,
+  anchored rather than by substring (`includes('11.9.4')` is also satisfied by
+  `## v11.9.40`).
+
+  **Policy change, stated plainly:** every release from here needs a `RELEASENOTES.md`
+  entry. Six published 11.x versions do not have one, so that file has been curated rather
+  than exhaustive; the gate only ever looks for the version being released, so those gaps
+  are unaffected.
+
+- README's `## Latest release` is deliberately gated by a **test** rather than written by
+  `sync-version.js`. Auto-bumping the version token onto the previous release's paragraph
+  produces the right number attached to the wrong description — a better-disguised
+  falsehood than a visibly stale one.
+
+- `docs/sdk-reference.md` offered `npx mindforge-cc@stable` as a way to get the SDK
+  "as part of the framework". Measured false: the published package declares exactly
+  `express` and `sql.js` and ships no `sdk/` directory. Removed.
+
+### Added
+
+- **`mindforge-sdk` is published, with provenance** — its first release since 11.8.0 and
+  its first ever attested one. This is not cosmetic. Everything fixed in the SDK across
+  11.8.1–11.9.4 reached nobody, including the one that matters most:
+  `WebSocketEventStream` scheduled a reconnect with `setTimeout(() => this.connect(), …)`
+  and nothing handled the returned promise, so a failed reconnect was an unhandled
+  rejection — fatal under Node's default mode, **terminating the caller's process**. Every
+  consumer on 11.8.0 still has that. (#191)
+
+- `npm run provenance:check` — the gate above, runnable offline.
+
+### Notes for operators
+
+- 11.9.4 is complete but was finished by hand: its GitHub Release was created at the
+  existing tag from the registry's own tarball (verified against `dist.integrity` and both
+  attestation bundles' subject digests), and the `v11.9.4` tag was deliberately **not**
+  moved, because two published packages' provenance attests to the commit it names.
+- The `stable` dist-tag lagged at 11.9.3 between the two releases. Because the dist-tag
+  step now runs *ahead* of both additive publishes, this release moves it forward even if a
+  package publish fails again.
+- Still outstanding, and requiring repository settings rather than code: there is no `v*`
+  **tag ruleset** restricting who may create the ref that triggers publishing, and
+  `NPM_TOKEN` remains a long-lived repository secret with no GitHub environment in front of
+  it. Create the environment *first* — adding `environment:` while none exists publishes
+  exactly as before while looking like a gate.

package/docs/faq.md

@@ -1,4 +1,4 @@
-# MindForge FAQ (v11.9.3)
+# MindForge FAQ (v11.9.5)
 
 ## Is MindForge tied to Claude only?
 No. MindForge supports Claude Code and Antigravity. Install with `--claude`,
@@ -55,7 +55,7 @@ The `deep-research` workflow was removed before the v11.8.0 release (the superpo
 ## Version & Stability
 
 **Q: What version is current?**
-v11.9.3 — verify with `node bin/mindforge-cli.js --version`
+v11.9.5 — verify with `node bin/mindforge-cli.js --version`
 
 **Q: Is v11.9.0 production-stable?**
 Yes. The IQ200 deep-audit (258 discrete checks across 14 dimensions) shows 258/258 passing. 0 CVEs, 0 test failures, 0 ESLint errors, 0 TypeScript errors.
@@ -80,7 +80,7 @@ Spawn dispatch is not yet implemented in v11.9.0. Use `/mindforge:auto` or `/min
 Tier-3 trust uses in-process key simulation in v11.9.0 — this is intentional and safe. `SECURITY_TIER_3_SIMULATED = true` is the documented v11.x behavior. Hardware TPM/HSM is planned for v12.x.
 
 **Q: What is the test coverage?**
-133 test files: 131 pass, 0 failures, 2 env-dependent skips (`browser.test.js` needs a Chromium
+135 test files: 133 pass, 0 failures, 2 env-dependent skips (`browser.test.js` needs a Chromium
 daemon, `sre-integration.test.js` needs git worktree support and a clean tree).
 
 The enforced floor is **30% lines**, gated in CI by the `mindforge-quality` job

package/docs/getting-started.md

@@ -1,4 +1,4 @@
-# MindForge — Getting Started (v11.9.3)
+# MindForge — Getting Started (v11.9.5)
 
 This guide gets you from zero to a working MindForge project in under five minutes.
 
@@ -54,7 +54,13 @@ Run the MindForge MCP server (`mindforge-mcp-server`) over stdio — it exposes
 claude mcp add mindforge -- npx -y mindforge-mcp-server
 ```
 
-This server is also published to the [MCP Registry](https://registry.modelcontextprotocol.io) as `io.github.sairam0424/mindforge` (currently `11.9.0`, marked latest).
+This server is also published to the [MCP Registry](https://registry.modelcontextprotocol.io) as
+`io.github.sairam0424/mindforge`. **The registry entry lags this package** — it is republished
+manually, so check what it actually serves before relying on it:
+`curl -s 'https://registry.modelcontextprotocol.io/v0/servers?search=io.github.sairam0424/mindforge'`.
+To pin a known version instead, install `mindforge-mcp-server` from npm directly. (The previous
+wording named a specific version and marked it latest; both were wrong in both directions, which
+is why this now describes how to check rather than asserting a number.)
 
 ### 4. Homebrew
 
@@ -108,7 +114,7 @@ Or use slash commands: `/mindforge:wf-code-audit`
 ## Your First 5 Minutes with MindForge
 
 1. **Verify install:** `node bin/mindforge-cli.js health`
-2. **Check version:** `node bin/mindforge-cli.js --version` (should print `11.9.3`)
+2. **Check version:** `node bin/mindforge-cli.js --version` (should print `11.9.5`)
 3. **List workflows:** `node bin/mindforge-cli.js workflow list`
 4. **Run first slash command:** Open Claude Code → `/mindforge:status`
 5. **Onboard your codebase:** Open Claude Code → `/mindforge:wf-onboard-codebase`

package/docs/sdk-reference.md

@@ -14,11 +14,11 @@ import {
 } from 'mindforge-sdk';
 ```
 
-Current SDK version: `11.9.3`
+Current SDK version: `11.9.5`
 
 ---
 
-## SDK Exports (v11.9.3)
+## SDK Exports (v11.9.5)
 
 ```javascript
 const {
@@ -28,7 +28,7 @@ const {
   commands,               // Command registry
   batch,                  // Batch execution
   MindForgeMemory,        // Memory interface
-  VERSION                 // '11.9.3'
+  VERSION                 // '11.9.5'
 } = require('mindforge-sdk');
 // or: import { MindForgeClient, VERSION } from 'mindforge-sdk';
 ```
@@ -418,13 +418,19 @@ cd sdk && npm install && npm run build
 ## Installation
 ```bash
 npm install mindforge-sdk
-# or: npx mindforge-cc@stable  # installs SDK as part of the framework
 ```
 
-> **`mindforge-sdk` is versioned independently of the framework.** The release workflow
-> (`.github/workflows/mindforge-release.yml`) publishes `mindforge-cc` and
-> `mindforge-mcp-server` only — it has no `sdk` steps — so `sdk/package.json`'s version
-> tracks the monorepo while the published package does not. At the time of writing the
-> latest published SDK is **11.8.0** (`npm view mindforge-sdk versions`), even though the
-> in-repo `sdk/package.json` reads 11.9.2. Install it unpinned, as above; pinning it to a
-> framework version yields `E404 No match found for version …`.
+> **`mindforge-sdk` lags the framework, and the framework does not contain it.** Installing
+> `mindforge-cc` does **not** give you the SDK: the published package declares exactly two
+> dependencies, `express` and `sql.js`, and ships no `sdk/` directory. A line here previously
+> offered `npx mindforge-cc@stable` as a way to get the SDK "as part of the framework"; that was
+> false and has been removed.
+>
+> The release workflow publishes the SDK as of 11.9.5, with provenance. Its first attempt
+> (v11.9.4) was rejected by the registry — `sdk/package.json` carried no `repository` field, which
+> npm's provenance check validates server-side at publish time — so **versions 11.8.1 through
+> 11.9.4 do not exist on npm** and never will. Check what is actually published with
+> `npm view mindforge-sdk version` rather than assuming it matches the framework: the version in
+> `sdk/package.json` tracks the monorepo because `scripts/sync-version.js` rewrites it, whether or
+> not that version reached the registry. Install it unpinned, as above; pinning it to a framework
+> version that was never published yields `E404 No match found for version …`.

package/docs/troubleshooting.md

@@ -1,4 +1,4 @@
-# MindForge Troubleshooting (v11.9.3)
+# MindForge Troubleshooting (v11.9.5)
 
 This page lists common issues and fast fixes. If you get stuck, start with
 `/mindforge:health`.
@@ -208,3 +208,58 @@ All tests must be run from the MindForge project root: `cd /path/to/MindForge &&
 **Symptom:** `--version` flag reports "Unknown command" on installs older than v11.9.0.
 
 **Fix:** Upgrade: `npx mindforge-cc@latest --claude --local`
+
+---
+
+## Hooks are installed but nothing is blocked
+
+**Symptom:** The hook scripts are present under `.claude/hooks/`, but a command that should be denied
+— say `git commit --no-verify` — runs normally.
+
+Hooks have two separate failure modes: **not registered** (no config names them) and **registered but
+not live** (the config exists, the harness has not applied it). Check them in that order.
+
+**1. Was registration attempted, and what did it decide?** The installer prints one line for every
+outcome, and writes a receipt:
+
+```
+cat .mindforge/hook-registration.json
+```
+
+`registered: false` there carries the reason. Registration is deliberately narrow: Claude Code only,
+`--local` only, non-Windows. A self-install inside a MindForge checkout also declines, because that
+repo maintains its own tracked config.
+
+**2. Restart the harness.** Claude Code snapshots hooks at session start, so a registration performed
+during an open session is not live in it. This is the single most common cause.
+
+**3. Confirm the project is trusted.** User-tier and project-tier settings are applied independently:
+`~/.claude/settings.json` is the user tier and applies to every session, while
+`<project>/.claude/settings.json` is the project tier and needs the project itself to be trusted.
+Measured on one machine: the user-tier hooks fired on every tool call while the project-tier hooks in
+the same session did not, and that project's entry in `~/.claude.json` had
+`hasTrustDialogAccepted: false`. Accept the trust prompt for the directory, then use `/hooks` to
+confirm the entries are listed.
+
+**4. Drive the hook directly** to separate "the hook is broken" from "the hook is not wired". This
+takes the harness out of the loop entirely — a deny-class hook must exit **2**:
+
+```bash
+echo '{"hook_event_name":"PreToolUse","tool_name":"Bash","cwd":"'"$PWD"'","tool_input":{"command":"git commit --no-verify -m x"}}' \
+  | node .claude/hooks/run-with-flags.js mindforge-block-no-verify .claude/hooks/mindforge-block-no-verify.js minimal,standard,strict
+echo "exit=$?"
+```
+
+Exit 2 with a `BLOCKED:` line on stderr means the hook works and the problem is registration or
+trust. Exit 0 with the payload echoed back means the dispatcher could not load the script — check
+that the second path exists under `.claude/hooks/`.
+
+**5. If you launch the harness somewhere else, install there too.** Project settings are read from the
+directory the harness starts in; they are **not** inherited from a parent directory. An ancestor
+project having its own `.claude/settings.json` does not make its hooks apply here, and does not stop
+these from applying — the installer warns when it sees one, and still registers.
+
+**Known residual:** if `CLAUDE_PROJECT_DIR` is unset, or `node` is not on the hook PATH, the
+registered commands exit 1 and the gate is simply absent — the same position as not installing. This
+is a deliberate trade: a fail-closed shell tail was measured denying benign commands on a fresh
+clone.

package/docs/user-guide.md

@@ -1,8 +1,8 @@
-# MindForge User Guide (v11.9.3)
+# MindForge User Guide (v11.9.5)
 
 This guide gets you from install to productive, with the minimum needed to run MindForge in a real project.
 
-> **v11.9.3 Stats:** 35 workflows · 221 slash commands · 232 engine skills · 216 personas · 0 CVEs · 258/258 IQ200 checks passing
+> **v11.9.5 Stats:** 35 workflows · 221 slash commands · 232 engine skills · 216 personas · 0 CVEs · 258/258 IQ200 checks passing
 
 ## Prerequisites
 
@@ -44,7 +44,7 @@ mindforge health          # Verify project integrity
 mindforge security-scan   # Run security checks
 mindforge headless        # Run agent in non-interactive mode
 mindforge --verbose ...   # Enable verbose output for debugging
-mindforge --version       # Print installed version (e.g. 11.9.3) and exit 0
+mindforge --version       # Print installed version (e.g. 11.9.5) and exit 0
 ```
 
 Use `--verbose` (or `-v`) on any command for detailed diagnostic output. Use `--version` (or `-V`) to print the installed version and exit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mindforge-cc",
-  "version": "11.9.3",
+  "version": "11.9.5",
   "description": "MindForge — Sovereign Agentic Intelligence Framework. Sovereign Stability: Production-Hardened Agentic Intelligence (v11)",
   "bin": {
     "mindforge-cc": "bin/install.js",
@@ -29,6 +29,7 @@
     ".mindforge/intelligence/",
     ".mindforge/memory/",
     "!.mindforge/memory/pattern-library.jsonl",
+    "!.mindforge/memory/sync-manifest.json",
     ".mindforge/metrics/",
     "!.mindforge/metrics/token-usage.jsonl",
     ".mindforge/models/",
@@ -67,6 +68,7 @@
     "harness:compliance": "node bin/installer/harness-adapter-compliance.js --check",
     "release:ready": "node bin/utils/readiness-gate.js release",
     "version:check": "node scripts/sync-version.js --check",
+    "provenance:check": "node scripts/ci/verify-provenance-metadata.js",
     "validate:assets": "node scripts/ci/validate-assets.js",
     "eval:retrieval": "node bin/eval/eval-harness.js --set golden-set-retrieval.json --min-recall 0.55",
     "commit": "cz",

package/.mindforge/memory/sync-manifest.json

@@ -1,6 +0,0 @@
-{
-  "pattern-library.jsonl": {
-    "lastSync": "2026-08-21T12:02:25.078Z",
-    "localCount": 1
-  }
-}