feat: initial agent-swarm-repo template

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.

docs/loops/audit-loop.md

@@ -0,0 +1,54 @@
+# Audit-Loop (rückwärts)
+
+Ziel: Korrektheit & Hygiene erhalten, Drift früh fangen.
+
+```
+Kalter Auditor (Opus, neue Session)
+  -> Orientierung allein aus AGENTS/STATE/CONVENTIONS pruefen
+    -> Manifest verifizieren + Tests ausfuehren
+      -> Drift & Hygiene-Befunde sammeln
+        -> audits/<datum>.md: Finding-Tabelle mit Severity + Model-Zuweisung
+          -> Korrektur-Tasks in ROADMAP/STATE einstellen
+            -> Observability-Gate (Effizienz + Doku-Drift) aktualisieren
+```
+
+## Trigger
+Nach N Feature-Zyklen, oder sofort bei Drift-Signal aus den Observability-Gates.
+
+## Finding-Orchestration
+
+Findings werden in `audits/<datum>.md` **mit Model-Zuweisung** erfasst:
+
+| ID | Typ | Sev | Status | Model | Session |
+|----|-----|-----|--------|-------|---------|
+| F-01 | drift | 🔴 | ⬜ | Sonnet | S1 |
+| F-02 | hygiene | 🟡 | ✅ abc123 | Haiku | S1 |
+
+Severity: 🔴 hoch · 🟡 mittel · 🔵 niedrig
+
+Model-Routing (s. `docs/roles/model-routing.md`):
+- **Haiku** — mechanisch, lokal, kein Risiko (Docs, Umbenennen, Konstanten)
+- **Sonnet** — klare Akzeptanzkriterien (Tests, Error-Handling, kleine API-Änderungen)
+- **Opus** — Numerik, Architektur, irreversible Entscheidungen + **jede Review-Gate-Session**
+
+Entscheidungs-Regel: nicht "wie schwer", sondern "wie viel muss **verstanden** werden,
+um es richtig zu machen."
+
+## Session-Sequenz
+
+Findings werden in Sessions gebündelt (ähnliche Model-Zuweisung, ähnlicher Scope).
+Nach jeder Implement-Session kommt eine **Opus-Review-Session** (kalt, unabhängig):
+
+```
+Implement-Session (Sonnet/Haiku)
+  -> dedizierten Review-Gate-Session (Opus, kalt)
+    APPROVE → Finding ✅ + Commit-Ref eintragen
+    CHANGES-REQUESTED → zurück zu Implement
+```
+
+Kaltstartfähige Prompts für jede Session: `session-prompts/`.
+
+## Ergebnis
+Priorisierte Korrektur-Tasks mit Model-Zuweisung, die der nächste Feature-Loop
+abräumt. Handoff zu Feature-Dev: jedes bereinigte Finding bestätigt, dass das
+Repo wieder der Clean-Start-Invariante genügt.

docs/loops/feature-loop.md

@@ -0,0 +1,62 @@
+# Feature-Loop (vorwärts)
+
+Ziel: neue Fähigkeit, sauber dokumentiert und belegt.
+
+## Kern-Pipeline
+
+```
+Roadmap-Item
+  -> Leader klassifiziert (port / research / infra)
+  -> Leader zerlegt in disjunkte Pakete (+ STATE-Ownership)
+
+  ┌── PORT ────────────────────────────────────────────┐
+  │  Worker (Sonnet): golden-oracle Implementierung    │
+  │  Validation (Sonnet): Parität-Tests                │
+  └────────────────────────────────────────────────────┘
+
+  ┌── RESEARCH ─────────────────────────────────────────────────────────┐
+  │  Theorist (Opus): Formeln aus Papers ableiten, Validation entwerfen │
+  │  Spike (Prototyper): Wegwerf-Implementierung auf scratch/**-Branch  │
+  │  GO/NO-GO-Gate: math korrekt? → GO: weiter; NO-GO: → Roadmap       │
+  │  Research-Implementer (Opus→Sonnet): produktiv umsetzen             │
+  └─────────────────────────────────────────────────────────────────────┘
+
+  -> Validation Engineer: Test-Batterie je Item-Typ bauen
+  -> Review-Gate (Opus, kalt): math korrekt? Parität? Public-API ok?
+       APPROVE → weiter | CHANGES-REQUESTED → zurück zu Implement
+  -> Leader integriert & löst Konflikte
+  -> Manifest + Docs + STATE aktualisiert
+  -> Quality-Gate (Hygiene/Kontext/Token)
+       PASS: Item nach "Done" | FAIL: Korrektur-Task
+```
+
+## Klassifikation Port vs. Research
+
+| Typ | Kriterium | Oracle | Validation-Pflicht |
+|---|---|---|---|
+| **Port** | hat Referenz-Implementierung (Java, Python, Pseudo-Code) | golden values bit-for-bit | FD-Gradient + Parität |
+| **Research** | kein direkter Vorläufer, nur Paper-Formeln | keine extern | Invarianten + analyt. Grenzfälle + Konvergenz |
+| **Infra** | kein fachlicher Inhalt (CLI, CI, Docs) | trivial | Smoke-Test |
+
+Regel: Research-Items **müssen** durch das Spike-Gate, bevor Produktions-Code
+geschrieben wird. Näheres: `docs/loops/spike-gate.md`.
+
+## Model-Routing (grobe Heuristik)
+
+Vollständige Matrix: `docs/roles/model-routing.md`. Kurzform:
+- Mechanische Arbeit (Umbenennen, Docs, CLI-Glue) → **Haiku**
+- Implementierung mit klarer Spec → **Sonnet**
+- Mathe, Architektur, jede Review-Gate-Session → **Opus**
+
+## Session-Prompts
+
+Kaltstartfähige Prompts je Phase/Paket unter `session-prompts/`.
+Template: `session-prompts/TEMPLATE.md`.
+
+## Eintrittskriterien
+Roadmap-Item priorisiert; Klassifikation (Port/Research/Infra) klar;
+betroffene Konventionen geklärt.
+
+## Austrittskriterien (Definition of Done, s. CONVENTIONS.md)
+Tests grün · Manifest `done` · Docs/STATE aktuell · Session-Log ·
+Review-Gate `APPROVE` · Hygiene-Gate `PASS`.

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