Phase 6: VBDOS-Theme umsetzen und Change 05a archivieren

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-07

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/design.md

@@ -0,0 +1,31 @@
+## 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.

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/proposal.md

@@ -0,0 +1,27 @@
+## Why
+
+Der gemeldete Screenshot vom 07.09.2026 zeigt blasse Code- und Titelfarben mit unzureichendem Kontrast. Die vorhandenen DOS-Farbnummern werden als terminalprofilabhängige ANSI-Farben ausgegeben; die bisherige Spezifikation garantiert damit noch kein sichtbar VBDOS-nahes, lesbares Theme auf den Phase-6-Zielen.
+
+## What Changes
+
+- Das gesamte IDE-Theme mit belegten VBDOS-Referenzansichten abgleichen; Herkunft, sichere Beobachtungen und bewusste Anpassungen für Lesbarkeit dokumentieren.
+- Dunkelblaue Codefläche, helle Schrift, graue Bedienflächen und die belegte aktive Titelfarbe verlässlich darstellen; die vorhandene Referenz nennt Weiß auf dunklem Magenta, nicht blasses Rosa.
+- Kontrast für normale und ausgewählte Texte, aktive/inaktive Fenster, Menüs, Dialoge, Hilfe, Debugger und Designer messbar absichern. Fokus und Zustände zusätzlich durch vorhandene Rahmen/Zeichen kennzeichnen.
+- Terminalprofilunabhängige IDE-Farbwerte und einen dokumentierten Fallback bereitstellen; Options→Display und gespeicherte Benutzerfarben erhalten.
+- Visuelle Nachweise mit der Plattformmatrix aus 05 verbinden und als Voraussetzung für Release-/Phasenabnahme in 06/07 führen.
+
+## Capabilities
+
+### New Capabilities
+
+Keine.
+
+### Modified Capabilities
+
+- `ide-oberflaeche`: VBDOS-Referenztreue, definierte Farbabbildung und überprüfbare Kontrastanforderungen für das IDE-Theme präzisieren.
+
+## Impact
+
+Betroffen sind insbesondere `crates/tb-ide/src/render.rs`, `options.rs`, `help.rs`, `debugger.rs`, `designer.rs`, ihre vorhandenen Render-/Optionsprüfungen und `docs/ide-referenz.md`. Die ANSI-Zuordnung in `tb-ui/src/screen.rs` ist bei der Abgrenzung zur BASIC-Ausgabe zu berücksichtigen. Kein neuer Theme-Manager und keine zusätzliche Abhängigkeit sind vorgesehen. Benutzerdefinierte BASIC-/Forms-Farbattribute bleiben erhalten.
+
+Eigenständiger Politur-Change innerhalb Phase 6 nach 04, vor finalen Nachweisen aus 05 und der Freigabe aus 06/07. 05 bleibt Eigentümer der echten OS-/Emulatormatrix; 05a liefert deren Theme-Prüffälle. Bereits erhobene Farbnachweise müssen bei Änderungen erneut geprüft werden.

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/specs/ide-oberflaeche/spec.md

@@ -0,0 +1,36 @@
+## MODIFIED Requirements
+
+### Requirement: Farben und Statusanzeige
+Die IDE SHALL das anhand belegter VBDOS-Ansichten dokumentierte Farbschema aus docs/ide-referenz.md verwenden, insbesondere dunkelblaue Codefläche mit heller Schrift, weiße aktive Titel auf dunklem Magenta, graue Menüs und schwarze Statusschrift auf Cyan. Die Standardfarben SHALL auf Terminals mit Unterstützung expliziter Farbwerte unabhängig von der benutzerdefinierten ANSI-Palette ausgegeben werden. Für eingeschränkte Farbfähigkeiten SHALL ein dokumentierter, lesbarer Fallback bestehen; die IDE MUST NOT die globale Terminalpalette verändern. Die Statuszeile SHALL kontextuelle klickbare Kürzel und Zeile/Spalte im Format 00001:001 zeigen. Display SHALL Vorder-/Hintergrund aus 16 Farben, Desktop-Füllzeichen und Tabweite ändern können. Bestehende gespeicherte Farbauswahlen SHALL gültig bleiben und MUST NOT stillschweigend überschrieben werden.
+
+#### Scenario: Farben ändern
+- **WHEN** der Benutzer Titelhintergrund, Desktopzeichen und Tabweite im Display-Dialog ändert
+- **THEN** erscheinen die Änderungen in der IDE, während die Farbvorgaben des ausgeführten BASIC-Programms unverändert bleiben
+
+#### Scenario: Abweichende ANSI-Palette
+- **WHEN** die IDE mit Standardoptionen auf einem Terminal mit expliziter Farbausgabe und einer pastellfarbenen ANSI-Palette gestartet wird
+- **THEN** bleiben Codefläche dunkelblau, Code lesbar und aktive Titel weiß auf dunklem Magenta; das Terminalprofil und die Farben nach Verlassen der IDE werden nicht verändert
+
+#### Scenario: Bestehende Einstellungen laden
+- **WHEN** eine vorhandene Optionsdatei mit angepassten DOS-Farbnummern geladen wird
+- **THEN** bleiben die gewählten Nummern sowie alle weiteren Einstellungen erhalten und gelten über dieselbe definierte IDE-Farbabbildung
+
+## ADDED Requirements
+
+### Requirement: Lesbare UI-Zustände
+Im Standardtheme SHALL jedes dargestellte IDE-Text-/Hintergrundpaar mindestens 4,5:1 Kontrast nach sRGB-Relativluminanz besitzen, einschließlich Auswahl, Hilfelinks, Fehlermeldungen und deaktivierter Beschriftungen. Zur Bedienung notwendige nichttextuelle Fokus-/Rahmenmarkierungen SHALL gegenüber angrenzenden Flächen mindestens 3:1 erreichen. Aktive/inaktive, ausgewählte, deaktivierte und Debuggerzustände SHALL zusätzlich durch Rahmen, Zeichen oder Text erkennbar bleiben. Benutzerdefinierte Farbkombinationen und programmgesteuerte BASIC-Farben sind von den Standardtheme-Grenzwerten ausgenommen.
+
+#### Scenario: Auswahl und Fensterwechsel
+- **WHEN** Text markiert, zwischen Code und Projekt gewechselt und ein Menü oder Dialog geöffnet wird
+- **THEN** bleiben Schrift und Fokus in allen beteiligten Zuständen lesbar; die Standardfarbpaare und erforderlichen Markierungen erfüllen die Kontrastgrenzen
+
+#### Scenario: Hilfe, Debugger und Designer
+- **WHEN** ein Hilfelink fokussiert, ein Breakpoint oder die aktuelle Ausführungszeile angezeigt und ein Designer-Control ausgewählt wird
+- **THEN** bleiben Inhalt, jeweilige Markierung und Beschriftungen unterscheidbar und erfüllen die Standardtheme-Kontrastgrenzen
+
+### Requirement: Belegter Theme-Abgleich
+Der Theme-Abgleich SHALL nachvollziehbare VBDOS-Referenzfundstellen und zugeordnete IDE-Ansichten für Editor, aktive/inaktive Titel, Menüs, Projekt, Dialoge, Status, Hilfe und Designer dokumentieren. Nicht belegte Details SHALL als solche und bewusste Abweichungen für Kontrast als Anpassungen gekennzeichnet sein. Die reale Darstellung SHALL in der Plattformmatrix für Windows Terminal, Terminal.app sowie xterm und VTE auf beiden Linux-Architekturen mit Revision, Terminalversion und Farbprofil geprüft werden. Fehlende visuelle Nachweise MUST offen bleiben.
+
+#### Scenario: Farbnummern stimmen, Darstellung weicht ab
+- **WHEN** ein Render-Test die erwarteten Farbnummern liefert, der reale Terminalnachweis aber blasse oder unlesbare Standardfarben zeigt
+- **THEN** bleibt der Theme-Befund offen, bis Ursache, Korrektur beziehungsweise belegte Terminalgrenze und erneute betroffene Abnahme dokumentiert sind

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/tasks.md

