What happened
While fixing #706 in PR #708, I (an agent on a Linux host) wrote and repeatedly
'verified' a PowerShell scratch-commit probe by reasoning about PowerShell
semantics and by structural analogy to an already-tested POSIX version, never
by executing it: no pwsh is installed on this host, and installing one would
still not reproduce native-Windows quirks (path spaces, $env:TEMP, native
command exit-code propagation) that a Linux port of PowerShell doesn't carry
the same way. Round 4 of the review loop on that PR found exactly one of those
quirks (unquoted $d, breaks on a Windows profile path with a space) that my
own reasoning had missed and that a Linux-side "looks right" pass could not
have caught.
The maintainer caught this mid-loop and pointed at it directly ("if you want
to defer closing out 708 to a windows box just say the word, don't guess if it
works or not"), then had a Claude session on an actual Windows host start
validating the PowerShell copies directly, which found real bugs the
Linux-side reasoning-by-analogy approach did not.
The rule to add
An agent must not claim platform-specific code (PowerShell on Windows, a
macOS-only mktemp/ssh-agent behavior, a WSL-specific path quirk, etc.)
works, is verified, or is fixed unless it actually executed that
code on that platform, or an agent that is running on that platform did.
Reasoning by analogy to an already-tested equivalent on a different platform
("the POSIX version works, so the PowerShell version should too") is not
verification, and should be stated as exactly that: an unverified structural
match, not a tested fact. When no agent has access to the target platform,
say so explicitly and either defer the platform-specific portion to a human
or an agent that does have that access, or ship it clearly labeled unverified
rather than asserting confidence the agent does not have.
Where this likely belongs
git-commit-conventions or pr-review-conduct (the multi-platform
signing-probe work sits in both), or a new short section in GOVERNANCE.md
if the rule is judged general enough to apply beyond git/signing work (a
Windows-only install script, a devcontainer path issue, etc. would hit the
same failure mode). Whichever skill states it should also cover the
practical corollary: reasoning-by-analogy across platforms is a reasonable
first pass and often correct, but it is not a substitute for execution, and
the two should never be reported to the user in the same words.
What happened
While fixing #706 in PR #708, I (an agent on a Linux host) wrote and repeatedly
'verified' a PowerShell scratch-commit probe by reasoning about PowerShell
semantics and by structural analogy to an already-tested POSIX version, never
by executing it: no
pwshis installed on this host, and installing one wouldstill not reproduce native-Windows quirks (path spaces,
$env:TEMP, nativecommand exit-code propagation) that a Linux port of PowerShell doesn't carry
the same way. Round 4 of the review loop on that PR found exactly one of those
quirks (unquoted
$d, breaks on a Windows profile path with a space) that myown reasoning had missed and that a Linux-side "looks right" pass could not
have caught.
The maintainer caught this mid-loop and pointed at it directly ("if you want
to defer closing out 708 to a windows box just say the word, don't guess if it
works or not"), then had a Claude session on an actual Windows host start
validating the PowerShell copies directly, which found real bugs the
Linux-side reasoning-by-analogy approach did not.
The rule to add
An agent must not claim platform-specific code (PowerShell on Windows, a
macOS-only
mktemp/ssh-agentbehavior, a WSL-specific path quirk, etc.)works, is verified, or is fixed unless it actually executed that
code on that platform, or an agent that is running on that platform did.
Reasoning by analogy to an already-tested equivalent on a different platform
("the POSIX version works, so the PowerShell version should too") is not
verification, and should be stated as exactly that: an unverified structural
match, not a tested fact. When no agent has access to the target platform,
say so explicitly and either defer the platform-specific portion to a human
or an agent that does have that access, or ship it clearly labeled unverified
rather than asserting confidence the agent does not have.
Where this likely belongs
git-commit-conventionsorpr-review-conduct(the multi-platformsigning-probe work sits in both), or a new short section in
GOVERNANCE.mdif the rule is judged general enough to apply beyond git/signing work (a
Windows-only install script, a devcontainer path issue, etc. would hit the
same failure mode). Whichever skill states it should also cover the
practical corollary: reasoning-by-analogy across platforms is a reasonable
first pass and often correct, but it is not a substitute for execution, and
the two should never be reported to the user in the same words.