doctor reports a registered MCP command as working without establishing its identity

[MongLong0214]

SSOT execution contract

Outcome

Doctor distinguishes "a command is present" from "a CommitLore MCP server is healthy".

Acceptance

• initialize, serverInfo name/version, minimum tool set are probed
• dead/foreign/unverifiable command is not ok
• healthy custom wrapper is preserved

---

Fifth production-readiness review. Recorded for 0.8.0.

0.8.0 changed .mcp.json registration from "the key exists" to "the entry has a non-empty command", which is what stopped null and {} from counting. The remaining gap is identity: {"command": "false"}, or a wrapper an earlier install left behind, still counts as registered. init leaves it untouched and doctor reports ok, which claims a host can start unattended capture.

The tension

Requiring our exact command would overwrite a wrapper somebody chose deliberately — the callers respond to "not registered" by writing our entry over it. Preserving a custom command is right. Reporting its identity as established is not.

What to do

Keep preserving the entry; narrow what doctor claims. Report the command it found rather than a bare ok, or add a check that the registered command actually answers as a CommitLore MCP server.

src/core/mcp-registration.ts, src/commands/doctor/checks/capture-unattended-initiator.ts.

[MongLong0214]

Still open, and the code says so itself. src/core/mcp-registration.ts:88-97:

// Not a probe — nothing is executed here.

registrationIsOurs is a string comparison against the command init writes. What v0.8.1 fixed is the worst case — {"command": "false"} no longer reads as healthy, and a registration that is not the one init writes is preserved and reported as registered-command-unverified rather than as ready. What it does not do is establish that the registration works.

So a registration whose command string is literally commitlore reports ok whether that resolves to a working server, a stale wrapper from a deleted prefix, a wrong-version build, or nothing on PATH at all. That is not hypothetical — four hosts on this machine were found pointing at a temp directory deleted long ago, and the string in their config was correct the whole time.

What would close it: spawn the registered command, complete an initialize handshake, assert serverInfo.name === "commitlore" and that tools/list returns at least the capture tools, and record command, server name, version and tool count as the evidence. With a timeout, and keeping custom-preserved distinct from verified — a registration somebody else wrote deliberately should stay reported as theirs, not silently promoted or replaced.

Worth noting the probe is cheap and already proven: the same handshake was run by hand against five repositories today and each answered in well under a second with commitlore 0.8.1 and seven tools.