/ba-develop — Du PRD au code/ba-develop — From PRD to code

Une fois qu'une PRD a passé l'audit (score GO ≥ 80), /ba-develop orchestre 4 phases séquentielles pour générer le code complet d'un module. C'est la dernière commande que vous tapez : à sa sortie, le module est compilé, testé, et fonctionnel — aucune action manuelle requise derrière. Once a PRD passes audit (GO score ≥ 80), /ba-develop orchestrates 4 sequential phases to generate the full module code. It is the last command you type: when it returns, the module compiles, passes tests, and is functional — no manual action required afterwards.

Vue d'ensemble du pipelinePipeline at a glance

4 phases séquentielles, chacune isolée dans son propre subagent, séparées par des gates bloquants qui interdisent toute progression sur un drift détecté. Les deux audits symétriques (audit-dev-api en sortie de Phase 2 et audit-dev-frontend en sortie de Phase 3) verrouillent l'alignement entre le pagespec (source de vérité métier) et le code généré. 4 sequential phases, each isolated in its own subagent, separated by blocking gates that forbid progression on any detected drift. The two symmetric audits (audit-dev-api exiting Phase 2 and audit-dev-frontend exiting Phase 3) lock the alignment between the pagespec (business source of truth) and the generated code.

Détail des 4 phasesThe 4 phases in detail

Chaque phase est un subagent isolé qui reçoit UNE slice du PRD. Une porte (gate) vérifie compilation + tests + audit dédié avant d'autoriser la phase suivante. Each phase runs as an isolated subagent that receives ONE PRD slice. A gate verifies compile + tests + dedicated audit before allowing the next phase to start.

À la sortie de la phase 3, le module est livré et fonctionnel (compilation + tests OK, smoke-test HTTP vert sur toutes les routes). At the end of phase 3, the module is delivered and functional (compile + tests OK, HTTP smoke-test green on all routes).

GarantiesGuarantees

• Aucun stub : règles métier et use cases sont implémentés, pas laissés vides.No stubs: business rules and use cases are implemented, not left empty.
• FK réelles : relations[] du PRD se traduit en HasForeignKey() + navigation + OnDelete.Real FKs: PRD relations[] map to HasForeignKey() + navigation + OnDelete.
• Phase 0 déterministe : la navigation + les rôles + les permissions sont écrites en un seul shot.Deterministic Phase 0: navigation + roles + permissions are written in a single shot.
• Gates entre phases : compile + tests + coverage avant de passer à la suivante.Gates between phases: compile + tests + coverage before moving to the next.

Propagation des actions customCustom-action propagation

Quand un pagespec déclare des actions au-delà des CRUD standard (par exemple syncFromPce kind:api ou openHistory kind:navigate), /ba-develop les propage verbatim à toutes les couches qui doivent les voir. Le champ endpoint du pagespec est l'unique source de vérité — il est compilé sans transformation dans le route attribute du Controller et dans l'URL axios du service. When a pagespec declares actions beyond the standard CRUD (e.g. syncFromPce kind:api or openHistory kind:navigate), /ba-develop propagates them verbatim to every layer that must see them. The pagespec's endpoint field is the single source of truth — it is compiled without transformation into the Controller route attribute and into the service's axios URL.

Les audits dev symétriques verrouillent l'alignement après génération : The symmetric dev audits lock the alignment after generation:

Garantie de fin de pipeline — un drift entre pagespec et Controller (cas classique Gesa : POST /sync-from-pce côté frontend, [HttpPost("sync-from-proconcept")] côté backend → 405 garanti) est bloqué au gate avant Phase 3, avec un message précis (« Controller manquant pour action <endpoint> du pagespec <file> »). Aucune commande utilisateur n'est requise après /ba-develop — quand la commande retourne avec succès, le module est 100 % opérationnel. End-of-pipeline guarantee — any drift between pagespec and Controller (classic Gesa case: POST /sync-from-pce on the frontend, [HttpPost("sync-from-proconcept")] on the backend → guaranteed 405) is blocked at the gate before Phase 3, with a precise message ("Controller missing for action <endpoint> from pagespec <file>"). No user command is required after /ba-develop — when the command returns successfully, the module is 100 % operational.

