Tarik Moussa
696eddb5ef
Some checks failed
gates / quality (push) Has been cancelled
Generelles Git-Repo-Template fuer KI-Agenten-Arbeit (multi-agent swarm pattern). Enthaelt: - Rollen-System (Leader, Worker, Reviewer) mit Model-Routing-Matrix (Tier-basiert) - Zwei komplementaere Loops: Feature-Loop (vorwaerts) + Audit-Loop (rueckwaerts) - Spike-Gate fuer Research-Items (GO/NO-GO vor Produktionscode) - Obligatorische Opus-Review-Gate nach jeder Implement-Session - Drei ausfuehrbare Gates: session-hygiene, ownership (Cross-Edit-Schutz), doc-drift -- alle dormant bis zur ersten Initialisierung, dann automatisch aktiv - Bootstrap: scripts/init.sh + session-prompts/BOOTSTRAP.md - Worked Example (URL-Shortener-Domaene): Board, Session-Log, Audit-Finding, ADR - Token-Hygiene (3-Tier: Session-Schnitt / Command-Disziplin / Cache-Disziplin) - GitHub Actions CI (gates.yml) laeuft auf jedem Push/PR Muster destilliert aus produktiv-bewaehrten Patterns des ConformalLabpp-Projekts.
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# 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/<datum>.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.
|