admin
4a4a1e245a
gates / gates (push) Successful in 32s
Four defects of one family, all shipped today: something the box already knows, thrown away or drawn
as its opposite. Agent v0.128.0, controller v0.210.0. NO HUB CODE, no hub bump, no ArgoCD sync.
R-265 (this repo). timeout-minutes: 5 on the gates job — every honest run in the observed session
finished in 18-34s, so this is ~9x the slowest and far under whatever reaped run 264 at 834s with no
log. The alarm mail now carries Elapsed (start stamp via $GITHUB_ENV; an absent stamp prints
"unknown (no start stamp)", never a bogus 1.7-billion-second figure) and its "names itself in the run
log" sentence is qualified so it cannot mislead when there is no log.
⚠ THE UNKNOWN IS NOT CLOSED. Whether the if: failure() alarm fires for a REAPED job is still
unverified. The timeout makes the reap unreachable in practice; it does not answer what happens in
one. Demonstrating it means deliberately hanging a run on main, which would leave the branch red for
a parallel session. Said in the workflow comment, the changelog, R-265 and the report — none of them
claiming it is answered.
GOLDEN 0.210.0 baked, published, round-trip verified, NOT VOUCHED. The currency gate went red the
moment the controller was bumped — correct — and is closed by the bake, never --no-verify. No
--no-verify anywhere this session.
⚠ THE AGENT WAS NOT PUBLISHED UNTIL THIS SESSION CHECKED, AND IT MATTERED. R-221's fix is in the
AGENT, and a fresh install takes its agent from the Day-0 manifest. The binary had been hand-deployed
to felhom-pve and never published, so agent_version 0.128.0 was not selectable and a fresh install
would have received 0.127.0 — the golden would have carried the controller fixes and NOT the one the
headline defect needed. Caught by checking each Day-0 value was FETCHABLE rather than assuming.
Published from the live-deployed bytes, sha-verified across the hop first.
Registers. R-221, R-259, R-258, R-265 CLOSED. R-266 MINTED (READY): the failed root statfs still
travels to the hub as a 0-of-0 disk; ranked LOW because it is the quiet direction — it can only miss
a true alarm, never raise a false one — and it is now a two-repo wire change governed by G-1's gate.
Highest ID moved R-265 -> R-266.
CONTEXT S-39 rules the convention this project was missing: "we do not know" is never drawn as
"fine", and the codebase has ONE way of saying it — an explicit ...Known bool companion checked in
the template. ROADMAP G-3 was explicitly blocked on that decision and is unblocked; what remains
there is a survey-and-convert of existing sites, not the gate.
Capability map row 93 CHECKED and it was NOT claiming something untrue — it is about the operator
notification path. But its narrative ("the page you open to ask whether ONE app is backed up")
invites the wrong reading, and the adjacent thing WAS false until v0.210.0, so the row now records
that the two halves disagreed and only the operator half was true.
Six red-proofs across the two code repos, each with the mutation asserted applied. The one that
matters: Part 1 Scenario A FAILED against today's tree, with the intended message.
Part 1's operator-present live validation is OWED and is the session's STOP.
repo_gates --fast: all 8 OK.
6.2 KiB
6.2 KiB
STATUS — what works, what's broken, what's next
Updated 2026-08-08.
A view, not a source.
documentation/backlog/OPEN-ITEMS.mdis the authority; this page restates part of it in plain words, and nothing may exist only here. NotCONTEXT.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.mdfiles 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).
- 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)