Audi Type Wide Normal fuer die grossen Zahlen, Audit-Durchgang

- Audi Type Wide gab es hier nur als Light (300). Der Eigentuemer hat den vollen Satz aus Audis Styleguide geliefert; Wide Normal (400) ist jetzt eingebunden (App und Panel), Wide Bold liegt vor und bleibt bewusst ungenutzt. Lizenz wie bei allen Audi-Assets: nur diese eine private Installation, deshalb nichts davon in design-system. - Dabei gefunden: die Aenderung im Design-System allein war wirkungslos. audi-schrift.css bringt fuer .ads-fig eine eigene, spaetere Regel mit und gewinnt. Im gebauten Stylesheet standen beide - nur die Reihenfolge entschied, und sichtbar wurde es erst am gerenderten getComputedStyle. - Vollstaendiger Durchgang (AGENTS.md Abschnitt DC): Statik, struktureller Paritaetstest ueber Routen, Dienste, Sensorrollen, Wortlaut und Statusfelder, dazu ein Funktionstest an beiden laufenden Oberflaechen. Ein echter Befund: standort_genauigkeit_m ist totes Schema im Panel. Drei Meldungen des Eigentuemers waren keine Fehler - das breite Layout, der Beschriftungs-Schalter ohne Reiterleiste, und eine Testfahrt von mir. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 17:47:50 +02:00
parent e76252505f
commit 1a6c8d4740
9 changed files with 165 additions and 6 deletions
@@ -1,6 +1,6 @@
 # AGENTS.md — Project state, review findings, open items, and working rules

