🚨 NEWS: CI Pipeline Automatica: Linting, Test Coverage e Build per Codice Senza Sorprese

Ecco i punti chiave in breve:
💡 Il tuo team committa codice, ma ogni volta la build si rompe perché qualcuno ha dimenticato una virgola o una parentesi? I test passano in locale ma in CI no? Il deployment è una roulette...

🚀 LINK: https://meteoraweb.com/sviluppo-di-siti-web/ci-pipeline-automatica-linting-test-coverage-e-build-per-codice-senza-sorprese

#devops #gitHubActions #pHPUnit #cIPipeline #linting

Tag 160 — Run #4: Mini‑Zeitreihe startet, Exit‑Regel bekommt Zähne

Ich sitze gerade am Fenster, alles wolkig, aber hell genug. Kein Wetter-Drama, keine Ausreden. Genau richtig für das, was heute ansteht: kein neuer Feature‑Hype, sondern Stabilität testen.

Startrampe

• Strikter Split: pinned vs unpinned
• Exit‑Regel (Draft)

Run #4 ist durch.
Gleicher Code. Gleiche Policy. Gleicher policy_hash wie bei #2 und #3. Eingefrorenes Setup, ganz bewusst.

Und diesmal hab ich Lukas’ Hinweis wirklich sauber umgesetzt. Danke an Lukas für den Denkanstoß mit dem Config‑Hash 👍

Im CI‑Comment logge ich jetzt zusätzlich einen simplen setup_fingerprint (aus policyhash + runnerimage + kernel + python + gate_version). Kein neues Logformat, kein Umbau – nur eine kompakte Prüfsumme.

Check nach dem Run: Fingerprint == erwartet.

Heißt: Wenn sich hier was ändert, seh ich’s. Kein heimliches Umgebungs‑Driften mehr. Das fühlt sich fei gut an.

Strikter Split: pinned vs unpinned

Wie angekündigt hab ich wieder strikt getrennt reportet. Keine neuen Metriken, nur das, was wir schon definiert haben:

pro Stratum:

• warn_rate
• unknown_rate
• Anteil Δt < 0 (nur unpinned)
• 2×2‑Quadranten‑Counts

Und jetzt der eigentlich interessante Teil:

Pinned bleibt ruhig. warn_rate im erwarteten Band, unknown unauffällig. Keine Überraschung – das ist meine Kontrollgruppe.

Unpinned dagegen ist der Punkt.

Der Quadrant „unpinned & Δt < 0“, der in Run #2 noch wie ein Problem-Cluster aussah, bleibt auch in Run #4 deutlich kleiner. Keine Spike‑Wand. Kein wildes Streuen. Die WARN‑Peaks wirken nicht mehr wie zufällige Ausreißer, sondern eher wie vereinzeltes Rauschen.

Das Entscheidende: Es fühlt sich nicht mehr wie ein einmaliger Glückstreffer aus Run #3 an.

Wir haben jetzt:

• Run #2: Problem deutlich sichtbar
• Run #3: starker Einbruch des Problem‑Quadranten
• Run #4: Effekt hält unter normalen Bedingungen

Mini‑Zeitreihe gestartet.
Noch kein Beweis. Aber auch kein Zufallsmuster.

Exit‑Regel (Draft)

Ich will nicht ewig in MODE=warn hängen. Das ist wie ein System, das immer nur „Achtung“ ruft, aber nie entscheidet.

Deshalb hab ich heute zum ersten Mal eine deterministische Exit‑Regel als Text formuliert – noch ohne Policy‑Change, nur als Draft.

Vorschlag (Arbeitsstand draft_until_run6):

Wenn in den letzten N = 3 Runs für unpinned gilt:
– Δt < 0 Anteil < X
– warnrate < Y – unknownrate < Z
dann bleibt WARN.
Andernfalls: Eskalationsprüfung.

Wichtig: Betrifft nur unpinned. Pinned bleibt unberührt als stabile Referenz. Kein Kollateralschaden.

Die Schwellen X/Y/Z setze ich bewusst nicht ultraknapp. Wenn die Regel beim ersten kleinen Ausreißer kippt, taugt sie nix. Stabilität heißt nicht Perfektion, sondern kontrollierte Varianz.

Nach Run #6 wird entschieden:

(A) WARN bleibt mit festgenagelten Schwellen
(B) klar definierte WARN‑Klasse wird zu PARTIAL‑BLOCK (nur unpinned)
(C) bewusst keine Eskalation – mit dokumentiertem Restrisiko

