Documentation du workflow de gouvernance ProbatioVault¶

Table des matières¶

• Partie 1 : Documentation fonctionnelle
• 1.1 Vue d'ensemble
• 1.2 Diagramme d'état global
• 1.3 Fiches détaillées des 10 étapes
• 1.4 Gates PMO
• 1.5 Étape 6 — Multi-agents
• 1.6 Mapping agents → LLM
• 1.7 Artefacts produits
• 1.8 Verdicts PMO
• Partie 2 : Documentation technique
• 2.1 Architecture des composants
• 2.2 Scripts principaux
• 2.3 Bibliothèques (scripts/lib/)
• 2.4 Templates de prompts
• 2.5 Templates de sortie
• 2.6 Définitions des agents
• 2.7 Commandes Claude
• 2.8 Gestion de l'état (WORKFLOW-STATE.md)
• 2.9 Arborescence des fichiers

Partie 1 : Documentation fonctionnelle¶

1.1 Vue d'ensemble¶

Principe architectural¶

Le workflow de gouvernance ProbatioVault suit une architecture multi-agents gouvernée résumée par la maxime :

Les agents produisent. Claude orchestre. Le PMO juge. L'humain tranche.

• Agents spécialisés : chaque domaine (développement, sécurité, QA, métier, conformité) est confié à un agent dédié qui travaille en isolation.
• Claude (orchestrateur) : coordonne les agents, assemble les prompts, confronte les documents. Il ne produit pas le code principal lui-même.
• PMO : rend des verdicts structurés aux gates (étapes 3, 5, 8) sur la base de dossiers de conformité factuels.
• L'humain : autorité de décision finale, sollicité uniquement par escalade.

Deux LLM utilisés¶

Cycle de vie d'une user story¶

Chaque user story (format PD-XX) traverse 10 étapes séquentielles. Trois d'entre elles sont des gates PMO (étapes 3, 5, 8) qui peuvent bloquer le workflow. L'étape 6 est un workflow multi-agents décomposé en sous-étapes.

1.2 Diagramme d'état global¶

stateDiagram-v2
    [*] --> Step0_Besoin

    Step0_Besoin: 0 — Expression de besoin (Claude)
    Step1_Spec: 1 — Spécification (ChatGPT)
    Step2_Tests: 2 — Tests & Validation (ChatGPT)
    Step3_Gate: 3 — Review spécification (Gate CONFORMITY_CHECK)
    Step4_Plan: 4 — Plan d'implémentation (Claude)
    Step5_Gate: 5 — Review plan (Gate AMBIGUITY)
    Step6_Impl: 6 — Implémentation (Multi-agents)
    Step7_Accept: 7 — Acceptabilité (ChatGPT)
    Step8_Gate: 8 — Review acceptabilité (Gate CLOSURE)
    Step9_Rex: 9 — Retour d'expérience (Claude)

    Step0_Besoin --> Step1_Spec
    Step1_Spec --> Step2_Tests
    Step2_Tests --> Step3_Gate

    Step3_Gate --> Step4_Plan: GO / RESERVE
    Step3_Gate --> Step2_Tests: NON_CONFORME (rework)
    Step3_Gate --> Escalade3: ESCALADE

    Step4_Plan --> Step5_Gate

    Step5_Gate --> Step6_Impl: GO / RESERVE
    Step5_Gate --> Step4_Plan: NON_CONFORME (rework)
    Step5_Gate --> Escalade5: ESCALADE

    Step6_Impl --> Step7_Accept

    Step7_Accept --> Step8_Gate

    Step8_Gate --> Step9_Rex: GO / RESERVE
    Step8_Gate --> Step6_Impl: NON_CONFORME (rework)
    Step8_Gate --> Escalade8: ESCALADE

    Step9_Rex --> [*]

    state Step6_Impl {
        [*] --> S6a_Decomposition
        S6a_Decomposition: 6a — Décomposition
        S6b_Agents: 6b — Agents spécialisés (1..N)
        S6c_Synthese: 6c — Synthèse

        S6a_Decomposition --> S6b_Agents
        S6b_Agents --> S6c_Synthese
        S6c_Synthese --> [*]
    }

    state Escalade3 {
        [*] --> DecisionHumaine3: Décision humaine requise
    }
    state Escalade5 {
        [*] --> DecisionHumaine5: Décision humaine requise
    }
    state Escalade8 {
        [*] --> DecisionHumaine8: Décision humaine requise
    }

