---
title: Pipeline de bootstrap
description: Ordre d'exécution — hooks de cycle de vie autour des copies de fichiers, guards regex, fallbacks, et vérifications no-symlink.
---
# Pipeline de bootstrap
Le pipeline de bootstrap s'exécute **après** que `git worktree add` a réussi, sur chaque `gwm create` (sauf si `--no-bootstrap` est positionné) et sur chaque `gwm bootstrap`. Il est aussi ré-exécutable depuis l'intérieur de la TUI via la touche `b`.
Chaque point d'entrée est **protégé par le [trust ledger TOFU](/fr/configuration/trust-ledger)** — la première fois que vous exécutez `gwm create` / `gwm bootstrap` contre le `.gwm.toml` d'un dépôt, la barrière demande confirmation (CLI) ou refuse avec un indice dans la barre de statut (TUI) avant qu'aucune étape du pipeline ne s'exécute. Les exécutions suivantes contre la même paire `(URL d'origin, sha256 de .gwm.toml)` passent silencieusement ; tout changement d'un octet dans `.gwm.toml` redéclenche la demande. Bypass CI : `--allow-bootstrap` ou `GWM_ALLOW_BOOTSTRAP=1`.
Les hooks de cycle de vie enveloppent le cœur du bootstrap :
```
gwm create / gwm bootstrap
↓
trust gate (issue #95) prompt / refuse on untrusted (origin, hash)
↓
pre_bootstrap hooks optional [[hooks.pre_bootstrap]]
↓
(1) [[bootstrap.copy]] duplicate files from main → worktree
↓
(2) [[bootstrap.guard]] regex deny-list each copied file
↓
(3) [bootstrap.fallback.*] materialise inline content when a
required source is missing
↓
(4) [[bootstrap.no_symlink]] refuse to inherit listed symlinks
↓
post_bootstrap hooks optional [[hooks.post_bootstrap]]
↓
✓ worktree ready, status bar reports per-step ✓ / ! / ✗
```
Les étapes **1 → 4** sont étroitement couplées — une action de guard `seed-from-example` déclenche un fallback (étape 3) en inline, et la vérification no-symlink (étape 4) s'exécute après les copies afin de pouvoir refuser des liens que l'étape de copie aurait suivis. Les entrées legacy `[[bootstrap.command]]` sont traitées comme des hooks `post_create` pour la compatibilité ; préférez `[[hooks.post_create]]` dans les nouvelles configs.
## rapports d'étape
Chaque étape affiche une ligne avec un sigle — même convention que `gwm doctor` :
| Sigle | Sévérité | Effet sur le worktree |
|:------|:----------|:-----------------------------------------------------|
| `✓` | succès | rien |
| `!` | warning | l'étape est ignorée ou partielle ; le pipeline continue |
| `✗` | échec | le pipeline s'interrompt ; le nouveau worktree est rollback |
Exemple de sortie (depuis `gwm create feat 42 user-auth` avec une config typique) :
```
creating worktree:
branch : feat/#42-user-auth
dir : feat-42-user-auth
path : /Users/you/cc-worktree/myrepo/feat-42-user-auth
✓ worktree created at /Users/you/cc-worktree/myrepo/feat-42-user-auth
bootstrap report:
✓ copy .env.testing
! no-symlink vendor
target not present
✓ guard no-aws-rds on .env
✓ run composer install
· run direnv allow
when condition 'file_exists:.envrc' false
```
Le sigle `·` (utilisé par certains skips de prédicat) est un indicateur « l'étape ne s'est pas exécutée » et est purement informatif — aucune sévérité attachée.
## ignorer le bootstrap
```bash
gwm create feat 42 user-auth --no-bootstrap # skip the whole pipeline
gwm bootstrap auth --skip-hooks pre_bootstrap # skip one lifecycle hook phase
```
Utile quand :
- Vous scriptez une création en masse et voulez le bootstrap comme étape séparée.
- Le `.gwm.toml` du dépôt est en transition et le bootstrap échouerait de manière prévisible.
- Vous voulez inspecter le worktree nu avant que tout effet de bord ne se produise.
Ré-exécuter le bootstrap plus tard sans recréer :
```bash
gwm bootstrap # on the CWD worktree
gwm bootstrap auth # ...on a fuzzy-matched name
```
## pourquoi cet ordre
L'ordre n'est **pas arbitraire**. Il encode les leçons de sécurité d'origine qui ont motivé gwm :
1. **Copies d'abord** — donne aux guards quelque chose à inspecter.
2. **Guards immédiatement après** — échouer vite sur un `.env` contenant des endpoints AWS RDS **avant** que les shell hooks du worktree ne tirent de vraies données de production.
3. **Fallbacks** — quand un guard déclenche `seed-from-example`, la substitution se produit avant que la vérification no-symlink ne regarde le résultat.
4. **No-symlink** — s'exécute en dernier parmi les étapes au niveau fichier, afin d'attraper tout lien créé par un `cp -R` qui aurait suivi des indirections.
5. **Commandes shell** — la seule étape qui peut avoir des effets de bord arbitraires sur des systèmes externes (composer install, npm ci, etc.). Placée en dernier afin que les invariants au niveau fichier tiennent au moment où elle s'exécute.
## en lien
- [Configuration → schéma `.gwm.toml`](/fr/configuration/gwm-toml) — la surface TOML de chaque section de bootstrap
- [Guards regex](/fr/configuration/guards) — comment l'étape 2 fonctionne en détail
- [prédicats when:](/fr/configuration/when-predicates) — comment l'étape 5 conditionne les commandes
- [Intégrations → `gwm doctor`](/fr/integrations/doctor) — valide que la config de bootstrap est cohérente en interne (références de guards, grammaire des prédicats)