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.

OpenHardwareOS v0.1.9 — Linux 风扇通道：按通道开启

OpenHardwareOS v0.1.9 adds Linux fan control, one channel at a time and only where you have confirmed it. The Linux preview has been read-only since it shipped, and the reason was written down rather than hidden; this release makes that reason the switch. Existing v0.1.0 – v0.1.8 tags and downloads remain available.

Changes

Reading is unconditional; writing is per channel and opt-in

pwm<N> and fan<N>_input share a chip and a channel number, which is not a promise that pwm1 drives the header fan1_input measures. That pairing is a property of the board and no kernel interface states it, so this project treats it as information only a person can supply:

{
  "adapter_settings": {
    "system": { "pwm_write_allow": ["fan.system.nct6798d_fan1"] }
  }
}

• Empty by default, and empty means read-only.
• Only a listed channel gains a writable fan.speed_percent; the others stay read-only, and a write that reaches the path anyway is refused naming the setting that would have allowed it.
• A blank or non-string entry matches no device: a mistake fails towards allowing nothing.

Taking control is explicit, reversible, and refuses to guess

• The first write switches pwm<N>_enable to manual (so a driver curve cannot overwrite it) and remembers what it was. On exit the original value goes back — which is why the adapter now declares that it hands control back to the firmware. It also declares that writing needs root, because pwm<N> does.
• If the channel's ownership cannot be read — an unreadable file, or a value that is not a number — nothing is written and nothing is restored: writing a guess back would decide who owns a fan.
• A write that fails puts the channel back before reporting the failure, and a shutdown that cannot restore one channel still attempts the rest, reporting every failure rather than the first.

What is verified, and what is not

13 new tests cover the path against a prepared sysfs tree: capability exposure with and without consent, percentage-to-255 conversion including out-of-range and non-finite values, taking control and giving it back, an unauthorised channel refused with its file untouched, a read-only capability still refused, and a shutdown with nothing to hand back.

Nothing here has run on real hardware. Linux install explains why the confirmation must be human; the field checklist §3 is the procedure — write one channel directly as root to see whether the tachometer follows, record pwm<N>_enable, hand the channel over, and a three-step rollback. Until that is done on your machine, leave the list empty: the default is always available.

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.

OpenHardwareOS v0.1.8 — 实机核对：让证据能带回来

OpenHardwareOS v0.1.8 makes the real-machine work produce evidence that can travel: one command collects everything about a machine into a single file, and a checklist says exactly what to do, what to record, and how to undo it. Existing v0.1.0 – v0.1.7 tags and downloads remain available.

Changes

ohm-cli report — both halves in one file

Validating a chassis fan happens on a machine that is not the one writing the code, and "it read 1200 rpm" is worth exactly as much as the evidence attached to it. The report carries:

• what this project reports: providers with their status and reason, every device with its readings, the reason for each missing reading, the capability notes, and the installed rules;
• what the platform itself says, unparsed: for every hwmon chip the raw contents of its fan*_input, pwm*, pwm*_enable and temp*_input files, plus /proc/meminfo and df -k.

The two halves sit side by side so somebody who is not at that machine can compare a reading with the file it came from, without trusting this project's parser. Every unreadable section explains itself — a report from a machine with no hwmon is still a useful report. It is written to the config directory's reports/ unless you name a path.

docs/field-checklist.md — the procedure that goes with it

Read-only confirmation first, then restricted control of one channel with its rollback written next to it, then normal exit and a forced kill (which does not hand control back — recorded as a fact, not fixed), then the service running while the window closes. It opens with the safety rules (never the CPU fan, one channel at a time, know the way back) and closes with the list of claims that still have no evidence at all. On Windows the platform half of the report is empty by nature; the checklist says to compare against LibreHardwareMonitor's own window instead.

Install

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

Nothing in this release has been validated on real hardware: the readings, the channels and the machines in its tests are prepared trees and simulated providers, and the checklist is what would change that. 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.

OpenHardwareOS v0.1.7 — 服务能说明它在做什么

