chore(claude): add stacked PR pattern for inter-ticket dependencies

Les tickets peuvent désormais déclarer leurs dépendances dans une
section `Depends on:` de leur body. `/epic` parse cette section et
calcule la branche de base à passer à code-dev :

- Aucune dépendance → origin/alpha
- Toutes dépendances mergées → origin/alpha (refresh)
- 1 dépendance en In review → ticket/<parent-slug> (stacked PR)
- 2+ dépendances en In review → partial blocking v1

code-dev crée sa branche depuis la base reçue et ouvre la PR avec
--base correspondant. GitHub retargette automatiquement vers alpha
quand la PR parent est mergée. L'exécution n'attend jamais une
validation humaine.

Parent issue GitHub reste utilisé uniquement pour la relation
epic → ticket. Les dépendances inter-tickets passent par la section
Depends on pour être parseable et éviter l'ambiguïté.

Author: Viczei

.claude/agents/architect/AGENT.md

@@ -28,20 +28,25 @@ N sub-issues of the epic, each **strictly** following `rules/ticket-spec-format.
 
 1. **Lire** epic + scénarios + mockups + fichiers source pertinents
 2. **Cartographier** — modules, patterns existants, fichiers à toucher
-3. **Draft ticket list** inline, montré à l'utilisateur :
-   - Titre, résumé 1 ligne, fichiers impactés, dépendances
-4. **Validation utilisateur** — « valide-tu ce découpage ? »
-5. **Sur approbation** — créer chaque ticket :
-   - Parent issue = epic
-   - Sub-issues ordonnées par dépendance
+3. **Découper + établir le DAG de dépendances** :
+   - Chaque ticket = unité cohérente (≤ 8 critères d'acceptation)
+   - Pour chaque paire de tickets, identifier si A doit être livré avant B (ex : schéma DB → routes tRPC → composants UI)
+   - Ces dépendances iront dans la section `Depends on` du body de chaque ticket
+4. **Draft ticket list** inline, montré à l'utilisateur :
+   - Titre, résumé 1 ligne, fichiers impactés, **dépendances explicites** (`T2 dépend de T1`)
+5. **Validation utilisateur** — « valide-tu ce découpage ? »
+6. **Sur approbation** — créer chaque ticket :
+   - Parent issue = **epic** (uniquement pour relier au parent, PAS pour les dépendances)
+   - **Section `Depends on`** dans le body listant les tickets dont il dépend (format `- #<N>`)
    - Labels appliqués
-6. **Commentaire final sur l'epic** — `[Validation utilisateur] Architecture validée — N tickets créés, prêt pour /epic`
+7. **Commentaire final sur l'epic** — `[Validation utilisateur] Architecture validée — N tickets créés, prêt pour /epic`
 
 ## Contraintes
 
 - **Respecter `rules/ticket-spec-format.md`** — toutes les sections requises, chemins de fichiers explicites, pas de « voir le code »
