v0.2.10

v0.2.10 — the platform checks that its own backups ran

Fifteen invariants were re-asserted every night and not one of them was "the backups ran". The whole claim is that a node is rebuilt rather than repaired, and a rebuild restores from a backup, so the backup was the one load-bearing thing nothing asserted. The restore drills prove the mechanism worked once; they say nothing about whether last night produced a file.

Added

• posture.backups — a declared list of {namespace, cronjob, max_age_hours}. Each one's last SUCCESS must be recent, and each gets its own line. 15 → 18 invariants.
  • Reads lastSuccessfulTime, never lastScheduleTime: a CronJob that fires nightly and fails nightly keeps a fresh schedule time forever, which is exactly the silent failure worth catching.
  • DECLARED rather than discovered. A check that went looking for CronJobs that look like backups would fall silent the moment one was renamed or deleted — the two failures most worth catching. A declared name with no matching CronJob is a FAILURE, so deleting a backup is not a way to stop being asked about it.
  • A site that declares none prints backups: none declared, not asserted as info, never as a note (ADR-199): a line that cannot fail must not raise the number that holds.

Fixed

• bug-198 — deploy-observability installed a new binary and left the old process running. The installer already restarted a unit whose FILE changed and one whose startup-only CONFIG changed; a replaced EXECUTABLE was covered by neither, because the unit file and every config file stayed byte-identical and systemctl enable --now does nothing to a running unit. So the deploy printed "fetching v1.153.0", "active" and "host matches what was deployed" while two stale processes served — from two SECURITY releases, which left a patched binary on disk and an unpatched process answering requests.

  The install shapes now record what they replaced, and the restart pass asks what the unit loop already asked one layer up: is this process older than the artefact it is executing? That phrasing handles a fresh install for free, since a unit just started is newer than the binary it started from.

• The verification line reports the version the PROCESS returns, not systemctl is-active. The old line was true and said nothing about which binary, which is how this passed its own check.

Operator notes

• install.sh v0.2.10 on each host, then from the host that reaches the others: substrate deploy-posture --apply (ships the site.yml carrying the new backups: block) and substrate deploy-observability --apply.
• That deploy-observability --apply is the one that finally moves VictoriaMetrics to v1.153.0 and VictoriaLogs to v1.53.0 in the running processes. Confirm with the new line: victoria-metrics: active running v1.153.0.
• The invariant count on the site follows the hosts, not this release. It reads 15 until a host on v0.2.10 with the new site.yml records a run (ADR-173).

175 tests.