Release 1.1.1

[MongLong0214]

Cuts 1.1.1.

What it says about Windows, and what it does not

1.1.0 stated plainly that host wiring did not work on Windows. This is the release that gets to say otherwise — for exactly what was observed on a real machine, and no more:

• Codex and Gemini CLI wire, verify through a live MCP Initialize, and appear in their configs on disk.
• ok is still false on that machine, and the hosts that failed are still reported failed.
• Hermes fails for a cause that is not this one and is not yet named (Windows: every detected host fails to wire — the temp filename carries the whole path, and hasCommand cannot see a .cmd #716).
• .cursor/mcp.json was zero bytes on the tester's machine — a user file. The installer read the file it says it reads and reported the true reason.

The note leads with what is still broken, as 1.1.0's did.

The fix

hasCommand joined each PATH entry with the bare command name and never consulted PATHEXT, so a .cmd shim was invisible; spawnSync ran with shell: false, which cannot execute one. Resolution now finds a single concrete executable and both detection and execution use it — the original defect was those two disagreeing about what "present" means.

Two more came out of the review rather than the machine:

• A trailing backslash reached the cmd.exe argument vector unescaped, where the closing quote consumes it and the following argument is absorbed. A --verify swallowed that way would let a step report verified for a verification that never ran — the exact failure this project exists to remove, arriving through its fix.
• X_OK on resolution. Without it a non-executable file of the same name earlier on PATH is selected and spawned, breaking macOS and Linux, where this already works. Guarded by a POSIX-only test that puts a mode-0644 shadow ahead of a mode-0755 CLI — the fixtures were all executable before, so nothing could have failed on it.

Version surfaces: twenty-one, known in advance

1.1.0 found three of them with CI instead of the checklist. This time all twenty-one were asserted before pushing:

4   manifests   package.json, two plugin.json, package-lock.json (two fields)
20  README      5 install pins × 4 READMEs
6   installers  3 header examples × install.sh, install.ps1

package-lock.json is edited structurally, not textually: a "version": "1.1.0" replacement also matches dependencies genuinely at that version, and no test in the suite reads them, so that corruption would be silent.

dist/commitlore.mjs is unchanged — the bundle comes from src/, which this release does not touch. installer/canonical-artifact.json does move, because package.json is one of its four source inputs.

Verification

104 cases across manifest, readme, check-release-version and release-publish-prerequisites. build:canonical then artifact:verify → 14ff61683da747382e03b026db252dd06d4f20820c3ab6f6a75282837458429d.

Note on the merge that preceded this

#720 was squash-merged from a fork, and its four records were discarded — preserve cannot push notes with a fork PR's read-only token, and it is not a required check. Recovered with commitlore squash-preserve and republished; the structural gap is #723.

[github-actions]

CommitLore — record lint

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

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