Files

T

gates / gates (push) Successful in 7s

Details

docs: R-196 closed, R-204 items 1-3 closed, item 4 open (R-193)

- OPEN-ITEMS: R-196 CLOSED; R-204 items 1-3 CLOSED with item 4 named and
  its dependency stated. Header restates that R-202, the 1.2 GB ciphertext
  deletion and R-198's still-unit-proven retention all REMAIN OPEN.
- capability map: the recovery row keeps its 'with a person present'
  qualifier, names which crutch remains, and cites the three now gone.
- 07-backup-architecture: new 7.0 - what a customer can and cannot do
  ALONE, the four steps in a table with status. This is the section a
  future reader will use to answer that question.
- CONTEXT: standing ruling S-32, superseding S-31 steps 2-5.
- STATUS: rewritten to one screen per its own header; removes a corrupted
  half-overwritten section left from the drill session.
- ROADMAP: R-196 and R-204 collapsed.

2026-08-05 07:37:35 +02:00

6.3 KiB

Raw Blame History

STATUS — what works, what's broken, what's next

Updated 2026-08-05.

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority on open work; 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 — keep the two separate. Maintenance: update at the end of every session in which something shipped, broke, or was decided. One screen; cut items rather than extend it.

What works right now

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.

And the whole backup promise is now proved. On 4 August we destroyed a machine on purpose and deleted a marked file from its disk. Using the recovery code you saved: the backup key came back identical, character for character; the existing off-site store opened rather than starting over; and the file was restored byte for byte identical. (R-201)

What's broken

A customer still cannot do that recovery alone — but only one step is left. Getting from "the key is recoverable" to "the file is back" took four steps that appeared in no instructions. Three are fixed today (R-204): the local reset-code tool works on the first try instead of needing the controller restarted; re-issuing the storage credential no longer falsely marks the recovery key "stale" (which used to stop every off-site backup and invite the one act that would have destroyed the recovered key); and the everyday restore now says in plain Hungarian that it returned the app's settings and database and not your documents, and names the button that does. The step that remains is the first one: a rebuilt machine cannot get a storage credential by itself, because the one-time password was used up by its predecessor — so you still have to press Re-issue. That is a design decision waiting on you, below. (R-193)
Rebuilding a machine still throws away its off-site backup HISTORY. The machine invents the key that encrypts its own off-site backups, and a rebuilt machine invents a brand-new one. Both demo machines did this on 3–4 August — 51 backups (~1.2 GB) between them. The old key now survives the recovery ceremony, and a changed key now raises an alarm the same day, but the rebuild itself still starts a fresh history. (R-193)
One screen still tells the customer something we cannot yet promise. The „elárvult tároló" card says the old backups may later be restorable with the matching recovery code. That is true for machines that re-seal from now on and false for anything already orphaned — and the machine cannot tell which case it is in. We deliberately did not patch the sentence: a conditional promise that can still be wrong is worse there than a vague one. (R-202)
The off-site copy can be erased by the machine that made it. The credential that writes it can also delete it. A daily snapshot is armed as a stopgap. (R-95, R-87)

What shipped recently

2026-08-05 — Three of the four recovery crutches removed. The reset code works first time; a credential re-issue no longer blocks off-site backups on a healthy machine; and the default restore no longer quietly returns the wrong thing. (R-204 items 1–3, R-196)
2026-08-04 (night) — The drill PASSED, end to end, on real hardware. (R-201)
2026-08-04 — The folder-left-out-of-the-backup problem fixed both halves: the app and its backup look in the same directory, and a backup that misses a folder marked essential reports incomplete instead of success. (R-203)
2026-08-04 — The hub now keeps the off-site backup key when a machine re-seals, instead of only the whole-machine one, and a machine can fetch its own sealed package back. (R-198, R-199)
2026-08-04 — The daily false alarm about David is gone; a vanished permission now repairs itself and says it had to; the weekly off-site backup stopped reporting failure after a successful upload. (R-195, R-190, R-191)

What we're working on

Next: the retention proof. The hub keeping the old sealed key when a machine re-seals is the one remaining link that has never run outside a test. Proving it needs a second deliberate wipe on the spare demo machine, and it is its own procedure. (R-198)
Then: the orphaned-backup deletion you asked for (below), and the off-site copy the machine can still erase. (R-193, R-95)

Waiting on you

The one-shot credential decision — this is now the last thing between a customer and an unaided recovery. A rebuilt machine has no storage credential of its own, so an operator must press Re-issue. Everything after that point is now self-service. Deciding how a rebuilt machine should get a credential is the remaining design question. (R-193, R-204 item 4)
The recovery screen you described has been priced, and it can be built. A freshly installed machine that finds a sealed package waiting should say so, offer a box for the recovery code, and show what would come back before doing anything. One thing to weigh, deliberately not decided: that screen is reachable by anyone with the household's dashboard password, and the preview reveals backup dates and app names. (R-193)
The orphaned backups on the storage box — you said delete, and it is still owed. About 1.2 GB across the two demo machines, in set-aside stores nobody can open and nothing prunes. It wants its own session rather than riding along with other work. (R-193)
(decided 4 Aug) You chose not to keep a copy of the backup key on the Proxmox host, which makes the customer's own recovery code the only route back from a rebuild. (R-193)
A job, not a decision: the hub password needs changing. A diagnostic command printed it into a session log; nothing suggests anyone else saw it. (R-132)
One small question, not urgent. The automatic version check cannot see which version you have told machines to install, only which ones exist. (R-184)

6.3 KiB Raw Blame History Unescape Escape