From 7865dc9f58adec4586a9f877a73c40515155b337 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Mon, 12 Oct 2026 19:04:48 +0200 Subject: [PATCH] R-917: the first Facebook post is published (19:00:07, permalink 200); only the operator's pin left Co-Authored-By: Claude Opus 5.5 (1M context) Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS --- REPORT-disk-evening-2026-10-12.md | 2 +- STATUS.md | 1 + .../audits/answers-2026-10-12/r917-post-published.txt | 4 ++++ documentation/backlog/OPEN-ITEMS.md | 2 +- 4 files changed, 7 insertions(+), 2 deletions(-) create mode 100644 documentation/audits/answers-2026-10-12/r917-post-published.txt diff --git a/REPORT-disk-evening-2026-10-12.md b/REPORT-disk-evening-2026-10-12.md index c3cf6038..61e7fdf9 100644 --- a/REPORT-disk-evening-2026-10-12.md +++ b/REPORT-disk-evening-2026-10-12.md @@ -7,7 +7,7 @@ | Part | State | What | |---|---|---| | A — the disk | **done** | Read only: two alerts (`DiskUncorrectableSectors`, `DiskOfflineUncorrectable`) on `device=ata-ST3000VX010-2E3166_Z6A07P2G`, 352 sectors flat since 2026-10-09; not mounted; fstab line commented out since 2026-08-14; k3s does not wait for it; Longhorn HDD4 empty; no script/PV/hostPath uses it; the SMART exporter names it (checklist step). After the operator's yes: silence `1e18c10a…` (matches 1 of 7 disks); Longhorn HDD4 removed (78 volumes healthy); R-231 token moved to a header (`1943a70`, proven read-only). Runbook + operator row R-934. | -| B — verify and close | **done**, two dated | R-304 closed (released + runbook `RUNBOOK-open-retained-package.md`); R-836 closed (kernel lane removes the harm); R-330 wire half closed in the row; R-528 WATCH to 2026-11-12; R-435 re-dated 2026-10-20 (window unreadable today); R-231 VERIFY 2026-10-13; R-917 read after 19:00 (below); R-314 not attempted. | +| B — verify and close | **done**, two dated | R-304 closed (released + runbook `RUNBOOK-open-retained-package.md`); R-836 closed (kernel lane removes the harm); R-330 wire half closed in the row; R-528 WATCH to 2026-11-12; R-435 re-dated 2026-10-20 (window unreadable today); R-231 VERIFY 2026-10-13; R-917: the post IS published (19:00:07, permalink 200) — only your pin is left; R-314 not attempted. | | C — small rows | **partly** | R-931 (gzip: 114 784 → 22 130 B), R-932 (13 em dashes + a gate rule, red-proved), R-521 F7 (helper), R-206 part (a) in git (role `docker_daemon`, tag `never`, not installed). Not reached: the rest of the hint list. R-895 not touched (no hub release). | | D — notification slice 1 | **done** | Operator Q1/Q2 „as picked" (decisions 234–235). Three group switches, details + cooldown under „Részletek", „egyedi" saved back unchanged; default list fills groups 1 and 3 for households with no saved list (group 2 custom: R-329). In 0.309.0. | | E — hub readers | **not started** | A parallel session was releasing hub 0.148.0 (security); no second hub release here. | diff --git a/STATUS.md b/STATUS.md index ce41b709..9480e92c 100644 --- a/STATUS.md +++ b/STATUS.md @@ -10,6 +10,7 @@ - **DooPlex's backup no longer puts the Gitea token in the clone address** (your yes). Tonight's 03:10 run tests it. - **Box 0.309.0 runs on demo-hp, demo-felhom and Tester 1** (delivered 18:08): the notification page shows three switches, details and the „every N hours" setting under „Részletek" (your Q1/Q2); a full system disk now mails the household in its own language. - **The website is compressed:** the stylesheet goes out at a fifth of its size. **The catalog** lost 13 em dashes, and a check now stops new ones. +- **The first Facebook post went out at 19:00** and its link works. Only your pin is left (on the post: „…", then „Kiemelés"). - **Closed:** the retained-package runbook (R-304), the kernel-hang item (R-836). Dated checks: Tester 1's clean-up (20 Oct), the memory-kill watch (12 Nov). - **Two findings:** - Something switched the shared felhom.eu checkout to „bare" twice this afternoon (every git command there failed). I switched it back each time; my own pushes do not do it. Filed to find the cause. diff --git a/documentation/audits/answers-2026-10-12/r917-post-published.txt b/documentation/audits/answers-2026-10-12/r917-post-published.txt new file mode 100644 index 00000000..85d44376 --- /dev/null +++ b/documentation/audits/answers-2026-10-12/r917-post-published.txt @@ -0,0 +1,4 @@ +# R-917 read-back 2026-10-12 19:02 CEST (fb_probe loader + Graph client, page token in memory only; evidence JSON grep EAA = 0) +GET /1360018983863273_122096547315511222?fields=id,is_published,permalink_url,created_time,scheduled_publish_time -> 200 +{"is_published": true, "permalink_url": "https://www.facebook.com/122096546283511222/posts/122096547315511222", "created_time": "2026-10-12T17:00:07+0000", "scheduled_publish_time": null} +permalink GET (no login) -> 200 diff --git a/documentation/backlog/OPEN-ITEMS.md b/documentation/backlog/OPEN-ITEMS.md index 85428d8e..667f5cb1 100644 --- a/documentation/backlog/OPEN-ITEMS.md +++ b/documentation/backlog/OPEN-ITEMS.md @@ -254,7 +254,7 @@ stopping line that lies. | **R-89** | Business & legal | P4 | Retention as a per-customer **commercial** policy on the hub | READY (increment 2) | — | Policy object + reconciler → ep0 prune job; keep box tokens write-only | CC | | **R-794** | Business & legal | P4 | **[P3-LOW] redis 7.4 (RSALv2 / SSPL, not OSI) runs as a private cache in seven apps: dawarich, docmost, immich, nextcloud, outline, paperless-ngx, romm.** READ 2026-10-02 (`audits/licences-2026-10-02/TABLE.md`). Read as permitted (a private cache only its app uses is not Redis offered as a service — inferred). Valkey (BSD-3) or redis 8 (AGPL option) removes the question. **Needs:** a ladder step per app to valkey or redis 8, through the harness — no hurry. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: the row itself says no hurry; usage read as permitted.** | — | — | CC | | **R-914** | Business & legal | P4 | **Write the Felhom Facebook Page skill from the spike's findings.** Spike 2026-10-08 (`audits/SPIKE-facebook-page-api-2026-10-08.md`): key valid, never expires; the Page (`1360018983863273`) is reached with CREATE_CONTENT/MODERATE/ANALYZE; a scheduled text post and a scheduled photo were created, read back byte-equal and deleted (removal proven). Probe `scripts/facebook/fb_probe.py`. Gap to close in the skill: a scheduled photo's publish state was not read (no `post_id` returned). **2026-10-08 (Page pictures task) — two more for the skill:** (1) **the removal proof was not a proof**: the text post's after-DELETE answer was (#10) „does not exist, cannot be loaded due to missing permission…" — that message also means a permission gap. The skill proves removal by listing the Page's scheduled posts before and after the delete (present, then absent); the operator's Planner view on 2026-10-08 showed nothing on 15 October (a different channel, by eye). (2) **pictures by API** (READ, developers.facebook.com/docs/graph-api/reference/page/picture and …/reference/page/): `POST /{page}/picture` needs the `MANAGE` task, which the robot does not have (measured task list); the cover is `POST /{page}` `cover=`, „only by the Page Admin or Page Editor with `EDIT_PROFILE`" + `business_management`. Neither names `pages_manage_metadata`. Today the pictures are uploaded by hand (`marketing/facebook/README.md`). **-- 2026-10-09: the first slice exists.** `scripts/facebook/fb_probe.py` gained a **`schedule-post`** sub-command (text + link, scheduled only) reusing the probe's token loader, redaction, Bearer call and evidence writer. Guards, each with a test (30 tests; all 30 pass on DooPlex, 2 skip on Windows for want of a tz database): **it cannot publish immediately** — `published` is always `false` and the test enumerates every keyword `schedule_form()` takes to prove none flips it (RED-PROOFED: the guard was removed and the test seen failing, `'true' != 'false'`); the body is **read from `COPY.md` by section**, never through a shell; `check_when()` refuses a time outside Meta's 10-minute..6-month window before the call; `budapest_to_epoch()` uses the real tz database and **refuses** rather than guessing a DST offset; `list_scheduled()` records which route answered and returns `None` when both are refused, so a caller cannot claim a removal it never saw. **What the full skill still needs:** the photo path (the spike could not prove a scheduled PHOTO stays hidden — deliberately not reused), the pin, comment moderation, and the insight read-back after a post. | **READY — owner: CC** | — | Write the skill (drafts scheduled for operator review by default); read a scheduled photo back through the Page's scheduled-post listing | CC | -| **R-917** | Business & legal | P4 | **`COPY.md` §2, the Page's longer description (867 characters), has nowhere to go: Facebook's current Pages experience has no long-description field at all.** FOUND 2026-10-08 (Page setup task, `audits/facebook-page-setup-2026-10-08/`). Looked in four places, all on the live Page as its admin: the Page's „Névjegy" tab (Rövid áttekintés / Személyes adatok / Részletek — only a 255-character „Bemutatkozás" and the pinned category), Business Suite's „Oldal módosítása" dialog (profile picture, cover, Bemutatkozás, category, phone, e-mail, address, website, social links — and nothing else), Facebook settings → „Oldal adatai" (redirects to the same Névjegy tab) and settings → „Oldal beállítása" (name, access, type, history, status, recommendation, messaging, data sharing). MEASURED by Graph with the Page token: `description`, `general_info` and `bio` all read `null`. Writing `description` by API would need `pages_manage_metadata`; the robot key's scopes are `read_insights, pages_show_list, business_management, pages_read_engagement, pages_read_user_content, pages_manage_posts, pages_manage_engagement, public_profile`, and the task's fences forbid adding a permission. So §2 is written, reviewed and unplaceable. **Options for the operator:** (a) leave §2 unused and let the 99-character intro plus the website carry it; (b) shorten §2 to ≤ 255 characters and make it the „Bemutatkozás" instead of §1 — but §1 was written for exactly that slot, so this is really „rewrite one of the two"; (c) publish §2 as the Page's first pinned post once the app is Live (R-915), which is where a long text actually gets read; (d) ask Meta support whether the field still exists for this Page type. Recommended (c) — the text reads like a post already. **-- SCHEDULED 2026-10-09, option (c) carried out.** The text was shortened from §2 into `COPY.md` §6 (two versions; the operator chose **6.2 Közepes**, 638 Unicode characters, Hungarian only, 0 emoji, 0 hashtags). Scheduled through the robot, **not published**: post `1360018983863273_122096547315511222`, due **2026-10-12 19:00 Europe/Budapest** (epoch 1791824400 = 17:00 UTC, checked against the tz database). 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 (`887514383eff997c`). Present in `GET /{page}/scheduled_posts`, and visible in Planner on H 12 at 19:00 with the link card attached (a different channel from the API). It can still be changed or deleted there. The number in the post was checked, not copied: the apps page carries 57 cards while saying 56, which is 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. | **VERIFY -- scheduled on `main` 2026-10-09, due 2026-10-12 19:00. Not public yet; the operator reviews it in Planner and confirms after it goes out** | the scheduled time passing, then the operator's look | Operator: after it publishes on Monday evening, pin it — „…” → „Kiemelés”. Close on that word. CC (next session): read the post back — `is_published` must be **true** and the permalink must resolve; **if it did not publish, report it and do NOT post again**. If nothing is done: the post goes out anyway at 19:00 and simply is not pinned | operator | +| **R-917** | Business & legal | P4 | **`COPY.md` §2, the Page's longer description (867 characters), has nowhere to go: Facebook's current Pages experience has no long-description field at all.** FOUND 2026-10-08 (Page setup task, `audits/facebook-page-setup-2026-10-08/`). Looked in four places, all on the live Page as its admin: the Page's „Névjegy" tab (Rövid áttekintés / Személyes adatok / Részletek — only a 255-character „Bemutatkozás" and the pinned category), Business Suite's „Oldal módosítása" dialog (profile picture, cover, Bemutatkozás, category, phone, e-mail, address, website, social links — and nothing else), Facebook settings → „Oldal adatai" (redirects to the same Névjegy tab) and settings → „Oldal beállítása" (name, access, type, history, status, recommendation, messaging, data sharing). MEASURED by Graph with the Page token: `description`, `general_info` and `bio` all read `null`. Writing `description` by API would need `pages_manage_metadata`; the robot key's scopes are `read_insights, pages_show_list, business_management, pages_read_engagement, pages_read_user_content, pages_manage_posts, pages_manage_engagement, public_profile`, and the task's fences forbid adding a permission. So §2 is written, reviewed and unplaceable. **Options for the operator:** (a) leave §2 unused and let the 99-character intro plus the website carry it; (b) shorten §2 to ≤ 255 characters and make it the „Bemutatkozás" instead of §1 — but §1 was written for exactly that slot, so this is really „rewrite one of the two"; (c) publish §2 as the Page's first pinned post once the app is Live (R-915), which is where a long text actually gets read; (d) ask Meta support whether the field still exists for this Page type. Recommended (c) — the text reads like a post already. **-- SCHEDULED 2026-10-09, option (c) carried out.** The text was shortened from §2 into `COPY.md` §6 (two versions; the operator chose **6.2 Közepes**, 638 Unicode characters, Hungarian only, 0 emoji, 0 hashtags). Scheduled through the robot, **not published**: post `1360018983863273_122096547315511222`, due **2026-10-12 19:00 Europe/Budapest** (epoch 1791824400 = 17:00 UTC, checked against the tz database). 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 (`887514383eff997c`). Present in `GET /{page}/scheduled_posts`, and visible in Planner on H 12 at 19:00 with the link card attached (a different channel from the API). It can still be changed or deleted there. The number in the post was checked, not copied: the apps page carries 57 cards while saying 56, which is 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. | **WAITING-ON-OPERATOR** — **2026-10-12 19:02: the first post IS published** (Graph: `is_published` true, `created_time` 17:00:07Z, the permalink answers 200 without a login; `audits/answers-2026-10-12/r917-post-published.txt`). Only the pin is left — the operator's one click. **VERIFY -- scheduled on `main` 2026-10-09, due 2026-10-12 19:00. Not public yet; the operator reviews it in Planner and confirms after it goes out** | the scheduled time passing, then the operator's look | Operator: on the post, „…" → „Kiemelés" (pin); then close | operator | | **R-919** | Business & legal | P3 | **On a phone the Facebook Page cuts the left edge of the cover: the „s” of „saját szabályaid” and the „f” of „felhom.eu” are gone.** MEASURED 2026-10-08 on the live Page in Chrome DevTools device mode, Pixel 9 (412 × 924, mobile user agent, after a reload so Facebook serves the mobile bundle): `audits/facebook-page-setup-2026-10-08/C2-phone-headline-cut-closeup.png`. The mobile Page header is **412 × 274 = 1,504:1**, so Facebook keeps our cover's full height and shows only the centre **938 px of its 1640 px width (57,2 %)** — **351 px cut from each side**. `marketing/facebook/build.py` builds to a safe area of the centre **1028 × 544** (306 px clear of each edge), which is **45 px wider per side than the phone actually shows**; the light text in `out/cover-c.png` runs from x 333 to x 997, and the left crop edge is x 351, so the first **18 px** of the text are cut. Covers A and B are built from the same safe area and will have the same edge. Two further facts this measurement establishes: **Meta's own help page is wrong about its own rendering** — it states the mobile cover is 2,4:1 where the Page header measures 1,504:1 — and the mobile profile circle is far bigger than assumed (172 px, centred, overlapping the bottom 112 px of the 274 px cover, i.e. source x 637–1030 × y 369–624 is hidden). Not re-cropped on Facebook, per the task's fence. **-- 2026-10-09, FIXED in the build:** `marketing/facebook/build.py` now takes the phone view from the measurement (`PHONE_HDR = (412, 274)` -> the centre 938 px), so SAFE is (391, 40)-(1249, 584) and the phone profile circle is the measured CENTRED box (637, 369, 393) rather than a left-anchored one. Every cover is drawn in a derived `BAND` (408, 48)-(1249, 340), and a `cap` check holds each headline's capital at >= 4 % of the cover height. The red-proof runs on EVERY build (`control_old_window`): it draws the headline where the old 640 x 360 assumption put it, x 328, and the check must reject it -- the phone's crop edge is x 351, so 23 px were cut. Against the three covers as committed at `a76207945e` the new check convicted 3 of 3 (A 23/22 px over the left/right edges, B 63/58 px plus 1017 content pixels under the phone circle, C 63/82 px plus 1778). The profile pictures are untouched -- sha256 identical before and after. **-- 2026-10-09 (operator refinements, same day):** the profile picture now carries the logo MARK only (the lettering was unreadable at 176 px; the mark grew 69 % -> 76 % of the circle, canvas 932 -> 648), and the covers set the headline the way `site.css` sets `.page-index .hero-text h1` (Bold 700, letter-spacing -0.03em, not ExtraBold 800 untracked) with „felhom.eu” drawn from the logo's OWN lettering instead of typed. No geometry changed; every R-919 check and the red-proof stand. **-- 2026-10-09 (second measurement):** a phone has TWO views and they disagree. SIGNED IN the sides are cut (confirmed on the operator's REAL phone, Chrome/Android: the window solves to x 351..1298 against the emulator's 351..1289 - the left edge to the pixel). SIGNED OUT the FULL width is shown but the cover is top-anchored and only the top 525 px survives (the bottom 99 px is cut; the file's blue top rule is still visible, which is how the side was established), with a much bigger, higher circle at x 486..1150 from y 232. `build.py` now carries both views, models the circles as DISCS rather than rectangles running to the bottom, and splits the artwork into a READ layer (must survive every view) and a DECOR layer (may be cropped or covered; the build reports the cost - B 39 %, C 62 %). The two-view geometry convicted all three then-current covers before the redraw (A 908 px under a circle, B 1715, C 1962). Covers redrawn: C is the operator's laptop idea with the dashboard at 640 px (was 370), B's motif grown to match. **-- 2026-10-09 (the APP measured):** 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 / 349..1291 - the LITE APP CROPS EXACTLY LIKE SIGNED-IN MOBILE WEB, and both agree with the emulator's 351..1289. Their circle is at x 645..1021 from y 451, LOWER than the emulator's 369, so that figure was pessimistic rather than wrong. Five views measured; the signed-out one stays the binding constraint. Cover C redrawn to the operator's layout (wordmark 88 px on top, gap, catchphrase) - one line, not his two, because two measured 392 text pixels behind the signed-out circle („saját szabályaid” read „saját szab”) and sizing them to fit drops the capital to the 25 px floor. | **VERIFY -- rebuilt on `main` 2026-10-09. The app IS now measured and the cover renders correctly there; what is left is the operator's look at the NEW cover in the app after uploading it.** | — | Operator: upload the rebuilt cover-c (and the profile picture if not already), then confirm in the Facebook app that the wordmark and the catchphrase are whole. Close on that word | CC | | **R-920** | Business & legal | P4 | **The Messenger „Gyakori kérdések" automation does not exist for this Page, so `COPY.md` §5 — four questions with answers condensed from `gyik.html` — has nowhere to go.** FOUND 2026-10-09 (Page details task, `audits/facebook-page-details-2026-10-09/`). SEARCHED, not assumed absent: the create-automation catalogue („Az összes automatizálás") holds exactly THREE templates — Automatikus válasz, Távolléti üzenet, A megválaszolatlan üzenetek azonosítása (`B5-no-faq-template-all-three.jpg`); the template search for „kérdés" answers **„Nincs a keresésnek megfelelő automatizálási sablon."** while the POSITIVE CONTROL „üzenet" returns two, so the search works and the term genuinely misses; the existing instant-reply automation carries only channel, message and media — no FAQ and no quick replies; and the business-portfolio settings have no messaging/FAQ entry. The copy is written, sourced line by line to `gyik.html` and committed as `marketing/facebook/COPY.md` §5, ready to paste unchanged the day the feature appears. **Same shape as R-917** (§2 has nowhere to go), and the same cause: Meta removed a Page field this project had planned copy for. **Options for the operator:** (a) leave §5 unused until Meta brings the feature back; (b) fold the four answers into the Messenger welcome message (§3) — it holds 500 characters and today uses 120, so one or two would fit, not four; (c) publish them as a pinned FAQ post once the app is Live (R-915); (d) ask Meta support whether the FAQ automation still exists for this Page type. Recommended (a) with (c) later — the welcome message stays short, and the website's own `gyik.html` already answers these. | **DEFERRED — operator chose (c) on 2026-10-09:** park the text and publish it as a post once posting starts. Not a defect, and not waiting on CC | nothing — **UNBLOCKED 2026-10-09**: R-915 is closed, the app is Live, so posting can start whenever the operator wants | When posting starts: publish `COPY.md` §5 (the four Messenger FAQ answers) as one later post. If nothing is done: the text stays in `COPY.md` unused, which the operator has accepted | operator | | **R-930** | Business & legal | P3 | **The site's primary call-to-action fails WCAG AA: white on `--blue` #0083D8 measures 4.01:1 at 16px/600, against a 4.5:1 floor.** MEASURED 2026-10-10 in the browser, on the LIVE home page and on the redesign preview: identical, so this is **pre-existing and site-wide**, not a regression of the redesign. It is the „Jelentkezem tesztelőnek" button and every `.cta-button` on every page. `.cta-button-secondary` is fine (7.17:1). Three fixes, all needing the operator because each touches brand: (a) darken `--blue` until the ratio clears 4.5 (changes a token used across hub, controller and website); (b) make the label 700 weight at 18.66px+, which moves it into WCAG's „large text" band where 3:1 applies and 4.01 passes, at the cost of a bigger button everywhere; (c) accept it and record the decision. **Not changed unilaterally**: `felhom-web-design` §6 puts a new accent colour behind the operator's word. | **WAITING-ON-OPERATOR** — filed 2026-10-10 by the home-page redesign session; evidence `audits/redesign-2026-10-10/AUDIT.md` | operator's choice between (a), (b), (c) | pick one of the three | operator |