docs: R-110 + R-115 closed, R-182 re-scoped by measurement, R-183/R-184 filed

R-182's direction REVERSED by Part 0's measurement. Filed yesterday as "the
reserve re-alerts on every status refresh" — too many alerts, seen at the
sending end. Measured at the receiving end: 9 events received today, 2 operator
emails sent. When two apps are refused in the same second the operator is told
about ONE; the other is dropped before LogNotification, so it leaves no row on
any channel and cannot be audited. The operator cooldown key is
customerID:eventType(+tier) and the capture-failed event carries `app` but no
`tier`, so the key has no app identifier. Same failure mode as R-97a, in a
second event type that never opted into the narrow fix. Nothing changed —
Part 0 was investigation only.

Correction owed: yesterday's report said "one recovery_unit_capture_failed per
app, HTTP 200". True of what the CONTROLLER pushed; a reader would take it as
"the operator was told about each app", which is false.

R-110 CLOSED (installer v1.23.0). Both channels moved. The spec's mechanism for
channel 2 rested on a factual error — the run-time fetches are sixteen, not
nine, and come from felhom-agent, not this repo — so no tag here could cover
them; pinned to the agent version being installed instead, on the operator's
ruling. Channel 3 needed no change: the URL never carried a ref, so no hub
change and no hub bump.

R-115 CLOSED. release-agent.sh builds, tags, publishes and verifies by an
independent download; check-published-versions.py refuses a tag with no package;
CI now runs the full gate set so it actually runs.

R-183 NEW+CLOSED: a fresh install fetched the vouched agent binary and its
sixteen config files from two different refs, and nothing compared them.

R-184 NEW: nothing stops the hub vouching a version that was never released.
The R-115 gate cannot see it — measured, the hub manifest and Gitea's package
listing are both 401 anonymously.

capability map: new PROVEN-LIVE row for the published installer channel.
STATUS.md 138 -> 127 lines.

STATUS.md

@@ -27,34 +27,51 @@ time, and an app switched off deliberately stayed off every time.
 also delete it. A daily snapshot is armed as a stopgap, and we have never restored from that copy.
 *(R-95, R-87)*
 
-**A full disk emails you repeatedly instead of once.** When the reserve refuses an app's backup you
-are told once by the backup run — correctly — but the page showing backup status re-checks on a timer
-and sends the same message again each time. Not new: as old as the reserve itself, and seen only
-because we watched the alerts closely while proving the fix below. Harmless if the hub already
-collapses repeats — which a comment claims and nobody has checked. *(R-182)*
+**A full disk tells you about ONE app and silently swallows the rest.** Yesterday this was written
+down the wrong way round — as *too many* emails. Measuring the receiving end reversed it: of nine
+refusals the machine reported today, **two emails were sent**. When two apps are refused in the same
+second you are told about one of them, and the other leaves no trace anywhere — not an email, not
+even a line in the log saying it was held back. So a second app can be going unbacked-up while you
+have already been told the problem is handled. It is the same fault we fixed once before for
+whole-machine backups, in a second place that never opted into the fix. *(R-182)*
 
 ## What shipped recently
 
-**The backup partition is gone, and both demo machines run on the new shape.** Wiped and rebuilt on
-3 August and taken through the whole customer journey — set up, install an app, back it up, restore
-it. One storage area instead of two; the space a backup can use went from 19 GB to 65 GB on the small
-machine and 45 GB to 233 GB on the big one. Three reboots each, correct every time. The two were
-rebuilt deliberately differently — one from a local copy of the image, one by the ordinary customer
-route with the published fingerprint checked — so the disk shape and the delivery route are both
-proven, rather than one proven twice. Their previous demo apps and data are gone; that was the point
-of a wipe, and you approved it. *(R-165, R-178)*
+**Pushing the installer no longer publishes it.** The script that runs as root on a brand-new
+machine was copied from the main branch and served within thirty seconds, so pushing it *was*
+publishing it, with no staging and no way back but another push. It now comes from a **labelled**
+version: publishing is moving the label, and undoing it is moving the label back — about half a
+minute, no deploy. The website is untouched by this and still updates in thirty seconds, because a
+typo fix must never need a release. Proven by actually doing it: a real push changed nothing that
+anyone downloads, moving the label published it, moving it back restored the previous bytes exactly.
 
