## Context

`Options::default` enthält bereits Code (7,1), aktiven Titel (15,5), Menü/Dialog (0,7) und Status (0,3). `render::dos` übersetzt diese Werte in benannte ANSI-Farben; `help.rs`, `debugger.rs` und Teile von `render.rs` setzen zusätzlich direkte Farben. Die konkrete Darstellung hängt daher vom Terminalprofil ab. Der Screenshot „Bildschirmfoto 2026-09-07 at 17.04.25.png“ zeigt das Problem, beweist aber weder das verwendete Profil noch die Ursache jeder einzelnen blassen Fläche. Auch Auswahl, gespeicherte Optionen, Transparenz und Inaktivitätsdimmung sind zu prüfen.

`docs/ide-referenz.md`, Abschnitt 4, nennt Weiß auf Magenta ausdrücklich als VBDOS-Merkmal. Diese Sekundärrekonstruktion ist der Ausgangspunkt; ihre Originalfundstellen sind bei der Umsetzung nachvollziehbar zu belegen. Ein Austausch gegen eine beliebige moderne Palette wäre kein Referenzabgleich.

## Goals / Non-Goals

**Goals:** Definierte IDE-Farbwerte, VBDOS-nahe Flächen und Kontrast in allen interaktiven Zuständen mit wenigen Änderungen an vorhandenen Renderpfaden.

**Non-Goals:** Theme-Framework, neue Theme-Auswahl, globale Terminalpalette verändern, automatische Umfärbung von BASIC-Programmen, Emulatorinstallation, Änderungen an Build-/Exportarchitektur.

## Decisions

1. Die bestehenden sieben konfigurierbaren Elemente und DOS-Farbnummern erhalten. Die vorhandene zentrale IDE-Abbildung um explizite RGB-Werte der dokumentierten DOS-Palette ergänzen; sämtliche direkten IDE-Farbzuweisungen und geerbten Hintergrundfarben prüfen und auf dieselbe Abbildung führen. Keine zweite Palette pro Fenster. Reine Änderungen der Defaults reichen gegen profilabhängige ANSI-Farben nicht aus.
2. Direkte Farbausgabe verwenden, wenn vom Terminal unterstützt; für 256 Farben feste passende Einträge außerhalb der profilabhängigen ersten 16 verwenden, für reine 16-Farb-Terminals bestehende ANSI-Zuordnung als begrenzten Fallback dokumentieren. Vorhandene Terminalfähigkeitsinformationen wiederverwenden; keine neue Erkennungsbibliothek oder Terminalabfrage-Protokollschicht. Fehlende Erkennung und tatsächlich genutzter Fallback müssen im Prüfbericht benannt sein.
3. Referenzfarben je Rolle mit Fundstellen festhalten. Zuerst Originalzuordnung prüfen, danach nur unzureichende Kontrastpaare gezielt anpassen. Für diese Anpassungen explizite Begründung statt falscher Behauptung historischer Identität. Insbesondere Auswahl, deaktivierte Menüs, inaktive Titel, rote Breakpoints und Hilfelinks gegen ihren tatsächlichen Hintergrund messen. Alle Standardtexte erhalten 4,5:1, notwendige nichttextuelle Markierungen 3:1; vorhandene Symbole/Rahmen als zusätzliche Zustandsmerkmale nutzen.
4. Die IDE-Palette vom `ScreenWidget` für BASIC-Ausgabe getrennt halten. Dessen `basic_color` und die BASIC-/Forms-Farbattribute werden durch diesen Change nicht global ersetzt. Designer-Vorschau von programmbestimmten Farben unterscheiden: IDE-Werkzeuge erhalten das Theme, Vorschau respektiert Form-Farbattribute.
5. Bestehende TestBackend- und Optionsprüfungen um tatsächliche Vorder-/Hintergrundwerte, Kontrast und Zustandswechsel erweitern. Keine rein textuellen Snapshots als Farbprüfung ausgeben. In 05 dieselben Ansichten unter Standardprofil und absichtlich abweichender ANSI-Palette erfassen; Terminalprofil, Transparenz/Dimmung und ausgewählte Texte protokollieren. Keine Screenshot-Pixelgleichheit über unterschiedliche Schriften fordern.
6. 05a kann unabhängig von noch fehlenden Prüfrechnern implementiert werden, ist aber erst mit den zugeordneten visuellen Matrixnachweisen vollständig verifiziert. 05 bleibt Eigentümer dieser Nachweise. Vor Releasefreigabe 06 und Phasenabschluss 07 müssen 05a und die betroffenen Matrixzellen bestanden sein.

## Risks / Trade-offs

- Terminal erzwingt Transparenz oder Inaktivitätsdimmung → Anwendung kontrolliert dies nicht; reproduzierbares undurchsichtiges Prüfprofil und tatsächliche Einschränkung dokumentieren, keine unlesbare Pflichtzelle als bestanden werten.
- 16-Farb-Fallback hängt weiter von der Palette ab → Grenze und geprüftes geeignetes Profil dokumentieren; bei unterstützten expliziten Farben nicht unnötig auf ANSI zurückfallen.
- Exakte historische Kombination verfehlt Kontrast → Lesbarkeit hat Vorrang; eng begrenzte Anpassung mit Originalpaar und Messwert belegen.
- Benutzerfarben sind absichtlich kontrastarm → erhalten, ohne Standardtheme-Abnahme auf diese Auswahl zu übertragen.

## Migration Plan

Keine neue Optionsdatei und keine automatische Überschreibung. Referenzbelege und Farbabbildung ergänzen, betroffene Renderpfade und Regressionen prüfen, anschließend visuelle Nachweise in 05 aktualisieren. Rücknahme betrifft nur die IDE-Farbabbildung und zugehörige Renderkorrekturen; gespeicherte Farbnummern bleiben kompatibel.
