TLS-Gate v3.11.0: Registrar-Bestand als Lesespiegel in der DB, danach nur Änderungen

Von: Branko → OZMAI
Stand: 8. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STAND + DESIGN_INTENT. Setzt 2026-10-07_TLS-GATE-V3-10-1-ADMIN-DIENSTE-NICHT-IM-USER-DASHBOARD-NACHTRAG_BRANKO.md fort. Ersetzt keine frühere Aussage.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org). Tag v3.11.0 = Commit e727611 (Vorgänger v3.10.1 = 43b7ab2).
Belege: tests/test_inventory.sh (44), alle lokalen Suiten grün; MariaDB von Hand geprüft (Migration 1–5, Baseline, Änderung, Append-only-Trigger).

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

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs. Die Tests nutzen nur synthetische Daten (example.test); der echte Bestand (mehr als 600 Datensätze) liegt nie im Repo.

1. Was gebaut ist

  • 🧪 Tabellen: registrar_inventory (eine Zeile je SOAP-Zugang, Order und Domain, denn eine Order kann mehrere Domains tragen) und registrar_inventory_events (append-only: baseline, new, changed mit alt→neu je Feld, gone, back). Migration 0005 nur MariaDB.
  • 🧪 Abgleich: soap_cli.php sync [--dry-run] [--force] (live) und inventory_cli.php load <datei|-> (gespeicherte Ausgabe von soap_cli.php list), dazu status, events. Der erste Lauf je Zugang ist die Baseline (ein Ereignis mit Anzahl), danach stehen nur Änderungen im Protokoll. Eine Transaktion, Audit cli.inventory_sync.
  • 🧪 Fail closed: nur source soap (mock nur mit --allow-mock, unavailable nie); Liste ab 2000 Zeilen gilt als abgeschnitten und wird auch mit --force abgelehnt; leere Liste oder mehr als die Hälfte weg (ab 10 vorhandenen Zeilen) nur mit --force; eine ungültige oder doppelte Zeile bricht alles ab. Vier dieser Regeln sind mutationsgetestet (je rot ohne die Regel).
  • 🧪 Abweichung statt Automatik: Ein productId ohne passendes products.registrar_ref wird als ABWEICHUNG gemeldet und nie angelegt. Sonderprodukte, Stammdaten und Verknüpfungen pflegt der Mensch per SQL-Import (Branko: „abweichende Bestellungen müssen manuell eingearbeitet werden … audit“).
  • ✅ Das Bestandssystem bleibt führend; TLS-Gate schreibt hier nichts zum Registrar zurück.

2. Was NICHT belegt ist

  • ❓ Die Statuswerte zertifizierung_laeuft und ssl_ok stammen aus einem von Branko eingefügten Beispiel mit fünf Zeilen. Die echte Liste kann weitere Werte oder Felder haben.
  • ❓ sync lief nur in Tests (ohne Live-SOAP) und nie gegen den echten Bestand. Für den ersten echten Lauf ist --dry-run vorgesehen.
  • ❓ Die VM-Suiten (docker_vm/tests/run.sh) sind für v3.11.0 nicht neu gelaufen; p5.sh erwartet jetzt 19 Tabellen (vorher 17), das ist ungeprüft. MySQL-8-Pfad der Migrationen weiterhin ungetestet.

3. DESIGN_INTENT (Branko, 8.10., nicht gebaut, nicht von der Crew bestätigt)

Aus Brankos Beschreibung, sinngemäß zusammengefasst:

  • ⬜ Arbeiten mit der Order-ID aus dem eigenen Bestand, ohne bei jedem Aufruf die ganze Liste vorab zu laden. In der Oberfläche soll die neue Order-ID mit Sortierung angezeigt werden, um danach in die Bash zu wechseln (Human-Loop-Test).
  • ⬜ Entscheidungen aus der DB, auch per Cron: alles, was die DB vorhält, muss nicht erneut beim Registrar abgefragt werden.
  • ⬜ „Order-Pool“ als möglicher neuer Begriff für v3.11.1 (Arbeitsbegriff, nicht definiert), dazu eine Tabelle, die die Zertifizierung überwacht (DCV, CNAME bei Comodo/Sectigo usw.). Ihr Stand soll an die Bash übergeben bzw. gepiped werden können und wäre die Grundlage eines sinnvollen Dashboards.
  • ⬜ Cron je SOAP-Gruppe: das JSON zusätzlich im Dateisystem halten und nur dann in die DB übernehmen, wenn es sich geändert hat. Admin und User bekommen den letzten Spiegel aus der DB oder fordern eine Aktualisierung an.
  • ⬜ Ziel: lokal und offline tragbar (Crumbforest, Maschine), weniger Zugriffe auf den Registrar, damit weniger Zeit, Energie und Kosten.
  • ⬜ Reihenfolge laut Branko: zuerst Bestand in die DB (v3.11.0); danach Verknüpfung mit Stammdaten für Lesesicht (User) und Schreibsicht (Admin); neue Bestellungen bleiben im Bestandssystem. Abweichungen von der Regel werden singulär geloggt und an die Crew „resoniert“ (Benachrichtigung ist nicht gebaut).

Offene Fragen, die ich als Entwickler sehe (keine Festlegung): Was die Sicht von User und Admin auf den Spiegel im Datenschutz-Sinn zeigen darf (Bestandszeilen sind Kundendaten); ob „Aktualisierung anfordern“ ein Rate-Limit braucht; wo die JSON-Ablage je Gruppe liegt und mit welchen Rechten.

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

Ein Spiegel ist eine Aussage über den Stand zu einem Zeitpunkt, nicht über den heutigen. last_seen_at hält fest, wann zuletzt gesehen wurde, und der Abgleich verweigert, eine halbe Antwort als „alles weg“ zu lesen. Wiederholung ist keine Bestätigung: ein unveränderter Lauf schreibt kein Ereignis, nur last_seen_at. Ob eine gespiegelte Zeile später als Geltung für eine Entscheidung taugt, ist offen.