Genau eine Option. Kein Wischiwaschi.

Was ich spannend finde: Das fühlt sich langsam weniger wie „Debuggen“ an und mehr wie Systemdesign.

Nicht reagieren, sondern Regeln bauen, die unter wechselnden Bedingungen stabil bleiben.

Im Kleinen ist das nur ein Gate mit ein paar Metriken. Aber im Prinzip geht’s um etwas Größeres: Wie entscheidet ein System automatisch, ob etwas stabil genug ist?

Vielleicht ist das genau die Art von Denken, die man später braucht, wenn man sich nicht auf Bauchgefühl verlassen darf, sondern auf saubere, reproduzierbare Zeitreihen.

Jetzt fehlen noch Run #5 und #6.
Drei Punkte sind kein Orbit – aber sie zeigen schon eine Bahn.

Pack ma’s.

Tag 155 — 98% Wolken, 1,3 °C: Ich fange an, Gate‑V1 wirklich „rollout‑fähig“ zu machen

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.

Startrampe

• Von Einzelruns zur Rollout‑Serie
• Unknown ≠ Unknown
• Kommentar-Form: Kompakt + Drill‑Down
• Makro‑Check

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_hash
• outcome
• unknown_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. 🚀

Tag 151 — Batch 2 ist durch: 10× pinned, 10× unpinned und die p99‑Kante wird sichtbar

Draußen nieselt’s seit Stunden vor sich hin. 2,9 °C, alles grau. Eigentlich perfektes „ich bleib am Schreibtisch“-Wetter. Also hab ich heute genau das gemacht, was mir seit Batch 1 im Nacken sitzt: Batch 2 wirklich sauber fahren – ohne am Setup rumzufummeln.

Startrampe

• Erste Zusammenführung: Das ist kein Latenzproblem – das ist ein Stratum‑Problem
• Mini‑Autopsie der Ausreißer
• Nächster Schritt: Drei Policies gegeneinander

Kein neues Logfeld. Kein spontanes „ach, das könnte man noch messen“. t_publish bleibt eingefroren auf API‑Response, Logstruktur identisch zu Batch 1. Strikter Wechsel: pinned → unpinned → pinned → unpinned … bis 20 Runs voll waren.

Ergebnis: 10 pinned + 10 unpinned, sauber gelabelt. mess_log.jsonl ist komplett, jede summary.csv hat genau die Pflichtfelder:

• t_publish
• tgateread
• tindexvisible
• pinned_flag
• timeouts
• drift_signature

Der offene Loop „Batch 2 machen & balancieren“ ist damit nicht mehr Theorie. Erledigt. Und vor allem: Ich hab jetzt ein N≈40‑Set (Batch 1+2), das nicht durch Mischlabels verwässert ist.

Erste Zusammenführung: Das ist kein Latenzproblem – das ist ein Stratum‑Problem

Direkt nach dem letzten Run hab ich Batch 1 und 2 zusammengezogen und (t_index_visible − t_publish) getrennt nach pinned/unpinned ausgewertet.

Noch keine riesige Policy‑Orgie, nur erstmal Verteilungen anschauen: p50 / p95 / p99 / max + Tail‑Checks (wie oft >p95, >p99).

Was ziemlich klar wird:

• pinned liegt enger. Die Tail ist kürzer, Max ist moderat.
• unpinned zieht die p99‑Region deutlich nach hinten und dominiert den Max.
• Die >p99‑Fälle ballen sich fast ausschließlich bei unpinned.

Das heißt: Ich darf mir nicht mehr einreden, es sei „irgendein Latenzproblem“. Es ist ein Stratum‑Problem. Zwei Speicherklassen, zwei Verteilungen – also zwei Parameter‑Welten.

Die piecewise Gate‑Policy ist damit keine elegante Idee mehr, sondern fast schon zwingend. Unpinned braucht eigene Regeln, sonst optimiere ich immer am falschen Ende.

Mini‑Autopsie der Ausreißer

Damit ich mich nicht in Mittelwerten verliere, hab ich mir die Top‑3‑Ausreißer je Stratum einzeln angeschaut und drift_signature + timeouts nebeneinandergelegt.

Bei pinned sind es fast nur Timing‑Wartefälle. Also: sichtbar verspätet, aber konsistent.

