Files

gates / quality (push) Has been cancelled

Details

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.

2026-06-03 06:35:06 +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