felhom.eu/documentation/audits/evidence-bignight-2026-09-14/journal.md

Journal — BIGNIGHT 2026-09-14 (a household's first month in one night)

Times UTC unless marked. Hub logs print CEST (UTC+2). Brief: drills/BIGNIGHT-2026-09-14.md.

Phase 1 — baselines (read 17:29–17:40Z from live source)

repo	main == origin/main	version
felhom-controller	406755fa8fba	v0.242.0 (CHANGELOG top)
felhom-agent	4586f0f7f6d1	v0.130.0 (tree: one untracked scripts/__pycache__/, no tracked change)
felhom.eu	a4d684412b49	hub v0.113.0 (CHANGELOG top; live image felhom-hub:0.113.0)
app-catalog-felhom.eu	6d6eec307939	—

Register: highest id R-508; 221 table rows (grep ^| R-n).

ISO 1.27.1: /mnt/5_hdd/felhom.eu/felhom-iso/out/felhom-installer-1.27.1-pve9.2-1.iso, 1 705 322 496 B, sha256 25637007d5a7120ff9faa6b5b7ead3e33c0a361ac2d67e9fd4e0ee77c034c053 = .sha256 = manifest output-sha256; manifest repo-commit 27e8ec86…, mode release, answer-file NONE. Found, not rebuilt.

DooPlex headroom: /mnt/5_hdd 37 %, / 52 %.

demo-hp (17:29Z): qm list empty; 9201 + 9202 running (each memory: 25898, cores: 7); host RAM 29 994 MB total, 24 652 MB available; 8 threads (Ryzen V1756B); storages local 56.96 %, local-lvm 44.17 %, nvme-scratch (dir /mnt/hdd_1, is_mountpoint yes) 1.03 %.

Gmail connector: authenticates as felhom.eu@gmail.com — the catch-all for @felhom.eu (threads to admin@felhom.eu and drill0242@felhom.eu land there). Read only; nothing sent.

Phase 1 — the Tester 1 record (hub GET /customers/tester-1, Basic auth, 17:30Z)

Customer ID tester-1 · Name „Tester 1" · Domain enkicsifelhom.hu · Email tester1@felhom.eu · Config MANAGED. Status tile still reads down, „Last report 1h ago · Controller 0.242.0" — the stale report of the destroyed VM 331 (host record deleted 16:46:52Z). Claim: „Claimed 1h ago · generation 1". Edit tab: dr_tier ON (all four DR steps „waiting — no host enrolled yet"); offsite_enabled OFF („Enable offsite (provisions a Hetzner Storage Box on save)"). Controller floor v0.242.0. Mailbox: to:tester1@felhom.eu → 0 threads before tonight.

Brief vs record — off-site. The brief says "Off-site (Tier 3) is ON … its own namespace on ep0". On the record, the ep0 namespace is the DR tier (PBS whole-guest); the Tier-3 restic off-site is OFF, and turning it on provisions a Hetzner Storage Box (money, and a new external resource). Not followed: I do not tick it — money is fenced by the rules file §1. "Off-site" tonight = the DR tier to ep0 as configured. Consequence, stated up front: the Phase 4 off-site integrity check and the Phase 6 app restore "from off-site" have no restic tier to act on; each is recorded as such when reached.

Harness slip: the first read of the customer page printed the page's text into this session's tool output, which includes the customer's hub API key (not the retrieval passphrase — that is masked). It stayed on DooPlex; not written to any file.

Tunnel before any box (17:31:19Z, from DooPlex) — tunnel-before-no-box.txt

DNS resolves to Cloudflare (both resolvers); https://felhom.enkicsifelhom.hu → 530, error code: 1033 (no connector). Expected with no box.

Venue — VM 333 bignight-household on demo-hp (created 17:31:52Z)

q35 / OVMF (pre-enrolled-keys=0), 4 cores, cpu=host, 16 384 MB, virtio NIC BC:24:11:F2:E2:95 on vmbr0, scsi0 200 G qcow2 on nvme-scratch (dir at /mnt/hdd_1, its root), ISO 1.27.1 on ide2 (sha verified on the HP = 25637007…). One disk at install; the data disk is added after.

Why these numbers. System disk = doorstep VM 331's 200 G. Memory: the HP has 29 994 MB; 9201 and 9202 together used ≈ 5.3 GB at 17:29Z with 24 652 MB available. Both LXCs carry a 25 898 MB limit, so no VM size leaves both limits whole; 16 GB leaves ≈ 8 GB free plus 8 GB swap for 9201's real load. Cores: the 0242 drill's 4 of 8 threads.

Power-on 17:32:13Z. GRUB (s01, s02): the two Felhom entries; text mode chosen (H4).

Phase 2.1 — install from 1.27.1 (text mode), one disk

UTC	screen	what it said / what was done
17:34:5x	s03	English Proxmox EULA → „I agree"
17:35:11	s04	„Target harddisk: /dev/sda (QEMU HARDDISK) (200.00 GiB)" — one disk, no choice to make → Next
17:35:24	s05	Country Hungary · Timezone Europe/Budapest · Keyboard layout Hungarian (H2: changed to U.S. English, s06–s09; one dropped keystroke landed on „Turkish" first, corrected)
17:37:00	s11	„Root password [at least 8 characters]" · Confirm · „Administrator email" prefilled mail@example.invalid → 20-char generated password (0600 file on DooPlex), tester1@felhom.eu (the guide: „a saját e-mail címedet")
17:39:01	s13	nic0 bc:24:11:f2:e2:95, virtio_net · Hostname pve.example.invalid · IP 192.168.0.136/24 (the DHCP lease, frozen static) · GW 192.168.0.1 · DNS 192.168.0.250 · „[X] Pin network interface names" → hostname set felhom.enkicsifelhom.hu per the guide (s15)
17:40:36	s16	Summary: ext4 · /dev/sda · Europe/Budapest · U.S. English · tester1@felhom.eu · nic0 · felhom.enkicsifelhom.hu · 192.168.0.136/24 · 192.168.0.1 · 192.168.0.250 · „[X] Automatically reboot after successful installation" (H3: unticked, s17)
17:41:02	—	Install pressed
≤17:43:47	s18	„Success — Installation finished - reboot now?" (≤ 2 m 45 s copying; qcow2 4 058 MB, settled)
17:44:xx	first boot	H3: qm stop, --delete ide2, --boot order=scsi0, qm start

Seeds prepared on DooPlex (scratchpad, tmpfs): 200 JPEG 1600×1200 noise + caption (264 MB), 20 three-page PDFs (2.3 MB), a 50 MB random file, a 150 s 1280×720 H.264 video (98.9 MB).

Phase 2.2 — first screen, and waiting for the mail

17:44:53Z — hub lists Unclaimed appliance 28 (38 s after power-on): smbios uuid 1ecd1c40…, pairing code ***-*** (redacted), MAC bc:24:11:f2:e2:95, „Standard PC (Q35 + ICH9, 2009)", 15.6 GB, three SSH host keys. Bind list offers „Tester 1 (0 hosts)".

The console, 17:45:31Z (s19, code redacted), verbatim:

  Felhom otthoni szerver

  Ezen a gépen most nincs dolgod, és bejelentkezni sem kell.
  A beállításhoz kövesd a Felhomtól kapott útmutatót.

felhom login:
==============================================
  Felhom — a doboz készen áll, és a párosításra vár.

  Párosító kód:  ***-***

  Nyisd meg az e-mailben kapott linket, és add meg
  ezt a kódot és a Tulajdonosi jelmondatodat
  (az 5 szót a Felhom üzemeltetőjétől kaptad).

  Ez a képernyő magától frissül — nincs teendő a
  doboznál, és nyugodtan itt hagyhatod bekapcsolva.
==============================================

No Proxmox :8006 line on the first boot (the 1.27.1 fix holds on a fresh install). Text says „otthoni szerver"; the guide §3 quotes „Ezen a képernyőn nincs teendőd" — the guide's quote does not match the screen word for word (meaning is the same).

Mailbox, 17:46Z: to:tester1@felhom.eu → 0 threads. The console asks for „az e-mailben kapott linket". Hub source: the self-bind link is auto-sent only at customer creation (configs.go:725) and at RESET completion (customer_reset.go:162); tester-1 was created 32 days ago with no e-mail, so no link was ever sent to tester1@felhom.eu. Waiting the brief's 10 minutes (to 17:55Z) before acting.

17:55:11Z — ten minutes, 0 messages to tester1@felhom.eu. Filed R-509 (P1) at 17:56Z, before acting. Intervention I1: the operator's „Send self-bind link" button on the customer's Setup tab is pressed (a volunteer cannot press it).

17:55:42Z POST /customers/tester-1/selfbind-link → 303 flash=selfbind-sent; hub: self-bind link (hash effe179d…, valid 7 days) emailed to the registered address of tester-1.

The mail, as the volunteer reads it (Gmail connector, message 1a0a10f8cd07d8f6, Date 17:55:43Z — 1 s after the press; Gmail threads it under the older drill0242 mail of the same subject, a mailbox quirk):

[Felhom] Kösd össze a Felhom dobozodat — from monitoring@felhom.eu to tester1@felhom.eu

Kedves Ügyfél! Elkészült a Felhom dobozod, és készen áll az összekötésre. Az alábbi hivatkozáson tudod te magad összekötni a fiókoddal — nincs szükség bejelentkezésre: https://hub.felhom.eu/bind/<64 hex, redacted> A hivatkozás megnyitása után két adatot kell megadnod:

1. A párosító kódot, amely a doboz képernyőjén (a monitoron) látható.
2. A tulajdonosi jelmondatodat (az 5 szóból álló kifejezést), amelyet a Felhom üzemeltetőjétől kaptál — személyesen vagy telefonon, e-mailben soha. Ez igazolja, hogy a fiók a tiéd. A hivatkozás 7 napig érvényes. Biztonsági okból 5 sikertelen próbálkozás után zárolódik — ilyenkor vedd fel a kapcsolatot az ügyfélszolgálattal. Ha nem te kérted ezt, hagyd figyelmen kívül ezt az e-mailt. Üdvözlettel, Felhom.eu

The Tulajdonosi jelmondat is taken from the hub customer page into a 0600 file (the operator's hand-over, per the guide's prerequisite 3 — not a volunteer act, not counted).

Phase 2.2 (cont.) — following the link (the self-bind page, first time exercised by any walk)

17:56:11Z GET https://hub.felhom.eu/bind/<token> → 200 (screen-bind-page.txt), verbatim: „Felhom — Doboz összekötése" · „Kösd össze a most telepített Felhom dobozodat a fiókoddal. Add meg a doboz képernyőjén látható párosító kódot és a tulajdonosi jelmondatodat." · Párosító kód („A doboz monitorán jelenik meg, a telepítés után.", placeholder ABC-234) · Tulajdonosi jelmondat („Az öt szóból álló kifejezés, amelyet a beállításkor kaptál.", placeholder „öt szó, kötőjellel vagy szóközzel") · Összekötés · „Biztonsági okból 5 sikertelen próbálkozás után a hivatkozás zárolódik. …"

Observation: the page still says the phrase was received „a beállításkor" (at setup); the mail (hub v0.113.0) says „a Felhom üzemeltetőjétől kaptál — személyesen vagy telefonon". Two wordings for one hand-over.

17:56:29Z POST /bind/<token> (pairing code + Tulajdonosi jelmondat) → 200 (screen-bind-result.txt): „Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan elérhető lesz." The self-bind link works end to end — first time any walk exercised it. One try, no error.

Hub (CEST): 19:56:30 self-bind SUCCESS: appliance 28 bound to customer tester-1 by customer self-service · 19:56:47 credentials DELIVERED once · 19:57:23 host enrolled: tester-1-a61396 · 19:57:24 [claim] reenroll code (gen 2) emailed … reset code re-issued (gen 2) for tester-1 on box re-enrollment (clean-slate reinstall) · 19:57:25 manifest agent 0.130.0 golden 0.242.0 · 19:57:42 wg registered … ip=10.77.0.5/32 · 19:57:42 [ERROR] pbsdr auto-provision for tester-1 (WG-registration hook): the endpoint already holds a PBS token for tester-1 but the hub has no descriptor — use the explicit "Re-issue PBS credentials" action · 19:59:06 controller_started (info) — Controller elindult (0.242.0) · 19:59:43 tester-1 down → ok. Console after bind (s21, codes redacted): the pairing banner is printed three times with the same code; it never changes to "bound" (R-214 class).

Which claim path — the brief asked "fresh claim or reset flow". Neither a fresh claim nor the RESET: the hub treated the box as a re-enrolment of a claimed customer and sent the reinstall mail (gen 2). Quoted (Gmail 1a0a111205fa7fe8, 17:57:24Z, 54 s after the bind):

[Felhom] Új beállító kód — újratelepült a szervered Kedves Ügyfél! A Felhom szervered újratelepült, ezért a vezérlőpultod belépését újra be kell állítani. A korábbi jelszavad már nem érvényes. Beállító kód: <3 words, redacted> A kód 72 óráig érvényes, és egyszer használható fel. Nyisd meg a vezérlőpultot — "A szerver beállítása" oldal fogad —, add meg a kódot, majd válassz új jelszót: https://felhom.enkicsifelhom.hu Ha nem te telepítetted újra a szervered, vedd fel a kapcsolatot az üzemeltetővel.

For a volunteer on their first box this mail is wrong in two places: the guide §5 tells them to look for „Elindult a Felhom szervered — beállító kód", and this one says their server was reinstalled and their previous password no longer works — a password they never had. A careful stranger reads „Ha nem te telepítetted újra … vedd fel a kapcsolatot" and stops. (Cause: the record was claimed once today by VM 331.)

Tunnel after bind, before claim — 18:07:48Z from DooPlex (tunnel-after-bind.txt): 502 ×3 (server: cloudflare, body error code: 502). Changed from 530/1033 (no connector) to 502 (connector present, origin failing).

Phase 2.4 — the gate: the dashboard through the tunnel — FAIL (P1)

box-logs-phase2/cloudflared-before-claim.txt, tunnel-origin-diagnosis.txt. Guest 9201 on the box: 192.168.0.150; containers felhom-controller:0.242.0 (healthy), traefik:v3.6.7, cloudflared:2026.6.0, filebrowser 1.3.3-stable. cloudflared: 4 connections registered (17:59:02Z, vie06 …), pre-checks all PASS. Then every request: Request failed … tls: failed to verify certificate: x509: certificate is valid for 544346c4….traefik.default, not traefik … ingressRule=0 originService=https://traefik. Traefik on 127.0.0.1:443 with SNI felhom.enkicsifelhom.hu serves CN=*.enkicsifelhom.hu, Let's Encrypt YR1, valid 2026-09-14 17:01 → 12-13 — the right certificate exists. Control (demo-hp 9201, read only): its route {"hostname":"*.enkisfelhom.hu","originRequest":{"noTLSVerify":true},"service":"https://traefik"}. Conclusion: the operator's route reaches the box now (530 → 502) but lacks „No TLS Verify". Filed R-510 (P1) at 18:1xZ before acting. Intervention I2: from here the claim and all dashboard traffic go to 192.168.0.150:443 with the name forced (--resolve), from DooPlex on the same household LAN as the box.

Phase 2.2 (cont.) — the claim, with the mailed code (I2 route)

screen-claim-page.txt. 18:10:06Z GET / → 302 /claim; the page: „A szerver beállítása — Tester 1 — Add meg az e-mailben kapott beállító kódot, majd válassz saját jelszót a vezérlőpult védelméhez." · Beállító kód · Új jelszó (min. 12 karakter) · Új jelszó megerősítése · Beállítás és belépés · „Nem kaptad meg a kódot? Új kód kérése". (The page does not mention the reinstall the mail talked about — the two agree on the code, not the story.)

Harness slip: the first POST /claim (18:10:06Z) sent both of the page's _csrf values joined (two forms, two tokens) → 200 „Érvénytelen űrlap — töltsd újra az oldalt." (form refused, not a code attempt). Re-fetched, one token.

18:10:28Z POST /claim (the mailed code, a generated 24-char password twice) → 302 / + felhom_session. The mailed setup code works — first walk to use the real mail instead of a box-printed code. /launcher 200: „Indítópult — Felhom.eu", tile Filebrowser, sharing off; menu Vezérlőpult · Alkalmazások · Tárhely (Meghajtók, Hálózati tárhely) · Biztonsági mentés (Áttekintés, Távoli mentés, Alkalmazások, Visszaállítás) · Megosztás (Hálózati megosztás) · Rendszermonitor · Debug · Beállítások (Rendszer, Értesítések, Biztonság és hozzáférés) · 0.242.0.

Power-on → claimed dashboard: 38 m 15 s (17:32:13 → 18:10:28), of which 10 min were the brief's mail wait.

Phase 2.3 — version

Box: felhom-controller:0.242.0 (healthy), felhom-agent 0.130.0. Hub: „Controller 0.242.0 · Registry latest v0.242.0 — up to date · Effective floor v0.242.0 — at/above floor". PASS — landed on golden 0.242.0, reports current, no self-update needed (golden == floor). Bind → controller_started 2 m 36 s.

Phase 2.4 — the gate after the claim — FAIL, still R-510

tunnel-after-claim.txt: 18:10:41Z from DooPlex https://felhom.enkicsifelhom.hu/login → 502 ×6; box cloudflared at 18:10:42Z: the same x509 … traefik.default, not traefik for each. Continued on the LAN address (I2).

Phase 2.1 (cont.) — the data disk (100 G scsi1, hot-attached 17:46:42Z, before the bind)

• Box lsblk: sdb 100G disk, no partitions.
• Dashboard (screen-storage-dashboard-after-claim.txt): „Lemezek állapota — QEMU QEMU HARDDISK · Nincs adat · 0 °C" (one line, which disk is not said); nothing mentions a new disk.
• Tárhely → Meghajtók: „Nincs regisztrált adattároló. Adjon hozzá egyet az alábbi űrlappal." · „Új meghajtó inicializálása" · „Meglévő meghajtó csatolása" · „Nem regisztrált meghajtók — az ügynök által észlelt, még nem regisztrált adatmeghajtók" · „Rendszermeghajtók — védett …" · „Már csatlakoztatott tárhely hozzáadása kézzel — Elérési út — Pl. /mnt/hdd_1 …". Formal „Adjon" (the rest of the product says „te").
• GET /api/disks/candidates: initialize: [/dev/sdb 107374182400 B, QEMU HARDDISK, data_bearing false]; attach: [/dev/mapper/pve-vm--9201--disk--1, mount_source /mnt/sys_drive, already_mounted true] (the guest's own system volume offered for attach — observed in the 0242 drill too).
• Would a household know to enrol it? No. Nothing on the dashboard, the launcher or any mail says a disk appeared; the volunteer guide has no step for it; the page that lists it is two menus deep and speaks of „inicializálás" and „ügynök". A volunteer who plugs in a second disk has to go looking.

The DR tier on this box — stuck (operator act O1, not a customer step)

Hub 19:57:42 CEST: pbsdr auto-provision … the endpoint already holds a PBS token for tester-1 but the hub has no descriptor — use the explicit "Re-issue PBS credentials" action. 18:11:57Z operator POST /configs/tester-1/ pbsdr-reissue → 400 No provisioned PBS DR tier for this customer. Neither path provisions it. Filed R-511 (P2). Not forced further: removing the old ep0 token is a destructive act on ep0 tenancy, and RESET would also remove the tunnel (fenced by the brief: the customer is kept). Consequence for tonight, stated once: this box has no off-site tier of either kind — restic Tier-3 is off (money) and the PBS DR tier cannot provision. Nothing is written to ep0 tonight. Phase 4's off-site integrity check and Phase 6's restore „from off-site" are recorded as not possible when reached, with the local tiers walked instead.

No „A vezérlőpultod mostantól jelszóval védett" mail arrived for the claim (the 0242 drill's box received one at 13:31:23Z, 12 s after its claim); at 18:12Z the mailbox holds only the bind mail and the reinstall mail.

Phase 2.1 (cont.) — enrolling the data drive, as a household could from the screens

18:12:57Z POST /api/storage/init (the „Új meghajtó inicializálása" wizard's call) {device /dev/sdb, ext4, mount_name hdd_1, label Adatlemez, set_default true} → formatting → done at 18:12:59Z (2 s), where /mnt/felhom-drives/hdd_1 (drive-init.txt). The wizard's „Csatlakoztatási név" field has no value, only the placeholder hdd_1 — a person must type a name. Tárhely now: „Adatlemez · /mnt/felhom-drives/hdd_1 · Alapértelmezett · Aktív · 0.0 GB / 97.9 GB · ext4 · /dev/sdb[/felhom-data] · QEMU HARDDISK · Nincs alkalmazás ezen a tárolón". /api/disks: role user-data, durable id uuid:c4b530fd….

Phase 2 evidence pulled off the box 18:14Z: box-logs-phase2/ (bootstrap + agent journals, controller log, box state, cloudflared). Secret patterns searched (passphrase=|retrieval_password|password:): 0 hits.

Phase 2 interventions: 2

• I1 (R-509): the self-bind mail never came for an existing customer; the operator's send button was pressed.
• I2 (R-510): the tunnel answers 502; claim and dashboard over the LAN address with the name forced. Operator acts that are prerequisites, not counted: passphrase hand-over; PBS re-issue attempt (O1, refused).

Phase 3 — a family moves in (phase3/)

Deploy pages captured before any deploy (phase3/deploy-pages-before.txt); the memory line each showed at 18:14Z with 3 infra containers running: bookstack 1525 / 11444 MB · docmost 1568 · privatebin 1404 · gokapi 1408 · nextcloud 1633 · immich 3422 · vaultwarden 1427 · paperless-ngx 1880 · jellyfin 1892 · mealie 1578 · uptime-kuma 1431 · adventurelog 1476 (guest limit 11 444 MB of the VM's 16 GB). Every deploy goes through the page's own call, POST /api/stacks/<app>/deploy {"values":…} with the form's server-generated values; a required empty password (gokapi, nextcloud admin) is typed as a customer would — a generated value in a 0600 file.

app	deploy	seed through the front door	household use
bookstack	18:14:35 → running 80 s	default login → admin e-mail + password changed (old default refused); book „Családi tudástár BIGNIGHT"; 5 Hungarian pages (Töltött káposzta, Wifi jelszó helye, Kutya oltási naptár, Nyaralás Balaton 2026, Autó szerviz); 2 attachments 256 KiB + 512 KiB, sha equal ×2	2nd user „Kovács Péter" (Editor) created, logs in, edits Balaton page (edit visible); Péter's attachment upload returned an HTML page, not JSON — inconclusive (harness: page id hard-coded); Anna deletes „Kutya oltási naptár" → 404 → recycle bin → restore → 200 with its text
docmost	18:16:10 → running ≈ 90 s	/api/auth/setup workspace „Kovács család"; space „Háztartás"; 5 docs via Markdown import (titles taken from each file's # heading: Rezsi, Iskola, Lista, Orvos, Kert); read back „ELMŰ", „árvíztűrő" present	renamed „Bevásárlólista — szombat"; deleted „Kert" → trash → restored → listed; invited peter@ (200)
privatebin	18:18:2x → running 15 s	5 encrypted pastes (browser v2 format): 1week, never, 1month, never, 10min (the expiring one); every one decrypts equal; TTL meta 604800 / [] / 2592000 / [] / 600. Harness: PrivateBin's 10-second post limit refused one post (status 1), retried	— (file-only; pastes are the use)
gokapi	18:18:43 → running 20 s	deploy page asks „Admin jelszó *" (customer types it); login admin; 3 uploads via the dropzone's chunk calls: 50 MB (2 chunks, 1.6 s), a PDF, a JPEG; admin lists 3	a stranger downloads all three, sha equal ×3; the PDF deleted through the UI's API → its link no longer serves it (78-byte page)

App pages: „Fut · Naprakész" (title „Ez az alkalmazás a legfrissebb elérhető változatot futtatja."). Gokapi's password: app page „Első lépések" says „a jelszó a Beállítások oldalon található"; Beállítások shows „Admin jelszó 👁 — Telepítéskor beállított kezdeti jelszó — ha az alkalmazásban megváltoztattad, az itt nem frissül." Findable. BookStack page „Első lépések": „Nyisd meg a wiki.DOMAIN címet" (R-498, still).

nextcloud 18:20:14 deploy (HDD_PATH offered: „Adatlemez — 92.9 GB szabad (alapértelmezett)") → +50 s starting → +121 s unhealthy (the harness stopped polling there — its own mistake) → at 18:23:43Z running, all three containers (healthy). So the card reads „unhealthy" for a while on a first start; recorded as observed, not a defect.

nextcloud seed (WebDAV, 4 parallel, as the admin the deploy page asked for): folders Fotók/Balaton 2026, Számlák, Közös mappa; 200 JPEG + 20 PDF, 220 × 201, 86 s (264 MB of photos); 2nd user „peter" (OCS 100), „Közös mappa" shared with him (OCS 200); Péter uploads into it and Anna reads it back (sha equal); foto-123 read back sha equal. Household use: a child deletes foto-007 (204 → 404); trashbin lists it; restore (201); photo back, sha equal. Admin used 343 161 297 B. Nextcloud 34.0.1.

immich 18:22:57 deploy → +116 s degraded → +126 s starting … (continues below).

immich running after 146 s (degraded 116 s on the way). Seed through its API: admin sign-up (201), 200 JPEG uploads, 200 × 201 in 16 s; stats photos 200, 275 682 444 B; ML queues draining (faceDetection / smartSearch / ocr).

vaultwarden 18:25:37 → running 15 s. Seed with the Bitwarden client crypto (PBKDF2 600 000, AES-CBC + HMAC): register (200), token (200), 10 login entries (200 × 10), /api/sync → 10 items, all names decrypt to the originals. Attachment: the v2 slot's returned url is /ciphers/<id>/attachment/<id> — posting it to the web root 404s, under /api 200 (a client detail, the harness's first try left one empty attachment slot on „Ügyfélkapu+"). The retried attachment downloads 200 with its recorded size; byte-equality not proven (harness lost the key). Finding R-512 (P2): registration stays open and the page's instruction to close it points at a read-only field; a stranger registered with no invite (200).

SECURITY — R-513 (P1), found 18:30Z while looking for a way to put a video on the drive

The launcher's Filebrowser tile opens files.enkicsifelhom.hu: password login, no signup. No screen gives the customer a FileBrowser login. A customer's first guess, admin / admin, works (200 + token); wrong password 401. With it, both sources list (Adatlemez → documents, …; Beolvasás → paperless). The same login works on demo-hp's 9201 and 9202, and 9201's login page answers 200 through Cloudflare from the internet (GET only, no login attempted remotely). Filed R-513 before anything else; nothing changed on any box.

immich (cont.) ML queues empty at 18:32:09Z (≈ 6 min after upload); asset 42 original read back sha equal.

paperless-ngx 18:27:xx deploy → running. Token with the deploy-generated admin password (the app card's „admin / admin" is not what was set — the form generates a 16-char password). Tags Számla / Garancia / Adó (201 ×3); 20 PDFs posted 18:29:57Z → 0 documents. Kernel: the container's cgroup OOM-killed gs and the celery worker at 18:31:22Z; tasks 11 FAILURE (WorkerLostError) · 1 STARTED · 8 PENDING, unchanged at 18:44Z. App still „Fut". R-514 (P2).

jellyfin 18:29:34 → running 50 s. Startup wizard through its REST calls (Hungarian UI culture, user „anna"), login 200; libraries none; the container sees /media/{audiobooks,books,comics,movies,music,photos,podcasts,tv} (the drive's userdata/media, read-only).

mealie → running 85 s. The card's default login changeme@example.com / MyPassword works (200); password changed (old now 401); 5 Hungarian recipes with ingredients + steps (201/200 ×5); meal plan 15–19 Sept (201 ×5) reads back all five; Gulyásleves reads back its accents.

uptime-kuma → running 50 s. Its socket.io endpoint answers the polling transport with the SPA page (websocket only); DooPlex has no websocket library — a raw client is written next.

uptime-kuma (cont.) The first screen of a fresh Uptime Kuma 2.4 is an English „Which database would you like to use?" page (SQLite / Embedded MariaDB / …, „Next") — the controller's card says nothing about it; the socket API is not up until it is answered. SQLite chosen through its own call (POST /setup-database → {"ok":true}), then over a websocket: setup „anna" (successAdded), login ok, 3 monitors (the box's own dashboard, the family wiki, the router by ping). Heartbeats after 90 s: router UP (0.5 ms); dashboard and wiki DOWN — „Request failed with status code 502": from inside the box, its own public names go out to Cloudflare and hit R-510. A household that adds its own apps as monitors gets red for every one.

jellyfin media via the product's own route — „Hálózati megosztás" (SMB): enable (303 „Beállítás mentve…"), password (first try used wrong field names → „legalább 8 karakter" flash, harness; second 303 „Megosztási jelszó beállítva"), share „Filmek" = existing folder userdata/media/movies (303 „A megosztás létrehozva."). State „fut"; list shows beolvasas (rendszer) and Filmek (Felhőmentés bekapcsolva). From demo-hp on the LAN (a household laptop): smbclient //192.168.0.150/Filmek -c put 98 898 905 B in 2.6 s. The drive root itself is refused for sharing („Ez a mappa nem osztható meg.").

jellyfin (cont.) the video, copied through \FELHOM\Filmek, is visible inside the container at /media/movies/Csaladi-nyaralas-2026.mp4; library „Családi videók" (movies, /media/movies) added (204); the scan finds „Csaladi-nyaralas" (RunTimeTicks 1 500 000 000 = 150 s) in 5 s; static stream of the first MiB → 206, 1 048 576 B.

adventurelog → running 161 s. Account creation took five harness attempts (evidence kept in order): the headless /auth/browser/v1/auth/signup through the frontend refuses without a usable CSRF token (the frontend clears csrftoken on every response); the backend's own /accounts/signup/ form works (302) — a household would use the frontend's sign-up page, which this harness did not drive. Then the frontend login form (POST /login) → sessionid (Domain .enkicsifelhom.hu) and through it: collection „Balaton 2026 nyár" 201; Tihany, Badacsony, Keszthely 201 with a visit each 201; Badacsony edited (rating 4) 200; read back 3 locations with their visits. Photos: 502 then 500 — see below. (An anonymous POST to /api/collections/ makes the backend raise ValueError … AnonymousUser → 500: the app's own behaviour, noted, not filed.)

Version labels (phase3/version-labels.txt, 18:56:27Z): all 12 app pages „Fut · Naprakész" (ASCII fragment Naprak = 1 each, control 0).

The memory guard never refused. All twelve deployed on the default box; the last deploy page before immich read 3 422 / 11 444 MB and before vaultwarden 3 734 / 11 444 MB; free in the guest at 18:45Z: 3 520 MB used of 11 828. How many apps fit on a default box: at least these twelve, with room left; the one app that ran out of memory did so inside its own container cap (R-514), which the guard does not see.

adventurelog photos — the frontend proxy logs RequestContentLengthMismatchError: Request body length does not match content-length header for the multipart POST: the R-483 class („photo upload fails from any non-browser client"; the operator confirmed the browser path on 2026-09-13). Not re-filed; the harness cannot prove the browser path.

Hub during Phase 3: 12 × app_deployed (info) for tester-1, 20:14:35 → 20:45:42 CEST; nothing else — no alarm for the Paperless OOM (R-514).

Phase 3 interventions: 0 (every seed through the app's own front door or the product's own SMB share;

harness retries are recorded, none needed an act a customer could not make). Rows: R-512, R-513, R-514, R-515, R-516. Evidence pulled off the box 19:00Z: box-logs-phase3/.