* board-test: exercise the binaries that ship, not an example that doesn't
The playground was a second implementation of the update system — publisher and
robot in one binary — written from a premise its own module doc still stated:
that `updaterd`'s socket server and `robotctl`'s transport "are not wired up
yet, so this drives `Engine` directly". They are wired up, and board-test.sh
drove them over a real unix socket forty lines below the checks that didn't.
So the board test asserted install, unhealthy rollback, tamper refusal and
boot-counter recovery against `updater/examples/playground` — which `xtask
package` never puts in a release artifact. Every one of those checks covered a
binary no robot will ever run, in a script whose stated job is to "exercise the
result on real ARM64 Linux".
The shipped daemon already has every piece needed: `install --from` for the
local-dir install a bare board does, `--inject-fault` for the failure paths,
`--check-only` for what a boot does. The only thing neither binary does is mint
a signed release to feed them, so that — and only that — becomes a
`test-support` example, reusing the same `Publisher` the tests publish with
rather than the playground's third hand-rolled copy of it (which had drifted:
no fixed tar mtime, the reproducibility property xtask relies on).
The fixture is minted host-native and mounted into the container: a release is
signed manifests and tarballs, no more architecture-dependent than the ones
GitHub serves. Releases are staged into `published/` one at a time, so what
`latest` resolves to is explicit at every step rather than a side effect of
publish order.
Two stale claims fixed while here: updater-design.md said release.yml verifies
via "`LocalDir` + `playground apply`" when it uses `updaterd install --from`,
and the README walkthrough is now the real daemon and CLI.
Assisted-by: Claude:claude-opus-5
* README: document the real update paths, drop the synthetic walkthrough
The "see the engine work" walkthrough was ceremony: mint fake releases, copy
one into a directory, start a daemon with a rigged health gate, drive it from a
second terminal. Six commands to watch a rollback that `updater/tests/apply.rs`
already asserts, and nothing a reader would ever type again.
What was actually missing from the README was how you install without a
network. `updaterd install --from <dir>` is the factory and sideload path, and
`--force` is the one escape hatch for the case that has already come up on a
board: an installed `updaterd` too old to accept the release that fixes it
being too old, rolling the new release back every time, with the binary running
that gate being the one to be replaced. Both were documented only in
`--help` text nobody reads before they need it.
`fake-release` stays — `scripts/board-test.sh` mints its fixtures with it. It
is just not something to put in front of someone reading the README.
Test count corrected to 319 while in that paragraph.
Assisted-by: Claude:claude-opus-5
6e70c1b882