1.3 Fiches détaillées des 10 étapes¶

Étape 0 — Expression de besoin¶

Description : Claude agit comme agent de clarification neutre. Il structure le besoin brut de l'humain en un document normalisé : contexte, objectifs, non-objectifs, contraintes, scénarios d'échec, tensions, questions ouvertes. Il ne propose jamais de solution technique.

Étape 1 — Spécification¶

Description : ChatGPT produit une spécification normative contractuelle structurée en 10 sections : objectif, périmètre, définitions, invariants, flux nominaux, cas d'erreur, critères d'acceptation, scénarios de test, hypothèses, points ouverts.

Étape 2 — Tests & Validation¶

Description : ChatGPT produit les scénarios de test contractuels au format Given/When/Then, tracés vers les exigences de la spécification (TC-XX). Chaque invariant critique et règle de sécurité doit être couvert par au moins un test.

Étape 3 — Review spécification (Gate CONFORMITY_CHECK)¶

Description : Cette gate vérifie la complétude et la testabilité de la spécification. ChatGPT produit la review, puis Claude confronte spec et tests automatiquement, le dossier de conformité est assemblé, et l'humain rend un verdict structuré.

Étape 4 — Plan d'implémentation¶

Description : Claude produit le plan d'implémentation technique (composants, flux, mapping invariants→mécanismes, mapping tests→observables) et un fichier code-contracts.yaml qui définit les frontières de code par module : agent responsable, interfaces, invariants, patterns interdits, périmètre fichiers.

Étape 5 — Review plan (Gate AMBIGUITY)¶

Description : Cette gate vérifie que le plan d'implémentation n'introduit pas d'hypothèses non déclarées ni d'ambiguïtés par rapport à la spécification. La review inclut aussi l'audit des code contracts (complétude, cohérence des frontières, invariants).

Étape 6 — Implémentation (Multi-agents)¶

Description : Voir section 1.5 Étape 6 — Multi-agents pour le détail du sous-workflow.

Étape 7 — Acceptabilité¶

Description : ChatGPT réalise un audit d'acceptabilité qui confronte l'implémentation à la spécification et aux tests. Il rend un verdict interne (REFUSÉ / ACCEPTÉ AVEC RÉSERVES / ACCEPTÉ) et classifie les écarts éventuels (BLOQUANT / MAJEUR / MINEUR).

Étape 8 — Review acceptabilité (Gate CLOSURE)¶

Description : Gate de clôture. Vérifie que l'implémentation est conforme à la spécification, que tous les tests contractuels passent et que les écarts identifiés à l'acceptabilité ont été traités. Inclut la confrontation avec les livrables agents si disponibles.

Étape 9 — Retour d'expérience¶

Description : Claude documente les décisions techniques prises, la dette technique introduite, les risques identifiés et les améliorations potentielles. Ce document est en append-only (chaque passage ajoute, ne remplace pas).

Post-REX obligatoire (avant clôture Jira) :

1. Mettre à jour data/metrics.jsonl (gate scores, iterations, deviations)
2. Régénérer GOVERNANCE-METRICS.md
3. Exécuter la revue documentaire automatique :

./scripts/check-docs.sh {STORY-ID} {EPIC-DIR} {PROJECT}

Vérifie les 12 documents obligatoires (6 MD + 6 YAML) : besoin, specification, tests, plan, acceptability, rex. Retourne exit 0 (clôture autorisée) ou exit 1 (clôture bloquée). Appelé automatiquement par gov-workflow.sh.

1. Si exit 0 : Transition Jira → Done (31) avec le commentaire généré par le script.

1.4 Gates PMO¶