OpenHardwareOS v0.1.7 is about the background service from v0.1.6 being able to say what it is doing — and about the two outage paths the goal asks to be verified. Existing v0.1.0 – v0.1.6 tags and downloads remain available.

Changes

The service now reports each rule, not a count

• ohm-cli service status prints every rule's status, its confirmed value, and its own sentence about what it is doing:

  rules:
    chassis       fallback  at 70  fan.system.fakechip_fan1/fan.rpm is missing: falling back to 70 %
    gpu-cooling   held      at 64  no change worth writing (0.00 % within the 0.00 % deadband)
  

• "3 rules loaded" could not distinguish cooling along the curve from sitting on the fail-safe because a sensor went away. The state file carries the difference.

The service writes a log file

A process nobody is watching must leave a record: service run now logs into the config directory's logs/, and its banner prints the exact paths of the state file and the log directory.

Sensor loss and recovery, and suspend and resume, are tested at the service level

• A prepared hwmon tree is read through OHM_HWMON_ROOT (read-only: this build writes no pwm<N>, so it changes what is read and never what is written). The test's rule reads a tachometer from that tree and drives the simulated fan.
• Delete the tachometer: the state file reports fallback, the fail-safe 70 %, and names the sensor that went away. Put it back: the rule reads again — status leaves fallback and the message returns to that reading.
• Suspend and resume: after SIGSTOP beyond the heartbeat window, service status reports "not running" and names whose stale file it is — the state in which another process may take the channels over, which is what a sleeping machine looks like. After SIGCONT the same process is still the owner, with heartbeat and cycle counter moving again.

One behaviour that looked like a bug, now stated

After a reading returns, the rule keeps the fail-safe 70 % rather than stepping to the curve's 65 %. That is hysteresis working: hold until the reading passes the anchor, because less cooling is the dangerous direction. The rule's own message says so ("holding 70 % until … drops below …"), and the page repeats it — it cost an hour to read as "the sensor came back and the rule never recovered".

Install

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

Nothing here has run on real hardware: the sensor, the channel and the machine are all prepared trees and simulated providers, and the page says so. 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.

OpenHardwareOS v0.1.6 — 后台规则服务

OpenHardwareOS v0.1.6 adds a background rules service: closing the desktop window no longer stops the rules. It exists because of the problem underneath it — two processes driving one fan. Existing v0.1.0 – v0.1.5 tags and downloads remain available.

Changes

The rules keep running with no window open

• ohm-cli service run starts the runtime and the rule loop in a process that never opens a window. It runs until Ctrl-C or SIGTERM.
• ohm-cli service status reports from the state file: pid, start time, heartbeat age, cycles, rules, whether the sources are simulated, whether writes are dry-run. It exits 1 when nothing is running and 0 when something is, so a script can ask.
• docs/background-service.md documents the semantics, a systemd user unit template, the permission reality (reading needs no privileges; writing pwm<N> is not implemented in this build at all), and what is not verified.

One writer per channel

• The service claims the hardware channels before touching them, by creating a state file atomically: two processes starting together — or two that both decide an abandoned file is reclaimable — cannot both win.
• Liveness is a heartbeat, not a guess: the owner rewrites the file every second, so a file whose heartbeat stopped belongs to a process that died, including one killed with SIGKILL. A file that cannot be parsed counts as unowned, because refusing to start over a hand-broken file would leave a machine unable to run its rules until somebody deleted it by hand.
• The desktop stands down. When another process owns the channels, the desktop does not start its own rule loop; it keeps reading and drawing, and records why in the log and the event feed instead of silently doing nothing.

Stopping hands control back

• SIGTERM (what a service manager sends) and Ctrl-C stop the rule loop, shut the runtime down — which releases control and reports what that achieved, confirmed and unconfirmed and refused and failed separately — and remove the state file.
• The signal handler is installed before the state file is claimed, so a service that looks alive can always be stopped cleanly.
• The page says plainly why kill -9 is the wrong way to stop it: nothing hands control back, so the fans stay at the last value written.

Install

