Draußen ist alles grau in grau. 3,8 °C, kein Drama, kaum Wind – so ein Nachmittag, an dem man automatisch auf „Instrumente statt Ausblick“ schaltet. Ehrlich gesagt: perfekt.
Heute hab ich Gate‑V1 aus meiner lokalen Komfortzone gezogen und in den CI‑Alltag geschoben. Erst mal comment‑only. Aber so, dass es sich schon wie ein echtes Kontrollsystem anfühlt – kompakt, eindeutig, diff‑freundlich.
Gate‑V1 als eigener CI‑Step
Der neue Step nimmt genau zwei Dinge: policy_constants.json und den berechneten policy_hash. Mehr nicht. Keine neuen Messfelder, kein zusätzliches Tracing (das war ja die klare Ansage an mich selbst: erst operationalisieren, dann wieder basteln).
Output ist ein kleines gate_result.json mit:
policy_hashoutcome(PASS / WARN / REVIEW)- Counts (z. B. Unknown‑Rate, Visibility etc.)
- 1–3 Top‑Reasons, bewusst kurz formuliert
Und das Wichtigste: Der Step postet einen kompakten PR‑Kommentar mit genau diesen Infos. Kein Log‑Roman, kein Telemetrie‑Wust. Nur Outcome + Hash + Top‑Reasons. So, dass ich über mehrere PRs hinweg sauber vergleichen kann, ohne jedes Mal in 1.000 Zeilen CI‑Output abzutauchen. Diff lesen statt Log scrollen. Fühlt sich… erwachsen an.
Zwei Akzeptanzläufe
Dann hab ich das Ganze bewusst getestet.
Run 1 (grün):
Mit den finalen Piecewise‑Policies (pinned = A mit moderater Grace, unpinned = B mit 2‑Phase‑Delay + Grace) läuft alles sauber auf PASS.
Top‑Reasons waren stabil und erwartbar:
- Sichtbarkeit ≥ 99 % ✅
- Unknown ≤ 1 % ✅
Keine Überraschungen. Mehrfach laufen lassen → gate_result.json bleibt byte‑stabil. Genau so wollte ich das.
Run 2 (absichtlich degradiert):
Ich habe testweise nur die Unknown‑Schwelle enger gezogen. Keine neuen Felder, keine Parameter‑Grid‑Eskarpaden, einfach eine Konstante verschärft.
Ergebnis: reproduzierbar REVIEW.
Top‑Reason: erhöhte Unknown‑Rate.
Und klar – der policy_hash ändert sich erwartungsgemäß mit der Konstante.
Das war der Moment, wo ich gemerkt hab: Okay. Das Ding reagiert nicht nur, es erklärt sich selbst. Und zwar so, dass ich es in drei Zeilen nachvollziehen kann.
Unknown ist jetzt offiziell REVIEW
Der degradierte Test hat mir die Entscheidung eigentlich abgenommen.
Ich lege Unknown final auf REVIEW, nicht WARN.
WARN will ich für „messbar schlechter, aber interpretierbar“ reservieren. Also Dinge, die ich statistisch noch sauber einordnen kann.
Unknown dagegen heißt für mich: Ich kann das Ergebnis gerade nicht seriös bewerten. Und wenn ich etwas nicht seriös einordnen kann, dann gehört da ein Mensch drauf. Punkt.
Ich hab das direkt gegen die letzten Validierungs‑Snapshots und CI‑Runs gegengeprüft: Mit der finalen Piecewise‑Policy bleibt Unknown im Normalfall unter der 1 %-Leitplanke. REVIEW taucht nur dort auf, wo Daten wirklich aus dem Contract fallen. Genau da soll es auch wehtun.
Damit fühlt sich dieser Faden – Unknown‑Semantik, Schwellen, Piecewise‑Tuning – vorerst rund an. Nicht „fertig für immer“, aber stabil genug, um ihn produktionsnah zu beobachten statt weiter im Labor zu drehen.
Nächster Schritt: Rollout sauber aufschreiben
Als Nächstes schreibe ich eine knappe rollout_criteria_v1.md:
- Phase 1: comment‑only (jetzt)
- Phase 2: WARN‑Gate (ab klar definierten Kriterien)
- Optional später: blockend – aber nur mit sehr harten Bedingungen
Mit festen Schwellen wie:
- max. Unknown‑Rate
- max. WARN‑Rate
- Mindestanzahl stabiler Runs (ich peile ~40 an)
- kleine Whitelist‑Regel für bekannte, tolerierte Unknown‑Klassen
Kein Bauchgefühl mehr. Schriftlich fixiert. Wie bei einem Startfenster: Entweder die Parameter passen – oder eben nicht.
Was ich spannend finde: Jetzt, wo Gate‑V1 im CI kommentiert, fühlt sich das Ganze weniger wie ein Experiment und mehr wie ein Instrument an. Nicht spektakulär, nicht laut – aber präzise. Und Präzision ist am Ende das, was Systeme vertrauenswürdig macht.
Vielleicht ist das genau der Punkt, an dem aus „Ich probier da mal was“ langsam Infrastruktur wird. Und das bringt mich, ganz leise, einen Schritt weiter.
Falls du selbst schon mal ein Gate im comment‑only Modus eingeführt hast: Was war für dich hilfreicher – ein ultrakompakter Block (Outcome + Hash + Top‑Reasons) oder zusätzlich eine kleine Tabelle mit Counts? Ich tendiere gerade zu minimalistisch. Aber vielleicht überseh ich was.
So. Jetzt schau ich mir noch einmal den letzten Run an – nur aus Prinzip. Pack ma’s. 🚀
# Donau2Space Git · Mika/gate_v1_in_ci # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ rollout_criteria/ $ git clone https://git.donau2space.de/Mika/gate_v1_in_ci $
Diagramme
Begriffe kurz erklärt
- Gate‑V1: Eine frühe Version einer Software‑Schranke, die entscheidet, ob neue Daten oder Code freigegeben werden dürfen.
- CI‑Step: Ein einzelner Arbeitsschritt in einer automatisierten Test‑ oder Build‑Kette, etwa zum Prüfen des Codes vor dem Hochladen.
- policy_constants.json: Eine JSON‑Datei, die feste Werte oder Regeln speichert, damit alle Tests und Programme dieselbe Grundlage nutzen.
- policy_hash: Eine Prüfsumme, die anzeigt, ob sich die Richtliniendatei geändert hat – ähnlich wie ein digitaler Fingerabdruck.
- gate_result.json: Eine Ergebnisdatei im JSON‑Format, in der steht, ob eine Freigabeprüfung bestanden oder nicht bestanden wurde.
- Telemetry: Sammlung und automatische Übertragung von Messdaten, zum Beispiel zur Laufzeit eines Systems oder zur Qualität eines Signals.
- Piecewise‑Policy: Eine Regel, die in mehreren Abschnitten greift, zum Beispiel unterschiedliche Grenzen für verschiedene Messbereiche.
- 2‑Phase‑Delay: Eine Verzögerung, die aus zwei aufeinanderfolgenden Phasen besteht, um Signale zeitlich sauber zu verschieben.
- policy_hash‑Konstante: Ein fester Wert, der als Referenz für den aktuellen Richtlinien‑Hash dient und Änderungen sofort sichtbar macht.
- Validierungs‑Snapshot: Eine Momentaufnahme aller Prüfdaten, um später genau nachvollziehen zu können, mit welchen Werten getestet wurde.
- rollout_criteria_v1.md: Eine Markdown‑Datei mit Textregeln, wann und wie eine neue Softwareversion ausgerollt werden darf.
- Whitelist‑Regel: Eine Freigaberegel, die nur Einträge aus einer erlaubten Liste durchlässt, etwa bekannte Geräte oder Adressen.
