prepare_capture fails with ENOENT on a dev-hash asset root that is never installed

[MongLong0214]

commitlore_prepare_capture fails immediately and cannot be used at all:

commitlore: ENOENT: no such file or directory,
open '/Users/isaac/.local/share/commitlore/dev-3b70a1bebfb3/spec/SPEC.md'

The whole capture pipeline is unreachable, because verify_capture and stage_capture both need the nonce prepare_capture returns.

What is on disk

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

$ find /Users/isaac/.local/share/commitlore -maxdepth 3 -name SPEC.md
/Users/isaac/.local/share/commitlore/v0.8.2/spec/SPEC.md
/Users/isaac/.local/share/commitlore/v0.8.1/spec/SPEC.md
/Users/isaac/.local/share/commitlore/v0.8.0/spec/SPEC.md

$ ls /Users/isaac/.local/share/commitlore/dev-3b70a1bebfb3/
ls: No such file or directory

The payload directories are named by release version. The server resolves its asset root to dev-3b70a1bebfb3, which no installer step ever creates. So the lookup is not a missing file inside a valid directory — the directory itself does not exist.

Reproduction

• macOS, commitlore --version → 0.8.2, binary at /Users/isaac/.local/bin/commitlore
• MCP wiring is the default: .mcp.json → {"command": "commitlore", "args": ["mcp"]}
• Call commitlore_prepare_capture with any transcript. Repository policy is {"mode": "auto", "unattended": true, "max_records_per_commit": 1, "require_verified_evidence": true}, and the call passed unattended: true.
• Fails every time with the ENOENT above.

What still works

commitlore_query answers normally, so the server starts, reads git history and serves records. Only the asset lookup is broken. That is consistent with the CLI and the MCP server disagreeing about which asset root to use rather than with a broken install.

Why it matters

A repository can be fully wired — hooks installed, policy present, MCP connected — and still have no way to capture a record. The failure arrives at the moment of use, after the decision context has already been assembled, and it is not obviously distinguishable from "this commit has nothing worth recording", which is a normal and expected refusal. An operator following the documented flow will read a broken asset path as a rejection.

What I could not determine

Where dev-3b70a1bebfb3 comes from — whether it is a build-time constant baked into a dev binary that shipped as 0.8.2, a stale value in some state file, or derived at runtime. I did not find that string anywhere under ~/.local/share/commitlore. Whether a released 0.8.2 binary from a clean install reproduces this, or only this particular binary, is also unverified.

[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]

Linked to #635 as a candidate of the same root cause — several execution surfaces running different builds — rather than as a duplicate. This issue's own acceptance criteria stay as written and are not absorbed by the umbrella.

Measured on one machine at one moment: four commitlore runtimes answering as MCP servers (0.6.0, v0.8.1, v0.8.2, dev-3b70a1be), two of them from package roots that no longer exist on disk, alongside a PATH CLI at 0.8.2 and a Claude plugin cache at 0.8.0.

If the convergence work closes this symptom, that will be shown against this issue's criteria before it is closed here.