Plant a host in Windows CI so the wiring branch actually runs (#722) - #731
Merged
Conversation
A GitHub runner has no coding agents, so detection short-circuits and the Windows job has printed `"hosts":[]` on every run it has ever made. Every branch that wires a host is unexecuted there -- not under-tested, unreachable -- and an assertion reading that list passes whether the wiring code works, is broken, or has been deleted. That vacancy is why #714 existed as a standing record rather than a task, and why both Windows defects in #716 were found by a person on a real machine instead of by any job here. The response until now was to make the guards falsifiable somewhere the code does run: #717 pinned a temporary-filename property as a pure function, #720 added a mode-0644 shadow for executable resolution. That works and it is second best, because it proves properties of helpers rather than executing the path. A planted `cursor.cmd` removes the vacancy instead of working around it. Detection looks for the command on PATH, and nothing here executes Cursor -- Cursor plays no part in wiring, since what gets written is its config and what gets probed is CommitLore's own wrapper. So the fixture is a file, and the branch it unlocks is the real one, end to end: detection, the atomic config write, and a live MCP initialize. Two cases, and the second is what makes the first mean anything. A fixture that can only succeed proves the installer reports what the fixture told it, which is the empty runner again with more steps. So the second gives the same detected host a config it cannot parse and requires `outcome: "failed"`, `ok: false`, the file named in the reason, and the unusable config unmodified afterwards. The suggestion and its framing -- so this class cannot hide behind an empty runner again -- came from kantorcodes1 in a public discussion. It is a better answer than the one I was giving. Limit: one host of seven, on one platform. gemini-cli, windsurf and opencode take the same JSON path and are not planted; codex, hermes and claude-code take different ones and are not covered at all Limit: this executes wiring, not a real agent -- a planted shim is a file the job wrote, and it says nothing about what Cursor itself does with the registration Ruled-out: assert on the existing `"hosts":[]` output | it is the same on a working installer and a deleted one, which is the defect this replaces Ruled-out: a stub that always registers cleanly | it proves the installer reports what the stub told it, and cannot fail, so it restores the vacancy under a new name Blast: system Undo: easy Certainty: firm Verified: the workflow parses as YAML and the job gains one step; `EXPECTED_CI_WORKFLOW_SHA256` is re-locked to the edited file, which is the mechanism that would otherwise let a workflow body change unreviewed, and 29 release-prerequisite cases pass against it. The step itself cannot be run locally -- it needs windows-latest, which is the whole point -- so its first execution is this pull request's own `install-ps1` job. Record-Id: r-plantedhost722 Provenance: authored CommitLore-Version: 2.0.0
CommitLore — record lintTrailers: clean — 4 commits in Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
The step's first run did everything it claimed. On a GitHub runner, with no coding agent installed, the enumeration wired a host and live-verified it:
ok:true cursor installed healthy "registration created and live-verified"
ok:false cursor failed "D:\a\_temp\cl-host-bad\.cursor\mcp.json is not parseable JSON..."
The job still failed, and the reason is worth keeping rather than papering over. GitHub's pwsh shell exits with the last native command's status, and the second case deliberately produces a failing one -- so the step was reporting, accurately, that a host had failed.
That is a property nothing asserted. `install.ps1` returns this command's status, so a host that failed must make it non-zero or an install reports success over a repository with nothing wired -- the exact claim the installer is for. Both codes are now checked: zero when the host wired, non-zero when it did not, and an explicit `exit 0` at the end because every assertion throws before reaching it.
Limit: the second case's non-zero code is asserted, not its value -- a change from 1 to 2 passes here
Blast: module
Undo: easy
Certainty: firm
Record-Id: r-plantedexit722
Provenance: authored
Verified: the run this repairs is the evidence -- both enumerations are in its log with the outcomes the step requires, and the only thing that failed was the shell's exit status; the workflow parses, the digest is re-locked to it, and 29 release-prerequisite cases pass
CommitLore-Version: 2.0.0
This was referenced Aug 17, 2026
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
1 participant
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.
Closes #722.
A GitHub runner has no coding agents, so detection short-circuits and the Windows job has printed
"hosts":[]on every run it has ever made. Every branch that wires a host is unexecuted there — not under-tested, unreachable — and an assertion reading that list passes whether the wiring code works, is broken, or has been deleted.That vacancy is why #714 existed as a standing record, and why both Windows defects in #716 were found by a person on a real machine rather than by any job here.
What changes
A planted
cursor.cmdonPATH. Detection looks for the command; nothing executes Cursor — Cursor plays no part in wiring, since what gets written is its config and what gets probed is CommitLore's own wrapper. So the fixture is a file, and the branch it unlocks is the real one: detection → atomic config write → live MCPinitialize.Two cases, and the second is the point
outcome: installed,healthy, not innotDetected, and the registration present in.cursor/mcp.jsonafterwardsoutcome: failed,ok: false, the file named in the reason (#716), and the config byte-identical afterwardsA fixture that can only succeed proves the installer reports what the fixture told it — the empty runner again with more steps. The failing case is what makes the passing one mean anything.
Notes for review
EXPECTED_CI_WORKFLOW_SHA256is re-locked to the edited file. That digest is what stops a workflow body changing unreviewed, so it moves deliberately with the job contract; 29 release-prerequisite cases pass against it.windows-latest, which is the whole point, so its first execution is this PR's owninstall-ps1job.Scope
One host of seven, on one platform.
gemini-cli,windsurfandopencodetake the same JSON path and are not planted;codex,hermesandclaude-codetake different ones and are not covered.The suggestion and its framing — so this class can't hide behind an empty runner again — came from kantorcodes1 in a public discussion, and it is a better answer than the one I was giving.