v0.1.10 — the report carries the vendor's own answer

OpenHardwareOS v0.1.10 makes a field report carry the platform's own answer on Windows, tells the desktop why it is not writing, and fixes a verification step that had silently stopped running. Existing v0.1.0 – v0.1.9 tags and downloads remain available.

Changes

The report now carries LibreHardwareMonitor's own sensor list

ohm-cli report collects a JSON file that puts this project's readings next to the platform's raw answer, unparsed, so a reading can be checked without trusting this project's parser. On Linux that half is sysfs, and it worked. On Windows there is no sysfs, so the Windows half of every report so far was empty — which is exactly the platform half that someone who is not sitting at your machine needs.

• New platform.lhm: every sensor LibreHardwareMonitor reports, with its own id, name, sensor type, hardware path and raw value string, copied as it came.
• When LibreHardwareMonitor cannot be read, the report says why — the URL it tried and the failure, for example "no web server is running" — instead of looking like a machine with no sensors.
• Complex nodes are flattened and only sensor nodes are kept, because container nodes bury the numbers that need comparing. Capped at 400 sensors with truncated_at recorded if a machine has more.
• The report summary line prints how many sensors were collected.

The desktop explains why it stays out of the way

The background service holds hardware channels while it runs, and the desktop deliberately stands down to keep one writer per channel. Until now the screen showed a stalled engine with no reason given, which looks like a broken feature.

• The Automation screen reports the holder — including its pid — and states that it still reads and displays, but will not write while another process owns the channels, and how to stop that process.
• When this window is the owner, no notice appears.
• Covered by two front-end tests, checked by mutation: removing the notice fails them.

A verification step that had stopped running, and six records that said otherwise

The step that launches the real desktop application and proves its IPC path end to end had not actually run since v0.1.4. 29b95dd renamed the built application (through tauri.conf.json's mainBinaryName), the script kept looking for the old path, and every pass from v0.1.4 to v0.1.9 stopped there. Worse, the two checks that ran before the missing-file guard — "a probe with no isolated configuration directory is refused" — passed on exit 127, because a command that does not exist also exits non-zero.

What changed:

• The artefact's name is read from tauri.conf.json instead of assumed, and the script stops before judging anything if the build did not produce it.
• The artefact's own self-reported version must equal the version the tree declares, so a stale binary carrying the right name cannot stand in for this revision's code.
• The step's complete output is kept and its PASS/FAIL lines are printed; the truncated tail was how a red step looked green.
• scripts/versions.py retries a transient gh api failure a bounded number of times and reports gh's own error text. A single network blip used to make the version check exit 1, which reads as "the catalogue disagrees with GitHub" when nothing disagreed.

The six rounds of docs/verification-log.md that recorded that step as verified are corrected in place, with the cause written next to the correction.

What is verified, and what is not

• 559 Rust tests, 46 front-end tests, clippy --workspace --all-targets -- -D warnings, fmt --check, cargo deny check, the documented Linux install route, the readings cross-check fixtures, both cross-target compile gates, and the real desktop IPC round trip (51 checks, 0 failures) all pass at the released commit. Every number is in the verification log.
• Nothing in this release has been verified on real hardware. No fan has been measured, no pwm<N> has been written, and no SuperIO chip has been read. On Windows, LibreHardwareMonitor against a real motherboard still needs your machine — the field checklist is the procedure, and writing a fan channel on Linux still requires confirming that channel yourself before enabling pwm_write_allow.

Install

• Windows: PowerShell instructions for this version
• Linux: CLI, Debian package and AppImage instructions
• Running the rules in the background
• Validating a real machine

The Windows desktop installer and the optional PowerShell script are unsigned, and so are the Linux packages. LibreHardwareMonitor is a separate prerequisite for supported motherboard channels on Windows and is not bundled.