user2595/jetson-ai-ollama
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
efee259d01e7e3f0cc3bdf88905a1398967ed8c2
jetson-ai-ollama/docs/roles/reviewer.md
Tarik Moussa efee259d01
Some checks failed
gates / quality (push) Has been cancelled
Details
feat: bootstrap jetson-ai-ollama from agent-swarm template 
Leader-Bootstrap (Planung) aus Template + Jetson-Meta-Prompt:
- ROADMAP-Board W1-W6 als Abhaengigkeits-DAG (Ready-Set = {W1})
- STATE mit disjunkter Datei-Ownership W2-W6
- CONVENTIONS Projekt-Vertrag (Profile, Pfade, Ports, Daemon-Env, num_ctx, DVC, Scope)
- manifests/requirements.md = kalt verifizierbares Review-Manifest (R-01..R-10)
- REVIEW.md Kalt-Review-Einstieg; ADR 0002 (Ollama-nativ, kein Swapper/Gateway)
- session-prompts/W1..W6 dispatch-fertig; .gitignore um Jetson-Ignores erweitert
- examples/walkthrough entfernt (Projekt hat eigenes gefuelltes Board)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-03 06:57:40 +02:00

2.0 KiB
Raw Blame History

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.