Musterseite verworfen, Zahnrad-Regression behoben, Fotomenue als Aktionsblatt

Musterseite entfernt (companion-app/muster, vite.muster.config.ts,
/config/www/dmmuster). Ansage des Eigentuemers: sie fuehrt nur zu neuen
Fehlerquellen. Ausloeser war ein Befund, den ich als App-Fehler gemeldet hatte
- Ringe und Typenschild schwarz auf schwarz - und der nur dort bestand.

Behoben:

* Das Zahnrad im Autohaus-Kasten hatte seine Ecke verlassen (58/288 statt
  8/8). Ursache war mein HIG-Durchgang von gestern: .zahnrad kam in die
  Gruppe fuer die 44x44-Trefferflaeche und bekam damit position:relative,
  was das absolute aus dem Basisblatt ueberschrieb. Die Auflage war
  ueberfluessig - .zahnrad ist dort schon 44x44.
* Das Fotomenue hing mit position:absolute an der Kachel statt am
  Bildschirm und lag bei der hohen Raeder-Kachel ausserhalb des Sichtfelds;
  einen Abbrechen-Knopf hatte es nie. Das Panel benutzt jetzt dasselbe
  Aktionsblatt wie die App. .bildmenu ist samt Zustand, Markup, totem
  Handler und CSS entfernt.
* Der Blattkopf las sich als dritte Auswahl (linksbuendig, 15px, --fg).
  Jetzt zentriert, 13px, gedaempft - Apples Muster, in beiden Codebasen.
* "Anstehende Termine" stand 5px ueber "Oelwechsel" und wirkte als dessen
  Beischrift. Entfernt.
* Wartungsplan-Formular: Art nach oben, Datum 124px statt Browser-Vorgabe,
  Werkstatt ueber die volle Zeile (218 -> 306px), Kosten 116px. Zwei
  Erklaertexte entfernt.
* Thema folgt jetzt einer Systemumstellung im laufenden Betrieb. Vorher las
  es prefers-color-scheme genau einmal beim Laden. Drei Tests, die ohne die
  Behebung nachweislich fallen.

Geprueft: 295 App-Tests, Panel node --check, 0 Tracebacks, alle Aenderungen
live an der Testinstanz gemessen.

Co-Authored-By: Claude Opus 5 <[email protected]>

AGENTS.md

@@ -9952,6 +9952,17 @@ strukturell, nicht optisch belegt.
 
 ## CG. Eine Musterseite loest den wiederkehrenden Pruefblocker (2026.9.4.12)
 
+> **Zurueckgenommen am 05.09.2026.** Die Musterseite ist entfernt -
+> `companion-app/muster/`, `vite.muster.config.ts`, `dist-muster/` und
+> `/config/www/dmmuster` im Testcontainer. Ansage des Eigentuemers: *"der
+> fehler ist nur in deiner musterseite. Verwerfe diese - die fuehrt nur zu
+> neuen Fehlerquellen"*. Ausloeser war ein Befund, den ich als App-Fehler
+> gemeldet habe (Vier Ringe und Typenschild schwarz auf schwarz im
+> Nachtmodus) und der nur auf der Musterseite bestand - genau die Klasse
+> Fehlalarm, die eine zweite Bauweise derselben Oberflaeche erzeugt. Fuer
+> Live-Pruefungen gilt jetzt allein der Weg ueber den Zugangstoken
+> (Abschnitt CP). Der folgende Text bleibt als Aufzeichnung stehen.
+
 **Das Problem, das seit Wochen wiederkehrt:** die App zeigt ohne gespeicherten
 Zugang gar nichts, jede OPTISCHE Pruefung haengt damit an einem Zugangstoken -
 und fast jeder Fehler, den dieses Projekt findet, ist nur am gerenderten Bild
@@ -11451,3 +11462,139 @@ sie war es nicht:
 Beides hat dazu gefuehrt, dass ich zwischenzeitlich alte Dateien gelesen und
 fuer neue gehalten habe. Gegenprobe, die das aufdeckt: `find <ziel> -name
 manifest.json | wc -l` muss `1` ergeben.
