The installed plugin is pinned at 0.4.0 — three releases behind — so no fix since 2026-07-30 has reached a user who installed it

[MongLong0214]

What is on disk

repo / plugin manifest:  0.6.0
latest published:        v0.6.0  (2026-08-01)
installed plugin cache:  0.4.0

Only one version directory exists: ~/.claude/plugins/cache/commitlore/commitlore/0.4.0/. Releases 0.4.1, 0.5.0, 0.5.1 and 0.6.0 never arrived.

Why this is the most important open issue for the product direction

The stated goal is that one install is the last thing a user does. "Runs unattended" has to include staying current, and right now it does not.

Everything fixed since 2026-07-30 is invisible to anyone who installed the plugin — including, from today alone:

#409	anyone who can write refs/notes/commitlore can forge a [directive]
#408	an attack paraphrase passes the injection guard while a defensive record is withheld
#417	an ordinary git fetch silently destroys unpublished records
#406	a pre-#335 index keeps serving records the current classifier rejects
#428	a hook can block the commit it sits next to

Two of those are security fixes. A user on 0.4.0 has none of them and has no signal that they are behind.

What is not the cause

Checked, so the investigation does not restart from zero:

• The cached 0.4.0 server starts and works. Driven directly over stdio it answers initialize and lists all seven tools with empty stderr, identical to a dev build.
• .mcp.json in the cache is well-formed and resolves ${CLAUDE_PLUGIN_ROOT}.

So this is not a broken install. It is an install that never updates.

What needs establishing

1. Whether the marketplace entry this plugin was installed from advertises 0.6.0 or is itself pinned.
2. Whether a version bump in .claude-plugin/plugin.json is what triggers a client refresh, and whether the release process updates whatever the client actually reads.
3. What a user sees when they are behind — today, apparently nothing. doctor knows its own version and could say.

Related

#424 reports commitlore's MCP tools vanishing mid-session on this same 0.4.0 cache. Not established as the cause — the server starts cleanly — but any investigation there should record which version it is talking to, because it is not the one in this repository.

[MongLong0214]

Reported by #434, merged to dev. The refresh itself is still open — see below.

doctor now asks the configured PreToolUse executable for its version and compares it to the running CLI. Against the real 0.4.0 cache on this machine:

warn  PreToolUse hook version — the agent's hook runs 0.4.0 but this CLI is 0.6.0
      — every edit is graded by 0.4.0's rules, not this one's

Not a duplicate of #382, which compares the install the commit-msg hook is pinned to. These are separate installations and it was the PreToolUse one that was stale.

The suite caught a real weakness on the way: test/init.test.ts ships a stub commitlore that prints a hook payload for any argv, --version included, so the first version of the check read that JSON as a version and warned on a healthy install. Exit 0 is not an answer; output that is not shaped like a version is now skipped.

Still open here: making the refresh happen rather than only reporting it. That is client-side — the cache is the client's — and nothing in this repository can update it. What this change buys is that a user who runs doctor finds out, instead of running a two-release-old grader indefinitely with no signal.

[MongLong0214]

Answered. The distribution path is not broken — nothing was ever running the update.

Run from a client session:

/plugin marketplace update commitlore
⎿ ✔ Updated 1 marketplace (1 plugin bumped)

Plugins changed. Run /reload-plugins to activate.

$ ls ~/.claude/plugins/cache/commitlore/commitlore/
0.4.0
0.6.0

So the marketplace entry advertises 0.6.0 and the client fetches it when asked. There is no publishing defect to fix.

The part that is a real finding

Updating is two steps, and neither is automatic. The fetch lands a new version directory; the running server keeps the old one until /reload-plugins. Measured in the same session, immediately after the update above:

$ ps
49700 node .../commitlore/0.4.0/dist/commitlore.mjs mcp

0.6.0 on disk, 0.4.0 in the process, no signal to the user that the two disagree.

That is the state #434's check was built for, and it is worth being explicit that it catches this one rather than only the never-updated case: it asks the executable the hook resolves to for its version, so "cache is new, process is old" reports the same mismatch as "cache is old". Trusting the manifest would have missed it.

What is left here

Documentation, not code: docs/install.md should say that staying current is /plugin marketplace update commitlore followed by /reload-plugins, and that commitlore doctor reports when the running hook is behind.

Closing once that lands. Nothing about the plugin's own distribution needs changing.