Files
felhom.eu/documentation/audits/facebook-page-setup-2026-10-08
admin 6a2670101a
gates / gates (push) Successful in 4m42s
marketing/facebook: report filled in (gates, CI run #846 green), STATUS updated
The DooPlex gate run at 8664cbda is rc=0, all 18 gates OK; the Windows run's two
failures are platform artifacts (fcntl, symlink privilege, C:/E: mount, cp1250
console) and the deliberate workspace-CLAUDE.md divergence.

CI gates.yml #846 for 8664cbda78: Success, 4m39s. The Gitea API refused every
credential in the store (401), so the run was read from Gitea's web UI, which
serves the Actions list unauthenticated; /actions/runs/846 redirects to
/actions/runs/1573, R-417's index-vs-id offset again, so both numbers are on the
screenshot.

STATUS: the Facebook section rewritten for what is now live, the open-items
count corrected to the counted 140.
2026-10-08 20:57:30 +02:00
..
…

Facebook Page setup — evidence, 2026-10-08

Task: marketing/facebook/TASK-page-setup-windows.md. Run from the Windows workstation with Claude in Chrome (the operator's own Chrome, logged in as the Page admin); the Graph read-backs ran on DooPlex, where the credentials file is.

Baseline felhom.eu main = 1d692734 (clean on both working trees before the run).

What is in here

File What it is
A-meta-sizes.md Phase A — Meta's own size page, quoted verbatim, with the comparison against our README
A-meta-sizes-screenshot.jpg the same page on screen
B0-page-before.jpg the Page before any edit (old intro text visible)
B1-intro-after.jpg the Page after the intro was replaced
B3-action-button-readback.jpg the action button read back from the Page header „…" menu (a different entry point than the one that set it)
B4-messenger-welcome-refused-attempt.jpg the welcome message typed in, on the attempt Meta refused
B4-messenger-welcome-after.jpg the saved automation, on, with our text
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
C3-narrow-window-horizontal-scroll.jpg the proof that narrowing the window does NOT give the phone layout (see below)
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

The read-backs, each from a different channel than the edit

Edit Made in Read back from Result
B1 intro the Page's „Névjegy" editor Graph API GET /{page}?fields=about (DooPlex, Page token) about = 99 chars / 111 bytes, hex equal to COPY.md §1; the before run holds a different 134-char value
B3 action button the „Az oldalad beállításának befejezése" card the Page header „…" → „Műveletgomb módosítása" „További információ", https://felhom.eu/
B4 Messenger welcome Business Suite → Bejövő üzenetek → Automatizálások the automation reopened from its own URL after a reload 120 chars / 134 bytes, hex equal to COPY.md §3; toggle „Bekapcsolva"
B5 username Facebook settings → Oldal általános beállításai Graph API GET /{page}?fields=username and loading facebook.com/felhom.eu username = felhom.eu; the address loads the Page

Hex comparisons were made against the fenced blocks of marketing/facebook/COPY.md, read from the file — never retyped. The in-page text was read with TextEncoder in the browser and compared byte for byte.

Phase C — what was measured and what was not

Computer width: measured, nothing is cut. At a 1435 px viewport the cover renders 1059 × 403 from the natural 960 × 365 Facebook re-encode of our 1640 × 624 PNG; object-fit: fill, and the image's rectangle equals its container's rectangle exactly, so no crop and no visible distortion (2.6301 vs 2.6316 — 0.06 %). The cover container is capped at 1250 px, so a 2067 px viewport shows the same picture; the requested 1440 px and the 1435 px measured are the same case. The headline „Saját felhőd, saját szabályaid" and „felhom.eu" are whole. The profile circle renders 168 × 168 and its top edge sits 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:

  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).
  2. The operator un-maximised the window; resizing then worked, but only the first call after a window 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.
  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 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.

Secret scan

Run over this whole directory, with a planted control:

printf 'EAAfakeprobe\n' > decoy-control.txt
grep -r -o -a '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

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 directory; the Messenger inbox, the credentials file and the operator's personal profile were never screenshotted.