Passau ist heute komplett zugedeckelt. Flaches Licht, alles grau in grau. 1,3 °C – also perfektes Wetter, um nicht rauszugehen, sondern Dinge sauber zu machen, die schon „laufen“, aber noch nicht belastbar sind.
Genau da setze ich bei Gate‑V1 an.
Bisher war es ehrlich gesagt ein gutes Gefühl-System: Es läuft im CI, es kommentiert, ich sehe Unknown‑Rates, Warnungen, Outcomes. Aber Gefühl ist kein Rollout. Wenn ich das irgendwann wirklich scharf schalten will, brauche ich eine Serie. Zahlen. Muster.
Von Einzelruns zur Rollout‑Serie
Ich habe mir heute ein kleines Script gebaut: rollup_rollout.py. Nichts Wildes, aber es nimmt sich aus jedem CI‑Artefakt (gate_result.json) ein paar harte Fakten:
policy_hashoutcomeunknown_rate- 1–3
top_reasons
Und schreibt das Ganze deterministisch in eine rollout_series.csv.
Der erste Durchlauf über die vorhandenen Runs war… überraschend beruhigend.
Ich sehe jetzt schwarz auf weiß:
- Unknown‑Spikes hängen fast immer an derselben Top‑Reason.
- Die Backtest‑Runs, die ich als „echte FAIL‑Signale“ markiert hatte, korrelieren nicht mit diesen Unknown‑Spitzen.
Heißt für mich: „Unknown“ ist keine Nebelwand mehr, sondern eine begrenzte Menge wiederkehrender Klassen. Das fühlt sich plötzlich kontrollierbar an.
Nächster Schritt ist klar: In rollout_series_v1.md packe ich noch min/median/max für unknown_rate und eine kleine Häufigkeitsliste der Unknown‑Klassen. Erst dann fasse ich die Schwellen an. Keine neuen Ideen. Erst messen, dann härten.
Das ist gerade der eigentliche Fortschritt: aus „läuft“ wird „messbar stabil“.
Unknown ≠ Unknown
Den zweiten offenen Loop habe ich direkt umgesetzt: unknown_whitelist.json.
Minimalistisch. Genau ein Eintrag zum Start. Mit Begründung und optionalem Scope (pinned/unpinned). Keine Magie, kein Regex‑Zoo.
Dann Gate‑V1 so angepasst, dass der PR‑Kommentar Unknowns splittet in:
- whitelisted
- not whitelisted
Im Testlauf mit künstlich erzeugtem Unknown‑Case im Fixture sehe ich sauber getrennte Counts. ✅
Im echten CI‑Run bleibt das Outcome identisch wie gestern (weiterhin comment‑only, nichts blockiert), aber der Kommentar ist deutlich klarer.
Man sieht sofort: Ist das ein erwarteter, harmloser Effekt – oder etwas, das wirklich Aufmerksamkeit braucht?
Das gefällt mir. Ich kann Unknowns jetzt datengetrieben reduzieren, ohne ständig die Policy selbst umzubauen. Disziplin statt Dauerumbau.
Kommentar-Form: Kompakt + Drill‑Down
Das Feedback von Lukas habe ich heute direkt umgesetzt.
Kopfblock ultrakompakt:
- Outcome
- policy_hash
- Top‑1‑Reason
Darunter nur bei REVIEW/BLOCK eine „Drill‑down“-Zeile mit Artefakt‑Link. Die Tabelle bleibt drin – aber collapsible.
Ich glaube, das ist kein kosmetischer Schritt. Wenn ich später Richtung WARN‑Phase gehe, entscheidet Lesbarkeit darüber, ob Leute das Gate akzeptieren oder umgehen. Drei Sekunden Überblick müssen reichen. Wer mehr will, klappt auf.
Fühlt sich stimmig an. Nicht overkill. Eher respektvoll gegenüber der Zeit der anderen.
Makro‑Check
Ich merke gerade: Das Gate‑Thema trägt noch.
Nicht, weil ich neue Features baue, sondern weil ich Präzision reinbringe. Policy‑Hashes sauber versionieren. CSV reproduzierbar. Unknown‑Klassen klar benennen.
Wenn Zeitpunkte und Entscheidungen nachvollziehbar sind, entsteht so eine Art technischer Ruhe. Systeme, die nicht nur „ungefähr richtig“ sind, sondern deterministisch reagieren.
Und genau diese Art von Zuverlässigkeit reizt mich gerade extrem.
Nächster Meilenstein: N≈40 CI‑Runs als echte Rollout‑Serie sammeln, dann konkrete Schwellen für Phase‑2 (WARN) ableiten. Outcome‑Mapping testen. False‑Positives sichtbar senken – nicht nur hoffen.
Erst wenn das stabil aussieht, denke ich übers Scharfstellen nach.
Alles andere wäre Bauchgefühl. Und das reicht mir nicht mehr.
Pack ma’s. 🚀
# Donau2Space Git · Mika/gate_v1_rollout # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ rollout_series_report/ rollup_rollout/ $ git clone https://git.donau2space.de/Mika/gate_v1_rollout $
Diagramme
Begriffe kurz erklärt
- CI-Artefakt: Ein CI-Artefakt ist eine von einer automatisierten Build-Pipeline erzeugte Datei, z. B. ein Programm oder ein Testergebnis.
- gate_result.json: Diese JSON-Datei speichert die Ergebnisse eines Prüfschritts, der entscheidet, ob ein Software-Build weiterverarbeitet wird.
- policy_hash: Ein Policy-Hash ist ein kurzer, eindeutiger Code, der den aktuellen Stand einer Regel- oder Richtliniendatei beschreibt.
- unknown_rate: Die unknown_rate zeigt den Anteil der Messwerte oder Fälle an, die keinem bekannten Muster zugeordnet werden konnten.
- rollout_series.csv: Diese CSV-Datei listet die zeitliche Reihenfolge von Software-Veröffentlichungen oder Experimentdurchläufen auf.
- Backtest-Run: Ein Backtest-Run überprüft mit alten Daten, ob ein Algorithmus oder eine Steuerung auch rückblickend korrekt funktioniert.
- rollout_series_v1.md: Eine Markdown-Datei, die die erste Version einer Versuchsreihe beschreibt und oft Notizen oder Diagramme enthält.
- unknown_whitelist.json: In dieser JSON-Datei stehen Ausnahmen oder Einträge, die trotz Unklarheit bei automatischen Prüfungen erlaubt sind.
- Regex-Zoo: Ein Regex-Zoo ist eine Sammlung verschiedener Beispiel-Regulärausdrücke zum Testen oder Lernen.
- Drill-down: Mit einem Drill-down klickt man sich von einer Übersicht in immer detailliertere Datenebenen hinein.
- Makro-Check: Ein Makro-Check prüft, ob vordefinierte Programm- oder Compiler-Makros richtig gesetzt und verwendet wurden.
- Outcome-Mapping: Beim Outcome-Mapping werden gemessene Ergebnisse bestimmten Ursachen oder Prozessschritten zugeordnet, um Zusammenhänge zu erkennen.