-- **Max 8 critères d'acceptation par ticket** — découper sinon
-- **Dépendances via Parent issue / Sub-issues GitHub** — `/epic` respecte cet ordre
+- **Max 8 critères d'acceptation par ticket** — découper sinon, et lier via `Depends on`
+- **Dépendances inter-tickets via section `Depends on`** dans le body (jamais via `Parent issue` qui sert uniquement à lier l'epic) — `/epic` parse cette section pour orchestrer le stacked-PR pattern
+- **Pas de cycles** dans le DAG de dépendances — sinon `/epic` refuse de dispatcher
 - **Aucune décision résiduelle** pour `code-dev` — Sonnet exécute, ne conçoit pas
 
 ## Output Format

.claude/agents/code-dev/AGENT.md

@@ -12,6 +12,9 @@ You execute one pre-specified ticket end-to-end : edit code, write/update tests,
 - Ticket issue number
 - Worktree path (assigned by `/epic`, e.g. `../egapro-epic42-t1`)
 - Dev server port (assigned by `/epic`, e.g. 3001)
+- **Base branch** (assigned by `/epic` ou `/code`) :
+  - `origin/alpha` si aucune dépendance ou toutes mergées
+  - `ticket/<parent-slug>` si le ticket dépend d'un autre encore en `In review` (stacked PR)
 
 ## Workflow
 
@@ -21,7 +24,10 @@ You execute one pre-specified ticket end-to-end : edit code, write/update tests,
 
 3. **Status ticket** → **In progress** (op. 3+4 de `rules/github-board.md`, option ID `47fc9ee4`).
 
-4. **Branche** dans le worktree : `git checkout -b <ticket-slug>`.
+4. **Branche** dans le worktree, à partir de la **base branch** reçue en input :
+   - `git fetch origin <base-branch>` pour rafraîchir
+   - `git checkout -b ticket/<N>-<slug> <base-branch>`
+   - Si `<base-branch>` ≠ `origin/alpha`, on est en mode **stacked PR** — la PR sera ouverte avec `--base <base-branch>`, GitHub retargettera vers `alpha` quand la PR parent sera mergée
 
 5. **Implémenter** :
    - Modifier les fichiers listés dans le ticket
@@ -42,10 +48,11 @@ You execute one pre-specified ticket end-to-end : edit code, write/update tests,
    - Démarrer dev server sur le port assigné
    - Playwright → screenshots desktop (1280×800) + mobile (375×667)
 
-8. **PR draft** via `gh pr create --draft` :
-   - Base = branche epic (ou master)
+8. **PR draft** via `gh pr create --draft --base <base-branch>` :
+   - Base = la `<base-branch>` reçue en input (`origin/alpha` ou `ticket/<parent-slug>`)
    - Body : lien ticket (`Closes #NNN`), résumé, test plan, screenshots
    - **Ticket reste en In progress** pendant les validators
+   - Si stacked : noter dans le body « Stacked on #<parent-PR> — GitHub retargettera automatiquement sur `alpha` une fois le parent mergé »
 
 9. **Validations en parallèle** — 3 axes simultanés, tous doivent être verts avant de passer à l'étape 10.
 

.claude/rules/ticket-spec-format.md

@@ -66,12 +66,22 @@ Si pas d'UI, écrire "N/A".>
 - [ ] Lint vert (`pnpm lint:check`)
 - [ ] Scénario(s) rejoué(s) sans erreur par `functional-validator`
 - [ ] (si UI) Comparaison visuelle PASS par `design-validator`
+
+## Depends on
+
+<Liste des tickets dont celui-ci dépend (le code/schéma de ces tickets doit exister avant que celui-ci puisse être implémenté). Un ticket par ligne avec le numéro GitHub :
+
+- #<N1>
+- #<N2>
+
+Si aucune dépendance, écrire "N/A" ou omettre la section entièrement.>
 ```
 
 ## Règles de rédaction
 
-- **Un ticket = une unité cohérente** : si les critères d'acceptation dépassent 8 éléments, découper en deux tickets avec dépendance parent-enfant GitHub.
+- **Un ticket = une unité cohérente** : si les critères d'acceptation dépassent 8 éléments, découper en deux tickets et exprimer la dépendance via la section `Depends on`.
 - **Pas de décision architecturale** dans le ticket : l'architect a déjà tranché. Le dev exécute.
 - **Pas de "voir le code pour comprendre"** : les fichiers à lire doivent être listés explicitement.
 - **Le label `complexe`** est ajouté uniquement si la tâche demande un raisonnement multi-étapes non trivial (refacto multi-fichiers, perf critique, algo complexe). Par défaut, Sonnet suffit.
-- **Dépendances** : utiliser le champ `Parent issue` / sub-issues GitHub. `/epic` respecte l'ordre : les tickets sans dépendance partent en premier, les suivants dès que leurs parents sont **Done**.
+- **Dépendances inter-tickets** : listées dans la section `Depends on` du body. `/epic` parse cette section et applique la stratégie **stacked PRs** : si un ticket `T2` dépend de `T1` encore `In review` (PR non mergée), `T2` est créé avec `--base` sur la branche de `T1`. Ainsi l'exécution n'attend jamais une validation humaine.
+- **Parent issue GitHub** : utilisé uniquement pour pointer vers l'epic (relation epic → ticket). **Pas** pour exprimer des dépendances inter-tickets — utiliser `Depends on` à la place.

.claude/skills/code/SKILL.md

@@ -25,12 +25,20 @@ Exécute **un seul ticket** end-to-end via l'agent `code-dev`. Utilisé seul (de
 
 ---
 
-# Step 1 — Worktree + port
+# Step 1 — Worktree + port + base branch
 
-Si déjà dans un worktree assigné par `/epic` → le réutiliser (variable d'env ou chemin courant).
+Si déjà dans un worktree assigné par `/epic` → le réutiliser (variable d'env ou chemin courant), `/epic` a déjà calculé la base branch.
 
-Sinon (standalone) :
-- Créer `../egapro-ticket<N>` depuis `origin/alpha` : `git worktree add ../egapro-ticket<N> -b ticket/<N>-<slug> origin/alpha`
+Sinon (standalone), déterminer la base branch selon la section `Depends on` du body :
+- Aucune dépendance → `origin/alpha`
+- Toutes les dépendances en `Done` → `origin/alpha` (après `git fetch`)
+- 1 dépendance en `In review` → `ticket/<parent-slug>` (stacked PR)
+- 2+ dépendances en `In review` → **exit** avec message : « attendre le merge d'au moins une dépendance avant `/code` »
+- 1+ dépendance en `In progress` ou `To Do` → **exit** avec message : « dépendance pas prête, attendre `/epic` »
+
+Création :
+- `git fetch origin <base-branch>`
+- `git worktree add ../egapro-ticket<N> -b ticket/<N>-<slug> <base-branch>`
 - Assigner le prochain port libre (check via `lsof -i :3001`, incrémenter)
 
 ---
@@ -41,6 +49,7 @@ Invoquer l'agent `code-dev` (`.claude/agents/code-dev/AGENT.md`) avec :
 - Ticket number
 - Worktree path
 - Dev server port
+- Base branch (cf. Step 1)
 
 Model :
 - **opus** si ticket a label `complexe`

.claude/skills/epic/SKILL.md

@@ -19,23 +19,35 @@ Dispatche les sous-issues d'un epic sur plusieurs worktrees en parallèle, invoq
 
 - Vérifier que l'issue existe et a le label `Epic`
 - Fetcher ses sous-issues avec leur statut board — utiliser le snippet op. 5 de `rules/github-board.md`
-- Filtrer : ne conserver que les tickets dont le champ `Status` = **To Do** (ignorer Backlog / In progress / In review / Done)
-- Valider le graphe de dépendances (parents avant enfants, pas de cycles)
+- **Parser la section `Depends on`** du body de chaque sub-issue pour construire le DAG de dépendances inter-tickets (regex : extraire les `#<N>` listés dans la section).
+- Valider le DAG : pas de cycles. Si cycle détecté → exit avec diagnostic.
+- Filtrer les tickets dispatchables = en **To Do** (ignorer Backlog / In progress / In review / Done).
 
-Si rien en To Do → exit avec `Nothing to dispatch on epic #<N>`.
+Si aucun ticket dispatchable → exit avec `Nothing to dispatch on epic #<N>`.
 
 ---
 
-# Step 1 — Worktree + port assignment
+# Step 1 — Worktree + port + base branch
+
+Pour chaque ticket à dispatcher, déterminer :
 
-Pour chaque ticket à dispatcher, assigner :
 - **Worktree** : `../egapro-epic<N>-t<ticket-id>`
 - **Dev server port** : `3000 + <index>` (3001, 3002, 3003, …)
+- **Base branch** selon l'état de ses dépendances (stacked PR pattern) :
+
+  | État des dépendances | Base branch |
+  |---|---|
+  | Aucune dépendance | `origin/alpha` |
+  | Toutes `Done` (PR mergées) | `origin/alpha` (après `git fetch`) |
+  | Exactement 1 en `In review` (PR non mergée) | `ticket/<parent-slug>` (branche de cette dépendance) |
+  | 2+ en `In review` | **ne pas dispatcher** — attendre qu'au moins une soit mergée (partial blocking v1) |
+  | 1+ en `In progress` ou `To Do` | **ne pas dispatcher** — attendre que la dépendance arrive en `In review` au minimum |
 
-Création :
+Création du worktree à partir de la base branch choisie :
 
 ```bash
-git worktree add ../egapro-epic42-t123 -b ticket/123-<slug> origin/alpha
+git fetch origin <base-branch>
+git worktree add ../egapro-epic42-t123 -b ticket/123-<slug> <base-branch>
 ```
 
 Si un worktree avec ce path existe déjà (re-run d'`/epic`), le réutiliser plutôt que d'en créer un nouveau.
@@ -44,39 +56,46 @@ Si un worktree avec ce path existe déjà (re-run d'`/epic`), le réutiliser plu
 
 # Step 2 — Dispatch loop
 
-Tant qu'il reste des tickets en **To Do** dont toutes les dépendances (Parent issue / Sub-issues GitHub) sont en **In review** ou **Done** :
+Tant qu'il reste des tickets en **To Do** dispatchables (toutes dépendances résolues selon le tableau de Step 1) :
 
 1. **Sélectionner les N prochains tickets dispatchables** — parallélisme par défaut **N = 3**. Ajuster selon la RAM de la machine (~1–2 GB par dev server).
 
 2. **Invoquer `code-dev` en parallèle** (un Agent tool call par ticket, dans un seul message) :
    - Model : **opus** si label `complexe`, sinon **sonnet**
-   - Arguments : ticket number, worktree path, dev server port
+   - Arguments : ticket number, worktree path, dev server port, **base branch** (cf. tableau Step 1)
    - `run_in_background: true` pour que `/epic` continue à orchestrer pendant l'exécution
 
 3. **Attendre la complétion** de tous les `code-dev` lancés. Chaque retour est PASS ou REFACTO.
 
 4. **Traiter les verdicts** :
-   - **PASS** → ticket en **In review**, PR prête (`gh pr ready`). Worktree conservé pour revue utilisateur.
-   - **REFACTO** → ticket retourné en **To Do** avec diagnostic. Signaler à l'utilisateur qu'une intervention `architect` est probablement nécessaire.
+   - **PASS** → ticket en **In review**, PR prête (`gh pr ready`). Worktree conservé pour revue utilisateur. Les tickets qui dépendaient de celui-ci deviennent **dispatchables** en stacked (leur base branch = la branche de ce ticket).
+   - **REFACTO** → ticket retourné en **To Do** avec diagnostic. Signaler à l'utilisateur qu'une intervention `architect` est probablement nécessaire. **Tous les tickets qui en dépendent restent bloqués** jusqu'à résolution.
 
 5. **Reboucler** sur Step 2 tant qu'il reste des tickets dispatchables.
 
+**Fin de boucle** — il peut rester des tickets en To Do dont les dépendances ne sont ni `In review` ni `Done` (ex : dépendances multiples toutes encore en flight). Dans ce cas, sortir proprement du loop et signaler à l'utilisateur que certains tickets attendent le merge humain d'une de leurs dépendances.
+
 ---
 
 # Step 3 — Report
 
 ```
 ## Epic #<N>: dispatch complete
 
-PASS (In review): #N1, #N3, #N4
+PASS (In review):
+  - #N1 (PR #101, base: origin/alpha)
+  - #N3 (PR #103, base: ticket/N1-slug ← stacked)
+  - #N4 (PR #104, base: ticket/N3-slug ← stacked)
 REFACTO (retour To Do): #N2 — <diagnostic>
+Bloqués (en attente merge humain) : #N5 (dépend de #N3 merged)
 Worktrees actifs: ../egapro-epic<N>-t*
 
 Next:
-1. Revoir les PR ouvertes
-2. Passer manuellement les tickets In review → Done
-3. Si REFACTO : re-lancer /ticket sur l'epic (phase architect) puis /epic
-4. `git worktree remove ../egapro-epic<N>-t*` après merge de toutes les PR
+1. Revoir et merger les PR dans l'ordre du stack (#101 → #103 → #104)
+2. Les PR dépendantes seront auto-retargettées par GitHub vers `alpha` après chaque merge
+3. Passer manuellement les tickets In review → Done
+4. Si REFACTO : re-lancer /ticket sur l'epic (phase architect) puis /epic
+5. `git worktree remove ../egapro-epic<N>-t*` après merge de toutes les PR
 ```
 
 ---
@@ -86,4 +105,6 @@ Next:
 - **Nettoyage worktrees** : conservés après `/epic` pour la revue humaine. L'utilisateur les supprime après merge.
 - **Never auto-Done** : `/epic` termine sur **In review** pour tous les tickets PASS. La transition **Done** est manuelle.
 - **Parallélisme** : max 3 par défaut. Chaque dev server consomme de la RAM et des ports. Ajuster `N` si machine modeste.
-- **Ordre de dispatch** : les tickets sans dépendance partent en premier. Les tickets dépendants attendent que leur parent soit **In review** (pas Done — sinon `/epic` bloquerait sur la validation humaine).
+- **Stacked PR pattern** : un ticket dépendant part immédiatement dès que son parent est **In review** (PR prête, pas encore mergée). Sa PR est ouverte avec `--base ticket/<parent-slug>`. GitHub retargette automatiquement vers `alpha` quand le parent est mergé. Évite le blocage sur la validation humaine.
+- **Ordre de merge humain** : critique. Merger les PR **dans l'ordre du stack** (parent avant enfant). Merger un enfant avant son parent casse l'historique. `/epic` le rappelle dans le report final.
+- **Multi-dépendances non mergées** (v1) : partial blocking — attendre qu'au moins une dépendance soit mergée avant de dispatcher le ticket. v2 future : merge commits croisés si besoin.