a release reaches the CLI wrapper but not the Claude plugin cache, and four generations run at once

[MongLong0214]

Measured on one machine, 2026-08-14, while preparing 0.9.0.

Four generations of this product were running simultaneously

$ ps -axo pid=,ppid=,args= | grep -i 'commitlore.*mcp'

47260  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
91147  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
79775  ~/.local/share/commitlore/v0.8.1/dist/commitlore.mjs
34918  ~/.claude/plugins/cache/commitlore/commitlore/0.6.0/dist/commitlore.mjs
26878  ~/.claude/plugins/cache/commitlore/commitlore/0.6.0/dist/commitlore.mjs
35102  ~/.local/share/commitlore/dev-3b70a1bebfb3/dist/commitlore.mjs

v0.8.1, 0.6.0 and a dev hash, while the repository and .claude-plugin/plugin.json both say 0.8.2.

~/.claude/plugins/cache/commitlore/commitlore/0.6.0 does not exist on disk. Those two processes are holding a deleted directory's inodes and answering from it.

Why a release does not fix this

There are two distribution paths and only one of them is a release:

• the CLI wrapper ~/.local/bin/commitlore — rewritten by install.sh every time, so anything wired through it follows a new version automatically
• the Claude Code plugin — copied into ~/.claude/plugins/cache/ from the marketplace, and install.sh never touches it

The MCP tools an agent actually calls come from the second. So tagging a release and running the installer leaves the tools the users hold at whatever version their cache last copied.

What doctor sees, and what it does not

#644 landed today and its check fires correctly on the surfaces that are registered:

warn  runtime-identity  hook identity differs from CLI: hook v0.8.2; entry …/v0.8.2/dist/commitlore.mjs

It cannot see the list above, because config says what was registered and the process table says what is answering. A process holding a deleted install is invisible to every configuration-derived check by construction.

The branch f001-red-multi-runtime (b20f465) was written for exactly this and adds delivery-mcp-runtime-identity, enumerating live runtimes rather than declared ones. It was held until #644 and #636 landed; both have.

Suggested acceptance

• doctor reports when a live MCP runtime's version differs from the installed CLI's, rather than staying silent
• the release procedure checks .claude-plugin/plugin.json against package.json before tagging, so a version bump cannot land on one and not the other
• the release notes say that plugin users need the marketplace refreshed and their session restarted, because until then the old MCP server keeps answering

The pattern this belongs to

Fourth instance today of one shape: a version-pinned path keeps answering after a newer generation arrives, and nothing fails.

• the index caches a signature status that is not a property of the repository, so two routes grade the same record differently #653 — the index cached a signature verdict without recording which keyring produced it
• query reports a v4 index against a v3 reader and falls back forever without rebuilding #634 — a v3 reader meets a v4 index and falls back forever
• ~/.hermes/config.yaml pins v0.8.2 skills, and old version directories are never removed, so a 0.9.0 binary would read 0.8.2 skills silently
• this — a deleted plugin cache still serving MCP

Each was found separately. They are the same defect: a comparison whose two sides are not bound to the same generation, resolved silently in favour of the older one.

Not doing

The running processes belong to sessions that must not be interrupted. Updating them is what happens when their owner restarts; the work here is making sure the right version arrives when they do.

[MongLong0214]

The measurement that closes this, written to be run by someone else

It needs a release to exist and a session started after it. Neither is available
from here, so this is the procedure rather than the result.

Before

commitlore --version                  # expect the released version
ls ~/.claude/plugins/cache/commitlore/commitlore/     # the generations present

Record what is there. The reported symptom is that this directory keeps
generations the release never wrote.

Do

1. Refresh the marketplace and update the CommitLore plugin.
2. Start a new session. A running host keeps the runtime it loaded; the
   update does not reach it.

Then, from inside the new session

Call commitlore_query with {"kind":"limits","path":"<any tracked path>"} and
read two things from the answer:

runtime.version     the released version, or not
runtime.build_id    a 12-hex digest of the bundle that answered

Then, in a terminal, commitlore limits --json <same path> and compare both
fields.

What each outcome means

