Files

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.3 KiB

Raw Blame History

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

2.3 KiB Raw Blame History