Files

T

gates / gates (push) Successful in 7s

Details

docs: R-182 closed, R-90 closed on measurement, R-86 unblocked, ep0 record corrected

R-182 CLOSED (controller v0.194.0 + hub v0.90.0/.1), proven live on demo-hp. The
hub's notification_log for the run reads: two per-app failures RECORDED, one
digest SENT naming both, and the customer channel SKIPPED with operator_only.
Against the measured previous behaviour — two failures, one email naming one
app, one leaving no trace anywhere.

Scenario D proved itself on an event I had not planned: disk_critical alarmed on
two filesystems, the second was collapsed by the cooldown, and that collapse is
now visible WITH ITS KEY. Yesterday it would have left nothing at all.

A gap the spec did not anticipate is recorded with its fix: the per-app event
also fires from the periodic sweep, outside any run, so making it record-only
would have created a NEW silence. The sweep emits a digest too, with no run_id,
so it stays under the ordinary hourly cooldown.

ep0: MEASURED on the box — 7757 MB (8 GB), 4 vCPU, and the 4 GiB swapfile
SURVIVED the resize and is active (checked, because a resize is a stop/start).
The 40 GB local disk is UNCHANGED, so no disk figure was touched anywhere.

Five documents corrected — three of which the task's list did not name, found by
searching. Two audit/evidence documents ANNOTATED, body untouched: they record
what was true when written and that is their value.

R-90 CLOSED. R-86 unblocked and re-ranked, stated honestly: 8 GB is comfortable,
not unbounded — the original OOM was a 14.46 GB restore — so the restore-test
cadence should still be paced, just not by fear of the endpoint.

target-selection.md's "D-d did not name ep0 either way" is deliberately left
standing. It is the operator's question, not CC's.

STATUS.md 127 -> 83 lines, items rather than sentences.

2026-08-03 14:00:54 +02:00

5.4 KiB

Raw Blame History

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

Updated 2026-08-03.

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. Apps come back after a power cut: hard-reset the demo box six times, everything returned every time, and an app switched off deliberately stayed off. Proven end to end on real hardware.

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)
Nothing else open that affects a customer. The three faults that were on this list yesterday — the reserve watching the wrong step, the last app whose data was never saved, and the alert that told you about one app and swallowed the rest — are all fixed and proven on a real machine.

What shipped recently

A failed backup now tells you about every app, once. When several apps fail in one night you get one email listing all of them, what kind of backup failed for each, why, and how much space is left — instead of an email about one app and silence about the rest. Measured before the fix: nine failures, two emails. Separately, every failure is now written down the moment it happens, whether or not it is emailed, and a message the machine decides not to send now leaves a record saying so. A machine choosing not to tell you and nothing happening no longer look identical. A run that finds nothing wrong stays silent, and a backup you trigger yourself always reports. (R-182)
Publishing became something you do, not something that happens. The installer that runs as root on a new machine, and the agent, both moved onto labelled versions with a way back; a check now refuses a release nobody can download. (R-110, R-115)
The reserve now guards the step that fills the disk, and its promise is true. It decides once per app, before writing anything, and no longer waves an app through at 96% full. (R-181)
The backup partition is gone; both demo machines were rebuilt on the new shape by two different routes. Backup space went from 19 GB to 65 GB on the small machine, 45 GB to 233 GB on the big one. (R-165, R-178)
The last of the three apps that never saved their data is fixed. (R-156)
A filling disk warns the customer before anything breaks, naming the drive and the space left. (R-167, R-158)
The checks have two nets — one before every push, one on the build server that emails you. (R-29, R-161, R-168)

What we're working on

Now: nothing outstanding. Everything raised in the last three days is closed.
Next: restore-tests scheduled around each backup rather than on a free-running timer — now unblocked, because the off-site endpoint has the memory for it. (R-86)
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)
One small question, not urgent. The automatic check cannot see which version you have told machines to install, only which ones exist. Closing that needs either a password given to the build server or a check inside the hub itself. (R-184)
One older question still standing: whether the off-site endpoint counts as protected. It was never named either way, and it is yours to settle. (target-selection.md)

Changed since last update

2026-08-03 — A failed backup now reports every app in one email, and nothing is dropped without a record. You rescaled the off-site endpoint to twice the memory, which closed one item and unblocked another; the documents describing the old machine were corrected, and the audit records of what it used to be were annotated rather than rewritten.
2026-08-03 — Publishing became deliberate for both the installer and the agent, with a way back and a check that a release can actually be downloaded.
2026-08-03 — The reserve was fixed to guard the step that fills the disk; the last unsaved app was fixed; both demo machines were rebuilt on the merged disk layout and proven end to end.
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.

5.4 KiB Raw Blame History