admin
59527d00f9
gates / gates (push) Failing after 21s
R-254 site one was the same defect and is fixed the same way. Site two was NOT the defect the row described: the pre-deploy hidden input is deliberate (a form must carry what it submits, README §318) and was left alone; the indefensible one was the readonly display input on an ALREADY-DEPLOYED app, where nothing is submitted. The premise that this broke a repo rule does not hold and is recorded rather than dropped: no line in the repo says 'no silent auto-fill'. What exists is CONTEXT.md:2070, about accidental EMPTY-password deployments. §7.3 measured on the fleet: site one's code path has never run (crafty-controller is the only app declaring initial_credentials and is deployed nowhere); site two's exposure is also empty (demo-hp runs three apps, none with a generated secret field). HONEST LIMIT: that is a current-state measurement, and nothing recorded reads — which was part of the fault. No evidence of exposure, and no mechanism that could have produced evidence either way. Rotation not indicated by anything measured. R-255 NEW: the guard covers 4 of 27 pages at runtime, and the cheap all-templates gate is blind to the shape that actually shipped (a secret under a neutral page-data key) — both verified, both stated in the gate's own docstring. Filed rather than declaring a partial guard complete. R-242 red a second time in 24h; --no-verify declared. The cadence is the argument for its other half: nothing gates the vouch.
95 lines
5.9 KiB
Markdown
95 lines
5.9 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 the walk found are gone.** After a rebuild the restore used to stop dead
|
|
twice — once because the machine no longer recognised its own drives, once because it refused to
|
|
restore an app that was not installed while promising, three lines above, that it would reinstall it.
|
|
Both now say what has happened, say that nothing is lost, and link to the one screen that fixes it.
|
|
*(R-252, R-253 — both closed 2026-08-08.)*
|
|
|
|
## What's broken
|
|
|
|
- **Nothing new is broken.** The three known secret-in-page faults are all fixed; what remains is that
|
|
the *check* against a fourth covers 4 pages out of 27, and the cheap check that covers all of them is
|
|
blind to the exact shape that shipped. Filed rather than papered over. *(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 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 last two passwords are out of the page source**, the same way as yesterday's: the page carries
|
|
only a yes/no, and the value is fetched when you ask for it — and the asking is now recorded, which
|
|
it never was. One of them was an app's own first-login password, read live out of the running app.
|
|
*(R-254, both sites fixed.)*
|
|
- **How much was actually exposed: nothing we can find.** The only app that generates a first-login
|
|
password isn't installed anywhere, and of the three apps actually running on the demo machine, none
|
|
uses a generated secret. **But nothing recorded reads** — that was part of the fault — so this is
|
|
"no evidence of exposure", not "proof there was none". No passwords need changing on that basis;
|
|
the call is yours.
|
|
- **One of the two turned out not to be a fault.** The deploy form's hidden password field is
|
|
deliberate: a form must submit what it saves, so the value you wrote down is the one stored.
|
|
|
|
## What we're working on
|
|
|
|
- **Widening the check** so a fourth secret-in-a-page is caught by a machine rather than by
|
|
someone looking. *(R-255)*
|
|
- **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.** Today's release needs a new base image before installations receive it — same
|
|
as yesterday, same answer: it is ours to do, not yours. *(R-242)*
|
|
|
|
*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 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)*
|
|
- **Instruction-file follow-ups**, each needing a decision rather than an edit. *(R-229, R-230)*
|