felhom-controller/REPORT.md

REPORT — controller v0.260.0: a box ahead of the catalog, and a pin that never moves backwards

R-524 (P2). Base 19ef0329ab66 → v0.260.0 (8f8a64cad7a5). MinAgent 0.131.0 unchanged. Architecture read first and named: felhom.eu/documentation/architecture/09-update-architecture.md (§3 the nine decisions, §5.4 the render table, §6.1 slice 4 as shipped, §8 the limitations).

What was wrong

Measured, not imagined — BIGNIGHT Phase 6, 2026-09-15, VM 333. privatebin was updated 2.0.5 → 2.0.6 through the guarded Update; the catalog was then reverted to 2.0.5. At 22:13:37Z the box read installed privatebin/pdo:2.0.6, catalog privatebin/pdo:2.0.5, and the app page showed „Frissítés elérhető — ma" with a title inviting the household to press Frissítés. The comparison asked only does the installed reference DIFFER?, so a catalog revert — an operator act on our side — presented itself to a customer as an update, and the guarded Update behind it would have advanced the pin 2.0.6 → 2.0.5, onto a datadir the newer version may already have migrated, with §4's ruling saying that cannot be undone.

What shipped

• stacks.CatalogOrder (controller/internal/stacks/updateorder.go) — the comparison gains a fourth verdict (Unknown / Current / Behind / Ahead) and moves out of web. That move is the substance: two callers must reach the same verdict — the badge and Manager.UpdatePreflight — and a comparison implemented twice is a comparison that drifts. web.compareInstalledToTemplate is now a thin wrapper and keeps every property it had (absent means UNKNOWN and never „Naprakész"; it reads CatalogImages and never TemplateImages; it queries no registry).
• The badge. Ahead reads „Naprakész" / "Up to date", tag-ok — the same word and class as level, because there is nothing for the household to do — with a title that says why (badge.update.ahead.title, born as a key in both bundles). No version number reaches the customer.
• The refusal. UpdatePreflight returns reason downgrade, HTTP 409, „Ez a változat újabb a katalógusban lévőnél — visszalépés csak az üzemeltető kérésére.", logged with both image maps. The API now renders update refusals through errText — without that one line the new key would have been a seam built and never wired, which is a documented failure class here.
• Ahead is the NARROW arm. Every differing service must be orderable AND newer; one older, one unorderable, and the verdict falls back to Behind — i.e. to v0.233.0..v0.259.0 behaviour. This gate can BLOCK an update, so it errs towards letting one run.
• Ordering is util.Version.Compare and nothing else (house rule: one comparator). The new code is a tag NORMALISER in front of it.

What the fixture caught that the design did not

The first implementation called every real catalog tag unorderable. It accepted only bare X.Y/X.Y.Z, and the test fixture uses nextcloud:31.0.14-apache — the real catalog pin. The refusal test failed with got nil, and the cause was the code being right about a rule that was wrong. The rule now takes the version at the FRONT of the tag and requires the trailing suffix to be identical on both sides, so 31.0.14-apache → 31.0.15-apache orders while 26.05.2-ls310 → -ls311 (a build number with no rule), postgres:16-alpine (a major LINE, not a version), kimai/kimai2:apache-2.57.0 (version at the back), a date stamp and a digest pin all stay unorderable. Measured against the real catalog: 8 of 66 pins float and one puts its version last.

Red-proofs — three, each SEEN to fail

#	the mutation	what failed
1	make CatalogOrder's Ahead arm unreachable	TestR524_PreflightRefusesDowngrade/ahead — "this update must be REFUSED with reason "downgrade", got nil". The update is ALLOWED and the next thing it does is move the pin back.
2	treat an UNORDERABLE pair as ahead (cmp < 0 with the ok dropped)	the floating-tag, different-image and digest-pin cases all fail with Ahead — the verdict that would suppress a real „Frissítés elérhető" on the floating pins
3	delete the ahead arm from localeFuncs	TestUpdateBadgeFollowsTheLanguage — "an app ahead of the catalog must carry a badge"

An honest note on #1: the first attempt deleted the preflight block and failed to BUILD (an unused import), which proves nothing. It was redone by neutering the Ahead arm instead, and that failed for the right reason.

A claim in the brief that was wrong, named

R-589 was NOT open. The brief said, reviewer-verified, that updatebadge.go builds the badge from four raw Hungarian literals with no key and that R-589 is therefore open. The literals are real; the conclusion does not follow. They are the Hungarian form and are deliberately frozen — that IS the parity guarantee — and the ENGLISH form has been rebuilt from the bundle in web.localeFuncs since v0.258.0, pinned by TestUpdateBadgeFollowsTheLanguage and proven live on a fresh box the same morning (DRILL-first-hour-en-0258-2026-09-20.md item 9). The register row was stale, not the code; it is closed with that citation. The general lesson: a reviewer who reads one producer cannot see a second producer that overrides it. updatebadge.go now says so in its own comment, and v0.260.0's new arm was written into BOTH producers with a test that fails if either is missing.

Green gate and delivery

go build ./... && go vet ./... && go test ./... — all green (full suite, not a subset). controller_gates.py --fast — 17 gates, all OK; go-parity convicted first and was satisfied properly, by registering both new keys as BORN-AS-KEYS in i18n_go_keys.json with the test that pins each. No --no-verify; the pre-push hook ran and passed.

Image gitea.dooplex.hu/admin/felhom-controller:0.260.0 built and pushed. Deployed and healthy on three guests: demo-felhom 9201, demo-hp 9201, and demo-hp 9202 (the scratch guest, upgraded from 0.245.0 for the live proof).

The fleet floor was NOT raised, and the number in the repo's own CONTEXT was stale. CONTEXT.md said the floor stood at 0.257.0; the hub says 0.259.0 (read live from /configs, not from a document — the operator raised it after that entry was written, which felhom.eu/STATUS.md records). v0.260.0 therefore reaches the two demo boxes by hand and no further.

Stated rather than silently skipped: the standing rule asks for the floor to be raised to deliver a release, and this session deliberately did not. Why: a floor raise reaches peti-felhom, a real customer box, and the unprompted-work fence puts anything that changes risk to customer data behind an operator word. The two preceding sessions recorded the raise as the operator's own act, and the one that happened came after the operator asked for it. Put to the operator with what happens if they do nothing: the fix stays on the two demo boxes and the rest of the fleet keeps offering a downgrade as an update — which is a badge and a button, not data at risk, so waiting costs little.

Live proof, drift numbers and the state of the whole arc: felhom.eu/documentation/audits/UPDATE-ARC-STATE-2026-09-21.md and audits/update-arc-2026-09-21/.