TerminalBasic/openspec/changes/archive/2026-09-04-phase-3-runtime-bildschirm/specs/sprachinventar/spec.md

Purpose

Das Sprachinventar ist das Messinstrument für die Leitplanke „Vollständigkeit ist das Soll": eine gepflegte Liste aller in der Original-Hilfe des Vorbilds dokumentierten Anweisungen, Funktionen und Metabefehle mit Abdeckungsstatus, gegen die sich der Implementierungsstand jederzeit prüfen lässt.

ADDED Requirements

Requirement: Vollständiges Inventar der Original-Hilfe

docs/inventar.md SHALL jede in der Original-Hilfe des Vorbilds dokumentierte Anweisung, Funktion, Metabefehl, Operator-Schlüsselwort und Klausel als eigenen Eintrag führen. Ein dokumentiertes Element MUST NOT fehlen; Vollständigkeit gegenüber der Quelle geht der Kürze vor. Jeder Eintrag SHALL Name, Art (Anweisung/Funktion/Metabefehl), Themengruppe, Status und Fundstelle tragen.

Scenario: Dokumentiertes Element ist erfasst

• WHEN die Original-Hilfe die Anweisung VIEW PRINT dokumentiert
• THEN enthält das Inventar einen Eintrag VIEW PRINT mit Art, Gruppe, Status und Fundstelle

Scenario: Non-Feature ist erfasst, nicht weggelassen

• WHEN PEEK als Non-Feature deklariert ist
• THEN steht PEEK mit Status Non-Feature im Inventar und die Fundstelle verweist auf den Abschnitt „Abweichungen" der Sprachreferenz

Requirement: Festes Statusvokabular

Der Status eines Eintrags SHALL genau einen von drei Werten tragen: implementiert (Frontend senkt ab und die Laufzeit führt aus), offen (dokumentiert, noch nicht verfügbar) oder Non-Feature (vom Projektinhaber abgelehnt und in der Sprachreferenz unter „Abweichungen" gelistet). Ein Eintrag mit Status Non-Feature MUST eine Fundstelle in der Sprachreferenz nennen.

Scenario: Unzulässiger Status

• WHEN ein Eintrag den Status teilweise trägt
• THEN schlägt die Inventarprüfung mit Nennung des Eintrags fehl

Scenario: Non-Feature ohne Fundstelle

• WHEN ein Eintrag den Status Non-Feature trägt, aber keine Fundstelle nennt
• THEN schlägt die Inventarprüfung mit Nennung des Eintrags fehl

Requirement: Automatischer Abgleich Inventar gegen Implementierung

Ein automatischer Test SHALL das Inventar gegen den tatsächlichen Implementierungsstand prüfen und bei jeder Divergenz fehlschlagen. Als implementiert markierte Elemente MUST im Frontend eine Signatur besitzen und MUST NOT auf einen „nicht verfügbar"-Marker absenken; als offen markierte Elemente MUST auf einen solchen Marker absenken oder ohne Signatur sein; als Non-Feature markierte Elemente MUST zur Compile-Zeit mit „Feature unavailable" abgewiesen werden. Der Test MUST das divergierende Element, seinen Inventarstatus und den vorgefundenen Zustand benennen.

Scenario: Inventar hinkt der Implementierung hinterher

• WHEN LOCATE implementiert wurde, im Inventar aber noch offen steht
• THEN schlägt der Abgleich fehl und nennt LOCATE, Status offen und den Befund „implementiert"

Scenario: Inventar behauptet zu viel

• WHEN ein Eintrag implementiert trägt, das Element aber weiterhin auf den „nicht verfügbar"-Marker absenkt
• THEN schlägt der Abgleich fehl und nennt das Element

Scenario: Abdeckungsstand ist abrufbar

• WHEN der Abgleich läuft
• THEN nennt er die Zahl der Einträge je Status als Abdeckungsstand

Requirement: Keine stillen Lücken bei dokumentierten Elementen

Ein Element mit Status offen MUST bei Verwendung eine benannte Ablehnung erzeugen — entweder eine Compile-Diagnose oder den Laufzeitfehler für nicht verfügbare Funktionen —, die das Element namentlich nennt. Ein generischer Syntaxfehler oder „unbekannter Bezeichner" für ein dokumentiertes Element MUST NOT auftreten (Guiding Principle).

Scenario: Offenes Element wird namentlich abgewiesen

• WHEN ein Programm eine im Inventar als offen geführte Anweisung verwendet
• THEN nennt die Ablehnung den Namen der Anweisung, nicht nur „Syntaxfehler"