docs: R-167 + R-158 CLOSED, R-165 SPIKED, R-174..R-177 filed

R-167/R-158 shipped and proven live (controller v0.191.x, hub v0.89.0):
two new capability-map rows PROVEN-LIVE with live citations, and
07-backup-architecture.md §7.5's closing claim "nothing warns when an app
crosses the line" is now false and rewritten (S-1: an architectural
contract changed in the same session). §7.5 also gains the caveat that its
size bound is ONE BOX'S, not the fleet's.

Part 3 SPIKE (audits/SPIKE-r165-mp1-merge-2026-08-02.md): M1-M5 measured,
NO layout touched. Three findings the merge session must not re-derive:
"the layout" is not one thing (200G/50G vs 50G/20G vs 16G/8G); mp1 is a
BULKHEAD and not only a ceiling, so after the merge an overflow reaches
/var/lib/docker; the golden fails closed on the split in four places.
D-a's condition (1) is currently SATISFIED — no external box is in the
hub's register, and both demo boxes are Tier 0 and reinstallable.
Recommendation given, choice NOT made — it ends at the operator's ruling.

CONTEXT.md S-11 (D-c's routing, and why R-158's own backup_failed proposal
was overruled) and S-12 (the monitoring landed BEFORE the merge).
STATUS.md gains the plain-language section and the merge decision, with two
older entries trimmed so the page did not grow.

New rows R-174 (closed same session), R-175, R-176, R-177; each ID grepped
free before minting.

STATUS.md

@@ -47,11 +47,30 @@ change, not assumed. The one thing it still cannot do is *stop* the change: ever
 straight to the main copy with no review step, so there is no point in the road for it to stand at.
 It notices, quickly, and tells you. *(R-29, R-161, R-168, R-169)*
 
+**A filling disk now warns the customer before anything breaks, and a failed backup now reaches you.**
+Until today the first sign that a disk was filling up was a backup that did not happen — nothing said
+anything beforehand. Two things changed. The customer is now warned while there is still room to act,
+naming the drive and how much space is left, in plain Hungarian that says what to do about it. And
+when one app's backup fails for any reason, **you** are told which app and why, with the disk figures
+attached — the page that answers "is this app backed up?" was, until now, the one page that never
+said. The customer is deliberately *not* told about that second one: they can free up space, but they
+can do nothing about a backup that failed, so telling them would only alarm them.
+
+Both were proven on the demo machine by actually filling a disk. One detail is worth knowing because
+it is why there are two rules and not one: the serious warning fired when free space dropped below a
+fixed amount while the disk was only 91% full — a percentage on its own would have missed it.
+
+**These went in *before* the partition change deliberately.** The partition being removed is also a
+barrier against a runaway backup filling the space the machine needs to run; putting the warnings in
+first means that when it comes down, the thing watching is already working and already tested.
+*(R-167, R-158)*
+
 ## What we're working on
 
 - **Now:** the last app whose data was never saved; today's decisions written down.
-- **Next:** merging the small backup partition into the large one, with the drive-filling warning and
-  the backup-failure alert in the same step.
+- **Next:** merging the small backup partition into the large one — **the warnings for it are already
+  done and working**, so this step is now only the partition change. It needs one decision from you
+  first (below).
 - **After:** rebuilding how the machine records whether an app is meant to be running.
 
 ## Waiting on you
@@ -63,6 +82,13 @@ It notices, quickly, and tells you. *(R-29, R-161, R-168, R-169)*
   settle both. *(R-110, R-115)*
 - **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)*
+- **The partition merge: one decision, now measured.** Removing the backup partition also removes a
+  barrier — today a runaway backup is refused on its own and cannot touch the space the machine needs
+  to run; afterwards it can, and a machine out of that space is stopped, not slow. So: do we add a
+  hard stop that refuses a backup before it eats the last of the room, or do we rely on the new
+  warnings? The recommendation is the hard stop, because it keeps exactly what the barrier gave us.
+  **Second question, which only you can answer:** does the tester's box need converting in place, or
+  can it be reinstalled? It does not report to the hub, so nothing here can tell. *(R-165, R-176)*
 
 ## Changed since last update
 
@@ -75,25 +101,20 @@ It notices, quickly, and tells you. *(R-29, R-161, R-168, R-169)*
   live. **Also found while checking it: the hub's own database is not in any automatic backup** — it
   holds every machine's emergency password and the escrow records. Filed, not yet fixed.
 
-- **2026-08-02** — Boot recovery finished. Both halves of the power-cut problem are closed: the
-  machine records what the customer asked for, and it now waits for the system to finish starting
-  before deciding what is missing. Six hard resets in a row, everything back every time. A hole the
-  previous day's change had opened — the machine would have tried to start an app whose external
-  drive was missing — was found by reading the code, reproduced on the demo box **before** anything
-  was changed, and fixed the same day. No data ever reached the wrong disk, but only because of a
-  filesystem accident nothing was relying on deliberately, which is why it was fixed rather than
-  noted.
+- **2026-08-02** — Boot recovery finished: the machine records what the customer asked for, and waits
+  for the system to finish starting before deciding what is missing. Six hard resets, everything back
+  every time. A hole the previous day's change had opened — starting an app whose external drive was
+  missing — was found by reading the code, reproduced on the demo box first, and fixed the same day.
+  **A second instance of the same hole was found and fixed today**, on the path that restarts an app
+  after an interrupted backup.
 
-- **2026-08-02** — Fixed and then doubled: thirteen mechanical checks had built up across the four
-  repositories and nothing ran most of them; two were failing quietly, one since 14 July. Both fixed.
-  Every repository now has one command that runs all its checks, it runs automatically before every
-  push, and the build server re-runs it after every push and **emails you when it fails** — proven
-  with a real broken change. One of the two failures was the setup page claiming the installer was
-  version 1.19.0 while machines got 1.22.0; that number is now **gone** rather than corrected,
-  because the page cannot know it — the installer is fetched fresh each run, so any number there is a
-  guess. A check refuses to let one be added back.
+- **2026-08-02** — Thirteen mechanical checks had built up across the four repositories and nothing
+  ran most of them; two were failing quietly, one since 14 July. Both fixed, and the arrangement that
+  replaced them is described above.
 - **2026-08-02** — Decided: the 20 GB backup partition goes away and shares space with app data. That
-  changes the disk layout, so it happens before any machine is installed outside the house.
+  changes the disk layout, so it happens before any machine is installed outside the house. **Measured
+  since:** no machine outside the house is registered yet, so this is as cheap now as it will ever be;
+  and the two demo machines can simply be reinstalled rather than converted.
 - **2026-08-02** — Decided: only this machine and the tester's box are protected; every other box,
   demo boxes included, may be broken or reinstalled freely. Two of the three apps that never saved
   their data are fixed; this page created.