observation	disposition
both routes report the released version and the same build_id	one generation answers everywhere — closes
same version, different build_id	two installations of the same release; the plugin cache holds its own copy. Still this issue: a release that lands twice is a release that can land once and stop
MCP reports an older version	the plugin cache did not receive the release — this issue, unchanged, with the update path itself as the defect

build_id is what makes the second row visible at all. Before v1.0.0 the answer
carried no runtime identity, and three of the four installations found here
reported the same version — so "same version" could not distinguish one
installation from four.

One thing this cannot show

Whether a session started before the update keeps serving the old runtime. It
does, by design — hosts load once. That is worth documenting for users rather
than fixing, and it is the reason step 2 is a step and not a note.

[MongLong0214]

Acceptance rewritten against post-release data

Measured 17:30, immediately after v1.0.0 was published, on the machine that
produced the original report:

0.6.0              3 processes   ← the deleted plugin cache this issue named
v0.8.1             2
0.9.0              2             ← no such public release exists
v0.8.2             1
dev-3b70a1bebfb3   1

commitlore --version   0.8.2
latest release         v1.0.0

Three things this settles.

It gets worse with time. Four generations on 2026-08-14, five now.

Publishing v1.0.0 did not reach the CLI. The wrapper still reports 0.8.2.
This issue's title, with the release itself as the evidence.

A build with no public release is running. 0.9.0 is not in the release
list. Something reached a process by a path that is not a release, which is a
distribution question this issue did not previously contain.

Why "one generation running" cannot be the criterion

It was proposed, and it is not satisfiable by this product. A process that is
already running keeps the runtime it loaded until its host restarts, and no
release can reach it. Adopting that as the bar would leave this issue open on a
condition CommitLore does not control.

The criterion, restated so it is checkable

A session started after installing reports the installed release.

commitlore_query → runtime.build_id equals the CLI's runtime.build_id,
and both equal the released build.

That is what a release is responsible for, and it can be judged while stale
processes are still alive. build_id is what makes it judgeable at all: three
of the generations here report distinct versions, but two installations of one
version could not have been told apart before v1.0.0 added it.

What has to be measured next, in this order

1. Whether install.sh re-run updates the CLI from 0.8.2 to 1.0.0. If it
   does, the defect is that nothing prompts it. If it does not, the update path
   itself is broken and that is the fix.
2. Then the plugin: update, start a new session, compare the two build_ids.

Step 2 destroys the only condition under which #634 is measurable, so #634's
measurement comes before it.

[MongLong0214]

The closing condition, once more — and this one needs nobody

Superseding the criterion two comments up. That one still required a session
started after installing, which means waiting on whoever owns the session.

doctor already counts this defect by name:

warn  live MCP runtime identity — 4 live CommitLore MCP runtime(s) are unusable:
      …/plugins/cache/commitlore/commitlore/0.6.0 is missing dist/commitlore.mjs and spec/SPEC.md
      …/share/commitlore/dev-3b70a1bebfb3 is missing dist/commitlore.mjs and spec/SPEC.md

So:

commitlore doctor reports live MCP runtime identity with zero unusable
runtimes.

Fixing it still needs sessions to restart — that part is not ours. But deciding
whether it is fixed is now a command anyone can run, and that is the difference
between an issue that waits on a person and one that waits on a condition.

What v1.0.0 changed about measuring this

Three fields differ between a v1.0.0 CLI and a stale plugin runtime, measured
side by side:

v1.0.0 CLI    runtime present · unreadCommits present · at = now
0.8.0 MCP     runtime absent  · unreadCommits absent  · at = end of day

Any one of those separates the generations; together they are unambiguous. Before
v1.0.0 there was no runtime field at all, and three of the four installations
reported the same version — so "which build answered" was not a question the
product could be asked.

build_id measured from the released CLI: 3a46807bf447, with no path in the
ordinary answer and the full entrypoint available from runtime-identity. That
is §5.2 of the execution contract behaving as specified in production.

Still true, and still the substance of this issue

install.sh v1.0.0 updated ~/.local/share/commitlore/ and the CLI wrapper, and
the plugin cache stayed at 0.8.0. A release reaches the wrapper and not the
tools an agent calls — this issue's title, now demonstrated by the release that
was supposed to be unaffected by it.