felhom.eu/marketing/CHANGELOG.md

# marketing — CHANGELOG

## facebook — the Page's first post, drafted and SCHEDULED (2026-10-09)

R-917 option (c) carried out. The post is **not public**: it sits in Planner until Monday.

- **`COPY.md` §6** — two versions shortened from §2, Hungarian, tegező, no price. 6.1 = 347
  characters, 6.2 = 638 (Unicode characters, counted). Every claim carries a source comment naming the
  line of `website/index.html` it rests on; the first line of each carries the point alone, because
  Facebook cuts after about three lines. **Zero emoji, zero hashtags** though two of each were allowed
  — the design system uses no emoji and two hashtags would serve no real search.
- **The operator chose 6.2**, Hungarian only, for **2026-10-12 19:00** (over today: it was Friday
  15:08, the weakest evening of the week for a first post, and three days in Planner is review time).
- **Scheduled**: post `1360018983863273_122096547315511222`, epoch 1791824400. Read back
  `is_published` **False**, scheduled time sent == read, message **hex-equal** to `COPY.md` §6.2 — and
  the sha256 recomputed **outside** the probe agrees. Visible in Planner on H 12 at 19:00 with the link
  card, which is a different channel from the API.
- **`fb_probe.py schedule-post`** — text + link, scheduled only. **It cannot publish immediately**:
  `published` is always `false` and no argument can change it, because the operator's review in Planner
  is the safety net. The body is read from `COPY.md` by section, never through a shell. Time outside
  Meta's 10-minute..6-month window is refused locally. `budapest_to_epoch()` uses the real tz database
  and **refuses** rather than guessing a DST offset.
- **Scenario A, the dry check**: a throwaway scheduled post **with the link** was accepted (so `link`
  is not refused on a scheduled post — the open question), read back hex-equal and unpublished, seen
  **present** in `GET /{page}/scheduled_posts`, deleted, and seen **absent** in the same list. The
  removal proof comes from the list, not from an error after DELETE.
- **30 tests**, all passing on DooPlex (2 skip on Windows for want of a tz database). The
  cannot-publish guard was **red-proofed**: removed, test seen failing `'true' != 'false'`, restored.
- **Checked, not copied:** the post repeats „56 alkalmazás". The apps page carries **57** cards while
  saying 56 — deliberate: „6 alkalmazás + 1 beépített", the 57th being FileBrowser, built into every
  box. `index.html` says „56 telepíthető alkalmazás" too. A „fix" here would have made a live page wrong.

## facebook — the Meta app is LIVE; the Page can post in public (2026-10-09)

R-915 is closed. What it had waited on for a day was R-813's Terms of Service URL, which did not
exist until the closed-test legal set went live this morning.

- **Filled in the app's Basic settings:** Privacy policy URL `https://felhom.eu/adatkezeles`,
  Terms of Service URL `https://felhom.eu/feltetelek`, User data deletion → *Data deletion
  instructions URL* `https://felhom.eu/adatkezeles` (the notice says how: write to `info@felhom.eu`),
  and Category „Vállalkozások és oldalak" — the app exists to manage the Page.
- **The app icon was NOT required**, although the original row listed it among the blockers. Meta
  answered „All required app settings are complete" with the icon still empty. Recorded because the
  row would otherwise keep sending the next session to upload one. (It cannot be uploaded from here
  anyway — the icon control creates its file input only on click, and clicking opens a native dialog
  the browser tooling cannot drive.)
- **Published, and read back from a full page reload rather than the success toast**, because Meta's
  toasts have lied on this Page before: the badge reads `Published`, the string `Unpublished` is
  gone, and the page now offers `Unpublish`.
- **Nothing was granted.** No permission added, no use case changed; the scopes stay
  „Ready for testing", which is all a system user needs for the business's own Page. Going Live
  changes **who can see what the app posts**, not what it may do.
- **R-917 and R-920 are unblocked** by this: both were waiting for posting to start. The long
  description (§2) and the four Messenger FAQ answers (§5) can be published as posts whenever the
  operator wants.

## website — one brand lockup in the header, footer links that look like links (2026-10-09)

- The header showed the name twice: `logo.png` carries its own „felhom.eu" lettering under the mark,
  and a typed `<span class="logo-text">` repeated it beside the image — which also forced the mark
  down to 40 px. Now the mark alone (the vector `logo_notext.svg`, 54 px) with the brand's OWN
  lettering next to it, cropped from `logo.png` into `assets/logo-wordmark.png`.
- **Why the name is artwork and not text:** that face is „M+ 2c"/„Vremena Grotesk" (R-916), which
  nothing here has, and the site deliberately loads **no external font** — the privacy notice
  published the same morning states exactly that, so adding Google Fonts to match a logo would have
  made a published claim false. The Facebook covers already draw the wordmark from the logo for the
  same reason. The white/blue split is in the artwork itself.
