HACS-Entscheidung und die dabei aufgefallene Auslieferungsluecke festgehalten

HACS scheidet fuer den aktuellen Aufbau aus, gegen die installierte
Version 2.0.5 geprueft statt aus dem Gedaechtnis: HACS kann
ausschliesslich GitHub (fest verdrahtet, dieses Repo liegt auf Gitea),
und keine der sechs Kategorien installiert nach /config/pyscript/ - die
Zielpfade sind custom_components/, www/community/, python_scripts/,
themes/, custom_templates/ und appdaemon/apps/. Die App braucht aber
pyscript/, audi_dashboard/ und Eintraege in der configuration.yaml.

Einziger Weg waere die Konvertierung des pyscript-Backends zu einer
echten custom_component - die nebenbei panel_custom, das www-Kopieren,
die data-Umbenennung, allow_all_imports/hass_is_global und die
pyscript-Abhaengigkeit selbst erledigen wuerde. Umfang gemessen: 2.911
Zeilen, 21 Dienste, 15 State-Trigger, 10 Zeit-Trigger. Der Besitzer hat
entschieden, das bis nach der ersten echten Inbetriebnahme
zurueckzustellen.

Dabei aufgefallen und ebenfalls festgehalten: die Paritaetsregel sichert
Quell-Paritaet, nicht Auslieferungs-Paritaet. Das Panel holt sich
audi-dashboard-version.json bei jedem Seitenaufruf und ist damit sofort
aktuell; die Companion-App ist eine Capacitor-Huelle mit gebuendelten
Assets, package.json sagt 0.1.0 und in src/ prueft nichts jemals eine
Version. Die iOS-App kann also wochenlang hinterherhinken, ohne dass es
irgendwo sichtbar wird. Loesungsskizze im Abschnitt notiert, noch nicht
gebaut - die Entscheidung ueber den Auslieferungsweg steht aus.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AGENTS.md

@@ -1793,6 +1793,52 @@ especially for how long a full year takes (the UI waits up to two minutes before
 in the background). Address reverse-geocoding is not attempted for imported trips (`start_address`/
 `end_address` stay null, same as live-detected ones before the user edits them).
 
+### H) HACS: deferred by decision, and the deployed-parity problem it exposed (2026-08-23)
+
+**Decision: no HACS conversion for now.** Owner asked whether the app could be installed via HACS.
+Checked against the actually installed HACS 2.0.5 rather than from memory — it cannot, for two
+independent reasons:
+
+- **HACS is GitHub-only.** `github.com`/`api.github.com` are hardcoded throughout; no Gitea, GitLab
+  or self-hosted support. This repo lives on `gitea.nothaft.cloud`.
+- **No HACS category installs to `/config/pyscript/`.** The six categories resolve to
+  `custom_components/<domain>/`, `www/community/<name>/`, `python_scripts/`, `themes/`,
+  `custom_templates/` and `appdaemon/apps/<name>/` (verified in `repositories/*.py` → `localpath`).
+  The app needs `/config/pyscript/` **and** `/config/audi_dashboard/` **and** `configuration.yaml`
+  entries — none of which HACS can do.
+
+The only path is converting the pyscript backend into a real custom integration
+(`custom_components/audi_dashboard/`), which would also kill `panel_custom:`, the `www/` copying,
+the `data/`→`audi_dashboard/` rename, `allow_all_imports`/`hass_is_global` and the pyscript
+dependency itself. Scope measured: 2.911 lines, 21 services, 15 state triggers, 10 time triggers,
+39 `task.executor`, 12 `state.set`. Owner chose to defer it until after the app has actually run on
+the real HA — sensible: converting first means debugging the rewrite and the real environment at the
+same time. **Do not start this without the owner raising it again.**
+
+**The open question this surfaced — deployed parity of the iOS app.** The parity rule (binding,
+above) guarantees *source* parity: both codebases change in the same session. It guarantees nothing
+about what is *running*. Today those two are wired completely differently:
+
+- the panel fetches `/local/audi-dashboard-version.json` with `cache: "no-store"` on every page load
+  and reloads its assets when the number changed — current within one page load, no user action
+- the companion app is a Capacitor shell with `webDir: "dist"` and **bundled** assets, sideloaded
+  through Xcode. `package.json` says `0.1.0` and **nothing in `src/` ever checks a version.** It
+  stays on whatever was bundled at signing time, silently, indefinitely
+
+So the iOS app can be weeks behind the panel with nothing anywhere making that visible. That is a
+real gap, not a hypothetical one, and it gets worse once the app is genuinely in daily use.
+
+Proposed shape (discussed 2026-08-23, **not yet built** — needs the owner's call on the delivery
+layer): one shared version stamp fed into both builds instead of today's unrelated
+`audi-dashboard-version.json` integer and `0.1.0`; the backend publishing the version it shipped
+with, so both frontends can compare their own build stamp against it and show a visible hint when
+behind (drift becomes loud instead of silent); and for delivery, OTA web-bundle updates so the iOS
+shell can follow without an Xcode rebuild. Pointing Capacitor's `server.url` at HA was considered
+and rejected: it would make the app as current as the panel, but the shell then cannot boot without
+reaching HA, which guts the deliberately built offline queue (`api/warteschlange.ts`). Note the
+whole mechanism survives the later integration conversion unchanged — that end state serves panel
+assets and companion bundle from the same component, so one HACS update moves both.
+
 ### G) Fresh-install audit + installer hardening (2026-08-23, before the first real deployment)
 
 Owner is about to install on the real HA OS instance and asked for two things: that the one-click