plan — plan d'implémentation à partir d'une spec

Input : une spec finalisée (.ai/specs/{date}-{slug}.md sans aucune open question non résolue) ou, pour les petits changements, une description explicite de l'utilisateur. Output : un plan à .ai/plans/{YYYY-MM-DD}-{slug}.md que /execute peut suivre mécaniquement.

Écrivez le plan pour l'exécuteur le plus faible plausible : un agent sans mémoire de cette session. Chaque tâche doit être exécutable à partir du texte du plan seul.

Annoncez au démarrage : « Using the plan skill — turning the spec into an implementation plan. »

Step 1: Check prerequisites

Lisez la spec. Si une Open Question n'est pas cochée → STOP et retournez à /spec-writing Step 7. Ne planifiez pas autour d'une open question.
Lisez .ai/lessons.md et le module AGENTS.md pour chaque module que la spec touche.
Lisez les guides correspondants pour le travail du plan (à partir du AGENTS.md Task Router racine). Au minimum :
- migrations → .ai/rules/workflow-database-migration.md
- services → .ai/rules/conventions-services.md
- forms/UI → .ai/rules/conventions-forms.md + packages/form/AGENTS.md
- database access → .ai/rules/database-patterns.md

Step 2: Decompose into tasks

Une tâche = une unité de travail vérifiable (une migration, une fonction service + son test, une route + formulaire, un composant UI). Si une tâche ne peut pas être vérifiée par une seule commande ou un seul contrôle navigateur, divisez-la.
Ordre par défaut : migration → pnpm run generate:types → modèles (zod) → fonctions service (+ tests unitaires) → routes/actions → UI → vérification navigateur.
Pour chaque tâche UI, nommez le précédent : l'écran ou le composant Carbon existant à copier depuis (chemin du fichier). Ne concevez pas l'UI à partir de concepts — faites d'abord un grep sur packages/react/src/ et apps/erp/app/components/.
Marquez les tâches indépendantes les unes des autres — /execute peut les exécuter comme sous-agents parallèles.

Step 3: Write each task

Chaque tâche utilise exactement cette forme :

## Task N: {titre impératif}

**Depends on:** {numéros de tâche, ou "none"}
**Files:**
- Create: `{chemin exact}`
- Modify: `{chemin exact}` — {ce qui change}
- Copy from (precedent): `{chemin exact de l'exemplaire}`

**Steps:**
1. {instruction exacte ; incluez le SQL complet pour les migrations, les signatures de fonction pour les services, et l'exemplaire à copier pour l'UI}
2. ...

**Verify:**
```bash
{commande exacte}
# Expected: {ce que la sortie doit contenir}
```

**Out of scope:** {choses qui paraissent connexes mais NE DOIVENT PAS être touchées}

Règles strictes pour le contenu des tâches :

Migrations : créez avec pnpm db:migrate:new <name> (ne choisissez jamais un timestamp à la main ; n'utilisez jamais 000000 comme HHMMSS). Le SQL doit utiliser id('prefix') defaults, companyId + composite PK ("id", "companyId"), colonnes audit (createdBy/createdAt/updatedBy/updatedAt), RLS policies selon .ai/rules/conventions-database.md, et être idempotent (IF NOT EXISTS / DROP ... IF EXISTS guards). Ne backdatez jamais un timestamp plus ancien que la plus nouvelle migration sur main. La tâche après toute migration est toujours pnpm run generate:types.
Verification is scoped. Typez une package avec pnpm exec turbo run typecheck --filter=<pkg> (e.g. --filter=erp, --filter=@carbon/react). Ne planifiez jamais un pnpm typecheck de tout le repo — ça fait OOM. Tests : pnpm --filter <pkg> test.
No placeholders. Pas de « TBD », pas de « similar to Task 3 », pas de « add appropriate logic ». Si vous ne pouvez pas le spécifier, la spec est incomplète — retournez en arrière.
Escape hatches. Quand une tâche repose sur une assumption, ajoutez : « If {assumption} turns out false, STOP and report — do not improvise. »

Red flags — si vous vous surprenez à écrire l'une de ces choses, la tâche est sous-spécifiée ; corrigez-la avant de continuer :

« similar to the previous task » / « as appropriate » / « etc. »
un bloc Verify sans expected output
une tâche UI sans chemin de fichier précédent
une tâche migration sans suivi generate:types

Step 4: Write the plan file

Sauvegardez à .ai/plans/{YYYY-MM-DD}-{slug}.md (date d'aujourd'hui, même slug que la spec) :

# {Feature} — implementation plan

**Spec:** .ai/specs/{date}-{slug}.md
**Research:** .ai/research/{slug}.md
**Branch:** {branch name}

## Progress
- [ ] Task 1: {title}
- [ ] Task 2: {title}

## Dependencies
{`Task 2 needs Task 1 (types)`, `Tasks 4–5 independent`}

---
{tasks}

La checklist Progress est le tracker en direct — /execute coche les éléments dans ce fichier. Ne créez pas un fichier todo séparé.

Step 5: Self-check, then present

[ ] Chaque tâche a des chemins exacts, des commandes exactes, une sortie attendue
[ ] Chaque tâche migration suit les règles strictes ci-dessus et est suivie d'une étape generate:types
[ ] Chaque tâche UI nomme son fichier précédent
[ ] Aucun typecheck de tout le repo nulle part dans le plan
[ ] Chaque critère d'acceptation de la spec est couvert par au moins une tâche, et la tâche finale est vérification navigateur via /test pour le travail orienté utilisateur

Présentez le chemin du plan et un résumé d'un paragraphe. Attendez l'approbation, puis passez à /execute.