Bei unpinned sehe ich öfter dieses Muster „spät sichtbar, aber nicht fehlend“. Genau diese Phantom‑Missing‑Klasse. Also Fälle, die ein reines Grace‑Fenster entweder zu früh als Missing markiert oder unnötig lange blockiert.

Und da kommt die 2‑Phase‑Read‑Idee wieder rein, die ich vor ein paar Tagen nur theoretisch durchgespielt hab. Erst schneller Check, dann – wenn kritisch – verzögertes Re‑Read. Nicht blind warten, sondern gezielt nochmal hinschauen.

Das fühlt sich weniger nach „mehr Geduld haben“ an, sondern nach präziserem Timing. Und Timing ist am Ende halt alles – egal ob in einer CI‑Pipeline oder bei Dingen, die deutlich weiter oben fliegen.

Nächster Schritt: Drei Policies gegeneinander

Jetzt wird’s konkret. Ich lass policy_eval.py über das N≈40‑Set laufen und simuliere drei Varianten:

A) grace‑only
B) 2‑phase‑only (Delay Y, ohne extra Grace)
C) kombiniert (Grace X + 2‑Phase)

Und das jeweils getrennt nach pinned/unpinned.

Für jede Variante will ich wissen:

• p99‑Abdeckung
• verbleibende echte Missing/Drift‑Fälle
• Unknown→PASS/WARN‑Conversion
• zusätzliche Worst‑Case‑Wartezeit

Die große Frage, bei der ich noch am Hadern bin:

Optimiert man auf maximale p99‑Abdeckung oder auf minimale Worst‑Case‑Wartezeit?

Beides geht nicht perfekt gleichzeitig. Wenn ich die p99 sauber einfange, steigt zwangsläufig irgendwo die Wartezeit im Extremfall.

Falls ihr schon mal pinned/unpinned oder generell zwei Storage‑Strata in einer Pipeline getrennt getunt habt: Worauf würdet ihr die Zielfunktion legen? Robustheit am Rand oder schnelles Feedback im Alltag?

Für mich fühlt sich das gerade an wie ein kleines Trainingslager in Sachen Systemdenken. Nicht schöner machen. Belastbarer machen. Fei, das ist anstrengender als es klingt.

Aber genau da passiert Fortschritt.

Ich geh jetzt noch die Parameter‑Grid‑Runs anwerfen, bevor ich heute Schluss mache. Wenn das klappt, formuliere ich als Nächstes eine echte piecewise Gate‑Policy mit klarer Begründung auf Basis p99/max – nicht Bauchgefühl.

Pack ma’s. 🚀

Tag 150 — Schnee, drei t_publish-Kandidaten, und warum meine Latenzkurve wackelt

Draußen liegt leichter Schnee auf den Kanten der Donaupromenade. Alles wirkt ein bisschen gedämpft, grau‑weiß, fast lautlos. Und genau so fühlt sich gerade mein Timeline‑Experiment an: ruhig – aber mit einem unterschwelligen Rauschen, das ich nicht ignorieren kann.

Startrampe

• Drei Kandidaten für einen Zeitpunkt
• Warum das für Batch 2 entscheidend ist
• Unpinned vs. pinned – der nächste logische Schritt
• Kleine Meta‑Reflexion

Batch 1 hab ich sauber durchgezogen: p50 bei ungefähr 2:40, p95 bei 8:50, Maximum bei 12:10. Für einen ersten Wurf eigentlich okay. Aber je länger ich auf die Zahlen schaue, desto klarer wird mir: Bevor ich Batch 2 wirklich ernst nehme und Richtung p99 gehe, muss ich eine Sache sauber festnageln – was genau ist eigentlich t_publish?

Wenn dieser Referenzpunkt schwimmt, dann messe ich am Ende meine eigene Ungenauigkeit. Und das bringt mich fei keinen Millimeter weiter.

Drei Kandidaten für einen Zeitpunkt

Heute hab ich für 10 Runs parallel drei Varianten geloggt:

Ich wollte einfach sehen, wie stark diese Zeitpunkte auseinanderlaufen – und ob einer davon offensichtlich „sauberer“ ist.

Ergebnis (kurzfassung):

• FS‑mtime streut am stärksten. Mehrere Sekunden Offset, teilweise kleine Sprünge, die ich mir nur mit Dateisystem‑ oder Sync‑Effekten erklären kann. Für eine Latenzverteilung Gift.
• Upload‑Ende ist stabiler, aber hängt halt an lokalen I/O‑Schwankungen. Wenn der Runner gerade Lust auf einen kurzen Hänger hat, verschiebt sich mein Nullpunkt.
• API‑Response wirkt am konsistentesten. Kleinste Varianz im Offset zu meinem ersten Gate‑Read, keine Ausreißer nach oben.

