FlexGodX/autonomer-agentischer-Entwicklungszyklus

Autonomer Agentischer Entwicklungszyklus (Qualitätsgesicherte Pipeline)

Diese Fertigkeit formalisiert den 5-Phasen-Engineering-Workflow und die Multi-Agenten-Arbitration-Pipeline, die während der autonomen Erstellung von Quest Nova (Flutter + Go + PostgreSQL 16 + Drift/SQLite) entwickelt und verifiziert wurde.

Sie garantiert hohe Architekturtreue, Null-Datenverlust, strenge Sicherheit (Zero-Trust/IDOR) und mathematisch verifizierte verteilte Synchronisation ohne menschliches Eingreifen zwischen den Phasen.

[!NOTE] Reverse Engineering ausgeschlossen: Die Phase des Reverse Engineering ist ausgelassen/deaktiviert. Die Pipeline beginnt direkt mit der Zieldefinition und der Erstellung der funktionalen Spezifikation (oder nimmt eine bestehende Produktbeschreibung als Eingabe).

---

1. Kern-Architekturprinzipien

1. Null-Unterbrechungs-Autonomie: Der Orchestrator durchläuft alle Phasen autonom. Bestätigung wird ausschließlich durch strenge Qualitäts-Gate-Audits abgeleitet, nicht durch Rückfragen an den Benutzer.
2. Kontextbereinigte unabhängige Verifikation: Prüfer und Gutachter werden als dedizierte Unteragenten mit sauberem Kontext gestartet (sie erhalten nur das überprüfbare Zielartefakt, Referenzspezifikationen und explizite Bewertungskriterien – frei von vorherigem Chat-Argumentationskontext).
3. Einstimmigkeitssperre: Der Übergang zur nächsten Phase wird blockiert, bis alle Prüfer/Gutachter ein explizites APPROVED-Urteil fällen. Fehlerlisten (CHANGES_REQUESTED) lösen eine sofortige Korrektur-Wiederholungsprüfungsschleife aus.
4. Fallback-Modell-Routing: Wenn primäre Reasoning-Modelle auf Ratenbegrenzungen stoßen (z. B. HTTP 429-Kontingenterschöpfung), leitet die Pipeline Aufgaben nahtlos an verfügbare Hochdurchsatzmodelle (z. B. Gemini 3.8 Flash) weiter, während Agentenrollen und saubere Kontextgrenzen strikt erhalten bleiben.

---

2. Die 5-Phasen-Pipeline

flowchart TD
    P1["Phase 1: Zielformulierung & Funktionale Spezifikation"] --> QG1{"Qualitäts-Gate 1: Spezifikationsaudit"}
    QG1 -->|"CHANGES_REQUESTED"| P1Fix["Behebung von Spezifikationsfehlern"]
    P1Fix --> QG1
    QG1 -->|"APPROVED (Einstimmig)"| P2["Phase 2: Systemdesign & Architektur"]
    P2 --> QG2{"Qualitäts-Gate 2: Gericht der 3 Agenten"}
    QG2 -->|"CHANGES_REQUESTED"| P2Fix["Architekturverfeinerung"]
    P2Fix --> QG2
    QG2 -->|"APPROVED (Einstimmig)"| P3["Phase 3: QA-Artefakt & Implementierungsplan"]
    P3 --> QG3{"Qualitäts-Gate 3: Rückverfolgbarkeits-Cross-Review"}
    QG3 -->|"CHANGES_REQUESTED"| P3Fix["Plan- & QA-Angleichung"]
    P3Fix --> QG3
    QG3 -->|"APPROVED (Einstimmig)"| P4["Phase 4: Implementierung (Backend + Client)"]
    P4 --> P5["Phase 5: Vollständige Verifikation, Belastungstests & Veröffentlichung"]

---

3. Benennungskonvention für Artefakte

Jedes von der Pipeline erstellte Artefakt ist eine versionierte Datei. Überschreiben Sie niemals ein Artefakt direkt – erstellen Sie stattdessen die nächste Version.

<ARTEFAKTNAME>-<Datum>-<NN>.md

