ben-to/docs/tickets/issue-builder-solid.body.md

Contexte

La logique et l’UI du parcours builder sont concentrées dans apps/web/src/ui/BuilderFlow.tsx (fichier très volumineux). Le domaine pur existe déjà dans packages/features/builder/src/domain.ts.

Objectif

Réduire la surface « tout-en-un » du flux builder et clarifier les frontières entre UI, état du wizard, et domaine (@ben-to/builder).

Pistes techniques

• Extraire par responsabilité unique : étapes (base / variante / recette), barre d’actions, feuille recette, navigation « Continuer », synchronisation reset (builder-reset-bus).
• Introduire des hooks / ports testables (ex. useBuilderSteps, useRecipeSheet) pour isoler les effets et la lecture du catalogue.
• DIP : l’UI consomme le domaine (domain.ts) et des interfaces stables pour le catalogue, sans détails de parsing dispersés.
• Conserver / étendre les tests (*.unit.test.ts, e2e, Gherkin @int-builder-*).

Critères d’acceptation

• Aucun fichier du flux builder > ~250–300 lignes sans justification documentée en commentaire de module.
• Tests unitaires / intégration et e2e verts ; pas de régression sur le parcours dans specs/features/builder.feature.

Références

• apps/web/src/ui/BuilderFlow.tsx
• packages/features/builder/src/domain.ts
• specs/features/builder.feature