Les gates sont les étapes 3, 5 et 8. Elles constituent les points de contrôle qualité du workflow. Chaque gate suit un processus en 4 phases :

Diagramme de séquence d'une gate¶

sequenceDiagram
    participant H as Humain
    participant C as Claude (orchestrateur)
    participant GPT as ChatGPT
    participant PMO as PMO (verdict)

    Note over C: Phase 1 — Review ChatGPT
    C->>C: Assemble le prompt de review
    C->>H: Copie le prompt dans le presse-papier
    H->>GPT: Colle le prompt dans ChatGPT
    GPT->>GPT: Analyse et produit la review
    H->>H: Sauvegarde la review dans le dossier epic

    Note over C: Phase 2 — Confrontation automatique
    C->>C: Assemble le prompt de confrontation
    C->>C: Exécute via claude -p
    C->>C: Produit PD-XX-confrontation-stepN.md
    Note right of C: Identifie convergences,<br/>divergences, zones d'ombre

    Note over C: Phase 3 — Dossier de conformité
    C->>C: Collecte tous les artefacts existants
    C->>C: Extrait les hypothèses du plan
    C->>C: Référence le rapport de confrontation
    C->>C: Produit PD-XX-dossier-conformite-stepN.md

    Note over C,PMO: Phase 4 — Verdict PMO
    C->>H: Présente le menu de verdict
    H->>PMO: Choisit GO / RESERVE / NON_CONFORME / ESCALADE
    H->>PMO: Saisit la raison et l'action requise
    PMO->>PMO: Génère PD-XX-verdict-stepN.yaml
    PMO->>C: Retourne le code de sortie (0 / 2 / 3)

Types de gates¶

Documents confrontés par gate¶

1.5 Étape 6 — Multi-agents¶

L'étape 6 est le cœur de l'implémentation. Elle est décomposée en 3 sous-étapes orchestrées par Claude.

Diagramme d'état du step 6¶

stateDiagram-v2
    [*] --> S6a

    state "6a — Décomposition" as S6a {
        [*] --> LirePlan: Lire plan + code contracts
        LirePlan --> Decouper: Découper en tâches par agent
        Decouper --> SauverManifest: Sauver PD-XX-decomposition.md
        SauverManifest --> InitSubsteps: Créer sous-étapes dans WORKFLOW-STATE.md
        InitSubsteps --> [*]
    }

    state "6b — Agents spécialisés" as S6b {
        [*] --> Boucle
        Boucle --> Agent_N: Pour chaque tâche du manifest
        Agent_N --> CheckLLM: Déterminer le LLM (claude/chatgpt)
        CheckLLM --> AssemblerPrompt: Assembler prompt agent
        AssemblerPrompt --> ExecClaude: Si claude → claude -p
        AssemblerPrompt --> ExecChatGPT: Si chatgpt → presse-papier
        ExecClaude --> SauverLivrable
        ExecChatGPT --> SauverLivrable
        SauverLivrable --> Boucle: Tâche suivante
        Boucle --> [*]: Toutes les tâches terminées
    }

    state "6c — Synthèse" as S6c {
        [*] --> CollecterLivrables: Collecter tous les livrables agents
        CollecterLivrables --> Assembler: Assembler + vérifier cohérence
        Assembler --> CodeFinal: Produire le code intégré
        CodeFinal --> [*]
    }

    S6a --> S6b
    S6b --> S6c
    S6c --> [*]

Déroulement détaillé¶

6a — Décomposition : Claude lit le plan d'implémentation et les code contracts, puis découpe le travail en tâches isolées. Chaque tâche est assignée à un agent spécialisé avec un périmètre fichiers précis. Le résultat est un manifest (PD-XX-decomposition.md) qui liste toutes les tâches.

6b — Agents spécialisés : Pour chaque tâche du manifest : 1. L'agent reçoit un prompt contenant : son système prompt (identité), le code contract de son module, la spécification, les tests, le plan, et la description de sa tâche. 2. Si l'agent est mappé sur claude → exécution automatique via claude -p. 3. Si l'agent est mappé sur chatgpt → le prompt est copié dans le presse-papier, l'humain le colle dans ChatGPT et sauvegarde la réponse. 4. Chaque agent produit un livrable : PD-XX-agent-{nom}-{module}.md.

