Files
felhom.eu/STATUS.md
T
admin 56f8aa611c
gates / gates (push) Successful in 40s
R-267 closed: 26.2s -> 5.4s cold / 0.14s warm, and two corrections to my own measurements
Registry pruned to the newest 10 per package on the operator's confirmed rule. 33 deletions, all
HTTP 204; the live-vouched golden 0.210.0, agent 0.128.0 and floor 0.127.0 were asserted into the
KEEP set BEFORE any DELETE was issued and verified still fetchable after.

TWO CORRECTIONS TO WHAT I REPORTED EARLIER, both recorded rather than quietly dropped:

1. 'Only 50 generic versions exist' was NOT a count, it was a PAGE LIMIT. ?limit=1000 returns at most
   50, and the 50 I measured was exactly the cap. Three older agent versions (0.81.0/0.80.0/0.79.0)
   only became visible after the first 30 deletions moved them onto page one. An unpaginated listing
   is not evidence of a total — this repo's own 'an empty listing is not evidence of emptiness' rule,
   walked into while measuring it.

2. The operator's 'reduce the number of artifacts' was the better call and my measurement said
   otherwise. I reported it helps sub-linearly and is not the lever. Measured after: trimming to
   10+10 took the COLD load from 13.4s to 5.4s, a 2.5x improvement on exactly the path the memo
   cannot help, because the fan-out is per-version.

drill-r50 runs agent 0.113.0, now deleted; flagged before deleting, disposable nested drill VM, only
its re-download path is gone.
2026-08-08 20:44:58 +02:00

7.2 KiB

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)
  • An already-paired box is still told to pair itself, 25 minutes on. (R-214, R-235)
  • A backup that covered nothing still calls itself „Sikeres". (R-240)
  • A machine waiting for its recovery code can stop backing up off-site without alarming us. (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 manual. (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)

And R-221 is now proven on hardware, not just in tests — on a demo machine we removed the one line, watched the setup screen refuse, waited one minute, and watched it go green by itself with nothing restarted. Every other line of that file came back identical.

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 — 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)
  • After DooPlex next restarts, read /var/log/felhom-store-postboot-check.log — the second-SSD move has never survived a reboot; 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 is fixed: 26 s → 0.14 s. It was never hashing anything — the hashes are already stored and simply read. It was making 42 calls one after another. Now they overlap, connections are kept, the answer is held for a minute, and the old artifacts are gone. Worst case is 5 s, once a minute at most. Your instinct to prune was right and my measurement said otherwise — trimming to ten of each halved the slow path. (R-267 — closed.)
  • I printed a live access token into a session log while setting up today's drill, and I am telling you rather than quietly rotating it. It only opens the agent's private channel to one demo guest, on a wire that exists solely between that host and that guest — not reachable from your network or the internet, on a disposable machine with no customer data. Rotating it also means updating the guest, so it is a deliberate act, not a background one. (R-268)
  • 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)