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
A page-by-page review of the live site (1440px and 390px) found six defects and
two editorial questions. The operator answered three questions; the answers and
the evidence are in REPORT-review-2026-10-12.md.
Fixed:
- The contact form showed its consent error before any submit, on both pages:
#privacyError sits outside any .form-group and the hide rule was scoped to
.form-group. Scoped to the page. Checked: load (none) -> submit unticked
(shown) -> tick (gone), with no message sent.
- The consent checkbox is the site's own control now: 24px box, keyboard focus
ring, and a second <label for="privacy"> at 44x44 round it for touch.
- The contact page promised a reply within 24 hours while /feltetelek 1.1 §4
promises no reply time. Now 1-2 days usually, and no promise during the test.
- sitemap.xml was missing /szolgaltatasok and /en/services: 18 -> 20 URLs.
- The pre-shell mobile-menu script still ran on 20 pages and logged
"[mobile-menu] Missing elements" on every one. Removed.
- The sidebar's tester button was btn-outline while the hero's was btn-primary.
- The home page's "Mit tud a doboz ma?" was three bare links; each card now
carries 2-3 of the services page's own items, word for word.
- A plain Facebook link in the footer of all 22 pages. No script, widget or
pixel: the only external hosts any page refers to are still felhom.eu and
stats.felhom.eu.
Voice (operator ruling: "I" everywhere a person speaks): contact, tester and FAQ
pages in both languages, and the home and services pages that repeat the same
promises. An inclusive "we" (you and I, talking) stays plural, and the legal
texts are untouched. Each FAQ answer exists twice (JSON-LD + visible) and gate 18
holds them equal - it caught the five answers whose markup split the sentence.
Hero clip rebuilt: Immich first, so the poster is a wall of real photographs;
the Jellyfin scene starts after the demo's library wall (eleven pieces of poster
art whose licence cannot be quoted from a first-party source); 1.3s of blank
screen cut from the OnlyOffice scene. The film that plays, Caminandes 3:
Llamigos, is CC BY per Blender's own video platform ("licence": {"id": 1,
"label": "Attribution"}) - NOT public domain as website/CHANGELOG.md said
yesterday. That sentence is corrected in place and the film is credited under
the hero caption.
New gate 24: sitemap.xml lists every public page once, with its twin's hreflang
pair, and lists nothing else. Decoy: site/sitemap-missing-page, the exact shape
the reviewer found by hand.
site.css ?v=30; hero clip and poster ?v=2.
- 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
The operator recorded the six scenes and ruled on their length: use them whole,
"they had been cut as I liked them". Jellyfin, Tandoor, OnlyOffice, Immich,
RomM, Paperless, 0.6s crossfades, 36.6s looping at 904x556.
- hero-clip.mp4 (1 134 KB) + hero-clip.webm (1 295 KB) + hero-poster.webp
(53 KB), one set for both languages: the recordings are the same on / and /en/.
- The hero <video> sits in the frame's cut-out hole at z-index 1, the frame above
it at 2. No autoplay attribute: the page's script starts it when the hero is on
screen, pauses it when it leaves, and never starts it under
prefers-reduced-motion. With JS off the poster stays.
- make_hero_clip.py reads each scene's own length (ffprobe) instead of cutting
every one to a fixed window, and the xfade offsets count from the running sum
minus one fade per transition already made.
- site.css ?v=26 on all 22 pages.
NOT verified: playback in this workstation's Chrome, whose media pipeline loads
nothing at all today (a 1 KB generated WAV blob stalls the same way, with no
error) - which rules the clip out as the cause. Geometry, layering and the
poster frame were verified in the browser.
Jellyfin, Paperless and RomM were filmed on those projects' own public demo
sites; the films in the Jellyfin scene are public-domain prints.
Reported from his own screens. Five defects, two design.
1. THE CATEGORY ANCHORS WERE DEAD - all 100 of them. The sidebar's five app-category
links pointed at #fajlkezeles-irodai and friends; the ids are #fajlkezeles and
friends. The sidebar is copied into every page, so one wrong fragment was wrong
twenty times, and a dead fragment raises no error anywhere: the browser stays put.
New gate 23 resolves every in-site #fragment against the page it names (360 today).
It convicted two more on its first run: the home page's four hero tiles pointed at
/alkalmazasok#immich, which no page had ever carried, and the FAQ's contact button
pointed at a home-page section that had moved out. Every app card now carries its
slug as an id - taken from the card's own logo file, which gate 21 already ties to
the catalog, so the ids cannot drift from it silently.
Decoy site/dead-fragment puts the operator's own bug back and the gate convicts.
2. SZOLGALTATASOK IS A PAGE: /szolgaltatasok + /en/services, registered in TWINS, URL
and SHELL. The ten capability items moved VERBATIM out of the home page; the home
keeps the promise sentence, the three group names as links and a button, and is 345
Hungarian / 434 English words shorter. The .caps rules stopped being .page-index-
scoped, because the block now lives on a page with a different body class.
3. THE HOME HEADLINE is back in the hero column beside the picture, two lines with the
second in --blue-bright at clamp(2.1rem, 4.4vw, 3.2rem). M3 had moved it into
.page-header - the INNER pages' heading - so it shrank to 2.1rem and the domain
badge was stranded beside it.
4. THE HERO PICTURE is the real dashboard in a laptop. The frame is the operator's own
supplied render; the screen is dashboard-start-{hu,en}.webp composited into it, so a
visitor sees a real box's Launcher rather than a drawing of one - the supplied
screens are AI-drawn and misspell app names. 57 KB, named dashboard-laptop-<lang>
so gate 19 holds it to the page's language.
5. .page-lede HAD NO CSS AT ALL on 16 pages: a bare paragraph, full width of the
content column, hard against the box beneath it. 760px measure, centred over the
box, air beneath; left-aligned on /szolgaltatasok, which has no centred box.
6. THE SIDEBAR LOGO: the wordmark shipped at 0.67x the mark's width where the real
lockup (assets/logo.png, measured: mark 492px wide, wordmark 631px) has it at 1.28x.
Mark 112px, wordmark 25px tall, 28px less vertical padding.
7. SCROLLBARS are the page's own now. The first attempt missed the viewport's: it is
painted from <html>, and a `body.shell ::-webkit-...` rule only reaches scrollers
inside the page.
Also: the two Latin font subsets are preloaded. With font-display: swap the page
reflowed after first paint - measured at 1339px on /alkalmazasok#media.
Checked at 390px and 1440px on all 21 pages: no sideways scrolling, footer inside the
content column everywhere, drawer opens with all 13 items. site.css?v=24.
The two defects the operator found on his own phone are fixed and live since
5aeb36b5; this is what pins them so they cannot come back silently.
site_gates.py gate 22 parses site.css and shell.css into
(media context, selector, declarations) and fails on any property site.css
declares on a selector shell.css also styles that nothing overrides - neither
shell.css itself nor a `.shell ...`-scoped reset. site.css loads first, so
"later wins" is per PROPERTY, not per rule. Today: 689 site rules vs 119 shell
rules, 9 shared selectors, 0 leaks. .hamburger-box / .hamburger-line are an
explicit allow-list with the reason beside them.
It is media-aware precisely because the check it replaces was not. The STOP-1
leak diff excluded @media blocks and reported "exactly six" leaking
declarations; the real number is forty, and the worst of them
(@media (max-width: 900px) .nav-links { position: fixed; right: -100% })
parked the drawer's menu off-canvas and shipped.
Two decoys in test_gate_decoys.py, both the exact shape that went live, both
seen to convict:
site/shell-css-leak-in-media the body:not(.shell) scope taken back off that
one rule - the gate names the media query, the
selector and `right: -280px`
site/footer-outside-main <main> closed early on gyik.html - gate 3b's line
They plant and restore BYTES, with the anchor translated to the file's own line
ending: these files are CRLF in a Windows worktree and LF in a Linux one, and
replace_in's text-mode round trip would have rewritten a whole file on one side.
Also: CHANGELOG entries for both areas, the M3 report corrected where it quoted
its own wrong "exactly six", and one plain-language STATUS line.
Records what shipped, the two operator decisions as answered, what the website and
the controller now share and how a change flows between them, and the five faults
that measurement caught before the switch rather than after.
head-before.json / head-after.json are kept as the evidence that the switch changed
no SEO-bearing tag: the only difference across 19 pages is the dash substitution
inside the two FAQ pages' JSON-LD.
Every document that described the biography as a home-page section would now be
wrong, so each is corrected rather than left:
ki-all-mogotte.md gains 'Where it ended up' with the operator's reasoning, the
rejected /rolam option, and why the home page keeps a trace
AUDIT.md lever 2 carries a dated revision note (the audit itself is a
record of what was found, so it is annotated, not rewritten)
PREFLIGHT.md re-measured on the deployed page after the move:
1440: 6 780 -> 6 385 px (42% shorter than the old page)
390: 10 865 -> 10 145 px (49% shorter, 23.6 -> 12.0 screens)
sections 10 -> 9, layout families 10 -> 9, still no repeat
eyebrow allowance 4 -> 3, still 0 used
website/CHANGELOG the live change, with the layout bug that the deployed page
revealed and the markup did not
REPORT + STATUS what is live vs what is still waiting on the operator
The numbers moved because a whole section left the page; leaving the old ones in
place would have been a quiet overclaim in the other direction.
REPORT-redesign-2026-10-10.md (not REPORT.md: that file belongs to the kernel
night session de4a8d20 and is overwritten per session).
NEXT.md - the other pages in order with what each needs, and the traps:
teszteles/en/testing first (the destination of every CTA, newest page)
gyik/en/faq second, with the warning that gate 17 requires the FAQPage JSON-LD
to EQUAL the visible answers, so every copy edit there is a two-place edit
technologiak third ("Ipari szintu megoldasok" is the exact language the home
page just removed)
alkalmazasok is BLOCKED on R-929 - prose 58, page 59 cards, catalog 60
adatkezeles/feltetelek are reviewed legal texts; a dash sweep there needs the
operator's word separately and is not ours to take
It also records the per-page em-dash count: 300 across 19 pages, the preview
being the only page at zero.
STATUS.md - the operator's one screen, in plain language: the preview is waiting
on him, the two fixes that DID go live, and the two new decisions (R-931 the
missing compression, R-929 the app count).
website/CHANGELOG.md - the footer sweep and R-930, both with their measurements
and with the scope stated rather than implied.
Register 127 -> 129 (R-930, R-931 opened; none closed).
Records what your screenshots turned up: the per-page scoping that left the
tester pages unstyled, the site-wide missing base link rule (which also
affected gyik/technologiak/biztonsagimentes), the sitemap BOM, and the
correction that nobody is testing today so all five places are open.
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.
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.
PART A -- the poster. documentation/architecture/felhom-system-poster.html
(307 KB). Secret scan first: ZERO IPv4, zero PEM blocks, zero ssh keys, zero
Bearer. The one EAA... match is base64 inside an embedded "mime":"font/woff2"
blob, not a Facebook token. "token"/"secret"/"password" appear 11 times and
every one is a NAME ("6. ep0 read token", "the hub seal key"); the poster
itself says "Names only; no secret values". All five long base64 blobs are
declared assets: 1 image/png, 3 text/javascript, 1 font/woff2.
It renders with NO network: the source mentions cdn.jsdelivr.net and Google
Fonts, but the loaded requests are only the HTML plus blob:/data: URLs -- the
bundler inlined everything. Measured, not assumed, and it matters: this is a
disaster-recovery document, so needing the internet to draw would be a defect.
No console errors.
The operator's three Claude Design fixes are all present: (a) no "WG" badge,
WireGuard only for the tunnel, no badge on the ep0-copy tile; (b) the box ->
ep0 arrow reads "encrypted on the box, sent through WireGuard"; (c) "Known
gaps" holds two items and NOT the household-keys sentence, which is now a
neutral "By design" note under the ep0 household namespace.
ONE FACT ON IT WAS WRONG. The felhom.eu tile said "served from DooPlex through
Cloudflare". It is not: Cloudflare is DNS only and the traffic goes direct --
measured this morning for the privacy notice, which states exactly that. The
poster would have contradicted a published page. Fixed in place (a label):
"served from DooPlex, Cloudflare DNS only". The first wording overflowed the
fixed-size tile, so it was shortened to fit and the evidence lives in the
facts file instead -- checked by re-rendering, not by hoping.
PART B -- the facts and the rule. DESIGN-PROMPT-...md is renamed
felhom-system-poster.facts.md (one home per fact), with the three fixes folded
in as explicit instructions so a regeneration cannot undo them, plus a new
"Badges" section saying a "WG" chip must never come back.
New rule, section 6 "The system poster stays true", added IDENTICALLY to all
five copies of unprompted-work.md (the four repos and the workspace root on
DooPlex; verified identical by diff before and after) and to
PROMPT-TEMPLATE.md's end-of-session checklist as a FIFTH coupled artifact.
scripts/poster_facts_gate.py WARNS when the facts file has a newer commit than
the poster. It never fails a push, deliberately: a refresh needs Claude Design
and the operator, --no-verify is forbidden here, so a blocking gate would leave
deleting it as the only way out. It compares COMMIT times, not mtimes, because
a checkout rewrites mtimes and every fresh clone would shout.
RED-PROOF -- and it found a real bug in the gate. The first run warned
correctly but exited 1: a single non-ASCII character in its own warning raised
UnicodeEncodeError on this cp1250 console. A gate whose entire contract is
"never fails a push" was failing pushes. Fixed (ASCII output + an encode
guard), and the decoy now asserts BOTH the warning and exit 0. Three branches
proven: facts newer -> warns, rc 0; poster newer -> quiet, rc 0; poster
missing -> "could not tell", rc 2, not a false all-clear.
The decoy itself was seen to fail, twice, on Linux (the suite needs fcntl and
cannot run on Windows): breaking the warning gives STALE_WARNS=False, and
making it exit 1 gives RC_STALE=1. All 80 felhom.eu decoys behave.
PART C -- do box reports pass through Cloudflare? NO. Two channels. DNS from
PUBLIC resolvers (not DooPlex's own, which answers the LAN address):
hub.felhom.eu is a CNAME to dooplex.hopto.org -> 37.191.56.193, not a
Cloudflare address, and no cf-ray comes back. The manifest: an ordinary k3s
Ingress, Cloudflare named only in a DNS setup comment. THE CONTROL that makes
the negative mean something: iso.felhom.eu resolves to 172.67.x / 104.21.x,
real Cloudflare addresses -- so the method does detect proxying.
So nothing is added to the Cloudflare row: the hub path does not touch it.
06-offsite-connectivity.md section 1 claimed the public edge is a
Cloudflare-Tunnel and "DooPlex has no public IP" -- both untrue today. Kept
and marked STALE with the measurement rather than rewritten, because that
paragraph is the reason ep0 exists and the argument needs its premise visible.
total-loss-of-dooplex.md's "today a CNAME to dooplex.hopto.org" is confirmed
correct.
Register: 137 before, 137 after, 0 opened, 0 closed -- every finding here was
small and fixed in the session.
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.
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.
Same two Windows-only gate failures as the previous commit (instructions: the
Windows workspace CLAUDE.md is MEANT to diverge from the DooPlex-shaped
versioned copy; script-tests: WinError 32, no sqlite3 CLI, POSIX shell tests).
All 18 gates are green on DooPlex at 97d3c29f9c, run in a throwaway worktree
beside the sibling repos, and CI run #863 for that commit is Success.
unproven.py --summary unchanged: 35 of 55 not walked.
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.
The DooPlex gate run at 8664cbda is rc=0, all 18 gates OK; the Windows run's two
failures are platform artifacts (fcntl, symlink privilege, C:/E: mount, cp1250
console) and the deliberate workspace-CLAUDE.md divergence.
CI gates.yml #846 for 8664cbda78: Success, 4m39s. The Gitea API refused every
credential in the store (401), so the run was read from Gitea's web UI, which
serves the Actions list unauthenticated; /actions/runs/846 redirects to
/actions/runs/1573, R-417's index-vs-id offset again, so both numbers are on the
screenshot.
STATUS: the Facebook section rewritten for what is now live, the open-items
count corrected to the counted 140.
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.
Read phase passes (Page 1360018983863273, CREATE_CONTENT/MODERATE/ANALYZE, page token PAGE expires_at 0, three insights
metrics alive on v26.0). Write test: removal check accepts Meta's code-10 'Object does not exist' (fixed without a row,
4 tests); run 1 evidence kept. R-914 READY, R-915 narrowed to Live mode.
scripts/facebook/fb_probe.py (stdlib, read + write-test, no real-post command) with tests; read run twice:
SYSTEM_USER, expires_at 0, /me/accounts empty, so D/E did not run and nothing was posted. Findings, redacted
evidence, CONTEXT decision home, STATUS item, scripts CHANGELOG, REPORT-facebook-page-api.md.
Register 131 -> 134 (R-909 Apps card header, fixed on main; R-910 retake the website's dashboard pictures
after tomorrow's release; R-911 storage-unavailable banner stays Hungarian on English pages).
Evidence: before (0.303.0) / after (0.304.0-layout.rc2) pictures and measurements on scratch 9202, red proofs,
fixture diff. 9202 is back on 0.303.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qRErfCoiTkvDK9N5XHbzb
admin