build ritual: antivirus smoke test before shipping a zip (#190). Windows Defender's ML classifier flagged btl4.exe as Trojan:Win32/Bearfoos.A!ml and DELETED it -- a false positive, and crucially PER-BINARY rather than per-project: of 17 archived builds extracted side by side only 4.11.957 was condemned (622 through 913 all survived), plus that evening's fresh build. Our exe fits the profile that trips these classifiers (unsigned, rebuilt every session so it never accrues reputation, raw sockets, process enumeration, writes beside itself), so each build is a coin flip; and it turns WITHOUT a code change -- the same binary ran clean across benches all evening, then the 8/14 19:34 signature update (1.457.172.0) condemned it hours later, which is why the field was quiet: nobody had launched since. Ritual added: extract the new exe OUTSIDE any Defender exclusion, wait ~60s (deletion is asynchronous -- an immediate Test-Path passes and the file vanishes a minute later), confirm it survives, and if not, submit to Microsoft as a false positive before shipping. Notes that a rename cannot help (content is what is scored; the exe name is constant, only the zip is versioned) and that an exclusion on the repo makes the test silently pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

context/build-and-run.md

@@ -199,6 +199,23 @@ default (`-DBT_STEAM=ON` is the documented dev-checkout state). `BT_EXPIRE=ON` (
 14-day tester window; an expire-OFF zip is renamed `-noexpire` and warns. Verify by extracting the
 zip somewhere clean and booting it with no repo present — that is what catches a missing runtime DLL.
 
+⚠ **ANTIVIRUS SMOKE TEST — do this before handing a zip to anyone (#190, 2026-08-15).** Windows
+Defender's ML classifier flagged `btl4.exe` as `Trojan:Win32/Bearfoos.A!ml` and DELETED it. This is
+a false positive, and it is **per-binary, not per-project**: of 17 archived builds extracted side by
+side, only **4.11.957** was condemned — 622 through 913 all survived — plus that evening's fresh
+build. Our exe fits the profile that trips these classifiers (unsigned, rebuilt every session so it
+never accrues reputation, opens raw sockets, enumerates processes, writes beside itself), so any
+given build is a coin flip. It also turns without warning: the same binary ran clean across benches
+all evening, then a signature update (8/14 19:34, 1.457.172.0) condemned it hours later.
+**The check:** extract the new exe to a normal folder that is NOT inside a Defender exclusion (a
+Desktop subfolder is realistic), wait ~60 s, and confirm the file still exists. Deletion is
+asynchronous — an immediate `Test-Path` can pass and the file vanish a minute later. If it is
+condemned, do not ship it: submit to https://www.microsoft.com/en-us/wdsi/filesubmission (category
+"software developer / incorrectly detected", 1-3 day turnaround, clears it for EVERY player) and
+rebuild. A rename does not help — the classifier scores content, and the exe name is constant
+anyway (only the zip is versioned). Long-term fix is code signing.
+⚠ A Defender exclusion on the repo makes this test silently pass — test outside it.
+
 ## Build ritual — the stale-link flake (bit 4+ times; MANDATORY for bench work)
 MSBuild often does NOT relink `btl4.exe` when only static-lib members changed — the bench then
 runs a STALE exe and the session burns hours on phantom results. Ritual for every code-change build: