3.7 KiB
Context
Phase 5 verwendete crossterm-Ereignisse, ratatui-TestBackend und tests/support/ide-execution-pty.py. Der vorhandene PTY-Test setzt Unix voraus. Die verbindlichen Release-Targets sind Windows amd64, macOS arm64 und Linux amd64/arm64; Plattform-/Emulatornachweise fehlen noch.
Goals / Non-Goals
Goals: Tatsächliche Terminalgrenzen von Produktfehlern unterscheiden und sämtliche Zielkombinationen mit reproduzierbaren Bedienfolgen abnehmen.
Non-Goals: Zweites UI-Toolkit, Emulation des historischen DOS-Programms, ein automatischer Test als Ersatz für reale Emulatorbedienung.
Decisions
-
Eine Matrix mit Windows Terminal auf Windows amd64, Terminal.app auf macOS arm64 sowie xterm und einem VTE-Terminal auf beiden Linux-Architekturen verwenden. Konkrete installierte Versionsnummern sind Messmetadaten. Diese Kombinationen bilden den geplanten Mindestsatz, weitere Emulatoren sind keine Voraussetzung.
-
Die vorhandenen Phase-5-Befehls-/Fokus-/Help-/Debuggerfälle zu kurzen tatsächlichen Eingabesequenzen verdichten. Screenshots/Transkripte, Eventdiagnosen und sichtbare Resultate werden je Matrixzelle festgehalten; ein Log „Prozess gestartet“ reicht nicht. F1–F12 und konfliktreiche Modifikatoren vollständig aufführen.
-
Buildhost und Prüfsystem unterscheiden: Pakete entstehen in 06 zentral auf Linux arm64, echte Zielprüfungen laufen auf passenden Systemen; vier native Buildrunner sind keine Voraussetzung. Für 05 können Kandidaten aus lokalen Repository-Buildaufrufen verwendet werden, sodass kein Vorababschluss von 06 nötig ist. 06 prüft später die tatsächlich gepackte Revision. Die unveränderte
tests/libraries/portable.tblaus 03 mittests/support/library-abnahme.pyauf allen vier Zielen prüfen; TBL-Prüfsumme, Toolrevision, tatsächliches Host-Target und Ergebnisse einschließlich quellfreier TBC-/EXE-Nutzung und RUN festhalten. -
Unix-PTY-Prüfung wiederverwenden; Windows-ConPTY-/Konsolenprüfung für automatisierbare Terminalübergänge ergänzen. Dieselben nativen Releaseprogramme und eine repräsentative exportierte Forms-Anwendung verwenden. Gitea-Jobs führen automatisierbare Prüfungen aus; echte Emulatorfolgen dürfen dokumentiert manuell erfolgen.
-
Windows-/Unix-spezifische Tests und Hilfsprozesse mit passenden Plattformzweigen führen. Keine Unix-Shell-Kommandos unverändert auf Windows als vermeintliche Produktfehler werten. Produktsemantik und Testhost-Portabilität getrennt prüfen.
-
Fehler im gemeinsamen Terminaladapter beheben und einen fokussierten Regressionstest ergänzen. Für vom Emulator reservierte Shortcuts einen bereits vorhandenen Menü-/Mausweg prüfen. Fehlende Pflichtfunktionen werden nicht als Terminalgrenze umetikettiert.
-
Den ergänzenden Theme-Change 05a vor Abschluss der visuellen Matrix berücksichtigen. Dessen Referenzansichten und Kontrastprüfungen mit tatsächlicher Revision, Farbprofil und Standard-/abweichender ANSI-Palette in jeder Pflichtzelle prüfen; vor einer Theme-Korrektur erhobene betroffene Bilder erneut aufnehmen. Diese Nachweise gehen mit der bestehenden Matrix an 06/07.
Risks / Trade-offs
- CI ohne interaktiven Desktop → automatisierte Zieltests plus zugeordnete manuelle Emulatornachweise, keine Gleichsetzung beider Kategorien.
- Nicht verfügbare Maschinen → benannter externer Nachweisbedarf; Change erst nach vollständiger Matrix abnehmen.
- Globale Tastenbelegung des Benutzers beeinflusst Ergebnis → Terminalkonfiguration mitprotokollieren und Ersatzweg prüfen.
Migration Plan
Bestehende Headless-Regressionen erhalten. Plattformkorrekturen inkrementell anwenden; Nachweise mit geprüfter Revision ablegen. Matrix an 06 und 07 übergeben; ihre Gültigkeit bei Änderungen am Terminaladapter oder Hostpfad erneut prüfen.