Supported targets and verified environments are different things. Hotshot targets Windows 10 build 19041+ and Windows 11 on x64/ARM64. Release builds are cross-built and packaged for both architectures; that does not establish usability on every physical device.
What is verified#
| Area | Evidence | What it does not prove |
|---|---|---|
| x64/ARM64 builds and runtime | Hosted Windows CI builds; Full/Core MCP protocol and optional-component stdio startup run natively on x64 and windows-11-arm for 0.1.14. |
Physical ARM64 UI/capture/audio behavior. |
| Native screenshots and video | Fixture-owned windows through real Windows.Graphics.Capture, GDI/clipboard harnesses, MP4/GIF checks, and target-state tests. | Fidelity of every GPU driver or HDR display. |
| Native UI | Native WinUI acceptance run executed natively on x64 and Windows 11 ARM64: 8/8 GUI checks plus 7/7 accessibility stages on each architecture. Process/OS architecture and interactive-desktop prerequisites are recorded; generated fixtures use a software renderer. | Physical user's full ARM64 device/audio/GPU acceptance, Narrator user experience, or every display layout. |
| Native accessibility automation | Real control peers, accessible names/relationships, focus traversal/recovery, keyboard-command handlers, error/status live regions, compact layouts and local font-growth checks. | Human Narrator speech, physical keyboard event delivery, or actual system contrast/text-scale transitions. |
| Display geometry and color references | Synthetic different-scale/negative-origin/disconnected-monitor placement regressions; shared float16 scRGB readback reference patches and validated display-query ABI. | Physical mixed-display movement or HDR perceptual fidelity merely because unit tests pass. |
| Settings roaming | Independent isolated-machine stores, offline merges/conflicts, native reload safety, and real local OneDrive file persistence. | Completed OneDrive cloud transfer or a second physical PC unless explicitly tested there. |
| Website/docs | Desktop/mobile browser, keyboard, contrast, reduced-motion, text-size, and search checks. | Native app accessibility; those need their own evidence. |
The available interactive x64 environment reports Windows build 26300 and a single 1080 x 2268 monitor at 200% scale. A read-only DISPLAYCONFIG_GET_ADVANCED_COLOR_INFO_2 query establishes that the display supports HDR but currently has HDR disabled (SDR, 8 bits per channel). That is useful high-DPI/readiness evidence, not mixed-monitor or enabled-HDR fidelity acceptance. HDR and system accessibility settings are never changed by the test runner. Product media is generated by the isolated native harness from demo content only.
Run the available-device checks#
Build Hotshot.Recording.Harness and Hotshot.Product.Harness with the architecture for the test machine, then pass the actual executables:
pwsh tests\Hotshot.Device.Validation.ps1 -RecordingHarness <absolute-recording-harness.exe> -ProductHarness <absolute-product-harness.exe> -OutputDirectory <absolute-task-owned-folder> -Soak
The runner writes a JSON report and logs with explicit passed checks, platform architecture/build, and unverified areas. Product evidence also records anonymous monitor dimensions/scales. Review all logs before sharing; do not attach user settings, capture libraries, window lists, device names, serials, or account information.
For clipboard-free native UI/accessibility and display-readiness checks, use:
pwsh tests\Hotshot.Device.Validation.ps1 -RecordingHarness <absolute-recording-harness.exe> -ProductHarness <absolute-product-harness.exe> -OutputDirectory <absolute-task-owned-folder> -UiOnly
The GUI acceptance harness is architecture-neutral and the native UI workflow runs it on x64 and windows-11-arm. Its evidence records the actual process and OS architecture, interactive-desktop availability, renderer and checks completed. A cross-build is not execution, a software renderer is not hardware GPU fidelity, and a hosted ARM64 VM is not a physical user's complete device acceptance. Failed, unsupported or timed-out checks remain failures with retained logs.
The display report records physical bounds/DPI, native color-query status, HDR support/enabled state and active SDR/WCG/HDR mode. Unsupported queries remain unknown, not a guessed successful HDR result. --hdr-reference exercises the same float16 row converter used by screenshot readback, but does not enable HDR or verify a monitor.
Use -RequireMixedDpi to demand two actual different-scale displays. It fails explicitly when those resources are absent; when present, the recording harness moves only its synthetic target across the displays and checks native DPI, physical capture dimensions and known pixels. Pure geometry tests also protect logical window-size restoration, nearest remaining display selection and off-screen/oversized placements, but remain labeled synthetic.
The runner captures/records generated fixture-owned windows. It does not run monitor/microphone capture, enable cloud AI/agent permissions, or replace the installed app's profile. The recording harness can change the clipboard to a generated test image; preserve any clipboard content you need before running it.
Hardware checks still requiring their environment#
| Test | Required setup | Pass criteria |
|---|---|---|
| Physical ARM64 | ARM64 Windows device running the ARM64 release. | Install, tray/hotkeys, region/window capture, editor/export, recording/GIF, companion, updates, and local permission preservation. |
| Mixed-scale monitors | At least two connected displays with different scales. | Move settings/editor and targets between displays; capture physical bounds correctly, maintain input/annotation coordinates, and reject changed targets. |
| HDR fidelity | HDR-capable display with HDR enabled and a controlled scRGB reference. | Record the display mode, compare known SDR/HDR reference output, and confirm explicit SDR tone mapping without claiming HDR-preserving PNG. |
| Narrator usability | Human-operated Narrator session on a supported Windows machine. | Complete setup, capture selection, filename navigation, editor actions, errors, and recording controls using keyboard/speech without ambiguous names or trapped focus. |
Human accessibility acceptance#
Automated native peer/focus tests are prerequisites, not a substitute for this sign-off. Use generated captures in a tester-controlled profile. Do not turn on Narrator or change system settings on somebody else's desktop without approval.
| Step | Human pass criteria |
|---|---|
| Settings and setup | Navigate with Tab/Shift+Tab; hear meaningful control names, step headings, validation and saved-state announcements; search results move focus to the target control. |
| Editor and history | Browse filename-based captures and toolbar/overflow without a mouse; hear selected annotations/layers and helpful canvas instructions. |
| Canvas keyboard operations | Focus the canvas: Insert creates a shape; Page Up/Down selects; arrows move, Ctrl+arrows resize, Shift uses larger steps; Alt+arrows pan; +/- zoom; Ctrl+0 fits, Ctrl+1 uses actual pixels; Escape cancels/deselects. Confirm Undo/Redo. |
| Editable fields and focus | Text/number/choice controls keep their normal keys. Hiding annotation fields, completing/canceling work and refreshing history leave visible, sensible focus without trapping or stealing it. |
| Recording and errors | Announce pause/resume/state changes and actionable errors without reading every elapsed-time tick. |
| Contrast and enlarged text | After approval, change system contrast/text scale while windows stay open; verify readable text/cards/focus indicators and restore the original settings afterward. |
Record the tested app version, Windows build, architecture, themes/text scale, date, PASS/FAIL per step and any issues. A human receipt is not produced automatically. Direct HighContrastChanged event registration can be unavailable on an unpackaged desktop; the app retains color/theme fallbacks and test evidence records that capability limitation explicitly.
Do not convert “not run,” “unsupported,” “needs a device,” or a failed probe into “passed.” A release report should retain each test's date, version/edition, architecture, environment, and outcome. No physical ARM64, mixed-monitor, HDR-fidelity, or Narrator completion is claimed here merely because synthetic checks passed.