6c — Synthèse : Claude reçoit tous les livrables agents, la spec, les tests, le plan et les code contracts. Il assemble le code final dans le projet cible en vérifiant la cohérence, en résolvant les conflits mineurs (style, nommage) et en signalant les conflits majeurs (logique, interfaces).

Isolation des agents¶

Les agents ne communiquent jamais entre eux. Chaque agent travaille en isolation avec uniquement : - Son système prompt (rôle, contraintes) - Le code contract de son module (interfaces, invariants, fichiers autorisés) - Les documents de référence (spec, tests, plan) - La description de sa tâche

Claude est le seul médiateur entre les agents.

1.6 Mapping agents → LLM¶

Les agents claude -p sont exécutés automatiquement. Les agents ChatGPT nécessitent un copier-coller manuel.

1.7 Artefacts produits¶

Tous les artefacts sont stockés dans le dossier epic du projet cible : ProbatioVault-{projet}/docs/epics/{domaine}/{PD-XX-description}/

1.8 Verdicts PMO¶

Les 4 verdicts possibles¶

Diagramme de flux des verdicts¶

flowchart LR
    Gate[Gate PMO<br/>step 3/5/8] --> Verdict{Verdict}

    Verdict -->|GO| Continue[Workflow continue<br/>étape suivante]
    Verdict -->|RESERVE| ContinueR[Workflow continue<br/>avec conditions]
    Verdict -->|NON_CONFORME| Pause[Workflow en pause<br/>corrections requises]
    Verdict -->|ESCALADE| Hold[Workflow en pause<br/>décision humaine]

    Continue --> NextStep[Étape N+1]
    ContinueR --> NextStep

    Pause --> Rework[Corriger les écarts]
    Rework --> Relaunch[Relancer le workflow]
    Relaunch --> Gate

    Hold --> Human[Décision humaine]
    Human --> Relaunch

Format YAML du verdict¶

pmo_verdict:
  workflow: PD-XX
  step: 3
  gate_type: CONFORMITY_CHECK
  status: GO
  reason: "Spécification complète et testable"
  required_action: ""
  escalation: false
  date: 2026-01-15
  reviewer: human

Partie 2 : Documentation technique¶

2.1 Architecture des composants¶

Diagramme de dépendances¶

flowchart TD
    subgraph "Commandes Claude"
        GOV["/gov"]
        GOVSTEP["/gov-step"]
        GOVSTATUS["/gov-status"]
        GOVHELP["/gov-help"]
    end

    subgraph "Scripts principaux"
        GW["gov-workflow.sh<br/>(orchestrateur séquentiel)"]
        GS["gov-step.sh<br/>(exécution d'une étape)"]
        GST["gov-status.sh<br/>(affichage état)"]
    end

    subgraph "Bibliothèques (scripts/lib/)"
        STATE["state.sh<br/>(gestion WORKFLOW-STATE.md)"]
        INJECT["inject-docs.sh<br/>(assemblage de prompts)"]
        AGENTS["agents.sh<br/>(gestion multi-agents)"]
        RPROJ["resolve-project.sh<br/>(résolution projet)"]
        REPIC["resolve-epic.sh<br/>(résolution dossier epic)"]
    end

    subgraph "Données"
        PROMPTS["templates/prompts/<br/>(14 templates de prompts)"]
        TEMPLATES["templates/outputs/<br/>(13 templates de sortie)"]
        AGENTDEFS["agents/<br/>(13 définitions d'agents)"]
        STATE_FILE["WORKFLOW-STATE.md<br/>(dans le dossier epic)"]
    end

    subgraph "LLM"
        CLAUDE["claude -p<br/>(automatisé)"]
        CHATGPT["ChatGPT<br/>(copier-coller)"]
    end

    GOV --> GW
    GOVSTEP --> GS
    GOVSTATUS --> GST

    GW --> GS
    GW --> STATE
    GW --> RPROJ
    GW --> REPIC

    GS --> STATE
    GS --> INJECT
    GS --> AGENTS
    GS --> RPROJ
    GS --> REPIC

    GST --> STATE
    GST --> RPROJ
    GST --> REPIC

    INJECT --> PROMPTS
    INJECT --> TEMPLATES
    AGENTS --> AGENTDEFS
    STATE --> STATE_FILE

    GS --> CLAUDE
    GS --> CHATGPT
    AGENTS --> CLAUDE
    AGENTS --> CHATGPT

