TLS-Gate: User-Test auf ozm03, Knopf „aktivieren“ nachgebaut; RĂŒckmeldung zur OZMAI-Antwort; HTTP 402 als nĂ€chstes Interface (Vorhaben)

Von: Branko → OZMAI, Crew
Stand: 10. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG + RÜCKMELDUNG zu 2026-10-10_ANTWORT-OZMAI_CRUMBFOREST-LOGIN-031200.md und 2026-10-09_TLS-GATE-CRUMBFOREST-LOGIN-031200-STATEMENT_BRANKO.md.
Ersetzt eine Aussage in 2026-10-09_TLS-GATE-AUDIT-ABLEHNUNGEN-MIT-VERSUCH-UND-CRUMBFOREST-LOGIN-GEBUCHT-NACHTRAG_BRANKO.md §3: „Das Aktivieren durch den jeweiligen User im Dashboard ist der nĂ€chste Klicktest“ → im Dashboard gab es dafĂŒr keinen Knopf; jetzt gebaut. Löst das ❓ „alle Orders freigeben“ auf: gemeint waren die Katalogprodukte (Branko, 9.10.).
Quelle: Repo TLS-Gate-Mock-Pipeline, main 16ee534, ohne eigenen Tag (OZMAI §2: Stand genau benannt, nicht „3.12.0“).
Belege: lokal alle Suiten grĂŒn, tests/test_katalog.sh 111; VM run 87, p3 48, p4 54, p5 31, p6 22, p7 50.

Legende: ✅ real/gebaut · đŸ§Ș gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

1. User-Test auf ozm03 (DEMO)

  • ✅ Branko meldete beide Demo-User als „aktiviert“. Das Audit von ozm03 zeigt: Anmeldung, TOTP-Einrichtung per QR, eine Konsolenabfrage (mock). Kein booking.activate, die drei Buchungen fĂŒr Crumbforest Login stehen weiter auf offered.
  • Ursache: Das Dashboard war reine Lesesicht, einen Knopf zum Aktivieren gab es nicht. Der Entwickler hatte ihn trotzdem angekĂŒndigt — Fehler des Entwicklers.
  • đŸ§Ș Gebaut: Im eigenen Baum unter „Meine Buchungen“ trĂ€gt eine freigeschaltete Buchung den Knopf „aktivieren“ (POST + CSRF, Bookings::activate, Audit booking.activate). Nur der Inhaber, nur aus offered. Ablehnungen (nur_inhaber, zustand) stehen im Audit. Sonst bleibt das Dashboard lesend.
  • Der bewusst offene Prozess (offered bis zur Aktivierung) gehört laut Branko in den Monitor. ⬜ MonitorExport kennt heute nur Zertifikate, keine Buchungen. Monitor kommt laut Branko zuletzt.

2. Live-Lauf vom 9.10. (ATTESTED_BY_BRANKO, Auszug aus seinem Audit, Domains von ihm maskiert)

Nur Zahlen und Ereignisarten, keine Domains, keine Order-Nummern:

  • ssl.inventory_sync Baseline: 587 Zeilen. Zweiter Lauf: neu 3, geĂ€ndert 1, weg 0, gleich 586.
  • Beide LĂ€ufe melden unbekannte_produkte: SSL-4, SSL-80 — der Katalog der Live-Instanz kennt diese Produkt-IDs des Bestands nicht. ❓ Ob dort vorher die Produktliste importiert wurde, ist nicht bekannt; die Frage „SSL-4 = ID 4 der Produktliste?“ bleibt offen, gewinnt aber an Gewicht.
  • ssl.orderCert zweimal accepted: Die SOAP-Antwort trĂ€gt die neue Order-Nummer und returnCode 1001 im Audit-Kontext. Damit ist die v3.6.1-Frage („liefert die API live eine neue Order-ID?“) jetzt durch einen maskierten Auditauszug gestĂŒtzt — Evidenzklasse bleibt ATTESTED_BY_BRANKO.
  • ssl.deployZip zweimal ok mit PrĂŒfsumme und chain: true.
  • Jede Anmeldung der Live-Admin-Gruppe erzeugt auth.mfa_enroll (Passwort → neues TOTP). Das ist der MFA-Modus qr — siehe §3 zu OZMAI §7.
  • Stand des Live-Laufs war v3.11.1 (laut Migration Version 5), nicht 16ee534.

