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.

REPORT-facebook-page-setup.md

@@ -82,7 +82,8 @@ that job more prominently. Nothing to fix; said here so it is not read later as
 
 ## 4. Phase C — the four checks
 
-Measured at a **1435 px** viewport (`C1-page-computer-1435px.jpg`), with the geometry read from the DOM:
+Computer width measured at a **1435 px** viewport (`C1-page-computer-1435px.jpg`); phone width on an
+emulated **Pixel 9** (`C2-page-phone-pixel9-412px.jpg`). Geometry read from the DOM in both cases.
 
 1. **The profile circle does not cut the logo** — **pass.** Rendered 168 × 168; zoomed on it, the cloud,
    house, keyhole, server and the „felhom.eu" lettering are all whole.
@@ -93,16 +94,28 @@ Measured at a **1435 px** viewport (`C1-page-computer-1435px.jpg`), with the geo
    (`C1-page-computer-2067px.jpg`) — the requested 1440 px and the 1435 px measured are the same case.
 3. **The profile circle does not cover cover text** — **pass.** Its top edge sits 16–17 px *below* the
    cover's bottom edge; at this width it does not touch the cover at all.
-4. **Phone width (390 px)** — **NOT performed.** `resize_window` reported success while the window was
-   maximised and changed nothing (`innerWidth` 2133); after the operator un-maximised it, only the first call
-   after each window-state change took effect. At about 500 px wide, **`www.facebook.com` kept the desktop
-   layout and grew a horizontal scrollbar** — `innerWidth` pinned at 1105, `scrollWidth` 2051
-   (`C3-narrow-window-horizontal-scroll.jpg`) — and `m.facebook.com/felhom.eu` redirected to
-   `www.facebook.com/felhom.eu?_rdr`. The phone view needs a mobile user agent, which these tools do not set.
-   Filed **R-918**. The arithmetic (a 2,4:1 crop of 1640 × 624 loses ~71 px a side; the safe area is 306 px
-   clear) says the headline should survive, but that is arithmetic and is reported as such, not as a check.
+4. **Phone width** — **performed on a second pass, and it FAILS.** The operator switched the tab to Chrome
+   DevTools device mode, **Pixel 9** (412 × 924, dpr 2,625, Android user agent). The mobile Page header
+   renders **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**. `build.py`'s safe area is the
+   centre 1028 × 544, i.e. 306 px clear of each edge, which is **45 px per side wider than the phone shows**.
+   Measured on the shipped `out/cover-c.png`: the light text runs x 333 → 997, 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 „**elhom.eu**" (`C2-phone-headline-cut-closeup.png`). The mobile profile circle is also 172 px
+   and centred, overlapping the bottom 112 px of the cover — source x 637–1030 × y 369–624 — which hides part
+   of the dashboard picture but no text. Filed **R-919**.
 
-No cut was found at the width that could be measured, so nothing was re-cropped on Facebook.
+**A cut was found on the phone, and nothing was re-cropped on Facebook** — the task's fence says a cut is a
+finding, and the fix belongs in `marketing/facebook/build.py`'s safe area, with the operator re-uploading the
+rebuilt cover. The computer-width checks above all still pass.
+
+**The arithmetic in the first pass was wrong, and why matters.** Before the measurement this report carried:
+„a 2,4:1 crop of 1640 × 624 loses ~71 px a side; the safe area is 306 px clear, so the headline should
+survive." The method was sound; the input was not. It trusted **Meta's own stated mobile ratio of 2,4:1**,
+and the Page header actually renders **1,504:1** — so the real crop is about five times deeper than
+predicted. Meta's help page is wrong about Meta's own rendering. This is the second time in one session that
+this page's figures did not survive contact with the product (§2 is the first), and it is the reason the
+prediction was labelled arithmetic rather than a check.
 
 ## 5. Secret scan, with its control
 
