v1.1.0

Canonical source: d9a041f; Canonical dist/commitlore.mjs SHA-256: 50ad329497c15e9ff8cfd3de9a96470688b41930c21c4f0de83119dc502efcfe

One machine can now differ from the committed capture policy without modifying it.

A local policy overlay (#709)

.commitlore-policy.json is committed with the repository, which is right for a policy: commitlore auto on authorises an agent host to prepare, verify and stage records with nobody in the loop, and that applies to everyone who clones. A contributor who needed a different answer had exactly one route — edit the tracked file — and their worktree then stayed modified forever. That is enough to stop a release script which refuses to tag a dirty tree, which is the failure that was reported.

.commitlore-policy.local.json     per key, wins
.commitlore-policy.json           repository default
built-in defaults

Per key, not per file: an overlay setting only unattended leaves mode and max_records_per_commit as the repository set them, so a later change to the committed file still applies. commitlore auto on --local and auto off --local write it; once it exists it is the file commitlore auto writes, so opting in or out never touches the tracked file again. Keep it out of version control — nothing writes a .gitignore entry for you.

Two things keep the precedence answerable rather than ambiguous. The policy identity hash is computed over the effective policy whenever an overlay is present, so a record prepared under one is stamped with the policy that produced it rather than with bytes that did not — and a repository with no overlay keeps exactly the digest it had, so no capture in flight is refused by this upgrade. And a new policy-overlay doctor check names both files, the value beneath, the value in the overlay, and the one in force.

Reasoning and what it is conditioned on: ADR-0035.

Windows: host wiring still does not work

Read this before upgrading on Windows.

An owner ran 1.0.2 on a real Windows machine with coding agents installed. Every detected host failed and nothing was written to any config. This release fixes one of the two causes, not both.

Still broken (#716):

• hasCommand joins each PATH entry with the bare command name and never consults PATHEXT, so it cannot see cursor.cmd, codex.cmd or claude.cmd. A host whose executable is not found is reported notDetected even with its config file present.
• spawnSync runs with shell: false, which cannot execute a .cmd shim. This is what produced codex mcp add failed and Hermes setup failed.

Fixing that needs a design which preserves the reason shell: false was chosen — the wrapper path and user config paths reach those calls — and it cannot be verified anywhere except a Windows machine with agents installed. CI has no coding agents, so its install-ps1 job detects zero hosts and never reaches the code (#714).

What this release does fix on Windows: both atomic writers built the temporary file name out of the whole target path, because path.split('/').pop() returns its argument unchanged when there is no / in it. C:\Users\u\.gemini\settings.json became …\.gemini\.C:\Users\u\.gemini\settings.json.commitlore-….tmp, which cannot exist — so every host that reached its write failed with ENOENT. That is repaired, and pinned by a test a POSIX runner can fail on, which is the only kind of guard this repository can hold against a Windows-only defect.

The installer was honest throughout: ok:false, per-host outcome:"failed", and no config silently changed. It reported failure correctly; it could not do the work.

Every host failure now names the file it was about (#716)

The 1.0.2 run reported cursor as config is not parseable JSON: Unexpected end of JSON input while an independent check of that machine found valid, byte-identical JSON. Both can be true — this command reads %USERPROFILE%\.cursor\mcp.json and only that, while Cursor keeps configuration in more than one place — and nothing in the output could separate them. The path had never been recorded anywhere, so no transcript could have contained it either.

All seven read and write failure paths now lead with the path: <path> is not parseable JSON: …, <path> could not be written atomically: …. The summary schema is unchanged.

doctor no longer claims a record was lost when none was staged (#710)

A repository whose captures never reached staging was told a decision had been "never written to the history". Nothing was dropped there: the commit each draft was prepared for either never happened, or happened without it.

The installers carry only the code that runs (#691)

install.sh and install.ps1 have delegated every detection, config write and MCP probe to one shared TypeScript command since 0.9.0. Both files still carried the superseded shell and PowerShell implementations below an unconditional exit — 845 lines no install has executed, and which three readers in three days took for live code. They are gone; four guards that were asserting against those copies now target the enumeration that runs.

---

Full notes: CHANGELOG.md.