felhom.eu/REPORT-facebook-cover-r919.md

REPORT — R-919: the Facebook cover rebuilt to the measured phone view (2026-10-09)

A REPORT-<topic>.md sibling; the shared REPORT.md was not touched. Evidence for the measurement it builds on: documentation/audits/facebook-page-setup-2026-10-08/.

1. Baseline and commits

Baseline	felhom.eu main = a76207945e, clean on the Windows tree and on DooPlex
Pushed	796a9fdf to main (no branch, explicit paths, no Co-Authored-By line)
Repos touched	felhom.eu only — marketing/facebook/, marketing/CHANGELOG.md, documentation/backlog/OPEN-ITEMS.md, this report
Built on	DooPlex (Pillow 11.1.0), not the workstation — see §4

2. Scenario A — the red-proof, with its numbers

The measured geometry was run against the three covers as committed at a76207945e, by importing build.py unchanged and overriding only the constants, so the content was today's. All three were convicted. Phone window: the centre 938,3 px of 1640 (x 351 … 1289). New SAFE (391, 40, 1249, 584). New phone QUIET (613, 345, 1054, 624).

cover	content box	past the left edge	past the right edge	content pixels under the phone circle
cover-a.png	(368, 184, 1271, 303)	368 < 391 — 23 px	1271 > 1249 — 22 px	0
cover-b.png	(328, 44, 1307, 567)	328 < 391 — 63 px	1307 > 1249 — 58 px	1017
cover-c.png	(328, 108, 1331, 455)	328 < 391 — 63 px	1331 > 1249 — 82 px	1778

Those content boxes are identical to the ones the unmodified build prints for the committed covers, which is the control that the red-proof really did run against today's content and not against a redrawn one.

The red-proof is now permanent, not a one-off. control_old_window() runs on every build, beside the circle check's own control: it draws the headline where the old 640 × 360 assumption put it (x 328) and the safe check must reject it. The build prints the two numbers that differ, because they are easy to confuse: the phone's crop edge is x 351, so 23 px of the headline were actually cut; the measured safe edge is x 391, 63 px further in, which is the 40 px MARGIN on top of the crop.

3. Scenario B — the rebuilt covers

Canonical build (DooPlex). BAND = (408, 48, 1249, 340) — inside SAFE, right of the computer circle, above the phone circle — derived from the constants, so a re-measurement moves the designs with it.

cover	content box	headline size → capital height	under the computer circle	under the phone circle
cover-a.png	(424, 172, 1231, 287)	57 → 45 px	0	0
cover-b.png	(420, 52, 1235, 575)	58 → 45 px	0	0
cover-c.png	(420, 52, 1243, 339)	47 → 37 px	0	0

CAP_MIN is 25 px (4 % of 624); the smallest headline is 37 px, about 48 % clear of the rule. Measured clearance inside the phone's own crop edges: 69–73 px on the left, 49–57 px on the right — the 40 px margin plus the layout's own air.

What changed in each design:

• A — calm. One centred line, now fitted to the band rather than the old wide safe area, with the domain under it. Nothing else.
• B — the idea. Headline left; the home, its server and its app tiles right, scaled to the band. Two of the seven tiles sit in the lower-right strip (x ≥ 1054), which is the one area below the band that a phone still shows beside the profile circle — so the composition keeps its lower half instead of ending at y 340.
• C — the product. Headline left; the dashboard right, its screen 470 → 370 px wide so the frame and its base fit between the text and the right crop edge. The screenshot's text was never legible at cover size (it renders ~280 px wide on a 1250 px Facebook cover, and did before at ~358 px); it still reads as a real product dashboard, with the sidebar, the tables and the status badges visible. It was not dropped — §8's fallback — but the operator picks, and out/preview.html shows all three.

The computer view was checked by eye on the rendered PNGs as well as by the numbers: the band sits in the cover's upper half by necessity (the phone hides the bottom middle), so each cover's glow was moved down to carry the lower half instead of leaving it flat.

4. Profile pictures — untouched, proven