@@ -123,15 +136,28 @@ dialog (with the operator's name and avatar) was deliberately **not** copied int
 - **R-915 — switch the Meta app to Live** before any real public post; it needs a Terms of Service URL
   (blocked on R-813). `COPY.md` §4, the first three posts, waits on this and was out of scope here.
 - **R-916 — the vector logo master**, on the machine that has the „M+ 2c" and „Vremena Grotesk" fonts.
-- **R-918 — the phone check**: open `facebook.com/felhom.eu` on a phone, or Ctrl+Shift+M in Chrome at
-  390 × 844, and say whether the cover headline is cut.
+- **R-919 — the cover is cut on phones.** Nothing for you until the covers are rebuilt with a narrower safe
+  area (a CC job); then you re-upload the chosen cover by hand, as the pictures are not settable by API
+  (R-914). Until then every phone visitor sees „aját szabályaid" and „elhom.eu".
 
 ## 7. Register
 
-Rows before **138**, after **140**, opened **2** (R-917, R-918), closed **0** — counted the way
-`register_shape_gate.py` counts (`| **R-n** |` lines). `STATUS.md` had said 139 before this session and now
-says 140, the counted number. Section counts updated:
-Business & legal 9 → 10, Process & tooling 23 → 24. R-915 stays open as the task says.
+Rows before **138**, after **140**, opened **3** (R-917, R-918, R-919), closed **1** (R-918, opened and
+closed the same evening — the phone check it asked for was done, and its own finding is R-919). Counted the
+way `register_shape_gate.py` counts (`| **R-n** |` lines). R-915 stays open as the task says.
+
+Section counts: Business & legal 9 → 12, Process & tooling 23 → 23 (R-918 in, R-918 out).
+
+**Two pre-existing count errors, noticed while editing, one fixed.** `STATUS.md` said the register was at
+**139** when the counted number was **138**; it now says 140, the counted number. The Business & legal header
+said „9 rows (P2 4, P4 5)" when the section actually held **10** rows with **5** at P2 — I corrected that
+header to the truth (12 rows, P2 5, P3 1, P4 6) because this session changed that section. **Other section
+headers are also drifting** and were left alone as out of scope: Backup & restore says P2 5 / P4 14 where
+the rows are P2 4 / P4 15; Storage & devices says 6 where there are 5; Security & access says 15 where
+there are 16; Box system & updates says 6 where there are 7; Monitoring & notifications says 17 where there
+are 16. A whole-file recount is a deliberate job for a session that owns the register, not a side effect of
+this one. (A strict parse also totals 141 against the gate's 140 — one row id is not purely numeric, so the
+gate's `| **R-n** |` pattern skips it. The gate's number is the canonical one.)
 
 ## 8. Teardown — three layers
 

STATUS.md

@@ -19,10 +19,15 @@
   Suite, not in the settings. The best use for it is to publish it as the Page's first post once the app is „Live"
   (below). If you do nothing: the Page carries only the short introduction, which is fine, and the long text waits
   in the file.
-- **The pictures look right on a computer** — the cover is shown whole, nothing is cut, and the round profile
-  picture does not cover it. **Nobody has checked the Page on a phone.** A desktop browser cannot show Facebook's
-  phone layout, so it needs a real phone: open facebook.com/felhom.eu on yours and tell me whether the headline
-  and „felhom.eu" on the cover are whole.
+- **On a computer the pictures look right** — the cover is shown whole, nothing is cut, and the round profile
+  picture does not cover it.
+- **On a phone the cover is cut, and we should fix it (needs a short job from me, then 2 minutes from you).**
+  Facebook shows phones only the middle 57 % of the cover's width. That is narrower than we built for, so the
+  first letter of a line is lost: the cover reads „aját szabályaid" instead of „saját szabályaid", and „elhom.eu"
+  instead of „felhom.eu". Nobody saw this before because a normal browser window cannot show Facebook's phone
+  layout; it took a phone simulator. I did **not** re-crop anything on Facebook. The fix is to rebuild the covers
+  with a narrower safe middle, then you upload the new one by hand. If you do nothing: every phone visitor sees
+  the cut headline.
 - **Before real posts:** switch the Meta app to „Live". It needs a Terms of Service web address (the legal pages
   item). If you do nothing: posts are seen only by people with a role on the app.
 - **When you have time:** the logo needs a clean vector copy, made on the machine that has its fonts. If you do

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.

marketing/CHANGELOG.md

