v0.8.2

Five boundaries where CommitLore could tell you something had worked when it had not.

If you are upgrading

Nothing here changes the record format or how records are read, so no migration is needed. Two behaviours become stricter, and both fail loudly rather than silently:

• An abbreviated or truncated git object id is no longer accepted where a canonical one is expected. If something in your setup persisted a short id, it is now rejected on read instead of being treated as though it named an object.
• The installer exits non-zero when a host's MCP registration cannot actually serve MCP. An install that previously reported success while the integration was dead now reports the failure — and says which host and why.

What was wrong, and what it does now

A truncated object id validated as a canonical one. One pattern, [0-9a-fA-F]{4,64}, was doing two different jobs: matching a full object id and matching a revision a person typed. Under it, a 5-, 39-, 41- or 63-character string passed as canonical and was persisted and compared as though it named an object. Full ids are now exactly 40 or exactly 64 hex — the only two widths git has — and a branch, tag, HEAD~3 or abbreviation is resolved by git to one full id before it enters internal state.

A malformed request looked like an empty answer. The MCP boundary validated draft as a string and then cast each decoded record without checking its shape. A null, a number, or a record whose trailers was a string reached the verifier, which accepted nothing and replied validation_result: "empty" — byte-identical to what a session gets when it genuinely had no decision to record. That is the one distinction the capture contract rests on. Malformed input is now a caller error naming the offending record and field.

A hanging remote could stop your push. The pre-push notes sync ran git fetch and git push with no timeout. The surrounding code was fail-open, but a remote that accepts a connection and then goes quiet never reached the catch — the branch push simply stopped, with nothing explaining why. Those children are now bounded and non-interactive; a notes failure prints one line and the branch push continues.

The installer reported success for a host it never verified. A registration was considered fine because the config mentioned commitlore, or because the command string existed. A directory, a non-executable file, or the wrong arguments were skipped as "already configured" and the installer exited 0. Both installers now delegate to one shared command that treats ownership as the exact wrapper plus mcp, verifies a custom registration by speaking MCP to it, writes config atomically, and returns non-zero for any requested host that fails. When that inspection itself fails, the installer now says so instead of returning a bare status code.

The action that carries records across a squash could not write. It had no git identity, so on a default runner it detected the squash correctly and then died on Author identity unknown. With that fixed it immediately found the opposite defect: squashing a single commit keeps that commit's trailer block intact, so there was nothing to preserve and attaching anyway left two copies of one record. It now skips a record the merge commit already carries.

Also in this release

Capture no longer stages a reference the commit-msg hook would refuse. context builds the index it previously only read, bounded rather than walking all of history on every edit. Commits carrying only Signed-off-by: or Co-authored-by: are no longer refused as malformed records, so DCO and CommitLore can coexist in one repository.

The Node floor is now >=22.23.2, the current Node 22 LTS. node:sqlite is unflagged from 22.13, but its bundled SQLite only supplies the FTS5 virtual table from 22.16.0, so the previous >=22.12.0 floor silently used the slower path on 22.13–22.15.

What this release does not claim

Automatic capture on every coding agent, cryptographically authenticated directives by default, and organization-wide production readiness all remain out of scope. [directive] in the default mode still means the commit's author string matched a configured one — which anyone able to write a commit can set. Signer-to-authority binding is tracked in #597 and is not in this release.