-**What replaced the wall — and it now watches the right moment.** The wall was quietly doing a second
-job: keeping a runaway backup from eating the space the machine needs to keep running. That job is now
-explicit, and as first built it was checked too late — the big write happened first, unchecked, and
-only the small write after it was refused, while the message still promised your last good copy was
-untouched. **Fixed and proven on 3 August.** The machine now decides once, per app, **before it writes
-anything at all**, and that one answer covers all three steps: a refused app writes nothing, is not
-restarted, and the promise is now literally true — checked by fingerprinting every file before and
-after. It also stopped being blind to size, so an app is no longer waved through at 96% full and then
-allowed to write two gigabytes. Proven by deliberately filling a demo machine, once for each way it
-can refuse. Nothing is ever deleted to make room: every app has only one local copy, so "delete the
-oldest" would always mean destroying some other app's only copy. *(R-181)*
+**The catch that would have made it cosmetic was found and covered.** While it runs, the installer
+fetches sixteen more files — not nine, and from the *agent's* repository, not the website's. They now
+come from the same version of the agent the machine is installing. That closed a real fault nobody
+had noticed: a new machine was getting the agent's tested program and its untested settings files, in
+one install, from two different places. *(R-110, R-183)*
+
+**Releasing the agent now publishes it, in one command.** Putting a built agent where a new machine
+can download it was a step someone had to remember, and it was forgotten three times in five days —
+the last time leaving both demo machines running a version nobody could download, so a rebuild would
+have quietly installed the *older* one and reported success. There is now one command that builds,
+labels, publishes and then **downloads it back to check** — and a check that refuses to stay quiet if
+a released version cannot actually be fetched. Proven by making CI fail on purpose and then go green
+again on the same code. *(R-115)*
+
+**The backup partition is gone and both demo machines run on the new shape** — wiped, rebuilt and
+taken through the whole customer journey on 3 August, by two deliberately different routes so the disk
+shape and the delivery route are both proven. The space a backup can use went from 19 GB to 65 GB on
+the small machine and 45 GB to 233 GB on the big one. Their previous demo apps and data are gone; that
+was the point of a wipe, and you approved it. *(R-165, R-178)*
+
+**What replaced the wall now watches the right moment.** The wall was quietly keeping a runaway
+backup from eating the space the machine needs to run. As first built, that replacement was checked
+too late — the big write happened first, unchecked — while still promising your last good copy was
+untouched. Fixed and proven on 3 August: the machine decides once, per app, **before it writes
+anything**, and that one answer covers all three steps, so a refused app writes nothing, is not
+restarted, and the promise is now literally true. It also stopped being blind to size. Nothing is ever
+deleted to make room. *(R-181)*
 
 **The last of the three apps that never saved their data is fixed.** Installed nowhere, so nothing was
 stranded — checked on both demo machines and in the fleet list rather than assumed. Proven by the check
@@ -75,24 +92,27 @@ step — but it notices quickly and tells you. *(R-29, R-161, R-168, R-169)*
 
 ## What we're working on
 
-- **Now:** both of today's items are done — the reserve and the last unsaved app. Your two decisions
-  are written down and are ours to build.
-- **Next:** building those two — moving the installer onto a labelled version so publishing is one
-  step you can undo, and a check that refuses to install a version nobody can download *(R-110, R-115)*.
+- **Now:** nothing outstanding from today — the reserve, the last unsaved app, and both of your
+  decisions are all built and proven.
+- **Next:** the alert that tells you about one app and swallows the second *(R-182)*.
 - **After:** the off-site copy that the machine making it can still erase *(R-95, R-87)*.
 
 ## Waiting on you
 
 - **A job, not a decision: the hub password needs changing.** A diagnostic command printed it into a
   session log; nothing suggests anyone else saw it. *(R-132)*
-- **Nothing else.** You settled both open questions on 3 August — the installer moves onto a labelled
-  version, and a check will refuse to install a version nobody can download. Both are written down and
-  are ours to build. *(R-110, R-115)*
+- **Nothing else.** Both decisions you took on 3 August are now built and proven. One small question
+  will come back later: the automatic check cannot see which version you have told machines to
+  install, only which ones exist — closing that either needs a password given to the build server or
+  a check inside the hub itself. Filed, not urgent. *(R-184)*
 
 ## Changed since last update
 
-- **2026-08-03** — The reserve now guards the step that fills the disk, and its promise is true; the
-  last app whose data was never saved is fixed. Both proven on a demo machine, not just in tests.
+- **2026-08-03** — Publishing became something you do rather than something that happens: the
+  installer and the agent both moved onto labelled versions with a way back, and a check now refuses
+  a release nobody can download. Earlier the same day: the reserve now guards the step that fills the
+  disk and its promise is true, and the last app whose data was never saved is fixed. All proven on
+  real machines, not just in tests.
   Earlier the same day: both demo machines wiped and rebuilt from the new base image and taken through
   set-up → install an app → back it up → restore it, with the backup space ceiling gone and measured.
 
@@ -102,10 +122,6 @@ step — but it notices quickly and tells you. *(R-29, R-161, R-168, R-169)*
   the hub's own database is in no automatic backup** — it holds every machine's emergency password.
   Filed, not yet fixed.
 
-- **2026-08-02** — Boot recovery finished; six hard resets, everything back every time. Two instances
-  of the same hole — starting an app whose external drive was missing — were found by reading the code
-  and fixed the same day.
-
 - **2026-08-02** — Thirteen mechanical checks had built up and nothing ran most of them; two were
   failing quietly. Fixed. Decided the same day: the 20 GB backup partition goes away; and only this
   machine and the tester's box are protected, every other box may be broken or reinstalled freely.