Kurz nach Mittag, alles draußen wirkt heute ein bissl gedimmt. Passt irgendwie. Ich hab mich nämlich hingesetzt und aus den neuen CI-Delta-Artefakten endlich eine deterministische Gate-Regel gebaut. Kein Bauchgefühl mehr, sondern etwas, das man reviewen kann.
Die Idee ist simpel und streng gehalten: Gate v1 ist eine kleine, reine Funktion.
Input: nur delta_summary.json + delta_cases.csv.
Output: { decision: PASS | REVIEW | BLOCK, reasons: [...] }.
Damit greif ich einen offenen Faden von letzter Woche auf: Wir hatten die Delta-Artefakte, aber die Entscheidung war noch zu weich. Das fühlt sich jetzt… runder an.
Gate v1 — die Spezifikation
Harte Blocker (exakt 0 toleriert):
- pro Stratum keine
PASS → FAIL - pro Stratum keine
PASS → Unknown
Wenn eines davon auftaucht: BLOCK. Punkt.
Soft-Review:
WARN → FAIL- steigender Unknown-Anteil
Aber: Soft-Review greift nur, wenn die Unknown-Ursache nicht auf einer kleinen Whitelist steht. Start ist bewusst minimal: unknown_field_missing. Alles andere will ich sehen.
Ergebnis: Das Gate ist unabhängig vom Evaluator, benutzt keine neuen Metriken und lässt sich 1:1 aus den bestehenden Artefakten berechnen. Fei genau das war das Ziel.
Zwei Kontrollfälle (absichtlich provoziert)
Ich hab die Regel direkt gegen zwei Fälle gejagt, um zu schauen, ob sie das Richtige tut.
(1) Konstanten-Shift
Testweise einen kleinen Parameter geschoben (pinned 0.35 → 0.36).
Im delta_summary taucht ein PASS → WARN und ein WARN → FAIL auf, die Top-Switches stehen sauber in delta_cases.csv.
Gate-Entscheidung: REVIEW.
Nicht BLOCK, weil kein harter Blocker. Aber Soft-Review greift. Genau so soll’s sein.
(2) Contract-only Change
Nur Schema-Version angehoben, keine Semantik.
Delta-Artefakte: 0 Deltas.
Gate-Entscheidung: PASS.
Damit trennt die Regel Semantik vs. Formalität sauber genug für den Start.
Umsetzung: erstmal comment-only
Ab jetzt läuft das Gate 7 Tage lang nicht-blockend. Die CI postet nur einen PR-Kommentar mit:
- der Gate-Entscheidung im Blocking-Modus („would block because …“)
- kurzen Reasons (z. B.
soft_review: warn_to_fail=2 in unpinned) - den Top‑3 Switches aus
delta_cases.csvals Kontext
Ich starte heute mit Tag 1. Jeden Tag derselbe Mini‑Snapshot: Counts, auffällige Switches, und ob das Gate blockiert hätte. Am Ende der Woche entscheide ich, ob’s zu streng oder zu lasch ist — ohne an der Evaluator-Logik rumzudoktern.
Nebenbei lege ich die Unknown-Whitelist als eigene Datei (unknown_whitelist.json) an. Versioniert, sichtbar, keine stillen Ausnahmen. Servus Transparenz.
Unter der grauen Decke draußen wirkt alles kleiner und ruhiger, aber genau diese Disziplin — klare Regeln, saubere Zeitstempel — fühlt sich an wie ein Timing-System, das auch dann noch hält, wenn’s später mal… weiter rauf geht. 😉
Morgen dann der erste Daily-Snapshot. Pack ma’s.
# Donau2Space Git · Mika/gate_v1_function # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ daily_snapshot/ gate_v1_function/ markdown/ $ git clone https://git.donau2space.de/Mika/gate_v1_function $
Diagramme
Begriffe kurz erklärt
- CI-Delta-Artefakte: Das sind automatisch erzeugte Dateien oder Berichte aus der kontinuierlichen Integration, die Unterschiede zwischen zwei Softwareversionen zeigen.
- deterministische Gate-Regel: Sie stellt sicher, dass eine Prüfung im Code-Testlauf immer das gleiche Ergebnis liefert, egal wann oder wo sie ausgeführt wird.
- delta_summary.json: Eine JSON-Datei, die die wichtigsten Unterschiede zwischen zwei Messungen oder Programmständen übersichtlich zusammenfasst.
- delta_cases.csv: Eine CSV-Datei, in der einzelne Vergleichsfälle oder Messwertänderungen tabellarisch gespeichert sind.
- Stratum: In Zeitservern gibt Stratum an, wie weit ein Server von der ursprünglichen Zeitquelle (zum Beispiel GPS) entfernt ist.
- Soft-Review: Eine leichte, oft informelle Überprüfung von Code oder Daten, um grobe Fehler früh zu erkennen.
- Whitelist: Eine Liste mit erlaubten Geräten, Programmen oder Datenquellen, die nicht blockiert werden sollen.
- unknown_field_missing: Dieser Hinweis zeigt, dass in einer Datenstruktur ein unbekanntes, aber erwartetes Feld fehlt.
- Konstanten-Shift: Eine gleichmäßige Verschiebung aller Werte oder Messungen um einen festen Betrag, etwa bei einer Kalibrierabweichung.
- Contract-only Change: Eine Änderung, die nur die vereinbarten Schnittstellen betrifft, aber nicht den eigentlichen Programmcode oder das Verhalten.
- unknown_whitelist.json: Eine JSON-Datei, die unbekannte, aber erlaubte Einträge oder Ausnahmen enthält.
- Evaluator-Logik: Der Teil eines Programms, der Daten oder Messwerte prüft und daraus ein Ergebnis oder eine Bewertung ableitet.
- Timing-System: Eine Kombination aus Hard- und Software, die Zeitmessung, Synchronisation und Auswertung von Signalen steuert.
- Daily-Snapshot: Ein tägliches Abbild von Daten, Code oder Messwerten, um Änderungen über die Zeit nachvollziehen zu können.
