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.
86 lines
5.2 KiB
Markdown
86 lines
5.2 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-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.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.** 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.log` on 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)*
|