admin
ceac5e0deb
STATUS.md REBUILT FROM THE REGISTER, not trimmed. Its own header says one
screen; it had reached 258 lines, having been 83 four days ago.
The three named defects, all fixed:
1. the "waiting on you" list asked the operator to decide the RECOVERY
SCREEN, built and shipped 2026-08-05, and to approve an orphaned-backup
deletion the register records as DONE the same day;
2. a stray line reading only "- **Nothing.**" sat mid-list;
3. the DooPlex infrastructure work was mixed in with the product's.
Infrastructure is now under ITS OWN HEADING rather than dropped, and the
reason is stated on the page: these are real asks that need the operator, but
they concern the machine this is built on, not what a customer receives.
Dropping them would lose real work; mixing them is why the page stopped being
readable.
The 100-line "what shipped recently" log is gone. That is what the per-repo
CHANGELOGs and the register are for, and restating it here is what made the
page grow back.
R-245 RE-FILED as a decision taken, not a question pending. It sat as
WAITING-ON-OPERATOR for a day with nothing actually pending - it was settled
on 2026-08-07. It keeps the whole reasoning and now carries the condition that
would REOPEN it, which the reasoning already named: QUOTA, old set-aside
history blocking new backups. A condition, not a calendar.
AUDIT OF EVERY WAITING-ON-OPERATOR ROW, parsing the state column exactly
rather than grepping for the phrase (which over-matches rows that merely
mention it): exactly ONE row carried it - R-245 - and it was a settled
decision. So zero rows were genuinely waiting, and the drift was caught while
it was still a single row.
R-246/R-247/R-248 file the read-only stale-blob spike's findings. R-242
updated: it recurred within a day, and shape (b) is now built - with the vouch
half explicitly still open on that row rather than being papered over.
5.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-08. It had reached 258 lines; its "waiting on you" list asked for two things already shipped and carried a stray line reading only "Nothing."; and it mixed the DooPlex infrastructure work in with the product. The old "what shipped recently" log — 100 lines of it — 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. A machine has been destroyed on purpose and its files came back byte for byte identical — three separate times, including a filename with Hungarian accents.
What's broken
- A household still cannot get their own data back unaided. Every individual link now works; no single walk has completed end to end without someone stepping in. (R-201)
- 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 raises no alarm to us. It quietly stops making off-site backups, and three separate safety nets each correctly decide it is not their business. The household can see it; we cannot. (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
- A leftover flag has been silently switching off the new recovery detection on one demo machine since 4 August. A Re-issue during the recovery drill set it, using code we removed the next day. The flag is wrong — the sealed package does cover the key that machine is using, and the two fingerprints match exactly. Because of it the hub withholds a figure the machine needs, so the machine tells its owner "create a new recovery code" — the one act that would put their old backups beyond reach. A freshly installed machine cannot reach this state, because nothing has set that flag since 5 August. (R-246, R-247, R-248)
What we're working on
- The walk that either finishes the arc or says why not. It needs the base image current (done today) and a machine whose recovery detection is not silently switched off (answered today). (R-201)
- 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
- Approve the new base image, so every future installation carries this week's fixes. (R-239, R-242 — presented separately in this session.)
Nothing else is pending. 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). It has been re-filed as a decision taken rather than a question sitting in your queue.
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 move to the second SSD has never been through
a reboot; it now writes PASS or FAIL to
/var/log/felhom-store-postboot-check.logon every start. 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)