@@ -0,0 +1,20 @@
+## 1. Referenz und Ursachenabgleich
+
+- [x] 1.1 Die in `docs/ide-referenz.md` genannten Farben anhand nachvollziehbarer VBDOS-Fundstellen für Code, Titel, Menüs, Projekt, Dialoge, Status, Hilfe und Designer belegen; Tabelle mit Fundstelle, Sollpaar und ausdrücklich unbelegten Details liefert den prüfbaren Abgleich.
+- [ ] 1.2 Den Screenshot-Befund mit frischen und gespeicherten Optionen sowie normaler/abweichender ANSI-Palette reproduzieren; Auswahl, Transparenz und Inaktivitätsdimmung getrennt prüfen und tatsächliche Ursache samt Vorher-Nachweis dokumentieren.
+
+## 2. Farbabbildung und Zustände
+
+- [x] 2.1 Bestehende IDE-Farbabbildung um definierte DOS-RGB-Werte und passenden 256-/16-Farb-Fallback ergänzen; fokussierter Test bestätigt alle 16 Zuordnungen und tatsächlich erzeugte Terminalfarben ohne globale Palettenänderung.
+- [x] 2.2 Direkte und geerbte Farben in Editor, Fenstern, Menüs, Dialogen, Status, Hilfe und Debugger auf die einheitliche Abbildung führen; Renderprüfung muss reale Vorder-/Hintergrundpaare bei Auswahl, deaktivierten Einträgen, Fensterwechsel, Fehler und Debuggermarkierung erfassen.
+- [x] 2.3 Designer-Werkzeuge, Properties und Auswahlmarkierungen abgleichen; Renderprüfung belegt lesbare IDE-Zustände bei unveränderten BASIC-/Forms-Farbattributen und Vorschaufarben.
+- [x] 2.4 Standardpaare auf 4,5:1 Textkontrast und notwendige nichttextuelle Markierungen auf 3:1 prüfen, unzureichende Paare korrigieren und Abweichungen vom Vorbild begründen; ausführbarer Regressionstest muss bei einem absichtlich kontrastarmen Standardpaar fehlschlagen.
+- [x] 2.5 Options→Display und Laden/Speichern vorhandener Farbnummern prüfen; Regression bestätigt unveränderte Benutzerauswahl, Desktopzeichen, Tabweite und Programmausgabe ohne stilles Zurücksetzen.
+
+## 3. Visuelle Abnahme und Übergabe
+
+- [x] 3.1 Referenztabelle, Kontrastwerte und reproduzierbare Ansichten/Bedienfolgen für 05 bereitstellen; jede betroffene UI-Rolle und jeder Zustand muss einen erwarteten sichtbaren Effekt besitzen, einschließlich Standardprofil und abweichender ANSI-Palette.
+- [ ] 3.2 Tatsächliche Theme-Nachweise aus 05 für Windows Terminal, Terminal.app sowie xterm/VTE auf Linux amd64 und arm64 zuordnen; Revision, Terminalversion, Profil/Farbmodus und Vorher-/Nachher-Ansichten müssen vorliegen, fehlende Systeme bleiben offen.
+- [ ] 3.3 Alle Theme-Befunde beheben und betroffene Render-/Options-/Emulatorprüfungen wiederholen; Verifizierungsbericht mit null offenen Befunden, aktuelle Referenzdokumentation und konsistente Übergabe an 05/06/07 sind Abschlussbedingung.
+
+Archivhinweis 07.09.2026: Auf Benutzeranweisung nach offen ausgewiesenem Stand 7/10 archiviert. Aufgaben 1.2, 3.2 und 3.3 bleiben unbestanden; Change 05 führt Profil-Gegenprobe, tatsächliche Matrix und abschließende Theme-Verifizierung weiter.

openspec/changes/archive/2026-09-07-phase-6-05a-vbdos-theme-und-kontrast/verification.md

