diff --git a/AGENTS.md b/AGENTS.md
index f5c4fc0..d254634 100644
--- a/AGENTS.md
+++ b/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