• Windows: PowerShell instructions for this version
• Linux: CLI, Debian package and AppImage instructions
• Running the rules in the background — new in this version

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.

OpenHardwareOS v0.1.5 — 读数可核对

OpenHardwareOS v0.1.5 makes the Linux preview's readings checkable against the machine itself, and fixes a desktop control that could lose what you typed. Existing v0.1.0 – v0.1.4 tags and downloads remain available.

Changes

Readings you can check, not take on trust

• ohm-cli status --json and ohm-cli doctor --json print one JSON object and nothing else: every provider with its status and reason, every device with its readings, and the reason for each reading that is missing. It is the same snapshot the desktop renders from, so the two cannot disagree about what the runtime reported.
• scripts/verify-linux-readings.sh compares each reading with the platform's own answer on the same host and prints one line per reading: AGREE, DIFFER (exit code 1), NO-SOURCE (with the reason), NOT-CHECKED (no independent source exists). Memory against /proc/meminfo, fan tachometers and PWM against the very hwmon file the reading came from, temperatures against the range the platform reports, free space against df for the same mount point.
• The install page gained a section you can run yourself: which system file or command corresponds to each reading, and what a mismatch would mean. It says plainly that "this machine has no fan speed to read" is a normal outcome — and that cpu.load and cpu.frequency cannot be checked from a single sample, rather than pretending otherwise.
• The check runs in CI and in the release pipeline on a real kernel. On ubuntu-latest in this release: memory.total equals /proc/meminfo exactly, three mount points agree with df to 0/0/16384 bytes, the temperature reading sits inside the platform's own range, and the hwmon line reports NO-SOURCE because that runner has no fan driver.

The duty field no longer loses an uncommitted value

A refresh can unmount and re-mount a control — the device dropping out of one snapshot and coming back in the next, which a discovery cycle, a disable or a blip can do. The value being typed lived inside that control, so the edit died with it and the field came back showing the device's own duty; clicking Apply then wrote the device's old value. It happened in two consecutive release builds before the assertion was made to say what the field actually contained. The draft now lives on the screen and the field is derived from it (your edit ?? the reading), so re-creating the control changes nothing.

Install

• Windows: PowerShell instructions for this version
• Linux: CLI, Debian package and AppImage instructions

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.

OpenHardwareOS v0.1.4 — Linux 桌面预览包

OpenHardwareOS v0.1.4 adds the Linux desktop application — a Debian package and an AppImage — to the v0.1.3 Linux preview, which until now shipped only the command-line tool. Existing v0.1.0 – v0.1.3 tags and downloads remain available.

Changes

Linux desktop package

• OpenHardwareOS-v0.1.4-linux-x86_64.deb installs the application (sudo apt-get install ./<file>), and OpenHardwareOS-v0.1.4-linux-x86_64.AppImage runs it without installing anything. Both are built in CI on Ubuntu 24.04 and published under this project's own names, not the bundler's.
• The package declares its dependencies (libwebkit2gtk-4.1-0, libgtk-3-0, libayatana-appindicator3-1), installs /usr/bin/openhardwareos, a desktop entry and icons, and is named open-hardware-os for dpkg/apt (dpkg requires lower case).
• Verified by installing it, not by building it. The release run takes the packaged .deb, installs it with apt-get on the runner — the route the install page documents, so dependencies resolve the way they do on a real machine — and runs the installed binary with --selftest --mock (and once in --dry-run). It then runs the packaged AppImage the same way. The run prints the distribution and kernel it used: Ubuntu 24.04.5 LTS, kernel 6.17.0-1022-azure.
• docs/linux-install.md documents all three Linux routes (CLI, .deb, AppImage) and states plainly what the release run does not verify: the window, the tray and the application menu entry (the headless self-test returns before the GUI is built), real motherboard sensors, RPM-based distributions, and any fan control — reading is still all this build does on Linux.

Release pipeline