• <ARTEFAKTNAME> — GROSS_SCHLANGE Name des Artefakts: GOAL, SPECIFICATION, DESIGN, QA_ARTIFACT, IMPLEMENTATION_PLAN, RELEASE_NOTES.
• <Datum> — Erstellungsdatum im ISO-Format YYYY-MM-DD.
• <NN> — zweistellige Sequenznummer (01, 02, …), die Artefakte mit demselben Namen unterscheidet, die innerhalb eines Tages erstellt wurden. Beginnen Sie mit 01 für das erste Artefakt eines bestimmten Tages und erhöhen Sie sie für jede spätere Überarbeitung desselben Artefakts an diesem Tag. Der Zähler gilt pro Artefaktname, sodass verschiedene Artefakte, die am selben Tag erstellt wurden, dieselbe Nummer haben können (z. B. GOAL-2026-11-10-01.md und DESIGN-2026-11-10-01.md). An einem neuen Tag beginnt der Zähler wieder bei 01.

Beispiel:

Artefakt	Erstes Artefakt des Tages	Zweites Artefakt des Tages
Goal	docs/GOAL-2026-11-10-01.md	docs/GOAL-2026-11-10-02.md
Specification	docs/SPECIFICATION-2026-11-10-01.md	docs/SPECIFICATION-2026-11-10-02.md
Design	docs/DESIGN-2026-11-10-01.md	docs/DESIGN-2026-11-10-02.md

Regeln:

1. Phasenauslieferungen und alle Querverweise (Qualitäts-Gate-Aufforderungen, Pläne, Versionshinweise) müssen den exakten versionierten Dateinamen angeben, niemals einen unversionierten Namen wie docs/GOAL.md.
2. Die höchste <NN> für einen Artefaktnamen ist die aktuell maßgebliche Version; frühere Versionen bleiben als Prüfpfad unberührt.
3. Qualitäts-Gates prüfen die spezifische Version, die ihnen vorgelegt wird, und halten diesen Dateinamen in ihrem Urteil fest.

In dieser Fertigkeit stehen <Datum> und <NN> für das oben beschriebene Datum bzw. die Sequenznummer.

---

4. Phasenspezifische Ausführungsanleitung

Phase 1: Zielformulierung & Funktionale Spezifikation (Qualitäts-Gate 1)

• Ziel: Explizite Systemgrenzen, Benutzerschleifen, Domänenmodelle und technische Spezifikationen basierend direkt auf den Anforderungen/der Aufgabenbeschreibung formulieren.
• Liefergegenstände:
  • docs/GOAL-<Datum>-<NN>.md: Globaler Systemumfang, Kerninvarianten, Definition of Done (DoD).
  • docs/SPECIFICATION-<Datum>-<NN>.md: Entitätsschemas, zeitliche Mechaniken, Synchronisationsprotokoll, OCC-Versionierung, 3-Wege-Merge-Regeln, IDOR-Schutz, DDL-Schemas.
• Qualitäts-Gate 1 (Kontextbereinigter Prüfer):
  • Unteragenten starten (typeName: "research").
  • Nur docs/SPECIFICATION-<Datum>-<NN>.md und Kriterien bereitstellen (Vollständigkeit, Sicherheit, Datenintegrität, Konsistenz).
  • Schleife bis APPROVED.

Phase 2: Systemdesign & „Gericht der Drei Agenten" (Qualitäts-Gate 2)

• Ziel: Skalierbares, fehlertolerantes Backend und reaktiven Client architekturieren.
• Liefergegenstand: docs/DESIGN-<Datum>-<NN>.md (Systemdesigndokument: Backend, Client, Sicherheit).
• Qualitäts-Gate 2 (Das Gericht der Drei Agenten): 3 unabhängige Unteragenten mit sauberem Kontext starten:
  1. Gutachter 1 (Backend- & Systemarchitekt): Bewertet DB-Schema, Transaktionsgrenzen, Sperren auf Zeilenebene, topologischen DAG-Sortierung, Partitionsschemata und OCC.
  2. Gutachter 2 (Client- & UI-Architekt): Bewertet Offline-First-DB (Drift/SQLite), Hintergrundisolate, Frame-Budget (< 16,6 ms), Mutation-Queue-Coalescing und BLoC-Zustandsmaschinen.
  3. Gutachter 3 (Sicherheits- & Randfall-Kritiker): Identifiziert Race Conditions, Cold-Start-Deadlocks, Echo-Schleifen, Token-Replay (RTR), Sitzungsdiebstahl und IDOR-Schwachstellen.
  • Alle 3 Gutachter müssen APPROVED zurückgeben, bevor fortgefahren wird.