3. RĂŒckmeldung zu den Punkten der OZMAI-Antwort (Entwickler + Branko, keine OZMAI-Geltung)

  • §1 Matrix: einverstanden mit TESTED_IMPLEMENTATION_AGAINST(named_requirement_artifact). Der Matrix-Abgleich prĂŒft Code gegen Datei, nicht die Absicht dahinter.
  • §2 Versionslabel: Dieser Eintrag nennt den genauen Commit. ⬜ Vorschlag: Commit-Stand beim Image-Bau festhalten und bei SOAP-Aktionen im Audit-Kontext mitschreiben, damit „welcher Stand lief“ im PrĂŒfbeleg selbst steht. Nicht gebaut.
  • §3 Beobachtungslauf: Ja — jeder Abgleich-Lauf schreibt einen Audit-Eintrag (Web ssl.inventory_sync, CLI cli.inventory_sync), auch ohne Änderung (gleich: N), TrockenlĂ€ufe (dry_run), abgelehnte Listen (rejected mit Grund, z. B. abgeschnitten/leer/Quelle) und gebremste LĂ€ufe (denied, rate_limit). Die Folge der LĂ€ufe bleibt damit im Audit erhalten, nicht nur last_seen_at. Der Satz „Ein Lauf ohne Änderung bestĂ€tigt nichts neu“ war zu stark: Er erzeugt kein Änderungsereignis, ist aber als Lauf belegt (NO_CHANGE_EVENT ⇏ NO_SYNC_RUN).
  • §4/§5: einverstanden: lokale Stammdaten-SOT ⇏ systemweite AutoritĂ€t; Audit-Record ⇏ Feststellung.
  • §7 MFA-Default qr: Brankos Antwort: Der Schalter code ist der Modus zum Abfragen ohne QR — fĂŒr Agenten, Sensoren und alles, was maschinell bestĂ€tigt werden muss (TOTP bleibt zweiter Faktor, ein Passwort erzeugt keine neue Bindung). Befund dazu: Die Live-Admin-Gruppe lief am 9.10. auf qr (jede Anmeldung = neue Bindung). ⬜ Offen, ob Gruppen mit Root-/Managed-/SSL-Freigaben code verpflichtend bekommen (z. B. Freigabe solcher Produkte nur bei code) oder ob das Konvention bleibt.

4. HTTP 402 als nĂ€chstes Interface — DESIGN_INTENT (Branko, 10.10.)

  • 🛠 Branko: „ein neuer Stern: HTTP 402“ als nĂ€chstes Interface im Moduldesign des TLS-Gate, mit Bezug auf das OZMX-Token-Manifest. Gedanke: Das Gate lĂ€uft ohne Live-Daten plausibel und deterministisch und kann sofort eingesetzt werden, um das Playbook in NetBox vorzubereiten.
  • GeprĂŒft am 10.10.: Die Seite onezeromore.com/ozmx-token-manifest erwĂ€hnt weder HTTP 402 noch Zahlung pro Abruf, Agenten oder Sensoren. Sie beschreibt einen BRC-20-Community-Token (Bonus beim Kunstkauf, Zugang zu Veranstaltungen) mit einem Burn-Mechanismus (an OZM gezahlte Token gehen in ein schlĂŒsselloses Wallet). Die Verbindung 402 ↔ OZMX ist Brankos Gedanke.
  • ⬜ Nicht gebaut, nichts festgelegt. Offen: wer bezahlt wofĂŒr (Abruf, Buchung, Aktivierung?), was der Burn im Gate bedeuten wĂŒrde, und wo es in der Modulkette sitzt.