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/audits/facebook-page-setup-2026-10-08/README.md

@@ -20,7 +20,11 @@ Baseline `felhom.eu` `main` = `1d692734` (clean on both working trees before the
 | `B5-username-after.jpg` | „Oldal általános beállításai" showing the saved username |
 | `C1-page-computer-1435px.jpg` | the Page at a 1435 px viewport (the Phase C computer check) |
 | `C1-page-computer-2067px.jpg` | the same at 2067 px — the cover container is capped at 1250 px, so both show the identical cover |
+| `C2-page-phone-pixel9-412px.jpg` | the Page on an emulated Pixel 9 (412 × 924, mobile user agent) — the Phase C phone check |
+| `C2-phone-cover-cut.png` | the phone header at native size: the cover's left edge is cut |
+| `C2-phone-headline-cut-closeup.png` | the close-up: „**aját szabályaid**" and „**elhom.eu**" — one letter gone from each |
 | `C3-narrow-window-horizontal-scroll.jpg` | the proof that narrowing the window does NOT give the phone layout (see below) |
+| `D-ci-run-846-green.jpg` | the CI run for the first commit of this work |
 | `probe-before/` | `fb_probe.py read` before the edits — `C1-page.json` holds the OLD `about` |
 | `probe/` | `fb_probe.py read` after the edits — `C1-page.json` holds the NEW `about`; `run.log` is the run transcript |
 
@@ -47,7 +51,31 @@ saját szabályaid" and „felhom.eu" are whole. The profile circle renders 168
 **16–17 px below the cover's bottom edge** — it does not overlap the cover at all at this width, so it
 covers no cover text. Zoomed on the circle, the logo is whole: nothing is cut by the circular crop.
 
-**Phone width (390 px): NOT performed.** What was tried, in order:
+**Phone width: MEASURED on a Pixel 9, and it FAILS — the cover is cut.** See
+`C2-page-phone-pixel9-412px.jpg`, `C2-phone-cover-cut.png` and
+`C2-phone-headline-cut-closeup.png`.
+
+The mobile Page header renders **412 × 274 CSS px = 1,504:1**. Our cover is 2,628:1, so Facebook keeps its
+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, which leaves 306 px
+clear of each edge: **45 px per side wider than the phone actually shows**. Measured on the shipped file,
+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**. On screen the headline reads „**aját szabályaid**" and the wordmark reads
+„**elhom.eu**". Filed as **R-919**; nothing was re-cropped on Facebook, per the task's fence.
+
+The mobile profile circle is also much bigger than the README assumed: **172 px, centred**, overlapping the
+bottom **112 px** of the 274 px cover — in source coordinates it hides x 637–1030 × y 369–624. It covers
+part of the dashboard picture, no text.
+
+**Two things this contradicts.** Meta's own help page says the mobile cover is **2,4:1**; the Page header
+measures **1,504:1**, so Meta is wrong about its own rendering. And the arithmetic this file carried before
+the measurement — „a 2,4:1 crop loses ~71 px a side, and the safe area is 306 px clear, so the headline
+should survive" — was right in method and **wrong in conclusion**, because it trusted Meta's ratio. The
+real crop is five times deeper. It is left recorded here as the reason not to report arithmetic as a check.
+
+### How to get Facebook's phone layout at all (this took several wrong turns)
+
+What does **not** work — narrowing the browser window:
 
 1. `resize_window` to 1440 × 900 and to 390 × 844 while the Chrome window was maximised — the tool
    reported success each time and `window.innerWidth` never moved (2133).
@@ -55,32 +83,40 @@ covers no cover text. Zoomed on the circle, the logo is whole: nothing is cut by
    state change took effect — several later calls reported success and changed nothing.
 3. With the window narrowed to about 500 px (`C3-narrow-window-horizontal-scroll.jpg`), **`www.facebook.com`
    kept the desktop layout and grew a horizontal scrollbar**: `window.innerWidth` stayed pinned at 1105
-   and `document.documentElement.scrollWidth` at 2051. The desktop site has a minimum width and never
-   switches to the phone layout.
+   and `document.documentElement.scrollWidth` at 2051. The desktop site has a minimum width.
 4. `https://m.facebook.com/felhom.eu` redirected to `https://www.facebook.com/felhom.eu?_rdr`.
 
-So narrowing a desktop browser cannot produce Facebook's phone rendering — it needs a mobile user agent
-(Chrome DevTools device toolbar, Ctrl+Shift+M) or a real phone. Filed as **R-918**.
+What **does** work — Chrome DevTools device mode, which also sets the user agent:
 
-**What the numbers predict for the phone, as arithmetic and not as a measurement.** Meta's page says the
-mobile cover is 2,4:1 and the profile circle overlaps it by about 40 px. Our cover is 1640 × 624 =
-2,628:1. Reaching 2,4:1 at full height keeps 624 × 2,4 = 1497,6 px of the 1640 px width, so about 71 px
-would be cut from each side. Our safe area is the centre 1028 × 544, which is 306 px clear of each edge —
-comfortably inside that crop. This says the headline should survive; it does not show that it does.
+5. F12 → Ctrl+Shift+M → pick **Pixel 9** (412 × 924, dpr 2,625, Android UA). Set this on the tab the
+   browser tools drive: emulation is per-tab and cannot be switched on from the page.
+6. **Reload afterwards.** Without the reload Facebook keeps serving the already-booted desktop bundle and
+   the content stays 901 px wide inside the 412 px viewport (`clientWidth` 412, `scrollWidth` 901). After
+   it, `clientWidth == scrollWidth == 412` — no overflow, the real mobile layout.
+7. `www.facebook.com/felhom.eu` then hung on the Facebook splash (14 divs, no images, `readyState`
+   complete). `m.facebook.com/felhom.eu` loaded properly — the redirect in step 4 only happened because the
+   user agent was still a desktop one.
+8. Set DevTools' device-mode zoom to 100 %, or screenshots come back at the scaled size (118 × 264 at 29 %).
+   `getImageData` on a Facebook CDN image throws `SecurityError` (tainted canvas), so the cover cannot be
+   analysed in the page — read it off the screenshot.
 
 ## Secret scan
 
-Run over this whole directory, with a planted control:
+Run over this whole directory, with a planted control. **`--exclude=README.md` is load-bearing: this file
+quotes the search strings verbatim, so without it the scan finds itself** (4 false `EAA` hits and 1 false
+`"access_token"`) and stops being able to tell a real hit from its own documentation.
 
 ```
 printf 'EAAfakeprobe\n' > decoy-control.txt
-grep -r -o -a 'EAA' .      ->  1      (the control, so the search works)
+grep -r -o -a --exclude=README.md 'EAA' .      ->  1      (the control, so the search works)
 rm decoy-control.txt
-grep -r -o -a 'EAA' .      ->  0
-grep -r -o -a '"access_token"' .  ->  0
-grep -r -o -a -iE 'jelszo|jelszó|password' .  ->  0
+grep -r -o -a --exclude=README.md 'EAA' .      ->  0
+grep -r -o -a --exclude=README.md '"access_token"' .  ->  0
+grep -r -o -a --exclude=README.md -iE 'jelszo|jelszó|password' .  ->  0
 ```
 
+The exclusion is safe because this file is written by hand and holds no captured output.
+
 The first pass found **1** real hit: `probe/run.log` line 1, the probe's own
 `key FACEBOOK_API: <n> chars, starts EAA` line. That is token metadata, not a token, but it was redacted
 in place before committing and the line says so. No token, no password and no personal data is in this

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.