@@ -19,9 +19,21 @@ Evidence: `documentation/audits/facebook-page-setup-2026-10-08/`; report: `REPOR
   **none** of the 820 x 312 / 640 x 360 figures the section asserted; only the 176 px profile size matched,
   and Meta's mobile profile overlap is ~40 px where we assumed 24. Meta's own page contradicts itself (16:9
   on a computer, 2,4:1 on a phone, one 2,70:1 file recommended for both). What we build is unchanged.
-- **Measured on the live Page** at a 1435 px viewport: the cover renders whole — no crop, no distortion — the
-  container caps at 1250 px, and the profile circle sits 16 px clear below the cover. The **phone** check was
-  **not** performed: narrowing a desktop browser never gives Facebook's phone layout (**R-918**).
+- **Measured on the live Page at a 1435 px viewport: fine.** The cover renders whole — no crop, no distortion
+  — the container caps at 1250 px, and the profile circle sits 16 px clear below the cover.
+- **Measured on an emulated Pixel 9: the cover is CUT on phones (R-919).** The mobile Page header is
+  412 x 274 = **1,504:1**, so Facebook shows only the **centre 938 px of the cover's 1640 px width** — 351 px
+  off each side. `build.py`'s safe area leaves 306 px clear per side, **45 px too few**, so 18 px of the text
+  is lost: the headline reads „aját szabályaid" and the wordmark „elhom.eu" on every phone. Nothing was
+  re-cropped on Facebook; the fix is `build.py`'s safe area (≤ 938 px, ~900 for margin) plus the measured
+  172 px centred phone profile circle, then the operator re-uploads. **Meta's own 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 the first-pass
+  arithmetic built on Meta's figure under-predicted the crop about fivefold.
+- **How to see Facebook's phone layout** (it cost several wrong turns, recipe in the audit README): narrowing
+  the window never works — `www.facebook.com` has a minimum width and only grows a horizontal scrollbar, and
+  `m.facebook.com` redirects to `www` under a desktop user agent. DevTools device mode with a device chosen
+  **and then a reload** does it; without the reload the already-booted desktop bundle stays (content 901 px
+  wide in a 412 px viewport). `www` then hangs on the splash under the mobile agent — `m.facebook.com` loads.
 - **Gotcha, fixed in the session, no row.** In Business Suite the automatic-reply editor refused the first
   save with „A módosítás nincs mentve." **and still created the automation and switched it on — carrying
   Meta's default Hungarian greeting, not ours.** A red error toast was therefore a partial write. Reopening

marketing/facebook/README.md

@@ -44,11 +44,26 @@ phones, profile circle over the cover at 16 px / 176 px and 24 px / 196 px; sour
 fasturtle.com) appear **nowhere on Meta's page**; only the 176 px profile size matched. The mobile overlap we
 assumed, 24 px, is smaller than the ~40 px Meta states.
 
-What we build is unchanged and still safe: the cover at 2 x, **1640 x 624**, well above both stated minimums, as
-PNG; the profile picture 932 x 932, larger than Meta's 320 x 320 recommendation and therefore downscaled, not
-enlarged. **MEASURED on the live Page 2026-10-08** at a 1435 px viewport: the cover renders whole — no crop, no
-distortion — and the profile circle sits 16 px below the cover, so it covers no cover text. The phone rendering
-was **not** measured (R-918); the same audit explains why a narrowed desktop browser cannot show it.
+What we build: the cover at 2 x, **1640 x 624**, well above both stated minimums, as PNG; the profile picture
+932 x 932, larger than Meta's 320 x 320 recommendation and therefore downscaled, not enlarged.
+
+**MEASURED on the live Page 2026-10-08, both widths:**
+
+- **Computer (1435 px viewport): fine.** The cover renders whole — no crop, no distortion — the cover container
+  caps at 1250 px, and the profile circle sits 16 px *below* the cover, so it covers no cover text.
+- **Phone (emulated Pixel 9, 412 x 924): the cover is CUT — R-919.** The mobile Page header is
+  **412 x 274 = 1,504:1**, so Facebook keeps the full height and shows only the **centre 938 px of the 1640 px
+  width (57,2 %)** — **351 px cut from each side**. The safe area below is the centre 1028 x 544, i.e. 306 px
+  clear of each edge, which is **45 px per side too wide**. In `out/cover-c.png` the light text runs x 333 to
+  x 997 against a left crop edge of x 351, so **18 px of it are cut**: the headline reads „aját szabályaid" and
+  the wordmark „elhom.eu" on every phone. The mobile profile circle is **172 px and centred**, hiding source
+  x 637–1030 x y 369–624 — part of the dashboard picture, no text.
+
+**So `build.py`'s safe area is wrong for phones** and needs narrowing to the centre **≤ 938 px at full height**
+(use ~900 px for margin), with the phone profile-circle exclusion widened to the measured centred 172 px shape —
+shown failing on today's covers first. **Meta's stated mobile ratio of 2,4:1 is not what the Page header does**
+(1,504:1 measured), which is why a figure from Meta's page is not a substitute for looking at the Page. Getting
+Facebook's phone layout at all needs DevTools device mode **plus a reload**; the audit's README has the recipe.
 
 Page `about` = 100 characters: developers.facebook.com/docs/graph-api/reference/page/ (Meta, first-hand). The
 Page's own „Bemutatkozás" editor counts to **255** (seen on screen 2026-10-08); §1 is 99 characters, so neither