9 Commits

Author	SHA1	Message	Date
admin	97d3c29f9c	facebook: Page details — categories added, hours and Messenger FAQ refused by Meta ... Second Facebook task of the day. Page 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 (2026-10-08: "A modositas nincs mentve" arrived with a partial save). - Contact (B1) was ALREADY SET, by the operator, before this run: Graph reads emails ["info@felhom.eu"] and phone "+36702378499". Verified, not typed. - Place (B2) already city-only Budapest, as the operator chose. Service area REFUSED: Facebook offers the field but its picker has no "Magyarorszag", only cities. Control: "Szeged" returns Szeged. Left unset rather than narrowed to Budapest, which would shrink a coverage claim nobody authorised. - Categories (B3) DONE: Informatikai vallalat (kept first, the only one shown) + Internetes ceg + Szoftverceg. Facebook's Hungarian list has no IT-support, IT-consulting or cloud category; eleven terms searched, and the one true match is a repair counter, which the fences rule out. - Hours (B4) CANNOT be set and need not be: Facebook requires a street address first, which the fences forbid. Measured on the rendered page with controls present -- Zarva 0, Nyitva 0 while Budapest 1, Informatikai vallalat 1. The Page will never show "Zarva". - Messenger FAQ (B5) REFUSED -> R-920: the automation does not exist for this Page. Catalogue holds exactly three templates; search "kerdes" returns none while the control "uzenet" returns two. COPY.md section 5 is written anyway, questions verbatim from gyik.html and answers condensed from each question's own answer, and waits like section 2 does (R-917). - Link preview correct in both languages, re-scraped once each; only the expected fb:app_id warning, deliberately not fixed. Both report HTTP 206 where a plain curl gets 200 -- Facebook's scraper, preview complete. fb_probe.py read now also reports emails, phone, category_list, location, single_line_address and hours, ONE FIELD PER CALL: a batched fields= list fails whole when any member is unreadable, which would let one refused field hide the other five. Refusals are logged verbatim and never retried; "null" and "not returned" are logged apart. hours is never returned by Graph, which is why B4's read-back had to come from the rendered page. Also corrects the "Business & legal" header, which read 12 rows (P2 5) over a section holding 11 (P2 4); with R-920 it is 12 (P2 4, P3 1, P4 7). Only the section this commit edits -- the other drifting headers belong to a session that owns the register. No post, no invite, no money, no app or portfolio change, website unchanged.	2026-10-09 10:28:30 +02:00
admin	9a55f0bbc7	marketing/facebook: the Facebook APP measured; cover C to your layout (R-919) ... The app is no longer the unmeasured view. Solved against the laptop frame, your Facebook Lite shot gives a visible window of x 349..1290 and your Chrome-mobile shot x 349..1291 -- the LITE APP CROPS EXACTLY LIKE SIGNED-IN MOBILE WEB, and both agree with the emulator's 351..1289. Their profile circle is at x 645..1021 from y 451, LOWER than the emulator's y 369, so that figure was pessimistic rather than wrong and the margin it bought was real. Five views measured now; the signed-out one is still the binding constraint. Cover C follows your draft: the wordmark big on top (88 px, was 44), a small gap, then the catchphrase. The catchphrase is ONE line, not the two you drew, and the measurement forces it: 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 the R-919 defect itself. Sizing 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 shrank to 540 px to free the width; 64% of it is cropped or covered somewhere, which the build reports and which is what the decor layer is for.	2026-10-09 09:24:23 +02:00
admin	b9073e8fb6	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
admin	ba7174012a	marketing/facebook: the mark alone on the profile, the real lettering on the covers ... Operator refinements after looking at the rebuilt pictures. No geometry changed: R-919's measured constants, its band and every check stand, and the red-proof still convicts the old layout. Profile picture: the logo MARK only. The mark plus the "felhom.eu" lettering was too much for the 176 px Facebook shows -- and smaller than the shape the Page carried before this work, because build.py shrinks the artwork to fit inside the circle where the original was simply cropped by it. Dropping the lettering grows the mark from 69% to 76% of the circle; canvas 932 -> 648 and the profile_width floor 720 -> 640 (twice Meta's recommended 320 source; 720 was above what the mark alone needs and would have shrunk it for nothing). logo.png is split at a MEASURED row: ink y 5-289, blank band y 290-295, wordmark y 296-403. Covers: the headline is now set 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, so the cover did not actually match the page. HEADLINE_WEIGHT/HEADLINE_TRACK now carry those, with real per-glyph spacing. Bold is narrower so headlines grew: A 57->62, B 58->63, C 47->50. "felhom.eu" is no longer typed anywhere: 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 match the page. The DOMAIN constant is removed rather than left as dead code. Caught before it shipped: the preview's new profile paragraph added a fourth %d and the argument tuple stayed 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 real, just in the wrong slot, which is why it read as plausible instead of crashing. Found by reading the rendered paragraph back, not by the exit code. Built on DooPlex; all checks pass, the phone simulation still shows 0 px cut and 0 px under the profile circle on all three covers. R-919 stays VERIFY.	2026-10-09 07:29:57 +02:00
admin	796a9fdf40	marketing/facebook: covers rebuilt to the MEASURED phone view (R-919 -> VERIFY) ... build.py believed a phone shows 640x360 of the cover. It shows 412x274 = 1.504:1 -- the full height and only the centre 938 px of 1640, 351 px off each side. PHONE_HDR = (412, 274) now drives CW_PHONE, so SAFE is (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, the phone circle is CENTRED and hides only its measured box (637,369,393). The old shared formula, applied to a centred circle, would have blanked everything from x 0 to x 1054 below y 345. Every cover draws in a derived BAND (408,48)-(1249,340), and a cap check holds each headline's capital at >= 4% of the cover height; A/B/C come out at 45, 45 and 37 px against a 25 px floor. RED-PROOF, and it is permanent: control_old_window() runs on every build and draws the headline where the old assumption put it (x 328); the check must reject it. The phone's crop edge is x 351, so 23 px were cut; the measured safe edge is x 391. Against the covers as committed at a76207945e the new check convicted 3 of 3 -- A 23/22 px past the left/right edges, B 63/58 px plus 1017 content pixels under the phone circle, C 63/82 px plus 1778. Covers redrawn inside the band: A one centred line; B the home motif scaled with two tiles moved into the lower-right strip, the one area below the band a phone still shows beside the profile circle; C the dashboard screen 470 -> 370 px so frame and base fit. preview.html shows the phone panel at the measured 938x624 with the centred circle and no longer claims 640x360. Profile pictures untouched -- sha256 identical before and after, and not in the diff. Built on DooPlex: the PNGs are byte-reproducible there (Pillow 11.1.0) and not across Pillow versions; the README now says so. 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. Nothing uploaded, no Graph API call, FACEBOOK_API never read.	2026-10-09 06:59:53 +02:00
admin	a76207945e	marketing/facebook: the phone check ran after all — the cover IS cut on phones (R-919) ... Your suggestion to use DevTools device mode was right; "cannot be checked" was too quick a conclusion. On an emulated Pixel 9 (412x924, mobile UA, with a reload so Facebook serves the mobile bundle) the Page's mobile header renders 412x274 = 1.504:1. Facebook keeps the cover's full height and shows only the centre 938 px of its 1640 px width -- 351 px off each side. build.py's safe area leaves 306 px clear per side, 45 px too few, and the light text in cover-c.png runs x333..x997 against a left crop edge of x351, so 18 px are lost: the headline reads "aját szabályaid" and the wordmark "elhom.eu" on every phone. Nothing re-cropped on Facebook (the task's fence). The fix is build.py's safe area (<=938 px, ~900 for margin) plus the measured 172 px centred phone profile circle, then a hand re-upload. R-919 opened; R-918 closed and moved to CLOSED-ITEMS with the recipe that made the check possible. Meta's help 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 this session's first-pass arithmetic -- explicitly labelled arithmetic, not a check -- under-predicted the crop about fivefold. That is recorded rather than quietly deleted. Also: the evidence secret scan needed --exclude=README.md, because that README quotes the search strings and was matching itself (4 false EAA hits, 1 false access_token); with the exclusion, control 1 -> 0 and no real hit. And the Business & legal section header was already miscounted before this session (said 9/P2 4, actually held 10/P2 5) -- corrected; five other section headers drift too and are named in the report, left for a session that owns the register.	2026-10-08 21:50:57 +02:00
admin	8664cbda78	marketing/facebook: Page settings set by hand (intro, action button, Messenger welcome, username felhom.eu) ... Ran marketing/facebook/TASK-page-setup-windows.md from the Windows workstation through Claude in Chrome. Evidence in documentation/audits/facebook-page-setup-2026-10-08/, report in REPORT-facebook-page-setup.md. Done, each read back from a different channel than the edit: the intro is COPY.md §1 (Graph `about` hex-equal, 99 chars); the action button is "További információ" to https://felhom.eu/; the Messenger welcome is COPY.md §3 (hex-equal) and the automation is on; the username is felhom.eu, so the Page answers at facebook.com/felhom.eu. Not done: COPY.md §2 has no field to go in — Facebook's current Pages experience has no long-description field and the Graph `description` is null and unwritable with the robot key's scopes. R-917, four options, operator's call; no Hungarian copy was shortened. Phase A read Meta's size page first-hand: it carries none of the 820x312 / 640x360 figures our README asserted, and its own two ratios contradict the file it recommends. README's grade and comparison rewritten; what we build is unchanged. Phase C measured the computer width (cover whole, no crop, profile circle 16 px clear). The 390 px phone check was NOT performed: narrowing a desktop browser never gives Facebook's phone layout. R-918. Nothing posted; no ad, no boost, no Meta Verified; the Meta app stays in development mode; no host, guest, box or hub touched.	2026-10-08 20:49:14 +02:00
admin	1d6927345c	marketing/facebook: handover task for the Windows session (Page setup through Claude in Chrome)	2026-10-08 19:58:09 +02:00
admin	f0dc6a9d4e	Facebook Page: profile pictures, three covers, preview page and texts (marketing/facebook); R-916 opened ... build.py (Pillow, site tokens + Plus Jakarta Sans) with in-build checks: profile circle (today's shape 6823 pixels outside, new 0), cover safe area and profile-circle clearance, sizes read back. COPY.md: intro 99/100, long description, Messenger welcome, three first posts, each claim traced to the website. R-914 gets the listing-based removal proof and the picture-API tasks; R-915 the footer-link note; R-916 the logo's vector master.	2026-10-08 19:19:50 +02:00