felhom.eu/STATUS.md

# 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. 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)*

**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)*

## 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)*

**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 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
that caught it, run in both directions: it clears the fixed version and still convicts the old one.
*(R-156)*

**A filling disk warns the customer before anything breaks, and a failed backup reaches you** — the
customer while there is still room to act, naming the drive and the space left; you when one app's
backup fails, with the disk figures. The customer is deliberately not told about the second: they can
free space, but they can do nothing about a failed backup. Both proven by filling a real disk. There
are two rules and not one because the serious warning fired on free space while the disk was only 91%
full — a percentage alone would have missed it. *(R-167, R-158)*

**The checks have two nets and the second emails you.** Every repository has one command that runs all
its checks, before every push. That one can be skipped, so the build server runs them again and emails
you on failure. It cannot *stop* a change — everything goes straight to the main copy with no review
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)*.
- **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)*

## 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.
  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.

- **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. 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.