Fixes before the first tester: decisions 50/51 outcomes, register 359->361 (R-719/720/721/722/727 closed, R-723 fixed, R-724/725 narrowed, R-728/729 opened), STATUS with the Tester-2 checklist, report
## 2026-09-30T08:40:33Z 9202: the household's own NAS target, through the page's form (192.0.2.1 = RFC 5737 documentation address, never reachable; throwaway key)
time=2026-09-30T10:58:13.922+02:00 level=INFO msg="backup: restore-test skips an entry that is not a backup of a guest" target=local volid=local:backup/felhom-golden-0.236.0.tar.zst size_bytes=654115664 reason="not a backup of a guest (the storage reports no v
time=2026-09-30T10:58:13.924+02:00 level=INFO msg="backup: restore-test skips an entry that is not a backup of a guest" target=local volid=local:backup/vzdump-lxc-9100-2026_08_21-17_59_15.tar.zst size_bytes=656970239 reason="guest 9100 does not exist on this n
## 2026-09-30T08:38:33Z live, hub 0.126.0 — a made-up link (never real; same page as an expired one by design)
GET /bind/<made-up> → 200; page: Felhom — Doboz összekötése | Felhom | doboz | összekötése | Ez a hivatkozás érvénytelen vagy lejárt. | A hivatkozás 7 napig érvényes. Ha lejárt, kérj újat az ügyfélszolgálattól, vagy az összekötést az üzemeltető is elvégezheti. | Ha ez a te linked volt, és a dobozod még nincs összekötve, új linket küldünk arra az e-mail címre, amelyet a Felhomnál megadtál. | Új linket kérek | Felhom.eu
the button's form: <form method="POST" action="/bind/<token>/resend">
POST …/resend → 200; page: Felhom — Doboz összekötése | Felhom | doboz | összekötése | Kész. | Ha ez egy valódi hivatkozás volt, és a dobozod még nincs összekötve, néhány percen belül új e-mailt kapsz a regisztrált címedre. Ha nem jön, szólj az ügyfélszolgálatnak. | Felhom.eu
@@ -830,15 +830,17 @@ class (an image `VOLUME` at an unmounted path) is still live — `immich-server`
| **R-716** | **[P3-LOW] Apps installed before controller 0.281.0 keep their open sign-up — decision 47 closes it only on apps whose gate the box opened.** READ 2026-09-29 on the demo boxes after catalog `6faf432` synced: demo-hp's adventurelog and opengist, demo-felhom's opengist carry `signup_block:` in their synced template and no gate record, so no block (`audits/gate-rollout-2026-09-29/0/P0-3-demo-boxes-after-push.txt`). This is Part 0's rule working as designed (a catalog change never touches an installed app). **Needs an operator word** before anything changes on an installed app: a one-time "close sign-up now" press on the app page for an installed app, or leave them. Only the demo boxes have such installs today. **Operator ruled A (decision 49); built in controller v0.282.0 and pressed** on demo-hp's adventurelog and opengist and demo-felhom's opengist: before, sign-up served; after, refused; adventurelog's own switch on (`audits/signup-lock-2026-09-29/`C). | **CLOSED — 2026-09-29** |
| **R-717** | **[P3-LOW] opengist and wishlist keep their sign-up switch only in their own database — the box closes them with the address block alone.** MEASURED 2026-09-29: opengist `disable-signup` is an admin-panel setting (no env, no CLI); wishlist `system_config.enableSignup` (Prisma). Their blocks are case-insensitive and refused every trick shape (`audits/signup-lock-2026-09-29/B/`). **Fix direction:** an `after_setup` command that sets the database value (wishlist: a Node/Prisma one-liner; opengist: needs its sqlite with the app stopped). | **OPEN — P3; owner: CC** |
| **R-718** | **[P3-LOW] "Close sign-up now" restarts an app with its own switch, and the card does not say so.** MEASURED 2026-09-29 on demo-hp: pressing it on adventurelog recreated its backend (~30 s, one 500 on its login page). The window's card says the app restarts; the close card does not. **Fix direction:** the close card and the gate-open moment say "the app restarts once" where `after_setup.env` exists. **ALSO MEASURED 2026-09-29 (new-household drill):** the gate-open press on a fresh vikunja restarted it for its own switch — the front door answered 404 for ~2 s and nothing said so. | **OPEN — P3; owner: CC** |
| **R-719** | **[P2-MEDIUM] A customer who already exists never gets a fresh self-bind link when their new box registers: the last link expires in 7 days and nothing re-sends it.** MEASURED 2026-09-29 (new-household drill, `tester-1`): the previous link went out 2026-09-17 07:25 UTC at a host delete and expired 2026-09-24; the box registered at 19:11:30 UTC and its console told the volunteer to open the link from their e-mail — there was none that worked. Hub source: the link is sent at customer creation, RESET, e-mail set on a box-less customer and host delete (`selfbind_mint.go` callers `hosts.go:908`, `configs.go:850`, `customer_reset.go:162`) — never on appliance registration. The volunteer guide says the operator needs to press nothing. The operator pressed „Send self-bind link" (the mail arrived in 1 s) — an operator step the volunteer depends on, recorded, not an intervention. **Fix direction:** send the link when an unclaimed appliance registers while a box-less customer waits with no live link (R-509's first fix shape), or the guide's operator part says: press it the day the volunteer installs. Evidence: `audits/evidence-drill-new-household-2026-09-30/``phase0/operator-steps.txt`. |**READY — rank P2-MEDIUM; owner: operator (which shape) / CC** |
| **R-720** | **[P2-MEDIUM] A new household's apps are not in the off-site copy: every app starts with „3. mentés Kikapcsolva", and nothing the household is told says to switch it on.** MEASURED 2026-09-29 on a fresh box (customer with off-site ON, the default since 2026-09-16): `/backups/remote` read „Aktív — nincs kijelölt alkalmazás"; `/backups/apps` read „3. mentés Kikapcsolva — Ez az alkalmazás nincs kijelölve távoli mentésre" for all three apps. From source, an app is off-site only after `POST /backup/offbox/toggle` (`settings.SetAppOffbox`); no deploy or claim path sets it. The volunteer guide §7 says that after the recovery code „a távoli mentés magától elindul" — it starts, and copies nothing. So a household following the guide has **no off-site copy of its apps on night one**, on a one-drive box where the whole-guest tiers do not carry the data drive (`07` §6). The drill pressed „Bekapcsolás" for BookStack only, as a household reading the page might, to measure both paths on the night. R-240 (the empty run's wording) is the same gap seen from the other end. **Needs an operator decision** (it changes what the product promises): apps default to off-site ON when the customer has off-site, or the guide adds the step. | **READY — rank P2-MEDIUM; owner: operator (decide) / CC** |
| **R-721** | **[P2-MEDIUM] The household presses Stop during a whole-guest backup, and the backup starts the app again.** MEASURED 2026-09-29 19:37 UTC on a fresh box: the first off-site whole-guest backup quiesced three apps at 19:37:01; the household pressed „Leállítás" on actualbudget at 19:37:16 and the controller recorded `desired state for actualbudget recorded as "stopped"`; the same second the backup's early resume ran `unquiescing … restarting 3 stack(s)` and `Starting stack: actualbudget`. The app page then read „Fut" while `app.yaml` kept `desired_state: stopped` (so the next reboot would stop it). The household had to press Stop again, and the removal was refused „Az alkalmazáson mentés vagy visszaállítás fut" for ~4 min (honest). Evidence: `audits/evidence-drill-new-household-2026-09-30/``phase1/step10-stop-undone-by-quiesce.log`. **Fix direction:** unquiesce restarts only stacks whose desired state is still running; a test pins it (Stop during a quiesce → still stopped after the resume). |**READY — rank P2-MEDIUM; owner: CC** |
| **R-722** | **[P2-MEDIUM] The volunteer guide is stale in five places a volunteer reads literally.** MEASURED 2026-09-29 walking `runbooks/VOLUNTEER-first-hour.md` on golden 0.282.0: (1) §8 says BookStack's login is `admin@admin.com / password` — since the random first password (controller v0.280.0) that login is REFUSED; the app page says the right thing („a Beállítások oldalon látható első jelszó"). (2) §7 says the recovery-code bar comes „néhány perccel" after setup — measured ~15 min after enrolment (the off-site tier arrives with the agent's next 15-minute host report). (3) Nothing says to switch each app's off-site copy on (R-720). (4) §2 says a 2 GB USB stick and Rufus; the download page says at least 4 GB and Balena Etcher. (5) The operator part says no button is needed for the link (R-719), and §5 names the mail „Elindult a Felhom szervered" while a customer with an earlier box gets „Új beállító kód — újratelepült a szervered … A korábbi jelszavad már nem érvényes". Also, from the screens: the installer pre-selects `/dev/sda` (the guide says it never chooses), and its Summary screen rests on „Previous", not „Install". **Fix:** a guide edit; the operator approves the text. |**READY — rank P2-MEDIUM; owner: CC (text) / operator (approve)** |
| **R-723** | **[P3-LOW] A fresh box sends the operator two mails on day one that describe nothing wrong.** MEASURED 2026-09-29: `Operator email sent for tester-1/node_recovered` 2 s after the new box's first controller report (the customer's previous box had been silent 12 days — the new box is not a recovery); and `backup_tier_skipped (warning) — Whole-guest backup tier felhom-pbs skipped: its storage does not exist on the host (never provisioned or removed)` → operator mail at 19:27 UTC, 7 min after enrolment, because the first whole-guest run fired before the off-site tier's descriptor arrived (applied ~19:35 UTC, backed up fine at 19:37). Operator-only, so no household is alarmed, but an operator learns to ignore both. **Fix direction:**`node_recovered` not for a host enrolled < N min ago; the skipped tier inside the first hour after enrolment is `info`, not a mailed warning. |**READY — rank P3-LOW; owner: CC** |
| **R-724** | **[P3-LOW] The status pages disagree with each other in small ways a household notices.** MEASURED 2026-09-29 on a fresh box: Beállítások reads „Mentés ütemezés 02:30 / 03:00" while Biztonsági mentés says 02:30 / 03:30 / 04:15 / 04:30–08:30; Beállítások shows a raw `2026-09-29T19:22:30Z`; its „Helyi cím (LAN)" and „Átjáró" read „nem állapítható meg" on the page the household is asked to read out for remote help; the backups overview still says „Következő mentés — 0 órája" (the age of the LAST run, under the word "next" — noted 2026-09-14, never filed); the dashboard shows the backup at 19:33 where the backup pages say 21:33 (R-500, still reproducing). | **READY — rank P3-LOW; owner: CC** |
| **R-725** | **[P3-LOW] Small copy slips on the first-hour path.** MEASURED 2026-09-29: the self-bind PAGE says the passphrase was received „a beállításkor" while the mail and console say „a Felhom üzemeltetőjétől" (R-497 unified the mail and console, not the page); the recovery-code wizard addresses the household formally („Írja fel", „adja meg") while every other screen says „te"; the console's linked banner ends „a doboz össze van kötve. V" (a stray glyph); a gated app answers a phone app's API call with English JSON „this app is waiting for its first setup" (the browser gets the Hungarian gate page). | **READY — rank P3-LOW; owner: CC** |
| **R-719** | **[P2-MEDIUM] A customer who already exists never gets a fresh self-bind link when their new box registers: the last link expires in 7 days and nothing re-sends it.** MEASURED 2026-09-29 (new-household drill, `tester-1`): the previous link went out 2026-09-17 07:25 UTC at a host delete and expired 2026-09-24; the box registered at 19:11:30 UTC and its console told the volunteer to open the link from their e-mail — there was none that worked. Hub source: the link is sent at customer creation, RESET, e-mail set on a box-less customer and host delete (`selfbind_mint.go` callers `hosts.go:908`, `configs.go:850`, `customer_reset.go:162`) — never on appliance registration. The volunteer guide says the operator needs to press nothing. The operator pressed „Send self-bind link" (the mail arrived in 1 s) — an operator step the volunteer depends on, recorded, not an intervention. **Fix direction:** send the link when an unclaimed appliance registers while a box-less customer waits with no live link (R-509's first fix shape), or the guide's operator part says: press it the day the volunteer installs. Evidence: `audits/evidence-drill-new-household-2026-09-30/``phase0/operator-steps.txt`. **CHANGED AND BUILT 2026-09-30 (hub v0.126.0) — the brief's shape was not buildable:** a box registers UNCLAIMED (uuid, MACs, host keys, hardware — nothing of a customer), so "send the link when their box registers" would mail every waiting customer. Built instead: the expired AND used link pages offer „Új linket kérek" → a fresh link to the address registered for that link's customer, only when it has no box, ≤1/h per customer, identical answer for any token (no oracle). Live: the button on the real hub, the same page for a made-up token, no mail; the mint+send path unit-proven (RP42). Evidence: `audits/evidence-fixes-first-tester-2026-09-30/``partD/`. | **CLOSED 2026-09-30 — hub v0.126.0 (changed shape; operator may prefer another)** |
| **R-720** | **[P2-MEDIUM] A new household's apps are not in the off-site copy: every app starts with „3. mentés Kikapcsolva", and nothing the household is told says to switch it on.** MEASURED 2026-09-29 on a fresh box (customer with off-site ON, the default since 2026-09-16): `/backups/remote` read „Aktív — nincs kijelölt alkalmazás"; `/backups/apps` read „3. mentés Kikapcsolva — Ez az alkalmazás nincs kijelölve távoli mentésre" for all three apps. From source, an app is off-site only after `POST /backup/offbox/toggle` (`settings.SetAppOffbox`); no deploy or claim path sets it. The volunteer guide §7 says that after the recovery code „a távoli mentés magától elindul" — it starts, and copies nothing. So a household following the guide has **no off-site copy of its apps on night one**, on a one-drive box where the whole-guest tiers do not carry the data drive (`07` §6). The drill pressed „Bekapcsolás" for BookStack only, as a household reading the page might, to measure both paths on the night. R-240 (the empty run's wording) is the same gap seen from the other end. **Needs an operator decision** (it changes what the product promises): apps default to off-site ON when the customer has off-site, or the guide adds the step. **BUILT 2026-09-30 (controller v0.283.0, decision 50):** a fresh install on a box with off-site switches the app ON; older apps get one press on both backup pages; over the quota the page names the largest apps. Measured first: over the quota nothing but the ruled retention runs — no history is deleted (now pinned). Live on 9202: the press put both older apps ON; a fresh `glance` joined by itself. The size card is unit + parity proven (a household NAS target has no quota). Evidence: `audits/evidence-fixes-first-tester-2026-09-30/``partA/`. | **CLOSED 2026-09-30 — controller v0.283.0** |
| **R-721** | **[P2-MEDIUM] The household presses Stop during a whole-guest backup, and the backup starts the app again.** MEASURED 2026-09-29 19:37 UTC on a fresh box: the first off-site whole-guest backup quiesced three apps at 19:37:01; the household pressed „Leállítás" on actualbudget at 19:37:16 and the controller recorded `desired state for actualbudget recorded as "stopped"`; the same second the backup's early resume ran `unquiescing … restarting 3 stack(s)` and `Starting stack: actualbudget`. The app page then read „Fut" while `app.yaml` kept `desired_state: stopped` (so the next reboot would stop it). The household had to press Stop again, and the removal was refused „Az alkalmazáson mentés vagy visszaállítás fut" for ~4 min (honest). Evidence: `audits/evidence-drill-new-household-2026-09-30/``phase1/step10-stop-undone-by-quiesce.log`. **Fix direction:** unquiesce restarts only stacks whose desired state is still running; a test pins it (Stop during a quiesce → still stopped after the resume). **FIXED 2026-09-30 (controller v0.283.0 + v0.283.1):** the quiesce resume, the nightly volume dump, the update leg and the startup crash recovery skip an app the household stopped. **v0.283.0 was wrong in production** — its adapter did not answer the question and the dump restarted the app 8 s after the Stop (measured live on 9202); v0.283.1 wires it and pins the PRODUCTION types. Live on 0.283.1: `paperless-ngx NOT restarted after the volume dump: the household stopped it meanwhile`. Evidence: `audits/evidence-fixes-first-tester-2026-09-30/``partE/`. | **CLOSED 2026-09-30 — controller v0.283.1, proven live** |
| **R-722** | **[P2-MEDIUM] The volunteer guide is stale in five places a volunteer reads literally.** MEASURED 2026-09-29 walking `runbooks/VOLUNTEER-first-hour.md` on golden 0.282.0: (1) §8 says BookStack's login is `admin@admin.com / password` — since the random first password (controller v0.280.0) that login is REFUSED; the app page says the right thing („a Beállítások oldalon látható első jelszó"). (2) §7 says the recovery-code bar comes „néhány perccel" after setup — measured ~15 min after enrolment (the off-site tier arrives with the agent's next 15-minute host report). (3) Nothing says to switch each app's off-site copy on (R-720). (4) §2 says a 2 GB USB stick and Rufus; the download page says at least 4 GB and Balena Etcher. (5) The operator part says no button is needed for the link (R-719), and §5 names the mail „Elindult a Felhom szervered" while a customer with an earlier box gets „Új beállító kód — újratelepült a szervered … A korábbi jelszavad már nem érvényes". Also, from the screens: the installer pre-selects `/dev/sda` (the guide says it never chooses), and its Summary screen rests on „Previous", not „Install". **Fix:** a guide edit; the operator approves the text. **REWRITTEN 2026-09-30** (operator: CC rewrites as measured): both guides — BookStack's generated password on the app page, the ~15 min recovery-code delay, apps off-site by default + the one-press offer, a 4 GB stick, the returning customer's mail and the expired-link button, the pre-selected disk, focus on „Previous", and the auto-reboot (a sixth stale line: with the defaults the „reboot now?" prompt never appears). Operator part: set the e-mail language, check the domain's DNS for an earlier box's records, the tunnel route with No TLS Verify. Every changed line dated. | **CLOSED 2026-09-30** |
| **R-723** | **[P3-LOW] A fresh box sends the operator two mails on day one that describe nothing wrong.** MEASURED 2026-09-29: `Operator email sent for tester-1/node_recovered` 2 s after the new box's first controller report (the customer's previous box had been silent 12 days — the new box is not a recovery); and `backup_tier_skipped (warning) — Whole-guest backup tier felhom-pbs skipped: its storage does not exist on the host (never provisioned or removed)` → operator mail at 19:27 UTC, 7 min after enrolment, because the first whole-guest run fired before the off-site tier's descriptor arrived (applied ~19:35 UTC, backed up fine at 19:37). Operator-only, so no household is alarmed, but an operator learns to ignore both. **Fix direction:**`node_recovered` not for a host enrolled < N min ago; the skipped tier inside the first hour after enrolment is `info`, not a mailed warning. **FIXED 2026-09-30 (hub v0.126.0):** no `node_recovered` when the customer's host was enrolled after the outage began; `backup_tier_skipped` in a box's first hour recorded, not mailed. Real recoveries and old boxes' skips still mail (controls). Unit + red-proof (RP40, RP41); the live proof is Tester-2's first hour. | **FIXED — hub v0.126.0; live proof at the first real install; owner: CC** |
| **R-724** | **[P3-LOW] The status pages disagree with each other in small ways a household notices.** MEASURED 2026-09-29 on a fresh box: Beállítások reads „Mentés ütemezés 02:30 / 03:00" while Biztonsági mentés says 02:30 / 03:30 / 04:15 / 04:30–08:30; Beállítások shows a raw `2026-09-29T19:22:30Z`; its „Helyi cím (LAN)" and „Átjáró" read „nem állapítható meg" on the page the household is asked to read out for remote help; the backups overview still says „Következő mentés — 0 órája" (the age of the LAST run, under the word "next" — noted 2026-09-14, never filed); the dashboard shows the backup at 19:33 where the backup pages say 21:33 (R-500, still reproducing). **FIXED 2026-09-30 (controller v0.283.0):** Beállítások shows the real schedule and a local time; the dashboard's last backup is local time (R-500); „az előző N órája készült" replaces „0 órája". **NARROWED — remaining:** „Helyi cím (LAN)" / „Átjáró" read through the file-sharing container, so a box without it says „nem állapítható meg" — not a text fix (the read needs another path). | **NARROWED — the LAN/gateway read only; owner: CC** |
| **R-725** | **[P3-LOW] Small copy slips on the first-hour path.** MEASURED 2026-09-29: the self-bind PAGE says the passphrase was received „a beállításkor" while the mail and console say „a Felhom üzemeltetőjétől" (R-497 unified the mail and console, not the page); the recovery-code wizard addresses the household formally („Írja fel", „adja meg") while every other screen says „te"; the console's linked banner ends „a doboz össze van kötve. V" (a stray glyph); a gated app answers a phone app's API call with English JSON „this app is waiting for its first setup" (the browser gets the Hungarian gate page). **FIXED 2026-09-30:** the recovery wizard speaks „te" (controller v0.283.0; formal ceiling 18 → 17); the bind page says „a Felhom üzemeltetőjétől kaptál" (hub v0.126.0). **NARROWED — remaining:** the console's stray „V" (the installer/agent's banner, not these repos' text); the gate's English JSON to a phone app (the app shows its own error; left, deliberately); and the expired bind page still says „kérj újat az ügyfélszolgálattól" ABOVE the new „Új linket kérek" button (hub copy, next hub release). | **NARROWED — three small copy items; owner: CC** |
| **R-726** | **[P2-MEDIUM] A new box for a customer who had one before makes NO off-site copy on night one: the old repository is found orphaned, and the fix is a button nobody pointed the household to.** MEASURED 2026-09-30 00:15 UTC on the new-household drill box (`tester-1`, whose previous box was deleted 2026-09-17): `[offbox] offsite repo ORPHANED — remote holds backups written under a previous, no-longer-available key; runs will skip until reset` → `offbox_repo_orphaned` (warning) to the household's timeline and an operator mail; `offsite-integrity` then checked nothing. The household's page is honest („A távoli tároló másik kulccsal készült mentéseket tartalmaz … Új távoli mentés indítása…", old history set aside, never deleted), but the evening before, the recovery-code ceremony and the off-site page raised nothing, and the guide does not mention it. The hub re-issued the off-site credentials on re-enroll by itself; it could have known the repository would orphan. Customer data was never at risk (the old repository is untouched); the household simply has no off-site copy until someone presses the button. **Fix direction:** offer the reset at the recovery-code ceremony when the repository already holds another key's snapshots, or the hub's re-enroll re-issue sets the old history aside the same way (it is the same move-aside), and the guide says so. | **READY — rank P2-MEDIUM; owner: CC (design first) / operator (which)** |
| **R-727** | **[P2-MEDIUM] The whole-guest restore test picks a PREVIOUS box's archive, fails on its key, and the household sees a bare ✗ labelled with the wrong tier.** MEASURED 2026-09-30 01:52 UTC on the drill box: the agent's restore test chose `felhom-pbs:backup/ct/9201/2026-09-16T21:59:54Z` („newest settled archive … has not been proven") — written by a drill box of 2026-09-16, still in the customer's ep0 namespace next to tonight's own `2026-09-29T19:37:07Z` — and failed `wrong key - unable to verify signature since manifest's key 6b:ca:5f:3f… does not match provided key de:51:7a:18…`. One operator mail (`restore_test_failed`); the hub then re-logged the stored failure at every 15-minute report for 5 hours. The household's backups page read „✗ Visszaállítás ellenőrizve 2026-09-30 03:52 — Helyi tároló (local)" — the local tier had not failed; the pbs tier had, and the page says neither which nor why. Root: host delete leaves the old box's archives in the namespace (R-526's shape). **Fix direction:** the restore test skips (and reports as foreign) archives whose key fingerprint is not this host's; the page names the tier that failed. |**READY — rank P2-MEDIUM; owner: CC** |
| **R-727** | **[P2-MEDIUM] The whole-guest restore test picks a PREVIOUS box's archive, fails on its key, and the household sees a bare ✗ labelled with the wrong tier.** MEASURED 2026-09-30 01:52 UTC on the drill box: the agent's restore test chose `felhom-pbs:backup/ct/9201/2026-09-16T21:59:54Z` („newest settled archive … has not been proven") — written by a drill box of 2026-09-16, still in the customer's ep0 namespace next to tonight's own `2026-09-29T19:37:07Z` — and failed `wrong key - unable to verify signature since manifest's key 6b:ca:5f:3f… does not match provided key de:51:7a:18…`. One operator mail (`restore_test_failed`); the hub then re-logged the stored failure at every 15-minute report for 5 hours. The household's backups page read „✗ Visszaállítás ellenőrizve 2026-09-30 03:52 — Helyi tároló (local)" — the local tier had not failed; the pbs tier had, and the page says neither which nor why. Root: host delete leaves the old box's archives in the namespace (R-526's shape). **Fix direction:** the restore test skips (and reports as foreign) archives whose key fingerprint is not this host's; the page names the tier that failed. **FIXED 2026-09-30 (agent v0.138.0 + decision 51):** measured — a PBS archive carries its key FINGERPRINT (PVE content `encrypted`), not a host id; the storage carries its own (`encryption-key`). The restore test skips an archive written with another key (logged by name). The ✗ card names the tier (controller v0.283.0) — **and the 2026-09-30 claim "the page blames the local tier" was my misreading**: the „Helyi tároló (local)" after the ✗ was the next section's heading. ep0: the three drill archives in `tester-1` removed, other namespaces byte-identical. Delivered by signed jobs to both demo boxes (340 s); their due-check reads normally on 0.138.0. Evidence: `audits/evidence-fixes-first-tester-2026-09-30/``partC/`. | **CLOSED 2026-09-30 — agent v0.138.0** |
| **R-728** | **[P3-LOW] A customer created with one press was created TWICE, and the first of its two connect mails holds a dead link.** MEASURED 2026-09-30 on `Tester-2`: the hub logged `Customer config created: Tester-2` twice in the same second and two self-bind mints (hashes `c40df008…`, `6a1cbef4…`); a mint replaces the previous link (single-active), so one of the two identical mails the tester received answers „expired". Cause not established (a double form submit, or the handler run twice). **Fix direction:** make the create idempotent within a few seconds (or disable the button on submit), and pin it. The workaround for the tester is in STATUS. | **READY — rank P3-LOW; owner: CC (hub)** |
| **R-729** | **[P3-LOW] An off-site target, once saved on the page, cannot be removed through the product.** MEASURED 2026-09-30 on 9202: `/backup/offbox/config` refuses an empty address and no route clears the target; the session removed its throwaway target from `settings.json` by hand, with the controller stopped (harness teardown on a scratch guest). A household that tries its own NAS and gives up keeps a disabled target forever. **Fix direction:** a „Távoli mentési cél törlése" press that clears the target (never the repository). | **READY — rank P3-LOW; owner: CC (controller)** |
<!-- DUE-CHECKS-BEGIN — machine-readable. Parsed by scripts/due_checks_gate.py.
One row per dated check. The R-number must have a row above. Dates are UTC.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
