Quality-Gate System — Critical Assessment, Catalog and Replication Playbook (Deutsch)

Teil 1 — Fazit und Reifegradklassifizierung

Gesamtnote: A− / „Fortgeschritten“. Unter den besten ~5–10 % der Projekte. Das System implementiert unabhängig mehrere Muster, die in der Branche ausdrücklich benannt werden — dies ist das stärkste Übereinstimmungssignal (wir haben keine Checkliste kopiert, sondern sind zu den richtigen Praktiken konvergiert).

Referenz-Framework	Unser Stand	Bewertung
OWASP DSOMM (5 Stufen, 5 Dimensionen)	Solide auf Stufe 3, mit Annäherung an Stufe 4 bei Testintensität und statischer Analysetiefe. Die meisten Organisationen befinden sich auf Stufe 1–2.	L3→L4
OpenSSF Scorecard (18 Prüfungen)	Wir bestehen CI-Tests, Code-Review, Dependency-Update-Tool, Fuzzing, SAST, Signed-Releases (Provenance), Token-Permissions, Vulnerabilities und Dangerous-Workflow. Lücken: Branch-Protection auf main ist AUS; einige Actions sind nicht auf feste Versionen gepinnt.	~7–8/10
SLSA (4 Stufen)	npm publish --provenance + id-token: write + von GitHub gehosteter Build = L2, mit Annäherung an L3. Für L3+ fehlt ein gehärteter/hermetischer Builder.	L2→L3
SonarQube „Clean as You Code“	Identische Philosophie: Das Ratchet verhindert Regressionen (neuer Code verschlechtert die Metrik nicht). Abweichung: Sonar empfiehlt wenige Bedingungen; wir haben ~46 Gates (Risiko von Ermüdungserscheinungen).	Ausgerichtet, mit Vorbehalt
Quality-Ratchet-Muster	Referenzimplementierung: Ratchet + dedicatedGate + tightenSlack + --require-tighten + elegantes Überspringen. Ausgereifter als die meisten öffentlichen Beispiele.	Vorbildlich
DORA 2024	Sehr stark auf der Achse Stabilität. Risiko: Umfangreiche Gates können die Durchlaufzeit erhöhen — gemildert durch die Aufteilung in schnelle Gates, jedoch mit einer Abdeckungslücke (siehe Teil 2).	Stark (Stabilität)
OWASP LLM Top 10 (2025)	Wir decken Risiko Nr. 1 (Prompt-Injection) mit Laufzeitschutz + promptfoo (Evaluierung) + garak (Red-Teaming) ab. Branchenübliche Standardtools.	Abgedeckt
Mutationstests	Stryker nächtlich, Schwellenwerte 70/50, 8 kritische Module. Branchenkonsens (60 % für bestehenden / 80 % für neuen Code, nächtlich) — wir übertreffen ihn. Lücke: Der Score ist noch kein Ratchet.	Fast erreicht

---

Teil 2 — Kritische Bewertung (Stärken + ehrliche Schwächen)

Stärken (was überdurchschnittlich ist)

1. Multi-Metrik-Ratchet-Engine. Das Herzstück des Systems. 24 Metriken in quality-baseline.json
   • 4 dedizierte Baselines, jeweils mit Richtung (up/down), Toleranz (eps), Spielraum (tightenSlack) und dedicatedGate-Flag. Dinge, die behoben werden, bleiben behoben — das ist das Gegenmittel gegen die Entropie der Codebasis.