Phase 3: QA-Artefakt, Rückverfolgbarkeitsplan & Qualitäts-Gate 3

• Ziel: 100% bidirektionale Rückverfolgbarkeit zwischen Spezifikation, Architektur und Tests sicherstellen, bevor Code geschrieben wird.
• Liefergegenstände:
  • docs/QA_ARTIFACT-<Datum>-<NN>.md: Vollständige Akzeptanzkriterien (AC-XX), Unit-, Integrations-, verteilte Synchronisations- (TC-SYNC-XX) und Belastungstestszenarien (STRESS-XX).
  • docs/IMPLEMENTATION_PLAN-<Datum>-<NN>.md: Gestaffelter Aufgabenabbau, der direkt auf QA-Fälle abgebildet wird.
• Qualitäts-Gate 3 (Cross-Auditor):
  • Überprüfen, ob jedes einzelne Akzeptanzkriterium und jeder Randfall in docs/QA_ARTIFACT-<Datum>-<NN>.md direkt auf einen Implementierungsschritt in docs/IMPLEMENTATION_PLAN-<Datum>-<NN>.md abgebildet ist.
  • Schleife bis APPROVED.

Phase 4: Implementierung & Testverifikation

1. Datenbankmigrationen: Alle DDL-Migrationen mit zusammengesetzten Indizes und Partitionierung anwenden.
2. Backend-Engine:
   • Clean Architecture: domain/, repository/, usecase/, delivery/http/.
   • Unit- & Integrationstestausführung: cd backend && go test -v ./....
3. Client-Engine:
   • Zentrale Zeit-Dienstprogramme (PlainDate, FloatingTime, SparseSortOrder).
   • 3-Wege-Differential-Merge-Engine (5 Checklisten-Szenarien, Notizen zum Null-Datenverlust).
   • In-Place-Mutation-Coalescing & In-Flight-Race-Behandlung (MutationQueueManager).
   • BLoC-Architektur & Adaptives UI (Desktop 3-Pane + Mobile Navigation).
   • Client-Testausführung: cd client && flutter test.
   • Linter-Verifikation: cd client && flutter analyze (0 Probleme).

Phase 5: Belastungstests, Veröffentlichung & Übergabe

1. Verteilte Synchronisationsverifikation: Multi-Device-Gleichzeitigkeit, OCC-Konflikte, Echo-Unterdrückung und HTTP 410-Bootstrap-Abstimmungsabgleich durchführen.
2. Belastungstests:
   • Datenbankverbindungspool-Sättigung (STRESS-01): Gleichzeitige Worker mit 0 Pool-Leaks.
   • UI-Frame-Budget-Benchmark (STRESS-02): 1000 Aufgaben verarbeitet in < 16,6 ms (stabile 60/120 FPS).
3. Artefaktkompilierung:
   • Natives Backend-Binary erstellen: go build -o bin/<service> cmd/<service>/main.go.
   • Client-Bundle erstellen: flutter build bundle / flutter build macos / flutter build web.
4. Versionshinweise: docs/RELEASE_NOTES-<Datum>-<NN>.md generieren, das verifizierte Metriken, die DoD-Checkliste und Ausführungsanweisungen dokumentiert.

---

5. Prüfer- & Gutachter-Prompt-Vorlagen

Für Prompt-Vorlagen, die beim Aufruf von kontextbereinigten Unteragenten für die Qualitäts-Gates 1, 2 und 3 verwendet werden, lesen Sie references/auditor_prompts.md.