Pipeline de l'Orchestrateur (moteur partagé)
Les compétences orch-* sont des surcouches légères. Elles ne réimplémentent aucune tâche — elles classifient la demande, choisissent quelles phases de ce pipeline exécuter, et délèguent chaque phase à un agent ECC ou une commande existante. Ce fichier est ce pipeline.
Invoquez une compétence opérationnelle (
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 exécution d'une compétence opérationnelle
orch-*. - Lu directement uniquement lors de l'ajout d'une nouvelle opération à la famille ou de l'ajustement des phases, portes ou de la carte des agents partagés.
La famille d'opérations
| Compétence | Opération | Déclencheur | Première action |
|---|---|---|---|
orch-add-feature | feature | la capacité n'existe pas encore | rechercher + planifier une nouvelle tranche |
orch-change-feature | ajustement | ça fonctionne, mais le comportement souhaité diffère | modifier le comportement existant et ses tests |
orch-fix-defect | correction | cassé ; le comportement est erroné | reproduire via 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 depuis un document de conception/spécification | ingérer le document → tranches verticales |
Ces surcouches composent des 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 famille orch-* ajoute le classificateur de taille partagé et les deux portes par-dessus, de sorte qu'un seul parapluie couvre les cinq opérations de manière cohérente.
Étape 0 — Classifier la taille (dimensionnement adapté)
Le formalisme s'adapte à l'étendue de l'impact. Évaluez la demande sur trois signaux, retenez le plus haut niveau atteint par l'un des signaux, et affichez le résultat sur 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 | aucun | aucune — la modification est évidente | 4 → 5 → 6 |
| petit | 1 fichier / 1 fonction | aucun | 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 | nombreux / transversaux | nouvelle dépendance externe, API publique ou document de spécification | plusieurs questions ouvertes | 1 → 2 → (3) → 4 → 5 → 6 |
La phase 0 (Réception) est toujours exécutée et omise de la colonne de masque ci-dessus. La règle de départage : tout ce qui touche à un déclencheur de sécurité (ci-dessous) ou à une API publique / contrat est au moins standard, quel que soit le nombre de fichiers.
Les phases
Chaque phase délègue — elle n’effectue pas le travail en ligne.
- 0. Réception — reformuler la demande. Pour
orch-build-mvp, lire le document de spécification/conception et extraire le périmètre, les décisions figé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 / docs fournisseurs, puis registres de paquets, puis Exa. Privilégier l'adoption d'une implémentation éprouvée plutôt que du code entièrement nouveau. - 2. Planification — déléguer à l'agent
planner(ouarchitect/code-architectpour les décisions structurelles). Produire unetask_listordonnée en tranches verticales fines. → BARRIÈRE 1. - 3. Échafaudage —
orch-build-mvpuniquement : mettre en place la première tranche de bout en bout. - 4. Implémenter (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. Revue — agent
code-reviewer//code-review. Ajoutersecurity-reviewerlorsque le diff touche un déclencheur de sécurité (ci-dessous). - 6. Commit — commits conventionnels (
feat:/fix:/refactor:/ …), un par bloc logique. → BARRIÈRE 2.
Les deux barrières
Cette famille est contrôlée, pas autonome :
- BARRIÈRE 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é. - BARRIÈRE 2 — avant le Commit. Présenter le résumé du diff et les messages proposés ; ne pas commit tant que l'utilisateur n'a pas confirmé.
Tout ce qui se trouve entre les barrières s'exécute sans interruption.
Carte des agents / commandes
| Phase | Primaire | Secondaire / escalade |
|---|---|---|
| Réception / compréhension | code-explorer | tracer les chemins existants avant un ajustement, une correction ou une refactorisation |
| Planification | planner | architect, code-architect pour les appels structurels |
| Implémentation | tdd-guide (ou compétence tdd-workflow) | build-error-resolver / /build-fix en cas d'échec de build |
| Revue | code-reviewer / /code-review | relecteur 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 |
Faire correspondre le relecteur de langage au dépôt (voir le CLAUDE.md du dépôt lui-même).
Déclencheur de revue de sécurité
Faire intervenir 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 fichiers, appels 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 produire PRD / architecture / system_design dans le
docs/du dépôt selonrules/common/development-workflow.md. - Les résultats de revue (CRITIQUE / HAUTE) doivent être résolus avant la Barrière 2.
Vérification
- le niveau de taille a été indiqué et correspond au travail
- la Barrière 1 (plan) et la Barrière 2 (commit) ont toutes deux été respectées
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 / comportements modifiés ont des tests ; couverture ≥ 80 % selon
rules/common/testing.md