mirror-mind 0.33.0 → 0.33.2

package/docs/releases/index.md

@@ -12,6 +12,8 @@ Future release notes should use the structure defined in [Release Notes](../proc
 
 ## Releases
 
+- [v0.33.2 — Git Runs Where Mirror Lives](v0.33.2.md) — patch release of one Change Request, CR138: on a clone install, `runtime status`, `version`, and `diagnose` describe the install from any directory, and `diagnose` grades Mirror's own tree. Git now runs only in the install's own checkout, so a checkout someone else made can no longer run a `core.fsmonitor` command through these commands; `version --start PATH` is the one explicit exception. Package installs were never exposed. No migration.
+- [v0.33.1 — The Install Answers For Itself](v0.33.1.md) — patch release of six RS010 Change Requests: the welcome card, the status line, and both `release-notes` readers answer for the install that is running, never for the cwd or the repository around the install. A package asks its own tree and the npm registry, a clone its own checkout and remote; `pending` says `unknown` when it cannot tell, and a `--ref` value can no longer run a command through git. No migration.
 - [v0.33.0 — One Plugin, Three Runtimes](v0.33.0.md) — minor release closing CV21.DS2: the one plugin works as it is on Claude Code, Codex, and Grok. Its MCP server starts on all three, the explicit Mirror form is recognized in every runtime's spelling, and each session is logged under its runtime with every reply beside its prompt. Also: a faster Pi session start, and notice that Gemini CLI is retired in favor of Antigravity.
 - [v0.32.1 — The Release That Shipped](v0.32.1.md) — patch release that is the published CV22 release: `v0.32.0` was tagged and its publication refused by the retired-surface tripwire over one sentence in Getting Started, now rephrased. No code, behavior, or schema differs from `v0.32.0`; read that note for the release itself.
 - [v0.32.0 — One Language, One Install](v0.32.0.md) — minor release that closes CV22, the TypeScript Core Port. Mirror Mind is one TypeScript package run by Node.js 24, installed with `npm install -g mirror-mind` and wired to Pi, Claude Code, Gemini CLI, or Codex by one documented step each; no Python remains in the repository or the shipped artifact; every command answers as it did. Eleven surfaces are retired with cutoffs, recorded in [Pending Cutoffs](pending-cutoffs.md), which this note carries. A new home imports only the Pi sessions newer than itself.

package/docs/releases/v0.33.1.md

@@ -0,0 +1,174 @@
+---
+digest: >
+  v0.33.1 is a maintenance release: six Change Requests from RS010, closed
+  since v0.33.0, and no story or epic. Its subject is one defect in four
+  surfaces. The welcome card, the status line, and both release-notes readers
+  answered for the directory the person was in, or for the git repository
+  around the install, instead of for the install that was running. Each now
+  asks the install itself: a package its own tree and the npm registry, a
+  clone its own checkout and remote. `release-notes pending` says `unknown`
+  when it cannot tell, and a `--ref` value can no longer run a command through
+  git. Upgrade with `mirror runtime update`; there is no migration.
+---
+
+# v0.33.1 — The Install Answers For Itself
+
+**Date:** 2026-10-15
+
+## Highlights
+
+- **The welcome card and the status line announce the update the running install
+  has** (CR135). A package asks the registry for its channel's version, a clone its own
+  checkout and remote. Before, both asked the git repository of whatever directory the
+  session started in: another project's tag could be announced, a package was never told
+  of a release, and the status line kept a stale `⬆` after the update.
+- **npm runs in the install's own directory**, for the card and for `runtime update`, so
+  a project's `.npmrc` can no longer choose the registry the card reads and the update
+  installs from.
+- **`release-notes latest` and `vX.Y.Z` read the notes the package ships** (CR133). On a
+  Homebrew install on Apple Silicon, where `/opt/homebrew` is itself a git repository,
+  they answered `Release notes: not found`.
+- **`release-notes pending` answers for the install, never the cwd** (CR134). A clone
+  reads its own channel's ref in its own checkout. A package asks the registry which
+  version its channel holds and reads that version's notes from its tarball. When
+  nothing can answer it says `Pending releases: unknown` with a reason and exits 1, so
+  `none` always means a source answered.
+- **`--ref` can no longer run a command.** A value like `--upload-pack=<command>`
+  reached `git fetch` as an option, and git ran it. Refs beginning with `-` are refused,
+  and every git call takes `--end-of-options` before its operands.
+- **A clone's update fetch has git's network budget again** (CR132): 120 seconds, not
+  the 2 seconds a local git call gets.
+
+## Where We Started
+
+`v0.33.0` was installed onto a Homebrew package on 2026-10-14, and three surfaces
+answered wrongly the same day. `mirror runtime release-notes v0.33.0` said `not found`, with
+the note sitting in the package. `release-notes pending` said `none` from `/tmp` and,
+from inside an unrelated project, listed that project's releases after fetching from its
+remote. The welcome card asked the same wrong repository whether Mirror had an update.
+
+The three had one root. The readers were ported faithfully from a Python core that ran
+from a checkout, where the cwd, git's top level, and the install were usually one
+directory. Under npm distribution they are three: a skill runs in the person's project,
+and a global prefix can sit inside someone else's repository. CV22 had already moved the
+version and the welcome card's release note onto the running tree, and handed `latest`
+that tree. But the reader still climbed out of it to git's top level, and `pending` and
+the update check still began at the cwd.
+
+The promotion of `v0.33.0` itself had stumbled on the same day. Its push timed out at two
+seconds and was finished by hand (CR132), and npm's `latest` had needed a move nobody's
+route printed (CR125).
+
+## What Changed
+
+**Each install asks about itself.** The card, the status line, and `pending` detect the
+install from where the front door lives, as `runtime channel` does, with nothing spawned
+and no cwd involved. A package reads its channel's dist-tag through the same call `runtime
+update --check` makes. A clone runs its check, its tag lookup, and its "commits behind"
+count in its own checkout. The channel shown is the install's. On `stable` the card checks
+at every render; on `main` it never checks and shows the cached verdict.
+
+**npm's directory is a trust decision.** A four-lens review of CR135's plan found that npm
+reads the `.npmrc` of the directory it runs in. A cloned project that ships
+`registry=` could therefore choose what the card announced and what `runtime update`
+installed. Every npm call the product makes now runs in the install's own root, whose
+project config is the package's own.
+
+**One bound for the session start.** The card's remote reads share one 5-second deadline,
+and the registry read does not retry, so an unreachable registry costs at most that. A
+cached update the install already has is shown by neither surface, and a successful
+`runtime update` records `up_to_date`.
+
+**Release notes come from the install.** `latest` and `vX.Y.Z` read `docs/releases` under
+the running tree and ask git nothing. `pending` reads, for a clone, `origin/<channel>`
+(or `--ref`) in the clone's own repository, after fetching it there. For a package, it
+resolves the channel's dist-tag to a version, as `runtime update` does when it plans.
+When that version is newer, `npm pack --ignore-scripts` fetches that exact tarball into a
+private directory, and its notes are read in memory and the directory removed. When it is
+not newer, nothing is downloaded.
+
+Three choices shaped the package path:
+
+- the registry tarball, not the GitHub branch: the branch is a second authority that can
+  disagree with the dist-tag, as a half-promoted release does;
+- not version numbers alone, which would not answer "what's new in this update?";
+- a reader of its own over `node:zlib` rather than a spawned `tar`, which would take
+  archive-chosen names as arguments. It stops at 64 MB inflated. It refuses an archive
+  that ends before its end-of-archive block, so a cut tarball cannot pass for a whole one
+  missing its newest notes.
+
+**`unknown` is said.** A failed fetch, a ref or dist-tag that does not resolve, an
+unreachable registry, or an install that cannot be identified answers `Pending releases:
+unknown` with a `Reason:` line and exit 1. `--no-fetch` reads a clone's ref as last
+fetched; a package keeps no copy of its channel, so it cannot answer offline.
+
+**The ref is an operand.** `--ref` was split at its first slash into a remote and a
+branch for `git fetch`, so `--upload-pack=touch X/y`, or `origin/--upload-pack=touch X`,
+reached git as an option, and git ran the command. A test claimed this could not happen.
+It passed only because its marker path was absolute, which the split cuts at the leading
+`/`. The exposure was local: whoever can pass `--ref` can run commands anyway. Refs
+beginning with `-` are now refused, and `fetch`, `ls-tree`, and `show` take
+`--end-of-options`, which covers the half after the slash.
+
+### What you will notice
+
+- On a package, `release-notes pending` shows `Source: npm mirror-mind@stable (<version>)`.
+  On a clone it shows `Source: origin/<channel>`, so a clone on `main` now reads
+  `origin/main`, where it used to read `origin/stable`.
+- A package on `main` answers `unknown`: npm has no `main` dist-tag, as `runtime update
+  --check` already says.
+- A `⬆` that the status line kept after an update is no longer shown once the install
+  has that version.
+
+## Upgrading
+
+```bash
+mirror runtime update          # or: npm install -g mirror-mind
+```
+
+There is no database migration, and no runtime wiring changes. The update itself is run
+by the version you have now, so this release's changes to it apply from the next update
+on: npm running in the install's root, and recording `up_to_date` when it succeeds. A
+Homebrew package on Apple Silicon reads its release notes again from the first command
+after the update.
+
+## Also In This Release
+
+- **For maintainers.** `release:promote` pushes with the network budget, and a failed push
+  shows git's message with a recovery that says what is where (CR132). A `stable` release
+  now ends, in both places the route is printed, with `npm dist-tag add
+  mirror-mind@<version> latest`. The publish workflow stages under `stable` or `next` and
+  nothing else (CR125).
+- **For contributors.** The updater smoke gives the same result on any machine, whatever
+  the shell exports (CR137). The npm package smoke installs into a prefix that is a git
+  repository, the Homebrew shape. Its `npm` is a stub after the install, so it never
+  reaches the live registry.
+
+## Conscious Exclusions
+
+- **`runtime status` and `runtime version` on a clone**, which still read the clone's
+  repository and channel from the cwd, so a healthy clone reads `attention needed` outside
+  its checkout. It is the same family, captured as CR138.
+- **The `release` environment's ref check.** It accepts a dispatch from any ref, so a
+  branch's own copy of the publish workflow could stage (CR136).
+- **A `--channel` option on `pending`**, which `update --check` and `version` have.
+- **The `mm-release-notes` skill's wording**, which still says "the current stable
+  release", true on the default channel.
+
+## What We Learned
+
+A faithful port inherits its oracle's idea of where it runs. Each of these readers matched
+the Python core's goldens, and each was wrong once the program stopped living in the
+directory it was asked about. The tests agreed with the oracle for the same reason: they
+ran from a clone's root, where the cwd, git, and the install coincide. The new tests for
+the card and for `pending` run every case from two places, outside any repository and
+inside an unrelated one, and the answer must not move.
+
+A validation route must say which install it tests. On a machine with both a package and
+a linked checkout, a bare `mirror` runs whichever comes first on the PATH, and both
+report the same version.
+
+## Next Horizon
+
+CR138, the same defect in `runtime status` and `runtime version`, is the visible next
+step. CR136 would harden the publish route. RS010's other hygiene requests follow.

package/docs/releases/v0.33.2.md

@@ -0,0 +1,124 @@
+---
+digest: >
+  v0.33.2 is a maintenance release of one Change Request, CR138, which closes
+  the family v0.33.1 began. For a clone install, `runtime status`, `version`,
+  and `diagnose` described the repository the person was standing in, not the
+  install: a healthy clone read `attention needed` outside its checkout, and
+  `diagnose` reported another project's uncommitted files as Mirror drift.
+  Because git reads a repository's own config, running these commands inside a
+  checkout someone else made could also run a command that checkout chose. Git
+  now runs only in the install's own checkout, and `version --start PATH` is
+  the one explicit exception. Package installs, the default, were never
+  exposed. Upgrade with `mirror runtime update`; there is no migration.
+---
+
+# v0.33.2 — Git Runs Where Mirror Lives
+
+**Date:** 2026-10-15
+
+## Highlights
+
+- **On a clone install, `runtime status`, `version`, and `diagnose` describe the install
+  from any directory** (CR138). A healthy clone is `ready` everywhere. The channel row is
+  what `runtime channel` reports, and the clone role is the checkout's own.
+- **`diagnose` grades Mirror's own tree.** Run inside another project, it reported that
+  project's uncommitted files as Mirror drift and advised committing, stashing, or
+  discarding them. It no longer looks there.
+- **A checkout you did not make can no longer run a command through these commands.**
+  Git reads a repository's `.git/config`, where `core.fsmonitor` names a command git runs
+  on `status`. Run inside such a checkout, `runtime status`, `version`, and `diagnose` ran
+  it. They now run git only in the install's own checkout. `version --start PATH` is the
+  one documented way to inspect another repository.
+- **Package installs were never exposed.** A package inspects no repository; its
+  clone-role row now reads `none (package install)`.
+- **An install that cannot be identified inspects no repository**, and says why;
+  `update --check` answers `unknown` with the reason.
+
+## Where We Started
+
+`v0.33.1` made the welcome card, the status line, and both release-notes readers answer
+for the install instead of the cwd. CR138, captured during that work, named the same
+defect in `runtime status` and `runtime version` for a clone: both named the install on
+their first line, then reported the repository, git state, and channel of whatever
+directory they were run in. REFERENCE.md's recommended update flow begins with `runtime
+status`, so a clone user who ran it from a project was told `attention needed` about a
+healthy install.
+
+Selection found more than the capture said. The clone-role row read the cwd too.
+`runtime diagnose` built the same report, so from inside another project it listed that
+project's uncommitted files as Mirror's and recommended discarding work in a repository
+that was not Mirror's. The plan's review then measured the third face. Git runs a
+repository's own `core.fsmonitor` command on `status`, so these commands, run inside a
+checkout someone else made, ran what that checkout chose. No skill runs these commands,
+so it took a person running them there. The exposure was clone installs, and installs
+that cannot be identified; a package never inspected a repository.
+
+## What Changed
+
+**One rule says where the repository rows come from.** `inspectionRootFor(install,
+start)`: `--start` when given, else a clone's own checkout, else nowhere. The report
+builder and `runtime version` both use it. The builder no longer defaults to the cwd, and
+`status`, `diagnose`, and the update gate pass none.
+
+**The rows are the install's.** The channel row is the answer `runtime channel` gives,
+and the clone role is the checkout's marker. `diagnose`'s worktree findings come from the
+install's tree, so a dirty Mirror checkout is still reported and another project's work
+never is.
+
+**`--start` is the one explicit exception.** `runtime version --start PATH` keeps its
+documented meaning, to inspect the repository at PATH, and is now named as the one way
+these commands run git in a repository the install does not own.
+
+**An install that cannot be identified asks nothing.** Its git rows say `install kind
+unknown: <reason>`, and its verdict is `attention needed`, which is true: `runtime
+update` refuses such an install. `update --check` answers `unknown` with the same reason
+instead of asking the cwd's git.
+
+The tests run every command from a directory in no repository and from a hostile project:
+uncommitted work, its own channel and role markers, and a `core.fsmonitor` that creates a
+marker file. The answers are byte-identical, and the marker never appears, except through
+`--start`, which asks for it. No golden changed.
+
+### What you will notice
+
+- On a clone, `runtime status` gives the same answer from any directory as from the
+  checkout, and `runtime version`'s `Update channel:` matches `runtime channel`.
+- On a package, `Clone role: none (package install)`.
+- `runtime diagnose` may still report `front_door_errors`. Every command that exits 1 to
+  report a verdict, `diagnose` included, is logged as an error and counted. That is
+  CR139, captured and not in this release.
+
+## Upgrading
+
+```bash
+mirror runtime update          # or: npm install -g mirror-mind
+```
+
+There is no database migration, and no runtime wiring changes. The update itself is run
+by the version you have now; the fix applies from the first command after it.
+
+## Conscious Exclusions
+
+- **Counting verdicts as front-door errors** (CR139). `runtime status`'s `attention
+  needed`, `diagnose`'s findings, and `release-notes pending`'s `unknown` exit 1, and the
+  front door logs every non-zero exit as an error that `diagnose` counts. This release
+  removes the false verdicts that fed it, not the loop.
+- **The `release` environment's ref check** (CR136).
+- **Retiring `version --start`.** It was kept, as the explicit override it always was.
+
+## What We Learned
+
+In CR133 to CR135, "never the cwd" was a correctness rule: the person's project is not
+Mirror, so it cannot answer Mirror's questions. CR138 showed it is also a trust boundary.
+The cwd's repository configures the very git that inspects it, so a wrong answer and an
+executed command had the same cause and the same fix, which is where a command decides to
+look.
+
+A test can pin a defect as faithfully as it pins a feature. One CLI test asserted, with a
+comment saying so: "Git inspection still describes the cwd." It was right about the
+oracle and wrong about the product, and it now pins the fix.
+
+## Next Horizon
+
+CR139, the verdict loop, is the visible next step in RS010. CR136 would harden the
+publish route.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mirror-mind",
-  "version": "0.33.0",
+  "version": "0.33.2",
   "description": "Mirror Mind: a local-first memory and identity framework for agentic AI runtimes (Pi, Claude Code, Gemini CLI, Codex)",
   "license": "MIT",
   "repository": {

package/plugins/mirror-mind/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mirror-mind",
-  "version": "0.33.0",
+  "version": "0.33.2",
   "description": "Mirror Mind — local-first memory and identity for agentic runtimes.",
   "author": {
     "name": "Mirror Mind"