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.