admin
b03a105375
gates / gates (push) Successful in 17s
Hub only. No controller change, no agent change, no wire change — nothing to bake. demo-hp untouched: the operator is re-deploying it this evening. R-323 — the five-word phrase is „Tulajdonosi jelmondat". It was „Visszaállító jelszó": one word from the name retired last week, and false besides — it restores nothing, it proves the account owns the box being bound. Five sites, all in the hub; felhom-controller and felhom-agent carry the name nowhere, so no halt and no bake. Both suggested names were rejected with reasons: „Fiókjelszó" would collide with the dashboard login (a DIFFERENT real secret), and „Összekötési jelszó" would leave the two factors on this page separated only by kód-versus-jelszó — the exact shape being removed, since the other factor is the „Párosító kód". The chosen name differs on both axes, stem and noun. Naming only; the acceptance pin drives the real handler. R-324 — the hub's customer copy is under a guard for the first time. Retired names banned across all 95 hub files; retrieval stems registered in four declared customer surfaces. The selftest found a defect in its own instrument on the first run. One shared vocabulary in scripts/, drift-checked into the controller gate rather than copied (R-325 removes the scaffold). R-321 — a machine we told to be quiet is no longer reported as dead, and it was two doors, not one: because the state is RECORDED rather than deleted, the morning deadline check can skip it too. A deleted state returns "", which is not "down" — R-195's shape returning through a second door. The clock runs from the report the hub can see, so re-enabling starts it there and emits no recovery for an outage that never happened. Three red-proofs; the one that matters showed a genuinely dead machine sitting at "disabled" when the suppression was made unconditional. R-326 — "which claims are unproven" is answerable by a command now. The nine I have been repeating was the count of claims the 9 August pass DOWNGRADED, not the count of unproven ones. The real figures: 55 claims, 23 walked, 32 not — and only 6 of those 32 cite evidence. Its first run found a stale claim (R-327).
7.1 KiB
7.1 KiB
STATUS — what works, what's broken, what's next
Updated 2026-08-13 (late — the third name, a machine told to be quiet, and a picture you can query).
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. Items, not paragraphs. One screen. If it does not fit, it belongs in the register instead.
Waiting on you
Nothing. All three questions that stood here were answered on 12–13 August and have moved to Decided below. A decided question left in the deciding list is how a person loses track of what is actually waiting.
Decided — and what would reopen each
A decision with no trigger becomes a permanent silence, so each one names what would make us look again.
- Getting old backups back yourself: NOT BUILT, deliberately. A customer in that position is a support conversation, and we can do it by hand. Reopens if: a real customer actually asks — one request from a person who is not us. (register: R-312)
- The unopenable old copy on
demo-felhom: KEPT, as a test fixture. Not for sentiment: it is the only state in existence where a set-aside store is present and cannot be opened, which is the case any future handling of lost backups has to face honestly. Delete it when: that work ships, or is abandoned. Until then it is a fixture, not an accumulation. (register: R-313) - A machine in two kinds of trouble says both things: LEFT AS IT IS. Its real-world likelihood is unknown, and hiding one card risks hiding a real second failure. Reopens if: it is observed happening outside a constructed test. (register: R-303)
What works
Both demo machines are home, healthy and reporting on the approved pair — controller 0.214.0, agent
0.129.0, delivered by the floor rather than by hand. Off-site is credentialed on demo-hp and its
repository still opens with the machine's own key. drill-r50 is reverted to virgin, powered off.
What the fleet actually is, because two summaries have now been misread: the hub holds five
customer records and three machines. The machines are demo-felhom and demo-hp (both ours, both
disposable) and drill-r50 (a nested drill VM on DooPlex, reverted and powered off). peti-felhom
is a real machine we have not heard from since 15 July and has no host record. tester-1 is a
record with no machine — created 13 August, no host, no backups, nothing to lose.
Shipped
- The removal now genuinely reverses the installation (R-316,
installer-v1.28.0published). The second reinstall used to hit our own leftover; it was watched failing on the cycle that actually fails, then watched passing. - A correct recovery code is no longer called wrong (R-311, three components). If a customer types the code for an older set of backups, the machine now checks the packages we kept, recognises it, and says so: your code is correct, it belongs to an earlier package, we kept it, your current backups are fine, write to us. It deliberately promises no restore, because there is no button yet.
- The drive can be re-attached after a reinstall (R-280), and the orphan card and the countdown banner stop promising retrieval they cannot see is still true (R-294, R-299, R-302).
- One name per secret — now both halves (R-295). The dashboard code is „Beállító kód" everywhere, on the machine and in the hub's emails; „Visszaállító kód" is retired. It collided with the escrow „Helyreállítási kód" and cost a real code.
- The hub can see whether a machine's guest still has working networking (R-319, first reader built against R-264). A machine quietly repairing its own network over and over is now visible instead of being a green tick; a machine that does not report it is drawn as unknown, never as healthy.
- The third secret has its own name (R-323, on your ruling). The five-word phrase that proves an account owns the box being linked is „Tulajdonosi jelmondat". It was „Visszaállító jelszó" — one word from the name we retired last week, and false besides: it restores nothing. Five places, all in the hub; no machine touched.
- A machine we tell to be quiet is no longer reported as dead (R-321). It went stale, then down, then e-mailed you twice about a silence you asked for. It turned out to be two alarms, not one — the morning backup reminder had the same blind spot and is fixed with it.
- The hub's own words are under a guard (R-324). Every customer e-mail and the linking pages are now checked for a retired name, and the guard has been watched catching one, ignoring an explanation of one, and going quiet again.
- The countdown on
demo-felhomis cancelled on your ruling (R-307). Nothing was deleted.
Broken, or knowingly incomplete
- Peti's machine has no recovery route at all — see the
PETIrow. This is a real machine belonging to a real person, not one of ours and not a record: it reported to the hub for four and a half months and has been silent since 15 July, when its host record was deleted. There is no key, no off-site copy and no local backup. If that drive fails, everything on it is lost. First act of the visit: copy the ~3.6 GB off before anything is reinstalled — it is currently the only copy in existence. Whether it stays parked is your call and is deliberately left open. - Kept backups can be opened — but still only by us (R-304 partly closed, R-312 decided-not-built). Today the honest answer is "your code is right, write to us" — and we can.
- The agent picks dnsmasq by looking at a file another package owns (R-317). The box installs fine; only LAN name resolution goes missing, and quietly. One line, deliberately not taken tonight.
- The storage page has its own separate reason for showing an empty list (R-298), untouched.
- Three more facts the machines send still have no reader (R-264): a staged-but-unapplied agent update, how deep a restore test actually went, and the two backup-integrity timestamps. Five others are now recorded as deliberately unread, which is honest rather than fixed.
- Two thirds of the standing picture is still unproven, and now you can ask (R-326).
python3 scripts/unproven.pylists it: of 55 claims, 23 are walked and 32 are not — and of those 32, only 6 point at an evidence document. The "nine" I have been repeating was wrong: nine is how many claims the 9 August review lowered, which is a different question. - The picture still describes one defect we have since fixed twice (R-327) — the naming claim. Its status may only be raised after the capability map moves first, which is a separate judgement.
Working on next
demo-hp is yours this evening — this session did not touch it. After that: the three remaining
R-264 readers, now that one has been built and we know what one costs; R-317 (one line in the agent);
R-327 (decide what the naming claim's status should be); then the 2026-08-09 batch (R-279 … R-292),
still untriaged against everything since.