Trois niveaux d'orchestrationThree orchestration levels

Selon la portée du travail, trois entrées sont disponibles. Elles partagent toutes le même moteur (les 4 phases ci-dessus) mais varient en cardinalité. Depending on the scope of work, three entry points are available. They all share the same engine (the 4 phases above) but vary in cardinality.

Cycle multi-module — comment ça marcheMulti-module cycle — how it works

Le multi-module fonctionne en deux temps : Multi-module works in two steps:

1. Génération du plan : /ba-create-plan-development APP_A APP_B lit chaque entité.md, détecte les FK cross-module, trie les modules par dépendance en vagues parallélisables, et écrit dev-plan.json.Plan generation: /ba-create-plan-development APP_A APP_B reads every entité.md, detects cross-module FKs, sorts modules by dependency into parallelisable waves, and writes dev-plan.json.
2. Exécution du plan : /ba-develop-plan traite une vague à la fois. Dans chaque vague, il lance un subagent /ba-develop par module en parallèle ; une fois les N modules terminés, un gate compile + tests sur l'ensemble doit passer avant la vague suivante.Plan execution: /ba-develop-plan processes one wave at a time. Within each wave it launches one /ba-develop subagent per module in parallel; once the N modules complete, a compile + tests gate over the whole set must pass before the next wave starts.

Exemple : un plan à 3 vagues sur 2 applications. Example: a 3-wave plan over 2 applications.

Pourquoi des vagues ? Un module qui possède une entité référencée comme FK par un autre module doit être livré avant ses dépendants. Les vagues encodent cet ordre tout en autorisant le maximum de parallélisme. Why waves? A module whose entity is referenced as an FK by another module must ship before its dependents. Waves encode that ordering while allowing maximum parallelism.

Outil de remédiation — projets legacyRemediation tool — legacy projects

Pour les projets qui ont été développés avant la propagation typée des actions (custom actions en texte libre dans screen.md, drifts pagespec / Controller / service.ts accumulés), un CLI standalone cartographie les désalignements sans rien modifier par défaut : For projects developed before typed action propagation existed (free-text custom actions in screen.md, accumulated pagespec / Controller / service.ts drifts), a standalone CLI maps the misalignments without modifying anything by default:

npx tsx templates/skills/development/audit-dev-frontend/cli/audit-dev-actions-alignment/index.ts `
  --project-path "<chemin>/web/<app>-web" `
  --backend-path "<chemin>" `
  --module-path  "<chemin>/.smartstack/ba/<APP>/<MODULE>" `
  --mode report-only

Sortie : _audit/actions-alignment.md listant les drifts par catégorie (ACTION-DRIFT-001..005) avec, pour chaque drift, le pagespec / Controller / service concerné et la commande de correction. Le mode --mode apply existe (opt-in) avec --source-of-truth pagespec|controller pour choisir qui gagne — toujours à utiliser avec un commit propre derrière. Output: _audit/actions-alignment.md listing drifts per category (ACTION-DRIFT-001..005) with, for each, the affected pagespec / Controller / service and the fix command. The --mode apply mode exists (opt-in) with --source-of-truth pagespec|controller to choose who wins — always use it with a clean commit behind.

Quand l'utiliser : on hérite d'un projet ancien ; on observe un bug HTTP 405 / 404 sur un bouton ; on veut auditer un module avant de le migrer au format custom actions typé. When to use it: inheriting an old project; observing a 405 / 404 HTTP bug on a button; auditing a module before migrating it to typed custom actions.

Skills orchestréesOrchestrated skills

La table ci-dessous liste toutes les skills mobilisées (planification, backend, frontend, audits, tests) : The table below lists every mobilised skill (planning, backend, frontend, audits, tests):