feat: bootstrap jetson-ai-ollama from agent-swarm template
Some checks failed
gates / quality (push) Has been cancelled
Some checks failed
gates / quality (push) Has been cancelled
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>
This commit is contained in:
41
docs/roles/reviewer.md
Normal file
41
docs/roles/reviewer.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user