ci(status): STATUS.md-Drift im PR-Gate prüfen statt nach dem Merge#884
Conversation
Der status-sync-Job wurde am 17.05.2026 mit PR #516 entfernt, weil er nur auf push:main lief und sich mit contract-gates::status-sync-drift doppelte. Beides stimmte — nur blieb danach gar keine automatische Pruefung uebrig. Folge: docs/STATUS.md driftete unbemerkt. Backend-Testanzahl stand auf 3508, real waren es 3570. Aufgefallen ist das erst, als ein Backend-Slice am lokalen Gate haengenblieb. Der alte Job kommt nicht zurueck. Auf push:main haette er den Drift protokolliert, nicht verhindert. Die Pruefung laeuft jetzt als Step im backend-pr-gate, also auf dem PR. Kein eigener Job: uv, Dependencies und Checkout stehen dort bereits, der Frontend-Zaehler braucht nur das Repo — damit entfaellt auch die urspruenglich kritisierte Doppelung. Zusaetzlich sync-status.sh gehaertet: bisher setzte das Skript bei fehlgeschlagenem oder getimeoutetem `pytest --collect-only` still BACKEND_TESTS="unknown" und fuhr fort, worauf --check faelschlich DRIFT meldete. Als blockierendes Gate waere das flaky mit irrefuehrender Begruendung gewesen — genau die Flakiness, gegen die #516 antrat. --check unterscheidet jetzt Messfehler (exit 2, eigene Meldung) von echtem Drift (exit 1). STATUS.md einmalig synchronisiert, sonst waere das neue Gate ab dem ersten PR rot. Refs #883 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vo55HzjhQwyXQEJAzrF8TJ
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Comment |
1 participant
Closes #883
Release-Ziel
0.9.0Stability Beta. ROADMAP-Kriterium: "docs/STATUS.mdwird automatisch erzeugt oder CI-geprüft".Root Cause
Der
status-sync-Job wurde am 17.05.2026 mit PR #516 ("PR-Pipeline entschlacken, 13 → 6 Checks") entfernt. Die Begründung im Code war korrekt: er lief nur aufpush:mainund doppelte sich mit dem ebenfalls entferntencontract-gates::status-sync-drift.Übrig blieb allerdings gar keine automatische Prüfung.
docs/STATUS.mddriftete daraufhin unbemerkt: Backend-Testanzahl stand auf 3508, real waren es 3570 — 62 Tests Differenz, aufgelaufen über viele PRs. Aufgefallen ist es erst, als ein Backend-Slice am lokalen Gate hängenblieb.Warum nicht der alte Job zurück
Auf
push:mainläuft die Prüfung nach dem Merge. Sie hätte den Drift protokolliert, nicht verhindert — genau das ist passiert. Die Prüfung gehört auf den PR.Scope
1. Drift-Check als Step im bestehenden
backend-pr-gateKein eigener Job. Das Gate setzt uv, Dependencies und Checkout bereits auf, und der Frontend-Zähler braucht nur das Repo — der Step kostet damit kein zweites Setup. Nebeneffekt: die von #516 kritisierte Job-Doppelung entsteht gar nicht erst wieder.
2.
sync-status.shgehärtet — Messfehler ist kein DriftBisher setzte das Skript bei fehlgeschlagenem oder ins 180s-Timeout gelaufenem
pytest --collect-onlystillBACKEND_TESTS="unknown"und fuhr fort.--checkdiffte dann "unknown" gegen die dokumentierte Zahl und meldete "DRIFT: docs/STATUS.md weicht von autogenerated Inhalt ab" — obwohl kein Drift vorlag, sondern die Messung fehlgeschlagen war.Als blockierendes Pflicht-Gate wäre das flaky mit irreführender Fehlermeldung gewesen. Das ist exakt die Art Flakiness, gegen die #516 antrat; ohne diese Härtung hätte der Wiedereinbau den alten Fehler reproduziert.
--checkunterscheidet jetzt:3. STATUS.md einmalig synchronisiert (3508 → 3570)
Ohne das wäre das neue Gate ab dem ersten PR rot.
Out-of-Scope
Tests
Alle drei Pfade gezielt provoziert und verifiziert:
OK: docs/STATUS.md in syncuvnicht auffindbar (Messfehler)MESSFEHLER: … Das ist KEIN STATUS.md-DriftDRIFT: …YAML-Syntax per
yaml.safe_loadvalidiert, Step-Reihenfolge imbackend-pr-gategeprüft.Gate
bash scripts/pre-push-gate.sh backend→ALL GREEN, exit 0. Dersync-status --check-Schritt meldetOK: docs/STATUS.md in sync.Das ist der erste vollständig grüne Backend-Gate-Lauf dieser Serie — vorher blockierten nacheinander der ruff-Verstoß (PR #879) und dieser Drift.
Build-Verifikation
Entfällt — CI- und Skript-Änderung ohne Bundle-Auswirkung.
Subagents und Modelle
Vollständig vom Lead (Opus 5). Kleiner, präziser CI-Eingriff mit Design-Entscheidung (Step statt Job, Messfehler-Trennung) — ein Worker-Briefing wäre teurer als die Umsetzung gewesen.
Matt-Pocock-Skills
Keiner. Die Verifikation läuft über die drei provozierten Exit-Pfade, nicht über eine Testsuite;
sync-status.shhat keine.Dokumentationssync
docs/STATUS.mdauf den realen Stand gebracht. Derci.yml-Kommentar zur Entfernung von 2026-05-17 wurde nicht gelöscht, sondern um Rückkehr und Begründung ergänzt — die Historie bleibt nachvollziehbar.Review-Ergebnis
Lead-Review. Der kritische Punkt war nicht der Wiedereinbau selbst, sondern dass ein naiver Wiedereinbau ein flakiges Pflicht-Gate erzeugt hätte. Deshalb die Härtung im selben Slice.
Risiken
pytest --collect-onlykostet im Gate rund 50 Sekunden. Vertretbar, weil kein zusätzliches Setup anfällt.Bleibt die Gesamt-Testanzahl in CI aus Umgebungsgründen hinter dem lokalen Wert zurück (etwa durch Import-Fehler bei optionalen Dependencies), meldet das Gate Drift statt Messfehler — der Collect-Lauf war ja erfolgreich, nur mit anderem Ergebnis. Sollte das auftreten, ist der nächste Schritt, die Backend-Zahl aus dem Auto-Block zu nehmen und nur die deterministischen Werte zu prüfen. Der erste PR gegen dieses Gate zeigt es.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Vo55HzjhQwyXQEJAzrF8TJ