FlexGodX/cycle-developpement-autonome-agentic

Cycle de Développement Autonome Agentic (Pipeline à Quality Gates)

Cette compétence formalise le workflow d'ingénierie en 5 phases et le pipeline d'arbitrage multi-agents développé et vérifié lors de la création autonome de Quest Nova (Flutter + Go + PostgreSQL 16 + Drift/SQLite).

Elle garantit une haute fidélité architecturale, zéro perte de données, une sécurité stricte (Zero-Trust/IDOR) et une synchronisation distribuée mathématiquement vérifiée sans intervention humaine entre les phases.

[!NOTE] Rétro-ingénierie exclue : La phase de rétro-ingénierie est omise/désactivée. Le pipeline commence directement par la définition des objectifs et la rédaction des spécifications fonctionnelles (ou prend un brief produit existant en entrée).

---

1. Principes d'Architecture Fondamentaux

1. Autonomie sans interruption : L'orchestrateur progresse à travers toutes les phases de manière autonome. La confirmation est dérivée strictement d'audits rigoureux des Quality Gates plutôt que de demander à l'utilisateur.
2. Vérification indépendante en contexte vierge : Les réviseurs et juges sont générés en tant que sous-agents dédiés avec un contexte vierge (ils reçoivent uniquement l'artéfact cible vérifiable, les spécifications de référence et les critères d'évaluation explicites — libres de tout raisonnement de chat antérieur).
3. Barrière d'approbation unanime : La transition vers la phase suivante est bloquée jusqu'à ce que tous les auditeurs/juges accordent un verdict explicite APPROVED. Les listes de défauts (CHANGES_REQUESTED) déclenchent une boucle immédiate de correction et de ré-audit.
4. Routage de secours des modèles : Lorsque les modèles de raisonnement principaux atteignent leurs limites de débit (par ex. épuisement du quota HTTP 429), le pipeline achemine de manière transparente les tâches vers des modèles à haut débit disponibles (par ex. Gemini 3.8 Flash) tout en préservant strictement les rôles des agents et les limites du contexte vierge.

---

2. Le Pipeline en 5 Phases

flowchart TD
    P1["Phase 1 : Formulation des Objectifs & Spécification Fonctionnelle"] --> QG1{"Quality Gate 1 : Audit de Spécification"}
    QG1 -->|"CHANGES_REQUESTED"| P1Fix["Résolution des Défauts de Spécification"]
    P1Fix --> QG1
    QG1 -->|"APPROVED (Unanime)"| P2["Phase 2 : Conception Système & Architecture"]
    P2 --> QG2{"Quality Gate 2 : Cour de 3 Agents"}
    QG2 -->|"CHANGES_REQUESTED"| P2Fix["Affinage de l'Architecture"]
    P2Fix --> QG2
    QG2 -->|"APPROVED (Unanime)"| P3["Phase 3 : Artéfact QA & Plan d'Implémentation"]
    P3 --> QG3{"Quality Gate 3 : Relecture Croisée de Traçabilité"}
    QG3 -->|"CHANGES_REQUESTED"| P3Fix["Alignement Plan & QA"]
    P3Fix --> QG3
    QG3 -->|"APPROVED (Unanime)"| P4["Phase 4 : Implémentation (Backend + Client)"]
    P4 --> P5["Phase 5 : Vérification Complète, Tests de Charge & Publication"]

---

3. Convention de Nommage des Artéfacts

Chaque artéfact produit par le pipeline est un fichier versionné. Ne jamais écraser un artéfact sur place — créer la version suivante à la place.

<NOM-ARTEFACT>-<date>-<NN>.md

• <NOM-ARTEFACT> — Nom en UPPER_SNAKE de l'artéfact : GOAL, SPECIFICATION, DESIGN, QA_ARTIFACT, IMPLEMENTATION_PLAN, RELEASE_NOTES.
• <date> — date de création au format ISO YYYY-MM-DD.
• <NN> — numéro de séquence à deux chiffres (01, 02, …) qui désambiguïse les artéfacts du même nom créés le même jour. Commencer à 01 pour le premier artéfact d'un jour donné et incrémenter pour chaque révision ultérieure de ce même artéfact ce jour-là. Le compteur est par nom d'artéfact, donc différents artéfacts créés le même jour peuvent partager le même numéro (ex. GOAL-2026-11-10-01.md et DESIGN-2026-11-10-01.md). Un nouveau jour, le compteur recommence à 01.

Exemple :

Artéfact	Premier artéfact du jour	Deuxième artéfact du même jour
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

Règles :

1. Les livrables de phase et toutes les références croisées (prompts de Quality Gate, plans, notes de version) doivent citer le nom de fichier versionné exact, jamais un nom non versionné comme docs/GOAL.md.
2. Le <NN> le plus élevé pour un nom d'artéfact est la version courante faisant autorité ; les versions antérieures restent intactes comme piste d'audit.
3. Les Quality Gates auditent la version spécifique qui leur est remise et enregistrent ce nom de fichier dans leur verdict.

Tout au long de cette compétence <date> et <NN> représentent la date et le numéro de séquence décrits ci-dessus.

---

4. Guide d'Exécution Phase par Phase