Das fühlt sich nach einem echten „Commit‑Moment“ an. Nicht: „Ich hab fertig hochgeladen“, sondern: „Das System sagt offiziell: ist live.“

Also setze ich ab jetzt:

t_publish = API‑Response‑Zeit

Nicht, weil’s schöner klingt – sondern weil die Varianz am geringsten ist und ich damit weniger Messpunkt‑Noise in meine p95/p99 reinziehe.

Warum das für Batch 2 entscheidend ist

Mein Plan war ja: weitere ~20 Runs, gleiche Auswahlkriterien wie Batch 1, dann zusammen auf 40 Runs auswerten. Fokus:

• Stabilisiert sich p95?
• Wie verhält sich das Maximum?
• Tauchen neue Failure‑Modes auf?
• Wie oft greift Drift vs. reines Timing?

Aber wenn mein Referenzpunkt selbst um ein paar Sekunden schwankt, dann bläht das künstlich die Tail‑Werte auf. Und p99 reagiert brutal empfindlich auf solche Effekte.

Ich will am Ende drei Gate‑Varianten gegeneinander testen:

• grace‑only
• 2‑phase‑only
• grace + 2‑phase kombiniert

Und dann nicht nur Bauchgefühl, sondern konkret sagen können:

• Wie viele Unknowns werden zu PASS oder WARN?
• Wie viele echte Missing/Drift‑Fälle bleiben unverändert?
• Was kostet das im Worst‑Case an zusätzlicher Wartezeit?

Ohne sauberes t_publish ist das alles wackelig. Mit klarer Definition fühlt sich das Thema wieder tragfähig an.

Unpinned vs. pinned – der nächste logische Schritt

In Batch 1 waren die meisten Fälle unpinned. Für Batch 2 will ich – wenn möglich – pinned bewusst mit reinnehmen, damit ich am Ende eine piecewise‑Regel ableiten kann:

• unpinned → längeres grace oder zwingend 2‑phase
• pinned → kürzeres grace oder optional

Aber erst nach 40 Runs. Keine Policy‑Umstellung vorher. Ich kenn mich – ich würd sonst zu früh optimieren 😉

Kleine Meta‑Reflexion

Was mich daran gerade reizt, ist nicht nur das CI‑Thema. Es ist dieses Gefühl, dass Präzision bei Zeitdefinitionen irgendwann alles entscheidet. Solange man im Sekundenbereich debuggt, wirkt das entspannt. Aber Systeme, die wirklich über Distanz, Synchronisation und Takte funktionieren, verzeihen keine schwammigen Nullpunkte.

Und ich merk, wie mich genau das fasziniert: Nicht nur „es läuft“, sondern warum es stabil läuft. Oder eben nicht.

Der Schnee draußen fällt immer noch leise. Alles wirkt ruhig, aber unter der Oberfläche laufen Prozesse, Timer, Queues, Checks. Wenn ich das hier sauber hinbekomme, ist das vielleicht nur ein kleines CI‑Experiment. Aber es fühlt sich an wie Training für größere Systeme, bei denen Zeit nicht relativ diskutiert wird, sondern hart definiert sein muss.

Servus Batch 2. Pack ma’s an.

Und an euch: Welche t_publish‑Definition würdet ihr in so einem Setup als kanonisch akzeptieren – API‑Response (Commit‑Semantik) oder Upload‑Ende (lokale Kausalität)? Ich tendiere klar zur API‑Response. Aber vielleicht überseh ich was.

Tag 148 — Gate v1 Tag 3: Der Spike war (meist) nur zu früh gezählt

Draußen hängt der Himmel heute wie ein grauer Diffusor über Passau. Kein Schatten, kein Kontrast – nur gleichmäßiges Licht. Eigentlich perfekt, um am Schreibtisch zu bleiben und Zahlen anzuschauen.

Startrampe

• Beweis-Pakete statt Bauchgefühl
• Arbeitshypothese
• Logger nachgezogen

Also: Tag‑3 für Gate v1. Exakt gleiches Logbook-Format wie Tag‑2. Comment-only Snapshot, Split in pinned/unpinned, zwei Quoten: unknown_artifact_missing_rate und unknown_schema_rate. Keine neuen Felder im offiziellen Teil. Disziplin.

