Files
felhom.eu/STATUS.md
T
admin 2ce3c2a0f2
gates / gates (push) Failing after 29s
golden 0.209.0 BAKED, PUBLISHED, ROUND-TRIP VERIFIED — the currency gate goes green (R-242)
The G-1 session released controller v0.209.0 (R-247), which made golden_currency_gate.py correctly
red and REFUSED THE PUSH: no golden carried the newest release. The honest answer to that is the bake
it asks for, not --no-verify. The gate's own docstring says the cost of a trip is one bake, which is
the operation this project wants to be routine.

656 697 956 B, sha256 c9c4bcd6..e818ff. Round-tripped: the published bytes downloaded back, hashed
independently, size and sha identical, and ./etc/felhom-controller-image read OUT of the downloaded
archive says felhom-controller:0.209.0 — the delivered artifact naming the controller it will start.

Acceptance markers all green (overlay2 x1, mount points x2 rootfs+mp0, upload HTTP 201 x1,
excluding/FATAL/mp1 x0), Result=success, ExecMainStatus=0. 404 pre-gate with a 200 control on
0.208.0 so a 404 could not mean "wrong URL". Token file->file into a 0600 file read inside the VM;
systemctl show grep = 0; committed-log grep = 0 WITH a control returning 1 to prove the grep works.
Bake VM destroyed, /root residue clean, qemu confirmed gone, drill disk restored to virgin.

IT ALSO CONSOLIDATES THE OPERATOR'S APPROVAL. Golden 0.208.0 was baked last night and never vouched;
0.209.0 contains everything it did plus R-247, so it supersedes rather than wastes it. One Save, not
two — STATUS.md updated accordingly and back to its 93-line screen.

NOT VOUCHED. Fresh installs still land on 0.207.0 until the operator saves. And R-242's untouched
half showed itself again: this gate flipped green on the presence of the evidence DIRECTORY, with no
vouch anywhere near it. Recorded, not built — ROADMAP G-8.

repo_gates --fast: all 8 OK, including wire-contract and golden-currency.
2026-08-08 09:01:26 +02:00

95 lines
6.1 KiB
Markdown

# 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, including a
filename with Hungarian accents. 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**. From logging in to seeing what is in the store took **72 seconds**.
*(R-201 — closed.)*
**And the two rough edges that walk found are gone** — after a rebuild the restore used to stop dead
twice; both refusals now say what happened, that nothing is lost, and link to the screen that fixes
it. *(R-252, R-253 — closed 2026-08-08.)*
## What's broken
- **Nothing new is broken.** All three secret-in-page faults are fixed; what remains is that the
*check* against a fourth covers 4 pages of 27, and the cheap one covering all of them is blind to
the shape that actually 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 rebuilt machine cannot create a new recovery code at all.** *(R-221)*
- **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 a box reaching that state with no working tier behind it. *(R-243)*
- **The card offering to reopen set-aside backups promises more than we can deliver** — we keep the old
sealed package, but nothing can open it. *(R-202)*
- **Deleting a customer leaves rows behind** on every test machine ever torn down, while reporting a
clean teardown. No secrets involved, but it accumulates with each walk. *(R-244)*
- **Putting restored files back where they belong is still a manual step.** *(R-213)*
## Fixed today — the thrown-away sentence, and a check so there is no next one
We could not tell whether your engineer could get into a machine. The machine says so every few
minutes; **the hub had nowhere to put the sentence and discarded it on arrival**, so a box with the
door open, the lock working and **no key issued** was reported as fine. Not a wrong answer — an answer
to a question nobody was asking. Fixed, and the alert now **names the missing key** instead of saying
"access degraded". *(R-260, R-247 — closed; hub v0.99.0, controller v0.209.0.)*
**The check was built first and watched failing on 40 facts, before a single one was fixed** — the
night before, an off-the-shelf tool for a neighbouring shape was rejected for failing exactly that
test. Of the 40: three now change what we are told, sixteen are genuinely redundant, and **twenty-one
are recorded as undecided rather than quietly waved through** *(R-264)* — the strongest being
per-guest network health, which we already lost 1 h 15 m to once.
## 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
from the overnight sweep, none urgent: *(R-256…R-259, R-261…R-263)*
## Waiting on you
- **One approval, and now it is the only one: the new base image.** Baked, published, byte-checked —
and **installations receive an older version until you press Save.** Hub → Configuration → Day-0
artifacts → Golden **0.209.0** → Save. One field moves, the other two were checked and are right,
and it is reversible. It supersedes last night's unvouched 0.208.0, so this is one decision, not
two. *(R-242)*
- **Fourth time in three days, so worth a minute.** A check now catches the *baking* being forgotten
— it caught it again today and refused the push until it was done. **Nothing catches the approval
being forgotten.** Two ways to close that are written up, neither built. *(ROADMAP G-8)*
## 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)*.