OTA-Buendel neu gepackt - ausgeliefert war eine Oberflaeche ohne den Versionshinweis (2026.9.3.4)

bundle.json trug 2026.9.3.3, gebaut am 02.09. 23:54 - der Versionshinweis
kam aber erst am 03.09. 09:50 dazu (c254cf5). In allen 16 Dateien der
ausgelieferten Zip kein Treffer fuer den neuen Code: die .ipa hatte das
Feature, das Buendel unter derselben Nummer nicht.

Kein vergessener Schritt. package.json bindet "ota" an eine Windows-
PowerShell-Datei; ios-signieren.sh baut ein frisches dist/, packt es in die
.ipa und fasst das Buendel nie an - npm run ota liesse sich dort auch gar
nicht ausfuehren. Jede Auslieferung vom Mac erzeugt diese Divergenz.

Schlimmer als der in VERSIONIERUNG.md beschriebene Normalfall, weil die
Nummern uebereinstimmen: die Pruefung in install.ps1 vergleicht Versionen,
nicht Inhalte, und schweigt deshalb.

Neue Nummer statt derselben, weil ein Geraet auf dem faulen .3.3 gegen den
Server "gleich" meldet und nie wieder etwas angeboten bekaeme. c254cf5 war
ausserdem eine Oberflaechenaenderung ohne Versionserhoehung - beides holt
2026.9.3.4 nach.

Verifiziert: neue Zip enthaelt dm360.version.gesehen, bundle.json auf .3.4,
sha256 54a1d06c...

Noch offen (Abschnitt BV): ota-paket.ps1 nach Node portieren und in
ios-signieren.sh hinter npm run build aufrufen, damit .ipa und Buendel aus
demselben dist/ kommen; dazu ein Waechter ueber die Git-Historie.

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

AGENTS.md

@@ -1,6 +1,8 @@
 # AGENTS.md — Project state, review findings, open items, and working rules
 
-**Last updated: 2026-09-03** (Zwei Signalwechsel in derselben Sekunde kosteten eine Fahrt - Sperre
+**Last updated: 2026-09-03** (Das OTA-Buendel kann auf dem Mac gar nicht entstehen - ausgeliefert war eine
+Oberflaeche ohne den Versionshinweis unter richtiger Nummer, repariert mit `2026.9.3.4`,
+Abschnitt BV. Davor: Zwei Signalwechsel in derselben Sekunde kosteten eine Fahrt - Sperre
 plus Regressionstest, Bildformat-Pruefung, `2026.9.3.3`, Abschnitt BU. Davor: Rueckblick loest Orte
 selbst auf, Fotos werden vor dem Upload verkleinert, Abschnitt BT. Davor: Kalendertermine gehen ueber EventKit statt ueber das
 Teilen-Blatt, Abschnitt BS. Davor: Null heisst unbekannt, Momentanwerte nur fuer
@@ -8727,3 +8729,36 @@ Hinweisstreifen hat dieselbe Eigenschaft seit jeher. Sortierbar zu vergleichen w
 Alternative wäre ein zweites Signal vom Backend, und das lohnt für diesen Randfall nicht.
 
 Verifiziert: `tsc --noEmit` sauber, 179/179 Tests (6 neue).
+
+---
+
+## BV. Das OTA-Bündel kann auf dem Mac gar nicht entstehen (2026.9.3.4)
+
+Beim Gegenlesen der vier Mac-Commits gefunden: `bundle.json` trug `2026.9.3.3`, gebaut am
+02.09. 23:54 — der Versionshinweis (`c254cf5`) kam aber erst am 03.09. 09:50 dazu. In allen 16
+Dateien der ausgelieferten Zip: **kein Treffer** für den neuen Code. Die `.ipa` hatte das Feature,
+das Bündel unter derselben Nummer nicht.
+
+**Das war kein vergessener Schritt.** `package.json` bindet `ota` an
+`powershell -File scripts/ota-paket.ps1` — eine Windows-Datei. `ios-signieren.sh` baut in Zeile 70
+ein frisches `dist/`, packt es in die `.ipa` und fasst das Bündel nie an; `npm run ota` liesse sich
+dort auch gar nicht ausführen. **Jede Auslieferung vom Mac erzeugt diese Divergenz**, nicht nur
+diese eine.
+
+**Schlimmer als der in VERSIONIERUNG.md beschriebene Normalfall**, weil die Nummern übereinstimmen:
+die Prüfung in `install.ps1` vergleicht Versionen, nicht Inhalte, und schweigt deshalb. Wer per OTA
+auf `2026.9.3.3` ging, bekam eine Oberfläche ohne das Feature und hielt sich für aktuell.
+
+**Repariert mit einer neuen Nummer, nicht unter derselben.** Ein Gerät, das schon auf dem faulen
+`.3.3` sitzt, meldet gegen den Server „gleich" und bekäme nie wieder etwas angeboten. Ausserdem war
+`c254cf5` eine Oberflächenänderung ohne Versionserhöhung, entgegen VERSIONIERUNG.md — beides holt
+`2026.9.3.4` nach. Verifiziert: neue Zip enthält `dm360.version.gesehen`, `bundle.json` auf
+`.3.4`, sha256 `54a1d06c…`.
+
+**Noch offen, und der eigentliche Fix:** `ota-paket.ps1` nach Node portieren und in
+`ios-signieren.sh` direkt hinter `npm run build` aufrufen — dann kommen `.ipa` und Bündel aus
+demselben `dist/` desselben Laufs und *können* nicht mehr auseinanderlaufen. Eine Fremdabhängigkeit
+braucht es nicht: die Zip-Einträge schreibt die PowerShell-Fassung ohnehin von Hand (Begründung in
+ihrem Kopf), `zlib.deflateRawSync` reicht. Dazu ein Wächter, der in der **Git-Historie** den letzten
+Commit an `bundle.zip` gegen den letzten an `companion-app/src` und `design-system/src` hält — über
+Git und nicht über Dateidaten, weil ein frischer Klon alle Zeitstempel plattmacht.

custom_components/audi_dashboard/frontend/app/bundle.json

@@ -1 +1 @@
-{"version":"2026.9.3.3","sha256":"7b2e99c4c05b9522abc8cb3276a9cca3fd25d23c25db1ebd79d312be712f9945","bytes":266735,"gebaut":"2026-09-02T23:54:05Z"}
+{"version":"2026.9.3.4","sha256":"54a1d06cd129ee5c8c28869a7191a40adbfb383b5090bd2feaed2ec9c8c1ffe9","bytes":267146,"gebaut":"2026-09-03T08:56:06Z"}

custom_components/audi_dashboard/manifest.json

@@ -1,7 +1,7 @@
 {
   "domain": "audi_dashboard",
   "name": "Audi Dashboard",
-  "version": "2026.9.3.3",
+  "version": "2026.9.3.4",
   "documentation": "https://gitea.nothaft.cloud/paul/audi-app/src/branch/main/README.md",
   "issue_tracker": "https://gitea.nothaft.cloud/paul/audi-app/issues",
   "codeowners": ["@paul"],