The hook records a version-pinned path, so an upgrade leaves it behind

[MongLong0214]

Found after v1.0.1, in doctor:

warn  runtime identity — hook identity differs from CLI:
      hook v0.8.0 … CLI v1.0.1

The hook resolves through a per-repository git config value:

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

A versioned path. Every upgrade leaves it pointing at the previous install, so
commits in that repository are validated by an old build while the CLI reports
the new one.

This is the fourth instance of one pattern today

.mcp.json            "commitlore"                  the wrapper   → followed the upgrade
Hermes external_dirs .../v0.8.2/hermes/skills      versioned     → broke   (#686)
plugin cache         a copy of the code            a copy        → stalled (#660)
hook commitlore.bin  .../v0.8.2/dist/commitlore.mjs versioned    → this

The one config that pinned nothing is the one that survived. Everything holding a
version or a copy needed a fix.

Two halves, and both are needed

Record the wrapper, not the versioned path. ~/.local/bin/commitlore already
resolves to the current install; a hook written against it follows upgrades for
free, the way .mcp.json did. That is the actual repair, and it only helps hooks
installed after it ships.

Existing hooks need commitlore hooks install re-run. doctor already emits
exactly that as its fix line, so the path exists — what is missing is that
nothing tells a user to run doctor after upgrading.

install.sh cannot do this for them: it has no way to know which repositories
have hooks. That is a real limit and worth stating rather than working around.

Note on the versioned path's original purpose

It is not arbitrary — recording the exact bundle makes the hook independent of
PATH and of whatever node_modules/.bin/commitlore a parent directory holds
(the stub comments say so). The wrapper keeps that property: it is an absolute
path too, just one that does not name a version.

[MongLong0214]

Disposition: documented now, fixed when install.sh is next touched

#695 documents the limit and what to run about it. What remains is the actual
repair, and it is gated with #691 for the same reason.

The repair that was tried and does not work

#694 recorded the bin wrapper. CI caught it:

commitlore.bin: /Users/runner/work/_temp/home/.local/bin/commitlore
outcome: the hook exited 1 under the restricted PATH —
         commitlore: cannot find the CLI this hook was installed with.

The wrapper is a shell script that finds node on PATH. A hook runs where
PATH may carry no node at all — which is why commitlore.node is recorded
beside commitlore.bin in the first place. A .mjs bundle can be launched with
a recorded interpreter; a shell script cannot.

I asserted in that PR that the wrapper "keeps the property the versioned path was
chosen for". Being an absolute path and being launchable by a recorded
interpreter are different properties, and I derived the second from the first.
Three local reproductions passed before CI disproved it, because my PATH had
node.

What the repair actually needs

A stable, version-free path to a .mjs — a directory the installer maintains,
e.g. <data-root>/current/dist/commitlore.mjs, with the versioned directories
still beside it. That keeps both properties: an absolute path, launchable by the
recorded interpreter.

No such directory exists today. Creating one touches install.sh, the uninstall
path, and Windows symlink behaviour, so it belongs with #691's edit rather than
as its own change immediately after a release.

Why not sooner

Six defects came out of the install and distribution path today, one of them
introduced by me an hour ago while fixing this. v1.0.1 shipped and its four
controls all inverted. Reopening that path tonight has no user-facing
justification, and the limit is now stated where a user will meet it.

[MongLong0214]

Reproduced on three real repositories, including this one

Measured on a host running v1.0.1:

commitlore            commitlore.bin → v0.8.2
agent-control-plane   commitlore.bin → v0.8.2
stock-ai-newsletter   commitlore.bin → v0.8.0

This repository's own commit-msg hook was validating commits with v0.8.2 while
v1.0.0 and v1.0.1 were being released from it. doctor says exactly what that
means: the hook validates every commit with 0.8.0, so anything fixed since then
does not apply here.

commitlore hooks install in each repaired it — 15 ok/3 warn → 17 ok/1 warn. The
output names the shape precisely:

commit-msg hook already installed (file unchanged)
recorded CLI repointed: …/v0.8.2/dist/commitlore.mjs -> …/v1.0.1/dist/commitlore.mjs

The hook file is version-independent and never goes stale. Only the pin
recorded in git config does, and no step in the upgrade path re-aims it.

The CI gate is not contaminated — checked rather than assumed

ci.yml:796 does assert commitlore.bin is a bundle, and it was worth checking
whether that made the release gate self-referential. It does not:

• the check runs inside The installed tool works in a real repository, whose
  repo is $(mktemp -d)/repo freshly git init-ed
• a repository initialised moments ago has, by definition, just recorded the
  current bundle

So it verifies that a pin is a bundle, never that a pin is current. That
gap is the whole structure of this defect: the assertion that would have caught
it exists, and runs only where it cannot fail.

The release gate itself builds from PR HEAD (node dist/commitlore.mjs), so what
was compromised is the local developer and agent hook path, not the published
verdict. The real harm is narrower than "the gate was wrong" and still real:
anyone committing locally on this host was validated by a build they had never
shipped.

On severity — warn is the wrong level, and raising it is the wrong fix

Green meant v0.8.2 was satisfied, not v1.0.1 was satisfied. A check reporting
exit 0 for that is reporting a proxy as the measurement.

But promoting it to fail would stop every pipeline that runs doctor as a gate
immediately after an upgrade, for a state the user can repair with one command.
Severity should answer can this be acted on, and here it can.

The fix is the upgrade re-aiming the pin — then warn fires rarely, and when
it does it means something a user must actually decide about. Raising severity is
the response to a state that cannot be fixed, not to one that simply was not.

Gates for this issue

1. An upgrade re-aims existing pins, or fails in a way that says it must be done.
2. A named test that goes red when a pin is reverted to an older version.
   Without it this returns at the next upgrade.
3. Something must assert current, not just is a bundle — the existing
   assertion runs only where it cannot fail.

Still gated with #691 on the next install.sh edit; the evidence above raises
its priority within that gate rather than changing when it opens.