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.
55 lines
2.0 KiB
Markdown
55 lines
2.0 KiB
Markdown
# 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.
|