felhom.eu/REPORT-facebook-page-setup.md

REPORT — Facebook Page setup (2026-10-08, Windows + Claude in Chrome)

Task: marketing/facebook/TASK-page-setup-windows.md. Evidence: documentation/audits/facebook-page-setup-2026-10-08/ (its README.md holds the method and the read-back table). This file is a REPORT-<topic>.md sibling; the shared REPORT.md was not touched.

1. Baseline and pushed commit

Baseline	felhom.eu main = 1d692734, clean on the Windows tree and on DooPlex before the run
Pushed	8664cbda to main (no branch, no Co-Authored-By line, explicit paths staged)
Repos touched	felhom.eu only (marketing/, documentation/, REPORT-facebook-page-setup.md)

2. Phase A — Meta's figures, and how they compare

Read first-hand from https://www.facebook.com/help/125379114252045 at 18:04:31 UTC; quoted verbatim in A-meta-sizes.md. Meta says: profile picture shown 176 × 176 on a computer, 196 × 196 on a smartphone, 36 × 36 on a feature phone, circle-cropped, best source 320 × 320; cover 16:9 on a computer and 2,4:1 on a phone, minimum 400 × 150 either way, fastest as sRGB JPG 851 × 315 under 100 kB; the profile circle overlaps the cover by about 40 px on mobile; PNG beats JPG for a picture carrying a logo or text.

Different from ours, and mostly by absence. marketing/facebook/README.md asserted a cover shown 820 × 312 on computers and 640 × 360 on phones, and a profile-circle overlap of 16 px / 176 px and 24 px / 196 px. None of those figures is on Meta's page. Only the 176 px profile size matched. Meta's mobile overlap (~40 px) is larger than the 24 px we assumed, and 640 × 360 is 16:9 — which Meta puts on the computer, not the phone. Meta's page also contradicts itself: 16:9 and 2,4:1 and one recommended 851 × 315 (2,70:1) file for both. Recorded, not resolved.

Are the pictures still safe? Not rebuilt here, as the task says. Our 1640 × 624 PNG is far above both stated minimums and is the format Meta prefers; the 932 × 932 profile source is larger than Meta's 320 × 320 recommendation, so it is downscaled, never enlarged. Phase C measured the computer case directly and it is clean. The grade in README.md now reads „READ, Meta's help page", with what Meta does and does not confirm spelled out.

3. B1–B5, one line each

#	Edit	Result	Read-back, and from where
B1	Intro → COPY.md §1	done	Graph GET /{page}?fields=about on DooPlex: 99 chars / 111 bytes, hex equal yes. The before-run C1-page.json holds a different, 134-char value, so the change is visible across the pair
B2	About → details → COPY.md §2	REFUSED — the field does not exist	n/a. Graph description, general_info, bio all read null; four UI surfaces checked and none offers a long description. Filed R-917
B3	Action button → website	done, as „További információ"	Page header „…" → „Műveletgomb módosítása" (a different entry point than the setup card that set it): „További információ", https://felhom.eu/
B4	Messenger welcome → COPY.md §3, on	done, on the second save	the automation reopened from its own URL after a reload: 120 chars / 134 bytes, hex equal yes; toggle „Bekapcsolva"
B5	Username	done — felhom.eu	Graph GET /{page}?fields=username → "felhom.eu", and facebook.com/felhom.eu loads the Page

Three things in that table need their own paragraph.

B2 — this is the one that could not be done. The task assumed a „Névjegy → Részletek" long-description field. There is none. Checked, 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", which redirects back to the Névjegy tab; and settings → „Oldal beállítása" (name, access, type, history, status, recommendation, messaging, data sharing). The Graph fields are null. Writing description by API would need pages_manage_metadata, which the robot key does not have and which fence 3 forbids adding. No Hungarian copy was shortened — that is the operator's call, and R-917 lays out four options with (c), publish §2 as the first pinned post after the app goes Live, recommended.

B3 — the label in the task does not exist either. The action-button chooser offers no „Weboldal". The full list is Foglalás most, Regisztráció, Rendelés indítása, Jegyvásárlás, Üzenet küldése, WhatsApp-üzenet küldése, Hívás most, E-mail küldése, Kapcsolatfelvétel, További információ, Megnézem most, Csoport felkeresése, Játék indítása, Megveszem, Foglalás. The only generic website-opener is „További információ — Webhely megnyitása", so that is what was set. Facebook normalised the URL from https://felhom.eu to https://felhom.eu/. Before the edit the button was „Üzenet küldése".

B4 — a red error toast was a partial write. The first save answered „A módosítás nincs mentve." and the text did not change. Reloading showed the URL had gained an automation_id and the automation existed and was switched on — carrying Meta's default Hungarian greeting, not ours. So Meta refused the text and still created and enabled the rule. (The on/off toggle also would not move before the automation existed: clicked at its measured centre and via .click() on the role="switch" input, aria-checked stayed false.) With the automation now existing, pasting §3 again and saving gave „Mentve. A változtatások alkalmazása eltarthat egy ideig.", and the reopened automation reads back hex-equal with the toggle on. This is the inverse of the project's „HTTP 200 can be a REFUSAL" trap: here the error was the thing that lied. Small, fixed in the session, no row — but it is in marketing/CHANGELOG.md because the next person on that screen must reopen it and read the text back rather than trust either toast.