2.2 Scripts principaux¶

gov-workflow.sh¶

• Fichier : scripts/gov-workflow.sh
• Rôle : Orchestrateur principal. Lance les étapes séquentiellement, gère les pauses et interruptions.
• Arguments : <STORY-ID> [projet]
• Dépendances : resolve-project.sh, resolve-epic.sh, state.sh

Fonctions : Aucune fonction propre (utilise les libs).

Flux d'exécution : 1. Valide les arguments 2. Résout le projet (cascade : argument → auto-détection → interactif) 3. Trouve ou crée le dossier epic 4. Initialise WORKFLOW-STATE.md 5. Affiche l'état courant 6. Détermine l'étape courante (première non DONE) 7. Boucle sur les étapes : - Lance gov-step.sh en sous-processus - Gère le code de sortie (0→continue, 2→NON_CONFORME, 3→ESCALADE) - Demande confirmation entre chaque étape

Codes de sortie :

gov-step.sh¶

• Fichier : scripts/gov-step.sh
• Rôle : Exécute une seule étape du workflow dans un contexte isolé.
• Arguments : <STORY-ID> <STEP-NUM> [projet]
• Dépendances : resolve-project.sh, resolve-epic.sh, state.sh, inject-docs.sh, agents.sh

Fonctions :

Flux d'exécution principal (selon le type) :

• Claude (0, 4, 9) : assemble_prompt() → pbcopy → attente humaine → vérification artefact → DONE
• Multi-agent (6) : execute_multiagent_step6() → 6a/6b/6c → DONE
• ChatGPT (1, 2, 7) : assemble_prompt() → pbcopy → attente humaine → vérification artefact → DONE
• Gate (3, 5, 8) : assemble_prompt() (review) → execute_confrontation() → assemble_dossier() → collect_verdict()

Codes de sortie :

gov-status.sh¶

• Fichier : scripts/gov-status.sh
• Rôle : Affiche l'état complet du workflow pour une story.
• Arguments : <STORY-ID> [projet]
• Dépendances : resolve-project.sh, resolve-epic.sh, state.sh

Fonctions : Aucune fonction propre.

Flux d'exécution : 1. Résout le projet et le dossier epic 2. Appelle display_state() pour afficher le tableau d'état 3. Liste les artefacts principaux trouvés 4. Liste les artefacts de gouvernance (verdicts, confrontations, dossiers, code contracts, décomposition, livrables agents)

Code de sortie : 0 (succès) ou 1 (epic non trouvé).

2.3 Bibliothèques (scripts/lib/)¶

state.sh¶

• Fichier : scripts/lib/state.sh
• Rôle : Gestion du fichier WORKFLOW-STATE.md (création, lecture, mise à jour).

Variables globales :

Fonctions :

inject-docs.sh¶

• Fichier : scripts/lib/inject-docs.sh
• Rôle : Moteur d'assemblage des prompts avec injection de documents.

Variables globales :

Fonctions :

Mécanisme d'assemblage d'un prompt :

