Pipeline d'Orchestration (moteur partagé)
Les compétences orch-* sont des enveloppes fines. Elles ne réimplémentent aucun travail — elles
classifient la demande, choisissent quelles phases de ce pipeline exécuter,
et délèguent chaque phase à un agent ECC existant ou à une commande. Ce fichier est ce pipeline.
Invoquez une compétence d'opération (
orch-add-feature,orch-fix-defect, …) plutôt que ce moteur directement. Ce fichier est la référence qu'elles pointent.
Quand l'utiliser
- Chargé indirectement chaque fois qu'une compétence d'opération
orch-*s'exécute. - Lu directement uniquement lors de l'ajout d'une nouvelle opération à la famille ou du réglage des phases partagées, des points de validation ou de la carte des agents.
La famille d'opérations
| Compétence | Opération | Déclencheur | Première action |
|---|---|---|---|
orch-add-feature | fonctionnalité | la capacité n'existe pas encore | rechercher + planifier une nouvelle tranche |
orch-change-feature | ajustement | fonctionne, mais le comportement souhaité diffère | modifier le comportement existant et ses tests |
orch-fix-defect | correction | cassé ; le comportement est erroné | reproduire par un test échouant, puis corriger |
orch-refine-code | refactorisation | le comportement reste, la structure s'améliore | restructurer tout en gardant les tests verts |
orch-build-mvp | mvp | amorcer à partir d'un document de conception/spécification | ingérer le document → tranches verticales |
Ces enveloppes composent les commandes ECC existantes plutôt que de les remplacer :
/feature-dev,/plan,/code-review,/build-fix,/refactor-clean, et/gan-build, plus la compétencetdd-workflow. La familleorch-*ajoute le classificateur de taille partagé et les deux points de validation par-dessus, de sorte qu'un même parapluie couvre les cinq opérations de manière cohérente.
Étape 0 — Classifier la taille (dimensionnement adapté)
La cérémonie s'adapte au périmètre. Évaluez la demande sur trois signaux, prenez le niveau le plus élevé que tout signal atteint, et énoncez le résultat en une ligne pour que l'utilisateur puisse le modifier :
| Niveau | Fichiers touchés | Nouvelle dépendance / contrat | Ambiguïté de conception | Phases exécutées |
|---|---|---|---|---|
| trivial | 1, quelques lignes | aucune | aucune — la modification est évidente | 4 → 5 → 6 |
| petit | 1 fichier / 1 fonction | aucune | claire une fois le code lu | (1 légère) → 4 → 5 → 6 |
| standard | 2–5 fichiers | peut-être un nouveau module interne | un vrai choix à faire | 1 → 2 → 4 → 5 → 6 |
| grand | plusieurs / transversal | nouvelle dépendance externe, API publique, ou document de spécification | plusieurs questions ouvertes | 1 → 2 → (3) → 4 → 5 → 6 |
La phase 0 (Analyse) s'exécute toujours et est omise de la colonne de masque ci-dessus. Le décision pour les égalités : tout ce qui touche un déclencheur de sécurité (ci-dessous) ou une API publique / contrat est au moins standard, indépendamment du nombre de fichiers.
Les phases
Chaque phase délègue — elle n'effectue pas le travail en ligne.
- 0. Analyse — reformuler la demande. Pour
orch-build-mvp, lire le document de spécification/conception et extraire le périmètre, les décisions verrouillées et une liste de fonctionnalités. - 1. Recherche et réutilisation — selon
rules/common/development-workflow.md:gh search repos/gh search code, puis Context7 / documentations fournisseurs, puis registres de paquets, puis Exa. Privilégier l'adoption d'une implémentation éprouvée plutôt qu'un nouveau code. - 2. Planification — déléguer à l'agent
planner(ouarchitect/code-architectpour les décisions structurelles). Produire unetask_listordonnée en tranches verticales fines. → POINT DE VALIDATION 1. - 3. Échafaudage —
orch-build-mvpuniquement : mettre en place la première tranche de bout en bout. - 4. Implémentation (TDD) — piloter chaque tâche via l'agent
tdd-guide(ou la compétencetdd-workflow) : rouge → vert → refactoriser. Respecter la règle de première action de l'opération. - 5. Révision — agent
code-reviewer//code-review. Ajoutersecurity-reviewerchaque fois que le diff touche un déclencheur de sécurité (ci-dessous). - 6. Validation — commits conventionnels (
feat:/fix:/refactor:/ …), un par morceau logique. → POINT DE VALIDATION 2.
Les deux points de validation
Cette famille est validée, pas autonome :
- POINT DE VALIDATION 1 — après la Planification. Présenter la
task_list; ne pas écrire de code d'implémentation tant que l'utilisateur n'a pas approuvé. - POINT DE VALIDATION 2 — avant la Validation. Présenter le résumé du diff et les messages proposés ; ne pas valider tant que l'utilisateur n'a pas confirmé.
Tout ce qui se trouve entre les points de validation s'exécute sans interruption.
Carte des agents / commandes
| Phase | Principal | Solution de repli / escalade |
|---|---|---|
| Analyse / compréhension | code-explorer | tracer les chemins existants avant un ajustement, une correction ou une refactorisation |
| Planification | planner | architect, code-architect pour les décisions structurelles |
| Implémentation | tdd-guide (ou compétence tdd-workflow) | build-error-resolver / /build-fix en cas d'erreurs de build |
| Révision | code-reviewer / /code-review | réviseur de langage (python-reviewer, typescript-reviewer, …) |
| Sécurité | security-reviewer | — |
| Boucle interne MVP | /gan-build "<brief>" --skip-planner | pilote gan-generator → gan-evaluator ; ajuster --max-iterations / --pass-threshold |
Associer le réviseur de langage au dépôt (voir le CLAUDE.md propre au dépôt).
Déclencheur de révision de sécurité
Inclure security-reviewer lorsque le diff touche l'un des éléments suivants : authentification ou
autorisation, traitement des entrées utilisateur, requêtes de base de données, chemins de système de fichiers,
appels d'API externes, cryptographie, ou secrets / identifiants. (Selon rules/common/security.md.)
Artéfacts de transfert
Le pipeline ne transporte aucun état caché — les documents de planification sont le transfert :
task_list(de la Planification) pilote la boucle d'Implémentation.- Les travaux plus importants peuvent également émettre PRD / architecture / system_design sous le
docs/du dépôt selonrules/common/development-workflow.md. - Les constats de révision (CRITIQUE / HAUT) doivent être résolus avant le Point de validation 2.
Vérification
- le niveau de taille a été indiqué et correspondait au travail
- le Point de validation 1 (planification) et le Point de validation 2 (validation) ont tous deux été respectés
security-reviewera été exécuté si et seulement si un déclencheur de sécurité a été touché- les commits sont conventionnels et limités à un seul changement logique
- les nouveaux comportements / modifiés ont des tests ; couverture ≥ 80 % selon
rules/common/testing.md