Vom Scope zum nachvollziehbaren Finding.
Ein Review hat einen klaren Scope, eine Review-Art und gespeicherte Ergebnisse. Hier steht, wie die einzelnen Schritte zusammenarbeiten und welche Belege erhalten bleiben.
Unabhängige Aussagen.
Eine Aussage gehört zu genau einer Einheit und einer Review-Art. Ein Projekt-Review und ein Datei-Review sind verschiedene Aussagen; keine wird aus der anderen berechnet, und ein Aggregat ersetzt nie das Review einer anderen Ebene.
- ProjektSystemgestalt
- ModulGrenzen
- NamespaceKohäsion
- DateiImplementierung
- FunktionVerhalten
Korrektheit, Klarheit, Wartbarkeit. Architektur ist ein Aspekt der Projekt- und Modul-Code-Reviews, keine vierte Review-Art.
Deterministische Sensor-Belege kombiniert mit Agent-Urteil in einer Aussage. Ein eigener Review-Workflow im selben Paket: eigene Dateien, Prompts, Läufe und Bewertungen.
Eigener Sweep, eigene Sidecars. Ein Performance-Review erneuert nie Code- oder Security-Metadaten.
Das Repository besitzt seine Review-Wahrheit.
Jede geprüfte Einheit erhält ein kleines JSON-Dokument je Review-Art, abgelegt im selben Feature-Ordner wie der Code — .quality/reviews/files/file.<hash>.review-meta.code.json. Diffbar, portabel und versioniert wie jedes andere Artefakt. Historie ist gewöhnliche Git-Historie; der Score-Trend wird aus Commits rekonstruiert, nicht aus einer Report-Datenbank.
// abridged from a real sidecar in this repository
{
"schemaVersion": 3,
"kind": "code",
"reviewedAt": "2026-09-01T08:01:34Z",
"reviewedHash": { "value": "17a45eef…" },
"grade": { "score": 74, "band": "C" },
"findings": [ 3 items, with anchors ],
"reviewer": {
"agent": "codex",
"usage": { "inputTokens": 23711, … }
}
}Staleness ist eine berechnete Sicht auf eine unveränderliche Aussage. Scannen oder Browsen schreibt nie eine Meta-Datei um; der Content-Hash macht Drift von selbst sichtbar.
freshder geprüfte Hash entspricht noch dem Arbeitsstand.staleCode geändert — die Aussage beschreibt eine ältere Version.policyDrifteine Guideline hat sich nach der Aussage geändert.missingnicht geprüft. Dargestellt als Fehlen, nie als F.Sweeps mit Obergrenzen und Ledger.
Ein Lauf umfasst einen Scope und eine Review-Art. Der Browser startet nie einen Agent-Prozess: Die API reiht den Lauf ein, führt Agent-CLIs aus und meldet Fortschritt je Datei. Frische Einheiten werden übersprungen; eine Token- oder Kostenobergrenze stoppt den Sweep an der nächsten Operationsgrenze.
Ein kostenloser Preflight rendert die echten Prompts und schätzt Tokens und Kosten gegen den Modellkatalog — ausgewiesen als Schätzung, nicht als Zusage.
Agent-CLIs arbeiten je Einheit mit gerouteten Modellen. Endzustände werden explizit benannt: done, failed, cancelled, capped.
Jede abgeschlossene Einheit schreibt ihr Sidecar; der Lauf schreibt einen kanonischen Snapshot unter .quality/reports/runs/.
Modell, Tokens, Dauer und Lauf-Identität landen im Sidecar und in einem Append-only-Monatsledger unter .quality/usage/.
Das Modell-Routing folgt den synchronisierten Token-Economy-Katalogen: Fähigkeitsstufen, unterstützte Thinking-Level und Retirement-Status. Aktuelle Preise und Scores stehen in der datierten Token-Economy-Benchmark-Matrix. Provider-Quota wird als darstellungssicherer Snapshot gelesen — eine leere Antwort heißt nicht verfügbar, nie unbegrenzt.
Change-Reviews umfassen einen Übergang.
Stehende Metadaten beantworten, wie eine Einheit abschneidet, bis sich ihre Eingaben ändern. Ein Change-Review beantwortet eine andere Frage: was ein einzelner Integrationsübergang an dieser stehenden Evidenz geändert hat. quality diff berechnet zuerst das deterministische Delta — Bewertungsbewegung, neue und gelöste Befunde per Fingerprint, verursachte Staleness, Boundary-Änderungen — und lässt erst dann einen Agenten Risiko, Test-Evidenz, Scope-Disziplin und Architektur-Drift allein auf dem Diff beurteilen.
Committete Übergänge
Jeder geprüfte Übergang ist ein Artefakt unter .quality/changes/, adressiert über den Merge-Commit — bei Übergängen mit nur einem Elternteil über den Head-Commit. Ein reiner Datei-Move wird ohne Qualitätsdelta festgehalten.
Gemessene Ökonomie
Die Effizienz von Change-Sets bleibt als datierte Repository-Evidenz erhalten, statt als aktueller Modell-Benchmark präsentiert zu werden. Für aktuelle Modellvergleiche gilt die Token-Economy-Benchmark-Matrix.
Sensor-Belege, dann Agent-Urteil.
Deterministische Werkzeuge scannen zuerst; ihre Ergebnisse gehen als vorab erhobene Fakten an den Review-Agenten und werden getrennt von dessen Befunden gespeichert. Die gespeicherten Code- und Performance-Noten bleiben Bewertungen des Review-Agents. Bei Security-Reviews berücksichtigt eine Triage-Anpassung für ausgeschlossene Findings zusätzlich die vom Verdict abhängigen Obergrenzen.
Sensor-Registry
gitleaks (gepinnt und checksummengeprüft), roslyn, eslint, tsc, produzentenneutrales SARIF, Dependency-Audits, Coverage-Reader und ein Boundary-Inventar der von außen aufrufbaren Flächen.
Nicht verfügbar ist Evidenz
Ein fehlendes Werkzeug oder ein gescheiterter Scan wird als expliziter Nicht-verfügbar-Zustand mit Begründung gemeldet — nie als sauberes Ergebnis, nie als Pass.