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

/ba-develop <APP>/<MODULE>              # run normal (les phases dont le gate passe sont sautées)
/ba-develop <APP>/<MODULE> --force      # régénération complète
/ba-develop <APP>/<MODULE> --allow-dirty

Vue d'ensemble du pipelinePipeline at a glance

Chaque phase tourne dans son propre subagent avec UNE slice du PRD. Entre les phases, des gates auto-réparants : sur un échec, le pipeline tente de corriger lui-même (max 25 tentatives par item) ; un échec non réparable est différé en blocker et le run continue jusqu'au bout. Les audits symétriques (audit-dev-api côté backend, audit-dev-frontend côté frontend) verrouillent l'alignement entre le pagespec (source de vérité métier) et le code généré. Each phase runs in its own subagent with ONE PRD slice. Between phases, self-healing gates: on failure the pipeline tries to fix things itself (max 25 retries per item); an unhealable failure is deferred as a blocker and the run continues to the end. The symmetric audits (audit-dev-api on the backend, audit-dev-frontend on the frontend) lock the alignment between the pagespec (business source of truth) and the generated code.

Détail des 6 phasesThe 6 phases in detail

Chaque phase est un subagent isolé qui reçoit UNE slice du PRD. Un gate vérifie compilation + tests + audit dédié ; sur échec, il s'auto-répare (max 25 tentatives par item) puis diffère en blocker. Each phase runs as an isolated subagent that receives ONE PRD slice. A gate verifies compile + tests + dedicated audit; on failure it self-heals (max 25 retries per item) then defers as a blocker.

À la sortie de la phase 4, le module est livré : compilation + tests OK, smoke-test vert, et le rapport final liste healingSummary[] (ce qui a été auto-réparé) et blockers[] (ce qui requiert votre décision). At the end of phase 4, the module is delivered: compile + tests OK, smoke-test green, and the final report lists healingSummary[] (what was self-healed) and blockers[] (what needs your decision).

GarantiesGuarantees

• Le code appartient aux scaffolders : backend ET frontend sont générés par les CLIs déterministes (marqueur @generated-by) — jamais écrits à la main. La personnalisation passe par le seam @customised.Scaffolders own the code: backend AND frontend are generated by the deterministic CLIs (@generated-by marker) — never hand-written. Customisation goes through the @customised seam.
• 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.
• Never-halt : gates auto-réparants (max 25 tentatives/item), échec non réparable = blocker différé, aucune question en cours de run.Never-halt: self-healing gates (max 25 retries/item), unhealable failure = deferred blocker, no mid-run questions.

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.

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 6 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 6 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.

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.

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.

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

Dans quel cas ?Which situation, which command?

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):

Skills orchestrées par /ba-develop

Skills orchestrated by /ba-develop