mindforge-cc 11.9.3 → 11.9.5

package/RELEASENOTES.md

@@ -1,5 +1,192 @@
 # 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
+Nothing. Twenty-one fixes sharing a single defect: **an instrument reported success while doing
+nothing.** Gates that could not fail, tests a comment satisfied, docs naming scripts that do not
+exist, commands printing success while performing no action, and a publish path no check ever
+touched.
+
+### ⚠️ Breaking (under a patch bump)
+Six behaviour changes, each a bug fix whose correct behaviour differs from what shipped. Read these
+if you script against the CLI or the installer.
+
+- **Routed CLI commands now act on YOUR project, not MindForge's checkout.** The router passed
+  `cwd: ROOT`, so `mindforge classify` diffed MindForge's repository instead of yours and
+  `mindforge health` inspected MindForge's `node_modules`. Of 27 routed commands, 7 changed
+  behaviour — all in the correct direction.
+- **`npx mindforge-cc install`, and any other positional argument, now exits 1.** The installer
+  takes flags only and used to ignore stray words silently, so that command appeared to work while
+  configuring nothing. Use `npx mindforge-cc --claude --local`.
+- **`mindforge verify` now SKIPS unavailable stages instead of failing them.** A project with no
+  ESLint config or no test script was reported as FAILING those stages rather than as not having
+  them. CI that relied on a non-zero exit there will now pass. A run where every stage skipped
+  prints a "NOTHING WAS VERIFIED" banner rather than a clean bill of health.
+- **`scripts/sync-version.js` now exits non-zero when the plugin build artifacts are stale.** A bump
+  used to report success and exit 0 while leaving `npm test` red.
+- **A self-install no longer writes over your tracked files.** Running the installer inside a
+  MindForge checkout printed that it was skipping and then overwrote 149 tracked files, including
+  `CLAUDE.md`, `.claude/**`, `.agent/**` and `.mindforge/**`.
+- **Releases must be tagged on a commit reachable from `main`.**
+
+### Fixes
+- **11 of 27 routed CLI verbs died on `MODULE_NOT_FOUND` in a real install.** The router shipped;
+  six of the scripts it dispatches to did not.
+- **Every `--global` install reported failure on a correct run.** Verification demanded six `bin/**`
+  paths regardless of scope, so a global install — which writes 389 files to `$HOME/.claude` and,
+  deliberately, zero to `bin/` — ended `6 of 12 required file(s) missing` and exit 1, with a
+  `--force` retry that could not help.
+- **`--fetch-sha` hashed npm's 404 error body into the Homebrew formula.** For an unpublished
+  version the registry answers `{"error":"Not found"}` and `curl -sL` exits 0, so the digest written
+  was the SHA-256 of that error text — the same constant for every unpublished version — and
+  `--check` then passed. It now fails closed on both status and gzip magic bytes.
+- **No version channel covered a document a user receives.** `SECURITY.md` — the security policy at
+  the root of the published package — said "Current version: 11.9.0", and five docs titled
+  themselves v11.9.0: three releases stale while every npm manifest was correct. A channel that does
+  not exist cannot drift, so `--check` was green the whole time.
+- **The tag push that publishes was exempt from every gate.** Publishing is triggered by exactly one
+  event — a `v*` tag push — and the repository's only ruleset targets branches, so its six required
+  checks applied to nothing on the path that ships. GitHub cannot attach required status checks to a
+  tag, so this had to be fixed in the workflow itself.
+- **The `stable` dist-tag sat three releases behind `latest`** (11.8.3 against 11.9.2), so
+  `npm i mindforge-cc@stable` delivered a build with none of the 11.9.x fixes. The release workflow
+  now moves it as its final step — forward-only, prereleases skipped.
+- **`mindforge dashboard --status` and `--stop` were documented and implemented nowhere.** Both
+  printed nothing useful. `--stop` also identified its target by the SHAPE of a command line, which
+  matched any `node <anything>/dashboard/server.js` — verified against an unrelated app's dashboard.
+- **`temporal cleanup` printed "Cleaning up…" and "Cleanup complete." with no cleanup between them.**
+- **The protocol files instructed the agent to run scripts that do not exist** (`soul-engine.js`,
+  `shard-controller.js`), and 15 phantom `/mindforge:` slash commands appeared in shipped docs. A
+  reader following the user guide typed `/mindforge:personas --list` and got nothing.
+- **Every abandoned exit left a full copy of the database on disk** — 1.8 GB of orphaned `.tmp` files.
+
+Full detail, including the measured evidence for each: [changelogs/v11.9.3.md](./changelogs/v11.9.3.md).
+
 ## v11.9.2 — 2026-08-16 — Correctness: config gate, audit chain, retrieval, cost ledger
 
 ### What's New

