commitlore_prepare_capture fails with ENOENT on a 0.6.0 spec path; the Claude plugin cache only has 0.8.0 and the codex cache has 0.8.2

[MongLong0214]

The capture pipeline is unusable through MCP: commitlore_prepare_capture fails immediately, before any draft is written.

What happened

commitlore_prepare_capture(transcript: "<~2.4 KB session note>")
→ commitlore: ENOENT: no such file or directory,
  open '/Users/isaac/.claude/plugins/cache/commitlore/commitlore/0.6.0/spec/SPEC.md'

There is no 0.6.0 anywhere on this machine. What exists:

$ ls -d ~/.claude/plugins/cache/commitlore/commitlore/*/
/Users/isaac/.claude/plugins/cache/commitlore/commitlore/0.8.0/

$ find ~/.claude/plugins/cache/commitlore -name SPEC.md
/Users/isaac/.claude/plugins/cache/commitlore/commitlore/0.8.0/spec/SPEC.md

$ find ~/.codex/plugins/cache/commitlore -name SPEC.md
/Users/isaac/.codex/plugins/cache/commitlore/commitlore/0.8.2/spec/SPEC.md

$ ls ~/.local/share/commitlore/
codex-plugin.json  v0.8.0  v0.8.1  v0.8.2

$ commitlore --version
0.8.2

So three different versions are live at once depending on which surface you ask:

surface	version
commitlore on PATH	0.8.2
commitlore.bin in git config	v0.8.0
Claude plugin cache	0.8.0
codex plugin cache	0.8.2
what prepare_capture looks for	0.6.0

The 0.6.0 reference is the odd one — nothing else on the machine mentions it, so it looks like a
version string that is computed or persisted somewhere rather than read from the running install.

Reproduction

1. Install 0.8.2 and wire the MCP server into a repository (this repo has .commitlore-policy.json
   and commitlore.* git config present).
2. Call commitlore_prepare_capture with any non-empty transcript.
3. Observe ENOENT on a 0.6.0/spec/SPEC.md path.

The MCP server config in the plugin is:

{ "mcpServers": { "commitlore": { "command": "node", "args": ["./dist/commitlore.mjs", "mcp"], "cwd": "." } } }

cwd: "." plus a relative ./dist/commitlore.mjs means the resolved implementation depends entirely
on where the host launches it, which may be how the surfaces drifted apart.

Impact

This blocks the documented capture flow end to end — prepare is the first step, so verify and stage
are unreachable. Commits with real decision context cannot be recorded through MCP at all; the only
路 left is writing trailers by hand, which the tool explicitly advises against.

Possibly the same root cause as a separate report

I filed #631 for a related symptom: the same record reads trust: "directive" through the CLI and
trust: "claim" through MCP. If the MCP surface is resolving against a stale install, both would
follow from one cause. I am reporting them separately because I could not prove they share it.

Environment

• CommitLore 0.8.2 on PATH; commitlore.bin git config pointing at v0.8.0
• macOS 15 (Darwin 25.3.0)
• Claude Code plugin cache at 0.8.0, codex plugin cache at 0.8.2

[MongLong0214]

Follow-up on the impact, from using the fallback.

With prepare_capture broken I wrote the trailers by hand instead. The record indexes correctly:

$ commitlore context Sources/LogicProMCP/Channels/AccessibilityChannel+ModalReconcile.swift --json
records: {"records": 1, "limits": 1, "ruledOut": 2, "warnings": 1, "other": 0}
latest sha 0c4ada89  trust claim
  Limit     = a successful nil from the typed getAttributeResult helper …
  Ruled-out = widen the subrole allowlist alongside AXModal | …
  Ruled-out = treat -25205/-25212 on AXModal as structural absence …
  Warn      = absent AXModal must stay unreadable rather than clean …

But it lands as trust: claim, because a hand-written block carries no Provenance: authored — that
trailer is what the capture pipeline adds. The author is the configured commitlore.trustedauthor.

So the ENOENT does not merely block a convenience: every record written while it is broken is
downgraded to claim, and CommitLore's own MCP instructions tell agents to treat claim as "a
report to weigh, not an order". The constraints I just recorded — including one that exists
specifically to stop a real blocker certifying State A again — will be read as advisory by the next
agent.

Combined with #631 (the same record reading directive on the CLI and claim through MCP), the
practical effect is that the MCP surface currently cannot produce or recognise a directive at all.

One thing that worked well, and I want to say so: the prepare-commit-msg hook caught my first
attempt precisely.

commitlore: line 23 looks like a Limit trailer, but git did not parse it;
            the trailer block needs a blank line before it

Three lines, exact line numbers, exact cause. I had put the trailers directly after a paragraph. That
diagnostic is better than most linters manage.

[MongLong0214]

Classified against the A–Z review (document_version 4.1.0, evidence main@b578ca9890) as a symptom of F-001 — runtime identity and upgrade convergence (P0), not as an independent defect.

The finding records this exact machine state:

PATH CLI            0.8.2
Git hook pin        0.8.0
Claude plugin cache 0.8.0
Codex plugin cache  0.8.2
MCP asset lookup    0.6.0 or dev-<hash>
Index writer        schema v4
MCP reader          schema v3

Every one of those is called commitlore, which is why the symptom reads as a bug in whichever surface the user happened to be looking at.

This issue stays open and its evidence stays as reported. It is not a duplicate to be closed — it is the reproduction that proves the convergence failure is real rather than theoretical, and it is what the fix has to satisfy. Work is tracked under F-001 with the completion condition:

CLI identity == hook identity == live MCP identity == plugin identity

matching on entrypoint and package root, not on a version string alone.

[MongLong0214]

Measured on a live machine — this is current state, not a reconstruction

$ ps -axo args= | grep -i "commitlore.*mcp" | grep -v grep
   3  node …/.claude/plugins/cache/commitlore/commitlore/0.6.0/dist/commitlore.mjs mcp
   3  …/.local/bin/node …/.local/share/commitlore/v0.8.2/dist/commitlore.mjs mcp
   3  …/.local/bin/node …/.local/share/commitlore/v0.8.1/dist/commitlore.mjs mcp
   1  …/.local/bin/node …/.local/share/commitlore/dev-3b70a1bebfb3/dist/commitlore.mjs mcp

Four different runtimes were answering as MCP servers at the same moment, on one machine.
Alongside them: PATH CLI 0.8.2; ~/.local/share/commitlore holding v0.8.0, v0.8.1 and v0.8.2; the Claude plugin cache holding only 0.8.0.

Two of them are running from package roots that no longer exist

plugins/cache/commitlore/0.6.0        bundle=NO   spec=NO
share/commitlore/dev-3b70a1bebfb3     bundle=NO   spec=NO
share/commitlore/v0.8.2               bundle=yes  spec=yes

The 0.6.0 and dev-<hash> processes hold an entrypoint whose installation has been deleted underneath them. They keep serving, and a session routed to one of them gets ENOENT the moment capture needs spec/SPEC.md — which is this issue, and #633.

Why a version comparison cannot find this

Every one of these answers to the name commitlore. Two report a version that no longer has an installation behind it. Comparing version strings between the CLI and a registration finds nothing wrong here: the CLI is 0.8.2, the registration is valid, and the process actually serving the session is 0.6.0 from a deleted directory.

The identity has to be the entrypoint realpath and package root, which is what the review's completion condition already says:

CLI identity == hook identity == live MCP identity == plugin identity

What this becomes

The RED regression for F-001: with more than one live runtime answering, doctor reporting all-green is a failure. This distribution is the fixture.

Reproduce with:

ps -axo args= | grep -i "commitlore.*mcp" | grep -v grep

Evidence retained here as the umbrella for the stale-runtime family (#633, #634, #635).