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/loops/spike-gate.md

@@ -0,0 +1,55 @@
+# Spike-Gate (nur Research-Items)
+
+Bevor Research-Mathe produktivsiert wird: numerischer Proof-of-Correctness
+auf einem **Wegwerf-Branch**. Der Spike schützt davor, Wochen in eine
+mathematisch falsche Implementierung zu investieren.
+
+## Warum
+
+Research-Items haben keinen goldenen Oracle (keine Referenz-Implementierung).
+Eine Implementierung kann kompilieren, konvergieren und trotzdem **geometrisch
+falsch** sein. Invarianten-Checks und Konvergenz-Studien fangen das nur, wenn
+die zu prüfenden Invarianten vorab klar spezifiziert wurden.
+
+## Ablauf
+
+```
+Theorist (Opus):
+  Formeln aus Papers/Dissertation ableiten
+  Validation-Strategie entwerfen (Invarianten, analyt. Grenzfälle, Kreuzcheck)
+  LaTeX-Notiz / Spec-Dokument erstellen
+        ↓
+Prototyper (Opus → Sonnet):
+  Throwaway-Implementierung auf Branch `spike/<thema>`
+  Numerischen Korrektheitsnachweis führen (die vom Theorist entworfene Validation)
+        ↓
+GO/NO-GO-Gate:
+  GO  → Spike-Branch wird verworfen; Research-Implementer baut produktiv
+  NO-GO → Spike-Branch bleibt als Dokumentation des negativen Ergebnisses
+          → Eintrag in ROADMAP: "Spike <thema> FAILED — Grund: …"
+          → Zurück zum Theorist oder Human-Entscheidung
+```
+
+## NO-GO ist kein Versagen
+
+Ein NO-GO ist ein valides, wertvolles Ergebnis. Es dokumentiert, dass ein
+Ansatz numerisch nicht funktioniert, bevor Produktionscode und Tests dafür
+investiert wurden. **Negative Spikes müssen genauso sorgfältig dokumentiert
+werden wie erfolgreiche.**
+
+## Validation-Typen (gewählt vom Theorist)
+
+| Situation | Validation |
+|---|---|
+| Cross-Implementierung verfügbar (andere Bibliothek) | Übereinstimmung nach Normalisierung |
+| Analytische Grenzfälle bekannt (z. B. κ=0 ↔ Euklidisch) | Bit-for-bit-Übereinstimmung am Grenzfall |
+| Erhaltungsgrößen bekannt (Gauss-Bonnet, Holonomie-Closure) | Invarianten-Check unter Perturbation |
+| Analytisch vs. numerisch (FD vs. exakte Hessematrix) | Wert-Identität + Speed-Messung |
+| Kein direkter Check möglich | Konvergenz-unter-Verfeinerung-Studie |
+
+## Aufwand-Faustregel
+
+Ein Spike sollte **höchstens 20 % des Aufwands** einer vollständigen
+Implementierung kosten. Wenn er mehr braucht, ist das Scope entweder falsch
+klassifiziert (→ kleineres Research-Item) oder der Theorist hat die Spec
+nicht ausreichend präzisiert (→ zurück zum Theorist).