- Footer links were unstyled, so the browser painted them default blue and **purple once visited**.
  They now follow the site's own convention: `--blue-bright`, no underline, underline on hover, with
  **`:visited` pinned to the same colour** — a legal link that changes colour after one read looks
  like it stopped working.

## facebook — Page details: categories added, contact already set, Messenger FAQ refused (2026-10-09)

Second task of the day, after the cover work: the Page's details box, the Messenger FAQ and the link
preview. Settings changed by hand in the operator's Chrome; every edit read back from a channel other
than the one that made it, because Meta's toasts have lied here before.

- **Contact was already done — by the operator, not by this run.** The task's baseline said there was
  no contact e-mail; there is. Graph reads `emails = ["info@felhom.eu"]` (the address
  `website/kapcsolat.html` uses) and `phone = "+36702378499"`, and the Page's „Elérhetőségek" tab shows
  the same. Nothing was typed; the value was verified and left alone.
- **Two categories added**, so the Page is findable beyond its one label:
  **Informatikai vállalat · Internetes cég · Szoftvercég**. „Informatikai vállalat" stays FIRST, which
  is the only one Facebook shows on the Page — the other two serve search, and correctly do not appear.
  Facebook's Hungarian list has **no IT-support, IT-consulting or cloud category**: eleven terms were
  searched, and the one true IT-support match („Számítógépszerviz") is a repair counter, which the
  fences rule out. Read back by Graph: IT Company, Internet Company, Software Company.
- **Opening hours cannot be set, and do not need to be.** Facebook greys the row out: „A nyitvatartási
  idő megadása előtt add meg előbb a vállalkozásod címét." Hours need a street address and the fences
  forbid entering one — so there is no „no hours" option to choose, and none is needed, because with no
  hours set the Page shows **no hours label at all**. Measured on the rendered page with controls:
  `Zárva 0 · Nyitva 0 · Nyitvatartás 0`, while `Budapest 1 · Informatikai vállalat 1 · felhom.eu 1`
  prove the details box was actually being read. An absent string on its own would have proved nothing.
- **The Messenger „Gyakori kérdések" automation does not exist for this Page → R-920.** Searched, not
  assumed: the catalogue holds exactly three templates, and a search for „kérdés" returns none while
  the control „üzenet" returns two. `COPY.md` §5 is written anyway — four questions verbatim from
  `gyik.html`, each answer condensed from that question's own answer with no new claim — and waits like
  §2 does (R-917).
- **Service area refused.** Facebook offers the field but its picker has no „Magyarország": it returns
  cities and neighbourhoods only. Control: „Szeged" returns Szeged. Left unset rather than narrowed to
  „Budapest", which would have shrunk a coverage claim nobody authorised.
- **Link preview is correct on both pages**, re-scraped once each. Title, description and image all
  right, Hungarian and English, each with its own `og:image`. The only warning is the **expected**
  missing `fb:app_id`, deliberately not added. Both report **Response Code 206, not 200** — a plain
  `curl` gets 200, so it is Facebook's scraper and the preview is complete; noted, not chased.
- `fb_probe.py read` now also reports `emails, phone, category_list, location, single_line_address,
  hours`, **one field per call** — a batched `fields=` list fails whole when any one member is
  unreadable, which would let one refused field hide the other five. `hours` is never returned by
  Graph, and the probe logs „not returned" apart from `null`.

## facebook — the Facebook APP measured at last; cover C to the operator's layout (2026-10-09)

- **The app view is no longer unmeasured.** The operator checked the live Page in **Facebook Lite** and in
  Chrome on his phone. Solved against the laptop frame, both give a visible window of **x 349..1290** and
  **x 349..1291** — the Lite app crops exactly like signed-in mobile web, and both agree with R-919's
  emulator (351..1289). Their profile circle sits at **x 645..1021 from y 451**, i.e. LOWER than the
  emulator's y 369, so the emulated figure was pessimistic and the build's margin was real. **Five views
  are now measured and the signed-out one remains the binding constraint** (circle top y 232, bottom cut
  at 525).
- **Cover C now follows the operator's draft:** the wordmark **big on top** (88 px, was 44), a small gap,
  then the catchphrase. The catchphrase is **one line**, not the two he drew, and the measurement forces
  that: with the signed-out circle starting at y 232, a wordmark that size plus two catchphrase lines
  cannot both sit above it. Drawn as two lines it measured **392 sampled text pixels behind that circle**
  — „saját szabályaid" read „saját szab" there, which is exactly the R-919 defect. Shrinking the two lines
  to fit instead drops the capital to 25 px, the legibility floor. One line keeps the wordmark big, the
  capital at 34 px and **every measured view clean (0 text pixels behind any circle)**.
- The laptop moved right and down to 540 px to make room for the one-line catchphrase; 64 % of it is
  cropped or covered in some view, which the build reports and which is what decor is for.


## 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).