Phase 1 : Formulation des Objectifs & Spécification Fonctionnelle (Quality Gate 1)

• Objectif : Formuler les limites explicites du système, les boucles utilisateur, les modèles de domaine et les spécifications techniques basées directement sur les exigences/brief.
• Livrables :
  • docs/GOAL-<date>-<NN>.md : Périmètre global du système, invariants fondamentaux, Définition de Fini (DoD).
  • docs/SPECIFICATION-<date>-<NN>.md : Schémas d'entités, mécaniques temporelles, protocole de synchronisation, versionnement OCC, règles de fusion 3-voies, protection IDOR, schémas DDL.
• Quality Gate 1 (Auditeur en Contexte Vierge) :
  • Générer un sous-agent (typeName: "research").
  • Fournir uniquement docs/SPECIFICATION-<date>-<NN>.md et les critères (exhaustivité, sécurité, intégrité des données, cohérence).
  • Boucler jusqu'à APPROVED.

Phase 2 : Conception Système & "Cour des Trois Agents" (Quality Gate 2)

• Objectif : Architecturer un backend évolutif et tolérant aux pannes et un client réactif.
• Livrable : docs/DESIGN-<date>-<NN>.md (document de conception système : backend, client, sécurité).
• Quality Gate 2 (La Cour des Trois Agents) : Générer 3 sous-agents indépendants avec un contexte vierge :
  1. Juge 1 (Architecte Backend & Système) : Évalue le schéma DB, les limites de transaction, les verrous au niveau ligne, le tri topologique DAG, les schémas de partitionnement et l'OCC.
  2. Juge 2 (Architecte Client & UI) : Évalue la DB Offline-First (Drift/SQLite), les isolates en arrière-plan, le budget de trame (< 16.6 ms), le coalescing de la file de mutations et les machines d'état BLoC.
  3. Juge 3 (Critique Sécurité & Cas Limites) : Identifie les conditions de course, les interblocages au démarrage à froid, les boucles d'écho, le rejeu de tokens (RTR), le vol de session et les vulnérabilités IDOR.
  • Les 3 juges doivent retourner APPROVED avant de continuer.

Phase 3 : Artéfact QA, Plan de Traçabilité & Quality Gate 3

• Objectif : Assurer une traçabilité bidirectionnelle à 100 % entre la spécification, l'architecture et les tests avant d'écrire le code.
• Livrables :
  • docs/QA_ARTIFACT-<date>-<NN>.md : Critères d'Acceptation Complets (AC-XX), scénarios de tests Unitaires, d'Intégration, de Synchronisation Distribuée (TC-SYNC-XX) et de Stress (STRESS-XX).
  • docs/IMPLEMENTATION_PLAN-<date>-<NN>.md : Décomposition des tâches par étapes directement mappée aux cas QA.
• Quality Gate 3 (Cross-Auditeur) :
  • Vérifier que chaque critère d'acceptation et cas limite dans docs/QA_ARTIFACT-<date>-<NN>.md est directement mappé à une étape d'implémentation dans docs/IMPLEMENTATION_PLAN-<date>-<NN>.md.
  • Boucler jusqu'à APPROVED.

Phase 4 : Implémentation & Vérification des Tests

1. Migrations de Base de Données : Appliquer toutes les migrations DDL avec index composites et partitionnement.
2. Moteur Backend :
   • Clean Architecture : domain/, repository/, usecase/, delivery/http/.
   • Exécution des tests unitaires et d'intégration : cd backend && go test -v ./....
3. Moteur Client :
   • Utilitaires temporels fondamentaux (PlainDate, FloatingTime, SparseSortOrder).
   • Moteur de fusion différentielle à 3 voies (5 scénarios de checklist, notes de zéro perte de données).
   • Coalescing des mutations sur place et gestion des courses en vol (MutationQueueManager).
   • Architecture BLoC & UI Adaptative (3 volets Desktop + Navigation Mobile).
   • Exécution des tests client : cd client && flutter test.
   • Vérification du linter : cd client && flutter analyze (0 problèmes).

Phase 5 : Tests de Charge, Publication & Transfert

1. Vérification de la Synchronisation Distribuée : Exécuter les tests de concurrence multi-appareils, les conflits OCC, la suppression d'écho et la réconciliation Bootstrap HTTP 410.
2. Tests de Charge :
   • Saturation du Pool de Connexions Base de Données (STRESS-01) : Workers concurrents avec 0 fuite de pool.
   • Benchmark du Budget de Trame UI (STRESS-02) : 1000 tâches traitées en < 16.6 ms (60/120 FPS stable).
3. Compilation des Artéfacts :
   • Construire le binaire backend natif : go build -o bin/<service> cmd/<service>/main.go.
   • Construire le bundle client : flutter build bundle / flutter build macos / flutter build web.
4. Notes de Version : Générer docs/RELEASE_NOTES-<date>-<NN>.md documentant les métriques vérifiées, la checklist DoD et les instructions d'exécution.

---

5. Modèles de Prompts pour Auditeurs & Juges

Pour les modèles de prompts utilisés lors de l'invocation des sous-agents en contexte vierge pour les Quality Gates 1, 2 et 3, reportez-vous à references/auditor_prompts.md.