marketing/facebook: the phone check ran after all — the cover IS cut on phones (R-919)

Your suggestion to use DevTools device mode was right; "cannot be checked" was
too quick a conclusion. On an emulated Pixel 9 (412x924, mobile UA, with a
reload so Facebook serves the mobile bundle) the Page's mobile header renders
412x274 = 1.504:1. Facebook keeps the cover's full height and shows only the
centre 938 px of its 1640 px width -- 351 px off each side. build.py's safe
area leaves 306 px clear per side, 45 px too few, and the light text in
cover-c.png runs x333..x997 against a left crop edge of x351, so 18 px are lost:
the headline reads "aját szabályaid" and the wordmark "elhom.eu" on every phone.

Nothing re-cropped on Facebook (the task's fence). The fix is build.py's safe
area (<=938 px, ~900 for margin) plus the measured 172 px centred phone profile
circle, then a hand re-upload. R-919 opened; R-918 closed and moved to
CLOSED-ITEMS with the recipe that made the check possible.

Meta's help page is wrong about Meta's own rendering: it states 2.4:1 for the
mobile cover where the header measures 1.504:1, so this session's first-pass
arithmetic -- explicitly labelled arithmetic, not a check -- under-predicted the
crop about fivefold. That is recorded rather than quietly deleted.

Also: the evidence secret scan needed --exclude=README.md, because that README
quotes the search strings and was matching itself (4 false EAA hits, 1 false
access_token); with the exclusion, control 1 -> 0 and no real hit. And the
Business & legal section header was already miscounted before this session
(said 9/P2 4, actually held 10/P2 5) -- corrected; five other section headers
drift too and are named in the report, left for a session that owns the register.

documentation/backlog/CLOSED-ITEMS.md

@@ -1112,3 +1112,11 @@ Full original text of each row: `git show <the commit that added this section>^:
 | **R-689** | **demo-hp's restore test picked the golden template in `local:backup/` and failed every 6 h (P3).** Agent v0.135.0 + v0.136.0 + v0.137.0: only `vzdump-<type>-<vmid>` files or PBS `ct/…` or `vm/…` snapshots with a reported vmid, of a guest that still EXISTS on the node (v0.136.0 — the first half, read live with `-selftest=restore-test-due`, fell to a leftover archive of a guest deleted in August; v0.137.0 — PVE answers 403, not "does not exist", for a guest outside the agent's pool, which 0.136.0 read as a lookup failure). Delivered to both demo hosts by signed `agent_update`. | CLOSED 2026-09-27 — agent v0.137.0 | `audits/version-travel-2026-09-26/D1/` |
 | **R-655** | **adventurelog v0.13.0 could not become healthy in the catalog's template (P2).** Operator ruling decision 41 (keep the download). Catalog `06ea7da`: the frontend override dropped; a cut-off world-data file set aside before start (a pending import crash-looped 10× without it). Proven on the bench and on 9202 (204 s under the default 5-min wait). | CLOSED 2026-09-27 — catalog `06ea7da` | `audits/version-travel-2026-09-26/C/` |
 | **R-697** | **A restore dropped the `conversion_copy` record but not the kept pre-conversion volume — the copy was never released (P3).** Seen 2026-09-26 on 9202 (A1). v0.276.0: the restore's write carries the app's life records from the `app.yaml` it replaces (`carryLifeRecords`: conversion copies, `desired_state`, update history; not the pin, not `installed_images`); a second conversion after a restore to the old major keeps the first copy in `earlier_conversion_copies`, released by the same rule. Rule: a write that is not a new install is load-then-save, or it names every field it drops. Red-proofed RP1, RP2. | CLOSED 2026-09-27 — controller v0.276.0 | `audits/records-carried-2026-09-27/` |
+
+## 2026-10-08 (late evening) — the Facebook Page's phone rendering, checked
+
+Full original text of each row: `git show 6a267010:documentation/backlog/OPEN-ITEMS.md`.
+
+| id | what closed | closed | where the full text is |
+|---|---|---|---|
+| **R-918** | **The Facebook Page's phone rendering could not be checked from Claude in Chrome (P4).** Filed and answered the same evening. The obstacle was real and is worth keeping: `www.facebook.com` has a minimum width and a narrowed desktop window only grows a horizontal scrollbar (`innerWidth` pinned at 1105, `scrollWidth` 2051), and `m.facebook.com` redirects to `www` under a desktop user agent — so **narrowing a browser window can never produce Facebook's phone layout.** What does: Chrome DevTools device mode (Ctrl+Shift+M) with a device chosen, so the user agent is mobile too, **and a reload afterwards** — without the reload Facebook keeps serving the already-booted desktop bundle (content 901 px wide inside a 412 px viewport); with it, `clientWidth == scrollWidth == 412` and the real mobile layout renders. `m.facebook.com` then loads properly where the desktop UA had bounced it. | CLOSED 2026-10-08 — checked on Pixel 9 emulation; the check **failed** and its finding is **R-919** | `audits/facebook-page-setup-2026-10-08/README.md`, `REPORT-facebook-page-setup.md` §4 |

documentation/backlog/OPEN-ITEMS.md

@@ -263,7 +263,7 @@ stopping line that lies.
 | **R-814** | Hub & operator | P4 | `PBS-storage-1` (u629193, box 611421) still `status=active`, 19.9 MB | **VERIFY** (2026-10-03 triage: a July watch row with no id; given R-814. WAITING-ON-OPERATOR — no record found that the box was deleted.) — WAITING-ON-OPERATOR | operator console | Delete the box | operator |
 | **R-844** | Hub & operator | P4 | **The household's OS-update line exists only on the hub's customer timeline.** 2026-10-04: the box itself has no event surface for agent results (the controller UI shows no timeline), so `os_update_applied` is a hub customer event (info: recorded, never mailed). Its stored text is the hub's English sentence; the hu/en bundle text (`mail.event.os_update_applied`) is used only if it is ever mailed. Fix direction: a controller-side line (the controller already polls the agent's local API) when the box gets a household timeline. `audits/os-guest-lane-2026-10-04/partG/hub-customer-timeline-demo-hp.txt` | **READY — owner: CC** **2026-10-05 (burn-down night): NEEDS A DESIGN** — a household timeline on the box does not exist yet. | — | — | CC |
 
-## Business & legal — 10 rows (P2 4, P4 6)
+## Business & legal — 12 rows (P2 5, P3 1, P4 6)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -278,8 +278,9 @@ stopping line that lies.
 | **R-915** | Business & legal | P4 | **The Meta app `felhom.eu` is in development mode, so posts it makes are seen only by people with a role on the app.** READ 2026-10-08 (Meta docs, cited in the spike); not measured. MEASURED: development mode does not refuse posting (both test writes HTTP 200). Live needs display name, contact e-mail, a Terms of Service URL, an app icon, a category and the app purpose (privacy-policy and data-deletion URLs listed beside them). The robot's Page assignment, missing at first, was done by the operator the same day. | **WAITING-ON-OPERATOR** | R-813 (the Terms of Service URL) | Before real public posts: switch the app to Live in the Meta developer page. If nothing is done: posts stay invisible to the public. After Live: CC adds the Page link to the website footer (not before — a link to a Page nobody can read is worse than none) | operator |
 | **R-916** | Business & legal | P4 | **The logo has no usable vector master: `website/assets/logo.svg` sets „felhom.eu" as live text in the fonts „M+ 2c" and „Vremena Grotesk", which DooPlex does not have, so every renderer here draws other letters.** SEEN 2026-10-08 (Facebook pictures task): librsvg drew the lettering in DejaVu; `fc-match` resolves the family to DejaVu Sans. The PNG (645 x 408) is the only faithful copy, which caps every picture made from it at about that size (`marketing/facebook/README.md`). | **WAITING-ON-OPERATOR** | the machine with the fonts | In Inkscape on that machine: select the lettering → Path → Object to Path → save as `website/assets/logo-master.svg`; then `marketing/facebook/build.py` can use it. If nothing is done: the PNG stays the master; larger prints will be soft | operator |
 | **R-917** | Business & legal | P4 | **`COPY.md` §2, the Page's longer description (867 characters), has nowhere to go: Facebook's current Pages experience has no long-description field at all.** FOUND 2026-10-08 (Page setup task, `audits/facebook-page-setup-2026-10-08/`). Looked in four places, all on the live Page as its admin: the Page's „Névjegy" tab (Rövid áttekintés / Személyes adatok / Részletek — only a 255-character „Bemutatkozás" and the pinned category), Business Suite's „Oldal módosítása" dialog (profile picture, cover, Bemutatkozás, category, phone, e-mail, address, website, social links — and nothing else), Facebook settings → „Oldal adatai" (redirects to the same Névjegy tab) and settings → „Oldal beállítása" (name, access, type, history, status, recommendation, messaging, data sharing). MEASURED by Graph with the Page token: `description`, `general_info` and `bio` all read `null`. Writing `description` by API would need `pages_manage_metadata`; the robot key's scopes are `read_insights, pages_show_list, business_management, pages_read_engagement, pages_read_user_content, pages_manage_posts, pages_manage_engagement, public_profile`, and the task's fences forbid adding a permission. So §2 is written, reviewed and unplaceable. **Options for the operator:** (a) leave §2 unused and let the 99-character intro plus the website carry it; (b) shorten §2 to ≤ 255 characters and make it the „Bemutatkozás" instead of §1 — but §1 was written for exactly that slot, so this is really „rewrite one of the two"; (c) publish §2 as the Page's first pinned post once the app is Live (R-915), which is where a long text actually gets read; (d) ask Meta support whether the field still exists for this Page type. Recommended (c) — the text reads like a post already. | **WAITING-ON-OPERATOR** | the choice a/b/c/d; (c) also waits on R-915 | Pick a/b/c/d. If nothing is done: §2 stays in `COPY.md` unused and the Page carries only the 99-character intro | operator |
+| **R-919** | Business & legal | P3 | **On a phone the Facebook Page cuts the left edge of the cover: the „s” of „saját szabályaid” and the „f” of „felhom.eu” are gone.** MEASURED 2026-10-08 on the live Page in Chrome DevTools device mode, Pixel 9 (412 × 924, mobile user agent, after a reload so Facebook serves the mobile bundle): `audits/facebook-page-setup-2026-10-08/C2-phone-headline-cut-closeup.png`. The mobile Page header is **412 × 274 = 1,504:1**, so Facebook keeps our cover's full height and shows only the centre **938 px of its 1640 px width (57,2 %)** — **351 px cut from each side**. `marketing/facebook/build.py` builds to a safe area of the centre **1028 × 544** (306 px clear of each edge), which is **45 px wider per side than the phone actually shows**; the light text in `out/cover-c.png` runs from x 333 to x 997, and the left crop edge is x 351, so the first **18 px** of the text are cut. Covers A and B are built from the same safe area and will have the same edge. Two further facts this measurement establishes: **Meta's own help page is wrong about its own rendering** — it states the mobile cover is 2,4:1 where the Page header measures 1,504:1 — and the mobile profile circle is far bigger than assumed (172 px, centred, overlapping the bottom 112 px of the 274 px cover, i.e. source x 637–1030 × y 369–624 is hidden). Not re-cropped on Facebook, per the task's fence. | **OPEN — owner: CC** | — | Narrow `build.py`'s safe area to the centre ≤ 938 px at full height (use ~900 px for margin) and widen the phone profile-circle exclusion to the measured 172 px centred shape, with the check shown failing on today's covers first; rebuild A/B/C; the operator re-uploads the chosen cover by hand. Until then the cover reads „aját szabályaid” / „elhom.eu” on every phone | CC |
 
-## Process & tooling — 24 rows (P3 3, P4 21)
+## Process & tooling — 23 rows (P3 3, P4 20)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -306,7 +307,6 @@ stopping line that lies.
 | **R-903** | Process & tooling | P4 | **On a phone with JavaScript off, the website's menu does not open — so its links and the language globe cannot be reached there.** MEASURED 2026-10-08 (globe brief, headless Chrome at 376 px, JavaScript off): the three-line button is scripted (`#hamburger` toggles `.nav-links.is-open`), and below 900 px the nav list sits off-canvas until then. Older than the globe — the text switch had the same limit. The globe itself works with JavaScript off at desktop width (`audits/website-globe-2026-10-08/check.txt`). Fix direction: a CSS-only menu toggle (a `<details>` or a checkbox), a nav change on every page plus gate 3. | **OPEN — owner: CC** | — | Build the no-JS menu in a website task | CC |
 | **R-910** | Process & tooling | P4 | **The website's dashboard pictures show the old Apps card (the tags crowd the name, R-909) and no phone view (R-907).** Filed 2026-10-08. | **OPEN — owner: CC** — waits for tomorrow's controller release to reach demo-hp | Tomorrow's controller release on demo-hp | After the release reaches demo-hp 9201: retake the 8 `dashboard-*.webp` pictures the way `audits/website-dashboard-2026-10-08/` did (read only, language round trip), consider adding the phone view, run `site_gates.py`; then close R-907, R-909 | CC |
 | **R-912** | Process & tooling | P4 | **No gate checks that every catalog app has a logo file under its slug.** SEEN 2026-10-08: five apps (Crafty Controller, Gramps Web, Home Assistant, Plant-it, Uptime Kuma) had their logos and pictures under other names, so the dashboard showed the grey placeholder and no pictures; Docmost and Recipe Importer were added to the website today and are not in the hub's copy yet. Renamed the same day (website `CHANGELOG` 2026-10-08 evening). | **OPEN — owner: CC** | — | A gate (catalog or website): for every `templates/<app>/.felhom.yml` slug, `website/assets/<slug>-logo.svg` or `.png` exists, and no logo is coloured; with a decoy | CC |
-| **R-918** | Process & tooling | P4 | **The Facebook Page's phone rendering cannot be checked from Claude in Chrome: narrowing the desktop browser never produces Facebook's phone layout.** SEEN 2026-10-08 (Page setup task, Phase C). `resize_window` reported success while the window was maximised and `window.innerWidth` never moved (2133); after the operator un-maximised it, only the first call after each window-state change took effect. With the window at about 500 px, **`www.facebook.com` kept the desktop layout and grew a horizontal scrollbar** — `innerWidth` pinned at 1105, `scrollWidth` 2051 (`audits/facebook-page-setup-2026-10-08/C3-narrow-window-horizontal-scroll.jpg`) — and `m.facebook.com/felhom.eu` redirected to `www.facebook.com/felhom.eu?_rdr`. So the desktop site has a minimum width and the phone view needs a mobile user agent, which these tools do not set. The computer-width half of Phase C WAS measured and passed (cover whole, no crop, profile circle 16 px clear of it). Meta states a 2,4:1 mobile crop and a ~40 px profile overlap; our 1640 x 624 cover would lose about 71 px a side, and the safe area is 306 px clear — **arithmetic, not a measurement**. | **OPEN — owner: CC** | — | Check the Page on a phone, or in Chrome DevTools' device toolbar (Ctrl+Shift+M) at 390 x 844, and record it beside the computer screenshot; if the headline or „felhom.eu" is cut, that is a finding for `marketing/facebook/build.py`'s safe area, not a re-crop on Facebook. Same gap applies to any future Page picture change | CC |
 
 <!-- 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.