Tarik Moussa
696eddb5ef
Some checks failed
gates / quality (push) Has been cancelled
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.
56 lines
2.3 KiB
Markdown
56 lines
2.3 KiB
Markdown
# 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).
|