5 Commits

Author	SHA1	Message	Date
admin	e66d4669d6	v0.315.0: one app page with four tabs; the guide the catalog can carry; no Raspberry Pi badge ... An app was six pages — details, install/settings, logs, export, the per-app backup panel and a details card for moving data — and every "Vissza" on them went to the app LIST, so there was no way back to the app you were looking at. It is now ONE page with four tab URLs under /apps/{slug}/, one shared header and one set of banners. settings Mukodes (Start/Restart/Stop, Stop confirms) + the cards that want something from the household + the install-time and optional settings. The default for an installed app, RENDERED at the bare URL and never redirected to. data the data folders, move to another drive, the nightly copy, the 2nd-copy setting, export guide tagline, screenshots, use cases, first steps, the catalog's guide, the FAQ, the docs link — and the WHOLE page for an app that is not installed logs the log, and the only tab whose poller runs The tabs are links, not panels: a link in an alert has to land ON a tab, and the log poller must not run on the other three. Start/Restart/Stop left the page header, where they read as menu buttons. The old /stacks/{name}/{deploy,logs,export,backup} GETs answer 302 — never 301, which a browser caches beyond anyone's reach — to the tab that now holds them, query string carried through, with name->slug resolved through the stack list rather than assumed equal. Every POST on those paths is untouched: the backup form, the app-email toggle and the reveal endpoints keep their URLs. A value asked AFTER the app starts is now generic (D2). The catalog marks a field `after_start: true` and supplies its label; the ACTION is Go, in a registry keyed by slug + env var. The catalog can never declare what runs — a declared field with no registered action renders nothing, POSTs 404 and logs one WARN with the env var KEY, never the value. A red-proof found the second half of that guard unpinned: deleting the "the catalog must have DECLARED this field" check left the suite green, and a POST for an undeclared field then reached Plex and opened the setup gate. TestAfterStart_RegistryAloneIsNotAnInvitation pins it. New catalog block app_info.guide (sections + faq + checked_version), parsed, localised field by field and rendered with the household's own address filled in. It renders only when checked_version names the image tag its author clicked through. No template carries one yet. The Pi and "csak x86" badges are gone; PiCompatible and the catalog key stay this release, or a box on 0.314.0 would read "csak x86" on every app (R-1067). template_id_gate.py now follows {{template}} includes, with a scope decoy proving the walk did not become vacuous. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y	2026-10-15 18:37:50 +02:00
admin	8f8a64cad7	v0.260.0 — a box ahead of the catalog reads „Naprakész", and the pin never moves backwards (R-524) ... MEASURED 2026-09-15 (BIGNIGHT Phase 6): privatebin updated 2.0.5 -> 2.0.6, catalog reverted to 2.0.5, and the box read „Frissítés elérhető — ma" over an Update that would have moved the pin BACKWARDS onto a possibly-migrated datadir. - stacks.CatalogOrder: the comparison gains a fourth answer (Ahead) and moves out of web, so the badge and UpdatePreflight cannot drift apart. - The badge: ahead reads „Naprakész"/"Up to date", tag-ok, with a title saying why. - The refusal: UpdatePreflight returns `downgrade` (409), born as a bundle key; the API now renders update refusals through errText so it reaches English households. - Ahead is narrow: every differing service must be orderable AND newer, else Behind. - Ordering is util.Version.Compare behind a tag normaliser — no second comparator. - Three red-proofs, each seen to fail. R-589 was already fixed in v0.258.0; only its register row was stale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS	2026-09-21 12:48:55 +02:00
admin	8a0e0a59ad	v0.235.0: freeze the version, keep the fixes flowing (operator ruling 2026-09-06) ... Slice 3. R-447 was BLOCKED because R-438 established that RestartStack's use of up -d to pick up template changes was CHOSEN and written down in its own comment. The operator ruled Option 1, and this implements it. The rule: while the catalog offers the same version you run, its fixes flow to you; the moment it moves to a newer version you are frozen until you update. NOTHING was added to any of the thirteen compose up -d call sites. Most of them are repairs - the boot reconciler, the drive-return gate, the app-stop guard - and a repair path that refuses to repair leaves a customer's app down, which is worse than the problem. They are made safe by removing the reason. app.yaml gains pinned_images: what the app is SUPPOSED to run. It is NOT installed_images, which is an observation; letting a reading become a deployment is the R-166 category error one field over. Four writers, each also storing the exact definition as applied-compose.yml. UpdateStack advances the pin and re-renders BEFORE the pull, because pull and up -d act on the file on disk, and a pin set afterwards would pull the frozen version and report success. The syncer renders instead of copying, through one nil-safe seam. Catalog images equal the pin -> verbatim, so fixes and self-healing both survive; they differ -> the WHOLE stored definition, never a substitution of refs into a newer template (wger 2.6 needs a DB config the older template cannot supply). This is deliberately not 'skip deployed apps', which was option B and was rejected. AdoptPins runs once at boot after the backfill, files only, and skips loudly rather than inventing a pin. syncer.Start() moved to after it: the initial sync would otherwise run while every app was unpinned and overwrite a deployed app's version once per boot. THE BADGE HAD TO CHANGE OR SLICE 2 WOULD HAVE INVERTED SILENTLY. TemplateImages reads the LIVE compose file, which is now the frozen one, so the comparison would have answered Naprakesz on exactly the apps that are behind - with every test green, because the new field has the same type. It now reads CatalogImages. +16 tests (1729 -> 1745), 28 packages green. Three red-proofs run and reverted. A test also caught the syncer writing an empty compose file over a live app.	2026-09-06 09:45:34 +02:00
admin	38d28b5b62	v0.234.0: seed installed_images at startup, so the label appears on an app nobody touched ... The operator looked at demo-felhom the morning after v0.233.0 and found OpenGist - up 15 hours, running exactly the catalog pin - showing no badge at all. v0.233.0 wrote the record only from the four bring-up paths, so an app nobody restarts carried no record indefinitely. On a quiet box that is every app, which is the box we most want to see. The known limitation WAS the feature not working. BackfillInstalledImages runs once at startup, beside BackfillDesiredState and before the boot reconciler. It READS containers: starts nothing, restarts nothing, writes no compose file. It never overwrites an existing record. And it REFUSES to seed a partial observation, which is why this is not a three-line loop: the badge reads a service-count mismatch as BEHIND, so seeding a degraded app from what is visible would render 'Frissites elerheto' over an app that is perfectly current. The bring-up paths may write a partial because they follow a successful up -d where a gap is real news; a backfill meets any state. Same data, two writers, two admission rules - deliberately. Also fixes a calendar bomb of mine: the render test hardcoded catalog_since and the string '46 napja', but the render path reads time.Now(), so it was green on the day it was written and red the next morning. Now derived. Filed as R-457 with six other candidate files named as unchecked, not accused. +5 tests (1724 -> 1729), 28 packages green. Red-proof of the partial guard run and reverted; the wiring and its ORDER pinned by an AST walk.	2026-09-03 11:56:43 +02:00
admin	8025304acc	v0.233.0: record what each compose service actually installed, and badge whether it is current ... Update arc slices 1 and 2. NEITHER CHANGES ANY BEHAVIOUR — no new endpoint, no auto-update, the three lifecycle buttons byte-identical. Slice 1 — app.yaml gains installed_images, keyed by compose SERVICE name, each entry carrying ref + repo digest + first-seen timestamp. Written by Manager.recordInstalledImages after a successful compose up from StartStack, RestartStack, UpdateStack and runComposeDeploy. Read from the CONTAINER, never from docker-compose.yml: the syncer overwrites a deployed app's compose on a 15-minute cycle and the two disagreed for 25 minutes in the spike's own measurement. A failed write NEVER refuses the action - the deliberate opposite of SetDesiredState, because this is an observation and that is an intent. Not called from StartStackServices (the R-47 DB-only window). Its own docker seam with a context and a 30s timeout, which neither existing exec helper has. Slice 2 — .felhom.yml gains optional catalog_since; web.updateBadge compares the recorded ref per service against what the current template pins and returns a *MetaBadge through the EXISTING meta_badge partial. No new markup, no new CSS. NO RECORD RENDERS NOTHING: absent means unknown and never means current. No version number reaches the customer and no registry is queried. Known limitation, filed not hidden: 23 catalog pins float, so those apps can read Naprakesz when the image behind the tag has moved. +17 tests (1707 -> 1724), 28 packages green. Wiring proven through a real RestartStack plus an AST walk of the four call sites. Three companion red-proofs run and reverted.	2026-09-02 20:18:01 +02:00