TLS-Gate v3.11.1: Seite „Bestand“ als Klick-Dummy, v3.11.0 in der VM nachgewiesen

Von: Branko → OZMAI
Stand: 8. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STAND + NACHTRAG. Setzt 2026-10-08_TLS-GATE-V3-11-0-REGISTRAR-BESTAND-IN-DER-DB-NACHTRAG_BRANKO.md fort. Ersetzt zwei Aussagen dieser Datei: (1) „VM-Suiten nicht neu gelaufen; p5.sh erwartet jetzt 19 Tabellen, ungeprüft“ — siehe §2, die Aussage war unvollständig, sync lief in der VM gar nicht; (2) „Order-Pool als möglicher Begriff für v3.11.1“ — v3.11.1 ist stattdessen die Seite „Bestand“, der Order-Pool bleibt ⬜ für eine spätere Version.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org). Tag v3.11.1 = Commit b35a3f8 (Inhalt 53d8441 VM, b71300f Seite; Vorgänger v3.11.0 = e727611).
Belege: tests/test_inventory.sh (63), alle lokalen Suiten grün; VM gegen MariaDB run.sh 86, p3 48, p4 54, p5 31, p6 22, p7 37 (neu).

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs. Tests nur mit synthetischen Daten (example.test) und dem Fake-Registrar der VM.

1. Seite „Bestand“ (`bestand.php`)

🧪 Lesen ab readonly, nur Gruppen vom Typ eigen. Der Spiegel kommt aus der DB, nicht vom Registrar. Sortierbar (Order, Domain, Status, gültig bis, gesehen seit), Filter nach Status, Suche in Order/Domain, „auch verschwundene“.
🧪 NEU-Markierung: Orders, die nach dem Erstabgleich aufgetaucht sind (es gibt ein new-Ereignis), sind markiert. Brankos Ziel: die neue Order-ID direkt sehen und dann in die Bash wechseln.
🧪 Human Loop: je Zeile der Befehl soap_cli.php info <order> zum Kopieren.
🧪 „Aktualisieren“ ab user: holt sslListExtended live und gleicht mit denselben Schutzregeln wie die CLI ab (--force nur in der CLI). Höchstens alle 5 Minuten je Zugang, sonst gilt der Spiegel. Audit ssl.inventory_sync. Nie Beispieldaten.
🧪 Unbekannte Produkt-ID: „(nicht im Katalog)“ statt automatischer Anlage. Darunter die letzten 15 Änderungen.

2. Befund beim Nachweis in der VM

✅ sync lief in der VM gar nicht. Die VM bekommt ihren Code aus dem Spiegel native_php/, und dort fehlten Inventory, inventory_cli.php und das Schema 0005. Die Migration selbst kam an (Version 5), der Code nicht. Behoben in 53d8441.
✅ Der Doktor zählte weiter 17 Tabellen: die Tabellenliste ist dort fest hinterlegt. Die Anpassung nur in p5.sh hätte die Suite rot gemacht, nicht den Doktor geprüft. Behoben.
🧪 Neue Suite p7 (37): sync live gegen den Fake-Registrar mit dem DML-Benutzer der Instanz, load, Append-only-Trigger, Schutzregeln, Klickpfad mit Anmeldung, Pause, Aktualisieren, POST ohne CSRF (403, kein Abgleich). Dreimal hintereinander grün.
Eine Änderung am Fake-Registrar (tagesgenaue Zeiten) hat Branko verworfen: Test-Artefakt, die Bash bekommt ohnehin eine neue Variante. p7 prüft deshalb beim zweiten Abgleich nur „nichts neu, nichts weg“, weil der Fake seine Zeiten aus der Uhr rechnet.

3. Was NICHT belegt ist

❓ Abgleich mit dem echten Bestand (mehr als 600 Zeilen) über das Web: Laufzeit und Statuswerte. Vorgesehen für den 9.10. mit echtem SOAP-Zugang, als erstes sync --dry-run.
❓ Rollen user und readonly im Klickpfad der VM nicht durchgeklickt (nur Modell und Markup lokal). Browser-Optik nicht geprüft.

4. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Grüne Host-Tests und eine angewandte Migration sagten nichts darüber, ob der Code auf der Node ankommt. Erst der Klick- und CLI-Pfad in der VM zeigte, dass die Schema-Version 5 vermerkt war, die Funktion aber fehlte: Version vermerkt ≠ Funktion vorhanden. Ebenso prüfte die angepasste Erwartung im Test nicht den Prüfer (Doktor) selbst.

5. Offen (DESIGN_INTENT aus dem v3.11.0-Eintrag, unverändert)