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>

docs/roles/leader.md

@@ -0,0 +1,17 @@
+# Rolle: Leader
+
+## Auftrag
+Arbeit zerlegen, zuweisen, integrieren — nicht selbst alle Pakete bauen.
+
+## Ablauf (Feature-Loop)
+1. Oberstes Roadmap-Item ziehen, in **disjunkte Worker-Pakete** zerlegen
+   (klare Datei-Ownership, minimale Kopplung).
+2. Ownership-Tabelle in `STATE.md` eintragen; offene Fragen vorab in
+   `CONVENTIONS.md`/ADR klären, damit Worker nicht divergieren.
+3. Worker parallel dispatchen. Während sie laufen: nichts in ihren Dateien ändern.
+4. **Integrieren:** zusammenführen, Konflikte lösen, Schnittstellen prüfen.
+5. Manifest + Docs + `STATE.md` aktualisieren, Quality-Gate ausführen.
+
+## Regeln
+- Konflikte gehören dir, nicht den Workern.
+- Wenn ein Paket > 1 Worker-Session braucht: weiter zerlegen.

docs/roles/model-routing.md

@@ -0,0 +1,58 @@
+# Model-Routing — Zuweisung nach Aufgabentyp
+
+Vollständige Entscheidungsmatrix. Kurzform in `docs/loops/feature-loop.md`.
+
+> **Tier-Sprache statt feste Modellnamen:** Modellnamen veralten; die Tier-Logik
+> (klein/mittel/hoch) bleibt. Konkrete Modell-IDs (z. B. Haiku 4.5, Sonnet 4.6,
+> Opus 4.8) sind aktuelle Beispiele — beim Provider nachschlagen, wenn neue
+> Versionen verfügbar sind.
+
+## Tiers
+
+| Tier | Eigenschaft | Aktuelle Beispiele (Anthropic Claude) |
+|------|-------------|---------------------------------------|
+| **klein** | schnell, günstig, ausreichend für klar spezifizierte, mechanische Arbeit | Haiku |
+| **mittel** | ausgewogen; guter Coder bei klarer Spec | Sonnet |
+| **hoch** | höchste Reasoning-Kapazität; für Unklarheiten, Mathe, Review | Opus |
+
+## Routing-Matrix
+
+| Aufgabe | Rolle · Tier |
+|---|---|
+| Mechanisch, lokal, kein Risiko: Docs, Umbenennen, Konstanten, CLI-Glue | klein |
+| Faithful Translation von bekannter Referenz (Port, golden oracle) | Porter · mittel |
+| Implementierung mit klarer Spec + Akzeptanzkriterien: Tests, Error-Handling | mittel |
+| Numerik, Architektur, Mathe von Grund auf, irreversible Public-API-Entscheidungen | hoch |
+| Formeln aus Papers ableiten, Validation-Strategie entwerfen | Theorist · hoch |
+| Throwaway Proof-of-Correctness (Spike), bevor Produktionscode entsteht | Prototyper · hoch → mittel |
+| Test-Batterie für abgeschlossene Implementierung | Validation · mittel |
+| **Jede Review-Gate-Session** (unabhängig, kalt) | **Reviewer · hoch** |
+| Docs polieren, Referenz-Listen, Tutorials | Scholar · klein |
+| Branch/PR/CI/Rebase/Merge | Integrator · mittel |
+| Fachliche Richtungsentscheidungen, Lizenz, Precision-Substrat | Human |
+
+## Entscheidungsregel
+
+**Nicht** „wie schwer ist das Finding/Feature", sondern:
+**„Wie viel muss *verstanden* werden, um es richtig zu machen?"**
+
+- Eine 1-Zeilen-Korrektur mit klarer Spec → mittel (auch wenn 🔴 Severity).
+- Eine numerische Umformulierung mit Auswirkung auf Korrektheit → hoch
+  (auch wenn 🔵 Severity).
+
+## Review-Gate-Regel
+
+Die Review-Gate-Session ist **immer höchste Kapazitätsstufe und immer kalt**
+(eigene Session, kein Vorkontext aus der Implement-Session). Implement-Tier ≠
+Review-Tier ist keine Effizienzfrage, sondern eine Korrektheitseigenschaft.
+
+## Routing Port vs. Research
+
+```
+Gibt es eine Referenz-Implementierung / goldene Werte?
+  JA  → Port   → Porter (Sonnet), golden-oracle parity-Tests Pflicht
+  NEIN → Research → Theorist (Opus) ableiten → Spike → GO/NO-GO
+                    → Research-Implementer (Opus→Sonnet) produktivisieren
+```
+
+Details zum Spike-Gate: `docs/loops/spike-gate.md`.

docs/roles/reviewer.md

@@ -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.

docs/roles/worker.md

@@ -0,0 +1,14 @@
+# Rolle: Worker
+
+## Auftrag
+Genau **ein** zugewiesenes Paket umsetzen — innerhalb der eigenen Dateigrenzen.
+
+## Ablauf
+1. `AGENTS.md`-Reihenfolge lesen, dann nur die für dein Paket relevanten Dateien.
+2. Gegen den Vertrag in `CONVENTIONS.md` bauen (Naming/Pfade/Schnittstellen).
+3. Tests für dein Paket schreiben; Manifest-Einträge auf `in_progress`/`done` setzen.
+4. **Niemals** Dateien außerhalb deines Pakets anfassen — sonst Notiz an den Leader.
+5. Session-Log schreiben (inkl. Token-Verbrauch), Hygiene-Gate ausführen.
+
+## Anti-Pattern
+- Scope-Creep, "mal eben" fremde Dateien anpassen, Doku "später".