Windows PowerShell 5.1, still the default shell on Windows and the interpreter
every dispatcher reaches for first, reads a .ps1 as ANSI unless the file
carries a UTF-8 BOM. The UTF-8 encoding of an em dash is E2 80 94, and CP1252
maps 0x94 to a closing curly quote, so the character opens a string literal
that never closes. An arrow does the same through 0x92. The result is a parse
error before the first statement runs, and every dispatcher wraps its
PowerShell call in fallbacks that swallow it, so the script silently does
nothing.
Eight shipped scripts failed to parse: the Cursor plan injection hook, both
.kiro asset scripts, the Arabic check-complete, and check-complete plus
init-session for both Chinese variants. The last of those means a Windows user
of either Chinese variant could not create a plan at all.
Every tracked .ps1 holding a byte above 0x7F now carries a BOM. Pure ASCII
files deliberately do not, because the dual-shipped script parity tests
compare them byte for byte between locations.
The guard asserts the invariant in plain Python so it runs everywhere, and
where a real powershell.exe exists it additionally asks the interpreter to
parse all 81 tracked scripts through ParseFile, which catches any encoding
trap rather than only this one. Both halves were verified to fail against the
pre-fix files.
OthmanAdi
cebc94a94d