Plan Phase 6 runtime, P-code libraries and Gitea releases
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-07
|
||||
@@ -0,0 +1,26 @@
|
||||
## Context
|
||||
|
||||
`compat.rs` besitzt bereits Größen-/Uhr-/Ereignisdirektiven, Text-/Attributvergleiche und temporäre Dateiverzeichnisse. `foreign.rs` prüft sieben Einstiege aus cout/vbdos bei Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`, ist im normalen Lauf aber absichtlich ignoriert. `inventar.rs` und VM-`events.rs` prüfen mehr als Namenslisten. Phase 5 meldete 605 erfolgreiche Tests plus Offline-Kindprozess; dies ist Referenzhistorie, kein Phase-6-Messwert.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:** Bestehende Nachweise zu einem reproduzierbaren Release-Abnahmesatz verbinden, belegte Deckungslücken schließen und Optimierungsbedarf messen.
|
||||
|
||||
**Non-Goals:** Zweiter Interpreter/Harness, Emulatorbetrieb, automatisch neu geschriebene Golden Files, spekulative Optimierung, bereits als bestanden ausgegebene Plattformmatrix.
|
||||
|
||||
## Decisions
|
||||
|
||||
1. Den existierenden Harness und seine Deklarationen erweitern, keine neue Fixture-Sprache einführen. Abdeckung explizit gegen Konsole, Unicode/Attribute/Resize, Forms/Menüs/Fokus, Projekte/Includes, Dateien/ISAM und Fehlerbehandlung zuordnen. Für neue Fälle zunächst Soll aus Spec oder dokumentierter Referenz herleiten; vorhandene Proben wiederverwenden, wo sie das Verhalten bereits beweisen.
|
||||
2. Fremdprogramme aus dem festgelegten Checkout in temporäre Verzeichnisse exportieren. Den optionalen Entwicklertest beibehalten, aber im Release-Aufruf ausdrücklich aktivieren und seine Bereitstellung zwingend prüfen. Keine Originalbinärdateien oder ganzen Fremdkorpora ungeprüft vendorn. Ein fehlender Netz-/Checkoutzugang wird als externe Voraussetzung benannt.
|
||||
3. `cargo bench -p tb-vm --bench compile` und `--bench vm` als Messverfahren erhalten. Compile-Harness enthält harte bestehende Grenzen. VM-Vergleich verwendet denselben Rechner und reproduzierbare Revisionen; mehrere Läufe nur zur Klärung auffälliger Streuung. Kein willkürliches neues absolutes VM-Zeitlimit, kein Vergleich verschiedener Hardware als Regression. Bei unauffälligem Befund genügt ein dokumentiertes „keine Optimierung erforderlich“.
|
||||
4. CLI-, TBC- und IDE-Parität aus Phase 5 als Ausgangspunkt aufnehmen; 02/03/04 ergänzen später native Executables und quellfreie TBL-Verbraucher. Daten/Fehler/Dateien zählen ebenso wie Endbildschirme. Der finale Stand nach diesen Änderungen wird in 07 erneut qualifiziert.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Historische Sollwerte ungeprüft übernehmen → Herkunft je neuem Fall, negative Gegenproben und vorhandene unabhängige Inventarziele erhalten.
|
||||
- Externer Korpus oder Referenzhardware fehlt → fehlenden Nachweis offen führen; nicht durch Ignore als erledigt werten.
|
||||
- Messrauschen → Last, Toolchain und Vergleichsrevision dokumentieren; erst reproduzierbare Verschlechterung optimieren.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
Nur additive Korpus-/Abnahmeergänzungen; Fachkorrekturen mit gezieltem Regressionstest. Rücknahme einzelner Ergänzungen über Git möglich. Bestehende Dateien, Sprachsemantik und CLI-Aufrufe behalten ihren Vertrag. Ergebnisse an 02–07 übergeben.
|
||||
@@ -0,0 +1,154 @@
|
||||
# Phase 6: Gesamtproposal und Exploration
|
||||
|
||||
Stand: 2026-09-07. Erkundungsbasis: Commit `86c3ebeb6d623e2f3e33f957ceb24b19cf6d1940`,
|
||||
abgeschlossene Phase 5 und zunächst keine aktiven Changes. Dieses Dokument
|
||||
plant die gesamte Phase 6; es behauptet keine neue Implementation oder Abnahme.
|
||||
|
||||
## Verbindliche Vorgaben
|
||||
|
||||
- Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64.
|
||||
- Ausschließlich Gitea Actions am bestehenden Origin `git.rfc1437.de/hugo/TerminalBasic`.
|
||||
- Die Actions bauen die tatsächlichen Zielprogramme; reine Platzhalter-/Cross-Buildmeldungen genügen nicht.
|
||||
- Windows-Paket als `.7z`, macOS und beide Linux-Pakete als `.tar.gz`.
|
||||
- Make EXE erzeugt ein eigenständiges natives Executable mit eingebetteter TB-Runtime, ohne Compiler-/Linker-Toolchain beim Anwender.
|
||||
- Make Library liefert portable `.tbl`-P-Code-Bibliotheken. `tbc link` und IDE verwenden denselben Linkdienst; die nativ kompilierte Runtime ist Bestandteil von `tbrt`.
|
||||
- Die in Phase 5 fertiggestellten Dialoge werden jetzt an reale Erzeugung angebunden.
|
||||
- Stufe-2-Spracherweiterungen bleiben außerhalb dieser Phase.
|
||||
|
||||
## Feststellungen am bestehenden Code
|
||||
|
||||
| Bereich | Vorgefundener Stand | Konsequenz für Phase 6 |
|
||||
| --- | --- | --- |
|
||||
| CLI | `tb-cli/src/main.rs::cmd_build` schreibt ausschließlich `.tbc`; Native-Flags und Vorlagen fehlen | 02 ergänzt native Verpackung, bestehender TBC-Aufruf bleibt |
|
||||
| Gemeinsame Ausführung | `project_io::new_execution`, CLI `run_chain`, IDE-Sitzung nutzen dieselbe TBVM; CLI enthält auch Druck-/Exit-/Hostlogik | Runnerpfad wiederverwenden, keine zweite Runtime |
|
||||
| Kompilat | `TBC_VERSION = 4`; Projekt-, Forms-, DATA-, Signatur- und Quellortinformationen bereits vorhanden | Vorlagenversion prüfen, vollständiges TBC als eingebettete Nutzlast verwenden |
|
||||
| Library | Projektlinker vorhanden, aber noch AST-abhängig; kein TBL-Container oder tbc-link-Befehl | 03 ergänzt serialisierbare Modul-/Symbolmetadaten und quellfreie Verknüpfung |
|
||||
| IDE-Export | ExportRequest/ProjectStamp/ExportStatus vorhanden; gültiger Dialogauftrag endet in UNAVAILABLE | 04 bindet Erzeugung an; Staging erst nach gültiger Auftragsprüfung veröffentlichen |
|
||||
| Zielauswahl | UI akzeptiert bisher unabhängig drei Systeme und zwei Architekturen | Vierziel-Matrix für EXE zentralisieren; Make Library erzeugt TBL ohne native Zielwahl |
|
||||
| Korpus | `compat.rs`: Größen-/Zeit-/Ereignisdirektiven, Text-/Attributsnapshot, temporäre Dateien; weitere Projekt-/Forms-/Fehlerproben | Bestehende Pfade ergänzen und als Release-Abnahmesatz verbinden |
|
||||
| Fremdprogramme | Sieben Programme aus cout/vbdos, fixierte Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`; explizit optionaler Test | Releaseprüfung ruft ihn zwingend mit bereitgestelltem Bestand auf; fehlender Bestand bleibt fehlender Nachweis |
|
||||
| Inventar | Sprach- und vollständige Forms-Einträge; feste Sollziele, Absenkungs- und Ereignistests vorhanden | Nicht auf historische 285 Spracheinträge verkürzen; finale vollständige Null-offen-Abnahme |
|
||||
| Leistung | Vorhandene Compile- und VM-Benchmarks; Phase-5-Compile 0,74/98 ms auf M5 Max | Aktuelle Referenzmessung statt vorsorglicher Optimierung; historische Werte nicht als Phase-6-Ergebnis ausgeben |
|
||||
| Terminal | TestBackend und lokaler Unix-PTY-Test vorhanden | Tatsächliche Emulator-/Systemmatrix einschließlich Windows und Linux arm64 ergänzen |
|
||||
| CI | Keine Workflowdateien; Origin meldet Gitea 1.25.4 | Vier passende Runner und tatsächliche Actions-Läufe nachweisen; Verfügbarkeit bisher nicht bestätigt |
|
||||
| Doku | README „Projektrahmen“, alte Korpus-Phasenhinweise, Exportbackend noch als geplant beschrieben | 07 gleicht Installation, Hilfe, Migration, Beispiele und Plan an ausgelieferte Programme an |
|
||||
|
||||
## Change-Aufteilung und Abhängigkeiten
|
||||
|
||||
| Nr. | Change | Voraussetzungen | Eigenständige Leistung |
|
||||
| --- | --- | --- | --- |
|
||||
| 01 | [Kompatibilität und Leistungsabnahme](proposal.md) | Phase 5 | Reproduzierbarer Abnahmesatz, Fremdkorpus, Inventarbasis und begründeter Performance-Pass |
|
||||
| 02 | [Native Executables](../phase-6-02-native-executables/proposal.md) | 01 | Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung |
|
||||
| 03 | [P-Code-Bibliotheken und Linker](../phase-6-03-pcode-bibliotheken-und-linker/proposal.md) | 02 | TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher |
|
||||
| 04 | [IDE-Exportanbindung](../phase-6-04-ide-exportanbindung/proposal.md) | 02, 03 | Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse |
|
||||
| 05 | [Plattformmatrix](../phase-6-05-plattformmatrix/proposal.md) | 01–04 | Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen |
|
||||
| 06 | [Gitea Actions und Releases](../phase-6-06-gitea-actions-und-releases/proposal.md) | 01–05 | Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad |
|
||||
| 07 | [Dokumentation und Phasenabnahme](../phase-6-07-dokumentation-und-phasenabnahme/proposal.md) | 01–06 | Aktuelle Anleitungen/Hilfe, ausgelieferter Gesamtweg und belegter Phase-6-Abschluss |
|
||||
|
||||
Die Reihenfolge 01 bis 07 ist gültig. Native Zielprüfungen in 02/03/05 sind
|
||||
vor 06 zunächst lokal auf passenden Prüfrechnern ausführbar; 06 automatisiert
|
||||
diese Aufrufe in Actions und liefert die endgültigen Pakete. Dadurch entsteht
|
||||
kein Kreis „Export benötigt Release, Release benötigt Export“. Endgültige
|
||||
Evidenz mit Releasepaketen liegt in 07. Das Scaffolding von Changes und die
|
||||
OpenSpec-Artefaktstatus erzwingen diese fachlichen Abhängigkeiten nicht.
|
||||
Beim Anwenden sind umgesetzte/synchronisierte Vorgänger und ihre Ergebnisse
|
||||
zu prüfen; nach Archivierung liegen sie unter `openspec/changes/archive/`.
|
||||
|
||||
## Zuordnung der acht PLAN-Punkte
|
||||
|
||||
| Phase-6-Planpunkt | Umsetzung | Endgültiger Nachweis |
|
||||
| --- | --- | --- |
|
||||
| Kompatibilitäts-Testsuite | 01, native Erweiterungen 02–04 | Korpus-/Native-Parität, 06/07 |
|
||||
| Plattformtests | 05 | Windows Terminal, Terminal.app, je zwei Linux-Emulatoren auf amd64 und arm64; 07 |
|
||||
| Performance-Pass nur falls nötig | 01 | Vergleichbare VM-Messung plus bestehende Compile-Budgets; finale Revision 07 |
|
||||
| Native Standalone-Executables | 02, IDE 04 | Start ohne Quellen/TBC/tb/tbc; entpackte Actions-Pakete 06/07 |
|
||||
| P-Code-Bibliotheken und Linker | 03, IDE 04 | Identische TBL mit separaten BASIC-Verbrauchern auf allen vier Zielen; Paketprüfung 06/07 |
|
||||
| Dokumentation und Beispiele | Fachbegleitend 02–06, Abschluss 07 | Ausgeführte Anleitungen, Help-/Link-/Offlineprüfung |
|
||||
| CI und Releases | 06 | Vier tatsächlich erfolgreiche Gitea-Zieljobs und geprüfte Archive |
|
||||
| Vollständigkeit des Inventars | Grundlage 01, endgültig 07 | Vollständiges aktuelles Sprach-/Forms-Inventar, null offen, korrekte Non-Feature-Fundstellen |
|
||||
|
||||
## Verbindliche Release-Matrix
|
||||
|
||||
| System | Architektur | Rust-Target | Archiv |
|
||||
| --- | --- | --- | --- |
|
||||
| Windows | amd64 | `x86_64-pc-windows-msvc` | `terminalbasic-<version>-windows-amd64.7z` |
|
||||
| macOS | arm64 | `aarch64-apple-darwin` | `terminalbasic-<version>-macos-arm64.tar.gz` |
|
||||
| Linux | amd64 | `x86_64-unknown-linux-gnu` | `terminalbasic-<version>-linux-amd64.tar.gz` |
|
||||
| Linux | arm64 | `aarch64-unknown-linux-gnu` | `terminalbasic-<version>-linux-arm64.tar.gz` |
|
||||
|
||||
Die Archive enthalten `tb`/`tbc` und die native Runtime-/Exportvorlage `tbrt`
|
||||
(Windows mit `.exe`) sowie Metadaten, Lizenz und Benutzungshinweise. Jedes fertige Archiv wird
|
||||
entpackt und auf seinem Ziel geprüft. Mindest-OS-/Systembibliotheksstände
|
||||
werden aus dem festgelegten tatsächlichen Builder und Zieltest dokumentiert.
|
||||
Standalone bedeutet keine separat installierte TB-Runtime; gewöhnliche
|
||||
Betriebssystembibliotheken und explizite OPEN-/RUN-Ressourcen bleiben benannt.
|
||||
|
||||
## Architekturentscheidungen und Abnahmegrenzen
|
||||
|
||||
- Vorhandene Sprache und TBVM bleiben erhalten. Die Native-Erzeugung verpackt
|
||||
Kompilat und Runtime, sie übersetzt BASIC nicht neu über LLVM/JIT.
|
||||
- Vorlagenbau findet in den passenden Actions statt; `make exe` beim Anwender
|
||||
benötigt keine C-/Rust-Compiler oder nativen Linker. Auch der TBL-Bau und P-Code-Linkpfad laufen allein mit TB-Tools. Verfügbarkeit eines Cross-Exports
|
||||
hängt von Vorlage und korrekter Finalisierung ab, nicht nur von einem Dropdown.
|
||||
- Mac-Nutzlasteinbau und Signierung werden vor Dateiveröffentlichung geprüft.
|
||||
Die bisherige pauschale Aussage über portables Anhängen allein ist kein
|
||||
Mach-O-Nachweis. [Apple Code Signing](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)
|
||||
- Gitea-Runner werden über eindeutige Ziel-Labels gebunden. Vier Workflowzeilen
|
||||
beweisen keine vier vorhandenen Maschinen. [Gitea Runner](https://docs.gitea.com/1.25/usage/actions/act-runner/)
|
||||
- Der Phase-5-Exportvertrag wird in 04 bedingt fortgeführt: Ohne Backend bleibt
|
||||
die verständliche Sperre geprüft, mit Backend muss wirkliche Dateierzeugung
|
||||
nachgewiesen werden. Beide MODIFIED-Blöcke erhalten alle bisherigen Szenarien.
|
||||
- Golden-Ausgaben, Inventareinträge und Non-Features dürfen nicht zur
|
||||
Ergebnisbeschönigung verändert werden. Fachfehler gehören in ihren
|
||||
bestehenden Implementierungspfad und erhalten eine Regression.
|
||||
- Fehlende externe Rechner, Emulatoren, Releasezugänge oder Fremdkorpora bleiben
|
||||
sichtbare Voraussetzungen. Nur lokale Headless-Prüfungen schließen Phase 6 nicht.
|
||||
|
||||
## Abnahmestrategie
|
||||
|
||||
Jeder Change liefert einen eigenen verification.md mit Spec-/Taskzuordnung,
|
||||
konkreten Befehlen, Revision, Resultaten und Grenzen. Für 02–06 werden außerdem
|
||||
native Ziel- beziehungsweise Actions-Nachweise benötigt. 07 prüft die gesamte
|
||||
Kette mit den finalen Paketen. PLAN-Checkboxen bleiben während des Proposals offen.
|
||||
Die jetzige Planung verändert keine Produktdateien, installiert keine Runner
|
||||
und veröffentlicht keine Artefakte.
|
||||
|
||||
## Bestätigter Library- und Linkvertrag
|
||||
|
||||
`.tbl` ist die festgelegte Extension für portable P-Code-Bibliotheken.
|
||||
Die Bezeichnung native Systembibliothek betrifft die eigentliche Runtime:
|
||||
Sie wird nativ kompiliert und ist Bestandteil von `tbrt`. Ein eigener
|
||||
C-ABI-/`.lib`-/`.a`-Export von BASIC ist nicht vorgesehen.
|
||||
|
||||
```text
|
||||
BASIC-Quellen ── tbc build --library ──► Bibliothek.tbl
|
||||
Hauptprojekt + Bibliothek.tbl ── tbc link ──► vollständiges Programm.tbc
|
||||
Programm.tbc + tbrt des Zielsystems ── Verpackung ──► natives Executable
|
||||
```
|
||||
|
||||
`tbc link --exe` verbindet beide letzten Schritte; `tbc build --exe` und
|
||||
Make EXE verwenden dieselben Dienste. `.MAK` hält die TBL-Verweise, damit
|
||||
auch IDE-Start/Check/Debugger dieselben Bibliotheken verwenden. Make Library
|
||||
bietet `.tbl` ohne native Zielwahl an. Library-Bau und Linken benötigen beim
|
||||
Anwender keinen C-/Rust-Compiler oder nativen Linker. Die EXE-Finalisierung
|
||||
prüft ihre dokumentierten Systemvoraussetzungen separat.
|
||||
|
||||
Der vorhandene Modul-Linkpfad wird erweitert; ein TBL enthält die dafür
|
||||
nötigen Deklarationen und unverknüpften Produkte. Native Runtime, P-Code und
|
||||
Formatversionen werden eindeutig getrennt. Initialisierung, COMMON, Forms,
|
||||
DATA und Fehlerorte werden mit entsprechenden Quellprojekten verglichen.
|
||||
|
||||
Alle sieben Changes enthalten Proposal, Design, Delta-Specs und prüfbare,
|
||||
noch offene Implementierungsaufgaben. Es besteht keine offene Formatentscheidung.
|
||||
Vollständige Planung bedeutet weiterhin keine umgesetzte Phase 6.
|
||||
|
||||
## Prüfung der Planung
|
||||
|
||||
Alle sieben Changes sind im OpenSpec-Planungsstatus vollständig und für
|
||||
die Umsetzung bereit: 75 offene Aufgaben, 33 Delta-Anforderungen.
|
||||
`openspec validate --all --strict --no-interactive` besteht mit 30 geprüften
|
||||
Specs/Changes. Relative Dokumentverweise und der Erhalt bestehender
|
||||
Szenarien in den MODIFIED-Blöcken wurden geprüft. Der Help-Katalogtest
|
||||
`catalog_links_and_missing_targets_are_checked` besteht mit dem geänderten
|
||||
PLAN. Phase 6 bleibt bei 0/8 abgeschlossenen Planpunkten; diese Prüfungen
|
||||
sind Planungs-/Dokumentationsnachweise, keine Implementierungsabnahme.
|
||||
@@ -0,0 +1,26 @@
|
||||
## Why
|
||||
|
||||
Phase 5 ist abgenommen, aber die Distribution benötigt einen reproduzierbaren Kompatibilitäts- und Leistungsnachweis. Bestehende Snapshot-, Fremdprogramm-, Inventar- und Benchmarkpfade liefern die Grundlage; ihre Zusammenführung und gezielte Ergänzung fehlen.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Einen dokumentierten Abnahmesatz aus vorhandenen Konsolen-, Forms-, Include-/Projekt- und Fehlerfällen mit deterministischen Eingaben, Zeiten, Größen und Dateieffekten festlegen und um belegte Lücken erweitern.
|
||||
- Den öffentlichen Fremdprogrammbestand mit festgelegter Revision ausdrücklich ausführen; fehlende Bereitstellung als fehlenden Nachweis behandeln.
|
||||
- Bestehende Compile- und VM-Benchmarks reproduzierbar messen; ausschließlich bei nachgewiesener Regression oder konkretem Engpass optimieren.
|
||||
- Inventarstand einschließlich Forms, Frontend-Absenkung und Ereignisauslöser als Ausgangsbasis dokumentieren. Finale Inventar-/Release-Abnahme liegt in 07.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `release-kompatibilitaet`: Reproduzierbarer Abnahmesatz und messbare Leistungsentscheidung für Phase 6.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
Keine. Die bestehenden Verträge aus `kompat-testkorpus`, `sprachinventar` und `bytecode-kompilat` bleiben erhalten.
|
||||
|
||||
## Impact
|
||||
|
||||
Betroffen sind `tests/compat/`, die vorhandenen CLI-Tests `compat.rs`, `foreign.rs`, `inventar.rs`, VM-Ereignistests und `crates/tb-vm/benches/{compile,vm}.rs`. Fachbefunde werden in ihrem bestehenden Implementierungspfad korrigiert; kein zweiter Korpus-Harness und keine pauschale VM-Neuschreibung.
|
||||
|
||||
Abhängigkeit: abgeschlossene Phase 5. Übergabe: benannte Fälle und Referenzresultate für 02–07. Die vollständige Planung steht in [Phase-6-Übersicht](phase-6-uebersicht.md).
|
||||
@@ -0,0 +1,33 @@
|
||||
## Purpose
|
||||
|
||||
Sichert die nachvollziehbare Kompatibilitäts- und Leistungsgrundlage für auslieferbare Terminal-Basic-Artefakte auf dem bestehenden Sprachstandard.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Deterministischer Abnahmesatz
|
||||
Die Release-Abnahme SHALL Konsolen-, Forms-, Mehrmodul-/Include-, Fehler- und Dateifälle mit ausdrücklich festgelegten Eingaben, Zeitverläufen, Bildschirmgrößen und Anfangsdateien prüfen. Sichtbare Zeichen, Attribute, Laufzeitresultat und relevante Dateieffekte SHALL mit unabhängig begründeten Sollwerten verglichen werden. Ein fehlender Sollwert MUST als fehlender Nachweis gelten und MUST NOT automatisch aus dem aktuellen Istwert entstehen.
|
||||
|
||||
#### Scenario: Wiederholter Formularlauf
|
||||
- **WHEN** ein Formularfall mit Fokuswechsel, Maus, Menü und Größenänderung zweimal ausgeführt wird
|
||||
- **THEN** stimmen beide Läufe mit denselben Sollzuständen überein und eine Änderung nur am Farbattribut lässt die Prüfung fehlschlagen
|
||||
|
||||
### Requirement: Expliziter Fremdprogrammnachweis
|
||||
Die Release-Abnahme SHALL den verwendeten öffentlichen Fremdprogrammbestand mit unveränderlicher Revision, Einstieg, Eingabefolge und sichtbarem Resultat benennen und prüfen. Ein fehlender oder falscher Bestand MUST den erforderlichen Nachweis als fehlend melden; ein ignorierter optionaler Entwicklertest SHALL keinen erfolgreichen Release-Nachweis ersetzen.
|
||||
|
||||
#### Scenario: Referenzbestand fehlt
|
||||
- **WHEN** die Release-Abnahme ohne den vereinbarten Fremdprogrammbestand gestartet wird
|
||||
- **THEN** scheitert der erforderliche Fremdprogrammnachweis mit Benennung der fehlenden Voraussetzung
|
||||
|
||||
### Requirement: Begründete Leistungsentscheidung
|
||||
Die bestehenden Compile-Budgets von unter 50 ms für das Referenzmodul und unter 1 s für das Referenzprojekt SHALL im Release-Profil eingehalten werden. Der VM-Durchsatz SHALL für die vorhandenen Schleifen-, Aufruf- und Stringlasten mit Hardware, Revision, Profil und Verfahren gemessen werden. Optimierung SHALL einen gemessenen Engpass oder eine reproduzierbare Regression voraussetzen und danach dieselben Semantikprüfungen bestehen.
|
||||
|
||||
#### Scenario: Kein Optimierungsbedarf
|
||||
- **WHEN** Compile-Budgets bestehen und auf demselben Rechner kein reproduzierbarer VM-Rückschritt gegenüber dem dokumentierten Vergleichsstand vorliegt
|
||||
- **THEN** wird der Performance-Pass mit Messwerten und der begründeten Entscheidung abgeschlossen, den VM-Code unverändert zu lassen
|
||||
|
||||
### Requirement: Nachvollziehbare Befundbehandlung
|
||||
Abweichungen SHALL mit Sollquelle, Istverhalten und zuständigem Fachbereich dokumentiert und dort behoben werden. Geänderte Erwartungen SHALL durch den geltenden Vertrag begründet sein. Die Abnahme MUST NOT Anforderungen, Fälle oder Inventareinträge entfernen, um ein grünes Ergebnis zu erzielen.
|
||||
|
||||
#### Scenario: Snapshot weicht ab
|
||||
- **WHEN** ein bestehender Fall nach einer Fachänderung eine andere Ausgabe erzeugt
|
||||
- **THEN** nennt der Bericht die erste Abweichung und begründet Korrektur beziehungsweise zulässige Solländerung vor erneutem Prüfen
|
||||
@@ -0,0 +1,17 @@
|
||||
## 1. Kompatibilitätsnachweise
|
||||
|
||||
- [ ] 1.1 Bestehende Fälle aus compat.rs, foreign.rs, inventar.rs, events.rs und IDE-Abnahme einer dokumentierten Release-Matrix zuordnen; jede vereinbarte Verhaltensgruppe muss konkrete Fallnamen und einen ausführbaren Aufruf besitzen.
|
||||
- [ ] 1.2 Fehlende kombinierte Zeichen-/Attribut-/Resize- und Formularübergänge im vorhandenen Korpus ergänzen; wiederholte Läufe sowie absichtlich falsche Zeichen-/Attributerwartungen müssen die Vergleichsqualität belegen.
|
||||
- [ ] 1.3 Projekt-/Include-, Fehler- und Dateifälle mit festgelegtem Anfangszustand und Dateieffekten vervollständigen; gezielte Tests müssen Diagnosen und saubere temporäre Verzeichnisse prüfen.
|
||||
- [ ] 1.4 Öffentlichen Bestand in festgelegter Revision bereitstellen und den vorhandenen foreign-Test ausdrücklich ausführen; falsche/fehlende Revision muss den erforderlichen Abnahmepfad scheitern lassen.
|
||||
|
||||
## 2. Inventar und Leistung
|
||||
|
||||
- [ ] 2.1 Aktuelle Sprach- und Forms-Inventarsummen mit Quelllisten, Absenkungsproben und Ereignistests prüfen; Bericht muss alle Statusgruppen getrennt und offene Einträge namentlich ausweisen.
|
||||
- [ ] 2.2 Vorhandene Compile-/VM-Benchmarks im Release-Profil messen und mit reproduzierbarem Vergleichsstand einordnen; Hardware, Revision, Verfahren und beide Compile-Budgets im Bericht festhalten.
|
||||
- [ ] 2.3 Nur bei nachgewiesenem Engpass eine gezielte Fachkorrektur umsetzen und denselben Semantik-/Leistungsnachweis wiederholen; andernfalls „kein Optimierungsbedarf“ mit Messbegründung dokumentieren.
|
||||
|
||||
## 3. Übergabe
|
||||
|
||||
- [ ] 3.1 Gefundene Fachabweichungen vollständig beheben; betroffene Korpus-, Inventar- und Ereignistests müssen unveränderte Verträge bestätigen, ohne Golden-Dateien pauschal neu zu generieren.
|
||||
- [ ] 3.2 Abnahmesatz und Ergebnisse für native Artefakte und CI dokumentieren; Workspace-Tests, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, externe Voraussetzungen bleiben ausdrücklich sichtbar.
|
||||
Reference in New Issue
Block a user