felhom.eu/STATUS.md

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

Updated 2026-08-08.

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority; 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. Items, not paragraphs. One screen. If it does not fit, something belongs in the register instead.

Rebuilt from the register on 2026-08-07, from 258 lines. The old "what shipped recently" log is what the per-repo CHANGELOG.md files and the register are for, and is not restated here.

What works

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.

The backup promise is proved, and so is getting the data back yourself. A machine has been destroyed on purpose and its files came back byte for byte identical — four times now. On 2026-08-07 the household's own journey passed for the first time: someone with a browser and their recovery code got everything back with no command line inside the machine at any point, in 72 seconds. The two rough edges that walk found are also gone. (R-201, R-252, R-253 — closed.)

What's broken

• Nothing new is broken. The check against a fourth secret-in-a-page covers 4 pages of 27, and the cheap one covering all of them is blind to the shape that shipped. (R-255)
• The machine's own screen keeps telling an already-paired box to pair itself — 25 minutes after it was paired, on a screen that promises it refreshes itself. (R-214, R-235)
• A backup that covered nothing still calls itself „Sikeres". The state is honest; the word is not. (R-240)
• A machine waiting for its recovery code can stop backing up off-site without alarming us — after a rebuild we ARE told; the gap is reaching that state with no working tier. (R-243)
• The card offering to reopen set-aside backups promises more than we can deliver. (R-202)
• Deleting a customer leaves rows behind while reporting a clean teardown — no secrets, but it accumulates. (R-244)
• Putting restored files back where they belong is still a manual step. (R-213)

Fixed today — four things the machine knew and did not say

All one family: something the box already knows, thrown away or drawn as its opposite.

• A rebuilt machine can set up its own recovery again. The one fact the setup needs was written only the first time, and a rebuild replaced the configuration while leaving the note saying "already done". It is now checked and re-written every minute instead of remembered once, so a hand-edited or restored configuration heals too. This was the last item blocking a customer from something we promise them. (R-221 — agent 0.128.0.)
• A disk we failed to read is no longer drawn as a healthy empty one. No figures, no bar, and it says so: „A tárhely mérete most nem olvasható ki." (R-259 — controller 0.210.0.)
• A backup tick now answers about that app. It went green because some backup file existed and some other app's database dump had succeeded most recently. Now: that app's own result, and no mark at all when we have none. (R-258 — controller 0.210.0.)
• Our own alarm no longer points at a page that may not exist. A check run now gives up after five minutes rather than hanging until something else kills it, and the mail says how long it ran. (R-265.)

Not fixed, and said rather than glossed: that failed disk reading still reaches us as "0 of 0 GB". It is the quiet direction — it can only miss a true alarm, never raise a false one. (R-266)

What we're working on

• Widening the check so a fourth secret-in-a-page is caught by a machine. (R-255) · Deciding the twenty-one — each gets a reader, or stops being sent. (R-264)
• Proving the hub really keeps the old sealed key when a machine re-seals. (R-198) · Still open, none urgent: (R-256, R-257, R-261…R-263, R-266)

Waiting on you

• A watching moment, five minutes. Today's recovery fix is proved by removing one line from a demo machine's config — backed up first, disposable machine, no customer data near it — and watching the setup screen go green on its own. Nothing is destroyed. Say when.
• One approval, three values this time. Hub → Configuration → Day-0 artifacts: Golden 0.210.0, Agent 0.128.0, minimum agent 0.127.0 (unchanged) → Save. Each was checked to be downloadable and selectable before being written here. Agent 0.128.0 is the one that carries today's recovery fix, so a new machine needs both, not just the image. It supersedes the 0.209.0 approval you already gave, and it is reversible. (R-242)

DooPlex infrastructure — separate from the product

Kept under its own heading rather than dropped: these are real asks that need you, but they concern the machine all this is built on, not what a customer receives. Mixing them in is why the page stopped being readable.

• DooPlex's own backup keeps every copy inside the same box, and is silent when it fails. (R-232)
• 193 old images exist only on this machine, ~27 GB against 199 GB free — clutter, not space. (R-210)
• The hub password needs rotating — a diagnostic printed it into a session log; nothing suggests anyone else saw it. (R-132)
• One thing to read after DooPlex next restarts — the second-SSD move has never survived a reboot; it writes PASS/FAIL to /var/log/felhom-store-postboot-check.log. On PASS, 34 GB comes back. (R-209a)
• Backup scripts on DooPlex are unversioned host state (R-231), and the instruction-file follow-ups each need a decision rather than an edit (R-229, R-230).
• The Configuration page: 26 s → about 10 s, and not finished. It was never hashing anything — the hashes are already stored and just read. It was making 42 calls one after another. What is left is a single slow Gitea lookup per dropdown; making it instant means holding a short-lived copy, which trades freshness for speed and is your call. Numbers were taken on a busy box and swing 3× — worth a re-check when it is idle. (R-267)
• Our build-check alarm has one gap left. A run that hangs is now cut off after five minutes and the mail says how long it took — but whether the alarm fires at all when the machinery kills a run outright is still unverified, and we have not claimed otherwise. (R-265)