2. Mehrschichtige Absicherung der Lieferkette. SAST (CodeQL/Sonar) + Secrets (gitleaks mit useDefault) + SCA (osv/npm-audit/Trivy/Dependabot) + Lizenzen + Lockfile + SBOM + SLSA- Provenienz + Scorecard + Workflow-Härtung (zizmor). Nur wenige Codebasen verfügen über einen derart vollständigen Stack.
3. Gegenmittel gegen Goodharts Gesetz. Coverage als Zielvorgabe ist ein klassisches Anti-Pattern („Wenn eine Messgröße zum Ziel wird, ist sie keine gute Messgröße mehr“). Wir haben die Gegengewichte: Mutationstests (messen, ob ein Test den Fehler erkennt, nicht nur, ob er die Zeile ausführt), check-test-masking (verhindert das Abschwächen von Assertions, nur um Tests zu bestehen), Coverage-Mindestwerte pro Modul (erzwingen das Testen von Code mit HOHEM Risiko, nicht nur der einfachen Teile) und check-pr-evidence (Feste Regel Nr. 18).
4. Anti-Halluzinations-/Konsistenz-Gates. Eine seltene und wertvolle Kategorie: check-known-symbols, check-fetch-targets, check-openapi-routes, check-docs-symbols stellen sicher, dass Dokumentation, Spezifikationen und String-basierte Dispatches auf tatsächlich existierende Symbole verweisen. Erfasst „Verfall“, den Linting und Tests nicht erkennen.
5. Lebenszyklus von „informativ“ zu „blockierend“. Neue Gates werden zunächst informativ eingeführt (sie blockieren keine Merges, während sie ausreifen) und werden am Ende des Zyklus blockierend. Reduziert Reibungsverluste, ohne die Qualitätsobergrenze aufzugeben.
6. Sauberes Überspringen bei fehlender Infrastruktur. Scanner (--ratchet) werden mit exit 0 beendet, wenn Binärdatei oder Netzwerk ausfallen — fehlende Infrastruktur blockiert niemals einen legitimen PR. Reifes Engineering.
7. Kodifizierte Kultur. Feste Regeln + trust-but-verify + Stale-Allowlist + Evidence-Gate machen aus Disziplin eine automatisierte Verifikation.

Ehrliche Schwächen (echte Lücken)

