diff --git a/REPORT-iso-branding-website-grid-2026-07-19.md b/REPORT-iso-branding-website-grid-2026-07-19.md
new file mode 100644
index 0000000..10a2852
--- /dev/null
+++ b/REPORT-iso-branding-website-grid-2026-07-19.md
@@ -0,0 +1,119 @@
+# REPORT — ISO boot branding + single-entry GRUB menu (R-38) · website grid restored (2026-07-19)
+
+> `REPORT-<topic>.md` per this repo's parallel-session rule: another session was writing in this
+> clone tonight (CAMPAIGN 7 / `DIAG-immich-restore-2026-07-19.md`), so the shared `REPORT.md` is left
+> untouched.
+
+Parts 1 and 2 of the polish train. Parts 3 and 4 landed in `felhom-agent` and `felhom-controller`;
+see their own `REPORT.md`.
+
+---
+
+## Part 1 — scripts v1.22.0: GRUB branding + single-entry safety (R-38)
+
+### What shipped
+
+Every ISO is now **repacked** after `prepare-iso`. `mkimage-surgery.sh` → **`iso-repack.sh`**:
+branding and the slice-B loader swap need the same extract → modify → re-master cycle, so they share
+one pass instead of re-mastering twice. **The mkimage recipe is untouched.**
+
+**The safety half — the one that matters.** The stock PVE menu offers *Graphical*, *Terminal UI*, a
+serial variant, and an **Advanced Options** submenu holding two `nomodeset` entries, three debug
+entries, *Rescue Boot*, memtest and *UEFI Firmware Settings*. Every one of those reaches the
+**manual** installer, whose first question is which disk to wipe. They are **not emitted** — not
+hidden, not password-gated. What ships is one entry, „Felhom telepítés", default, 5 s.
+
+**Boot behavior is unchanged.** The `linux`/`initrd` lines are lifted **verbatim at repack time**
+from the ISO's own *Install Proxmox VE (Automated)* entry rather than frozen into a copy in this
+repo, so a PVE bump that moves the kernel path or edits the append line tracks automatically. The
+build **fails** if they cannot be found, if the append line has lost `proxmox-start-auto-installer`,
+or if `auto-installer-mode.toml` is absent — that last one because without it the single
+Felhom-labelled entry would boot a *manual* installer, i.e. exactly what this change prevents.
+
+**Gates, then a re-check against the shipped artifact.** The rendered menu is asserted to have
+exactly 1 `menuentry`, 0 `submenu`s and no *live* reference to
+`proxtui`/`proxdebug`/`nomodeset`/`Rescue Boot`/`memtest`/`fwsetup` (comments are stripped first —
+the template's header names the dropped entries deliberately). Then the menu and theme background
+are read back **out of `final.iso`**, not out of the extract tree.
+
+**The boot card.** `grub/generate-grub-background.sh` letterboxes `website/assets/og-image_2.png`
+onto a 1024×768 gfxterm canvas at repack time (ImageMagick added to the assistant image), so the boot
+screen has **one source** and not a second pre-rendered PNG to drift. The card's own subtle grid
+(measured: 4px lines of `#0D131A` on `#0D1117`, pitch 131px) is continued across the letterbox fill
+**phase-locked** to where the card's grid lands, so the fill is seamless instead of a 500px square of
+grid floating in flat navy. The generator refuses a source whose geometry no longer matches the
+measured constants — a swapped asset would misplace every line, and that only shows up on a boot
+screen nobody re-checks. Menu positioning needs a gfxmenu theme (plain `background_image` cannot move
+the menu off the wordmark), so `grub/felhom-theme.txt` puts it in the lower third the layout leaves
+empty, optically centered (measured off a canary screenshot; the comment records the measurement).
+
+### Live validation — nested canary, UEFI/OVMF, PVE 9.2-1
+
+Booted the built canary ISO under QEMU with OVMF and captured the framebuffer.
+
+| Check | Result |
+|---|---|
+| GRUB renders the Felhom card | **PASS** — background + grid visible at 1024×768 |
+| Exactly one entry, selected | **PASS** — „Felhom telepítés" only |
+| Hungarian accents under gfxterm | **PASS** — „telepítés", „Indítás … másodperc múlva" render correctly |
+| Countdown visible and counting | **PASS** — 5 → 0 |
+| Auto-fires at 0 | **PASS** — serial shows ``Booting `Felhom telepítés'`` |
+| Unattended install proceeds | **PASS** — „Fetching answers for automatic installation" → auto installer |
+| Same abort as v1.21.0 | **PASS** — `ERROR: Installation failed: filter did not match any device` → `Installation aborted`; no disk touched |
+
+A first build **correctly failed closed**: the banned-entry gate matched the template's own
+explanatory header. Fixed to strip comments before matching (a comment naming a removed entry is the
+point; a directive using one is the bug), which is a gate behaving as designed.
+
+### Artifacts (rebuilt on 180, `/mnt/5_hdd/felhom.eu/felhom-iso/out/`)
+
+| ISO | sha256 | bytes |
+|---|---|---|
+| `felhom-pve-9.2-1-v1.22.0-n100-generic-mkimage.iso` (safety) | `ff6f06ba1dbfe10f27d703afc29516001000349147426b43c9a424a0ea28bdbf` | 1 704 482 816 |
+| `felhom-pve-9.2-1-v1.22.0-n100-demo-generic-mkimage.iso` (real) | `494db0ddf859b6b152cad4d0e0d9e9cefd27255cde07e2b41aba3ac12a217888` | 1 704 482 816 |
+| `felhom-pve-9.2-1-v1.22.0-nested-canary-generic.iso` (validation) | `83c61c0413c84e27b26a37bb5dfaed2fcd44fd25e3e571c7310142bd305f2f9d` | 1 705 338 880 |
+
+Both shipping ISOs: `embedding 60 modules`, `El Torito boot images=2`, fs-uuid preserved, and the
+post-re-master verification confirming 1 entry + theme background inside the finished image.
+
+**Deliberately not done** (per the task): no squashfs/initrd rebranding — post-GRUB screens are still
+Proxmox-branded; no disk-setup or answer-generation change; the pairing banner is untouched.
+
+---
+
+## Part 2 — website: the index grid background, restored
+
+**Archaeology.** Not a deliberate removal. The grid lived as a fixed `body::before` in
+`index.html`'s inline `<style>` block and was dropped in **`bed8675`** ("D3 Part 2: index + kapcsolat
+on design system v2"), the commit that migrated the page onto the shared `assets/site.css`.
+`dd54e4c`, which *created* `site.css`, has no `body::before` at all — it was a porting omission and
+nothing took its place. `ccbb13a` (the other five pages) never had it. No asset was lost: the
+mechanism was pure CSS (two stacked `linear-gradient`s), which is why nothing looked missing in the
+worktree.
+
+**Restoration, not redesign.** Same 50px cells, same 1px lines, same 3% opacity, same
+`position:fixed` / `z-index:-1`. One deliberate difference: the accent is the v2 `--blue` `#0083D8`
+instead of the retired legacy `#0088cc`, which `site_gates.py` bans. Scoped to `body.page-index`,
+because index is the only page that ever had it. `site.css` cache-bust bumped `?v=1` → `?v=2` across
+all seven pages (nginx caches 7 days); BOM preserved on every file.
+
+**Live verification** (felhom.eu, after git-sync deploy):
+
+- Desktop: grid renders behind the hero, at its original subtlety.
+- **376px viewport** (via a same-origin iframe — the browser window would not resize in this
+  environment, so the narrow case was exercised for real rather than asserted): grid renders, mobile
+  layout unchanged, `scrollWidth === clientWidth` so **no horizontal overflow**.
+- Computed style confirmed live: `linear-gradient(rgba(0,131,216,0.03) 1px, …)`, `50px 50px`,
+  `position: fixed`, `z-index: -1`, `pointer-events: none`.
+- `python scripts/site_gates.py` — **OK** (BOM, no legacy tokens, no `<style>` blocks, cache-busted).
+
+---
+
+## Docs
+
+- `scripts/CHANGELOG.md` — v1.22.0 entry.
+- `website/CHANGELOG.md` — grid restoration entry.
+- `documentation/backlog/ROADMAP.md` — **R-38 flipped to SHIPPED**; **R-45** (unified async-job
+  feedback) and **R-46** (verification-copy browse + expiry) added; pre-invite checklist gained the
+  "golden ≥ 0.147.x carries all four infra images" line.
+- Capability map: **untouched** — no capability moved. These are UX and packaging.
diff --git a/documentation/backlog/ROADMAP.md b/documentation/backlog/ROADMAP.md
index 86e0144..be43ef0 100644
--- a/documentation/backlog/ROADMAP.md
+++ b/documentation/backlog/ROADMAP.md
@@ -78,12 +78,14 @@
 | R-29 | **The design-v2 green gates are not enforced anywhere — one has been RED for 16 releases.** `controller/scripts/docker_run_volume_path_gate.py` has failed continuously since **2026-07-14 (v0.129.0)** and nobody noticed until R-7b's close-out ran it by hand at v0.145.0. Two separable parts. **(a) The finding itself is benign and the fix is 3 lines.** The flagged call is `internal/appexport/estimate.go:179` `docker run --rm -v <volumeName>:/vol:ro alpine du` — a **NAMED-VOLUME** mount, i.e. daemon-side with no host path, which is the *safe* shape and byte-for-byte the same pattern as three entries already on the gate's ALLOWLIST (`export.go` `volName+":/vol"`, `backup.go` `volName+":/vol:ro"`, `restore.go` `volName+":/vol"`). It is NOT the v0.124.0 path-strand class the gate exists to catch — the author of the v0.129.0 F-A fix explicitly avoided that class (see the function's own comment) and simply never added the allowlist entry. So the fix is an ALLOWLIST addition WITH ITS WHY, **not** a docker-cp rewrite; anyone who 'fixes' this by rewriting the call has misread the gate. **(b) The systemic half is the real item:** the gates run only when a human remembers to run them, so a gate can sit red across 16 releases while every REPORT says 'green'. This is the SECOND instance of the class — cf. the v0.123.0 note *'Windows green gate silently red (read-only fsync)'*. Decide where they run (pre-push hook, `build.sh` step, or a CI job) and make a red gate block the train the way the Go green gate does. | S (a) / M (b) | idea | Origin: R-7b close-out, `felhom-controller` REPORT §4(f) — CC correctly left it alone as out-of-scope and pre-existing, and verified by stashing that it fails identically on the unmodified tree. Flips no capability-map row (engineering hygiene, no customer-visible behaviour). Affected gates to audit for the same rot: controller `template_id_gate` / `emoji_gate` / `native_confirm_gate` / `offbox_rename_gate` / `mojibake_gate` / `app_row_dedup_gate` / `docker_run_volume_path_gate`, hub `hub_confirm_gate`, manifests `manifest_bearer_gate`, website `site_gates`. **Do not bundle (a) into an unrelated feature commit** — it is a one-line behavioural claim about a mount's safety and deserves its own reviewed diff. **2026-07-18 rehearsal note:** the run's finding list independently re-raised "assign the pre-existing `docker_run_volume_path_gate` failure its ID so red stops normalizing" — **that is this item; no second ID was minted.** |
 
 | R-37 | **Post-RESET health card shows stale pre-RESET warnings.** After a RESET the card should read **„RESET óta nincs adat"** instead of carrying warnings about a lifecycle that no longer exists. | XS | **SHIPPED (hub v0.67.0, 2026-07-18)** | The customer page raises a banner when a RESET **completed** after the newest report, quoting „RESET óta nincs adat" and the reset timestamp, because until the box reports again every health figure describes a lifecycle that no longer exists. Deliberately narrow: an **in-flight** reset does not trigger it (only a completed one), and it **clears itself** on the first post-RESET report. Ties resolve to STALE — SQLite timestamps are second-resolution and a same-second report almost certainly arrived just before the reset destroyed what it describes; erring the other way would hide the banner exactly when it matters most. Red-proofed (neutering the predicate fails the assertion). — Origin: 2026-07-18 rehearsal. Same family as R-36 — the hub knows the state changed and the UI has not caught up |
-| R-38 | **Installer GRUB slice.** A single default „Felhom telepítés" entry; the **interactive installers REMOVED** (safety: an interactive entry is how a wrong-disk manual install happens); felhom background. | S | idea | Origin: 2026-07-18 rehearsal, alongside R-21's physical closure. **Squashfs/theme rebranding explicitly DEFERRED** — this item is the menu and the safety, not a skin |
+| R-38 | **Installer GRUB slice.** A single default „Felhom telepítés" entry; the **interactive installers REMOVED** (safety: an interactive entry is how a wrong-disk manual install happens); felhom background. | S | **SHIPPED (scripts v1.22.0, 2026-07-19)** | Origin: 2026-07-18 rehearsal, alongside R-21's physical closure. Every ISO is repacked after `prepare-iso`: exactly **one** entry („Felhom telepítés", default, 5 s), with Graphical / Terminal UI / serial and the whole **Advanced Options** submenu (nomodeset ×2, three debug variants, Rescue Boot, memtest, UEFI settings) **not emitted** — not hidden, not password-gated. Boot behavior unchanged: the `linux`/`initrd` lines are lifted **verbatim at repack time** from the ISO's own automated entry, so a PVE bump tracks automatically; the build fails if they are missing, if the append line has lost `proxmox-start-auto-installer`, or if `auto-installer-mode.toml` is absent. Gated for 1 entry / 0 submenus / no live banned references, then **re-verified by reading the menu back out of the finished ISO**. Background generated at repack time from `website/assets/og-image_2.png` (one source, no second copy to drift), with the card's own grid phase-locked across the letterbox fill. Live-validated on the nested canary (UEFI/OVMF): renders, auto-fires, reaches the same match-nothing abort as v1.21.0. **Squashfs/theme rebranding still DEFERRED** — post-GRUB screens remain Proxmox-branded. GRUB's `e`/`c` keys also remain reachable (suppressing them needs a superuser password — a separate decision); the menu no longer advertises them |
 | R-40 | **[P2-HIGH] The update path cannot express a MULTI-HOP major upgrade.** A template pin is a single value; the customer's update button pulls whatever the catalog now says. For apps whose upstream forbids version skipping this produces a broken upgrade. Nextcloud is explicit: *"You cannot skip major releases. Please re-run the upgrade until you have reached the highest available release."* Campaign 7 moved its template **31 → 34** (a fresh deploy validates fine — 302, 3/3 healthy), so an existing 31 customer pressing update would attempt a jump Nextcloud refuses. | M | idea | Origin: CAMPAIGN 7 (`audits/CAMPAIGN-7-catalog-sweep-2026-07-19.md` §7 F7). Not nextcloud-only — any app with sequential-major rules (gitea, tandoor, outline…) has the same shape. Directions: a per-app `upgrade_path:`/`max_hop:` in `.felhom.yml` that the update button walks in stages; or refuse-and-explain when the installed major is >1 behind; or pin an intermediate "stepping-stone" tag. **Until this exists, a >1-major catalog bump is safe for NEW deploys and unsafe for the update button** — which is exactly the asymmetry the campaign's MAJOR flag was meant to record but cannot enforce |
 | R-41 | **[P2-HIGH] The catalog has no standing "does every template still deploy?" check.** Campaign 7 was the first thing that ever tried to deploy all 53 apps, and found **5 that had NEVER been deployable**: papra (missing required `AUTH_SECRET`), zipline (v4 renamed `CORE_DATABASE_URL` → `DATABASE_URL`), wishlist (Docker Hub image gone; upstream moved to ghcr.io), homebox (upstream dropped the `v` tag prefix + new required env), glance (needs a seeded `glance.yml` the template never provides — PROVEN pre-existing: the pre-campaign v0.7.4 pin fails identically). Plus **7 broken healthchecks** and 2 apps whose images no longer resolve at all (plant-it, wanderer). | M | idea | Origin: CAMPAIGN 7 (§7 F5/F6). The repo already has the right pattern in `scripts/check-image-pins.py` — a mechanical gate run on every change. Cheap first slice: a **resolvability gate** (`docker manifest inspect` every pin) would alone have caught plant-it, wanderer, wishlist and homebox, and needs no box. Full slice: a periodic deploy-all sweep on the demo box reusing the campaign's engine. **Silent rot is the real risk** — an app can die upstream and nobody learns until a customer clicks Telepítés |
 | R-42 | **Ruling needed: do DB/cache sidecar majors follow the app, or the newest tag?** Campaign 7 deliberately did NOT bump sidecar majors (postgres 16→18, redis 7→8, mariadb 11.6→12.3, postgis 16→17) while bumping ~40 app images to current. | S | **decision pending (Viktor)** | Origin: CAMPAIGN 7 §4. The case for not bumping: a DB major is a **data-plane decision the application owns** — immich proves it, upstream pins one specific tested `postgres:14-vectorchord…` build — and `postgres:16-alpine`/`redis:7-alpine` already track the newest patch inside their major, so they are not stale. The case for bumping: EOL majors eventually stop getting security patches, and "we never bump" silently becomes "we ship EOL databases". Suggested shape: per-app sidecar pin follows **upstream's own compose** where upstream publishes one, else stay within the current major and revisit at that major's EOL date |
 | R-43 | **[P2-HIGH] No offsite restore path can restore a database — offsite restore cannot reconstitute a DB-indexed app.** All three offsite buttons are file-only. „Ellenőrző visszaállítás" and „Teljes visszaállítás" restore into a **scratch/verify folder** and never load a dump into postgres (`controller/internal/backup/offbox_restore.go:171-232`, `:130-164`); „Helyreállítás az élő adatok közé (csak a hiányzó fájlok)" is `rsync -a --ignore-existing` over **mandatory userdata paths only** — it never touches a DB and never stops/starts the stack (`offbox_restore.go:346-421`). The DB dump is faithfully carried *into* the snapshot and can never be replayed *out of* it by any offsite action; the only code that replays into a live DB is `RestoreFromRecoveryUnit` (`backup/restore_unit.go:74`), reachable solely from the **local** restore panel (`web/handlers.go:1108`). Compounding: the `live recovery unit present — not overwriting` guard (`offbox_restore.go:400-405`) skips the **entire** unit — compose, manifest **and db-dumps** — whenever a local `backups/primary/<app>` exists, which is true on any box whose local backup has run, so on a normal box the offsite dump is never even staged to disk. | M | idea | **Evidence: `audits/DIAG-immich-restore-2026-07-19.md` (live on demo-felhom).** Viktor deleted 11 immich photos to test offsite restore; both place runs merged **0 files** and flashed success. Root cause is two-layered — the UI delete only *trashed* the assets so nothing was missing to restore, **but a valid test would also have failed**: files return, the library stays empty, because immich's truth lives in postgres. **The customer-visible failure mode: correct bytes on disk and an app that cannot see them.** Severity case: this is the offsite tier — the one that survives losing the box — and most of the catalog is DB-indexed. Direction (needs a spec, do not improvise): either offsite gains a real DB-replay leg reusing `RestoreFromRecoveryUnit` behind a stop→restore→start sequence, or the offsite UI states plainly that it restores files only and routes the customer to the local recovery-unit flow for the DB. Pairs with R-44 (a replay leg is worthless while the dump is stale). Flips: the **customer-restore map row stays MISSING** and gains this as a note — the C6 evidence attempt found a product gap, which is the rehearsal system working |
 | R-44 | **[P2-HIGH] A manual offsite push ships an unrefreshed DB dump — "backed up now" is false for the DB half.** `offboxRunHandler` → `RunOffboxBackup` goes straight to the restic push and never calls `RunDBDumps` / `captureAllRecoveryUnits` (`controller/internal/web/offbox_handlers.go:203-227`, `backup/offbox.go:574-759`); the recovery unit merely **enumerates** existing dump filenames via `listFileNames`, never creates them (`backup/recovery_unit.go:105-106`). Dumps come only from the separate local `db-dump` daily at **02:30** (`cmd/controller/main.go:542`), with the scheduled offsite at 04:15 — so a *manual* run at any other hour ships a dump up to ~24 h old. **There is no freshness check and no RPO surface anywhere:** zero `RPO` hits across `controller/`; `offboxUnitTime` is only a two-drive tiebreak (`offbox.go:827-837`); the `DBValidationCache` exists (`backup.go:364-370`) but no offsite or restore path reads it. | S–M | idea | **Evidence: `audits/DIAG-immich-restore-2026-07-19.md`.** Today's unit dump `immich-postgres.sql` (51 954 452 B, mtime **02:30 CEST**) probed to **`asset: 0 rows`, `user: 0 rows`, `album: 0 rows`** — the 52 MB is entirely immich's shipped `geodata_places`/`naturalearth_countries` reference data. It predates both the admin user (created 07:56:25) and the photos (07:57). Same for the unit's `immich_immich_postgres_data.tar` (323 MB, also 02:30). **A dump that looks substantial by size can contain zero customer content** — size is not a health signal, and nothing in the product says otherwise. **Latent hazard:** had a full restore actually loaded that dump it would have written an empty DB over the live one, destroying the trashed rows that were the only surviving recovery path. Direction: dump-before-push on manual runs (the honest fix), **or** an explicit RPO line in the UI („adatbázis-állapot: <dump time>") so the operator/customer can see what they are actually shipping. Cheap interim: surface dump mtime + row-count sanity from the existing `DBValidationCache` on `/backups/restore` |
+| R-45 | **[P2] Unified async-job feedback.** Every long operation invents its own progress surface, or none. Tonight produced three more one-off cards (v0.147.x: samba bring-up, offsite progress, restore result) on top of two existing patterns (deploy 3-step panel; storage-init/netstorage status poll). They agree on nothing: some use `{ok,data}` envelopes and some raw JSON, some poll 1 s / 1.5 s / 3 s, some are in-memory-only and lie after a restart, and each re-implements single-flight + snapshot + phase→Hungarian mapping. | M | idea | Origin: 2026-07-19 feedback slice 1 (controller v0.147.0). The cases to generalise from are all in-tree: `web/storage_init_job.go` (the best shape — acquire/release/set/snapshot), `web/netstorage_job.go`, `web/samba_ensure_job.go`, `backup/opstatus.go`, `backup/offbox_progress.go`. Shape: one job registry + one poll endpoint + one client-side renderer, phases declared per job. **Two lessons tonight that any framework must encode:** (1) a terminal state must be **probed, not inferred** — `compose up -d` exits 0 on a crash-loop; (2) a progress source that reports nothing is normal, not broken — restic reports 0 bytes for a whole incremental run, and a bar that sits at 0% is worse than no bar. Also fixes the restart hole: in-memory job state currently vanishes and the card silently disagrees with reality |
+| R-46 | **[P2] Verification copies need a customer-visible browse surface and an expiry.** v0.147.0 made them *visible* (listed with path/size/date, individually deletable) — but the customer still cannot LOOK INSIDE a verification restore to confirm the file they wanted is really there, which is the entire point of a verification restore, and nothing ever removes them. | S–M | idea | Origin: 2026-07-19 feedback slice 4a, registered as the explicit follow-up to it. Two gaps, deliberately designed together because they are the same object: (a) **the invisible-result gap** — a read-only browse of `backups/offsite-restore/<app>` (the FileBrowser infra stack already exists and already serves scoped roots, so this may be a mount rather than new code); (b) **the disk-lifecycle gap** — auto-expiry after N days with the count/size surfaced before it fires, so a drive is never quietly filled by verification restores nobody remembers taking. Pairs with R-43: a browse surface is also how a customer would discover that a DB-indexed app's files came back but the app still cannot see them |
 
 ## Pre-invite checklist — what stands between here and the first remote tester
 
@@ -93,6 +95,7 @@ Everything here is **remote-doable** — the N100 is packed, and none of it need
 | Action | Owner | Note |
 |---|---|---|
 | ~~Rebuild the golden → 0.146.0~~ **BAKED + PUBLISHED 2026-07-18; awaiting the operator's two saves** | Viktor (saves) | Golden **0.146.0** baked on the drill VM and published to gitea — `felhom-golden/0.146.0/golden.tar.zst`, **sha256 `4834c703162c5437467a329144b1a523019bf5693ab9d439558be7323587e955`**, 612 696 588 B (584 MB archive). All pass markers green: `Result=success`/`ExecMainStatus=0`, **0** FATAL/exclusions, `docker OK (overlay2)`, **all three mounts included** (rootfs + mp0 `/var/lib/docker` + mp1 `/mnt/sys_drive`), pre-delete **404**, upload **HTTP 201**; controller **0.146.0** confirmed baked in. Integrity round-trip independent of the build host: anonymous `GET | sha256sum` **matches byte-for-byte**, ranged GET **206**, `content-length` matches. Teardown per GL-1: guest 9100 purged, token/script/log shredded in-VM, VM powered off, drill disk reverted to `virgin` exactly-as-found, **token-leak grep = 0**. Log retained `180:/mnt/5_hdd/felhom.eu/drill/bake-0.146.0.log`. Now selectable in the hub dropdown (versions: 0.136.0, 0.143.0, **0.146.0**). **REMAINING = operator, password-gated:** Day-0 manifest Golden → 0.146.0 (Agent stays 0.90.0, MinAgent stays 0.90.0 — the v0.146.0 CHANGELOG declares no new agent coupling) → save; **then** floor → v0.146.0 saved **LAST** |
+| **Golden ≥ 0.147.x carries ALL FOUR infra images** | — (next bake) | `build-golden.sh` v2.1.0 (2026-07-19) now derives the pre-pull list from the controller binary it is about to bake (`--print-infra-images`) instead of a hand-maintained copy that had already drifted: `felhom-samba` was never added to it, so every golden so far baked **3 of 4** — which is why enabling Megosztás on a fresh box pulled from the registry with zero feedback. **No golden rebuild for this alone**; it takes effect at the next bake. Until then a fresh box still pulls felhom-samba at enable time, which controller v0.147.0's progress card now at least explains |
 | **freemail.hu test-send** | Viktor | The open half of R-4; the gmail half closed on 2026-07-18 under `p=quarantine` |
 | **C6 — customer performs a restore, unassisted** | Viktor as customer zero | The one open script step in R-3 and still MISSING as capability evidence. Remote-doable on the reborn box — the dashboard is remote |
 | **R-11 rulings** | Viktor | Contact channel, tester agreement, alert thresholds (the R-5 gauge thresholds are still pending a ruling) |
diff --git a/scripts/CHANGELOG.md b/scripts/CHANGELOG.md
index 539d151..528ec69 100644
--- a/scripts/CHANGELOG.md
+++ b/scripts/CHANGELOG.md
@@ -1,5 +1,62 @@
 # Felhom scripts — Changelog
 
+## build-felhom-iso.sh v1.22.0 — the boot screen is ours, and it offers exactly one thing (R-38) (2026-07-19)
+
+**A boot menu is a product surface, and ours was Proxmox's.** Every ISO is now repacked after
+`prepare-iso` to carry a Felhom boot screen and — the half that actually matters — a menu with
+**exactly one entry**.
+
+- **The safety half.** The stock PVE menu offers *Install Proxmox VE (Graphical)*, *(Terminal UI)*, a
+  serial variant, and an **Advanced Options** submenu holding two `nomodeset` entries, three debug
+  entries, *Rescue Boot*, memtest and *UEFI Firmware Settings*. Every one of those reaches the
+  **manual** installer, whose first question is which disk to wipe. A customer — or their helpful
+  nephew — must not be able to get there from a boot menu they are staring at. Those entries are not
+  hidden and not password-gated: **they are not emitted**. What ships is „Felhom telepítés", default,
+  5 s.
+- **Boot behavior is unchanged.** The `linux`/`initrd` lines are lifted **verbatim at repack time**
+  from the ISO's own *Install Proxmox VE (Automated)* entry rather than frozen into a copy in this
+  repo, so a PVE bump that moves the kernel path or edits the append line tracks automatically
+  instead of silently diverging. The build **fails** if they cannot be found, if the append line has
+  lost `proxmox-start-auto-installer`, or if `auto-installer-mode.toml` is absent — that last one
+  because without it the single Felhom-labelled entry would boot a *manual* installer, which is the
+  precise outcome this change exists to prevent.
+- **Gates, and then a re-check against the shipped artifact.** The rendered menu is asserted to have
+  exactly 1 `menuentry`, 0 `submenu`s and no live reference to
+  `proxtui`/`proxdebug`/`nomodeset`/`Rescue Boot`/`memtest`/`fwsetup` (comments are stripped first —
+  the template's header names the dropped entries on purpose). Then the menu and the theme background
+  are read back **out of `final.iso`**, not out of the extract tree, so "the branding landed in the
+  image we ship" is proven rather than assumed.
+- **The boot card.** `grub/generate-grub-background.sh` letterboxes `website/assets/og-image_2.png`
+  onto a 1024×768 gfxterm canvas at repack time (ImageMagick, added to the assistant image), so the
+  boot screen has **one source** — the website asset — and not a second pre-rendered PNG in the repo
+  to drift. The card's own subtle background grid is continued across the letterbox fill
+  **phase-locked** to where the card's grid lands, so the fill is seamless instead of a 500 px square
+  of grid floating in flat navy. The generator refuses a source whose geometry no longer matches the
+  measured grid constants — a silently swapped asset would misplace every line, and that only shows
+  up on a boot screen nobody re-checks.
+- **Menu positioning needs a theme.** Plain `background_image` cannot move the menu off the wordmark,
+  so `grub/felhom-theme.txt` (gfxmenu) puts it in the lower third the layout deliberately leaves
+  empty, with the entry optically centered under the card (measured off a canary screenshot — the
+  comment records the measurement). No "e: edit entry" hint label: advertising the editor works
+  against a single-entry menu.
+- **`mkimage-surgery.sh` → `iso-repack.sh`.** Branding and the slice-B loader swap need the same
+  extract → modify → re-master cycle, so they now share **one** pass instead of re-mastering twice.
+  The mkimage recipe is untouched. The embedded module list is still derived from the **stock**
+  `grub.cfg` (snapshotted before branding rewrites it, so branding cannot shrink the embedded set),
+  plus gfxmenu's `bitmap`/`bitmap_scale`/`trig` renderer dependencies.
+- `--no-brand` exists for debugging the stock menu and says so loudly in the build log and the
+  manifest. It is not a shipping mode.
+
+**Live-validated (nested canary, UEFI/OVMF, PVE 9.2-1).** GRUB renders the card; the single entry is
+selected and counts down in Hungarian (accents render correctly under gfxterm); it auto-fires at 0;
+the automatic installer runs and reaches the **match-nothing abort exactly as in v1.21.0**
+(`ERROR: Installation failed: filter did not match any device` → `Installation aborted`), touching no
+disk. Both shipping ISOs rebuilt (see `REPORT-iso-branding-2026-07-19.md` for shas).
+
+**Not touched (deferred):** the installer squashfs/initrd theme — the post-GRUB screens are still
+Proxmox-branded. GRUB's `e`/`c` keys also remain reachable (suppressing them needs a superuser
+password, which is a separate decision); the menu no longer advertises them.
+
 ## build-felhom-iso.sh v1.21.0 — the pairing wait stops looking like a failure (R-33) (2026-07-18)
 
 **Waiting is not failing, and must not be reported as failure.** Until now the PAIRING poll loop WAS
diff --git a/website/CHANGELOG.md b/website/CHANGELOG.md
index 6b96564..88280f6 100644
--- a/website/CHANGELOG.md
+++ b/website/CHANGELOG.md
@@ -1,5 +1,21 @@
 # website/ changelog (newest on top)
 
+## 2026-07-19 — Restored: the index grid background
+
+The subtle grid behind the hero was **not** removed on purpose. It lived as a fixed `body::before` in
+`index.html`'s inline `<style>` block and was dropped when `bed8675` ("D3 Part 2") migrated the page
+onto the shared `assets/site.css`; `dd54e4c`, the commit that created `site.css`, has no
+`body::before` at all. A porting omission, and nothing took its place. No asset was lost — it was
+pure CSS (two stacked `linear-gradient`s), so there was nothing missing from the worktree to notice.
+
+Restored, not redesigned: same 50px cells, same 1px lines, same 3% opacity, same `position:fixed` /
+`z-index:-1` so it does not scroll. One deliberate difference — the accent is the v2 `--blue`
+`#0083D8` instead of the retired legacy `#0088cc`, which `site_gates.py` bans. Scoped to
+`body.page-index`, because index is the only page that ever had it.
+
+`site.css` cache-bust bumped `?v=1` → `?v=2` on all seven pages (nginx caches 7 days). Verified live
+on desktop and in a 376px viewport: grid renders, no horizontal overflow, mobile layout unchanged.
+
 ## 2026-07-18 — Pre-Facebook content refresh: capability-map alignment + „Zárt teszt" landing
 
 The site's audience changes from zero-stakes to real Hungarian households arriving from a Facebook