mindforge-cc 11.9.4 → 11.9.5

package/.mindforge/config.json

@@ -1,5 +1,5 @@
 {
-  "version": "11.9.4",
+  "version": "11.9.5",
   "environment": "development",
   "governance": {
     "drift_threshold": 0.75,

package/CHANGELOG.md

@@ -1,6 +1,109 @@
 # Changelog
 
-## [11.9.4] — 2026-08-22 — Delivery: the gates register, the tarball matches its tag, three packages attested
+## [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.
+
+## [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
@@ -71,13 +174,36 @@ not from reading the repository. That distinction is the whole content of this r
   exactly this reason, and the manifest's entire content is the sync record *for that
   already-excluded file*. (#225)
 
-- **`mindforge-sdk` is published again, with provenance.** It 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**. The release workflow now
-  publishes it with `--provenance`, after the two proven publishes and before the GitHub
-  Release, so the newest step cannot cost the others their artifacts.
+- **`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

package/MINDFORGE.md

@@ -1,9 +1,9 @@
-# MINDFORGE.md — Parameter Registry (v11.9.4)
+# MINDFORGE.md — Parameter Registry (v11.9.5)
 
 ## 1. IDENTITY & VERSIONING
 
 [NAME]    = MindForge
-[VERSION] = 11.9.4
+[VERSION] = 11.9.5
 [STABLE]  = true
 [MODE]    = "Platform Sovereign"
 [REQUIRED_CORE_VERSION] = 11.9.1

package/README.md

@@ -6,14 +6,24 @@
 
 ## Latest release
 
-**v11.9.3** (2026-08-21) — Honesty: gates that can fail, commands that run, a release path that is
-checked. Twenty-one fixes sharing one defect — an instrument reporting success while doing nothing:
-a self-install that printed "skipping" and overwrote 149 tracked files, 11 of 27 routed CLI verbs
-dying on `MODULE_NOT_FOUND` in a real install, `--fetch-sha` hashing npm's 404 body into the Homebrew
-formula, no version channel covering any document a user receives, and a publish path no check ever
-touched. **Contains behaviour changes under a patch bump** — several fixed bugs whose correct
-behaviour differs from what shipped. See the BREAKING section in
-[CHANGELOG.md](./CHANGELOG.md), or [RELEASENOTES.md](./RELEASENOTES.md) for human-readable notes.
+**v11.9.5** (2026-08-22) — The release path can no longer strand itself, and the SDK ships.
+11.9.4 published two packages and then failed on the third; because that step sat *before* the
+release page and the `stable` dist-tag move, its failure skipped both. Fixed two ways: the steps
+that finish a release now run ahead of any additive package publish, and a new offline preflight
+gate refuses to reach a publish that the registry will reject. Verified against a worktree at tag
+`v11.9.4` — the exact tree npm rejected — the gate exits 1 and names the file.
+
+**`mindforge-sdk` publishes for the first time since 11.8.0, and for the first time with
+provenance.** Everything fixed in it across 11.8.1–11.9.4 had reached nobody, including a
+`WebSocketEventStream` reconnect whose unhandled rejection **terminates the caller's process**.
+
+The previous release, **v11.9.4**, is where the hook gates started actually registering: 11.9.3
+shipped the code and then declined to run it on essentially every project. Measured against the
+published tarballs — 11.9.3: **11 hook scripts installed, 0 registered**; 11.9.4: **8 registered,
+3 deny-class verified blocking**. That **behaviour change under a patch bump** still applies — the
+installer writes `.claude/settings.json` where it previously declined, merging append-only and
+backing up first. See the BREAKING section in [CHANGELOG.md](./CHANGELOG.md), or
+[RELEASENOTES.md](./RELEASENOTES.md) for human-readable notes.
 
 ---
 
@@ -22,8 +32,9 @@ behaviour differs from what shipped. See the BREAKING section in
 Read this before the install instructions. MindForge ships a large corpus of agent
 instructions — commands, skills, personas, protocols — and those are advisory: they work by
 being in the model's context, and a model can decline them. The parts that would *block* an
-action are hooks. Through 11.9.2 **no channel registered them**; as of 11.9.3 both channels
-register and execute them **on Claude Code**, and nowhere else.
+action are hooks. Through 11.9.2 **no channel registered them.** 11.9.3 added the registration code
+but it declined to run on almost every project, so in practice nothing was enforced there either.
+**As of 11.9.4** both channels register and execute them **on Claude Code**, and nowhere else.
 
 | Capability | Plugin channel | `npx` channel |
 |---|---|---|

package/RELEASENOTES.md

@@ -1,5 +1,129 @@
 # Release Notes
 
+## v11.9.5 — 2026-08-22 — The release path can no longer strand itself, and the SDK ships
+
+### Why this release exists
+
+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:
+
+```
+success  Publish to npm                        <- mindforge-cc@11.9.4        (irreversible)
+success  Publish standalone MCP server to npm  <- mindforge-mcp-server@11.9.4 (irreversible)
+failure  Publish the SDK to npm                <- 422: "repository.url" is ""
+skipped  Create GitHub Release
+skipped  Point the stable dist-tag at this release
+```
+
+Two causes, both fixed here.
+
+**The metadata was only ever validated by the registry.** `sdk/package.json` had no
+`repository` field, and npm compares that field against the attestation **server-side at PUT**.
+`npm publish --dry-run` does not check it and nothing here read `repository` at all — so all six
+preflight gates passed on a manifest guaranteed to be rejected. There is now an offline gate in
+*preflight*, ahead of every publish, that discovers the provenance-publishing packages from the
+workflow itself. Run against a worktree at tag `v11.9.4` — the tree the registry rejected — it
+exits 1 and names the file. It would have stopped that release.
+
+**The step order let an optional package strand the release.** The SDK publish sat before the
+release page and the dist-tag move, so its failure skipped both. The same mode had already fired
+on v11.5.1 and v11.8.3. Reordered so the steps that *finish* a release run ahead of any additive
+package publish — which means this release moves `stable` forward even if a package fails again.
+
+### The user-visible part
+
+**`mindforge-sdk` publishes for the first time since 11.8.0, and for the first time with
+provenance.** Everything fixed in the SDK across 11.8.1–11.9.4 had reached nobody, including
+this: `WebSocketEventStream` scheduled a reconnect 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.
+
+### Also fixed
+
+- `bin/utils/readiness-gate.js` scored `RELEASENOTES.md` on existence while its changelog sibling
+  checked the version was *in* the file. That asymmetry is why both prose surfaces shipped stale
+  in 11.9.3 and again in 11.9.4. Both are now checked, anchored rather than by substring.
+  **Policy change:** every release from here needs an entry in this file.
+- `docs/sdk-reference.md` claimed `npx mindforge-cc@stable` installs the SDK "as part of the
+  framework". Measured false — the published package declares exactly `express` and `sql.js` and
+  ships no `sdk/`. Removed.
+
+### Note on 11.9.4
+
+It 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. The `v11.9.4` tag was deliberately **not** moved, because two published
+packages' provenance attests to the commit it names.
+
+## v11.9.4 — 2026-08-22 — Delivery: the gates register, the tarball matches its tag
+
+### The headline
+
+**11.9.3 shipped the hook-registration code and then declined to run it.** The installer skipped
+whenever any ancestor directory contained a `.claude`. On a machine that has ever run Claude Code
+that means `~/.claude`, so essentially every install copied the enforcement in and wired none of it.
+
+Measured against the published tarballs in a confined sandbox, with `~/.claude` as the only ancestor:
+
+```
+11.9.3:  11 hook scripts installed, 0 registered, no settings.json written
+11.9.4:   8 registered, preflight executed 7 of 8, 3 deny-class verified blocking
+```
+
+The reason the installer printed was wrong three separate ways:
+
+1. `~/.claude/settings.json` is the **user tier**, applied in addition to the project tier. Its
+   existence says nothing about whether a project file is read — so the condition that suppressed
+   the gates was satisfied by an ordinary laptop.
+2. For a real project ancestor the claim is false too: that file is not read either. Proved with a
+   marker hook two levels up that never fired across a dozen tool calls. Skipping did not deliver
+   the gates elsewhere; it delivered them nowhere.
+3. The git-boundary guard was dead code, which is why the walk reached `$HOME` at all.
+
+It now warns and registers anyway. A registration that turns out inert costs nothing; a skip is
+guaranteed inert.
+
+### ⚠️ Behaviour change under a patch bump
+
+The installer now writes `.claude/settings.json` on projects where it previously declined — for most
+users, **0 registered hooks becomes 8**, three of which can block a tool call. It merges append-only
+into any existing file, backs the previous one up under `.mindforge/backups/`, and records exactly
+what it did in `.mindforge/hook-registration.json`.
+
+A registered hook is only *live* if the harness has been **restarted** (hooks are snapshotted at
+session start), the project is **trusted** in the harness, and `CLAUDE_PROJECT_DIR` is set with
+`node` on the hook PATH. See *Hooks are installed but nothing is blocked* in
+`docs/troubleshooting.md`.
+
+### Fixes
+
+- The installer's only failure-path pointer led nowhere: it said "see `docs/troubleshooting.md`",
+  where the word *hook* appeared **0** times. That section now exists.
+- The published tarball was not reproducible from its own tag. `.mindforge/memory/sync-manifest.json`
+  — gitignored, written at runtime — 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.
+- The README understated the product: it still said **no channel registers hooks** and that the
+  plugin dispatcher crashes on every fire. Measured: 14 of 14 plugin path tokens resolve and two
+  deny-class hooks return exit 2. A document that under-claims a security capability is the same
+  defect as one that over-claims it.
+- Defects an 8-agent audit found in the *published* 11.9.3: an empty release page, a shipped CI
+  snippet telling users to `npx` a package we do not own, and a version-source gate that missed a
+  live defect twice.
+- The Homebrew formula carries the real 11.9.3 digest, verified against an independent measurement.
+
+### Known issue in this release
+
+**`mindforge-sdk` did not publish and remains at 11.8.0.** A publish step was added for it and the
+registry rejected it with 422: `sdk/package.json` carried no `repository` field, which npm's
+provenance verification validates **server-side at publish time** — `npm publish --dry-run` does not
+check it, and no gate here did either.
+
+Worse, the step was placed *before* the release-page and dist-tag steps, so its failure skipped
+both. `mindforge-cc@11.9.4` and `mindforge-mcp-server@11.9.4` published correctly with provenance;
+the release page and the `stable` tag were completed by hand afterwards. Both causes are fixed for
+the next release: the missing field, an offline preflight gate that refuses to reach a publish
+without it, and a reordering so the steps that finish a release run ahead of any optional package.
+
 ## v11.9.3 — 2026-08-21 — Honesty: gates that can fail, commands that run, a release path that is checked
 
 ### What's New

package/SECURITY.md

@@ -1,6 +1,6 @@
 # Security Policy
 
-> **Current version:** 11.9.4 | **npm audit:** 0 vulnerabilities across root, sdk, mcp-server
+> **Current version:** 11.9.5 | **npm audit:** 0 vulnerabilities across root, sdk, mcp-server
 
 ## Supported Versions
 

package/bin/utils/readiness-gate.js

@@ -100,12 +100,28 @@ function releaseReadinessChecks(root) {
       pass: Boolean(pkgVersion) && pkgVersion === configVersion,
       fix: `Align versions: package.json=${pkgVersion || '?'} vs config.json=${configVersion || '?'}`,
     },
+    // CHECKS CONTENT, NOT MERE EXISTENCE, and that change has a cost worth naming: from now on every
+    // release needs a RELEASENOTES entry. Six published 11.x versions do not have one (11.0.0, 11.2.0,
+    // 11.2.1, 11.4.0, 11.7.1, 11.9.1) — the file has been curated rather than exhaustive. Those gaps are
+    // unaffected, because this only ever looks for the version being released.
+    //
+    // WHY IT CHANGED. This gate passed on `fileExists` while its changelog sibling three lines down
+    // checked that the version was IN the file. That asymmetry is why both prose surfaces shipped stale
+    // twice running: 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 here at all — while README.md offers this
+    // file as the human-readable route to the BREAKING notes. 348a3a2c fixed the identical defect one
+    // release earlier by hand and added no gate, and it recurred immediately.
+    //
+    // Anchored, not `includes`. A substring test for "11.9.4" is also satisfied by "## v11.9.40" and by
+    // "## v11.9.4-notyet" — measured, when the equivalent test assertion was falsified.
     {
       id: 'releasenotes',
-      label: 'RELEASENOTES.md present',
+      label: 'RELEASENOTES.md present and has an entry for the current version',
       points: 2,
-      pass: fileExists(root, 'RELEASENOTES.md'),
-      fix: 'Add RELEASENOTES.md for this release.',
+      pass: fileExists(root, 'RELEASENOTES.md') && Boolean(pkgVersion)
+        && new RegExp(`^## v${pkgVersion.replace(/\./g, '\\.')}(?![\\d.\\w-])`, 'm')
+          .test(safeRead(root, 'RELEASENOTES.md')),
+      fix: `Add a "## v${pkgVersion || '?'}" section to RELEASENOTES.md. README.md links here as the human-readable route to the BREAKING notes, so releasing without one points readers at a file whose newest entry describes a different version.`,
     },
     {
       id: 'changelog',

package/changelogs/v11.9.4.md

@@ -1,6 +1,6 @@
 # Changelog
 
-## [11.9.4] — 2026-08-22 — Delivery: the gates register, the tarball matches its tag, three packages attested
+## [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
@@ -71,13 +71,36 @@ not from reading the repository. That distinction is the whole content of this r
   exactly this reason, and the manifest's entire content is the sync record *for that
   already-excluded file*. (#225)
 
-- **`mindforge-sdk` is published again, with provenance.** It 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**. The release workflow now
-  publishes it with `--provenance`, after the two proven publishes and before the GitHub
-  Release, so the newest step cannot cost the others their artifacts.
+- **`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

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.4)
+# 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.4 — 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?**
-134 test files: 132 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.4)
+# MindForge — Getting Started (v11.9.5)
 
 This guide gets you from zero to a working MindForge project in under five minutes.
 
@@ -114,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.4`)
+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.4`
+Current SDK version: `11.9.5`
 
 ---
 
-## SDK Exports (v11.9.4)
+## SDK Exports (v11.9.5)
 
 ```javascript
 const {
@@ -28,7 +28,7 @@ const {
   commands,               // Command registry
   batch,                  // Batch execution
   MindForgeMemory,        // Memory interface
-  VERSION                 // '11.9.4'
+  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.4)
+# MindForge Troubleshooting (v11.9.5)
 
 This page lists common issues and fast fixes. If you get stuck, start with
 `/mindforge:health`.

package/docs/user-guide.md

@@ -1,8 +1,8 @@
-# MindForge User Guide (v11.9.4)
+# 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.4 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.4) 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.4",
+  "version": "11.9.5",
   "description": "MindForge — Sovereign Agentic Intelligence Framework. Sovereign Stability: Production-Hardened Agentic Intelligence (v11)",
   "bin": {
     "mindforge-cc": "bin/install.js",
@@ -68,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",