Fonctionnalités Avancées

Ces fonctionnalités permettent des flux de travail SDD collaboratifs, à grande échelle et en parallèle. Elles s'appuient sur le cycle de vie principal — assurez-vous de maîtriser le Flux SDD avant de les utiliser.

1. Ramification de Specs

Outils : branch_spec, merge_spec_branch

Pensez aux branches de specs comme aux branches Git — mais pour vos plans. Créez une variante A/B pour explorer une approche d'implémentation différente avant de vous engager.

Quand l'utiliser :

• Décisions d'architecture avec plusieurs approches valides
• Expériences d'interface utilisateur (spec A de refonte vs. spec B incrémentale)
• Lorsqu'un partie prenante demande une estimation alternative

Quand NE PAS l'utiliser

Ne créez pas de branches de specs pour de petites modifications de formulation ou des corrections de fautes de frappe. Les branches sont réservées aux stratégies d'implémentation fondamentalement différentes — si les deux approches touchent les mêmes fichiers, résolvez la décision d'abord, puis implémentez.

Comment ça fonctionne :

1. Ramifiez une spec existante pour créer une variante :

"Ramifie la spec SPEC-042 en variant-B avec une approche microservices"
→ branch_spec(specId: "SPEC-042", branchName: "variant-b", description: "...")

2. Développez les deux variantes de façon indépendante. Chaque branche possède ses propres critères d'acceptation et son PLAN.md.

3. Comparez les estimations et choisissez la gagnante. Puis fusionnez :

"Fusionne la branche variant-b dans la spec SPEC-042"
→ merge_spec_branch(specId: "SPEC-042", branchName: "variant-b")

Planu détecte les conflits entre variantes et signale les critères contradictoires avant la fusion.

---

2. Fédération de Specs

Outils : federate_specs, federation_status

Partagez et synchronisez des specs entre plusieurs dépôts. Indispensable pour les monorepos, les microservices et les équipes de plateforme.

Quand l'utiliser :

• L'équipe plateforme possède des specs partagées (authentification, paiements, logging)
• Monorepo avec plusieurs services partageant des exigences
• Specs de contrats d'API partagées entre les dépôts frontend et backend

Quand NE PAS l'utiliser

Ne fédérez pas des specs étroitement couplées aux détails internes d'un seul service. La fédération est destinée aux contrats partagés — pas à la réplication de détails d'implémentation entre dépôts.

Comment ça fonctionne :

1. Dans le dépôt source, publiez une spec vers une cible en aval :

"Fédère la spec SPEC-010 vers team/payments-service"
→ federate_specs(...)

2. Dans le dépôt cible, la spec apparaît en lecture seule avec un lien vers la source. Les équipes en aval peuvent la référencer mais ne peuvent pas la modifier directement.

3. Les modifications se synchronisent automatiquement ou à la demande. Vérifiez l'état de synchronisation à tout moment :

"Vérifie le statut de fédération"
→ federation_status()

Le rapport d'état indique quelles specs sont en avance, en retard ou en conflit avec leur source.

---

3. Orchestration d'Équipes d'Agents

Outils : plan_team_distribution, orchestrate_runtime, orchestrate_agents

Répartissez une grande spec entre plusieurs agents IA en parallèle, chacun avec la propriété exclusive de fichiers spécifiques.

Quand l'utiliser :

• Specs touchant 5+ modules indépendants
• Grandes refactorisations avec des frontières de fichiers clairement définies
• Fonctionnalités urgentes pouvant être parallélisées

Quand NE PAS l'utiliser

N'orchestrez pas de petites specs (moins de 3 fichiers). Le coût de coordination dépasse le temps économisé. Évitez aussi l'orchestration lorsque les modules sont étroitement couplés — les agents ne peuvent pas résoudre les conflits inter-fichiers en cours d'exécution.

Comment ça fonctionne :

1. Planifiez la répartition — Planu analyse la spec et propose les assignations d'agents :

"Planifie la distribution de l'équipe pour SPEC-099"
→ plan_team_distribution(specId: "SPEC-099")
→ Résultat : 3 agents, assignations de fichiers, durée estimée

2. Lancez l'orchestration — les agents travaillent en parallèle, chacun avec ses fichiers assignés :

"Orchestre SPEC-099 avec 3 agents"
→ orchestrate_runtime(specId: "SPEC-099", agentCount: 3)
→ Les agents travaillent en parallèle, Planu surveille la progression

3. Surveillez et finalisez :

"Vérifie le statut de l'orchestration"
→ orchestrate_agents(action: "status")

Règles appliquées par Planu :

• Chaque agent possède des fichiers exclusifs — pas d'éditions concurrentes
• Les tests d'intégration s'exécutent après la fin de tous les agents
• Les conflits sont signalés, pas résolus automatiquement

---

Prochaines Étapes

• Consultez la Référence des Outils pour la documentation complète des paramètres
• Revenez au Flux SDD pour le cycle de vie principal