38 lines
4.3 KiB
Markdown
38 lines
4.3 KiB
Markdown
## Context
|
||
|
||
pruefe_forms erwartet jede Klasseneigenschaft und jedes Ereignis pauschal als implementiert. Der Formularfallback in handle_key erzeugt nur KEYDOWN, während FORM_KEYPRESS/FORM_KEYUP implementiert heißen. traps.bas und formular.frm fehlen die genannten Kombinationen. write_text besitzt bereits einen Erhaltungsmodus. Siehe proposal.md und die Delta-Specs.
|
||
|
||
## Goals / Non-Goals
|
||
|
||
**Goals:** Grüne Prüfungen an beobachtbares Sollverhalten binden und veraltete Normtexte gezielt berichtigen.
|
||
|
||
**Non-Goals:** Kein erneutes allgemeines Refactoring, kein ungezieltes Testframework, kein Aufweichen der übrigen Spezifikationen, keine Änderung des Bytecode-Vertrags dieses Changes (Eigentum projektmodule-und-kompilat).
|
||
|
||
## Decisions
|
||
|
||
### D1 — Vorhandenen Inventartest erweitern
|
||
|
||
Inventareinträge weiterhin aus der Markdowntabelle lesen, aber für implementiert mindestens erzeugbare Frontend-/HIR-Pfade ohne Unsupported und auflösbare Runtime-Ziele prüfen. Syntaxformen mit expliziten kleinen Programmvorlagen abdecken; Forms-Probequellen aus Klassen-/Signaturmetadaten erzeugen. Der Inventartest liegt im CLI-Testpaket, damit auch `$INCLUDE` den echten Projektlader durchläuft. Unabhängige Sollziele aus Runtime-ABI, Instruktionsvertrag und Modulmetadaten müssen in der tatsächlichen Absenkung vorkommen; Forms-Dispatch muss den konkreten Klassenmember erreichen. Gegenproben ersetzen gültige Bindungen, Forms-Member und Typselektoren oder entfernen die Absenkung. Klassentabellen allein gelten nicht als Laufzeitnachweis. Für Ereignisse reale Auslöser bis zum BASIC-Handler prüfen; die konkret fehlenden Form-KeyPress/KeyUp ergänzen, nicht den Status auf offen setzen.
|
||
|
||
### D2 — Korpusfälle nach fehlender Bedingung hinzufügen
|
||
|
||
Bestehenden CaptureHost/Harness wiederverwenden; jede Maskierungsquelle in ON/OFF/STOP, EVENT OFF, Control-Alt-Key, Shift-Tab und Fokusreihenfolge mit deklarierter Ereignis-/Zeitfolge prüfen. Sollbilder werden aus erwarteter Semantik festgelegt und bei Änderung fachlich geprüft.
|
||
|
||
### D3 — Bestehende Produktentscheidungen synchronisieren
|
||
|
||
Nur LINE/PAINT/VIEW/SCREEN 0–13 aus der pauschalen Grafikablehnung ausnehmen; verbleibende Non-Features behalten. FRM: unverändertes Lesen/Schreiben erhält die Originalbytes; neues/geändertes kanonisches Schreiben lässt Defaults aus. Keine Änderung des funktionierenden Erhaltungsmodus nötig. Explizite Control-Array-Indizes bleiben als Strukturangaben auch bei Index 0 erhalten. Elternreferenzen behalten ihren Arrayindex im bestehenden PARENT-Anfangswert (TBC4). Alle Containerpfade nutzen diese Referenz; Zeichnung und Trefferprüfung ordnen Container vor ihren Kindern ein. Die TBC-Validierung weist fehlende Elterninstanzen und Zyklen ab.
|
||
|
||
### D4 — Abschließender Review als Befundnachweis
|
||
|
||
Nach den fünf Korrektur-Changes jede F-ID mit konkretem Regressionstest/Prüfergebnis versehen. Den Bericht von 05.09. als historischen Ausgangsstand erhalten und eine eigene Ergebnisdatei anlegen. Den vorhandenen öffentlichen Fremdprogrammbestand mit seiner dokumentierten Revision verwenden; bei fehlendem Bestand Nachweis ausdrücklich offenlassen statt eine erfolgreiche Bedienung zu behaupten.
|
||
|
||
## Risks / Trade-offs
|
||
|
||
- Generierte Tests spiegeln wieder nur Implementierungsmetadaten → erwartete Ergebnisse für kritische Ereignisse und negative Markerfälle unabhängig in kleinen Quellen festhalten.
|
||
- Überlappung mit funktionalen Korrekturen → diese zuerst integrieren und die im vollständigen Ereignis- und Fremdprogrammlauf nachgewiesenen fehlenden Quellen bzw. Importpfade an ihrem gemeinsamen Ursprung korrigieren.
|
||
- Fremdprogramme können Hardware-Non-Features außerhalb des akzeptierten Bestands enthalten → dokumentierten Prüfbestand/Revision festhalten, keine globale Kompatibilitätszusage daraus ableiten.
|
||
|
||
## Migration Plan
|
||
|
||
Abschließende Gesamtabnahme nach allen fünf anderen Changes. Die Grafik-/FRM-Textpräzisierungen können vorher überprüft werden; Archivierung und Gesamtabschluss erst nach deren Regressionen. Bestehende Spec-/Codeverträge erst nach erfolgreicher Umsetzung synchronisieren und archivieren. Bis dahin bleiben alle Tasks offen. Änderungen als zusammenhängenden Commit je Change integrieren; bei Fehlschlag auf den vorherigen Code zurückgehen und neue Datenformatversionen nicht mit alten Lesern öffnen.
|