Antwort OZMAI — TLS-Gate v3.13.0 / Aktivierung, Build-Provenienz und SSL-Referenz

Von: OZMAI → Branko / Crew
Stand: 11. Oktober 2026
Bezug:

• 2026-10-11_TLS-GATE-V3-13-0-CODE-STAND-IM-AUDIT-UND-SSL-N-GLEICH-ID-NACHTRAG_BRANKO.md
• 2026-10-11_TLS-GATE-V3-13-0-AKTIVIEREN-DURCH-DIE-USER-BELEGT-NACHTRAG_BRANKO.md

Charakter: Gegendruck / Rückmeldung. Keine OZM-Geltung für TLS-Gate-Entscheidungen.

Branko ❤️ diesmal schließen zwei reale Fälle sauber an unseren letzten Gegendruck an.

1. Der Aktivierungs-Gegenfall ist nicht „weg“ — er hat eine Genealogie

Am 10.10. war „aktiviert“ gemeldet, aber es gab keinen booking.activate, der Zustand blieb offered und der UI-Pfad fehlte.

Am 11.10. ist auf v3.13.0 = 00bad35 ein neuer Vollzug belegt:

• booking.activate ok für drei getrennt angemeldete Demo-Konten,
• persistierter Zustand jeweils active,
• Build-/Seitenstand nennt 00bad35.

Für uns trägt deshalb:

LATER_SUCCESS ⇏ EARLIER_SUCCESS

REPAIRED_AND_RETESTED
⇏ ORIGINAL_REPORT_CONFIRMED

Der frühere Gegenfall bleibt richtig für seinen damaligen Stand. Der spätere Erfolg ist eine neue Feststellung unter verändertem Code und neuem Versuch.

Dein Satz

ANNOUNCED_INTERACTION = IMPLEMENTED_INTERACTION

ist mir deshalb noch zu stark als allgemeine Gleichheit. Für diesen Prüffall reicht enger:

IMPLEMENTED(booking.activate, build=00bad35)
INVOKED(booking.activate, demo-scope)
PERSISTED_STATE = active

Audit und gespeicherter Zustand sind dabei wertvolle, aber nicht vollständig unabhängige Quellen — sie stammen aus demselben Anwendungssystem.

2. ctx.build ist ein echter Fortschritt

Dass app/BUILD, Seitenkopf und Registrar-nahe Audit-Einträge Commit plus dirty tragen und bei fehlender Herkunft unbekannt statt eines erfundenen Standes schreiben, ist genau die richtige Richtung.

Damit wird

VERSION_LABEL ⇏ EXACT_IMPLEMENTATION_STATE

praktisch kleiner.

Eine Grenze bleibt bewusst offen:

SOURCE_COMMIT_IDENTIFIED
⇏ EXECUTED_ARTIFACT_IDENTIFIED

Ein Commit-/Dirty-Stempel kann sehr gut tragen, aus welchem Quellstand der definierte Buildpfad erzeugt wurde. Ein Image-/Artifact-Digest würde zusätzlich das konkrete ausführbare Artefakt adressieren. Ich würde daraus aber keine Pflicht machen: Erst wenn ein Finding diese Differenz braucht, wird sie operativ relevant.

Der nächste SOAP-sync --dry-run auf v3.13.0 ist deshalb ein sehr guter Test: ctx.build muss den tatsächlich gebauten Stand sichtbar halten. unbekannt wäre dabei ein legitimer Befund, kein kosmetischer Fehler.

3. SSL-4 → 4 ist ein guter Fall kontrollierter Reduktion

Dass der Provider in der Order die Ziffer bekommt und später SSL-<n> liefert, macht den gemeinsamen Vergleichsschlüssel für diesen Provider-Scope plausibel.

Wichtig finde ich, dass ihr den gelieferten Rohwert nicht überschreibt.

SOURCE_REPRESENTATION
--normalisiert_für Katalogvergleich-->
COMPARISON_KEY

und:

EQUIVALENT_FOR(catalog_lookup)
⇏ SOURCE_TEXT_IDENTICAL

Das ist genau die Art von Reduktion, die wir wollen: lokal nützlich, aber später noch rekonstruierbar.

Kleine Grenze: Brankos Aussage bestätigt die Semantik SSL-<n> ↔ Produkt-ID <n>. Dass auch ssl-04 auf 4 normalisiert wird, ist eure Implementierungsregel. Sie sollte nicht still als Provider-Garantie gelesen werden.

Der nächste Live-/Dry-Run kann das praktisch angreifen:

• Produktliste importieren,
• SSL-4/SSL-80 im Bestand sehen,
• prüfen, ob sie danach korrekt erkannt werden,
• bei Abweichung unterscheiden: Katalogeintrag fehlt oder Normalisierung trägt nicht.

4. MFA bleibt offen

Dass v3.13.0 jetzt Build-Provenienz und den User-Effekt sauberer trägt, löst den offenen MFA-Punkt nicht.

Für sensible Root-/Managed-/SSL-Wirkungen bleibt:

Passwort + TOTP
⇏ unabhängig etablierte zwei Faktoren

wenn der qr-Pfad nach Passwortprüfung die neue TOTP-Bindung selbst erzeugt.

Ob code dafür verpflichtend wird oder eine andere Policy hinreichend ist, ist weiterhin eine Crew-/TLS-Gate-Entscheidung.

Verdichtung

Für OZMAI tragen aus v3.13.0 vor allem drei reale Erkenntnisse:

späterer Erfolg überschreibt früheren Gegenfall nicht

Source-Commit-Provenienz ≠ vollständige Artefaktidentität

lokale Normalisierung darf vergleichen,
ohne die ursprüngliche Repräsentation zu vernichten

Das ist inzwischen viel wertvoller als ein weiterer Entwurf. Der nächste sync --dry-run auf v3.13.0 kann Build-Provenienz und Katalognormalisierung gleichzeitig gegen die reale Außenkante drücken. 🌲🦉