dogfather-universe

1,135 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGit	de8819f1fd	CRYONOVA: Farb- und Lichtsystem nach dem Design-System umgesetzt Umsetzung des Design-Systems "Baby Blue Optical Luxury" (Edition 2.0), Schritt 1 von mehreren: die zentrale Farbquelle. Nach der Kernregel auf Seite 3 ist das ausdrücklich ein Farb- und Licht-Redesign — Aufbau, Navigation, Texte und Funktionen bleiben unangetastet. FARBEN Grundflächen auf die vier Tiefenebenen des Systems (Void, Midnight, Obsidian, Deep Glass). Palette nach Seite 5: Signature Baby, Ion Blue, Hyper Aqua, Aurora Violet, Prism Indigo, Liquid Gold, Signal Coral, Chrome Silver. Die Variablen behalten ihre alten NAMEN (--wd-blau statt --cryo-baby). Ein Umbenennen hätte über 155 Fundstellen anfassen müssen — viel Bewegung ohne sichtbaren Nutzen, mit der realen Gefahr, eine Stelle zu übersehen und danach zwei fast gleiche Blautöne zu haben. Entscheidend ist die Rolle, nicht der Name; die Systembezeichnungen stehen als Kommentar daneben. EIN FEHLER IM DESIGN-SYSTEM, DER BEWUSST NICHT ÜBERNOMMEN WURDE Die Token-Liste auf Seite 20 ist um eine Zeile verrutscht — Namen und Hex-Werte passen dort nicht zusammen. Am folgenreichsten: --cryo-baby stünde auf #0C2740, einem fast schwarzen Navy, und ist laut Seite 21 zugleich die Standard-Lumenfarbe. Das Mauslicht wäre damit praktisch unsichtbar geworden — ausgerechnet der Effekt, den das System auf fünf Seiten als unantastbar schützt. Maßgeblich ist deshalb die Palette auf Seite 5 und die Lumen-Logik auf Seite 9, die untereinander stimmig sind. MAUSLICHT Der bestehende Effekt bleibt vollständig erhalten (Systemauflage) und bekommt eine Farbvariable pro Kachel: --wd-lumen. Vorher war die Farbe im Verlauf fest verdrahtet, und jede weitere Kachelfarbe hätte zwei neue Blöcke gebraucht (Fläche + leuchtende Kante). Bei sechs Lumen-Rollen wären das zwölf fast gleiche Blöcke gewesen, die beim nächsten Feinschliff zwangsläufig auseinanderlaufen. Jetzt setzt die Kachel nur ihre Farbe, der Verlauf steht einmal da — genau das meint Token-Regel 02 mit "Kachelfarbe steuert Lumenfarbe". 38 lose Hex-Codes durch Token ersetzt (Token-Regel 05). Drei davon (#3d9dbd, #7c5cd6, #a8873a) waren noch die ALTEN Markenfarben und hätten still neben den neuen weitergelebt — genau der Mechanismus, durch den Oberflächen mit der Zeit zwei fast gleiche Töne bekommen. KONTRASTE NACHGERECHNET Die Palette ist auf dunklem Grund durchweg stark (9,7 bis 19,8:1) — mit einer Ausnahme: Prism Indigo erreicht auf keiner Fläche 4,5:1 (nur 3,25 bis 4,29). Es ist deshalb ausschließlich für Kanten, Verläufe und große Premium-Flächen zugelassen, nie für Fließtext. Das System sieht Indigo ohnehin nur für "Premium-Momente" vor — die Rechnung bestätigt die Regel, statt ihr zu widersprechen. NEUER TEST: pruef-cryonova.mjs (24 Prüfungen) Palette, Grundflächen, Mauslicht-Erhalt, echte Zeigerbewegung, keine losen Hex-Codes, Kontraste und die Frage, ob alle 12 Seiten wirklich aus derselben Quelle schöpfen. Dabei drei Fehlalarme im eigenen Test gefunden und behoben — jeder davon hätte dauerhaft rote Zeilen erzeugt und irgendwann dazu geführt, dass man eine echte Meldung übersieht: - Halbtransparente Flächen müssen über ihren Untergrund gerechnet werden. Der aktive Reiter kam sonst auf 1:1 statt echter 8,25–10,23:1. - Text auf Farbverläufen liefert rgba(0,0,0,0) als Hintergrund; der Hauptknopf kam so auf 1:1 statt rund 11:1. - Die Maus muss mit Zwischenschritten bewegt werden, sonst feuert pointermove nicht. Eine Direktmessung bestätigte: Das Licht folgt einwandfrei (30px → 723px, Deckkraft 1). pruef-system.mjs auf den neuen Markenton gesetzt. Dass er dort zunächst "0 von 1804 Elementen" meldete, war kein Fehler, sondern der Beweis, dass der alte Ton nirgends mehr vorkommt. Geprüft: 24 (CRYONOVA) + 0 Fundstellen (Design/WCAG über 12 Seiten × 5 Sprachen) + 40 + 56 + 69 + 54 + 42 + 55 + 5 + 16 — alles grün.	2026-08-24 22:32:04 +02:00
DogFatherGitandClaude Opus 5	10a075cc33	Gestaltung: Hoehensystem -- mehrschichtige Schatten und Lichtkante Bis hierher trug jede Karte EINEN Schatten. Das ist solide und genau der Grund, warum eine Oberflaeche "ordentlich" statt "teuer" wirkt. Echtes Licht erzeugt zwei Dinge gleichzeitig: einen engen, dunklen Kontaktschatten an der Kante -- er sagt dem Auge, dass etwas AUFLIEGT -- und einen weiten, weichen Umgebungsschatten, der sagt, wie HOCH es darueber schwebt. Nur einen von beiden zu setzen sieht aus wie ein Aufkleber; beide zusammen ergeben einen Gegenstand. Dazu die LICHTKANTE: eine 1 Pixel hohe, sehr schwache weisse Linie an der Oberkante. Sie tut so, als kaeme das Licht von oben und braeche sich an der Kante. Das ist das meistuebersehene Detail in dunklen Oberflaechen und dasjenige mit der groessten Wirkung -- ohne sie wirkt eine Karte wie ein Loch im Hintergrund, mit ihr wie ein Stueck Material. Drei Stufen, mehr braucht es nicht: ruhende Flaechen, hervorgehobene Flaechen, Schwebendes. Dazu eine vierte, umgekehrte fuer Eingabefelder: Die liegen nicht AUF der Flaeche, sie sind hineingeschnitten -- oben dunkel, unten hell. Weil es die gemeinsamen Bausteine sind, wirkt es sofort auf allen 13 Seiten: Hauptseite, Portal und Verwaltung. Dazu Feinheiten, die einzeln niemand bemerkt und in Summe den Unterschied machen: Uebergaenge auf 160-180 ms verkuerzt (alles darueber wirkt beim Ueberfahren traege), eigene Rueckmeldung beim Druecken, optische Laufweitenkorrektur fuer grosse Ueberschriften (-.028em bei h1; das Auge sieht bei 48px mehr Weissraum zwischen Buchstaben als bei 16px), text-wrap: balance gegen einzelne Woerter in der letzten Zeile. EIN FEHLER BEIM EINBAU, GEMESSEN STATT UEBERSEHEN Nach dem ersten Durchgang hatten die Karten ihre Lichtkante, der Hauptknopf nicht. Grund: Die Grundregel lautet ".wd .wd-btn--haupt, .wd-btn--haupt" -- der erste Teil zaehlt ZWEI Klassen. Mein Nachtrag zaehlte eine und verlor, obwohl er spaeter steht. Dieselbe Falle wie am 22.08.2026 bei ".wd a" gegen ".wd-btn--haupt". Aufgefallen nur, weil die Pruefung die Lichtkanten ZAEHLT. PRUEFWERKZEUGE ANGEPASST diagnose.html ist jetzt ausgenommen. Sie traegt bewusst alles fest in sich -- eigene Farben, keine Uebersetzung -- weil sie funktionieren muss, wenn genau das kaputt ist, was sie untersucht. Sie an den Regeln der eigentlichen Seite zu messen erzeugte zwei Meldungen, die man auf Dauer wegsieht. Und irgendwann sieht man dann auch eine echte weg. ALLES GRUEN: Gestaltung 0 Befunde (12 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Designsystem 5, Verwaltung 69, Portal 32. Versionsstempel und Cache auf v17. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 18:37:17 +02:00
DogFatherGitandClaude Opus 5	be3599239d	Designsystem: eine Quelle je Farbe, Radien auf eine Skala Diese Runde ging eine Ebene tiefer als "sieht es gut aus": Ist das System, aus dem das Aussehen entsteht, ueberhaupt eines? DIE MESSUNG VORWEG Markenfarben ausgeschrieben im Quelltext: 155 Stellen davon Blau 74, Gold 33, Lila 22, Gruen 16, Rot 10 verschiedene Eckenradien: 12 darunter 5px, 7px, 9px, 11px Die Farben gab es laengst als Variablen. Sie standen trotzdem ueberall ausgeschrieben da, weil halbdurchsichtige Toene -- Raender, Leuchten, sanfte Flaechen -- einen Alphawert brauchen, und das mit einer fertigen Farbvariablen nicht geht: rgba(127, 208, 232, .16). Die Folge waere beim ersten Farbwechsel sichtbar geworden: Man findet 150 Stellen, uebersieht fuenf, und die Seite hat danach zwei Blautoene, die sich um eine Nuance unterscheiden. Genau das ist der Unterschied zwischen einer gewachsenen und einer gestalteten Oberflaeche. WAS GEAENDERT WURDE Kanalvariablen (--wd-blau-rgb: 127 208 232) neben den fertigen Farben. Damit schreibt man rgb(var(--wd-blau-rgb) / .16), und eine Aenderung wirkt ueberall. 164 Stellen umgestellt, verteilt ueber CSS und neun Seiten. Auch die abgeleiteten Farben zeigen jetzt auf die Kanaele statt eigene Werte zu fuehren -- und die vier Prozessfarben (--wd-p1 bis p4) sind keine eigenen Farben mehr, sondern Rollen: --wd-p1: var(--wd-blau). Sonst haette man vier weitere Stellen, die beim naechsten Farbwechsel stillschweigend zurueckbleiben. Ergebnis: Jede Markenfarbe hat genau EINE Quelle. Ausgeschriebene Markenfarben im Quelltext: 0. Radien auf vier Stufen plus Pillenform: 6 / 10 / 14 / 20 / 999. Kein Wert wurde um mehr als 2px verschoben, optisch aendert sich also nichts Spuerbares -- 12 verschiedene Werte sind auf 3 tatsaechlich verwendete zusammengeschmolzen. Zwischenwerte wie 7px oder 11px entstehen nicht aus Absicht, sondern weil man beim Bauen einer neuen Kachel nicht nachschaut, was nebenan schon gilt. DER BEWEIS, DASS ES EIN SYSTEM IST Neue Pruefung pruef-system.mjs. Sie behauptet nicht, sie STELLT UM: Die Markenfarbe wird von Babyblau auf kraeftiges Orange gesetzt und dann nachgezaehlt, ob irgendwo der alte Ton stehen bleibt. 658 von 1975 sichtbaren Elementen tragen die Markenfarbe 0 bleiben nach der Umstellung beim alten Ton Prozessfarben folgen nachweislich mit Radien: 3 Stufen UND DIE WICHTIGSTE ERKENNTNIS -- ueber das Messen selbst Der erste Anlauf meldete 110 haengengebliebene Elemente, alle in Kopf- und Fusszeile. Die naheliegende Erklaerung waere gewesen: "da steht die Farbe noch ausgeschrieben". Sie war falsch. Nachgewiesen ueber die DevTools-Schnittstelle: Auf diese Elemente wirkt die Regel ".wd a:not(.wd-btn) -> var(--wd-blau)", und --wd-blau resolviert an genau dieser Stelle korrekt zum neuen Orange. Trotzdem blieb die berechnete Textfarbe alt -- auch nach erzwungener Neuberechnung. Der Unterschied: Kopf- und Fusszeile werden von wd-core.js per innerHTML eingefuegt. Chromium erneuert solche Teilbaeume nicht zuverlaessig, wenn man eine Variable NACHTRAEGLICH umstellt. Laedt man dieselbe Seite mit bereits geaenderter Variable, sind sie orange -- gegengeprueft mit einem Minimalbeispiel, in dem derselbe Mechanismus einwandfrei funktioniert. Das Pruefverfahren wurde deshalb umgestellt: Die Variable wird VOR dem Laden ueberschrieben. Das entspricht genau dem, was eine Aenderung in der CSS-Datei bewirkt -- also dem Fall, um den es wirklich geht. Haette ich der ersten Messung geglaubt, haette ich 110 einwandfreie Stellen "repariert" und dabei das gerade aufgebaute System wieder zerlegt. Es ist der siebte Fehlalarm in eigener Messtechnik innerhalb von zwei Runden -- und der subtilste. ALLE PRUEFUNGEN GRUEN: Gestaltung 0 Befunde (13 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Anfragedetail 20, Verwaltung 69, Portal 32, Widerruf 58, Textkodierung 55 Kombinationen, Designsystem 5. Versionsstempel und Cache-Name auf v9. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 13:05:12 +02:00

Author

SHA1

Message

Date

DogFatherGit

de8819f1fd

CRYONOVA: Farb- und Lichtsystem nach dem Design-System umgesetzt

Umsetzung des Design-Systems "Baby Blue Optical Luxury" (Edition 2.0),
Schritt 1 von mehreren: die zentrale Farbquelle. Nach der Kernregel auf
Seite 3 ist das ausdrücklich ein Farb- und Licht-Redesign — Aufbau,
Navigation, Texte und Funktionen bleiben unangetastet.

FARBEN
Grundflächen auf die vier Tiefenebenen des Systems (Void, Midnight,
Obsidian, Deep Glass). Palette nach Seite 5: Signature Baby, Ion Blue,
Hyper Aqua, Aurora Violet, Prism Indigo, Liquid Gold, Signal Coral,
Chrome Silver.

Die Variablen behalten ihre alten NAMEN (--wd-blau statt --cryo-baby).
Ein Umbenennen hätte über 155 Fundstellen anfassen müssen — viel
Bewegung ohne sichtbaren Nutzen, mit der realen Gefahr, eine Stelle zu
übersehen und danach zwei fast gleiche Blautöne zu haben. Entscheidend
ist die Rolle, nicht der Name; die Systembezeichnungen stehen als
Kommentar daneben.

EIN FEHLER IM DESIGN-SYSTEM, DER BEWUSST NICHT ÜBERNOMMEN WURDE
Die Token-Liste auf Seite 20 ist um eine Zeile verrutscht — Namen und
Hex-Werte passen dort nicht zusammen. Am folgenreichsten: --cryo-baby
stünde auf #0C2740, einem fast schwarzen Navy, und ist laut Seite 21
zugleich die Standard-Lumenfarbe. Das Mauslicht wäre damit praktisch
unsichtbar geworden — ausgerechnet der Effekt, den das System auf fünf
Seiten als unantastbar schützt. Maßgeblich ist deshalb die Palette auf
Seite 5 und die Lumen-Logik auf Seite 9, die untereinander stimmig sind.

MAUSLICHT
Der bestehende Effekt bleibt vollständig erhalten (Systemauflage) und
bekommt eine Farbvariable pro Kachel: --wd-lumen. Vorher war die Farbe
im Verlauf fest verdrahtet, und jede weitere Kachelfarbe hätte zwei
neue Blöcke gebraucht (Fläche + leuchtende Kante). Bei sechs
Lumen-Rollen wären das zwölf fast gleiche Blöcke gewesen, die beim
nächsten Feinschliff zwangsläufig auseinanderlaufen. Jetzt setzt die
Kachel nur ihre Farbe, der Verlauf steht einmal da — genau das meint
Token-Regel 02 mit "Kachelfarbe steuert Lumenfarbe".

38 lose Hex-Codes durch Token ersetzt (Token-Regel 05). Drei davon
(#3d9dbd, #7c5cd6, #a8873a) waren noch die ALTEN Markenfarben und
hätten still neben den neuen weitergelebt — genau der Mechanismus, durch
den Oberflächen mit der Zeit zwei fast gleiche Töne bekommen.

KONTRASTE NACHGERECHNET
Die Palette ist auf dunklem Grund durchweg stark (9,7 bis 19,8:1) — mit
einer Ausnahme: Prism Indigo erreicht auf keiner Fläche 4,5:1 (nur 3,25
bis 4,29). Es ist deshalb ausschließlich für Kanten, Verläufe und große
Premium-Flächen zugelassen, nie für Fließtext. Das System sieht Indigo
ohnehin nur für "Premium-Momente" vor — die Rechnung bestätigt die
Regel, statt ihr zu widersprechen.

NEUER TEST: pruef-cryonova.mjs (24 Prüfungen)
Palette, Grundflächen, Mauslicht-Erhalt, echte Zeigerbewegung, keine
losen Hex-Codes, Kontraste und die Frage, ob alle 12 Seiten wirklich
aus derselben Quelle schöpfen.

Dabei drei Fehlalarme im eigenen Test gefunden und behoben — jeder
davon hätte dauerhaft rote Zeilen erzeugt und irgendwann dazu geführt,
dass man eine echte Meldung übersieht:
- Halbtransparente Flächen müssen über ihren Untergrund gerechnet
  werden. Der aktive Reiter kam sonst auf 1:1 statt echter 8,25–10,23:1.
- Text auf Farbverläufen liefert rgba(0,0,0,0) als Hintergrund; der
  Hauptknopf kam so auf 1:1 statt rund 11:1.
- Die Maus muss mit Zwischenschritten bewegt werden, sonst feuert
  pointermove nicht. Eine Direktmessung bestätigte: Das Licht folgt
  einwandfrei (30px → 723px, Deckkraft 1).

pruef-system.mjs auf den neuen Markenton gesetzt. Dass er dort zunächst
"0 von 1804 Elementen" meldete, war kein Fehler, sondern der Beweis,
dass der alte Ton nirgends mehr vorkommt.

Geprüft: 24 (CRYONOVA) + 0 Fundstellen (Design/WCAG über 12 Seiten × 5
Sprachen) + 40 + 56 + 69 + 54 + 42 + 55 + 5 + 16 — alles grün.

2026-08-24 22:32:04 +02:00

DogFatherGitandClaude Opus 5

10a075cc33

Gestaltung: Hoehensystem -- mehrschichtige Schatten und Lichtkante

Bis hierher trug jede Karte EINEN Schatten. Das ist solide und genau der
Grund, warum eine Oberflaeche "ordentlich" statt "teuer" wirkt.

Echtes Licht erzeugt zwei Dinge gleichzeitig: einen engen, dunklen
Kontaktschatten an der Kante -- er sagt dem Auge, dass etwas AUFLIEGT --
und einen weiten, weichen Umgebungsschatten, der sagt, wie HOCH es
darueber schwebt. Nur einen von beiden zu setzen sieht aus wie ein
Aufkleber; beide zusammen ergeben einen Gegenstand.

Dazu die LICHTKANTE: eine 1 Pixel hohe, sehr schwache weisse Linie an der
Oberkante. Sie tut so, als kaeme das Licht von oben und braeche sich an
der Kante. Das ist das meistuebersehene Detail in dunklen Oberflaechen
und dasjenige mit der groessten Wirkung -- ohne sie wirkt eine Karte wie
ein Loch im Hintergrund, mit ihr wie ein Stueck Material.

Drei Stufen, mehr braucht es nicht: ruhende Flaechen, hervorgehobene
Flaechen, Schwebendes. Dazu eine vierte, umgekehrte fuer Eingabefelder:
Die liegen nicht AUF der Flaeche, sie sind hineingeschnitten -- oben
dunkel, unten hell.

Weil es die gemeinsamen Bausteine sind, wirkt es sofort auf allen 13
Seiten: Hauptseite, Portal und Verwaltung.

Dazu Feinheiten, die einzeln niemand bemerkt und in Summe den
Unterschied machen: Uebergaenge auf 160-180 ms verkuerzt (alles darueber
wirkt beim Ueberfahren traege), eigene Rueckmeldung beim Druecken,
optische Laufweitenkorrektur fuer grosse Ueberschriften (-.028em bei h1;
das Auge sieht bei 48px mehr Weissraum zwischen Buchstaben als bei 16px),
text-wrap: balance gegen einzelne Woerter in der letzten Zeile.

EIN FEHLER BEIM EINBAU, GEMESSEN STATT UEBERSEHEN

Nach dem ersten Durchgang hatten die Karten ihre Lichtkante, der
Hauptknopf nicht. Grund: Die Grundregel lautet
".wd .wd-btn--haupt, .wd-btn--haupt" -- der erste Teil zaehlt ZWEI
Klassen. Mein Nachtrag zaehlte eine und verlor, obwohl er spaeter steht.
Dieselbe Falle wie am 22.08.2026 bei ".wd a" gegen ".wd-btn--haupt".
Aufgefallen nur, weil die Pruefung die Lichtkanten ZAEHLT.

PRUEFWERKZEUGE ANGEPASST

diagnose.html ist jetzt ausgenommen. Sie traegt bewusst alles fest in
sich -- eigene Farben, keine Uebersetzung -- weil sie funktionieren muss,
wenn genau das kaputt ist, was sie untersucht. Sie an den Regeln der
eigentlichen Seite zu messen erzeugte zwei Meldungen, die man auf Dauer
wegsieht. Und irgendwann sieht man dann auch eine echte weg.

ALLES GRUEN: Gestaltung 0 Befunde (12 Seiten x 5 Sprachen gegen
WCAG 2.2 AA), Designsystem 5, Verwaltung 69, Portal 32.

Versionsstempel und Cache auf v17.

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

2026-08-23 18:37:17 +02:00

DogFatherGitandClaude Opus 5

be3599239d

Designsystem: eine Quelle je Farbe, Radien auf eine Skala

Diese Runde ging eine Ebene tiefer als "sieht es gut aus": Ist das
System, aus dem das Aussehen entsteht, ueberhaupt eines?

DIE MESSUNG VORWEG

  Markenfarben ausgeschrieben im Quelltext:  155 Stellen
    davon Blau 74, Gold 33, Lila 22, Gruen 16, Rot 10
  verschiedene Eckenradien:                   12
    darunter 5px, 7px, 9px, 11px

Die Farben gab es laengst als Variablen. Sie standen trotzdem ueberall
ausgeschrieben da, weil halbdurchsichtige Toene -- Raender, Leuchten,
sanfte Flaechen -- einen Alphawert brauchen, und das mit einer fertigen
Farbvariablen nicht geht: rgba(127, 208, 232, .16).

Die Folge waere beim ersten Farbwechsel sichtbar geworden: Man findet
150 Stellen, uebersieht fuenf, und die Seite hat danach zwei Blautoene,
die sich um eine Nuance unterscheiden. Genau das ist der Unterschied
zwischen einer gewachsenen und einer gestalteten Oberflaeche.

WAS GEAENDERT WURDE

Kanalvariablen (--wd-blau-rgb: 127 208 232) neben den fertigen Farben.
Damit schreibt man rgb(var(--wd-blau-rgb) / .16), und eine Aenderung
wirkt ueberall. 164 Stellen umgestellt, verteilt ueber CSS und neun
Seiten.

Auch die abgeleiteten Farben zeigen jetzt auf die Kanaele statt eigene
Werte zu fuehren -- und die vier Prozessfarben (--wd-p1 bis p4) sind
keine eigenen Farben mehr, sondern Rollen: --wd-p1: var(--wd-blau).
Sonst haette man vier weitere Stellen, die beim naechsten Farbwechsel
stillschweigend zurueckbleiben.

Ergebnis: Jede Markenfarbe hat genau EINE Quelle. Ausgeschriebene
Markenfarben im Quelltext: 0.

Radien auf vier Stufen plus Pillenform: 6 / 10 / 14 / 20 / 999. Kein
Wert wurde um mehr als 2px verschoben, optisch aendert sich also nichts
Spuerbares -- 12 verschiedene Werte sind auf 3 tatsaechlich verwendete
zusammengeschmolzen. Zwischenwerte wie 7px oder 11px entstehen nicht aus
Absicht, sondern weil man beim Bauen einer neuen Kachel nicht nachschaut,
was nebenan schon gilt.

DER BEWEIS, DASS ES EIN SYSTEM IST

Neue Pruefung pruef-system.mjs. Sie behauptet nicht, sie STELLT UM: Die
Markenfarbe wird von Babyblau auf kraeftiges Orange gesetzt und dann
nachgezaehlt, ob irgendwo der alte Ton stehen bleibt.

  658 von 1975 sichtbaren Elementen tragen die Markenfarbe
  0 bleiben nach der Umstellung beim alten Ton
  Prozessfarben folgen nachweislich mit
  Radien: 3 Stufen

UND DIE WICHTIGSTE ERKENNTNIS -- ueber das Messen selbst

Der erste Anlauf meldete 110 haengengebliebene Elemente, alle in Kopf-
und Fusszeile. Die naheliegende Erklaerung waere gewesen: "da steht die
Farbe noch ausgeschrieben". Sie war falsch.

Nachgewiesen ueber die DevTools-Schnittstelle: Auf diese Elemente wirkt
die Regel ".wd a:not(.wd-btn) -> var(--wd-blau)", und --wd-blau
resolviert an genau dieser Stelle korrekt zum neuen Orange. Trotzdem
blieb die berechnete Textfarbe alt -- auch nach erzwungener
Neuberechnung.

Der Unterschied: Kopf- und Fusszeile werden von wd-core.js per innerHTML
eingefuegt. Chromium erneuert solche Teilbaeume nicht zuverlaessig, wenn
man eine Variable NACHTRAEGLICH umstellt. Laedt man dieselbe Seite mit
bereits geaenderter Variable, sind sie orange -- gegengeprueft mit einem
Minimalbeispiel, in dem derselbe Mechanismus einwandfrei funktioniert.

Das Pruefverfahren wurde deshalb umgestellt: Die Variable wird VOR dem
Laden ueberschrieben. Das entspricht genau dem, was eine Aenderung in der
CSS-Datei bewirkt -- also dem Fall, um den es wirklich geht.

Haette ich der ersten Messung geglaubt, haette ich 110 einwandfreie
Stellen "repariert" und dabei das gerade aufgebaute System wieder
zerlegt. Es ist der siebte Fehlalarm in eigener Messtechnik innerhalb
von zwei Runden -- und der subtilste.

ALLE PRUEFUNGEN GRUEN: Gestaltung 0 Befunde (13 Seiten x 5 Sprachen
gegen WCAG 2.2 AA), Anfragedetail 20, Verwaltung 69, Portal 32,
Widerruf 58, Textkodierung 55 Kombinationen, Designsystem 5.

Versionsstempel und Cache-Name auf v9.

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

2026-08-23 13:05:12 +02:00