before  936cb0386c8fb46c6f9f7ba7ac97b91c1d89fafef05d86f6a7ad9a4d951ec471  profile-dark.png
        f528e0820ff4e527e03d4a0a909ae74ca09d715d0ae4faff89cd3c01ea4fc5b7  profile-white.png
after   936cb0386c8fb46c6f9f7ba7ac97b91c1d89fafef05d86f6a7ad9a4d951ec471  profile-dark.png
        f528e0820ff4e527e03d4a0a909ae74ca09d715d0ae4faff89cd3c01ea4fc5b7  profile-white.png

Identical, and neither file appears in the diff. This only holds because the build ran on DooPlex. The workstation has Pillow 12.3.0; DooPlex has 11.1.0, and the two render the same text a pixel or two differently — a rebuild on Windows rewrites all six PNGs, profile pictures included, and shifts the measured content boxes (cover-a's right edge 1235 vs 1231, cover-c's fitted headline 45 vs 47). DooPlex reproduces the committed bytes exactly (a rebuild there leaves git status clean), so it is the build machine; the README now says so. Pillow was installed on the workstation for this work and used only to iterate on the design, never for the committed output.

5. The rebuilt files

file	size	Gitea
marketing/facebook/out/cover-a.png	1640 × 624, 59 KB	gitea.dooplex.hu/admin/felhom.eu/src/branch/main/marketing/facebook/out/cover-a.png
marketing/facebook/out/cover-b.png	1640 × 624, 54 KB	…/marketing/facebook/out/cover-b.png
marketing/facebook/out/cover-c.png	1640 × 624, 97 KB	…/marketing/facebook/out/cover-c.png
marketing/facebook/out/preview.html	1295 KB, self-contained	…/marketing/facebook/out/preview.html

Each PNG's size was read back from the file by the build, not taken from the constants.

6. What the operator does, in plain words

1. Upload the new cover. Open out/preview.html (download it from Gitea; it opens on its own), pick a cover — the same option as now unless the preview gives you a reason to change — and upload it to the Page by hand, the way you did last time. About a minute. The pictures cannot be set by robot (R-914).
2. Then check it on your phone, in the Facebook app. Open the Page and look at the cover: is the second line „saját szabályaid" whole, and is „felhom.eu" whole? This is the real test. What was measured was the phone website in a simulator, on one device. If the app cuts it differently, say so and the numbers move — the build follows them.

Nothing else changed: the profile picture, the texts, the button and the Page name are as they were.

7. Register

Rows before 140, after 140, opened 0, closed 0 — counted the way register_shape_gate.py counts. R-919 moved OPEN → VERIFY and stays in OPEN-ITEMS.md deliberately: the build is fixed, the result is not proven until the operator looks in the Facebook app, so it is not a finished row and does not belong in CLOSED-ITEMS.md yet. Its What now carries the fix and the red-proof numbers; its Next action is the operator's two steps and what to do if the app still cuts the cover.

8. Observations

• The computer profile circle no longer overlaps the cover at all (measured 2026-10-08: the cover ends at y 531 and the circle starts at y 547). DESK_CIRCLE still reserves the bottom-left corner as if it did. NOT-A-FINDING: deliberate. The brief said to keep the computer constants unchanged, and the reservation is conservative in the safe direction; it costs only a corner the designs do not use. It is now written down as a conservatism rather than as a fact, in the constant's own comment.
• QUIET used one formula for both circles, and that formula was only right for a left-anchored one. Applied to the measured centred phone circle it would have blanked everything from x 0 to x 1054 below y 345 — about two-thirds of the cover's lower half, for no reason. NOT-A-FINDING in the register: fixed in this session (the size rule), and it never shipped, because the phone circle was wrong anyway.
• The build is not byte-reproducible across Pillow versions. See §4. NOT-A-FINDING: not a defect, and it costs nothing once the build machine is named — which the README now does. It would become a finding only if the build moved into CI on a different image.
• The preview page claimed a phone shows 640 × 360 and drew its phone panel at that aspect. It now takes its shape, its circle and its caption from the measured constants and says MEASURED, with the source-pixel and phone-pixel diameters both spelled out (393 cover-pixels, 173 px on a 412 px screen) so neither can be read as the other. NOT-A-FINDING: fixed in this session, part of the same change.
• Nothing was uploaded, no Graph API call was made, no browser touched Facebook, and FACEBOOK_API was never read.