@@ -0,0 +1,51 @@
+# Verifizierung: phase-6-05a-vbdos-theme-und-kontrast
+
+Stand: 07.09.2026, Basis `69f200248198a7a0cc5cd23f7f379550eee0277f` plus lokaler Change-05a-Diff. Auf Benutzeranweisung nach dem Bericht 7/10 synchronisiert und am 07.09.2026 archiviert; die drei offenen Nachweise werden ausdrücklich in Change 05 weitergeführt. Implementierung und lokale Tests sind keine vollständige visuelle Plattformabnahme.
+
+## Ergebnis
+
+| Dimension | Stand |
+|---|---|
+| Vollständigkeit | 7/10 Aufgaben abgeschlossen; 1.2, 3.2 und 3.3 offen |
+| Korrektheit | Lokale Farb-, Zustands-, Options- und Regressionsprüfungen bestanden; tatsächliche Darstellung auf den Pflichtterminals noch nicht belegt |
+| Kohärenz | Vorhandene IDE-Farbabbildung erweitert, keine neue Abhängigkeit; BASIC-Ausgabe und Formularvorschau behalten ihre separate Zuordnung |
+
+## Implementierung und Nachweise
+
+- `crates/tb-ide/src/render.rs`: zentrale DOS-RGB-Palette, fester 256-Farben-Fallback außerhalb der Systempalette, begrenzter ANSI-Fallback. Bestehende Farbnummern bleiben kompatibel. Gemeinsame Farbpaare für aktive/inaktive Fenster, Projekt, Menüs, Dialoge, Status und Fehlermeldungen; aktive Fenster mit Doppelrahmen, deaktivierte Menüpunkte mit lesbarer Schrift und zusätzlichem ×-Zeichen. Mnemonics erben die Auswahlfarben.
+- `crates/tb-ide/src/help.rs` und `debugger.rs`: Hilfetitel/Links mit lesbarem Vordergrund, ausgewählter Link mit festem Paar, Debugger mit derselben IDE-Palette. Breakpoint und Ausführungsmarkierung erhalten in `render.rs` eigene kontrastreiche Hintergründe.
+- `crates/tb-ide/src/designer.rs`: Handles/Timerkennzeichen mit vollständigem Farbpaar und kontrastgerechte Beschriftung aller 16 Farbfelder. Toolbox und Properties Bar orientieren sich an den cyanfarbenen Referenzflächen; Formularfarbattribute bleiben unverändert.
+- `crates/tb-ide/tests/app.rs`: Zellprüfung von Editor, Textauswahl, allen Menüeinträgen, deaktivierten Zuständen, Dialogen einschließlich Fehlern, Projekt, Hilfe/Linkfokus, Debugger/Breakpoint/Ausführungszeile und Designer-Werkzeugen. Absichtlich zu schwaches Titelpaar wird abgewiesen. RGB-/256-Farben-Kontrast und alle Palettenbeschriftungen geprüft; reale Ratatui/Crossterm-Ausgabe enthält explizite Farbsequenzen und keine OSC-Palettenänderung. Bestehende Options-/Persistenzprüfungen sowie unveränderte BASIC-Palettenzuordnung bestehen.
+- `docs/ide-referenz.md`, Abschnitt 4a: drei nachvollziehbare Originalprogramm-Ansichten für Code/Run-Menü/Projekt, Designer und About-Dialog. Nicht belegte Hilfe-/Deaktivierungsdetails sind ausdrücklich benannt. Tabelle dokumentiert gezielte Kontrastabweichungen, Messwerte und die vollständige Bedienfolge für sechs Matrixzellen in 05.
+
+### Ausgeführte Prüfungen
+
+- `COLORTERM=truecolor cargo test --locked --workspace`: 636 bestandene Testergebnisse, 0 Fehler, 3 bestehende ignorierte Tests. Kein ignorierter Fall wird als Theme-Nachweis gezählt.
+- Anschließend `COLORTERM=truecolor cargo test --locked -p tb-ide` auf dem letzten Render-/Dokumentationsstand: bestanden (91 Tests plus erfolgreicher separater Hilfe-Kindprozess).
+- `COLORTERM= TERM=xterm-256color cargo test --locked -p tb-ide --test app theme_`: 3/3 bestanden. Erfasst auch den Fall, dass ein generisches COLORTERM die TERM-Erkennung überdecken würde.
+- `COLORTERM= TERM=vt100 cargo test --locked -p tb-ide --test app theme_`: 3/3 bestanden. Die Berechnung für ANSI setzt die dokumentierte DOS-Palette voraus und beweist kein frei konfiguriertes Emulatorprofil.
+- `cargo clippy --locked -p tb-ide --all-targets -- -D warnings`, `cargo fmt --all -- --check` und `git diff --check`: bestanden.
+- `openspec validate --all --strict --no-interactive`: 31/31 bestanden.
+- `cargo build --locked --release -p tb-ide`: bestanden; aktuelle IDE unter `target/release/tb` (macOS arm64). SHA-256: `b54dfa6607b454dae42bb57bc856b020a11ce80a2dd49a55f9826e461fbe8e0f`. Ein lokaler Build ist kein visueller Terminalnachweis.
+
+## Offene Befunde – Übergabe an Change 05
+
+### CRITICAL: Aufgabe 1.2 – konkrete Screenshot-Reproduktion fehlt
+
+Der Codebefund ist reproduzierbar: benannte ANSI-Farben werden vom Terminalprofil bestimmt, feste RGB-/256-Farben umgehen diese Systempalettenzuordnung. Aus dem Benutzerbild allein lässt sich jedoch nicht feststellen, welchen Anteil gespeicherte Optionen, Textauswahl, Transparenz oder Inaktivitätsdimmung an dessen Darstellung hatten. Am erwarteten macOS-Standardpfad lag keine Optionsdatei vor; das beweist nicht, dass die abgebildete Sitzung ohne Optionen lief.
+
+Erforderlich: dieselbe IDE-Ansicht im betroffenen Terminal mit frischen und den tatsächlich verwendeten Optionen sowie protokolliertem Profil nach der Folge in Abschnitt 4a vergleichen. Die Aufgabe bleibt bis zu dieser Gegenprobe offen.
+
+### CRITICAL: Aufgabe 3.2 – echte visuelle Matrix fehlt
+
+Windows amd64/Windows Terminal, macOS arm64/Terminal.app sowie Linux amd64 und arm64 jeweils mit xterm und VTE sind noch nicht visuell abgenommen. Es werden weder Cross-Builds noch TestBackend-Ansichten als solche Nachweise ausgegeben. Die Computer-Use-Schnittstelle hat den Zugriff auf Terminal.app im bisherigen Versuch ausdrücklich gesperrt; andere UI-Steuerwege werden nicht zum Umgehen dieser Sperre verwendet. Für die übrigen Pflichtterminals liegt noch kein nutzbarer Zugang vor.
+
+Erforderlich: die vorbereiteten Ansichten auf den sechs tatsächlichen Kombinationen prüfen und Revision, Executable-Prüfsumme, Terminalversion, Profil/Farbmodus und Bild-/Transkriptbelege in Change 05 zuordnen. Vorher-Nachher-Vergleich und getestete Ersatzwege bei Terminalgrenzen dokumentieren.
+
+### CRITICAL: Aufgabe 3.3 – Abschluss setzt die beiden Nachweise voraus
+
+Die lokalen Prüfungen melden auf dem geprüften Stand keinen weiteren Implementierungsbefund. Ein Report ohne offene Befunde kann erst nach 1.2 und 3.2 erstellt werden. Tatsächlich gefundene Zielprobleme müssen vor Abschluss korrigiert und auf dem betroffenen Terminal erneut geprüft werden.
+
+## Nächster Schritt
+
+Die korrigierte IDE ist die Implementierungsgrundlage für Change 05. Dessen echte Plattformabnahme liefert die noch offenen visuellen Nachweise für 05a; Change 05 bleibt bis dahin offen; das Archiv von 05a dokumentiert ausdrücklich den Stand 7/10 statt einer vollständigen visuellen Abnahme. Es wurde keine Pflichtprüfung gestrichen oder als bestanden angenommen.