package/SECURITY.md

@@ -1,6 +1,6 @@
 # Security Policy
 
-> **Current version:** 11.9.3 | **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/dashboard/metrics-aggregator.js

@@ -210,7 +210,12 @@ function getApprovals() {
   const { verifyRecord } = require('../governance/approval-record');
   let currentVersion = null;
   try {
-    currentVersion = JSON.parse(fs.readFileSync(path.join(__dirname, '..', '..', 'package.json'), 'utf8')).version;
+    // MindForge's version, resolved by package NAME. `path.join(__dirname, '..', '..',
+    // 'package.json')` reached <project>/package.json in an install — the CONSUMER's manifest — so
+    // verifyRecord() below compared an approval record against the host app's version (0.4.2, say)
+    // instead of MindForge's. The try/catch stopped it crashing, which is why it went unnoticed:
+    // a wrong binding is quieter than a missing one.
+    currentVersion = require('../utils/mindforge-version').resolveMindforgeVersion(process.cwd()).version;
   } catch { /* version binding is skipped if the manifest is unreadable */ }
 
   const now = Date.now();

package/bin/governance/approve.js

@@ -80,7 +80,18 @@ function approve(opts = {}) {
   const root = opts.root || ROOT;
   const approvalsDir = opts.approvalsDir || APPROVALS_DIR;
 
-  const pkg = JSON.parse(fs.readFileSync(path.join(root, 'package.json'), 'utf8'));
+  // TOLERATES A PROJECT WITH NO package.json. This was an unguarded readFileSync, so `mindforge approve`
+  // died with `ENOENT: no such file or directory, open '<project>/package.json'` on any repo that is not
+  // Node — Python, Go, Rust, or any polyglot root. Measured on the published 11.9.3 tarball.
+  //
+  // The FIELDS stay the consumer's on purpose: this record documents a governance decision in the
+  // user's project, so `project` and `version` describing that project is correct. Only the crash was
+  // wrong. Absent values are recorded as null rather than invented — an approval record that guesses
+  // what it is approving is worse than one that admits it does not know.
+  const pkg = (() => {
+    try { return JSON.parse(fs.readFileSync(path.join(root, 'package.json'), 'utf8')); }
+    catch { return { name: path.basename(root) || null, version: null }; }
+  })();
 
   const id = `MF-AUTH-${Date.now().toString(36).toUpperCase()}`;
   const timestamp = new Date().toISOString();

package/bin/governance/verify-approvals.js

@@ -72,7 +72,19 @@ function summary(lines) {
 
 function main(argv = process.argv.slice(2)) {
   const args = parseArgs(argv);
-  const currentVersion = JSON.parse(fs.readFileSync(path.join(ROOT, 'package.json'), 'utf8')).version;
+  // MindForge's version, by package NAME. This read `path.join(ROOT, 'package.json')`, which in an
+  // install is the CONSUMER's manifest — so every approval record was verified against the host
+  // app's version rather than MindForge's, and the command died with ENOENT on any project without
+  // a package.json at all. Version binding is the point of the record; binding it to the wrong
+  // version is worse than not binding it, because the check still reports a verdict.
+  //
+  // Degrades to null rather than throwing: an unresolvable version should make the binding
+  // unverifiable, not make the whole verification unrunnable. verifyRecord treats a null
+  // currentVersion as "do not check the binding".
+  let currentVersion = null;
+  try {
+    currentVersion = require('../utils/mindforge-version').resolveMindforgeVersion(process.cwd()).version;
+  } catch { /* binding unverifiable, reported as such rather than crashing the run */ }
 
   let files = [];
   try {

package/bin/installer/hook-registration.js

@@ -60,6 +60,7 @@
  */
 
 const fs = require('node:fs');
+const os = require('node:os');
 const path = require('node:path');
 const { spawnSync } = require('node:child_process');
 
@@ -366,14 +367,48 @@ function probeInner(projectRoot, failures) {
 
 // ── register ─────────────────────────────────────────────────────────────────
 
-/** Would the harness read a DIFFERENT .claude/settings.json than the one we are about to write? */
-function ancestorClaudeDir(projectRoot) {
-  const top = spawnSync('git', ['rev-parse', '--show-toplevel'], { cwd: projectRoot, encoding: 'utf8' });
-  const stop = top.status === 0 ? path.resolve(top.stdout.trim()) : path.parse(projectRoot).root;
+/**
+ * An ancestor project whose OWN .claude/settings.json a harness launched there would read instead of
+ * ours. Advisory only — see the three corrections below. Returns the directory, or null.
+ *
+ * THIS USED TO SKIP REGISTRATION ENTIRELY, and the reason it printed was wrong in three ways:
+ *
+ *   "the harness will read <ancestor>/.claude/settings.json, not this directory"
+ *
+ * 1. IT TRIPPED ON $HOME, so it tripped for essentially every project. ~/.claude/settings.json is the
+ *    USER TIER: Claude Code applies it to every session IN ADDITION TO the project tier, not instead
+ *    of it. Its existence says nothing about whether a project file is read. Measured on the author's
+ *    machine: the user-tier hooks fire on every Bash call while a project settings.json sits below
+ *    them. So the condition that suppressed the gates was satisfied by the normal state of a laptop.
+ *
+ * 2. FOR A REAL PROJECT ANCESTOR THE CLAIM IS ALSO FALSE — the ancestor's file is not read either.
+ *    Measured with a natural experiment: an ancestor two levels up carried a PreToolUse Bash hook
+ *    appending a marker to a log file. Across a dozen Bash calls with the inner directory as the
+ *    project root, that log was never even created. Claude Code reads the project tier from the
+ *    directory it treats as the project root; it does not walk up for settings. So skipping did not
+ *    deliver the gates "over there", it delivered them nowhere.
+ *
+ * 3. THE GIT-BOUNDARY GUARD WAS DEAD CODE. `stop` was the git toplevel, but the walk started at
+ *    path.dirname(projectRoot) — so when toplevel === projectRoot (the normal case) `dir === stop`
+ *    could never be true and the walk ran to the filesystem root every time. The boundary that was
+ *    supposed to keep this local is why it reached $HOME.
+ *
+ * So: WARN, NEVER SKIP. A registration that turns out to be inert costs nothing and becomes live the
+ * moment the harness is launched here; a skip is guaranteed inert. Two narrowings keep the warning
+ * meaningful rather than universal: $HOME is excluded because it is a tier and not a shadow, and an
+ * actual settings.json FILE must exist — the old check accepted any directory named .claude, of which
+ * a docs folder is a perfectly ordinary example.
+ *
+ * The git boundary is deliberately not repaired, just removed: a git toplevel ABOVE projectRoot means
+ * this project is nested inside another repo, which is exactly the case worth warning about, so
+ * stopping the walk there would suppress the one signal this function exists to produce.
+ */
+function shadowingProjectSettings(projectRoot) {
+  const home = os.homedir();
   let dir = path.dirname(path.resolve(projectRoot));
   for (let i = 0; i < 64; i++) {
-    if (fs.existsSync(path.join(dir, '.claude'))) return dir;
-    if (dir === stop || dir === path.dirname(dir)) break;
+    if (dir !== home && fs.existsSync(path.join(dir, SETTINGS_REL))) return dir;
+    if (dir === path.dirname(dir)) break;
     dir = path.dirname(dir);
   }
   return null;
@@ -391,10 +426,15 @@ function register(options = {}) {
   if (selfInstall) return skip('self-install: the repo maintains its own tracked .claude/settings.json');
   if (process.platform === 'win32') return skip('win32 is unverified for the emitted command shape');
 
-  const ancestor = ancestorClaudeDir(projectRoot);
-  if (ancestor) {
-    return skip(`the harness will read ${path.join(ancestor, '.claude', 'settings.json')}, not this directory — re-run the installer there`);
-  }
+  // Advisory, deliberately not a skip — see shadowingProjectSettings for the three measurements that
+  // demoted it from one. The operator is told what to do about it; the gates still get installed.
+  const shadow = shadowingProjectSettings(projectRoot);
+  const warnings = shadow
+    ? [`${path.join(shadow, SETTINGS_REL)} exists in an ancestor project. These hooks are registered `
+       + 'for THIS directory and are live when the harness runs with it as the project root. If you '
+       + `launch the harness in ${shadow} instead, run the installer there too — its project settings `
+       + 'are read from where it starts, not walked up from.']
+    : [];
 
   const copy = applyCopyManifest(projectRoot, repoRoot);
   if (!copy.ok) return skip(copy.reason);
@@ -424,7 +464,7 @@ function register(options = {}) {
 
   const text = `${JSON.stringify(merged.next, null, 2)}\n`;
   if (dryRun) {
-    return { status: 'dry-run', reason: `would write ${HOOK_SPEC.length} hooks to ${SETTINGS_REL}`, registered: false, preview: text };
+    return { status: 'dry-run', reason: `would write ${HOOK_SPEC.length} hooks to ${SETTINGS_REL}`, registered: false, preview: text, warnings };
   }
 
   const existedBefore = fs.existsSync(absSettings);
@@ -452,6 +492,7 @@ function register(options = {}) {
     preflight_skipped: verified.skipped,
     preflight_skip_reason: 'registered but not executed during preflight: spawns a background '
       + 'process and writes under $HOME. Advisory, so a failure there would not have blocked.',
+    warnings,
     residual_risk: 'CLAUDE_PROJECT_DIR unset, or node off the hook PATH, yields exit 1 and the gate is '
       + 'absent (identical to not installing). No fail-closed shell tail is used: measured, it denies '
       + 'benign commands on a fresh clone.',
@@ -466,6 +507,7 @@ function register(options = {}) {
     target: SETTINGS_REL,
     backup: receipt.backup,
     receipt: RECEIPT_REL,
+    warnings,
   };
 }
 
@@ -500,5 +542,6 @@ module.exports = {
   DENY_CLASS, OWNED_RE, KNOWN_IDS,
   commandFor, profilesFor, isOwned,
   applyCopyManifest, mergeSettings, assertNoLoss, probe,
+  shadowingProjectSettings,
   register, unregister,
 };

package/bin/installer-core.js

@@ -1152,7 +1152,15 @@ async function install(runtime, scope, options = {}) {
   } else {
     Theme.printStatus(c.yellow(`Hooks NOT registered (${hookRegistration.status}): ${hookRegistration.reason}`), 'warn');
     Theme.printStatus(c.dim('The hook scripts are installed but nothing invokes them, so no tool call '
-      + 'is gated. This is stated rather than implied — see docs/troubleshooting.md.'), 'info');
+      + 'is gated. This is stated rather than implied — see "Hooks are installed but nothing is '
+      + 'blocked" in docs/troubleshooting.md.'), 'info');
+  }
+
+  // Non-fatal advisories. Printed for BOTH outcomes, because the case that produces one today —
+  // an ancestor project with its own settings.json — used to CANCEL registration outright, and the
+  // whole point of demoting it to a warning is that the operator hears it without losing the gates.
+  for (const w of hookRegistration.warnings || []) {
+    Theme.printStatus(c.yellow(w), 'warn');
   }
 }
 
@@ -1297,11 +1305,31 @@ async function run(args) {
   const options     = { dryRun, force, verbose, withUtils, minimal };
 
   // Get package.json for version
-  const pJSON = JSON.parse(fsu.read(path.join(SOURCE_ROOT, 'package.json')));
+  // MINDFORGE'S VERSION, NOT THE HOST PROJECT'S — and it must not crash when there is no manifest.
+  //
+  // This read was `JSON.parse(fsu.read(path.join(SOURCE_ROOT, 'package.json')))`, and SOURCE_ROOT is
+  // path.resolve(__dirname, '..'). In an install that lands at <project>/bin/, so it read the CONSUMER's
+  // package.json. Measured on the published 11.9.3 tarball: in a project declaring version 0.4.2,
+  // `mindforge health` printed the banner `RELEASE v0.4.2` and then, 26 lines later, `Current : v11.9.3`
+  // — one command, two contradictory versions, exit 0. In a project with NO package.json the whole
+  // command was `Unexpected end of JSON input`, exit 1, no report at all: fsu.read returns empty for a
+  // missing file and JSON.parse throws.
+  //
+  // This is the same defect 11.9.3 fixed for `--version`, in the one verb whose advertised job is
+  // "verify project health and installation integrity". bin/utils/mindforge-version.js already resolves
+  // correctly — by package NAME, which is what distinguishes our manifest from a consumer's — and it
+  // shipped in the same release. It simply was not used here.
+  //
+  // It THROWS rather than guessing, which is right for a version check and wrong for a banner, so the
+  // banner degrades to 'unknown' instead of taking the whole health report down with it.
+  let bannerVersion = 'unknown';
+  try {
+    bannerVersion = require('./utils/mindforge-version').resolveMindforgeVersion(process.cwd()).version;
+  } catch { /* a banner must never be the reason health cannot run */ }
 
   // Print header and brand manifest
   // Print header and brand manifest
-  Theme.printHeader(pJSON.version);
+  Theme.printHeader(bannerVersion);
   Theme.printBrandManifest();
   // Check for updates only
   if (isCheck) {

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.3.md

@@ -12,6 +12,14 @@ Contains behaviour changes under a patch bump — several of the things being fi
 bugs that a consumer could have been relying on. Read BREAKING before upgrading if you
 script against the CLI or the installer.
 
+> **Corrected after release.** Three measured numbers in this entry were wrong and are fixed above:
+> the count of places `--status`/`--stop` were documented (removed rather than re-guessed — it reads 4,
+> 9 or 15 depending on how you count, which is the argument against stating it); the eslint total, which
+> was 199 on the author's machine and **190** on a clean clone, because 9 problems came from an
+> untracked local directory; and "four releases behind", which is **three** (11.8.3 → 11.9.0 → 11.9.1 →
+> 11.9.2). Found by an adversarial audit of this changelog against the published artifact. A release
+> arguing that measured numbers should be reproducible has to hold its own notes to that standard.
+
 ### BREAKING
 
 Each of these is a bug fix whose correct behaviour differs from the shipped behaviour.
@@ -113,15 +121,16 @@ Each of these is a bug fix whose correct behaviour differs from the shipped beha
   exactly one event — a `v*` tag push — and the repository's only ruleset targets
   branches, so its six required checks applied to nothing on the path that ships. GitHub
   cannot attach required status checks to a tag. A `preflight` job now gates it. (#216)
-- The `stable` npm dist-tag was moved by hand, or not at all — it sat four releases
-  behind `latest` (11.8.3 against 11.9.2), so `npm i mindforge-cc@stable` delivered a
+- The `stable` npm dist-tag was moved by hand, or not at all — it sat three releases
+  behind `latest` (11.8.3 against 11.9.2, via 11.9.0 and 11.9.1), so `npm i mindforge-cc@stable` delivered a
   build with none of the 11.9.x fixes. The release workflow now moves it as its final
   step: forward-only, prereleases skipped, and verified against npm's uncached dist-tags
   endpoint rather than the CDN-cached packument. (#216)
 
 **Dashboard**
 
-- `--status` and `--stop` were documented in nine places and implemented in none; both
+- `--status` and `--stop` were documented across the harness roots and the docs and implemented
+  nowhere; both
   printed nothing and exited 0. Now implemented, before `express` is required, so they
   work without the dependency installed. (#206)
 - `--stop` identified the target by the SHAPE of its command line, which matched any
@@ -141,8 +150,8 @@ Each of these is a bug fix whose correct behaviour differs from the shipped beha
 **Verification**
 
 - `mindforge verify`'s lint stage used `--max-warnings=0`, which made it impossible to
-  pass in the repository it ships from: `npx eslint .` reports 199 problems / 0 errors /
-  199 warnings, so `verify` reported a lint FAILURE on a tree that is green by the
+  pass in the repository it ships from: on a clean clone `npx eslint .` reports 190 problems /
+  0 errors / 190 warnings, so `verify` reported a lint FAILURE on a tree that is green by the
   project's own contract. Aligned with the project's definition; errors still fail. (#204)
 - `temporal cleanup` printed "🧹 Cleaning up old temporal snapshots..." and
   "✅ Cleanup complete." with no cleanup between them. Now wired to