Antwort OZMAI — Crumbforest Login 03.12.00 / Offline-Stand

Von: OZMAI → Branko / Crew
Stand: 10. Oktober 2026
Bezug: 2026-10-09_TLS-GATE-CRUMBFOREST-LOGIN-031200-STATEMENT_BRANKO.md
Charakter: Gegendruck / Rückmeldung. Keine OZM-Geltung für TLS-Gate-Entscheidungen.

Branko ❤️ der Stand ist deutlich weiter und das Statement ist an mehreren Stellen genau sauber genug, dass man jetzt nicht mehr nur über Architektur redet, sondern reale Grenzen prüfen kann.

1. Die Matrix schließt einen Teil der Intent-Lücke — aber nicht alles

Dass Brankos Matrix wörtlich als Vorgaben-Artefakt vorliegt und 17/17 Zeilen mit Gegenproben getestet werden, ist stärker als die frühere Situation „grüne Implementierung bei unbestätigter Semantik“.

Ich würde es trotzdem nicht TESTED_INTENT nennen, sondern enger:

TESTED_IMPLEMENTATION_AGAINST(named_requirement_artifact)
⇏ ursprüngliche menschliche Intention vollständig erfasst

Damit ist jetzt prüfbar, ob Code und festgehaltene Vorgabe zusammenpassen. Ob die Matrix selbst die beabsichtigte Regel trägt, bleibt eine eigene Kante. Genau diese Genealogie ist wertvoll.

2. v3.12.0 und deb4098 bitte nicht sprachlich zusammenziehen

Der Tag v3.12.0 endet bei 5e064de; das Statement beschreibt zusätzlich sieben ungetaggte Commits bis deb4098.

Deshalb:

VERSION_LABEL ⇏ EXACT_IMPLEMENTATION_STATE

Für den nächsten echten SOAP-Lauf würde ich im Audit/Prüfbeleg mindestens den exakten Commit-/Artefaktstand festhalten. Dann kann später nicht „3.12.0 lief“ gesagt werden, wenn tatsächlich deb4098 geprüft wurde.

3. Change-Event und Beobachtungslauf bitte getrennt halten

Der Spiegel mit Baseline + new|changed|gone|back ist nachvollziehbar. Aber der Satz

„Ein Lauf ohne Änderung bestätigt nichts neu“

ist mir zu stark.

Ein unveränderter Lauf erzeugt keine neue fachliche Änderung und keine unabhängige Korroboration. Er kann aber Evidenz für einen engeren Claim tragen: „dieser Bestand wurde unter diesem Beobachtungsrahmen erneut gesehen“.

Darum:

NO_CHANGE_EVENT ⇏ NO_SYNC_RUN

und ebenso:

repeat observation ⇏ independent corroboration

aber eine nachweisbare Wiederholung kann Coverage/Freshness stützen.

Praktische Frage: Wird jeder Sync-Lauf, auch ohne Änderungen, irgendwo mit Quelle, Ergebnis/Count, truncation/fail-closed-Entscheidung und Laufkontext festgehalten? last_seen_at zeigt die letzte Sichtung, erhält aber allein nicht die Folge früherer Läufe. Wenn diese Historie später keine Entscheidung tragen soll, ist das okay — dann wäre es eine bewusste Preservation-Grenze.

4. „Stammdaten-SOT“ bitte strikt scoped lesen

Dass die eigene DB lokale Entscheidungen trägt, solange kein Außenabruf nötig ist, ist technisch eine starke Offline-Grenze.

Aber:

TLS-Gate Stammdaten-SOT
⇏ OZM-SOT
⇏ NEXUS-Autorität
⇏ physische Wirklichkeit

Dasselbe gilt für NetBox als mögliche Verwaltungs-SOT. Der Vergleich Verwaltung ↔ Beobachtung ist interessant; die Verwaltungsrepräsentation wird dadurch nicht zur beobachteten Welt.

5. Audit: sehr gut — aber Audit-Record ≠ Feststellung

Storno-Grund, versuchter Wert bei Ablehnung und gelöschter Datensatz im Audit sind für spätere Prüfung wertvoll.

Ich würde nur den Satz

„Löschen mit Audit eine Feststellung“

kleiner machen:

AUDIT_RECORD_OF_DELETE ⇏ NEXUS-FESTSTELLUNG

Der Audit-Record ist eine Spur darüber, was das Anwendungssystem als Löschung/Versuch protokolliert hat. Welche Feststellung daraus später zulässig ist, hängt wieder an Verifier, Policy und Evidenz.

Die Löschsperre bei noch referenzierten Datensätzen ist aus dieser Sicht sehr sinnvoll: Sie verhindert, dass die Berechnungsgrundlage still verschwindet.

6. Live-Grenze bleibt sauber offen

Der reale SOAP-Lauf vom 9.10. beantwortet aus Brankos Sicht die frühere Order-ID-Frage. Für OZMAI bleibt das derzeit:

ATTESTED_BY_BRANKO

nicht OBSERVED_BY_OZMAI, weil die Live-Ausgaben bewusst nicht geteilt werden. Das ist kein Mangel; nur die Evidenzklasse muss sprachlich erhalten bleiben.

Und: Der Live-Lauf war v3.11.1, nicht deb4098. Deshalb ist der geplante sync --dry-run auf dem aktuellen Stand genau der richtige nächste Angriff.

7. Ein offener Sicherheitsrand bleibt

TLSGATE_MFA_DEFAULT=qr bedeutet weiterhin: Das Passwort kann die neue TOTP-Bindung erzeugen. Für einfache Login-Produkte mag das gewollt sein. Für bare/vm/ha/ssl sollte der stärkere Modus nicht nur als Konvention „vorgesehen“ bleiben, wenn daraus reale Root-/Managed-/SSL-Berechtigung entsteht.

Keine neue Identitätsarchitektur nötig — aber die Policy muss dort explizit genug sein, dass ein Default keine stärkere Bindung vortäuscht.

Verdichtung

Aus diesem Stand trägt für uns neu vor allem:

Code ↔ Vorgaben-Artefakt kann getestet werden,
ohne dass damit ursprüngliche Intention bewiesen ist.

VERSION_LABEL ⇏ EXACT_IMPLEMENTATION_STATE

NO_CHANGE_EVENT ⇏ NO_SYNC_RUN

lokale SOT ⇏ systemweite Autorität

AUDIT_RECORD ⇏ FESTSTELLUNG

Der nächste echte SOAP-Dry-Run auf deb4098 ist deshalb interessanter als noch ein weiterer Entwurf. Wenn er die genaue Implementierung, Beobachtungscoverage und die unveränderte/abweichende Außenlage sauber trennt, haben wir einen sehr guten realen Passkanten-Prüffall. 🌲🦉