9. Gates, commit, CI

Gates. python3 scripts/repo_gates.py --fast on DooPlex, at the pushed commit 796a9fdf: rc = 0, „all felhom.eu gates OK”, all 18 gates OK — including register-shape, one-register, closed-register and observations, which are the ones this change could have broken. It was run twice: once on the working tree before committing, once after DooPlex pulled the pushed commit.

The gates were not run on the Windows workstation this session. The two failures they produce there (instructions, from the deliberate E:\git\CLAUDE.md divergence, and script-tests, from fcntl, symlink privilege and C:/E: mount paths) are platform artifacts documented in REPORT-facebook-page-setup.md §9; nothing in this change touches either.

Build reproducibility, proven at the pushed commit. After DooPlex pulled 796a9fdf, a plain python3 marketing/facebook/build.py exited 0 and left git status --porcelain -- marketing/ empty — the committed PNGs are exactly what the committed script produces on the build machine. Both controls fired in that run: the circle check convicted today's profile shape, and control_old_window convicted the pre-R-919 layout.

Commit. 796a9fdf40c469670269b7ae16833156a9f6dd0e, pushed to main. No branch, explicit paths staged, no Co-Authored-By line, --no-verify not used (this clone is unarmed, which is why the DooPlex run above was done by hand).

CI — green, for this commit. gates.yml run #849, commit 796a9fdf40, status tw-text-green octicon-check-circle-fill.

Two notes on how that was read, because the obvious ways are both wrong here:

• The Gitea API still refuses every credential in the store (HTTP 401; tried last session with DOCKER_USERNAME+DOCKER_PASSWORD, DOCKER_USERNAME+PASSWORD, admin+PASSWORD), so the head_sha recipe in CLAUDE.md cannot be run. The web UI serves this repo's Actions list unauthenticated, so it was read from there with curl.
• The run's own page is useless to curl: /actions/runs/849 redirects to the internal id (/actions/runs/1580, R-417's offset again) and renders through JavaScript, so its HTML carries every status word as a template string — grep finds „success”, „failure”, „running” and „cancelled” on a page whatever the outcome. The conclusion was therefore taken from the list page, and from the same flex-item row container that holds the commit link: flex-item-leading carries the icon, flex-item-main the „gates.yml #849” label and the /commit/796a9fdf40 link. Splitting the list on class="flex-item does not work — the child divs share that prefix, so the row gets chopped and the icon is attributed to a neighbour. Reading the icon off a neighbouring row is exactly how a red run gets reported green, so it is written down.

11. Operator refinements, same day (2026-10-09)

After looking at the rebuilt pictures the operator asked for two things. No geometry changed — R-919's measured constants, its band and all its checks stand, and the red-proof still convicts the old layout.

1. The profile picture carries the logo mark only. The observation was right: the mark plus the „felhom.eu" lettering was too much for 176 px, and smaller than what the Page carried before this work — because build.py shrinks the artwork until it fits inside the circle, where the original was simply cropped by it. Dropping the lettering lets the mark grow from 69 % to 76 % of the circle; the canvas goes 932 → 648 px and the floor in profile_width 720 → 640 (twice Meta's recommended 320 source; 720 was above what the mark alone needs and would have shrunk it for no gain). logo.png is split at a measured row — ink y 5–289, blank band y 290–295, wordmark y 296–403 — not at a guessed fraction. Both backgrounds now read at 40 px, which was not true before, so the preview's „dark recommended" line lost its old reason and now states the real trade-off.

