marketing/facebook: Page settings set by hand (intro, action button, Messenger welcome, username felhom.eu)

Ran marketing/facebook/TASK-page-setup-windows.md from the Windows workstation
through Claude in Chrome. Evidence in
documentation/audits/facebook-page-setup-2026-10-08/, report in
REPORT-facebook-page-setup.md.

Done, each read back from a different channel than the edit: the intro is
COPY.md §1 (Graph `about` hex-equal, 99 chars); the action button is
"További információ" to https://felhom.eu/; the Messenger welcome is COPY.md §3
(hex-equal) and the automation is on; the username is felhom.eu, so the Page
answers at facebook.com/felhom.eu.

Not done: COPY.md §2 has no field to go in — Facebook's current Pages
experience has no long-description field and the Graph `description` is null
and unwritable with the robot key's scopes. R-917, four options, operator's
call; no Hungarian copy was shortened.

Phase A read Meta's size page first-hand: it carries none of the 820x312 /
640x360 figures our README asserted, and its own two ratios contradict the file
it recommends. README's grade and comparison rewritten; what we build is
unchanged.

Phase C measured the computer width (cover whole, no crop, profile circle 16 px
clear). The 390 px phone check was NOT performed: narrowing a desktop browser
never gives Facebook's phone layout. R-918.

Nothing posted; no ad, no boost, no Meta Verified; the Meta app stays in
development mode; no host, guest, box or hub touched.

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 — 9 rows (P2 4, P4 5)
+## Business & legal — 10 rows (P2 4, P4 6)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -277,8 +277,9 @@ stopping line that lies.
 | **R-914** | Business & legal | P4 | **Write the Felhom Facebook Page skill from the spike's findings.** Spike 2026-10-08 (`audits/SPIKE-facebook-page-api-2026-10-08.md`): key valid, never expires; the Page (`1360018983863273`) is reached with CREATE_CONTENT/MODERATE/ANALYZE; a scheduled text post and a scheduled photo were created, read back byte-equal and deleted (removal proven). Probe `scripts/facebook/fb_probe.py`. Gap to close in the skill: a scheduled photo's publish state was not read (no `post_id` returned). **2026-10-08 (Page pictures task) — two more for the skill:** (1) **the removal proof was not a proof**: the text post's after-DELETE answer was (#10) „does not exist, cannot be loaded due to missing permission…" — that message also means a permission gap. The skill proves removal by listing the Page's scheduled posts before and after the delete (present, then absent); the operator's Planner view on 2026-10-08 showed nothing on 15 October (a different channel, by eye). (2) **pictures by API** (READ, developers.facebook.com/docs/graph-api/reference/page/picture and …/reference/page/): `POST /{page}/picture` needs the `MANAGE` task, which the robot does not have (measured task list); the cover is `POST /{page}` `cover=<photo id>`, „only by the Page Admin or Page Editor with `EDIT_PROFILE`" + `business_management`. Neither names `pages_manage_metadata`. Today the pictures are uploaded by hand (`marketing/facebook/README.md`). | **READY — owner: CC** | — | Write the skill (drafts scheduled for operator review by default); read a scheduled photo back through the Page's scheduled-post listing | CC |
 | **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 |
 
-## Process & tooling — 23 rows (P3 3, P4 20)
+## Process & tooling — 24 rows (P3 3, P4 21)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -305,6 +306,7 @@ 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.