TLS-Gate: Seite „Stammdaten“ und Matrix-Abgleich — Brankos Produktmatrix 17 von 17 am Mockup bestätigt

Von: Branko → OZMAI, Crew
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-1-SEITE-BESTAND-KLICK-DUMMY-NACHTRAG_BRANKO.md fort. Ersetzt keine frühere Aussage.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org), main nach Tag v3.11.1, ohne eigenen Tag: 4769eda (Test-Fix), 2199256 (Beispielbestand), 2094358 (Seite Stammdaten), 0534761 (Matrix-Abgleich, Demo-Mockup).
Belege: lokal alle Suiten grün, neu tests/test_stammdaten.sh (32) und tests/test_matrix_mockup.sh (20); VM gegen MariaDB auf frischen Volumes run.sh 86, p3 48, p4 54, p5 31, p6 22, p7 44.

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

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs. Alle Demo-Daten sind synthetisch (example.test, *.test).

1. Anlass

Branko (8.10.): „wir drehen uns im Kreis, ich vermisse immer noch das Mockup, was den Test bestätigt.“ Grüne Suiten zeigten Regeln, aber keine Seite zeigte, dass seine Matrix abgebildet ist. Darauf wurde hin gebaut.

2. Was gebaut ist

• 🧪 Seite „Stammdaten“ (stammdaten.php), ab Rolle group_admin, nur lesen:
• Matrix-Abgleich ganz oben: jede Zeile der Matrix mit ✓/✗ — Produkt im Katalog, Kategorie zugeordnet, aktive Buchung in der Gruppe (von wem), Abrechnung.
• Prüfungen: Produkte ohne Kategorie, SSL ohne Registrar-ID, Bestand ohne Katalog, Personen ohne Buchung.
• Produkte mit Kategorien und „eingerechnet“ je Rolle: Admin = Kategorie der Achse access ohne Preis (Bereitschaft); User = Kategorie mit Preis, sonst „nicht buchbar“.
• Bestand ↔ Katalog: Produkt-IDs aus dem Registrar-Bestand ohne Katalogeintrag, mit Zeilenzahl und Kandidat aus der Registrar-Produktliste — mit Fragezeichen.
• Buchungen je Person als Baum (Grundprodukt → Zusätze), Systemakte nur als „hinterlegt“.
• ✅ database/matrix_branko.txt: Brankos Liste wörtlich (17 Zeilen, - <Produkt> #<Kategorie>). Die Seite prüft gegen genau diese Datei.
• ✅ database/produktliste_registrar.json: die 131 Einträge der Produkt-Auswahlliste der Registrar-Konsole (ID, Name, Laufzeit). Keine Kundendaten. Nur Referenz, legt nichts an.
• 🧪 bin/demo_matrix.sh <gruppe> [--vm <instanz>]: Demo-Mockup. Katalog, Beispiel-Import (database/demo/stammdaten_beispiel.sql: PositiveSSL 1 Jahr SSL-4, Wildcard 1 Jahr SSL-80), Freigaben aller Produkte, zwei Demo-User, 18 Buchungen über booking_cli.php — also durch alle Buchungsregeln —, als Inhaber aktiviert, Beispielbestand (12 synthetische Zeilen) an einem abgeschalteten Zugang.
• 🧪 inventory_cli.php load nimmt auch einen abgeschalteten Zugang (beim Laden aus Datei läuft kein SOAP-Aufruf).

3. Ergebnis am Mockup

• 🧪 Lokal (SQLite) und in der VM auf der Klicktest-Instanz (MariaDB) gleich: 17 von 17, PHP-Fehlerlog leer.
• 🧪 Gegenproben (der Abgleich kann rot werden): Gruppe ohne Buchungen → 0 bestätigt; falsche Kategorie, unbekanntes Produkt, nicht zugelassene Kategorie → offen; eine beendete Buchung zählt nicht mehr.
• Aufteilung im Mockup (Annahme des Entwicklers, nicht Vorgabe): Admin VM Small #admin → Postgres, VPN, Gitea, SSL; User 01 VM Small #proxmox → Storage, Backup, Monitoring, SSL #hosting, Support, Audit, Claude, dazu Server #baremetal; User 02 Hosting #managed → Managed #hosting, dazu Cluster #HA, RPI zero #container.

4. Nebenbefunde

• ✅ Frische Volumes: p4 war rot, weil neue Gruppen seit v3.7.0 mit MFA qr starten; auf alten Volumes stand die Testgruppe noch auf code. Test korrigiert (4769eda), Code unverändert.
• ✅ Docker-Desktop-Platte schreibgeschützt während eines Laufs (fdatasync() returned 5, emergency_ro): MariaDB fiel aus. Ursache im Host, nicht im Code; behoben durch Neustart von Docker Desktop, danach Build-Cache (~28 GB) aufgeräumt.

5. Was NICHT belegt ist

• ❓ Ob SSL-4 aus sslListExtended der ID 4 der Produktliste entspricht. Die Seite zeigt es als Kandidat mit Fragezeichen.
• ❓ Die Matrix am echten Bestand: Der erste echte Import ist für den 9.10. vorgesehen (Branko prüft selbst; Live-Ausgaben werden nicht weitergegeben).
• ⬜ Bearbeiten in der Oberfläche (Verknüpfen bleibt SQL-Import), Instanz ozm00 mit Admin an der Wurzel und lesendem NetBox-Zugriff, Order-Pool, Cron-JSON je Gruppe.

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

Eine Vorgabe ist erst bestätigt, wenn sie als Vorgabe geprüft wird — wörtlich als Datei, Zeile für Zeile gegen den Stand, mit Gegenproben, die rot werden können. Viele grüne Regeltests ergaben zusammen noch keine Aussage über die Matrix. Grüne Regeln ≠ bestätigte Vorgabe. Die Aufteilung der Buchungen auf Personen bleibt Mockup und ist keine Festlegung.