-**Last updated: 2026-09-05** (Tankstelle zweizeilig und antippbar, die Belegkarte sagt bei
+**Last updated: 2026-09-05** (Audit-Durchgang, Abschnitt DC) (Tankstelle zweizeilig und antippbar, die Belegkarte sagt bei
 fehlender Position die Wahrheit statt einen toten Knopf zu zeigen, der Regler bekommt einen
 Speichern-Knopf, und die Share-Erweiterung trug eine andere Versionsnummer als die App;
 dazu die Kopfmarke statt der Firmierung des Betreibers und ein
@@ -7839,6 +7839,128 @@ nicht setzen, und synthetisches Fetten verschmiert die Striche. Braucht
 entweder die Schriftdatei vom Eigentümer oder die Entscheidung, für diese eine
 Zahl auf „Audi Type" 400 zu wechseln.

+## DC. Vollständiger Durchgang: Statik, Parität, Funktion (2026.9.5.41)
+
+Auftrag des Eigentümers: „mache ein vollständiges audit und vor allem einen
+paritätstest, ebenso einen funktionstest der Funktionen".
+
+### Statik
+
+29 Backend-Dateien `py_compile`, **alle** Dateien unter `frontend/` als **Modul**
+geparst (Abschnitt AQ), sechs Backend-Testdateien OK, `tsc --noEmit` sauber,
+**303** App-Tests, `vite build` sauber, Design-System gebaut.
+
+### Struktur und Parität
+
+Maschinell geprüft (`paritaet.mjs`, Scratchpad), nicht per Augenschein:
+
+| | Ergebnis |
+|---|---|
+| Routen | Panel 21, App 21 — einzige Abweichung `live` (LiveFahrt, app-eigen, dokumentiert) |
+| Jede App-Unterseite mit Titel | ja |
+| Dienste | 28 in `const.py`, 28 in `services.yaml`, 28 registriert, alle mit Klarnamen |
+| Sensorrollen | 27 Dataclass, 27 Katalog, keine Dublette, jede mit Beispiel |
+| Wortlaut (13 Texte) | in beiden Codebasen gleich vorhanden |
+| Statusfelder (18) | von beiden gelesen bis auf eines |
+
+**Ein Befund:** `standort_genauigkeit_m` wird im Panel nach
+`CAR.standortGenauigkeitM` gelesen und **nirgends verwendet**, in der App gar
+nicht. Also kein Paritätsloch, sondern totes Schema — vorbestehend, deshalb
+gemeldet statt entfernt. Entweder anzeigen (GPS-Genauigkeit auf der
+Standortseite) oder streichen; Entscheidung des Eigentümers.
+
+Zwei weitere Meldungen des Prüfskripts waren **Artefakte meiner eigenen
+Suchmuster**: eine „Route Fehlte" (das Wort stammt aus einem Kommentar) und
+„56 Dienste registriert" (28 Schemata plus 28 Handler). Beide nachgesehen, kein
+Befund.
+
+### Funktionstest am laufenden System
+
+**Panel** (angemeldete Sitzung): alle **21 Routen** aufgerufen — jede rendert,
+**null** Konsolenfehler, keine unbehandelte Ablehnung. „Auf Update prüfen"
+gegen das echte Gitea: vorher keine Marke, danach „aktuell" plus „Zuletzt
+geprüft 05.09.2026 · 17:38 Uhr", **ein** Knopf. Das belegt zugleich die
+Richtungsprüfung aus Abschnitt CX — die Instanz stand auf `.40`, Gitea auf
+`.39`, gemeldet wurde „aktuell" statt eines Rückschritts. „Jetzt lesen" in der
+Dongle-Kachel liefert die Werte.
+
+**App** (Zugang vom Eigentümer eingetragen): sechs Hauptseiten rendern, **null**
+Konsolenfehler. Gemessen statt angesehen:
+
+| Prüfpunkt | Messwert |
+|---|---|
+| Modellfeld | echtes `<select>`, `appearance: none`, **ein** Chevron, 180 px, alle zehn Modelle |
+| Update-Kachel | genau ein Knopf, „aktuell" nach der Prüfung |
+| Abstand unter der Trennlinie | 16 px Polster + 1 px Linie = **17 px** (vorher 29) |
+| Sicherheitsseite | fünf Zeilen, Wortlaut zeichengleich mit dem Panel |
+| Tankbalken | `rgb(245, 5, 55)` auf `rgba(120,120,128,.24)`, 6 px, voll gerundet |
+| Zündung an | „Zündung an" / „Zündung an - Fahrzeug in Betrieb", Punkt `rgb(255, 214, 10)` = `--warn` |
+| Schmales Layout | Reiterleiste mit fünf Punkten, Ringe oben rechts, keine Seitenleiste |
+
+**Datenbestand:** 19 Fahrten, 18 Tankvorgänge, 18 Batterietage. Keine
+0-km-Fahrt, keine negative Strecke, keine Dublette, kein Ende vor dem Beginn,
+alle Spannungen in 8–15,5 V, Fahrten aufsteigend. Einziger Befund sind die drei
+bekannten Altbelege mit `odometer_km` als Zeichenkette (Abschnitt CA, am
+Lesepfad abgefangen).
+
+### Zwei Befunde, die erst der Durchgang gebracht hat
+
+**1. Meine eigene Schriftänderung war wirkungslos.** Ich hatte `.ads-fig` im
+Design-System auf 400 gesetzt und den gebauten Stylesheet geprüft — dort stand
+400. Gerendert wurden trotzdem 300, weil `audi-schrift.css` **nach** dem
+Design-System eine eigene Regel für `.ads-fig, .dm-detail__zahl` mitbringt und
+gewinnt. Im gebauten CSS standen beide Regeln nebeneinander; nur die
+Reihenfolge entschied. Behoben, in der Auflage selbst.
+
+**Merkposten:** eine Regel im Design-System zu ändern beweist nichts, solange
+die App dieselbe Klasse überschreibt. Der Beleg ist der **gerenderte**
+`getComputedStyle`-Wert, nicht der Fund im Stylesheet.
+
+**2. Der Entwicklungsserver backt die App-Version beim Start.** Die vom
+Eigentümer gemeldete Meldung „Diese App ist älter als der Server" kam daher,
+dass der Server seit 13:10 UTC lief, also von vor den Versionssprüngen —
+`__APP_VERSION__` liest `vite.config.ts` beim Laden der Konfiguration, ein
+Neuladen der Seite ändert daran nichts. Nach einem Neustart des Servers war die
+Meldung weg. Kein App-Fehler. Ebenso hält `node_modules/.vite` das CSS des
+Arbeitsbereich-Pakets fest: nach einer Änderung am Design-System muss der
+Zwischenspeicher gelöscht werden, ein Serverneustart allein reicht nicht.
+
+### Was der Eigentümer als Fehler gemeldet hatte und keiner war
+
+* **„Vollbild statt App", „Einstellungen unten links", „DataMetric360 oben
+  links"** — das breite Layout ab 860 px, so gebaut (Seitenleiste statt
+  Reiterleiste, Brotkrume statt Titelzeile).
+* **„Beschriftung der Menüleiste funktioniert nicht"** — im schmalen Layout
+  nachgewiesen: an → aus → wieder an. Im breiten Layout gibt es keine
+  Reiterleiste, der Schalter kann dort nichts bewirken. **Offen als
+  Gestaltungsfrage:** ein Schalter, der im aktuellen Layout wirkungslos ist,
+  gehört dort vermutlich ausgeblendet.
+* **„Fahrt beenden sichtbar"** — das war meins, siehe unten.
+
+### Meine eigenen Testartefakte, angelegt und wieder entfernt
+
+Ein synthetisches Zündungssignal in diesem Container **legt eine echte Fahrt
+an**. Mein erster Test um 15:05 und der zweite um 15:43 haben je eine Nullfahrt
+erzeugt (`t-190c61b28bc0`, `t-fae8fe9cb296`, beide 0,0 km, Beginn 14:43:55 aus
+der veralteten Gerätezeit). Meine Zwischenaussage, die erste habe sich selbst
+verworfen, war falsch — `MINDESTDAUER_S` greift nicht, weil der Beginn aus der
+alten Meldezeit stammt und die Dauer damit groß wird. Beide über
+`fahrt_loeschen` entfernt; Bestand wieder 19 Fahrten, keine von heute.
+
+**Regel für den nächsten Funktionstest:** ein Zündungswechsel ist kein
+folgenloser Anzeigetest. Entweder danach aufräumen oder den Zustand über eine
+andere Quelle stellen.
+
+### Offen
+
+* `standort_genauigkeit_m` — totes Schema im Panel.
+* Beschriftungs-Schalter ohne Wirkung im breiten Layout.
+* **Audi Type Wide Bold** liegt vor (`AudiType-WideBold_4.03.woff2`), ist aber
+  bewusst nicht eingebunden — falls 400 noch zu dünn wirkt, ist es eine Zeile.
+* Die Reservegrenze von **90 km** ist eine Festlegung, keine Messung. Ein
+  Bildschirmfoto der myAudi-App zwischen 95 und 110 km grenzt sie ein.
+* Die beiden Tankvorgänge vom 04.09. (29,8 l / 29,7 l) stehen unverändert.
+
 ## Working conventions (observed — keep them)

 - German is the project language: identifiers, comments, commits, UI texts. Exceptions:
@@ -32,6 +32,25 @@
  font-display: swap;
 }

