MCP commitlore_query reports trust:"claim" for a record the CLI reports as trust:"directive"

[MongLong0214]

Same repository, same path, same record, same moment — the MCP surface and the CLI disagree on the trust grade.

This matters because the MCP surface is the one agents read, and CommitLore's own MCP instructions say to treat directive as a constraint and claim as "a report to weigh, not an order". An agent reading through MCP therefore ignores constraints it should be obeying.

Reproduction

Repository: a repo with commitlore.trustedauthor configured and at least one record authored by that identity carrying Provenance: authored.

$ git config --get commitlore.trustedauthor
weplay0628@gmail.com

$ git log -1 --format=%ae 38df9665
weplay0628@gmail.com

$ git log -1 --format=%B 38df9665 | grep ^Provenance:
Provenance: authored

Both conditions for directive are satisfied. Now query the same path two ways.

CLI:

$ commitlore context Sources/LogicProMCP/Channels/AccessibilityChannel+MarkerDelete.swift --json \
  | jq -r ".records[0].trust"
directive

MCP (commitlore_query with kind: "context", same path), same moment:

{
  "sha": "38df9665586d5f5e5ed28367dc706dbbe5fb6f99",
  "trust": "claim",
  "provenance": "authored",
  "trailers": [
    { "key": "Provenance", "value": "authored" },
    { "key": "CommitLore-Version", "value": "0.7.1" }
  ]
}

The record's own provenance field is "authored" in the MCP response, so the MCP server parsed the trailer correctly — it is the trusted-author half of the decision that differs.

Possibly relevant: a version skew in git config

$ git config --get commitlore.bin
/Users/isaac/.local/share/commitlore/v0.8.0/dist/commitlore.mjs

$ commitlore --version
0.8.2

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

commitlore.bin still points at the v0.8.0 dist after upgrading to 0.8.2. If the MCP server resolves its implementation through commitlore.bin while the CLI on PATH is 0.8.2, the two are running different code — which would explain the disagreement, and would also mean upgrades silently do not reach the MCP surface.

I have not confirmed that is the mechanism; it is the most likely candidate I could see from the outside.

Why I am reporting this rather than working around it

A trust grade that differs by access path is worse than one that is simply wrong, because the CLI answer looks correct and the MCP answer looks plausible. An agent following the documented semantics will silently downgrade real directives.

Environment

• CommitLore 0.8.2 (commitlore --version), commitlore.bin pointing at v0.8.0
• macOS 15 (Darwin 25.3.0), node via commitlore.node
• Record written by CommitLore 0.7.1, read by 0.8.2

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