[repeat98]

• What was wrong or hard: Fix: Windows connects to the Octatrack where it never could (new USB revision) #1476 (now in Improvement: one Octatrack base update: update and sync screens, CPU FULL guard, stall frames, engine price in the package, Windows USB, a larger RAM boot stage #1502) changed the base's bcdDevice to 0x0101 so that Windows sets the Octatrack's vendor interface up again on computers where it lacks DeviceInterfaceGUIDs, and merged before its one Windows test was run. The hardware traps said that Windows binds WinUSB by itself, but not that it keeps an interface's first setup.
• What this changes: the Windows paragraph in docs/OCTATRACK_HARDWARE_TRAPS.md now says so and names the remedy, within its old length (the guide is over its size limit and may not grow). docs/verification/2026-11-13-windows-usb-revision.md is the record of the test, with what it does not show.
• How I checked it: on the owner's Windows 11 PC and MKII, 13 November 2026, registry and device state read with PowerShell: the value deleted under the old revision came back by itself when the unit arrived with the new one; deleted again under the new revision it stayed missing after a replug and the USB bridge could no longer open the unit; restored from an export, the bridge reached the unit again. node scripts/docs.mjs and scripts/docs.test.mjs pass. npm run pr:ready stopped only at the document size, fixed in the second commit; I did not run it again after that.
• What the guides lacked or got wrong, and where I fixed it: as above, in docs/OCTATRACK_HARDWARE_TRAPS.md.

Not shown by the test: that the affected computers are wrong in this way and no other (the break was made by hand after one browser log), and why they are. The site's own message in that state was not looked at.

🤖 Generated with Claude Code