4.3 KiB
Context
Die Vorgänger 01–07 besitzen abgegrenzte Fähigkeiten und eigene Szenarien. Bereits vorhandene CLI-/VM-/Forms-Regressionen und Release-Compile-Benchmarks bleiben maßgeblich. Die Referenz enthält mehr Befehle als die acht offenen Phase-5-Checkboxen; die Gesamtübersicht enthält deshalb eine vollständige Zuordnung statt einer erneuten allgemeinen Codeprüfung.
Goals / Non-Goals
Goals: Echte Benutzerwege und ihre Übergänge belegen, Abnahmestand reproduzierbar dokumentieren und Phase 5 nur bei vollständiger Umsetzung schließen.
Non-Goals: Neue Parallelimplementierung fehlender Features, Ersatz aller vorhandenen Tests, vorgezogene vollständige Terminal-/OS-Matrix aus Phase 6 oder pauschale Performanceoptimierung.
Decisions
-
Der Rahmen-Testpfad aus 02 treibt die echte App mit crossterm-Ereignissen und ratatui-TestBackend. Dokumente entstehen für End-to-End-Szenarien durch Eingaben und Dialoge. Unmittelbar vorbereitete VM-Objekte bleiben für fokussierte Unit-Tests nützlich, ersetzen aber keinen Create/Save/Reopen-Nachweis.
-
Ein dokumentierter Hauptablauf erstellt ein Projekt mit zwei BAS-Modulen, FRM, Control-Array, Menü und Include, erzeugt Ereigniscode über F12, nutzt Hilfe, startet, setzt Breakpoints, steppt über einen Aufruf, ändert einen Wert im Immediate Window, setzt fort und öffnet das gespeicherte Projekt erneut. Ergänzende kurze Fehlerabläufe prüfen Schreibfehler, externe Änderungen, Compilefehler, Include-Quellorte, kleine Terminals und Shell-Rückkehr. Das vermeidet einen einzigen undiagnostizierbar großen Test.
-
Eine Befehlsabdeckungstabelle bindet jeden Eintrag aus der Gesamtübersicht an Aktion, zulässige Modi und mindestens einen ausführbaren Nachweis. Tastatur-, Menü- und Mausäquivalenz wird am gemeinsamen Dispatcher geprüft; konfliktträchtige F-Tasten zusätzlich im vollständigen Ablauf. Nicht implementierte Phase-5-Befehle bleiben offene Befunde ihres zuständigen Feature-Changes, statt hier mit einem zweiten Codepfad kaschiert zu werden.
-
Parität verwendet dieselben gespeicherten Quellen, initialen Dateien, COMMAND$, Terminalmaße und deterministischen Ereignis-/Zeitfolgen. Verglichen werden IDE-VM, CLI-Quellcompile und geladenes TBC. STOP/Break und Debug-Nebenwirkungen werden gezielt gesteuert, normale Programmläufe dagegen ohne Debuggeroptionen verglichen.
-
Vorhandene Referenzprogramme und Benchmarks werden wiederverwendet; es wird kein fremder Korpus vendort. Der Abschlussbericht nennt Revision, Befehle, konkrete Ergebnisse, Referenzhardware und bekannte Terminalgrenzen. Normale Tests prüfen Cache-Wiederverwendung deterministisch, Release-Messungen die bestehenden Zeitbudgets. Wiederholungen nur bei Änderung oder ungeklärtem Fehler.
-
PLAN.md wird erst nach bestandenem Nachweis aktualisiert, einschließlich präziser Bezeichnung der Properties Bar. Die Phase-6-Plattformmatrix bleibt separat; die lokale headless Abnahme wird nicht als vollständiger Emulator-/OS-Nachweis ausgegeben. IDE-Bedienungsseiten aus 07 werden auf die endgültigen Tasten und Abläufe abgeglichen.
-
Die Exportdialoge aus 02 sind ein eigener vollständiger Phase-5-UI-Nachweis. Der Hauptablauf öffnet beide Make-Dialoge und prüft Zieleingaben, Validierung, Überschreibentscheidung und den erklärten fehlenden Erzeugungsdienst. Kontrollierte Ergebnisrückmeldungen testen Status/Erfolg/Fehler/Abbruch an der vorbereiteten Übergabe, ohne eine native Erzeugung zu behaupten. Der Phase-6-Plan hält echte Standalone-Executables und native Bibliotheken mit Verbraucherprüfung als getrennte offene Aufgaben fest.
Risks / Trade-offs
- Synthetische UI-Tests übersehen tatsächliche Tastencodierung → native Eingabe-Eventtypen bis zum Dispatcher einspeisen; reale Plattformmatrix weiter in Phase 6 verfolgen.
- Grünes Teilfeature wird mit fertiger IDE verwechselt → Abschluss nur mit allen Vorgängerszenarien und integrierter Befehlsmatrix.
- Monolithischer End-to-End-Test ist schwer zu warten → ein lesbarer Hauptablauf plus wenige gezielte Fehlerabläufe und vorhandene modulare Regressionen.
Migration Plan
Keine neuen Dateiformate. Nach vollständiger Verifikation Spezifikationen der Vorgänger und dieses Changes gemäß normalem Workflow synchronisieren/archivieren; PLAN-Checkboxen beziehen sich auf nachgewiesene Fähigkeiten, nicht auf die bloße Existenz der Planungsartefakte.