Files

T

gates / gates (push) Successful in 8s

Details

docs: R-165 merge built and proven at the bake; R-163 + R-175 closed, R-178 filed

07-backup-architecture.md gains §7.5.1 (S-1: the contract changed in the same
session): the ceiling §7.5 describes no longer exists for a box built from
golden >= 0.192.0, the bulkhead's replacement is recorded, and R-175 is FIXED
here rather than left standing — the bound is restated as a function of mp1
and scoped to split-layout boxes, naming all three real shapes.

Capability map: new row as IMPLEMENTED, deliberately NOT proven-live, with
the missing leg named — no box has been reinstalled from the golden, and
"the golden baked" is not "a box built from it works".

R-163 CLOSED: the ceiling it recorded stops existing. R-176(a) answered by
P1; (b) WITHDRAWN, since every node is reinstalled rather than migrated.
R-178 filed for the reinstalls, which were not done this session.

CONTEXT S-13 (the variant chosen on measurement; pruning rejected with its
reason) and S-14 (prove first, then vouch — the golden is published but
deliberately unvouched, because vouching is what makes a fresh install pick
up a layout no box has been proven from).

STATUS: plain-language section; both operator questions now answered, so the
waiting-on-you item is cleared. Two older entries trimmed so the page did
not grow.

2026-08-03 07:16:15 +02:00

8.6 KiB

Raw Blame History

STATUS — what works, what's broken, what's next

Updated 2026-08-02.

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority on open work; this page restates part of it in plain words, and nothing may exist only here. Not CONTEXT.md, which is technical state written for Claude Code — keep the two separate. Maintenance: update at the end of every session in which something shipped, broke, or was decided. One screen; cut items rather than extend it.

What works right now

A blank machine boots the Felhom disc, installs itself unattended, and is claimed by the customer, who sets their own password. They install apps from a catalogue of fifty-three, share files over the home network, and open apps from a launcher or a shared link. Backups run on their own to three places — the machine's drive, a second drive, and an encrypted off-site copy — and a customer can restore files and app data from the drive alone. Proven end to end on real hardware.

Apps come back after a power cut. The machine tells an app the customer switched off from one that simply did not come back, and waits for the system to finish starting before deciding instead of glancing once, five seconds in. Hard-reset the demo box six times in a row: everything came back every time, and an app switched off deliberately stayed off every time.

What's broken

The off-site copy can be erased by the machine that made it — the credential that writes it can also delete it. A daily snapshot is armed as a stopgap, and we have never restored from that copy. (R-95, R-87)

Three apps out of fifty-three kept their data where backups never looked. They reported healthy; the data would vanish on the next update. Two are fixed, the third is now clear to fix because it is installed nowhere. (R-156)

Local backups get 20 GB while apps get 50 GB. An app that outgrows the smaller space stops being backed up locally — and the off-site copy is made from the local one, so that stops too. Nothing is lost: the last good copy is kept intact. (R-163)

When that happens, only one page says so — no email, no alert. The page that answers "is this app backed up?" is the one that stays silent. (R-158)

The checks now have two nets, and the second one emails you. Every repository has one command that runs all of its checks; it runs by itself before every push and refuses a push that fails. That one lives on the workstation and can be skipped. So the build server now runs the same checks again, on a machine that does not care who pushed or what they typed — and when they fail it sends you an email, because a red mark on a page nobody watches is not a warning. Proven with a real broken change, not assumed. The one thing it still cannot do is stop the change: every change here goes 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)

The backup partition is gone from the base image. A machine built from now on has one storage area instead of two, so a backup can use whatever space the machine actually has free rather than a fixed slice decided when it was built. The wall does not move; it stops existing.

What replaced the wall. It 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: if a backup would push the disk below a safe reserve, that one app's backup is refused, its last good copy is left exactly as it was, and you are told. 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.

How the shape was chosen — worth one line, because it was not the obvious one. Three ways of doing it were built and rebooted rather than argued about. All three worked. They differed in what they quietly broke: one put your backups inside Docker's own storage, where the normal way of fixing a sick Docker would wipe them; another exposed all of Docker's internals to the part of the system that manages your drives. The third does neither, and costs one extra line of configuration.

Nothing has changed on any existing machine. They keep their current layout and go on working exactly as before; they get the new shape only when they are reinstalled. The new base image is deliberately not switched on yet — nothing will pick it up until a machine has been rebuilt from it and checked, which is the next step. (R-165, R-163)

What we're working on

Now: the last app whose data was never saved; today's decisions written down.
Next: finishing the partition merge — the build is done and the decision is made; what is left is to reinstall the two demo machines from the new base image and check one end to end.
After: rebuilding how the machine records whether an app is meant to be running.

Waiting on you

How a new version reaches a machine. Pushing the installer publishes it — half a minute later every new machine downloads it, with no staging and no way back but another push. And publishing is a step we remember rather than one the release performs, forgotten twice: a fix can be live here and still not reach a new machine. Nothing is installing today, so this is the cheapest moment to 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)
Nothing — both partition-merge questions are answered. You chose the storage shape and the hard stop; both are built. The tester's box needs no conversion: it will simply be reinstalled. (R-165)

Changed since last update

2026-08-02 — The false "host offline" warning is fixed. The hub's database was supposed to be in a mode where reading a page cannot block a machine's status update; a one-word difference meant that setting had never taken effect, for the hub's whole life. Fixed and verified live. Also found: 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, 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. 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.

8.6 KiB Raw Blame History