Stop a process on the machine from failing a repository command (#750)

[MongLong0214]

Closes #750.

Six cases in test/init.test.ts failed for every developer with an editor session open, and passed on CI runners. One warning caused it:

warn  live MCP runtime identity — 2 distinct live CommitLore runtimes are answering MCP
      <data-root>/v1.0.1/dist/commitlore.mjs
      <data-root>/v1.1.1/dist/commitlore.mjs

<data-root> keeps old versions by design, so that is the ordinary state of a developer machine rather than a misconfiguration.

Why it reached the exit code

init's final step is stricter than doctor on purpose — any check needing attention makes the step incomplete, because init is the command that was supposed to take care of everything at once.

That reasoning does not reach a finding about the machine. The check already made this argument for its own status, and the comment is still there:

warn, not fail. What this observes is the machine, not this repository: a server left running by another session, from an install that has since been deleted, is not something the checkout can fix and must not decide its exit code. Making it fail also made this suite's result depend on what happened to be running while it ran, which is the defect class this check exists to surface.

The same sentence applies one level further, and check() already has the parameter. The two existing overrides clear attention for the no-remote refspec warn and the ENOENT inject fail on exactly this test — "neither is something the user can act on here" (#192, #221).

All three warn rows here now clear it. They stay in the report, which is where a machine-scoped observation belongs; they stop deciding whether a repository-scoped command completed.

The test pins the property, not the symptom

Reproducing the symptom needs a stale server actually running — which is the dependency being removed. A test that needed one would carry the defect it tests for. So the check is driven with an injected scan:

case	status	needsAttention
two live runtimes	warn	false
the scan itself could not run	warn	false
a runtime whose install was deleted	warn	false
one runtime answering	ok	false

Negative control: removing the override fails three of the four.

Why this mattered beyond a red suite

Twice in one session I attributed this failure to a change of my own before checking origin/main, where it failed identically. A file that is usually red stops carrying information, and that is how a real regression gets waved through.

Limit

This is one check's classification, not a scope field. Another machine-scoped check added later will default to claiming attention again, and nothing here would notice.

[github-actions]

CommitLore — record lint

Trailers: clean — 2 commits in origin/main..82fb064ac542a4c6288fcb67acd13062373db968
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 6 paths; query one path at a time to follow its rename chain (6 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}

[MongLong0214]

One place this is broader than the precedent it cites, recorded rather than left to be noticed.

The two existing overrides each turn attention off for one branch of their check:

notes-refspec    only remotes.length === 0    — absent, forced and unreachable still claim attention
inject-runtime   only the ENOENT fail          — a missing hook and a non-zero exit still do
this change      every non-ok branch of mcp-runtime-identity

So the shape is the same and the reach is not, and it is worth saying why that is not a wider principle arriving by the back door.

This check has no fail path and no repository-keyed branch. Its three non-ok outcomes are: the process list could not be enumerated, a live runtime is missing dist/commitlore.mjs or spec/SPEC.md, and two distinct identities are answering. Every one of them is answered by killing a process or reinstalling a cache under <data-root> — machine work, none of it reachable from the checkout init was setting up. The other two checks have branches that are repository work, which is why theirs are per-branch and this one is not.

And the line is drawn at the observer, not at the subject. discoverLiveMcpRuntimes is the only consumer of ps in the checks, and checkMcpRuntimeIdentity is its only reader. The sibling checks that mention processes are all keyed to this repository — mcp-lifecycle reads .git/commitlore/mcp-lifecycle.log, inject-version and inject-runtime read this repository's hooks, unattended-initiator reads this repository's .mcp.json — and all keep attention. Exactly one check reads the process table, and it is this one.

The default is untouched. model.ts:246 still computes needsAttention from the status, and grep -rn needsAttention src/commands/doctor/checks/ returns two files: this one and the pre-existing inject-runtime. Sharing warn does not turn attention off — a check that omits the eighth argument keeps it.

The residual is the one named in the PR's Limit: a machine-scoped check added later defaults to claiming attention again, and nothing here would notice. That is a scope field's job, and this is not one.