• The packager now reads the .deb before publishing it: package name, version, architecture and dependencies, a 64-bit x86_64 ELF under usr/bin/, a desktop entry whose Exec launches that binary, and icons. The AppImage must be an executable x86_64 ELF, or it cannot be run after download. Failures name what was wrong; the facts are printed before the judgement.
• One checksum list covers every Linux asset of the version (SHA256SUMS-linux-x86_64), and the documented commands verify the file being installed rather than the whole list — so a user who downloads only the .deb is not told the three files they skipped are missing.
• A refused packaging run no longer leaves a half-written delivery behind. It used to, and because the packager refuses to write into an existing output directory, the corrected rerun then refused to start: one fixable mistake became a permanent one. The failure path cleans up after itself, and a fixture proves a corrected retry delivers.
• The release workflow is named Release assets (Windows and Linux): it has built both platforms since v0.1.3.

Install

• Windows: PowerShell instructions for this version
• Linux: CLI, Debian package and AppImage instructions

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.

OpenHardwareOS v0.1.3 — Windows 与 Linux 预览版

OpenHardwareOS v0.1.3 is the first release with a Linux artefact alongside Windows: a prebuilt x86_64 CLI that needs neither Rust nor Node.js. Existing v0.1.0, v0.1.1 and v0.1.2 tags and downloads remain available.

Changes

Control foundations — three defects found by source review, fixed and pinned by tests

• A provider is chosen by what is actually there. NVML used to be dropped whenever the settings merely enabled LibreHardwareMonitor, so a machine without LHM running (Linux, or Windows with LHM closed) had no GPU provider at all and nothing said why. An adapter now declares which provider it stands by for (AdapterInfo::yields_to) and the runtime decides from the probe, on every discovery cycle.
• Channel identity no longer rests on coincidence. The LibreHardwareMonitor mapping keyed both sides of a fan channel into one map, so two sensors with the same number silently replaced one another, and a tachometer named Fan #1 could be paired with a control numbered by its position — an enumeration artefact, not an identity, on the channel rules write to. Nothing is merged now, anchors are explicit, and a channel whose control cannot be shown to belong to the tachometer beside it is read-only, with the reason recorded on the device and the adapter.
• The exit path reports what it achieved, not what it attempted. release_control() returned a count of writes it had tried, and shutdown recorded that as "handed back to firmware" — an accepted-but-unreadable write was therefore reported as a release. The result now separates confirmed / unconfirmed / refused / failed / simulated, audits each one, and separates "the adapter handed control back" from "it never does": AdapterCapabilities::hands_back_control_on_shutdown exists because the trait's shutdown defaults to Ok(()). NVML does not implement a hand-back, so its channels are reported as not handed back instead of being claimed as released.
• Every writable duty channel is released on exit. The target list was Fan | Pump, so a GPU fan under the runtime's control kept its last duty while the audit said everything had been handed back. It now covers every device with a writable duty control.

Linux monitoring preview

• Chassis fan tachometers are read from the kernel's hwmon subsystem (fan<N>_input), with the current duty (pwm<N>) and who owns the channel (pwm<N>_enable) reported beside them. Read-only, deliberately: writing pwm<N> needs root, and which pwm maps to which physical header depends on the board and driver — a wrong value there is the classic "fans stop" failure. Control over a confirmed channel is separate work.
• Channel identity is the chip name and channel number (fan.system.nct6798d_fan1), so a kernel that renumbers hwmon* cannot move a saved rule's target. A missing file, non-numeric content, a chip without name, a vanished channel and an unrecognised control mode each carry a reason rather than a zero.
• Memory usage and total join as memory.system.0 (bytes).
• docs/linux-install.md documents download, checksum verification, extraction and running the CLI, and names what each reading's source is.

Release pipeline

• New scripts/release/package-linux.sh and a linux job in the release workflow: build, workspace tests, Clippy, frontend tests, two fixture suites, packaging, then the packaged CLI is executed and its version checked. The packager refuses anything that is not a 64-bit x86_64 ELF, refuses to overwrite an existing delivery, writes its checksum list with LF, and verifies before delivering.

