## 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"