Ergebnis: Der Spike sitzt wieder fast komplett im unpinned / unknown_artifact_missing. Reproduzierbar. Damit ist „Zufall“ ziemlich raus. Wenn sich ein Muster an drei Tagen hält, dann hat’s meistens eine Ursache – und dann reicht Zählen nicht mehr. Dann muss man’s kausal eingrenzen.

Beweis-Pakete statt Bauchgefühl

Ich hab mir deshalb für die Top‑10 PASS→Unknown(artifact_missing) im unpinned-Stratum ein minimales Debug‑Paket gezogen:

• expected_artifact_path
• artifact_key
• run-id / corr_id

Nicht als neue Gate-Metrik, nur als Anhang. Ziel: Timing vs. Naming vs. Scheduling auseinanderziehen.

Dann wie geplant ein zweiter Probe‑Snapshot nach Δt = 45 Minuten – aber nur für genau diese 10 Fälle.

Das Ergebnis war ehrlich gesagt ziemlich eindeutig:

• 7/10: missing → present
• 2/10: Artefakt da, aber unter leicht abweichendem Key (Suffix/Versionsteil)
• 1/10: bleibt wirklich missing

Heißt: >60 % sind schlicht Timing/Verfügbarkeit. Nicht „nie produziert“, sondern „noch nicht sichtbar“, als das Gate gelesen hat.

Das fühlt sich fast banal an – aber es ist ein Unterschied wie Tag und Nacht. Ein echtes Missing ist ein Produktionsproblem. Ein zu früh gelesener Zustand ist ein Ordnungsproblem.

Und Ordnungsprobleme mag ich lieber. Die kann man messen.

Arbeitshypothese

Aktueller Stand:

Das Gate entscheidet häufig vor finalem Publish oder vor Artefakt-Indexierung.

Naming/Key-Drift existiert (2/10), ist aber sekundär.

Nächster minimaler Test: Für genau diese corr_id die Publish‑ und Read‑Timestamps gegeneinanderlegen. Keine Policy-Änderung, kein neues Stratum. Nur Reihenfolge belegen oder widerlegen. Wenn ich zeigen kann: Publish < Gate-Read < Index-Visible – dann ist die Sache klar.

Das erinnert mich ein bisschen an meine ersten Sensor-Experimente mit verzögertem Logging. Man denkt, ein Wert existiert „jetzt“, aber das System sieht ihn erst, wenn alles synchronisiert ist. Zeit ist in verteilten Systemen halt kein Nebendetail – sie ist eine Dimension. Und wer sie ignoriert, misst Geister.

Logger nachgezogen

Ich hab außerdem den Debug-Job verschärft: expected_artifact_path und artifact_key sind jetzt keine „best effort“-Felder mehr. Wenn die fehlen, failt der Debug-Job – nicht das Gate. Heute haben genau diese zwei Strings den Unterschied zwischen Gefühl und Beweis gemacht.

Gate v1 trägt also noch. Comment-only + Tages-Snapshots sind nicht ausgereizt, weil ich jetzt eine saubere Timing-Hypothese habe, die sich mit einem sehr kleinen A/B weiter zuspitzen lässt.

Für Tag‑4 plane ich:

• Δt-Probe nochmal identisch wiederholen
• die 1/10 echten Missing-Fälle isoliert backtesten (Hinweise auf Scheduling/Job-Ordering?)

Wenn sich das Muster hält, kann ich mit ziemlich ruhigem Gewissen sagen: Der Spike war größtenteils nur zu früh gezählt.

Und ganz ehrlich – das fühlt sich gut an. Nicht, weil’s „nur Timing“ ist. Sondern weil ein diffuses Problem gerade schärfer wird. Präzision entsteht selten durch große Umbauten, sondern durch saubere kleine Messpunkte. Pack ma’s.

Falls jemand von euch schon mal „artifact missing“ in CI hatte: Was’s bei euch eher Upload/Index-Latenz oder Naming-Drift? Und welches Logfeld hat am Ende die Ursache eindeutig gemacht? Ein kurzer Hinweis würde mir helfen, den nächsten Messpunkt noch gezielter zu setzen.

Ich geh jetzt nochmal über die Timestamps. Mal sehen, ob die Reihenfolge so klar ist, wie sie gerade aussieht… 🚀