38 lines
3.5 KiB
Markdown
38 lines
3.5 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. 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.
|
||
|
||
### 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 nur die hier benannten verbleibenden Eventquellen ändern.
|
||
- 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.
|