TLS-Gate v3.15.0, Rückmeldung zur OZMAI-Antwort auf v3.13.0

Von: Branko → OZMAI, Crew
Stand: 11. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG + RÜCKMELDUNG zu 2026-10-11_ANTWORT-OZMAI_TLS-GATE-V3-13-0.md.
Ersetzt zwei Aussagen:
(1) In 2026-10-11_TLS-GATE-V3-13-0-AKTIVIEREN-DURCH-DIE-USER-BELEGT-NACHTRAG_BRANKO.md §2: „ANNOUNCED_INTERACTION = IMPLEMENTED_INTERACTION für booking.activate auf 00bad35“ → zu stark, enger gefasst in §1 unten.
(2) In 2026-10-11_TLS-GATE-NETBOX-CONNECTOR-SCHRITT-1-BIS-3-NACHTRAG_BRANKO.md: „main 949d114, ohne eigenen Tag“ → Tag v3.15.0 = 8b05cba (Inhalt 949d114 + §3 unten).
Quelle: Repo TLS-Gate-Mock-Pipeline, Tag v3.15.0 = 8b05cba (Vorgänger v3.14.0 = e494a87).
Belege: lokal 37 von 37 Suiten grün (test_stammdaten 35, test_inventory 72, test_netbox 56). VM nach docker_vm/build.sh aus genau 8b05cba (dirty=0, ozm01 bis ozm03): run 91, p3 48, p4 54, p5 31, p6 22, p7 53, p8 23.

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

1. Zu OZMAI §1: Aktivierung, enger gefasst

Einverstanden. Der Gegenfall vom 10.10. bleibt für seinen Stand richtig: Gemeldet war „aktiviert“, im Audit stand kein booking.activate, und es gab keinen Knopf. Der Erfolg vom 11.10. ist eine neue Feststellung unter geändertem Code, kein Nachweis für den alten Bericht. Statt der allgemeinen Gleichheit gilt für diesen Prüffall nur:

IMPLEMENTED(booking.activate, build=00bad35)
INVOKED(booking.activate, demo-scope: drei Demo-Konten auf ozm03)
PERSISTED_STATE = active

Audit und gespeicherter Zustand stammen aus demselben System und sind deshalb keine unabhängigen Zeugen.

2. Zu OZMAI §2: Commit-Stempel ≠ Artefakt

Einverstanden: SOURCE_COMMIT_IDENTIFIED ⇏ EXECUTED_ARTIFACT_IDENTIFIED. Der Image-Digest bleibt bewusst nicht gebaut, bis ein Befund ihn braucht. Ein unbekannt im Live-Audit wäre ein Befund, kein kosmetischer Fehler.

3. Zu OZMAI §3: Reduktion nur so weit wie bestätigt (gebaut)

  • 🧪 Der Schlüssel gilt nur noch für die bestätigte Form: SSL-<n> und <n> werden zu <n>. ssl-4 (Kleinschreibung) und SSL-04 (führende Null) waren eine Regel des Entwicklers ohne Bestätigung durch den Provider und bleiben jetzt wie geliefert. Der gelieferte Wert wird weiterhin nie überschrieben (EQUIVALENT_FOR(catalog_lookup) ⇏ SOURCE_TEXT_IDENTICAL).
  • 🧪 Der Grund einer Abweichung steht jetzt in der Ausgabe, genau für den Prüfschritt, den OZMAI vorschlägt: ABWEICHUNG im Abgleich und inventory_cli.php status (unbekannt_grund) unterscheiden
  • kein_katalogeintrag: Die Form ist SSL-<n>, aber kein Produkt trägt <n>. Ist die Produktliste importiert?
  • form_nicht_normalisiert: Die Form ist nicht bestätigt und wird so verglichen, wie sie geliefert wurde.
  • ⬜ Ablauf des Dry-Runs in der VPN-Umgebung (Branko): Produktliste importieren (catalog_cli.php import-products), dann soap_cli.php sync --dry-run. Erwartung: SSL-4/SSL-80 erscheinen nicht mehr als Abweichung. Bleiben sie stehen, nennt die Ausgabe, ob der Katalogeintrag fehlt oder die Normalisierung nicht trägt. Im Audit steht ctx.build = 8b05cba1cf25, sofern die Live-VM mit build.sh gebaut ist.

4. Zu OZMAI §4: MFA bleibt offen

⬜ Unverändert: Passwort + TOTP ⇏ unabhängig etablierte zwei Faktoren, solange qr die Bindung nach der Passwortprüfung selbst erzeugt. Die Entscheidung liegt bei der Crew.

5. Neu in v3.15.0 (Verweis)

Der NetBox-Connector je Gruppe (Schritt 1–3, Regel b, MAC als beobachtete Tatsache) ist in 2026-10-11_TLS-GATE-NETBOX-CONNECTOR-SCHRITT-1-BIS-3-NACHTRAG_BRANKO.md beschrieben und jetzt Teil des Tags.

6. Hinweis zur Ablage

Die OZMAI-Antworten vom 10. und 11.10. (2026-10-10_ANTWORT-OZMAI_*, 2026-10-11_ANTWORT-OZMAI_TLS-GATE-V3-13-0.md) liegen in der Arbeitskopie, sind aber nicht committet. Der Entwickler hat sie nicht eingecheckt, weil sie nicht von ihm stammen.