Files
felhom.eu/marketing/CHANGELOG.md
T
admin b9073e8fb6
gates / gates (push) Failing after 11m54s
marketing/facebook: a phone has TWO views of the cover, not one (R-919)
You saw the cover uncropped signed out, after R-919 said the sides are cut.
Both are true; my first measurement was one view generalised to "the phone".

SIGNED IN, confirmed on your real phone (Chrome/Android, 1080 px): the crop is
real. The cover band is 708 px tall across 1080 = 1.525:1 against the file's
2.628:1, and solving the laptop frame's left edge against that scale puts the
window at x 351..1298 where the emulated Pixel 9 said 351..1289 -- the left edge
to the pixel. R-919 is confirmed on hardware, not replaced.

SIGNED OUT, measured from your screenshot: the box is 412x132 = 3.121:1, WIDER
than the file, so the height is cut, not the width -- and the file's blue top
rule is still visible at the top edge, which puts the cut at the BOTTOM: the top
525 px of 624 survives. The circle is far bigger and higher: x 486..1150 from
y 232, 41% of the width.

So the sides are cut for one visitor and the bottom for the other. build.py now
carries both views; SAFE is their intersection, (391,40)-(1249,485).

Two changes made that workable rather than merely safe:
- the circles are modelled as DISCS, not rectangles running to the bottom. Near
  its top a disc is a few pixels wide; the rectangle was discarding most of the
  lower cover for nothing, which is much of why the frame looked empty.
- TWO LAYERS. The READ layer (catchphrase, wordmark) must survive every view and
  the check fails on it. The DECOR layer may be cropped or covered, and the build
  REPORTS the cost instead of forbidding it (B 39%, C 62%). Before the split one
  check governed both, so no laptop big enough to read could ever pass.

Red-proof again: the two-view geometry convicted all three covers as they stood
-- A 908 content px under a circle (its wordmark sat inside the signed-out
circle), B 1715 plus content past the cut bottom, C 1962. control_old_window
still convicts the pre-R-919 layout, so there are two controls now.

Covers redrawn: C is your laptop idea -- catchphrase and wordmark left, the
dashboard at 640 px (was 370) running off the right edge, readable at last. B's
home motif grew the same way. A lifted into the tighter band. Capitals 48/45/43
against the 25 px floor. Profile pictures untouched, not in the diff.

Still VERIFY: three views measured, all disagreeing with each other and with
Meta's help page, and the Facebook APP is still the one nobody has measured.
2026-10-09 08:21:08 +02:00

13 KiB
Raw Blame History

marketing — CHANGELOG

facebook — a phone has TWO views of the cover, not one; the covers fill the frame again (2026-10-09)

