Summrise 0.3.12 (canary)

Canary build 0.3.12. Prerelease: canary channel, canary signing keys.

The change: the operator's device list now reads like a list of machines. The device announces
?v=<release>&n=<machine name> on the channel URL it already opens, the console records both, and
/devices returns name, online, version and a last_seen that updates when a channel opens.

One bug found on the way: the first attempt announced CARGO_PKG_VERSION, which is the crate's
0.1.0, not the release the launcher started — the list showed version=0.1.0. The value now comes
from the runtime config's release version.

Verified on two machines: name=DESKTOP-9VH92BJ online=True version=0.3.12 and
name=DESKTOP-14RJCR8 online=True version=0.3.12 through the public console URL.

Assets: installer, app binary, signed document, SHA256SUMS.

CI still cannot start a job on this account (private-repo minutes), so this release was assembled from
a local build and verified by installing it on both canaries.

Summrise 0.3.10 (canary)

Canary build 0.3.10. Prerelease: canary channel, canary signing keys.

The fix: making state.json read-only — what a full disk, a read-only volume or a permissions mishap looks like — took the device offline. 0.3.9 exited on its first write, so port 18090 refused connections while the supervisor kept restarting an app that could not start. The identity facts had been read successfully; only persisting them failed, and exiting throws away the console channel exactly when an operator needs it.

0.3.10 treats a failed write at startup as a loud warning: the device serves with the document it read. Every later write fails the same way, and the message says so.

Verified on a machine: on 0.3.9 the same fault produced curl: (7) Failed to connect; on 0.3.10 the device answered /api/health → {"status":"ok","version":"0.3.10","pid":7832} with the document still read-only. The attribute was then cleared and the device restarted so state persists again.

Assets: installer, app binary, signed document, SHA256SUMS.

CI still cannot start a job on this account (private-repo minutes), so this release was assembled from a local build and verified by running it.

Summrise 0.3.9 (canary)

Canary build 0.3.9. Prerelease: canary channel, canary signing keys.

The fix: truncating state.json left 0.3.8 answering {"status":"degraded","reason":"state: the state file is corrupt: … EOF while parsing a value"} — honest, and permanent until someone deleted the file. The state is a cache of identity the install can rebuild, so the unreadable bytes now move to state.json.bad (kept as evidence), the event log records state_quarantined with the parse error, and this start writes the document the install can describe.

Verified on a machine: the same truncation on 0.3.9 ends with /api/health → {"version":"0.3.9","pid":20936}, a fresh state.json naming 0.3.9, state.json.bad holding the old bytes, and the state_quarantined line in events.jsonl.

The degraded path stays for the other half: a document corrupted while the device runs is still reported as a 503, because inventing a document under a running device would hide data loss.

Assets: installer, app binary, signed document, SHA256SUMS.

CI still cannot start a job on this account (runner_id: 0, zero steps — private-repo minutes), so this release was assembled from a local build and verified by running it.

Summrise 0.3.8 (canary)

Canary build 0.3.8. Prerelease: canary channel, canary signing keys.

The fix: the uninstaller deleted the files NSIS installed and stopped there. The two baseline generations (~30 MB) and repair.log — written by the supervisor, not by NSIS — survived an uninstall, so a later install inherited a stale baseline. uninstall.exe now removes $INSTDIR\baseline, repair.log and the swap records, and still keeps %ProgramData%\Summrise on purpose.

Verified on a machine: before the fix, an uninstall left baseline/current 14.5 MB and baseline/previous 14.9 MB; after it, neither exists, sc query SummriseLaunch answers 1060 (not installed), and only the operator's own files remain. Both canary machines were then reinstalled on 0.3.8 and their --self-check is green.

Assets

• SummriseSetup-0.3.8.exe — installer (silent: /S /D=<dir>)
• summrise-device-0.3.8.exe — the updater's artifact (unchanged bytes from 0.3.7: the fix is in the installer)
• release-0.3.8.json — the signed release document
• SHA256SUMS

CI still cannot start a job on this account (runner_id: 0, zero steps), so the tag's installer run is red for that reason; this release was assembled from a local build and verified by running it.

Summrise 0.3.7 (canary)

Canary build of the Summrise device runtime (0.3.7). Prerelease: canary channel, canary signing keys.

What is in it

• SummriseSetup-0.3.7.exe — the Windows installer (MUI2/NSIS): service, Add/Remove Programs entry, silent /S /D=<dir>, uninstaller, health gate that refuses a device that does not answer.
• summrise-device-0.3.7.exe — the app binary the updater consumes.
• release-0.3.7.json — the signed release document the updater verifies.

What 0.3.7 adds over 0.3.6

• files.read/files.write take encoding: base64, so binary travels through the audited console path (verified on a canary: 8 bytes with NUL and high bytes, read back identical).
• summrise-launch --self-check prints what the install holds (current/previous generation, app hash, repair record, state) and exits 1 when something is wrong.
• a device that booted the previous generation records from:"previous" in repair.log.
• SSH private keys written by Windows' own ssh-keygen (CRLF) are accepted.
• the console's wait for a device's answer is bounded (30 s, 504) instead of unbounded.
• an unclaimed start no longer rewrites state.json's install identity.

How it was verified
Installed silently on two canary machines (registry readback '0.3.7', health: ok on port 18090), and the updater applied 0.3.7 on the first machine on its own schedule.

What is not verified
CI is blocked on the account (every workflow job fails at start with runner_id: 0, zero steps), so this Release was assembled from a local build rather than the CI pipeline; the tag's installer run is red for that reason.