The catalog published SABnzbd and NZBGet today (app-catalog 8ee687e). Here:
- two cards in the media category on both language sets, each with the project's own logo and
each saying IN BOLD that a paid Usenet subscription is the household's own
- the published count 60 -> 62 everywhere it is stated; the category badges are derived from
the cards now (media read 15 with 17 cards, otthon/home read 14 with 16 — both stale)
- documentation/audits/usenet-2026-10-12/: both bench runs, both box steps and verdicts, the
nine defects with their measurements, what a missing provider left unmeasured, the teardown
- R-988 closed (moved to CLOSED-ITEMS in this commit); R-989 filed: the drill-catalog route of
09 §6.5 cannot be followed — that repo is private and no box has catalog credentials, so the
templates were staged in the box's own catalog cache instead
- walk.app_env: a SECRET field in app.yaml is stored ENC:, so that helper returns ciphertext —
the docstring says so now, measured the hard way
- STATUS.md and REPORT-usenet-2026-10-12.md
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y
Read-only. fetch.py (polite, 5 s apart, 34 pages, all 200), parse.py (own text only; four parser
defects found by the controls and fixed), build.py + spotcheck.py (stdlib). tags.csv holds post
numbers and tags only - no username, author id, salt or post text in git. FINDINGS.md (2,908 posts,
195 people, 82 beginner threads in 7 clusters), FELHOM.md (catalog gap, hardware fit, 15 website
questions, objections, ten ranked recommendations), METHOD.md (controls, spot-check: role and
hardware below 85 % after two rounds, the table-driving splits 92.5 % and 97.3 %), REPORT.md.
R-990: operator rules on the recommendations. R-991: no buyer-readable hardware floor.
Claude-Session: https://claude.ai/code/session_012qRErfCoiTkvDK9N5XHbzb
Read-only. fetch.py + tables.py (stdlib), TABLE.md (45 charts, % of
respondents), FELHOM.md (apps, features, reasons, hardware, trends, ten
ranked recommendations), METHOD.md (hashes, counts, matching, MIT licence,
limits). Survey files are not committed. One register row (R-989) and one
STATUS line ask the operator to rule on the recommendations.
The catalog published qBittorrent and Transmission today (app-catalog 9081a47). Here:
- two cards in the media category on both language sets, each with the project's own logo,
each saying what a closed peer port costs (slower swarms, no incoming peers)
- the published count 58 -> 60 on every page that states it, FAQ JSON-LD with its visible twin
- documentation/audits/qbittorrent-2026-10-12/: both bench runs, both box walks and verdicts,
verify-fixes.json, teardown-newapps.json, and the README brought to its final state
- the 2026-09-30 walk harness: a `type: path` deploy field is filled with the drive ROOT —
the controller refuses a path inside a drive (409), so the walker could not install any app
with a drive field at all
- R-988: the Usenet pair (SABnzbd, NZBGet), operator request, not started
- STATUS.md and REPORT-newapps-2026-10-12.md
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y
- 09 §3: the decision sheet S1-S38, the operator's words quoted where they differ (S1, S2, S8, S32, S37)
- closed: R-831 R-870 R-698 R-327 R-230 R-719 R-352 R-526 R-770 R-771 R-913 R-290 R-209a R-769 R-616 R-884, and R-243 (dated check: the mail fired 2026-10-11 16:13:51Z, hub log agrees)
- R-698: the known limit written in 07 §6.6; new row R-933 (mirror supported catalog images, P3)
- R-327: capability-map row BUILT; stands claim re-titled and moved to built; page re-rendered
- R-913: the customer Cloudflare token recipe in day0-install A.1; 01 §7 points at it
- R-884: read only - ArgoCD Synced, live Deployment equals git
- R-887 dated check NOT met (4 lost jobs 10-10/11); re-dated 2026-10-19 after the S21 change
- 22 open rows carry their ruling; STATUS: the sheet is ANSWERED
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
documentation/audits/mockups-2026-10-11/
COMPARE.md the three directions side by side, measured the same way:
A current preview 12 req / 270 KB
M1 dashboard 68 req / 1012 KB (front page 1 660 px)
M2 hybrid 16 req / 150 KB (phone 3 057 px, the shortest)
plus three sentences each (good / risk / cost) and the risk I
think is real: a non-technical visitor may read M1 as somebody
else's account and look for a login.
SHARED-DESIGN.md REPORT ONLY, nothing built. M1 needed 260 CSS rules: 188 (72%)
copied from the controller UNCHANGED, 8 adapted, 64 new. It used
188 of the controller's 826 rules (23%). The 18 tokens are
already identical - verified by parsing both :root blocks, zero
differing values.
Recommends (a) a canonical felhom-ui.css plus a copy-drift gate,
over (b) serving the controller's stylesheet to the website -
and recommends NOT building it until a direction is chosen.
shots/ desktop and phone captures of all three, from the deployed pages
The finding that outranks the percentage, and the reason for the recommendation: a
component-level copy silently drops the element-level rules those components depend
on. The extractor copied every .sidebar/.content/.mobile-topbar rule and missed
"@media(max-width:768px){ body { flex-direction: column } }". Everything LOOKED
copied; the phone layout was broken in four measurable ways. Invisible to a diff,
invisible to review. A second instance the same evening: the drawer is gated on a
'js' class set by an inline script that was not copied either.
Register 129 -> 129 (one closed, one opened):
R-929 CLOSED - NOT A DEFECT. Measured from the catalog: 60 templates, minus
plant-it (abandoned) and wger (hidden) = 58 offered, exactly what the prose
says; the page's 59th card is FileBrowser carrying the single "Beepitett"
badge. Set difference both ways is empty. The premise was wrong on BOTH
halves. Rule kept: before filing a count disagreement, check whether the
counts are counting the same set.
R-932 OPEN - 8 catalog strings across 5 apps carry an em dash, and they render in
the controller's app page on every real box. Found because the mockups are
the first thing to show catalog copy on a website page. Lives in a repo this
session did not have in scope, so it is a row, not a fix.
PREFLIGHT.md - taste-skill §14 plus the Felhom additions, run in writing against
the DEPLOYED preview, Pass/Fail per line. Measured, not assumed:
page height 1440: 10 922 -> 6 780 px (38% shorter)
page height 390: 19 913 -> 10 865 px (45%, 23.6 -> 12.9 phone screens)
initial load: 13 req / 308 KB -> 11 req / 260 KB (same conditions)
fully loaded: 16 req / ~540 KB -> 15 req / ~545 KB (ESSENTIALLY UNCHANGED -
the 93 KB portrait is paid for by dropping the 49 KB hero logo
and the 31 KB mono font; stated rather than spun)
third-party hosts: 0 -> 0
em dashes in our copy: 18 -> 0
layout families: 8 for 11 sections (3 repeats) -> 10 for 10 (none)
no horizontal scroll: clientWidth == scrollWidth at 390 and at 1440
Contrast: three NEW styles measured 3.88 / 3.14 / 3.57 on the first pass, all under
WCAG AA. Fixed to --text-2 and re-measured on the deployed file: 7.56 / 6.12 / 6.96.
A measurement that lied, recorded because it nearly shipped a false verdict: the
first helper reported .limits p at 1.17:1 by treating the translucent --warn-dim
as opaque. Compositing the whole ancestor stack gives the true 5.67:1, a pass. The
three real failures in the same run were real. An instrument that can report a
wrong number silently is not a measurement.
Two rows filed, both needing something this session may not do alone:
R-930 (Business & legal, P3) the primary CTA is 4.01:1, under AA. MEASURED
IDENTICAL ON THE LIVE PAGE, so pre-existing and site-wide, not a regression
of this redesign. Three fixes offered, each touching brand, so it goes to
the operator rather than being changed unilaterally.
R-931 (Process & tooling, P4) felhom.eu serves NO compression at all - site.css
goes over the wire as 94 310 raw bytes with no Content-Encoding even when
gzip is offered. An nginx setting in manifests/, not a website change.
Worth more than anything on this page.
Register: 127 -> 129 rows, 2 opened, 0 closed. register_shape_gate.py OK.
OUTREACH.md: a personal message, a Facebook group post with a shorter variant,
a forum post, and a table of 15 places with the rules quoted where they are
published. Nothing was posted and no group was joined; the group data was read
from each group's public About page on 2026-10-10.
The rules that matter, measured rather than assumed: Magyar Linux Felhasznalok
(11970, public) has no advertising ban and Felhom is on topic; DIY Smart Home
forbids ads and names an e-mail route; HUP forbids unlicensed advertising; the
prohardver family forbids "tagok, vasarlok gyujtese ... felhivas" without the
operator's permission, which is literally what recruiting testers is.
R-929 (P4): the website's prose says 58 apps, the apps page renders 59 cards,
the catalog holds 60 template directories. Gate 15 cannot catch it because it
compares the two language sets to each other, never to the catalog. Not fixed
here - it needs the catalog skill's exclusion rules. The campaign posts say 58,
matching every prose claim on the site.
1631 (catalog b7f0f7c), 1632 (felhom.eu 970616b7) and 1634 (felhom.eu 29c9cb1e):
every step failure with 0 s after 10.5-14 minutes in set-up, logs absent. A job
never picked up would end at an arbitrary second; the same second-of-the-hour
twice two hours apart points at a periodic sweep or a fixed deadline. Between
them the runner worked — catalog job 1633 succeeded normally on the same tree,
and a shallow clone with no sibling runs the catalog gates green by hand, so the
code is not what is red. The 2026-10-12 due-check's premise is false and the row
now says so.
The operator was asked at the end, as the brief said, and ruled: keep Monica
out. R-927 opened and closed in the same session, with the measurements and the
sentence worth keeping — an app is not added because a gap exists, it is added
because the app can be kept. Register 137 -> 138: 2 opened, 1 closed.
Also in here: the two small things seen and not filed (remove leaves hold-logs
in the stack directory, with no secret in it; the catalog clone's pre-push hook
is unarmed, so the gates were run by hand before the commit and by CI after).
The catalogue side is app-catalog-felhom.eu b7f0f7c. Here: the evidence, the
website, the register and the operator's view.
Website
- Two cards in the Otthon & Eletmod / Home & Lifestyle section of BOTH apps
pages, with assets: grocy-logo.svg is grocy's own icon with its single fill
made white like the other logos, lubelogger-logo.png is the app's own icon
with its dark background dropped and the mark made white (the rule
SparkyFitness's PNG follows), and six screenshots of each app's own UI with a
household's own data, taken headless on the bench from the published template.
- The app count moved 56 -> 58 in 15 places per language set, both languages,
and the open-source tile 49 -> 51. Checked by asking the same patterns for the
new number afterwards. marketing/facebook/COPY.md still says 56 and is NOT
changed: the post it carries is already scheduled.
Evidence
- documentation/audits/new-apps-2026-10-10/ — FIT.md (checklist group 0 for all
three, with the Hungarian-UI column), the bench and box transcripts, the
memory samples, the screenshots and the gate runs.
Register: 137 -> 139 rows, 2 opened, 0 closed.
- R-926 after a remove-keeping-backups and restore, nobody has checked what the
app page shows for an after_install app's generated password. Measured here:
LubeLogger is safe (its login is derived from the environment at every start,
the new password signs in, the data is back); grocy's install password still
signs in from the restored database but the deployed environment no longer
carries ADMIN_PASSWORD at all. Seven apps are in the class.
- R-927 Monica, stopped at checklist 0.2 with the measurements, waiting on the
operator.
Gate scripts: the same console trap in nineteen of them and in repo_gates.py
itself, where it ABORTED THE WHOLE RUNNER at the first gate — printing a
non-ASCII character on this workstation's cp1250 console raised
UnicodeEncodeError before the gate had decided anything, and reuse_refs_check.py
died while printing a NOTE. All now reconfigure their own streams. Red-proof
that the remaining script-test failures are not mine: test_due_checks_gate.py
fails the same 5 of 42 with the change reverted.
Not public. It sits in Planner until Monday evening and can still be changed
or deleted there.
THE POST. Operator chose version 6.2 (kozepes), Hungarian only, 638 Unicode
characters, 0 emoji, 0 hashtags. He chose Monday over today on the reasoning
offered: it was Friday 15:08, the weakest evening of the week for a first
post, and three days in Planner is review time.
post id 1360018983863273_122096547315511222
due 2026-10-12 19:00 Europe/Budapest = epoch 1791824400 = 17:00 UTC
link https://felhom.eu/
READ BACK, and the hex check recomputed OUTSIDE the probe so it is not the
same instrument twice: is_published False; scheduled time sent == read;
message sha256 887514383eff997c on both sides (COPY.md 6.2 and what Facebook
returned). Present in GET /{page}/scheduled_posts. And from a DIFFERENT
CHANNEL than the API: Planner shows it on H 12 at 19:00 with the link card.
SCENARIO A, the dry check that had to come first. A throwaway scheduled post
WITH THE LINK was accepted -- so `link` is not refused on a scheduled post,
which was the open question. Read back hex-equal and unpublished, seen
PRESENT in the scheduled list, deleted, seen ABSENT in the same list. The
removal proof comes from the LIST, not from an error after DELETE, which is
what R-914 asked for.
CHECKED RATHER THAN COPIED. The post repeats the website's "56 alkalmazas".
The apps page carries 57 <div class="app-card"> while saying 56 -- which
reads as an 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.
NOT-A-FINDING, and a "fix" would have made a live public page wrong.
R-917 -> VERIFY (close when the operator confirms it published and is
pinned). R-914 noted, NOT closed: schedule-post covers text + link only; the
photo path stays unbuilt because the spike could not prove a scheduled PHOTO
stays hidden, and the pin, comment moderation and post-insight read-back are
still missing.
Secret scan on the committed evidence: planted EAA decoy 1 -> 0 after
deletion, 0 access_token, no run.log.
I used assets/logo_notext.svg for the header mark. That file is the
LIGHT-BACKGROUND variant: it has SEVEN #00408d fills and ZERO #ffffff, so on
the dark nav the cloud rendered as a hollow outline. The operator caught it.
logo_notext_white.svg is not the answer either -- it is a white OUTLINE
version, also unfilled. Rendered all four candidates side by side on the real
nav background to see it rather than infer it: only logo.svg (and logo.png)
carry the real artwork -- white cloud, #051343 house and servers, #008ddf
swoosh.
FIX: assets/logo-mark.svg, cut from logo.svg -- keep <defs>, path6 and g2;
drop the five wordmark paths and the two empty <text> elements; viewBox
cropped to the mark (70 0 505 295). Vector, correct fills, no text.
All 18 pages point at it; site.css cache-bust v7 -> v8. The CSS comment now
says which file NOT to swap back in, and why.
AND A CORRECTION THAT REMOVES AN OPERATOR TASK (R-916). That row says the
project has no usable vector master because logo.svg "sets felhom.eu as live
text" in 'M+ 2c'/'Vremena Grotesk', and it waits on "the machine with the
fonts". MEASURED today, while cutting the mark out of that very file:
- all five wordmark elements are <path> with real d= geometry
- NO <text> element has any content; the two present are empty leftovers
- the font-family strings the row cites are Inkscape METADATA left on
CONVERTED paths (-inkscape-font-specification). A grep for font-family
finds them and reads as live text -- the likeliest way the original
diagnosis went wrong.
- proof from a renderer that lacks both fonts: Chrome draws logo.svg's
lettering identical to logo.png's, side by side.
NOT re-tested: librsvg specifically -- DooPlex has no rsvg-convert, inkscape
or cairosvg installed today, so the original librsvg/DejaVu observation could
not be reproduced either way. It does not change the structural fact: there
is no font left to substitute. Consequence: the 645x408 PNG is not the only
faithful copy and does not cap picture size.
R-916 state -> READY with "re-check before doing any work: this may need
nothing from the operator at all", rather than closed on my say-so.
R-915 closed and moved to CLOSED-ITEMS in the same commit. What it had waited
on 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 and verified they persisted across a full
reload (not from the save toast):
Privacy policy URL https://felhom.eu/adatkezeles
Terms of Service URL https://felhom.eu/feltetelek
Data deletion instructions URL https://felhom.eu/adatkezeles
Category "Vallalkozasok es oldalak"
THE APP ICON WAS NOT REQUIRED. The original row listed it among the Live
blockers; Meta answered "All required app settings are complete" with it still
empty. Recorded so the next session does not go hunting for one -- and it
could not 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 on posting starting.
R-813's next action (a) is spent.
Also carries the marketing CHANGELOG entry for the header/footer change pushed
in 625d38645c.
CI for the three commits before this one: #875 SUCCESS (after a re-run -- the
first attempt was R-887's lost-job flake, "Set up job" 11m48s then every step
0s), #876 SUCCESS, #877 SUCCESS.
Operator ruled 2026-10-09, after seeing the measurement:
(a) he rotates the remaining services himself -- CC's scope stopped at the
Felhom boundary;
(b) felhom.eu STAYS anonymously readable for now, because making it private
breaks the website git-sync and the installer tag fetch, which both
clone with NO credentials (R-110).
The standing consequence of (b): no secret may ever enter this repo again,
which manifest_bearer_gate.py now enforces with no exemption. If (b) is ever
reversed, the 32 <!-- source --> comments served on /adatkezeles must be
stripped in the same change, because they are a map of the repo.
secrets.md now carries the exact checklist -- namespace / secret / key, 12
rows, RE-MEASURED after the Felhom rotation by hashing against the value git
history still serves, which also confirms the three CC rotated are absent
from it.
Two things recorded with it, both learned the hard way the same day:
- a DATABASE password is not changed by editing the Secret. bookstack-db
root-password is read at first init and then lives in the engine, exactly
like umami's POSTGRES_PASSWORD did.
- check the app can still RESTART before trusting the rotation: umami ran
124 days at 512Mi and was OOMKilled on every restart attempt.
And the urgency, measured rather than assumed: these are not LAN-only.
nextcloud / paperless / bookstack / qbittorrent .dooplex.hu all resolve in
PUBLIC DNS to the public address and answer HTTPS with a login page. No login
was attempted; reachability is the point.
WHY .gitignore "was not working": it was working. git never consults
.gitignore for a file it ALREADY TRACKS. The rule `*secret*` matched fine --
proved by dropping an untracked copy in and watching check-ignore name
`.gitignore:3:*secret*`. The file had been tracked since feea0606, which is
ironically the commit that de-gitted the Resend key.
WHAT THE EXPOSED VALUE ACTUALLY WAS. Not an analytics password: the GITEA
ADMIN ACCOUNT PASSWORD (is_admin true; /api/v1/admin/users answered 200), in
a repo gitea.dooplex.hu serves anonymously to the internet. That is push
access to every repo -- including the one whose website/ is git-synced live
and whose scripts/ is published by tag to every new box installer (R-110).
Re-ranked P2 -> P1 on that measurement; my first ranking had only measured
the analytics blast radius.
Every committed value was still live. Nothing had ever been rotated.
ROTATED (values never echoed; written to a 0600 file on DooPlex):
umami-config APP_SECRET + POSTGRES_PASSWORD. The password was
changed INSIDE postgres (ALTER USER) as well as in the
Secret -- the env var is only read at first init, so
patching the Secret alone would have changed nothing.
healthchecks-config SECRET_KEY + SUPERUSER_PASSWORD (nothing consumes them,
there is no healthchecks Deployment).
gitea-creds no longer holds the admin password at all: a SCOPED
token (read:package + read:repository).
gitea admin new random password; gitea-system/gitea-admin updated.
VERIFIED, not assumed:
- new admin password -> 200, OLD PUBLISHED PASSWORD -> 401 (the leak is dead)
- umami: a real beacon returns 200 (so the app authenticates to postgres and
writes) while a bogus site id still returns 400 (so the 200 means something)
- hub: "Registry version check: latest = 0.304.0" AND "Template fetched
(5881 bytes)", no auth failures
- BOTH token scopes are load-bearing, and the second was found by breaking
it: a package-only token made the hub log "Template fetch: unexpected
status 403", because the template fetcher reads a raw file out of the
felhom-controller repo, not the registry.
AN INCIDENT CAUSED BY THE FIX, recorded because it is the useful part: the
rollout restart needed to pick up the new umami secret put umami into
CrashLoopBackOff and took stats.felhom.eu down (503) for ~4 minutes. Not the
rotation -- at memory 512Mi that pod runs for months but CANNOT RESTART:
startup (Prisma + Next.js) peaks over the limit and is OOMKilled (exit 137).
Raised to 1Gi IN THE MANIFEST, not just live, per .claude/rules/manifests.md
("never bare kubectl set -- the next sync reverts it and the fix silently
disappears").
THE GATE: KNOWN_BACKLOG is removed from manifest_bearer_gate.py, as its own
comment instructed. Red-proofed with a decoy: exit 1 with it, exit 0 without.
An exemption kept this visible for three months and changed nothing.
WHAT REMAINS (operator, and it is bigger than what was fixed): the same
password is still the admin password in ~12 other namespaces -- nextcloud,
paperless, bookstack (a DATABASE ROOT password), tandoor, calibre,
adventurelog, gokapi, qbittorrent, servarr, homepage. Rotating Gitea does not
touch them. Also owed: a kisfenyo Gitea token sits in plaintext in the local
homelab-manifests remote URL and was printed to a session transcript during
this investigation, so it should be replaced regardless (R-580's shape).
NOT a finding: homelab-manifests is private (404 anonymously) and does not
contain the password; ArgoCD's repo credential is a separate token and was
untouched by the rotation.
Found while publishing the legal pages: a background security review flagged
the <!-- source --> comments served in website/adatkezeles.html. Chasing what
those comments point AT found something larger.
MEASURED, and the control is what makes it mean anything:
- manifest_bearer_gate.py itself prints
"manifests/felhom.secret.yaml:39 KNOWN-BACKLOG committed secret"
- that file holds live-shaped values, not placeholders: SECRET_KEY (69),
SUPERUSER_PASSWORD (18), Umami APP_SECRET (66) and POSTGRES_PASSWORD (34),
plus a username/password pair. Values were never printed, only measured
by length.
- gitea.dooplex.hu resolves to 37.191.56.193, the website's public address
- anonymous curl: 200 and 1686 bytes for that file; 200 for hub internals
- OFF-NETWORK CONTROL: fetched from outside the operator's network, a real
path returns the file's first line and a nonsense path returns 404. So
the 200 is genuine anonymous read from the internet, not a LAN-only ACL.
This contradicts documentation/runbooks/secrets.md:3-4, which states secret
values are never committed and the manifests carry only placeholders. That
promise is false today.
Ranked P2, not P1, and the row says why so the operator can overrule: the
exposed credentials guard analytics and an undeployed healthchecks instance,
NOT household data. Measured: umami-db is a ClusterIP service with no
external IP, so the Postgres password is not internet-reachable. No customer
box, hub token or escrow key is in the file.
NOTHING WAS CHANGED. Making the repo private could break the public day-0
installer path (R-110), and rotation plus repo visibility are operator
decisions on production infrastructure. The row carries the order: rotate
first (de-git alone kills nothing — the runbook says so), then decide
visibility, then CC does the de-git and tightens the gate.
Coupled and easy to miss: the 32 source comments on /adatkezeles are harmless
while the repo is public, but become a map of it the moment it is private, so
that is one change and not two. Their traceability is already kept in
documentation/legal/*-1.0.md.
Two new Hungarian pages, live on push: /adatkezeles (privacy notice) and
/feltetelek (what the free closed test is, and is not). Operator rulings of
2026-10-09: no company exists yet, so the operator is named as a PRIVATE
PERSON with no postal address and no phone; publish before the lawyer has
seen it, because the site was collecting data with no notice at all; the full
ASZF, the impresszum and the review wait for the company (R-802, R-809).
- All 18 pages carry the operator, info@felhom.eu and both links in the
footer. Counted, not assumed: 18 pages found = 18 with both links = 18
structurally valid. English footers say the legal texts are Hungarian.
- The contact form stopped claiming something untrue. The old consent said
"az adatokat harmadik felnek nem adjuk ki" while Resend, Cloudflare and
Google carry the message. Both languages replaced; the link opens in a new
tab so a filled form is not lost.
- site_gates.py NO_TWIN gains the two pages ON PURPOSE, with the reason in a
comment: an unreviewed English legal text would be worse than an honest
pointer from the English footer.
- documentation/legal/{adatkezelesi-tajekoztato,feltetelek}-1.0.md are the
text of record, DERIVED from the published HTML so they cannot drift. The
drafts are kept and marked superseded for the closed test.
FOUR LOAD-BEARING CLAIMS WERE MEASURED, not copied from a vendor or a README:
cookies zero, and no local storage - checked in the browser WITH A
POSITIVE CONTROL (a probe cookie WAS visible to the same
method) after the tracker fired; no Set-Cookie on any response
beacon the exact Umami payload: site id, screen, language, title,
url, referrer - no visitor identifier
Cloudflare DNS only: the public A record 37.191.56.193 is not a
Cloudflare address, so site traffic cannot be proxied
fsn1 Falkenstein, Germany (Hetzner's own location list)
Also measured: felhom-ep0-copy-gc.timer is installed and RAN SUCCESSFULLY
(2026-10-09 08:00, exit 0), so "deleted within 30 days" is true today where
on 2026-10-08 it was written but not switched on.
Three retentions are stated as having NO deadline, deliberately and with the
operator's word: website statistics, web server logs and contact messages
have no automatic deletion, and the pages say so instead of promising a date
nothing enforces. Every other period is enforced by configuration and cited.
No placeholder survived onto either page (0 of "[[", control: the draft still
has 36). The impresszum and the full ASZF are NOT published.
R-813 -> NARROWED. R-915 unblocked: the operator enters the two URLs in the
Meta app's Basic settings; the Live switch stays a separate decision.
R-917 and R-920 -> DEFERRED on the operator's (c): park, publish as posts
once posting starts.
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.
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.
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.
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.
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.
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.
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.
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.
admin
d