first commit

2026-07-21 16:50:58 +02:00
commit 256599626e
407 changed files with 30489 additions and 0 deletions
@@ -0,0 +1,14 @@
+# Tickets de travaux (post-MVP)
+
+Les corps d’issues prêts à l’emploi sont dans ce dossier (`issue-*.body.md`).
+
+## Créer les issues sur GitHub
+
+1. S’authentifier : `gh auth login`
+2. Depuis la racine du dépôt : `./scripts/github/create-post-mvp-issues.sh`
+
+Le script utilise `gh issue create` et les fichiers `docs/tickets/issue-*.body.md`.
+
+Sans CLI : **New issue** sur GitHub et choisir un des gabarits sous « Refactor Builder SOLID », « Architecture sans barrels index », « SEO recettes OG » — ou copier-coller le contenu des fichiers `.body.md`.
+
+Issues créées sur le dépôt de référence : [#19](https://github.com/kazerlelutin/ben-to/issues/19), [#20](https://github.com/kazerlelutin/ben-to/issues/20), [#21](https://github.com/kazerlelutin/ben-to/issues/21).
@@ -0,0 +1,25 @@
+## 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`
@@ -0,0 +1,28 @@
+## Contexte
+
+Les packages exposent des barrels `src/index.ts` avec `export * from "..."`. Les alias Vite dans `apps/web/vite.config.ts` pointent vers ces fichiers. Ce pattern complique le suivi des imports réels et la détection de code inutilisé.
+
+## Objectif
+
+Supprimer les barrels `index.ts`, migrer vers des imports **explicites**, et **verrouiller** la réintroduction du pattern (règles projet + CI).
+
+## Travail technique
+
+1. Remplacer les alias Vite (et chemins TypeScript si besoin) par des modules canoniques nommés (ex. `@ben-to/builder/domain`, `@ben-to/recipes/catalog`) ou par des sous-chemins `package.json` **`exports`** sans fichier nommé `index.ts`.
+2. Mettre à jour tous les imports (`apps/web`, `packages/**`).
+3. Supprimer les anciens `**/src/index.ts` après migration.
+
+## Règles / outillage
+
+- Étendre `.cursor/rules/ben-to-engineering.mdc` : pas de nouveau barrel `index.ts` ; imports depuis modules nommés.
+- Optionnel : ESLint `no-restricted-imports` ou script `scripts/quality/` qui échoue si un `**/src/index.ts` barrel réapparaît.
+
+## Critères d’acceptation
+
+- [ ] Plus de `export * from` dans des `index.ts` à la racine des packages features/shared concernés.
+- [ ] CI (`check:quality` ou lint) empêche la réintroduction du pattern (selon le niveau de durcissement retenu).
+
+## Références
+
+- `apps/web/vite.config.ts`
+- `packages/features/*/src/index.ts`, `packages/shared/*/src/index.ts`
@@ -0,0 +1,30 @@
+## Contexte
+
+Les métadonnées Open Graph et Twitter sont définies une seule fois dans `apps/web/index.html`. Les URLs de recette `/r/...` doivent exposer **titre**, **description** et **image** adaptés au partage.
+
+**Contrainte SPA** : modifier `<title>` ou les meta **uniquement en JavaScript après chargement** ne suffit souvent pas pour les robots d’aperçu (Facebook, X, LinkedIn) : ils lisent le HTML initial.
+
+## Objectif
+
+Pour chaque recette partageable, fournir des métadonnées correctes : `og:title`, `og:description`, `og:image`, `og:url`, `twitter:card` (idéalement `summary_large_image` si visuel adapté), éventuellement `canonical`.
+
+## Options à trancher (documenter le choix dans README ou `docs/`)
+
+| Approche | Effort | Aperçus réseaux |
+|----------|--------|-----------------|
+| Pré-rendu statique des routes `/r/*` au build (catalogue / pipeline recettes) | Moyen | Bon pour crawlers statiques |
+| Middleware / route serveur (Worker, reverse proxy, petite app Node) injectant le HTML minimal avec meta | Variable | Très bon si bien déployé |
+| Meta uniquement côté client (Solid) | Faible | Insuffisant pour la majorité des partages |
+
+Données : titres localisés, description courte, images de couverture produites par le pipeline recettes.
+
+## Critères d’acceptation
+
+- [ ] Partager une URL `/r/...` affiche un aperçu avec **titre et image recette** (validation manuelle : Meta Sharing Debugger / Twitter Card Validator ou équivalent).
+- [ ] Balises OG/Twitter cohérentes (`og:type`, `og:url`, etc.).
+- [ ] Documentation de la stratégie retenue (build vs serveur).
+
+## Références
+
+- `apps/web/index.html`
+- Parcours e2e et URL partagée dans `tests/e2e/builder.e2e.ts`