1. 🔴 Die Aufteilung der schnellen Gates hinterlässt weiterhin eine strukturelle Lücke. quality.yml (PR→release/**) führt nun Typechecking, schnelle deterministische Tests und für Code-PRs einen informativen Produktions-Build aus, deckt aber weiterhin nicht die vollständige Release-PR-Prüfoberfläche aus ci.yml ab (Coverage-Ratchets, Paketartefakt, Integration, E2E, SonarQube). Die Motivation (Geschwindigkeit) ist nachvollziehbar, aber das Gate sollte dort liegen, wo der Merge stattfindet (Shift-left). Größte noch ausstehende strukturelle Korrektur.
2. 🟠 Risiko von Gate-Wildwuchs und -Müdigkeit. ~46 Gates + 25 Jobs sind SEHR VIEL. Sonar warnt selbst: Zu viele Bedingungen führen zu „Gate-Müdigkeit“ und Priorisierungsdebatten, wodurch das Risiko besteht, dass ein Gate ignoriert wird. DORA warnt davor, dass schwergewichtige Gates die Durchlaufzeit verlängern. Wir wirken dem mit informativen Stufen und nicht absoluten Ratchets entgegen, aber eine regelmäßige ROI-Prüfung pro Gate fehlt (einige Mikro-Gates für die Dokumentationssynchronisierung könnten zusammengeführt werden).
3. 🟠 Der Mutationsscore ist noch kein Ratchet. Das stärkste Gegenmittel gegen die Manipulation von Coverage ist informativ. Es ist der wertvollste noch ausstehende Punkt (und bereits zu 90 % fertiggestellt).
4. 🟡 Informative Prüfungen, die blockieren sollten (mit dem richtigen Umfang). osv (vulnCount) und oasdiff sind trotz eingefrorener Baselines informativ. Der informative Status von osv ist nachvollziehbar (eine neue CVE in einer alten Abhängigkeit würde einen nicht damit zusammenhängenden PR blockieren) — es gibt jedoch einen Mittelweg (nur KRITISCHE und behebbare Schwachstellen blockieren, wie bei Trivy). Der informative Status von oasdiff bedeutet, dass eine vertragsbrechende Änderung durchgelassen werden kann.
5. 🟡 Laufzeitsicherheit wird nur nachts geprüft. schemathesis/garak/promptfoo/chaos/k6 laufen nachts. Eine richtige Entscheidung (langsam, benötigen einen laufenden Server), aber ein PR kann eine Regression beim Schutz vor Injections einführen, die erst in der folgenden Nacht erkannt wird.
6. 🟡 Der Branch-Schutz für main ist DEAKTIVIERT. BRANCH_LOCK_TOKEN sperrt Release-Branches, aber main selbst ist ungeschützt. Führt zu Abzügen bei Scorecard/DSOMM. Maßnahme durch den Owner erforderlich.
7. 🟡 CodeQL-Standardkonfiguration; semgrep nicht kodifiziert. Die Standardkonfiguration funktioniert (0 Alerts), aber eine committete codeql.yml bietet mehr Kontrolle; semgrep läuft über eine externe Cloud-Plattform und ist nicht im Repository versioniert.

---

Teil 3 — Vollständiger Katalog der Qualitätsprüfpunkte (portabel)

Die folgenden 12 Kategorien bilden das „Qualitätssystem“ in wiederverwendbarer Form. Jede Kategorie nennt das Ziel (was geschützt werden soll), die von uns verwendeten Werkzeuge und das werkzeugunabhängige Äquivalent zur Nachbildung auf jedem beliebigen Stack.

1. Stil & Formatierung (deterministisch, schnell)

• OmniRoute: Prettier + ESLint über lint-staged (Pre-Commit), 2 Leerzeichen/doppelte Anführungszeichen/100 Spalten.
• Generisch: ein automatisch korrigierender Formatierer + ein Linter, die beim Pre-Commit für bereitgestellte Dateien ausgeführt werden.

2. Typen

• OmniRoute: typecheck:core (blockierend) + typecheck:noimplicit:core (beratend) + type-coverage-Ratsche bei 92.17 % + any-Budget pro Datei.
• Generisch: strikte Typprüfung in CI + schrittweise verschärfte Typabdeckungsmetrik + Budget pro Datei für any/Ausweichmechanismen.

3. Tests (Intensität)

• OmniRoute: 2 nicht überlappende Runner (natives Node + vitest), 8 Shards, globale Abdeckung 60/60/60/60 + Ratsche bei ~76 % + 8 Mindestwerte pro Modul für kritische Module + nächtliche Property-Tests + nächtliche Mutationstests.
• Generisch: Test-Runner + absoluter Mindestwert für die Abdeckung (gegen Nullabdeckung) + Abdeckungs-Ratsche (gegen Regressionen) + Mindestwerte pro Modul für risikoreichen Code (gegen Goodhart-Effekte) + eigenschaftsbasierte Tests für reine Logik + nächtliche Mutationstests als tatsächliches Maß für die Testqualität.

4. Testrichtlinie (gegen Manipulation)

• OmniRoute: pr-test-policy (Produktionscode erfordert einen Test), check-test-masking (blockiert abgeschwächte Assertions), pr-evidence (Erfolgsmeldung erfordert einen Nachweisblock), test-discovery (jeder Test wird von einem Runner erfasst).
• Generisch: Gate nach dem Prinzip „neuer Code ⇒ neuer Test“ + Erkennung entfernter Assertions/Tautologien + Nachweispflicht (TDD oder lebender Test) + Garantie, dass kein Test außerhalb der Globs verwaist.

5. Komplexität & Codezustand (Ratschen)

• OmniRoute: ESLint-Warnungen (3769↓), jscpd-Duplizierung (5.72 %↓), zyklomatische Komplexität + maximale Zeilenzahl (1800↓), kognitive Komplexität mit sonarjs (753↓), toter Code/unbenutzte Exporte mit knip (339↓), Dateigröße pro Datei (eingefroren, darf nur sinken), zyklische Abhängigkeiten (benutzerdefinierter Tarjan-Algorithmus, blockierend).
• Generisch: jede Zustandsmetrik mit einer Ratsche versehen (Warnungen, Duplizierung, zyklomatische und kognitive Komplexität, toter Code, Dateigröße, Importzyklen). Die Richtung lautet immer: „keine Regressionen“.

6. Statische Sicherheit (SAST + Geheimnisse)

• OmniRoute: CodeQL (Ratsche für Warnungen = 0), gitleaks ([extend] useDefault=true — entscheidend!), SonarQube, benutzerdefinierte Sicherheitsregeln (öffentliche Zugangsdaten, Fehler-Helper, Mitgliedschaft bei Routen-Gates, Routenvalidierung).
• Generisch: SAST (CodeQL/Sonar/semgrep) mit Warnungsratsche + Geheimnisscanner mit geerbtem Standardregelsatz (eine benutzerdefinierte Konfiguration, die den Standard überschreibt, macht blind) + projektspezifische Sicherheits-Gates für harte Regeln.

7. Lieferkette (Abhängigkeiten)

• OmniRoute: osv-scanner + npm-audit + Trivy + Dependabot (SCA), license-checker (SPDX-Zulassungsliste), lockfile-lint (HTTPS+sha512+Registry), check-deps gegen Slopsquatting (Zulassungsliste + Alter ≥72 h).
• Generisch: SCA aus mehreren Quellen + Lizenz-Zulassungsliste + Integritätsprüfung der Lockdatei + Abhängigkeits-Zulassungsliste mit Alters-/Typosquatting-Prüfung + Bot für gruppierte Aktualisierungen.

8. Lieferkette (Build & Release)

• OmniRoute: SBOM (CycloneDX + syft), SLSA-Herkunftsnachweis (--provenance), OpenSSF Scorecard (wöchentlich), Workflow-Härtung (zizmor: artipacked→persist-credentials:false, Cache-Poisoning, Token-Berechtigungen).
• Generisch: beim Veröffentlichen eine SBOM erzeugen + signierter Herkunftsnachweis (SLSA L2+) + geplante Scorecard-Prüfung + alle Workflows härten (Tokens mit minimalen Berechtigungen, keine persistenten Zugangsdaten bei Checkouts ohne Push-Berechtigung, Actions per SHA fixiert).

9. Verträge & API

• OmniRoute: oasdiff (Breaking Changes in OpenAPI), schemathesis (nächtliches Contract-Fuzzing), openapi-coverage (% dokumentierte Routen, Ratsche bei 38.3 %), openapi-security-tiers (Spezifikation vs. Routen-Gate).
• Generisch: Vertrags-Diff für Breaking Changes (oasdiff/buf) + eigenschaftsbasiertes Fuzzing gegen die Spezifikation (schemathesis) + schrittweise verschärfte Dokumentationsabdeckung + Konsistenz zwischen Spezifikation und Code.

10. Dokumentation & i18n (gegen Verfall)

• OmniRoute: docs-sync (gespiegelte Versionen), docs-counts-sync (Zahlen in der Dokumentation vs. Code), env-doc-sync, doc-links, fabricated-docs, cli-i18n, i18n-ui-coverage (--threshold=65 + Ratsche bei 80.1 %).
• Generisch: Versionen/Zahlen/Umgebungsvariablen zwischen Dokumentation und Code synchronisieren (Gate statt Vertrauen) + interne Links validieren + schrittweise verschärfte i18n-Abdeckung.

11. Gegen Halluzinationen/Konsistenz (die seltene Kategorie)

• OmniRoute: known-symbols (String-Dispatch ⇒ existierendes Symbol), provider-consistency, fetch-targets (Client-Fetch ⇒ reale Route), docs-symbols, db-rules (harte Regeln #2/#5), migration-numbering.
• Generisch: für jede „duplizierte Wahrheitsquelle“ (Registry, String-Dispatch, schichtübergreifende Referenzen) ein Gate, das die Übereinstimmung beider Seiten nachweist. Erfasst den Verfall, den Typprüfung und Tests nicht erkennen.

12. Resilienz & Domäne (produktspezifisch)

• OmniRoute: Chaos (Fehlerinjektion), Heap-Wachstum (Lecks), k6 (Dauertest), promptfoo+garak (LLM-Red-Teaming gemäß OWASP LLM Top 10), die 3 Resilienzgesetze (Circuit-Breaker/Cooldown/Lockout).
• Generisch: die Fehlermodi Ihrer Domäne identifizieren und für jeden ein Gate einrichten, auch wenn es nur nächtlich ausgeführt wird. Für KI-Anwendungen: Red-Teaming gegen Injektionen. Für verteilte Systeme: Chaos- + Leck- + Dauertests.

---

Teil 4 — Replikationsplan für jedes Projekt

Bauen Sie in Phasen, von denen jede für sich einen Mehrwert liefert. Versuchen Sie nicht, alle 12 Kategorien gleichzeitig umzusetzen — das führt genau zu der Gate-Ermüdung, vor der Teil 2 warnt. Jedes neue Gate beginnt im Modus Advisory und wird blockierend, sobald es stabil ist.

Das wiederverwendbare Herzstück: die „Anatomie eines Ratchet-Gates“

Das gesamte System basiert auf diesem Muster aus 3 Dateien. Kopieren Sie es zuerst:

1. baseline.json — der eingefrorene Metrikwert + direction (up/down) + eps (gegen Flakiness) + tightenSlack + dedicatedGate.
2. collect-metrics.<ext> — führt das Tool aus, extrahiert den Wert und schreibt ihn in metrics.json.
3. check-ratchet.<ext> — vergleicht metrics.json mit baseline.json; exit 1 nur, wenn eine Regression über eps hinaus vorliegt; exit 0 (kontrolliertes Überspringen), wenn das Tool/die Infrastruktur fehlte; mit --require-tighten wird exit 1 ausgelöst, wenn sich der Wert verbessert hat, ohne dass die Baseline aktualisiert wurde (die Verbesserung wird dadurch festgeschrieben).

Sobald dies eingerichtet ist, ist jede neue Metrik (Abdeckung, Komplexität, Warnungen, SAST-Warnmeldungen, Bundle-Größe, Mutationswert …) nur noch eine weitere Zeile in der Baseline.

Phase 0 — Grundlage (Woche 1)

CI ist vorhanden; Formatter + Linter + Typprüfung + 1 Test-Runner + absolute Mindestabdeckung (z. B. 60 %). Pre-Commit führt schnelle, automatisch korrigierbare Prüfungen aus. Ergebnis: Kein PR verletzt die Grundlagen.

Phase 1 — Die Ratchet-Engine (Woche 2) — die Grundlage für alles

Implementieren Sie die 3 oben genannten Dateien. Frieren Sie Baselines ein für: Warnungen, Abdeckung, Komplexität, Duplikation, toten Code und Dateigröße. Ergebnis: Die Codebasis kann sich von nun an nur noch verbessern.

Phase 2 — Statische Tiefenprüfung (Woche 3)

SAST (CodeQL/Sonar/semgrep) mit Warnmeldungs-Ratchet; Secrets-Scanner (das standardmäßige Regelwerk übernehmen); SCA (osv/Dependabot) + Lizenz-Positivliste + lockfile-lint. Ergebnis: Bekannte Schwachstellen und offengelegte Secrets passieren die Prüfung nicht.

Phase 3 — Build-Lieferkette (Woche 4)

SBOM bei der Veröffentlichung + signierter Herkunftsnachweis (SLSA L2) + planmäßige Scorecard-Ausführung + Workflow-Härtung (zizmor: minimale Token-Berechtigungen, keine persistierten Zugangsdaten, fest angeheftete Actions). Ergebnis: nachvollziehbare und manipulationssichere Releases.

Phase 4 — Testintensität (Woche 5–6)

2. Runner, falls sinnvoll; Mindestabdeckung pro Modul für kritische Module (Anti-Goodhart); eigenschaftsbasierte Tests für reine Logik; nächtliche Mutationstests → sobald der 1. Wert vorliegt, wird mutationScore zu einem Ratchet. Ergebnis: Abdeckung ist keine reine Prestige-Metrik mehr; Tests fangen nachweislich Fehler ab.

Phase 5 — Verträge & dynamische Prüfungen (Woche 7)

Falls es eine öffentliche API gibt: oasdiff (Breaking Changes, blockierend) + schemathesis (nächtliches Fuzzing). Nächtliche DAST-/Red-Team-Tests, soweit für die Domäne angemessen. Ergebnis: Verträge werden nicht unbemerkt gebrochen.

Phase 6 — Anti-Halluzination & Domäne (Woche 8)

Ein Konsistenz-Gate für jede „duplizierte Wahrheit“ im Projekt. Domänenspezifische Fehlermodus-Gates (für KI: Red-Teaming gegen Injection-Angriffe). Ergebnis: Struktureller Verfall und domänenspezifische Fehler sind durch ein Sicherheitsnetz abgesichert.

Phase 7 — Governance (fortlaufend)

• Advisory→Blocking-Zyklus für jedes neue Gate.
• stale-allowlist: Jede Unterdrückung enthält eine Begründung + ein Issue; veraltete Unterdrückungen werden erkannt.
• evidence-gate: Eine Erfolgsaussage in einem PR erfordert einen Nachweis (Test oder Living Test).
• Vierteljährliche ROI-Prüfung für jedes Gate (nicht rentable Gates entfernen oder ihre Finanzierung einstellen — wirkt Ermüdung entgegen).
• Überführen Sie die Hard Rules Ihres Projekts in ausführbare Gates.

Übergreifende Prinzipien (nicht verhandelbar)

• Ratchet statt absolutem Wert. Verhindern Sie Regressionen, statt einen festen Wert vorzugeben (mit Ausnahme von Mindestwerten über null).
• Absoluter Mindestwert und Ratchet gemeinsam. Der Mindestwert verhindert einen Einbruch; das Ratchet verhindert eine schleichende Verschlechterung.
• Anti-Goodhart als Designprinzip. Jede Zielmetrik benötigt ein Gegengewicht (Abdeckung ⇒ Mutation + Schutz vor Verschleierung; Mindestwerte pro Modul erzwingen Tests für den schwierigen Code).
• Kontrolliertes Überspringen. Fehlende Infrastruktur blockiert nie; nur eine echte Regression blockiert.
• dedicatedGate für aufwendige Metriken. Metriken, die ein externes Binärprogramm benötigen, erhalten ein eigenes Skript (mit Möglichkeit zum Überspringen), außerhalb des synchronen zentralen Ratchets.
• Platzieren Sie das Gate dort, wo der Merge stattfindet. Lassen Sie keine Lücke zwischen dem schnellen Gate und dem tatsächlichen Merge (die Lehre aus der Aufteilung der Fast Gates).
• Wenige, sorgfältig ausgewählte blockierende Gates. Sonar/DORA: Zu viele Bedingungen führen zu Ermüdung. Bevorzugen Sie Advisory + Ratchet gegenüber einer Wand aus blockierenden Gates.

---

Teil 5 — Empfohlene Verbesserungen (priorisiert, kompatibel)

P0 — höchster ROI, fast fertig

1. Mutation-Score-Ratchet (nachdem der erste nächtliche Stryker-Lauf Werte erzeugt hat). Wichtigstes Gegenmittel gegen Coverage-Goodhart; zu ~90 % fertig.
2. Die verbleibende Lücke bei den Fast-Gates schließen — den Produktions-Build in quality.yml nach seiner einwöchigen Hinweisphase verbindlich machen und weiterhin deterministische, nur für Release-PRs ausgeführte Prüfungen in den PR→Release-Pfad verschieben.
3. Branch-Protection für main (Owner-Einstellung) — verbessert den Scorecard-Wert und schließt die DSOMM-Lücke.

P1 — wertvoll 4. osv/oasdiff → blockierend mit dem richtigen Umfang — osv nur für CRITICAL+behebbar (zweistufig wie Trivy); oasdiff blockiert Breaking Changes. 5. require-tighten → blockierend (am Ende des Zyklus) — sichert Verbesserungen der Metriken ab. 6. ROI-/Laufzeitprüfung pro Gate in ci-summary — langsame Gates mit geringem Nutzen identifizieren und entfernen.

P2 — abnehmender Grenznutzen 7. SLSA L3 — hermetischer/reproduzierbarer Builder (GitHub SLSA generator), wenn ihr von L2 aufsteigen möchtet. 8. Versionierte CodeQL-Konfiguration + versioniertes semgrep — mehr Kontrolle/Reproduzierbarkeit. 9. DAST-Smoke-Test pro PR — schnelle Teilmenge von schemathesis/promptfoo für Endpunkte mit dem höchsten Risiko (nicht nur nachts). 10. Flakiness-Dashboard + DORA-Metriken — sicherstellen, dass Gates die Geschwindigkeit nicht beeinträchtigen.

---

Teil 6 — Konkrete Erkenntnisse aus Releases (in Phase 9 hinzuzufügende Gates)

Dieser Abschnitt dokumentiert reale Vorfälle bei Release-Abschlüssen, bei denen ein Gate fehlte, einschließlich konkreter Belege und des vorgeschlagenen Gates. Jeder Punkt ist ein Kandidat für Teil 5.

Erkenntnis aus v3.8.27 (2026-06-17) — die „Fast-Gates-Lücke“ lässt deterministische Regressionen bis zum Release-Tag durch

Was geschah. Während /generate-release für v3.8.27 war der Release-PR (release/v3.8.27 → main) die erste Ausführung der vollständigen ci.yml-Matrix im integrierten Zyklus. Ergebnis: 12 gleichzeitig fehlgeschlagene Prüfungen — 3 deterministische Tests + ~9 Flakes/Umgebungsfehler. Keine davon waren aktive Produktregressionen, aber alle blieben unbemerkt, weil Zyklus-PRs über das Fast QG (quality.yml) in release/** gelangen, das weder die vollständige Unit-Test-Suite noch pr-test-policy (Test-Masking) noch die vollständige Integrationssuite noch die Prüfung der Schemaparität ausführt. Die drei deterministischen Fehler:

1. Durch UI-Änderung veralteter Test — permissions modal switch buttons declare button type: #4034 fügte einen vierten Schalter hinzu (a11y-type="button" blieb erhalten); die Anzahl === 3 des Tests war damit veraltet. Die statische Analyse hätte dies im PR #4034 erkennen müssen.
2. Durch Packaging-Änderung veralteter Test — findMissingArtifactPaths ... root runtime files: dist/http-method-guard.cjs wurde zu einem legitimen erforderlichen Pfad; die erwartete Liste des Tests war damit veraltet.
3. Verlustbehaftete Divergenz durch Modularisierung (am schwerwiegendsten) — settings schemas accept ... unprefixed toggle: Das modularisierte updateSettingsSchema (schemas/settings.ts, erstellt durch #3988) wich vom kanonischen Schema (settingsSchemas.ts) ab: 45 Felder gegenüber 85 — 40 entfernt + 6 abweichend (qdrant*). Es handelte sich um Dead Code (zur Laufzeit wird das kanonische Schema verwendet), sodass es keine aktiven Auswirkungen gab; erkannt wurde dies jedoch nur durch einen manuell geschriebenen Paritätstest. #4030 stellte 16 vergleichbare, durch #3988/#3993 entfernte Felder wieder her, doch dieses Problem blieb unentdeckt.

Vorgeschlagene Gates (Phase 9):

• G1 — Die Fast-Gates-Lücke tatsächlich schließen (erweitert P0 #2). In quality.yml (PR→release/**) zusätzlich zu Typecheck + betroffenen Tests auch pr-test-policy (Test-Masking) + die vollständige deterministische Unit-Test-Suite ausführen (oder zumindest die statischen/Paritätsdateien, die schnell und nicht flaky sind). So werden veraltete Tests und entfernte Assertions in dem PR erkannt, der sie einführt — und nicht erst am Release-Tag. Integration/e2e weiterhin ausschließen (langsam/flaky), aber die deterministische Schicht DARF NICHT ausschließlich in PR→main verbleiben.
• G2 — Gate für Modularisierungsparität (NEU, derzeit nicht abgedeckt). Eine Prüfung, die für jedes Symbol, das von einem modularisierten Barrel (src/shared/validation/schemas/*, providerRegistry- Module usw.) re-exportiert wird, die Struktur (z.object-Keys, Registry-Einträge) mit der kanonischen Quelle vergleicht und bei Abweichungen fehlschlägt (entferntes/zusätzliches Feld). Dies hätte die Entfernung der 40 Felder durch #3988 bereits in genau diesem PR erkannt. Verallgemeinert die manuell geschriebenen Paritätstests (die nur dort existieren, wo jemand daran gedacht hat, sie zu schreiben). Günstig: beide importieren und Object.keys(shape) vergleichen.
• G3 — Deterministische Flake-Triage (unterstützend). Die LiveWS-Startup- und Integration-Combo-/Breaker- Tests schlagen aufgrund von Server-Timeouts/Kaskaden in CI (Umgebung) fehl, nicht aufgrund der Logik. Diese als known-flaky markieren (mit Issue unter Quarantäne stellen), sodass ein roter Release-PR nur echte Signale enthält und nicht durch Rauschen deterministische Regressionen in der Mitte verschleiert.

Prinzip: Das Gate muss dort ausgeführt werden, wo der Merge stattfindet (bereits unter „Übergreifende Prinzipien“ aufgeführt). Der Vorfall bei v3.8.27 zeigt, dass dies auch für die deterministische Testschicht gilt, nicht nur für Lint/Typecheck — andernfalls wird die Last veralteter Tests + verlustbehafteter Modularisierung erst in PR→main sichtbar, gebündelt und zum ungünstigsten Zeitpunkt.

---

Quellen (Best Practices der Branche)

• OWASP DevSecOps Maturity Model (DSOMM) — https://dsomm.owasp.org/about
• OpenSSF Scorecard / SLSA — https://openssf.org · https://slsa.dev
• SonarQube „Clean as You Code“ — https://docs.sonarsource.com/sonarqube-server/latest/user-guide/clean-as-you-code
• Quality Ratchets (LeadDev) — https://leaddev.com/software-quality/introducing-quality-ratchets-tool-managing-complex-systems
• Kontinuierliche Codeverbesserung durch Ratcheting (Greiner) — https://robertgreiner.com/continuous-code-improvement-using-ratcheting/
• DORA 2024 State of DevOps — https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
• Best Practices für Mutationstests (Stryker) — https://stryker-mutator.io
• Testabdeckung als Anti-Pattern (Goodhart) — https://www.industriallogic.com/blog/code-coverage-complications/
• OWASP Top 10 für LLM-Anwendungen (2025) — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Vertragstests (oasdiff/schemathesis) — https://www.oasdiff.com · https://schemathesis.readthedocs.io

---

OmniRoute-Quellcode (a58000c7685f)