Files
felhom.eu/marketing
admin 3a77ed73aa
gates / gates (push) Successful in 5m58s
facebook: the first post drafted (COPY.md section 6) + fb_probe schedule-post
DRAFTS. COPY.md section 6: two versions of the Page's first post, shortened
from section 2. Hungarian, tegezo, no price. 6.1 = 347 characters, 6.2 = 638
(counted as Unicode characters). 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.

Deliberate: ZERO emoji and ZERO hashtags, though the brief allows two of each.
The Felhom design system uses no emoji (the website gate holds it at 0) and
two hashtags would serve no real search.

CHECKED, because the post repeats it: "56 alkalmazas" is CORRECT. The apps
page carries 57 <div class="app-card"> but states 56, which looks off by one
until you read the category line -- "6 alkalmazas + 1 beepitett". The 57th
card is FileBrowser, built into every box and deliberately not counted.
index.html says "56 telepitheto alkalmazas" too. I nearly "fixed" a live page
into being wrong. NOT-A-FINDING.

SCHEDULE-POST. A third sub-command on fb_probe.py, reusing its token loader
(R-453), redaction, Bearer call and evidence writer:

  - the body is READ FROM COPY.md by section name. The Hungarian never passes
    through a shell or an argv string (brief 9.6); the caller names a section.
  - published is ALWAYS "false" and NO argument can change it (brief 9.7).
    The operator's review in Planner is the safety net, so an immediate post
    must be unreachable, not merely not-the-default.
  - check_when refuses a time under Meta's 10-minute floor or over its
    6-month ceiling, BEFORE the call, so a bad time is a readable local
    refusal rather than a Graph error.
  - budapest_to_epoch uses the real tz database. If zoneinfo has no
    Europe/Budapest it REFUSES rather than falling back to a hardcoded
    +01:00/+02:00 -- guessing the offset is how a post goes out an hour wrong
    across a DST boundary.
  - list_scheduled tries /scheduled_posts then feed?is_published=false and
    RECORDS WHICH ANSWERED; when both are refused it returns None so the
    caller says "unproven" instead of claiming a removal it never saw.

TESTS: 30, of which 2 skip on Windows (no tzdata in this interpreter; the
command runs on the Linux host, which has the system zoneinfo).

RED-PROOF of the guard that matters, as the brief requires. Made
schedule_form accept published=..., ran ScheduleForm, and watched
test_no_argument_can_publish_immediately FAIL:
    AssertionError: 'true' != 'false' : published changed published
Guard restored, all 30 green again.

No post has been made. The dry check and the real post come next; the
operator picks the version and the time first.
2026-10-09 15:06:47 +02:00
..