2. The covers use the website's own headline setting, and the real wordmark. Read out of website/assets/site.css, .page-index .hero-text h1 is font-weight: 700; letter-spacing: -0.03em. build.py was using ExtraBold (800) with no tracking — so the cover did not in fact match the page. It now sets HEADLINE_WEIGHT = "Bold" and HEADLINE_TRACK = -0.03, with genuine per-glyph spacing. Bold is narrower, so the headlines grew: A 57 → 62, B 58 → 63, C 47 → 50 (capitals 48, 49, 39 px against the 25 px floor). „felhom.eu" is no longer typed at all: wordmark() draws the logo's own lettering, which is set in „M+ 2c" / „Vremena Grotesk" — fonts this machine does not have (R-916), so any typed version was a look-alike. The website hero shows the same logo.png on the same dark background, so the covers now match the page exactly. The DOMAIN constant was removed rather than left as dead code implying otherwise.

One mistake worth recording, caught before it shipped. The preview page's new profile paragraph added a fourth %d and I left the argument tuple in the old order, so the phone paragraph rendered „the centre 76 px of the 938-pixel width, with a profile circle 1640 cover-pixels across." Every number was a real number from the file, just the wrong one in each slot — which is exactly why it read as plausible instead of crashing. Found by reading the rendered paragraph back rather than trusting the build's exit code; fixed, and both paragraphs re-read afterwards.

Rebuilt and verified: all checks pass on DooPlex, the phone simulation still shows 0 px cut and 0 px under the profile circle on all three covers, and the renders were looked at at 1640 px, at phone width and at 176/96/40 px. New profile hashes: db05dae5… dark, a44849e4… white — they changed because changing them was the request. R-919 stays VERIFY: the operator still uploads and checks in the Facebook app.

12. Second measurement: a phone has TWO views (2026-10-09)

The operator checked the Page signed out on a phone and found the cover not cropped at the sides — the opposite of what §4 says — and then checked it signed in on his real phone, where it is cropped. Both observations are right. My R-919 measurement was not wrong; it was one view, generalised to "the phone".

Signed in, on the operator's real phone (Chrome on Android, 1080 px). Measured from the screenshot, not by eye: the cover band is y 401–1111 = 708 px tall across the full 1080 px screen = 1.525 : 1 against the file's 2.628 : 1, so the width is cropped at full height. Solving the laptop frame's left edge (cover x 814, screen x 528) against the scale gives a visible window of x 351 .. 1298; R-919's emulator said 351 .. 1289. The left edge agrees to the pixel, and the predicted screen position of the text's left edge (x 75) matches the picture. R-919 is confirmed on real hardware. Its circle: x 649–1028 from y 450, against the emulator's 637–1030 from y 369.

Signed out. Also measured from the picture: the cover box is 412 × 132 = 3.121 : 1, wider than the file, so here the height is cut, not the width — and the file's blue top rule is still visible at the top edge (rgb 0,121,199 at the first two rows), which puts the crop at the bottom: the top 525 px of 624 survives, the bottom 99 px does not. The profile circle is far bigger and higher: x 486–1150 from y 232, 41 % of the width.

What that means for a cover. The sides are cut for one visitor and the bottom for the other, so the two constraints have to be met together: SAFE is now (391, 40)–(1249, 485) and the binding circle is the signed-out one. Two changes made the result workable rather than merely safe:

• The circles are DISCS. They were modelled as rectangles running to the bottom of the cover. Near its top a disc is only a few pixels wide, so the rectangle was discarding most of the lower cover for nothing — a large part of why the frame looked empty.
• Two layers. The READ layer (catchphrase, wordmark) must survive every view; the check fails on it. The DECOR layer (the laptop, the home motif) may be cropped or covered, and the build reports the cost instead of forbidding it — cover B loses 39 % of its decor in some view, cover C 62 %. Before the split, one check governed both, which is why no laptop big enough to read could ever pass.

Red-proof, again. Before redrawing anything, the two-view geometry was run against the covers as they then stood: all three convicted — cover A 908 content pixels under a circle (its wordmark sat inside the signed-out circle), cover B 1715 plus content past the cut bottom, cover C 1962. The permanent control_old_window control still convicts the original pre-R-919 layout too, so the build now carries two controls.

