---
description: Validate readiness before construction — auto-checks and qualitative questions
user-invocable: false
---
# /godot-gate — Validation pré-construction

> **Synonymes** : gate, valider, vérifier, prêt à construire, ready to build, check, passer en dev, go/no-go

Tu es un quality gate. Ton rôle : **vérifier que le projet est prêt à passer en phase BUILD**. Tu ne crées rien — tu vérifies. Tu bloques si les conditions ne sont pas remplies.

---

## Sommaire

1. Quand gate
2. Auto-checks
3. Questions qualitatives
4. Post-gate

---

## 1. Quand gate

- **Après** `/godot-sequence` + au moins 1 `/godot-simulate`
- Le gate ne crée rien — il vérifie
- Un gate PASS ne garantit pas que le jeu sera bon, mais qu'on a fait le **minimum de préparation**

### Gate = moment de décision

Le gate est le dernier moment où c'est gratuit de changer. Après le gate, on construit — et chaque changement de direction coûte du code à réécrire.

---

## 2. Auto-checks

Lire les fichiers du projet et vérifier automatiquement :

### Prérequis (bloquants)

```
Gate : PLAN → BUILD

Prérequis (auto-vérifiés) :
  ✓/✗ GAME_PLAN.md existe et non vide
  ✓/✗ GAME_SEQUENCE.yaml existe et parseable
  ✓/✗ Au moins 1 simulation narrative complétée (vérifier CHECKPOINT.md ou demander)
  ✓/✗ Tous les states ont au moins 1 transition sortante
  ✓/✗ Pas de states orphelins (non atteignables depuis entry)
  ✓/✗ Core loop identifié (≥1 loop avec ≥3 states)
  ✓/✗ Emotional arc défini pour la core loop
  ✓/✗ Au moins 3 edge cases documentés
```

### Recommandé (non bloquants)

```
Recommandé (non bloquant) :
  ○/● Simulation balance complétée
  ○/● Simulation exhaustive complétée
  ○/● data/*.yaml créés pour les valeurs numériques
  ○/● Tous les edge cases severity:critical ont un "expected" défini
```

### Comment vérifier chaque check

| Check | Méthode |
|-------|---------|
| GAME_PLAN.md existe | Lire le fichier, vérifier qu'il n'est pas vide |
| GAME_SEQUENCE.yaml valide | Parser le YAML, vérifier les clés `meta`, `loops`, `states` |
| Simulation faite | Chercher dans CHECKPOINT.md ou demander au user |
| Transitions complètes | Pour chaque state dans `states:`, vérifier que `transitions:` existe et est non vide |
| Pas d'orphelins | Construire le graphe, DFS depuis chaque `entry`, lister les states non visités |
| Core loop ≥3 states | Dans `loops:`, au moins 1 loop avec ≥3 items dans `states:` |
| Emotional arc | `emotional_arc:` contient une entrée pour la core loop |
| Edge cases ≥3 | `edge_cases:` contient ≥3 items |

### Si un check échoue

Pointer vers le skill correctif :

| Check échoué | Action |
|-------------|--------|
| Pas de GAME_PLAN.md | → `/godot-plan` |
| Pas de GAME_SEQUENCE.yaml | → `/godot-sequence` |
| Pas de simulation | → `/godot-simulate` |
| Transitions manquantes | → `/godot-sequence` (éditer le YAML) |
| Orphelins | → `/godot-sequence` (ajouter les transitions manquantes) |
| Core loop trop courte | → `/godot-sequence` (décomposer la boucle) |
| Pas d'arc émotionnel | → `/godot-sequence` (ajouter la section emotional_arc) |
| Pas assez d'edge cases | → `/godot-sequence` (ajouter des edge cases) |

---

## 3. Questions qualitatives

Posées au user après les auto-checks. Adaptées du "Test UX" de Maelodynn.

### Les 4 questions

**1. DÉSIRABLE** — Le joueur a-t-il envie de jouer à ÇA ?

> Si tu n'es pas excité par ta propre séquence, le joueur ne le sera pas.

**2. LISIBLE** — En lisant la séquence, tu vois le jeu dans ta tête ?

> Si la séquence est confuse sur papier, elle sera pire en code.

**3. MÉMORABLE** — Quel moment le joueur racontera à un pote ?

> S'il n'y en a pas, ajouter un moment "wow" à la séquence.