• The Linux checksum list is published as SHA256SUMS-linux-x86_64: a Release holds one asset per name and SHA256SUMS is the Windows list. It names only files that are published beside it (the archive and release-linux-x86_64.json), so sha256sum -c SHA256SUMS-linux-x86_64 in the download directory is a complete check of the download — no line picking. LICENSE and the dependency notices travel inside the archive.

• A dependency advisory (RUSTSEC-2026-0285, rustls via ureq) is fixed by the patch release 0.23.45, because CI's dependency audit would otherwise have been red on the released tree.
  Two defects the release build found, by being slower than a developer machine

• The duty field no longer loses what you typed. It followed the device's reported value on every change, and the first reading always arrives a moment after the window opens: typing 80 % and having a reading land put the device's own 45 % back in the box, and Apply then wrote 45 % — the value the device was already at — with nothing on screen to say the request had been discarded. The field follows the device only until you touch it, says "your change is not applied yet" while an edit is outstanding, and follows the device again after a confirmed write. An unconfirmed write keeps your request visible next to a value that is still unknown.

• A slow disk is no longer reported as a missing sensor. The automation engine asked "are my readings too old?" after doing the tick's own file writes, inside a window of three poll intervals (300 ms). On a machine whose filesystem is slower than that — a CI runner scanning every new file — rules silently dropped to the fail-safe duty and the reason said a sensor was missing while it was reporting perfectly well. The question is now asked before the tick does any work of its own, so the window detects the runtime falling behind, which is what it is for; and when readings really have stopped arriving the message says exactly that ("the runtime has not refreshed … recently, so its readings are too old to act on") instead of blaming a sensor.

Install

• Windows: PowerShell instructions for this version
• Linux: shell instructions for this version

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

Scope of validation

Software and installation validation do not establish compatibility with a physical fan or water pump. No fan or pump has ever responded to a write from this code, and the version catalogue records hardware_validation: not_verified for every release. On Linux, whether fan tachometers exist at all depends on the board's driver (nct6798d, it87, …); the adapter reads what the kernel exposes and explains what it does not.

Verification evidence

• CI: all eight jobs on this commit.
• Windows release assets: CLI and NSIS build, both fixture suites, packaging, and the packaged CLI installed and run in isolation.
• Linux release assets: CLI built on ubuntu-latest, fixture suites, packaging, and the packaged CLI executed with its version checked.
• Version-management regression tests: 30 passed, including catalogue validation, rollback and CRLF checkouts.

OpenHardwareOS v0.1.2 — published-artefact fixes and a pinned toolchain

OpenHardwareOS v0.1.2 is a Windows x64 preview update. Existing v0.1.0 and v0.1.1 tags and downloads remain available.

Changes

• The published SHA256SUMS is now written with LF. Until v0.1.1 it used the host newline (CRLF on Windows), which made shasum -a 256 -c SHA256SUMS report every entry as a missing file on macOS and Linux. The digests themselves were always correct.
• The published install.ps1 is byte-for-byte the committed script. It used to be copied out of a Windows checkout, where core.autocrlf had converted it to CRLF, so the released file's digest could not be reproduced from the repository. The packager now normalises it, proves it equals the blob in the commit, verifies SHA256SUMS carries no carriage return, and refuses to produce a package when either check fails.
• .gitattributes pins eol=lf, so a checkout reproduces the committed bytes on every platform instead of depending on the machine's git configuration.
• rust-toolchain.toml pins 1.98.1, the compiler CI uses, so every rustup-managed cargo — CI, a fresh checkout, the Windows acceptance machine — resolves the same release. rust-version stays 1.95 as the minimum.
• A new fixture suite, scripts/release/test-packaging.ps1, runs before packaging in the release workflow and covers the asset set, every checksum, a CRLF working tree, a genuinely CRLF blob, and the two guards themselves.
• The six-stage hardware support plan is versioned in docs/plans/hardware-support/: a byte-for-byte mirror of GitHub issues #1–#7 plus an index that states which document is authoritative for what.
• Documentation corrections: what Windows CI has actually run (build, tests, NSIS packaging, public install) versus what still needs a real machine; the Windows-compile gap that the first CI run exposed; and the acceptance entry now lists the CI evidence with links.

