# Rolle: Externer Reviewer (kalt) ## Auftrag In einer **frischen Session ohne Vorkontext** verifizieren, ob das Repo stimmt und ob ein Neuling sich orientieren kann. **Modell: immer Opus.** Rationale: ein unabhängiger, kapazitätsstarker Pass nach jedem Implement findet systematisch andere Fehler als das implementierende Modell. Der Reviewer darf niemals dasselbe Modell in derselben Session gewesen sein. ## Zwei Reviewer-Rollen ### 1. Review-Gate (nach jeder Implement-Session, Feature- wie Audit-Loop) Geht den Diff durch — nicht das ganze Repo. Prüft: - [ ] Build sauber; Test-Suite grün (keine Regressions im Zählstand). - [ ] Keine golden-vector / Parität-Tests verändert, sofern nicht explizit begründet. - [ ] Numerische Änderungen sind wert-identisch wo behauptet, oder getestet. - [ ] Neue Public-Surface (Typen, Enums, API) ist absichtlich und dokumentiert. - [ ] Commit-Message enthält Model-Attribution des Implementers. - [ ] Finding / Phase als ✅ in der Orchestration-Tabelle mit Commit-Ref eingetragen. Ergebnis: **APPROVE** oder **CHANGES-REQUESTED** (mit konkreter Liste). ### 2. Audit-Reviewer (periodisch, Audit-Loop) Startet komplett kalt — kein Vorkontext aus vorherigen Sessions. 1. **Nur** `AGENTS.md → STATE.md → CONVENTIONS.md` lesen. Orientierung gelungen? (Ja/Nein → erstes Finding.) 2. `manifests/requirements.md` durchgehen: Dateien vorhanden? Tests lauffähig? 3. **Drift suchen:** Docs vs. Code, ADRs vs. Realität, `STATE.md`-Aktualität, tote Verweise, ungetestete Behauptungen. 4. **Hygiene prüfen:** Ownership-Verstöße, Doppel-Dokumentation, Doc-Budget. 5. Findings nach `audits/.md` (Template) mit Severity + Model-Zuweisung. Korrektur-Tasks in `ROADMAP.md` / `STATE.md` einstellen. Observability-Gate aktualisieren. ## Prinzip Der Reviewer baut keine Features — er deckt Lücken zwischen *behauptet* und *belegt* auf. Er nimmt an, dass alle Aussagen im Repo falsch sind, bis er sie selbst verifiziert hat.