**4. VIABLE** — Est-ce réaliste à construire avec ton budget temps ?

> Comparer le nombre de states/mécaniques au temps disponible.

### Interpréter les réponses

| Réponse | Signification | Action |
|---------|--------------|--------|
| "Non" à DÉSIRABLE | Red flag majeur | Revenir à `/godot-plan` — le concept ne tient pas |
| "Non" à LISIBLE | La séquence est trop complexe ou mal structurée | Simplifier via `/godot-sequence` |
| "Non" à MÉMORABLE | Il manque un moment fort | Ajouter un peak dans l'emotional arc |
| "Non" à VIABLE | Scope trop large | Couper des states, réduire le scope |

---

## 4. Post-gate

### Output format

```
## Gate Result : PLAN → BUILD

### Auto-checks : {X}/8 passed
  ✓ GAME_PLAN.md existe (42 lignes)
  ✓ GAME_SEQUENCE.yaml valide (12 states, 3 loops)
  ✓ Simulation narrative : First Timer complétée
  ✓ Transitions : tous les states ont ≥1 sortie
  ✓ Pas d'orphelins
  ✓ Core loop : 5 states (explore → encounter → resolve → reward → advance)
  ✓ Emotional arc : core loop défini
  ✓ Edge cases : 5 documentés (2 critical, 2 warning, 1 info)

### Recommandé : {X}/4 done
  ● Simulation balance : complétée
  ● Simulation exhaustive : complétée
  ● data/*.yaml : 3 fichiers (enemies, player, levels)
  ○ Edge cases critical — expected manquant pour EC-03

### Qualitative : {PASS | DISCUSS}
  DÉSIRABLE : "Oui, le loop est addictif" ✓
  LISIBLE : "Oui" ✓
  MÉMORABLE : "Le premier boss fight" ✓
  VIABLE : "Oui, 2 semaines max" ✓

### Verdict : {PASS ✓ | BLOCKED ✗ | CONDITIONAL ⚠}
```

### Verdicts

| Verdict | Condition | Message |
|---------|-----------|---------|
| **PASS** | 8/8 auto-checks + qualitative OK | "Prêt à builder. Next: `/godot-architecture`" |
| **BLOCKED** | ≥1 auto-check échoue | "Corriger avant de re-gate : {items}" |
| **CONDITIONAL** | Auto-checks OK mais recommandés manquants | "PASS avec notes : {items manquants}. On continue vers `/godot-architecture`. Les items recommandés pourront être ajoutés pendant la construction." |

### Après le gate

- **PASS** → Proposer `/godot-architecture` (le flow standard continue)
- **BLOCKED** → Pointer vers les skills correctifs
- **CONDITIONAL** → Traiter comme PASS. Proposer `/godot-architecture`. Noter les items manquants dans CHECKPOINT.md pour review ultérieur

### Enregistrer le résultat

Ajouter dans `CHECKPOINT.md` :

```markdown
## Gate : PLAN → BUILD
- Date: {date}
- Verdict: {PASS | BLOCKED | CONDITIONAL}
- Auto-checks: {X}/8
- Recommandé: {X}/4
- Notes: {résumé des findings}
```

---

## Checklist

- [ ] Tous les auto-checks ont été exécutés
- [ ] Les questions qualitatives ont été posées (ou skippées explicitement)
- [ ] Le verdict est clair (PASS, BLOCKED, ou CONDITIONAL)
- [ ] Les items bloquants pointent vers le bon skill correctif
- [ ] Le résultat est enregistré dans CHECKPOINT.md

---

## Pièges courants

| Piège | Solution |
|-------|---------|
| Forcer le PASS sans simulation | Le gate BLOQUE sans au moins 1 simulation narrative. Pas de négociation |
| Ignorer DÉSIRABLE = "non" | C'est le red flag le plus important. Revenir au plan, pas patcher la séquence |
| Gate comme formalité | Si on valide tout sans réfléchir, autant ne pas gate. Prendre le temps de lire le YAML |
| Scope creep post-gate | Le gate valide un scope. Si le user ajoute des features après, re-gate |

---

## See also

| Skill | Quand l'utiliser |
|-------|-----------------|
| `/godot-sequence` | Créer ou corriger la séquence |
| `/godot-simulate` | Simuler avant le gate |
| `/godot-plan` | Revenir à la vision si DÉSIRABLE = non |
| `/godot-architecture` | Prochaine étape après PASS |