Install

Use the Windows PowerShell installation instructions for this version. The prebuilt CLI requires neither Rust nor Node.js. SHA-256 verification happens before extraction. The default command installs to a separate version directory and preserves older installs.

The desktop installer and optional PowerShell script are unsigned. LibreHardwareMonitor is a separate prerequisite for supported motherboard channels and is not bundled.

Scope of validation

Software and installation validation do not establish compatibility with a physical fan or water pump. No fan or pump has responded to a write from this code. This release does not change the control path: the exit-reporting and provider-selection fixes are being prepared separately, and the version catalogue records hardware_validation: not_verified for every release.

release.json identifies the exact source commit and build workflow. SHA256SUMS covers the six accompanying assets.

Verification evidence

• CI: all eight jobs passed on this commit — formatting, Clippy, the three Rust platforms, the frontend, the NSIS bundle, the licence audit and the version catalogue. One desktop behaviour test failed on the first attempt and passed on re-run; its race is a known test defect, not a product one, and is fixed in the next version.
• Windows release assets: built the CLI and the NSIS installer, ran both fixture suites (test-install.ps1, and the new test-packaging.ps1), packaged the assets and installed the packaged CLI in isolation.
• Version-management regression tests: 30 passed, including catalogue validation, failed-update rollback and CRLF checkouts.
• The published SHA256SUMS was re-verified after download: it is LF-only, and shasum -a 256 -c SHA256SUMS validates all six entries on macOS/Linux — the check that failed on every entry for v0.1.0 and v0.1.1.
• The published install.ps1 hashes to the blob committed at this tag (git blob f2617d08), where v0.1.1 published the same committed script as CRLF.

OpenHardwareOS v0.1.1 — Version tree and cooling safety fixes

OpenHardwareOS v0.1.1 is a Windows x64 preview update. Existing v0.1.0 tags and downloads remain available.

Changes

• Add a searchable, keyboard-accessible version tree with separate released, development and planned states, exact source references, install instructions and validation evidence.
• Add a version catalogue and maintenance commands for version preparation, manifest synchronization, generated views and recording verified GitHub publications. Failed file updates roll back; concurrent edits are preserved.
• Parameterize Windows release and public-install checks by version. Install scripts require an explicit version.
• Fix ramp limiting that could reduce fan or pump duty below its safety floor.
• Ensure thermal emergency requests bypass ramp limiting even when the requested duty already meets the emergency target.
• Reject non-finite requested duty and keep non-finite current readings out of ramp calculations.
• Plan v0.2.0 around one identified LibreHardwareMonitor pump channel, with telemetry, bounded control, fault handling and restoration acceptance criteria.

Install

Use the Windows PowerShell installation instructions for this version. The prebuilt CLI requires neither Rust nor Node.js. SHA-256 verification happens before extraction. The default command installs to a separate version directory and preserves older installs.

The desktop installer and optional PowerShell script are unsigned. LibreHardwareMonitor is a separate prerequisite for supported motherboard channels and is not bundled.

Scope of validation

Software and installation validation do not establish compatibility with a physical fan or water pump. This release does not claim real-pump acceptance. See the pump support plan.

release.json identifies the exact source commit and build workflow. SHA256SUMS covers the six accompanying assets. The CLI archive includes its source metadata, Apache-2.0 license and third-party notices.

Verification evidence

• CI: all eight jobs passed, including Windows 490 Rust tests and frontend 42 tests.
• Version-management regression tests: 30 passed, including rollback, concurrent edits, CRLF and release-source validation.
• Windows release build and packaged installation checks passed. Seven release assets were downloaded and checked before publication, including all listed SHA-256 values and source commit b5ddc6da97c47ed1059618f4d654aeea4a92a478.
• Public Windows PowerShell 5.1 installation passed: anonymous release download, checksum verification, versioned install, source/tag check, diagnostics and ten-step simulated demo. All seven public assets also matched the reviewed build byte-for-byte.