One side effect worth naming. The old about carried https://felhom.eu as its first line, so the Page header used to show that as a blue link. Replacing the intro with §1 removed it. The website field is untouched (https://felhom.eu/), it still shows under „Hivatkozások", and the new action button now does that job more prominently. Nothing to fix; said here so it is not read later as a regression.

4. Phase C — the four checks

Measured at a 1435 px viewport (C1-page-computer-1435px.jpg), with the geometry read from the DOM:

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.
2. The cover headline and „felhom.eu" are whole — pass at computer width. The cover renders 1059 × 403 from the natural 960 × 365 Facebook re-encode of our 1640 × 624 PNG, object-fit: fill, and the image rectangle equals its container's rectangle exactly: no crop, and 2,6301 vs 2,6316 is a 0,06 % distortion. The container caps at 1250 px, so a 2067 px viewport renders the identical cover (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.

No cut was found at the width that could be measured, so nothing was re-cropped on Facebook.

5. Secret scan, with its control

Over the whole evidence directory: control planted (EAAfakeprobe) → grep -r -o -a 'EAA' = 1; control removed → 0. "access_token" = 0. jelszo|jelszó|password = 0.

The first pass returned 1 real hit: probe/run.log line 1, the probe's own key FACEBOOK_API: <n> chars, starts EAA line — token metadata, not a token. It was redacted in place before committing and the replacement line says so. No screenshot of the credentials file, a token page, the Messenger inbox or the operator's personal profile was saved; the one screenshot that caught the re-auth dialog (with the operator's name and avatar) was deliberately not copied into the evidence directory.

6. What the operator still does

• R-917 — decide where COPY.md §2 goes (a leave it unused / b rewrite one of §1-§2 to fit 255 characters / c publish it as the first pinned post after Live / d ask Meta). Recommended c. If nothing is decided, the Page carries only the 99-character intro — which is a working state, not a broken one.
• 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.

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.

8. Teardown — three layers

• Machine: nothing. No host, no guest, no box, no hub was touched. Two throwaway read-only scripts were written to DooPlex /tmp (fb_fields.py, fb_fields2.py) and nothing in the DooPlex working tree was changed; the probe wrote only to DooPlex /tmp, from where the JSON was copied here.
• Facebook: no post, no story, no reel, no comment, no message sent, no like, no follow, no invite. No ad, no boost, no Meta Verified, no payment or monetisation setting. No app change — felhom.eu (2273465403490709) stays in development mode. No business-portfolio change, no new permission, no new token, no Page-role change. No consent or terms banner accepted. The one automation created is the Messenger auto-reply that B4 asked for, and it carries our text.
• Hub: nothing.

9. Gates, commit, CI

Gates. python scripts/repo_gates.py --fast on Windows exits 1, and both failures are platform artifacts of this clone, not of the change:

• instructions — „E:\git\CLAUDE.md and documentation/runbooks/workspace-CLAUDE.md have diverged". That divergence is deliberate and documented in E:\git\CLAUDE.md's own header („Do not edit it to match this one"); neither file was touched by this commit.
• script-tests — ModuleNotFoundError: No module named 'fcntl', OSError: [WinError 1314] A required privilege is not held by the client (symlink), ValueError: path is on mount 'C:', start on mount 'E:', and a systemd unit path the test writes. All Linux-only.
• wire-contract was INCONCLUSIVE for a type in the felhom-agent sibling repo, also unrelated.
• The runner itself first died with UnicodeEncodeError: 'charmap' codec — the Windows cp1250 console. Re-run with PYTHONIOENCODING=utf-8 PYTHONUTF8=1 to get a readable result.

The authoritative run is on DooPlex, at exactly the pushed commit. After git pull to 8664cbda: python3 scripts/repo_gates.py --fast → rc = 0, „all felhom.eu gates OK", all 18 gates OK (including instructions, script-tests and wire-contract). golden-currency is OK waived by R-468 until 2026-10-13 — unchanged by this session, which baked nothing.

Commit. 8664cbda78e121572ce7374ba59ddad3e66b6c21, pushed to main. git push --no-verify was NOT used. This clone is unarmed (core.hooksPath unset), so the pre-push hook did not run here — which is why the DooPlex run above was done by hand.

CI — confirmed green by run, for this commit. gates.yml run #846, job gates, commit 8664cbda78, branch main, Success, total duration 4m39s (documentation/audits/facebook-page-setup-2026-10-08/D-ci-run-846-green.jpg).

Two notes on how that was read, because the usual recipe did not work:

• The Gitea API could not be authenticated. GET /api/v1/repos/admin/felhom.eu/actions/jobs returned HTTP 401 „invalid username, password or token" for DOCKER_USERNAME + DOCKER_PASSWORD, DOCKER_USERNAME + PASSWORD, and admin + PASSWORD. Those are the only plausible keys in ~/.config/credentials (the store holds no Gitea-named key). So the head_sha matching recipe in CLAUDE.md's end-of-session checklist could not be run. The run was read instead from Gitea's web UI, which serves this repo's Actions list without signing in — a different channel, and the conclusion was read off the run page, not inferred.
• R-417's id offset showed itself again. /actions/runs/846 redirected to /actions/runs/1573: the number in the list („gates.yml #846") is the run index, the number in the URL is the internal id. Both are on the screenshot, so neither can be quoted alone later and mistaken for the other.

scripts/unproven.py --summary (run on DooPlex): 55 claims, walked 20, partial 17, built 14, missing 4, NOT WALKED 35 of 55. No number moved — this session proved nothing about the product's claims; it set Page settings and read Meta's size page.