1. Localiser le template de prompt (pattern glob)
2. Lire le contenu et remplacer PD-XX par le vrai story ID
3. Injecter les documents obligatoires (## DOCUMENT D'ENTRÉE : ...)
4. Injecter les documents optionnels si présents (## DOCUMENT COMPLÉMENTAIRE : ...)
5. Injecter le template de sortie si applicable (## TEMPLATE DE SORTIE)
6. Ajouter les instructions de sauvegarde (## INSTRUCTIONS DE SAUVEGARDE)

agents.sh¶

• Fichier : scripts/lib/agents.sh
• Rôle : Gestion des agents spécialisés pour le workflow multi-agents (étape 6).

Variables globales :

Fonctions :

resolve-project.sh¶

• Fichier : scripts/lib/resolve-project.sh
• Rôle : Résolution du chemin du projet cible en cascade.

Variables : PROBATIOVAULT_ROOT, KNOWN_PROJECTS (backend, app, site, infra, doc).

Fonctions :

resolve-epic.sh¶

• Fichier : scripts/lib/resolve-epic.sh
• Rôle : Localisation du dossier epic pour une user story.

Fonctions :

2.4 Templates de prompts¶

Tous les templates sont dans templates/prompts/. Chaque prompt contient des placeholders PD-XX remplacés automatiquement par le story ID réel.

2.5 Templates de sortie¶

Tous les templates sont dans templates/outputs/. Ils définissent la structure attendue des artefacts produits.

2.6 Définitions des agents¶

Chaque agent est défini dans un fichier Markdown dans agents/. Le fichier contient le système prompt de l'agent : son rôle, ses responsabilités, ses contraintes et ses interdictions.

2.7 Commandes Claude¶

Les commandes slash sont définies dans .claude/commands/ et permettent d'invoquer le workflow directement depuis Claude Code.

Arguments¶

• STORY-ID : Identifiant de la user story (ex: PD-25, PD-42)
• STEP : Numéro d'étape de 0 à 9
• projet (optionnel) : Nom du projet cible (backend, app, infra, site, doc)

2.8 Gestion de l'état (WORKFLOW-STATE.md)¶

Format du fichier¶

Le fichier WORKFLOW-STATE.md est créé dans le dossier epic de chaque story. C'est un fichier Markdown avec un tableau structuré :

# Workflow State: PD-42
Projet cible: ProbatioVault-backend

| Étape | Nom | Agent | Statut | Gate | Artefact | Verdict | Date |
|-------|-----|-------|--------|------|----------|---------|------|
| 0 | Expression de besoin | Claude | DONE | | PD-42-besoin.md | | 2026-01-15 |
| 1 | Spécification | ChatGPT | DONE | | PD-42-specification.md | | 2026-01-16 |
| ...

## Gates PMO
- [x] Step 3: approuvé le 2026-01-18 (GO)
- [ ] Step 5: Review plan (AMBIGUITY)
- [ ] Step 8: Review acceptabilité (CLOSURE)

## Sous-étapes (step 6 — multi-agents)
| Sous-étape | Nom | Agent | LLM | Statut | Livrable | Date |
|------------|-----|-------|-----|--------|----------|------|
| 6a | Décomposition | Claude (orchestrateur) | claude | DONE | PD-42-decomposition.md | 2026-01-20 |
| 6b-1 | agent-developer — storage | agent-developer | claude | DONE | PD-42-agent-developer-storage.md | 2026-01-20 |
| 6b-2 | agent-adversarial — security | agent-adversarial | claude | IN_PROGRESS | ... | |
| 6c | Synthèse | Claude (orchestrateur) | claude | PENDING | (code) | |

Statuts possibles¶

Mécanisme des sous-étapes¶

Les sous-étapes n'existent que pour l'étape 6 (multi-agents). Elles sont créées dynamiquement après la phase 6a de décomposition :

1. L'utilisateur exécute 6a et produit le manifest PD-XX-decomposition.md
2. init_substeps() parse le manifest et crée les lignes 6b-1..N dans le tableau des sous-étapes
3. Chaque sous-étape est mise à jour indépendamment via update_substep_status()
4. Le statut global de l'étape 6 passe à DONE quand toutes les sous-étapes sont DONE

2.9 Arborescence des fichiers¶

ProbatioVault-ia-governance/
├── CLAUDE.md                              # Instructions Claude Code
├── README.md
├── .claude/
│   ├── CLAUDE.md                          # Instructions locales
│   └── commands/
│       ├── gov.md                         # Commande /gov
│       ├── gov-step.md                    # Commande /gov-step
│       ├── gov-status.md                  # Commande /gov-status
│       └── gov-help.md                    # Commande /gov-help
├── agents/                                # Définitions des agents
│   ├── index.md
│   ├── pmo.md
│   ├── agent-developer.md
│   ├── agent-adversarial.md
│   ├── agent-sre.md
│   ├── agent-qa.md
│   ├── agent-qa-unit-integration.md
│   ├── agent-qa-ihm.md
│   ├── agent-metier.md
│   ├── agent-compliance-auditor.md
│   ├── agent-architect.md
│   ├── agent-release-manager.md
│   ├── agent-documentation-maintainer.md
│   ├── agent-human.md
│   └── director-commercial.md
├── docs/
│   ├── AI-governance.md
│   ├── process-workflow.md
│   ├── specification_generale.md
│   ├── specification_architecture_multi_agents_gouvernee.md
│   ├── guide-claude-code-multi-agents.md
│   ├── workflow-documentation.md          # CE DOCUMENT
│   ├── prompts/                           # Templates de prompts (14 fichiers)
│   │   ├── 0 Expression de besoin.md
│   │   ├── 1 Specification.md
│   │   ├── 2 Tests & Validation.md
│   │   ├── 3 Spécification – Review.md
│   │   ├── 4 Plan d'implémentation.md
│   │   ├── 5 Plan d'implémentation - Review.md
│   │   ├── 6 Implémentation.md
│   │   ├── 6a Decomposition.md
│   │   ├── 6b Agent Task.md
│   │   ├── 6c Synthese.md
│   │   ├── 7 Acceptabilité.md
│   │   ├── 8 Revue d'acceptabilité (post-correction).md
│   │   ├── 9 Retour d'expérience.md
│   │   └── confrontation.md
│   ├── templates/                         # Templates de sortie (13 fichiers)
│   │   ├── PD-XX-specification.md
│   │   ├── PD-XX-tests.md
│   │   ├── PD-XX-plan.md
│   │   ├── PD-XX-plan-review.md
│   │   ├── PD-XX-acceptability.md
│   │   ├── PD-XX-acceptability-review.md
│   │   ├── PD-XX-rex.md
│   │   ├── PD-XX-epic.md
│   │   ├── PD-XX-code-contracts.yaml
│   │   ├── PD-XX-decomposition.md
│   │   ├── PD-XX-confrontation.md
│   │   ├── PD-XX-dossier-conformite.md
│   │   └── PD-XX-verdict.yaml
│   └── skills/                            # Compétences spécialisées
│       ├── index.md
│       ├── workflow/
│       ├── standards/
│       ├── compliance/
│       ├── documentation/
│       └── testing/
├── scripts/
│   ├── gov-workflow.sh                    # Orchestrateur principal
│   ├── gov-step.sh                        # Exécution d'une étape
│   ├── gov-status.sh                      # Affichage état
│   └── lib/
│       ├── state.sh                       # Gestion WORKFLOW-STATE.md
│       ├── inject-docs.sh                 # Assemblage de prompts
│       ├── agents.sh                      # Gestion multi-agents
│       ├── resolve-project.sh             # Résolution projet
│       └── resolve-epic.sh               # Résolution dossier epic
├── governance/                              # Principes de gouvernance
│   ├── governance-principles.md
│   ├── decision-authority.md
│   ├── escalation-policy.md
│   └── interaction-rules.md
├── rbac/                                  # Rôles et permissions
│   ├── roles.md
│   └── permissions-matrix.md
├── workflows/                             # Workflows métier
│   ├── code-generation.md
│   ├── spec-review.md
│   ├── qa-validation.md
│   ├── documentation-update.md
│   └── incident-response.md
├── integration/                           # Guides d'intégration
│   ├── claude-code.md
│   ├── chatgpt-usage.md
│   ├── local-llm.md
│   └── migration-plan.md
└── history/                               # Historique
    ├── decisions-log.md
    └── major-changes.md