The operator saw the cover UNCROPPED on a signed-out phone and asked why, after R-919 had said the sides are cut. Both are true, and the first measurement was one view generalised.

  • Measured, signed out (from the operator's screenshot, solved against the picture): Facebook shows the full width — nothing is cut at the sides — but the cover is top-anchored and only the top 525 px survives; the bottom 99 px is cut. The blue rule from the top of the file is still visible at the top edge, which is how the crop's side was established. The profile circle is much bigger and much higher than in the signed-in view: x 486–1150 from y 232.
  • Measured, signed in, on the operator's REAL phone (Chrome on Android, 1080 px): the crop is real. Solving the screenshot against the laptop frame put the window at x 351..1298 where the emulated Pixel 9 had said 351..1289 — the left edge to the pixel. R-919's number is confirmed, not replaced.
  • So the sides are cut for a signed-in visitor and the bottom for a signed-out one, and a cover has to survive both. build.py now carries both views (PHONE_IN_X, PHONE_OUT_Y, PHONE_CIRCLES) instead of one, and SAFE is their intersection: (391, 40)–(1249, 485).
  • The profile circles are modelled as DISCS now, not rectangles reaching the bottom. Near its top a disc is only a few pixels wide; the rectangle threw away most of the cover for nothing and is part of why the covers looked empty.
  • Two layers, because a cover has two kinds of pixel. The READ layer (catchphrase + wordmark) must survive every view and the check fails on it. The DECOR layer (laptop, home motif) may be cropped or covered — and the build now REPORTS how much is lost rather than forbidding it: cover B 39 %, cover C 62 %. Without that split the check forbade a laptop big enough to see, which is what left the frame bare.
  • The covers were redrawn. C is the operator's laptop idea: catchphrase and wordmark left, the dashboard now 640 px wide (was 370) and running off the right edge — legible at last. B's home motif grew the same way. A is unchanged in kind, lifted into the tighter band.
  • A second red-proof, run before the redraw: the two-view geometry convicted all three covers as they stood — cover A 908 content pixels under a circle, B 1715 plus content past the bottom, C 1962. The permanent control_old_window still convicts the pre-R-919 layout as well.
  • Profile pictures untouched; they are not in the diff. Still R-919 = VERIFY: the Facebook app is the one view nobody has measured.

facebook — the brand lockup: the mark alone on the profile, the real lettering on the covers (2026-10-09)

Operator refinements on the same day, after looking at the rebuilt pictures. No geometry changed; R-919's measured constants and all its checks stand.

  • The profile picture is the logo MARK only. The mark plus the „felhom.eu" lettering left both too small to read at the 176 px Facebook shows, and smaller than the shape the Page carried before. Dropping the lettering lets the mark grow from 69 % to 76 % of the circle, and the canvas drops 932 → 648 px (still twice Meta's recommended 320 source, so the floor in profile_width went 720 → 640; 720 was above what the mark alone needs and would have shrunk it for nothing). At 40 px the cloud, the house and the keyhole now read.
  • Both backgrounds read now. The preview recommended dark because the lettering faded on white — a reason that no longer exists. It now says what is actually true: dark matches the covers and the Page as it stands, white separates the circle from the dark cover, and the operator picks.
  • The covers set the headline the way the WEBSITE sets its h1. site.css .page-index .hero-text h1 is font-weight: 700; letter-spacing: -0.03em; this file used ExtraBold (800) with no tracking. Now HEADLINE_WEIGHT = "Bold" and HEADLINE_TRACK = -0.03, with real per-glyph letter-spacing rather than faked by scaling. Bold is narrower, so the headlines grew: A 57 → 62, B 58 → 63, C 47 → 50.
  • „felhom.eu" is no longer typed. It is the logo's own lettering, cropped out of logo.png at a measured split (mark y 5–289, blank band y 290–295, wordmark y 296–403) and scaled. That lettering is set in „M+ 2c" / „Vremena Grotesk", fonts this machine does not have (R-916), so typing it in Plus Jakarta Sans was a different wordmark. The website hero shows the same logo.png on the same dark background, so the covers now match the page. The DOMAIN constant is gone with it.
  • Caught before it shipped: the preview page's new profile paragraph added a fourth %d, and the argument tuple was left 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". All three numbers were real numbers from the file, which is why it read as plausible rather than as a crash. Fixed and both paragraphs re-read.
  • Checks unchanged and all passing; the cap check now measures the weight the headline is actually set in. Profile pictures necessarily changed (that was the point), so their sha256 moved: db05dae5… dark, a44849e4… white.

facebook — the covers rebuilt to the phone view we measured (R-919) (2026-10-09)

R-919's fix, from an operator brief (no TASK file in the repo). The covers shipped on 2026-10-08 were cut on every phone; this rebuilds them to the measured geometry. Report: REPORT-facebook-cover-r919.md.

  • The geometry is measured now, not assumed. build.py believed a phone shows 640 x 360 of the cover. It shows 412 x 274 = 1,504 : 1 — the full height and only the centre 938 px of 1640, 351 px off each side. PHONE_HDR = (412, 274) drives CW_PHONE, so SAFE is now (391, 40)–(1249, 584), 858 px wide with a 40 px margin inside each crop edge.
  • QUIET is no longer one formula for both circles. The computer circle is left-anchored (everything to its left is under it); the phone circle is centred and hides only its own measured box (637, 369, 393). The old shared formula would have blanked the whole left half of the cover's bottom.
  • A derived BAND — inside SAFE, right of the computer circle, above the phone circle — is where every cover draws, so a re-measurement moves the three designs with it.
  • A cap check holds each headline's capital at ≥ 4 % of the cover height (25 px). A, B, C come out at 45, 45 and 37 px.
  • The red-proof runs on every build, beside the circle check's own control: control_old_window draws the headline where the old assumption put it (x 328) and the check must reject it. Against the covers as committed at a76207945e the new check convicted 3 of 3 — A 23 px / 22 px past the left and right edges, B 63 / 58 px plus 1017 content pixels under the phone circle, C 63 / 82 px plus 1778.
  • The three covers were redrawn inside the band: A one centred line; B the headline left with the home, its server and now seven app tiles right — two of them in the lower-right strip, the one place below the band a phone still shows beside the profile circle; C the headline left with the dashboard, its screen 470 → 370 px wide to fit. out/preview.html shows the phone panel at the measured 938 x 624 with the centred circle, labelled MEASURED, and no longer claims 640 x 360.
  • The profile pictures are untouched — sha256 identical before and after, and they are not in the diff.
  • Build it on DooPlex. The PNGs are byte-reproducible there (Pillow 11.1.0); Pillow 12.3.0 on the Windows workstation re-renders text a pixel or two differently and rewrites all six files. Noted in the README.
  • Nothing was uploaded to Facebook and no key was read. R-919 is VERIFY, not closed: the geometry is measured on one emulated device in the mobile website, so the operator's check in the Facebook app is the acceptance step.

facebook — the Page's settings set by hand, and Meta's size page read first-hand (2026-10-08, evening)

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

  • Done, each read back from a different channel than the edit. Intro → COPY.md §1 (Graph about now hex-equal to §1, 99 chars); action button → „További információ" at https://felhom.eu/; Messenger welcome → COPY.md §3, hex-equal, automation on; Page username → felhom.eu, so the Page now answers at facebook.com/felhom.eu (Graph username confirms it). The operator typed the password Facebook demanded for the username; nothing else needed a human.
  • Not done — COPY.md §2 has no field to go in. Facebook's current Pages experience has no long-description field anywhere, and the Graph description reads null and is not writable with the robot key's scopes. Filed R-917 with four options; §2 stays in COPY.md unused. facebook/README.md's „What goes where" row says so.
  • facebook/README.md sizes grade: „READ, second-hand" → „READ, Meta's help page" — and the comparison went the other way. Meta's page (facebook.com/help/125379114252045, quoted verbatim in the audit) carries 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: 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 the now-existing automation, pasting §3 again and saving gave „Mentve."; the reopened automation reads back hex-equal. Anyone editing this screen must reopen it and read the text back, not trust either toast.
  • Nothing was posted; no ad, no boost, no Meta Verified; the Meta app stays in development mode.

facebook — the Page's pictures and texts (2026-10-08)

  • marketing/facebook/build.py (Pillow only) makes out/profile-dark.png + out/profile-white.png (932 x 932, the logo PNG placed unscaled), three covers out/cover-{a,b,c}.png (1640 x 624) and out/preview.html (self-contained). Checks in the build: profile circle (today's shape 6823 pixels outside radius 0.42 x width → new pictures 0), cover safe area + profile-circle clearance (content layer only), sizes read back from the files. The site's tokens and font.
  • COPY.md: intro (99 of 100 characters), long description, Messenger welcome, three first posts — each claim cites its website page; no price.
  • Fixed in the session: covers B and C first failed the safe-area check (text in the phone profile circle's corner, the frame past the phone crop) and were moved; logo.svg renders with the wrong lettering here, so the PNG is the master (R-916).