admin
3f4fb3825f
gates / gates (push) Successful in 17s
Capability map: the unaided-recovery row turns FAILED -> PROVEN-LIVE, scoped, with what it still does not claim stated in the row itself: shape (c) did not fire positively (with the mint guard holding there is no local key, so the offer comes from shape (a)); and 'unaided' here means possible-without-a-shell, not obvious, because two obstacles are unsignposted. OPEN-ITEMS: R-201 closed with its evidence. Five new rows R-249..R-253 (the retrieval passphrase in page HTML; the host-key scan ladder vs AAAA settle; the listing's per-tag rows; the two unsignposted restore steps). R-243 annotated rather than re-filed: on a REBUILD offsite_delivery_stuck does not skip, so the row's gap is narrower than it reads. STATUS.md: headline changed, and trimmed 97 -> 92 lines rather than extended, per its own header. Teardown recorded as OWED with its before-measurements, the stop-and-age gate, and the positive controls that must survive.
93 lines
5.8 KiB
Markdown
93 lines
5.8 KiB
Markdown
# STATUS — what works, what's broken, what's next
|
|
|
|
**Updated 2026-08-07.**
|
|
|
|
> **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. Two rough edges remain, below.)*
|
|
|
|
## What's broken
|
|
|
|
- **The recovery works, but two steps are unsignposted, and one of them the machine gets wrong.** After
|
|
a rebuild the restore stops with "no data drive available" and never says the drives must be
|
|
re-attached *(R-252)*; then it refuses because the app is not installed — on a page that says, three
|
|
lines above, that the restore will reinstall it *(R-253)*. Both are fixable from the dashboard in a
|
|
couple of minutes. Neither is something a household would work out on its own.
|
|
- **The passphrase that fetches a customer's whole configuration is sitting in the page's HTML**, behind
|
|
a Reveal button that only hides it visually. Anything that reads the page rather than looking at it
|
|
gets it, with no record that it was read. *(R-249)*
|
|
- **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 making off-site backups without alarming us.**
|
|
Measured on 7 August: after a *rebuild* we ARE told, promptly and correctly. The gap is narrower than
|
|
it read — it is a machine that reaches the state without a 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)*
|
|
|
|
## Found today
|
|
|
|
- **The recovery walk passed** — see above. It also turned up five things: the retrieval passphrase
|
|
sitting in the page HTML *(R-249)*, a customer create that can fail on a fresh sub-account's DNS and
|
|
only says "try again" by not saying anything *(R-250)*, a recovery listing that shows the household
|
|
an "app" they never installed *(R-251)*, and the two unsignposted restore steps *(R-252, R-253)*.
|
|
- **The leftover flag that had been switching off recovery detection on one demo machine since
|
|
4 August was cleared with your approval**, and the fresh machine built for the walk confirmed it
|
|
cannot reach that state. Still owed: a ruling on the flag itself — nothing sets it, nothing can see
|
|
it, and it changes what a household is told. *(R-246, R-247, R-248)*
|
|
|
|
## What we're working on
|
|
|
|
- **Smoothing the two rough edges the walk found**, so the recovery reads as one path rather than
|
|
three. *(R-252, R-253)*
|
|
- **Proving the hub really keeps the old sealed key** when a machine re-seals. Never run outside a
|
|
test; needs a second deliberate wipe and its own session. *(R-198)*
|
|
|
|
## Waiting on you
|
|
|
|
- **Nothing blocking.** One thing is owed by us, not you: the walk's machine (`walk5`, VM 325) is
|
|
still standing as the evidence and needs tearing down.
|
|
|
|
*R-245 — whether an undecided household is auto-abandoned after 30 days — was settled on 7 August: we
|
|
do not build it, and the reasoning is recorded.*
|
|
|
|
## 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 makes every copy inside the same box, and nothing says when it fails.**
|
|
*(R-232)*
|
|
- **193 old images exist only on this machine** and cannot be re-downloaded. About 27 GB against 199 GB
|
|
free — clutter, not space. Nothing deleted. *(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)*
|
|
- **Instruction-file follow-ups**, each needing a decision rather than an edit. *(R-229, R-230)*
|