Platforms

Claim

The test suite runs on Linux and macOS in continuous integration, and passes there. On Windows 11 the suite passed natively on 2026-10-19 (one virtual machine, one Python version), after a port; the GitHub Windows job has not yet run on the ported code, and media and power approvals are refused on Windows by design. Windows use also appears in an operator account and field manual. Raspberry Pi has not been tested as the host that runs Bootscry.

This is about the machine that runs the agent and Bootscry code, separate from the machine the KVM controls. KVM input is independent of the target operating system in principle; this project has not tested every target OS.

What supports it

• The NAS recovery began from a Windows workstation, according to the operator's account. See nas-recovery.
• The field manual documents a Windows line-ending fault: commands built on the Windows workstation carried \r\n into the keystroke stream. The documented fix was newline cleanup and chunked console payloads.
• The unit tests run against mocks and local sockets, with no hardware. On the operator's Linux workstation on 2026-10-19 the full suite gave 1052 passed and 5 skipped.
• Continuous integration run 39087816209 (2026-10-18) passed lint, Linux with Python 3.11, 3.12, 3.13 and 3.14, and macOS. On macOS 1016 tests passed and 41 were skipped; tests that need a tool the runner lacks skip. Windows ran as an experimental job: 982 passed, 44 skipped and 31 failed.
• Those 31 failures were sorted by cause and fixed on 2026-10-19. Private state is written only under the user's profile folder, and refused anywhere else, because Windows has no POSIX file modes. Approvals for media and power need a POSIX terminal, so on Windows they are refused rather than skipped. The rest were environment and line-ending issues in the tests and tools.
• Because GitHub Actions refused every job that day for a billing reason, the port was tested on an owned, disposable Windows 11 Enterprise LTSC 24H2 virtual machine with no network access, using Python 3.13.16. The first run found two import errors and five failures, one of them a bug in the release check. After the fixes the suite gave 1016 passed and 73 skipped, with no failures. Skips are tests that need a tool the machine lacks (QEMU, e2fsprogs, tesseract and others) and the 21 approval tests that need a terminal.
• Running the suite on GitHub found real portability bugs that are now fixed: payload images could not be built with the disk tools shipped by Ubuntu 24.04, Debian 12 or Homebrew; the MCP server could not load on Windows; and video titles came out tiny on a Mac without a particular font.
• The live suites (scripts/kvm/live_test.py, live_mouse_test.py, live_typing_test.py) ran on Linux against a real Comet wired to a Linux test machine. Results are on mouse-accuracy and typing.
• Windows-specific code here: scripts/kvm/ok.cmd launches the health check, and src/bootscry/kvm_tool.py has Windows key helpers (Ctrl+Alt+Del, Task Manager, Shift+F10 for Windows Setup). The key helpers send input to a Windows target. They say nothing about the host the agent runs on.
• The code reads and writes files with pathlib and talks to the Comet over HTTP and a WebSocket. That is a design note, not a test result.

What is not done

• No live suite against a real KVM has been run from macOS or Windows. The macOS result is the unit suite in continuous integration only.
• No unit or live suite has been run on a Raspberry Pi as the host.
• The Windows evidence is the overnight run, the manual's post-mortem, the experimental CI job before the port, and the native unit-suite run after it. No KVM has been driven from Windows by the ported code.
• To claim macOS, we still need one live suite from a Mac, with the versions recorded.
• To claim Raspberry Pi, we need the same on a Pi, plus a check that local OCR (Tesseract, and RapidOCR if used) runs at a usable speed on that hardware. The OCR speeds on the other pages come from a server, not a Pi.
• Until then Raspberry Pi is labelled planned, and macOS is unit-tested only.

Limits

• One operator, one Windows workstation, one Linux server for live runs, and GitHub's hosted runners for the unit suite.
• The manual is the operator's own post-mortem, so Discovery 4 is documented, not independently confirmed.

Where the raw documentation lives

The private field manual, scripts/kvm/, and tests/ are the source records. The manual needs redaction before public release.