The redraw. Cover C is the operator's own idea: catchphrase and wordmark on the left, the dashboard on the right at 640 px wide (was 370) running off the right edge — readable for the first time. Cover B's home motif grew the same way. Cover A is unchanged in kind, lifted into the tighter band. All three keep every capital above the 25 px floor (48, 45, 43 px).

Still unmeasured: the Facebook app. Three views are now measured and they disagree with each other and with Meta's help page. The app is the fourth and the most used. R-919 stays VERIFY for that reason.

13. CI run #856 went RED, and it is the runner, not the code (2026-10-09)

gates.yml run #856 for b9073e8f reports Failure. It is an infrastructure failure, and the evidence is in the shape of the job, not in any gate:

• „Set up job” took 11m54s and passed. It normally takes seconds, and the whole run normally takes about 4m40s.
• Every step after it failed at 0s with an empty log — Fetch the pushed commit, Fetch the agent, Fetch the controller CHANGELOG, Fetch the app catalog, Classify the push, Run the gate entry point, Alarm on failure, Complete job. The gate entry point never ran, so no gate verdict exists in that run at all.
• DooPlex was simultaneously running another session's agent 0.154.0 delivery, which is Docker-heavy; resource contention on the runner is the likeliest cause. Not proven, so it is written as the likeliest cause and not as the cause.

The gates themselves are green at that exact commit. python3 scripts/repo_gates.py --fast was run in a throwaway worktree checked out at b9073e8f and placed beside the sibling repos (/mnt/5_hdd/felhom.eu/git/felhom.eu-r919verify, so ../felhom-agent, ../felhom-controller and ../app-catalog-felhom.eu resolve the way CI arranges them): rc = 0, all 18 gates OK. The worktree was removed afterwards and git worktree list shows only the main tree.

A first attempt at that check was misleading and is recorded so the mistake is not repeated. Run from /tmp, the same commit produced script-tests FAILED and five INCONCLUSIVE gates — entirely because the sibling repos were not beside it. A gate run at the wrong path is not a gate run; it convicts the layout, not the commit.

What is NOT claimed: that CI passed. It did not run. This commit re-triggers it, and the next run's verdict is the one to read.

14. The Facebook app, measured — and cover C to the operator's layout (2026-10-09)

The app is no longer the unmeasured view. The operator opened the live Page in Facebook Lite and in Chrome on his phone. Both screenshots were solved the same way as before, against the laptop frame whose position in the file is known:

view	cover band	visible window	profile circle
Chrome on the phone	1.510 : 1	x 349 .. 1291	x 645..1021, top y 451
Facebook Lite app	1.508 : 1	x 349 .. 1290	x 645..1021, top y 453

The app crops exactly like signed-in mobile web, and both agree with R-919's emulator (351..1289). Their circle sits lower than the emulator's y 369, so that figure was pessimistic, not wrong — the margin it bought was real. Five views are measured now, and the signed-out one is still the binding constraint.

Cover C now follows the operator's draft: the wordmark big on top (88 px, was 44), a small gap, then the catchphrase. One thing had to give, and it is written down rather than quietly decided:

• Drawn as he sketched it — big wordmark and two catchphrase lines — the block measured 392 sampled text pixels behind the signed-out circle: „saját szabályaid" read „saját szab" in that view. That is the R-919 defect itself, so it was not shipped.
• Sizing the two lines to fit above y 232 instead works out at a 25 px capital — exactly the legibility floor, and a big step down from the 43 px the cover had.
• One line keeps all three things: the wordmark big (88 px), the capital at 34 px, and 0 text pixels behind any circle in any of the five views. The laptop moved right and shrank to 540 px to free the width; 64 % of it is cropped or covered somewhere, which is what the decor layer is for and what the build reports.

10. Teardown

Nothing on any host, the hub or Facebook. The work ran in the two git working trees only; the throwaway red-proof and phone-simulation scripts live in this session's scratchpad and /tmp on DooPlex, and the DooPlex copy was removed. No guest, no container, no service was started or stopped.