Canonical merge of #879 - #880
Merged
Merged
Conversation
CommitLore — record lintTrailers: clean — 4 commits in Active constraints for the paths this PR touchesLimits (390)
Truncated: 829 lines omitted — the comment hit GitHub's 65000 character limit. Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
`hook-runtime` ran the installed stub as one process and read its exit as the stub's. But the stub runs the hook it preserved at install time first and exits with that hook's code, verbatim, before commitlore is resolved. So a preserved hook calling `node` by name died with 127 under git's PATH, and the row said "the hook cannot find a node interpreter" about commitlore's hook, with `commitlore hooks install` as the fix. That command rewrites only commitlore's own file, reported it unchanged, and the next `doctor` failed identically (#876). The preserved hook now runs on its own first, under the same PATH-less environment and through sh the way the stub invokes it. If it exits non-zero the row says commitlore's hook is not what failed, names the preserved hook by path, classifies its first stderr line the same way the stub's was (node missing, node threw, unclear), and prescribes a fix aimed at that file. Only when it has passed does the stub run, so every remaining failure is commitlore's own resolution. `commit-msg-hook` inherits the runtime row's outcome when it is blocked on it; it now inherits the fix as well. It was the row the reporter read, and it kept saying `hooks install` under an outcome that had just explained why that could not help. Not addressed: the stub still lets a broken preserved hook block every commit. That is the chaining contract (`|| exit $?`) and a hook that was rejecting commits before commitlore arrived must keep rejecting them; whether a hook that is broken rather than rejecting deserves different treatment is a separate decision, not a diagnostic one. Verified with a harness against the compiled check because vitest's native binding cannot load in the sandbox this was written in: the reporter's shape (preserved hook `exec node ...` -> 127) names the preserved hook on both rows with no `hooks install` in either fix; a preserved hook exiting 3 with unrelated stderr does the same without claiming node is missing; a passing preserved hook followed by a missing `commitlore.node` still blames commitlore and prescribes `hooks install`; a preserved hook without its execute bit is ignored as the stub's `[ -x ]` ignores it; a preserved hook with no shebang still runs. The same cases are in test/doctor.test.ts for CI. Closes #876 Record-Id: r-doctorchainedhook Provenance: authored Ruled-out: teaching the stub to print a marker line before exec-ing the preserved hook so one run could be split | the stub is byte-compared by `hooks status` and doctor, so changing it flags every existing install as outdated for a diagnostic-only gain Ruled-out: parsing the stub's stderr for the preserved hook's path | the preserved hook's own error text is the only content, and a hook that fails silently leaves nothing to parse Limit: the preserved hook runs twice per doctor run (alone, then inside the stub); commit-msg hooks are expected to be re-runnable on a message file Warn: evidence paths are normalised, so tests must pin the chained hook's name, not its absolute path Blast: module Undo: easy Certainty: firm Co-Authored-By: Claude <noreply@anthropic.com>
Version fields, install pins and the changelog entry for 1.2.4. The release carries one fix: `doctor` attributed a preserved hook's failure to commitlore's own hook and prescribed `hooks install`, a remedy that rewrites only the file that was working (#876). The preserved hook is now probed on its own first and named by path when it is the one that fails, and the row the reporter read inherits that fix along with the outcome. The install pins move; the field-report paragraph in each README keeps saying v1.2.1, because that is the version the run it describes was made on. The `v1.2.3` mentioned in the installers' own error text is an example tag, not a pin, and stays. `dist/` is deliberately not in this branch. `canonical-merge.yml` rebuilds the bundle from the merged tree and refuses a pull request that touches it, so the committed bundle matches the source it lands with. Co-Authored-By: Claude <noreply@anthropic.com>
`build:canonical` on the merged tree, so the commit that lands matches the source it lands with. The pull request carried source only, which is what a contributor on a host that cannot run a linux/amd64 Docker build can produce (#720). Limit: this proves the bundle matches this tree; whether this tree is what a reviewer wants is what the pull request is for Blast: system Undo: easy Certainty: firm Record-Id: r-canonmerge879 Provenance: authored Verified: artifact:verify passed against the regenerated manifest in the same job, before any credential was available to it CommitLore-Version: 2.0.0
commitlore-canonical-build
Bot
force-pushed
the
canonical/pr-879
branch
from
September 8, 2026 07:26
c2e5c4d to
87f6dac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The commit that will land for #879:
mainplus that source plus a canonical rebuild, built together so all eleven required contexts run on the tree that merges rather than on one that resembles it.#879 carries source only, which is what a contributor on a host that cannot run a
linux/amd64Docker build can produce (#720). Nothing was rebuilt by hand.Merge this with a merge commit, not a squash. This branch merged #879 with
--no-ff, so its head commit is an ancestor here: a merge commit lands that commit onmain, and GitHub then records #879 as merged because its head is reachable -- which is what T-1502 asks for. A squash lands new bytes instead, and #879 stays open with nothing to point at.This body deliberately carries no closing keyword. GitHub binds one only to the number straight after it, and a pull request closed by keyword is recorded closed rather than merged -- the opposite of the line above. Reachability does the closing here.
Opened by
canonical-merge.ymlfor #719.