+/* Audi Type Wide gab es hier bis zum 05.09.2026 nur als Light (300) -
+   deshalb standen die grossen Zahlen im Light-Schnitt, und der Eigentuemer
+   verglich sie mit der myAudi-App: "die Ziffern der Reichweite sind in der
+   Audi App dicker". Er hat daraufhin den vollen Satz aus Audis eigenem
+   Styleguide geliefert (styleguide.audi.com, AudiType 4.03). Wide Normal ist
+   jetzt da; Wide Bold liegt vor, ist aber bewusst nicht eingebunden - 400 ist
+   der naechste Schritt, und 300/400 bleibt die Linie dieses Projekts.
+
+   Lizenz: gilt wie alle Audi-Assets nur fuer diese eine private Installation.
+   Deshalb liegt die Datei in companion-app bzw. im Panel, NIE in
+   design-system. */
+@font-face {
+  font-family: "Audi Type Wide";
+  src: url("../assets/audi/schriften/audi-type-wide-400.woff2") format("woff2");
+  font-weight: 400;
+  font-style: normal;
+  font-display: swap;
+}
+
@font-face {
  font-family: "Audi Type Extended";
  src: url("../assets/audi/schriften/audi-type-extended-400-italic.woff2") format("woff2");
@@ -51,10 +70,21 @@

 /* Große Zahlen (Kilometerstand, Reichweite, Beträge) in der breiten Schnitt-
   variante, wie im Panel. */
+/* Seit dem 05.09.2026 Normal- statt Light-Schnitt: der Eigentümer verglich die
+   Zahlen mit der myAudi-App („die Ziffern der Reichweite sind in der Audi App
+   dicker") und lieferte daraufhin den vollen Satz aus Audis Styleguide. Wide
+   Normal (400) ist seither eingebunden; Wide Bold liegt vor, ist aber bewusst
+   nicht in Gebrauch.
+
+   Diese Regel steht NACH dem Design-System und gewinnt gegen dessen .ads-fig —
+   eine Änderung dort allein bleibt hier wirkungslos. Genau das ist am
+   05.09.2026 passiert und erst an der gerenderten Seite aufgefallen, nicht am
+   gebauten Stylesheet: dort standen beide Regeln, und nur die Reihenfolge
+   entschied. */
 .ads-fig,
 .dm-detail__zahl {
  font-family: var(--font-wide);
-  font-weight: 300;
+  font-weight: 400;
 }

 .ads-sport {
@@ -1 +1 @@
-{"version":"2026.9.5.39","sha256":"1a78c65f9a96298f7ed97a8595e6505cf91f00a71620b068b4afcfdd14020483","bytes":324341,"gebaut":"2026-09-05T15:29:32Z"}
+{"version":"2026.9.5.41","sha256":"b216efc3c99df3a9def63c5a5504dc1d2351b5ea604306cbfcdfa133421e2882","bytes":364409,"gebaut":"2026-09-05T15:47:17Z"}
@@ -418,7 +418,7 @@ button.tile, .tilebtn { transition: background .15s, transform .1s; }
 }
 .fig {
  font-family: "Audi Type Wide", var(--font-stack);
-  font-weight: 300;
+  font-weight: 400;
  letter-spacing: -.02em;
  line-height: .95;
  color: var(--fg);
@@ -1,7 +1,7 @@
 {
  "domain": "audi_dashboard",
  "name": "Audi Dashboard",
-  "version": "2026.9.5.39",
+  "version": "2026.9.5.41",
  "documentation": "https://gitea.nothaft.cloud/paul/audi-app/src/branch/main/README.md",
  "issue_tracker": "https://gitea.nothaft.cloud/paul/audi-app/issues",
  "codeowners": [
@@ -1,5 +1,5 @@
 .ads-fig {
-  font-weight: 300;
+  font-weight: 400 /* Wide Normal, siehe audi-schrift.css */;
  /* -.03em, nicht -.02em: die iOS-Auflage im Panel überschreibt .fig dort
     eigens (audi-dashboard-ios.css, live gemessen -1.8px bei 60px = -.03em)
     - das Basisblatt allein (audi-dashboard.css, -.02em) reicht am echten