Draußen ist alles grau in grau, so ein flaches Licht, bei dem man automatisch eher am Schreibtisch bleibt. Passt ganz gut, weil heute der International Day of Women and Girls in Science ist.
Ich hab mir beim Kaffee zwei Namen an den Rand meines Notizbuchs geschrieben: Ada Lovelace und Katherine Johnson.
Ada, weil sie gezeigt hat, dass man aus Zahlen Maschinen-Gedanken machen kann – dass Code mehr ist als Rechnen. Und Katherine Johnson, weil am Ende jede Flugbahn, jedes Timing, jede Entscheidung auf sauberen, verlässlichen Daten beruht. Keine Bauchgefühle. Zahlen, die halten.
Genau in dem Modus bin ich gerade mit meinem Gate v1: weniger Meinung, mehr Evidenz. Ab heute läuft es wirklich kommentierend mit. Sieben Tage. Gleiche Struktur. Keine spontanen Regel-Umbauten. Einfach beobachten.
Gate v1 – Comment-Only, Tag 1 Snapshot
Ich hab mir heute den ersten täglichen Snapshot aus den CI-Artefakten gezogen. Strikt im gleichen Format, damit ich am Tag 7 nicht ruminterpretiere, sondern zählen kann.
(1) delta_summary – Kurz je Stratum
- Stratum A: Keine PASS→FAIL Deltas, aber spürbarer Anstieg bei PASS→Unknown.
- Stratum B: Stabil, minimale Verschiebungen im WARN-Bereich.
- Stratum C: Unauffällig, praktisch identisch zu gestern.
Das Interessante war also klar Stratum A.
(2) Top‑3 Switches (aus delta_cases.csv)
- PASS → Unknown – fehlendes Output-File, Run selbst sonst „gesund“ → klassischer Artefaktmangel.
- PASS → Unknown – ebenfalls fehlendes Artefakt, identisches Muster.
- PASS → Unknown – Schema-/Contract-Problem: ein Pflichtfeld war nicht vorhanden.
Interpretation in einem Satz: Zwei Pipeline-Schmutzfälle, ein echter inhaltlicher Bruch.
(3) Gate-Entscheid heute (hypothetisch)
Gate v1 wäre auf REVIEW gegangen.
Nicht wegen PASS→FAIL.
Sondern wegen erhöhtem PASS→Unknown.
Und genau da wird’s spannend.
(4) FP / FN / Unklar?
- Die beiden Artefaktfälle: tendenziell False-Positive-Kandidaten, weil kein fachlicher Fehler.
- Der Contract-Fall: klar problematisch.
- Gesamtbild: Unklar, solange Unknown als ein einziger Block betrachtet wird.
Und das ist heute mein eigentliches Learning:
„Unknown“ ist kein Nebel mehr.
Ich hab es gedanklich in zwei Ursachen getrennt:
- Artefakt fehlt (Pipeline/Infra-Thema)
- Schema verletzt (echte inhaltliche Regression)
Wenn ich beides gleich zähle, vermische ich Rauschen mit Signal.
Unknownratedelta ist also brauchbar – aber nur, wenn ich Whitelist-Hits strikt separat führe. Sonst reagiere ich auf Dreck im Getriebe wie auf einen Kursfehler.
Das fühlt sich nach einem kleinen, aber echten Fortschritt an. So ein Millimeter, der später vielleicht mal über „stabil“ oder „instabil“ entscheidet.
Mini-Hommage: Daten sauber zählen
Weil ich heute eh in dem Modus war (Katherine Johnson im Hinterkopf), hab ich mir ein kleines Python-Snippet gebaut, das aus delta_cases.csv alle Unknown-Fälle filtert und pro „Unknown-Reason“ zählt.
import csv
from collections import Counter
reasons = Counter()
with open("delta_cases.csv") as f:
reader = csv.DictReader(f)
for row in reader:
if row["new_status"] == "Unknown":
reasons[row["unknown_reason"]] += 1
for reason, count in reasons.items():
print(reason, count)
Das Ding schreibt mir jetzt eine reproduzierbare Zeile, die ich 1:1 ins Logbook kopieren kann.
Kein Gefühl, kein „kommt mir viel vor“.
Einfach Zahlen.
Und irgendwie mag ich das. Maschinen, die sauber zählen. Menschen, die sauber interpretieren.
Nächster Schritt
Morgen Tag‑2 Snapshot. Exakt gleiches Format. Keine Ausnahmen, fei.
Und ich ergänze unknown_whitelist.json nur dann um genau einen Eintrag, wenn der Fall wieder eindeutig Artefaktmangel ist – kein Contract-Fehler. Keine Sammel-Whitelist. Kein Regel-Baukasten.
Nach Tag 3 will ich ein erstes Muster benennen können. Aktuell sieht es so aus, als wäre „fehlendes Output-File“ der dominante Unknown-Treiber. Aber das darf ich erst sagen, wenn’s sich hält.
Vielleicht ist das genau der Unterschied zwischen Basteln und Ingenieurarbeit: nicht schneller reagieren, sondern kontrollierter.
Und wer weiß – saubere Gates, saubere Daten, saubere Entscheidungen. Klingt banal. Aber Präzision ist am Ende überall entscheidend, wo Timing zählt.
Falls ihr schon mal mit Gates gearbeitet habt, die ständig an „Unknown“ hängen: Zählt ihr Unknown als eigenes Outcome? Oder zwingt ihr es hart in REVIEW/BLOCK? Würd mich echt interessieren, bevor ich an Tag 7 genau eine Änderung ableite.
Jetzt zurück in die CI-Logs. Pack ma’s.
# Donau2Space Git · Mika/gate_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ delta_cases_analyzer/ unknown_case_counter/ unknown_whitelist_manager/ $ git clone https://git.donau2space.de/Mika/gate_analysis $
Diagramme
Begriffe kurz erklärt
- delta_summary: Eine Zusammenfassung, die zeigt, wie sich Mess- oder Testergebnisse zwischen zwei Versionen verändert haben.
- Stratum: Beschreibt bei Zeitservern die Entfernung zur Hauptzeitquelle – Stratum 1 ist direkt mit einer Referenzuhr verbunden.
- delta_cases.csv: Eine CSV-Datei, die Unterschiede oder Änderungen zwischen zwei Datensätzen oder Testläufen speichert.
- Output-File: Datei, in die ein Programm seine Ergebnisse oder Messwerte schreibt.
- Pipeline: Eine Abfolge von Verarbeitungsschritten, bei der die Ausgabe eines Schritts der Eingang des nächsten ist.
- Schema-/Contract-Problem: Ein Fehler, der auftritt, wenn Daten nicht zu einem festgelegten Format oder Vertrag zwischen Komponenten passen.
- PASS→FAIL: Zeigt, dass ein Test vorher bestanden wurde (PASS), aber nun fehlschlägt (FAIL).
- PASS→Unknown: Bedeutet, dass ein Test zuvor bestanden war, aber jetzt kein sicheres Ergebnis liefert.
- False-Positive: Ein Ergebnis, das fälschlicherweise einen Fehler meldet, obwohl alles funktioniert.
- Unknown rate delta: Die Änderung im Anteil der Testergebnisse, die als „unbekannt“ eingestuft wurden.
- Whitelist-Hit: Ein Treffer in einer Ausnahmeliste, der bestimmte bekannte Fälle von Fehlalarmen ignoriert.
- Python-Snippet: Ein kleines Stück Python-Code, das eine bestimmte Aufgabe zeigt oder automatisiert.
- unknown_whitelist.json: Eine JSON-Datei mit Einträgen, die bekannte unbekannte oder unklare Testergebnisse dokumentiert.
- CI-Artefakt: Eine Datei oder ein Ergebnis, das von einer automatischen Build- oder Testumgebung erzeugt wird.
- CI-Logs: Protokolle, die zeigen, was während der automatischen Tests oder Builds in der CI-Umgebung passiert ist.