+
+## CS. Fuenf Meldungen aus einer Sitzung - und ein Fehlalarm, den ich selbst gebaut hatte (2026.9.5.10)
+
+### Der Fehlalarm zuerst: die Musterseite ist weg
+
+Gemeldet als App-Fehler: "RS4 Logo ist im Nachtmodus schwarz und nicht mehr
+lesbar, Audi Ringe rechts oben sind schwarz auf schwarz". Ich habe daraufhin
+eine Ursache benannt, die keine war - `fill: rgb(0,0,0)` aus meiner Messung ist
+die geerbte CSS-Eigenschaft des `<img>`-Elements und sagt ueber das gezeichnete
+SVG nichts. Die Gegenprobe im Dunkelmodus zeigte weisse Ringe.
+
+Der Befund stimmte, aber nur auf der **Musterseite**. Ansage des Eigentuemers:
+*"der fehler ist nur in deiner musterseite. Verwerfe diese - die fuehrt nur zu
+neuen Fehlerquellen"*. Sie ist entfernt (Abschnitt CG traegt jetzt den
+Ruecknahme-Vermerk). Eine zweite Bauweise derselben Oberflaeche erzeugt
+Fehlalarme - genau das ist hier passiert.
+
+**Ein echter Mangel blieb aus der Suche uebrig**: `theme.ts` und das Panel
+lasen `prefers-color-scheme` genau einmal beim Laden und horchten danach nie
+wieder. Stellt das Geraet im Betrieb um - automatische Umschaltung bei
+Sonnenuntergang -, blieb die Oberflaeche bis zum naechsten Neuladen stehen.
+Beide horchen jetzt; eine selbst getroffene Wahl bleibt unangetastet. Drei
+Tests, die ohne die Behebung nachweislich fallen (gegengeprueft).
+
+### Das Zahnrad im Autohaus-Kasten - meiner
+
+Gemeldet: *"Das Zahnrad vom Autohaus hat seine Position (rechts oben in der
+Kachel) verlassen. Warum"*. Gemessen: 58px von oben, 288px von rechts statt
+8/8.
+
+Ursache war mein eigener HIG-Durchgang vom 04.09.2026 (Commit b0ec8b4). Ich
+hatte `.zahnrad` in die Gruppe fuer die 44x44-Trefferflaeche aufgenommen:
+
+    #back, .ringsbtn, .icon-btn, .zahnrad { position: relative; }
+
+`audi-dashboard-ios.css` laedt nach `audi-dashboard.css`, gleiche Spezifitaet -
+das `position: absolute`, das das Zahnrad in die Kachelecke heftet, war damit
+ueberschrieben. Die Auflage war ausserdem ueberfluessig: `.zahnrad` ist im
+Basisblatt schon 44x44. Ich hatte die Gruppe zusammengestellt, ohne zu pruefen,
+welche Knoepfe ihre Flaeche laengst haben. `.zahnrad` ist wieder heraus, die
+drei anderen sind nicht absolut positioniert und bleiben.
+
+### Das Fotomenue: an der Kachel statt am Bildschirm, ohne Ausweg
+
+Gemeldet: *"Der Popup zum ersetzen erscheint ausserhalb vom Sichtfeld... es
+fehlt ein abbrechen button wenn man zufaellig auf das rad klickt."*
+
+`.bildmenu` war `position: absolute` und hing damit an der **Kachel**, nicht am
+Bildschirm. Bei der hohen Raeder-Kachel lag es unterhalb des Sichtfelds. Einen
+Abbrechen-Knopf hatte es nie.
+
+Die App hatte den Fall schon geloest - `<ActionSheet>` mit abgesetztem
+Abbrechen. Das Panel zieht jetzt nach: `aktionsblatt(titel, aktionen)` neben
+`bestaetigen()`/`hinweis()`, gerendert am Wurzelelement. `.bildmenu` samt
+`bildMenuOffen`, den beiden Markup-Bloecken, dem toten
+`data-bildloeschen`-Handler und allen CSS-Regeln in beiden Blaettern ist
+entfernt. `.bildmenu-catcher` bleibt - den benutzt das SmartDeal-Blatt.
+
+Gemessen am laufenden Panel: Blatt bei 553-760px in einem 794px-Fenster, drei
+Knoepfe "Foto ersetzen / Foto loeschen / Abbrechen".
+
+### Der Blattkopf las sich als dritte Auswahl
+
+Gemeldet: *"Die Ueberschrift des Menues Sommerrad ersetzen/loeschen lautet
+'Sommerrad'... Auf mich wirkt es wie eine dritte Auswahl"*. Zu Recht: er stand
+linksbuendig, 15px, in `--fg` - fast genau wie die Knopfzeilen darunter. Apples
+Aktionsblatt setzt den Titel **zentriert, kleiner (13px) und gedaempft**
+(`--fg2`). Beide Codebasen nachgezogen.
+
+### "Anstehende Termine" gehoerte scheinbar zum Oelwechsel
+
+Gemeldet: *"Aktuell wirkt es als wuerde es zu Oelwechsel gehoeren"*. Gemessen:
+13px, Gewicht 400, `--fg3`, keine Grossschrift - und nur **5px** ueber
+"Oelwechsel" (16px, `--fg`). Der Kopf ist entfernt: die drei Zeilen benennen
+sich selbst, die Seite heisst bereits "Service".
+
+**Offen und nicht angefasst:** dieselbe schwache Behandlung hat die
+Kachelueberschrift ueberall im Panel (`.label`, iOS-Auflage: 13px, `--fg3`,
+keine Grossschrift). Die App setzt an derselben Stelle 10px in Grossschrift mit
+0.2em Sperrung - eine erkennbare Augenbraue. Das ist eine Abweichung ueber
+Dutzende Kacheln und gehoert nicht in einen Nebensatz.
+
+### Wartungsplan-Formular
+
+Vorgabe: Art nach oben, Feldbreiten nach Inhalt, zwei Erklaertexte weg.
+Gemessen vorher/nachher:
+
+| Feld | vorher | jetzt |
+|---|---|---|
+| Art | 3. Zeile | 1. Zeile |
+| Datum | ~170-190px (Browser-Vorgabe) | 124px Panel / 150px App |
+| Werkstatt | 218px | 306px, eigene Zeile |
+| Kosten | 96px | 116px |
+
+Die Browser-Vorgabe ist inhaltsblind: **jedes** Textfeld ohne `size` bekommt
+dieselbe Breite. Deshalb schwamm das Datum und wurde der Werkstattname
+abgeschnitten.
+
+Der Werkstattname passt in keine Spalte neben einem Label: ein echter Name
+("Audi AG Kundendienst Center Ingolstadt") braucht 322px, auf 375px Geraetebreite
+bleiben neben dem Label 218. Er steht deshalb in einer `.feld--breit`-Zeile.
+**Auch das reicht fuer diesen Extremfall nicht ganz** - 306 gegen 322px, das
+Feld scrollt dann. Weiter kaeme man nur mit kleinerer Schrift, und unter 16px
+zoomt iOS beim Antippen die ganze Seite.
+
+Die App hat ein natives `type="date"` mit Kalendersymbol, das Panel ein
+Textfeld - daher 150 gegen 124px. Das ist ein Bauunterschied, kein Versehen.
+
+### Raederzaehler: er rechnet, ihm fehlt nur Futter
+
+Frage: *"Funktioniert der Raederzaehler ueberhaupt? Ich sehe hier wenig
+Bewegung bei den Fahrten."* Gemessen an der Testinstanz:
+
+| | Anzahl |
+|---|---|
+| Fahrten gesamt | 19 |
+| mit `reifensatz` | 4 |
+| davon mit gemessener Strecke | 2 |
+| noch nicht gutgeschrieben | 0 |
+
+Die vier gestempelten Fahrten summieren 9,9 km, und **genau 9,9 km** stehen auf
+den Sommerraedern. Der Zaehler arbeitet also fehlerfrei. Wenig Bewegung hat
+drei Gruende, alle beabsichtigt oder bekannt:
+
+* Importierte Fahrten (6) werden **bewusst nicht** gestempelt - ihre Kilometer
+  stecken schon im gespeicherten Radstand, ein erneuter Import wuerde sie sonst
+  ein zweites Mal aufschlagen (Kommentar in `historienimport.py`).
+* Sieben `ha`-Fahrten stammen aus der Zeit vor dem Stempel und tragen ihn nicht
+  nach.
+* Zwei der vier gestempelten Fahrten haben noch keine gemessene Strecke; sie
+  werden gutgeschrieben, sobald das Screening sie fuellt.
+
+Der eigentliche Grund auf der **realen** Instanz ist ein anderer und heute
+zuerst gefunden worden: dort wurden ueberhaupt keine Fahrten erkannt, weil die
+Erkennung still das Trip-Signal des Dongles bevorzugte, das nie ankam. Ohne
+Fahrten kein Radstand.