---
name: forge-validator
description: "Validation complète du BLUEPRINT.md (8 checks déterministes + 23 checks sémantiques)"
context: fork
disable-model-invocation: true
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
---

# forge-validator — Validation Blueprint

Tu valides un BLUEPRINT.md en deux couches. Tu ne modifies jamais aucun fichier — lecture seule.

---

## ÉTAPE 1 — Checks déterministes (8 checks)

Exécute le script bundlé :

```bash
bash "${CLAUDE_SKILL_DIR}/validate.sh" BLUEPRINT.md
```

Le script retourne un JSON `{ valid, errors, warnings, parsed }`.

**Si `valid: false`** : rapporte les erreurs et stoppe. Ne passe pas à l'étape 2.
Les checks déterministes couvrent : sections obligatoires, format IDs, schéma JSON,
dépendances, cycles, critères d'acceptation, titres de sections.

**Si `valid: true`** : note les warnings éventuels et passe à l'étape 2.

---

## ÉTAPE 2 — Checks sémantiques LLM (23 checks)

Lis le BLUEPRINT.md en entier et vérifie chaque point. Pour chaque check, donne un
verdict : PASS, FAIL ou WARNING.

### Sections obligatoires — complétude (checks 1-8)

| # | Check | Quoi vérifier |
|---|-------|---------------|
| 1 | §1 Description substantielle | La description décrit le "pourquoi" du projet, pas juste le "quoi". ≥ 2 phrases. |
| 2 | §1 Utilisateurs identifiables | Les utilisateurs cibles sont des personnes/rôles concrets, pas "tout le monde". |
| 3 | §1 Critères de succès mesurables | Chaque critère est vérifiable objectivement (pas "le site est rapide" mais "LCP < 2.5s"). |
| 4 | §1 Contraintes réalistes | Les contraintes ne se contredisent pas entre elles ni avec la stack §3. |
| 5 | §1 Hors scope suffisant | Au moins 3 items hors scope. Vérifier qu'aucune feature §2 ne contredit le hors scope. |
| 6 | §2 Priorités cohérentes | Les features Critique sont réellement critiques (bloquantes pour le MVP). |
| 7 | §2 Critères d'acceptation testables | Chaque critère est formulé comme un scénario testable (Given/When/Then ou équivalent). |
| 8 | §2 Granularité features | Aucune feature ne devrait prendre plus de 5 jours de travail estimé. Si trop grosse, recommander de découper. |

### Architecture — cohérence (checks 9-14)

| # | Check | Quoi vérifier |
|---|-------|---------------|
| 9 | §3 Stack vs features | La stack technique est capable de supporter toutes les features Critique. |
| 10 | §3 Pattern vs complexité | Le pattern architectural est adapté à la taille du projet (pas de microservices pour un CRUD). |
| 11 | §3 Structure vs stack | La structure de dossiers §3.3 est cohérente avec le pattern et la stack (ex: Next.js → app/, pas pages/). |
| 12 | §3 Couches identifiables | Les couches/modules principaux sont identifiables depuis la structure (même si §3.4 absent). |
| 13 | §4 Intégrations vs features | Chaque intégration externe (API, MCP) est référencée par au moins une feature. |
| 14 | §4 Intégrations complètes | Aucune feature ne requiert une intégration non listée en §4. |

### Faisabilité — risques (checks 15-19)

| # | Check | Quoi vérifier |
|---|-------|---------------|
| 15 | Dépendances features réalistes | L'ordre de dépendances permet une implémentation incrémentale (pas de deadlock). |
| 16 | Complexité milestone 1 | Le premier milestone est réalisable en ≤ 20 tâches atomiques. |
| 17 | Contraintes vs timeline | Les contraintes (performance, sécurité, accessibilité) sont réalistes pour le scope défini. |
| 18 | Stack maturité | La stack choisie est stable et bien documentée (pas de framework beta sans mention explicite du risque). |
| 19 | Intégrations disponibilité | Les APIs/MCP listés sont accessibles (pas de service déprécié ou en accès restreint sans mention). |

### Qualité rédactionnelle — ambiguïtés (checks 20-23)

| # | Check | Quoi vérifier |
|---|-------|---------------|
| 20 | Pas de jargon non défini | Tout terme technique spécifique au domaine est défini ou évident depuis le contexte. |
| 21 | Pas d'ambiguïté "devrait/pourrait" | Formulations claires : "doit" (obligatoire) vs "peut" (optionnel). Pas de "devrait" ambigu. |
| 22 | Pas de contradiction interne | Aucune section ne contredit une autre (ex: hors scope vs feature, contrainte vs stack). |
| 23 | Pas de placeholder résiduel | Aucun `[TO BE DEFINED]`, `[TBD]`, `TODO`, `...` restant dans le Blueprint. |

---

## RAPPORT FINAL

Produis ce rapport structuré :

```markdown
# Rapport de validation BLUEPRINT

## Statut : COMPLET | INCOMPLET

## Score : {N}/23 checks passés

## Couche 1 — Checks déterministes
{Résultat de validate.sh : valid/invalid, erreurs, warnings}

## Couche 2 — Checks sémantiques

### Sections obligatoires (1-8)
- [x] #1 Description substantielle — PASS
- [ ] #2 Utilisateurs identifiables — FAIL : {raison}
...

### Architecture (9-14)
...

### Faisabilité (15-19)
...

### Qualité rédactionnelle (20-23)
...

## Graphe de dépendances features
F-001 → (aucune)
F-002 → F-001
...
Pas de cycle détecté | Cycle détecté : ...

## Recommandations
1. {Action corrective pour chaque FAIL}
2. ...

## Questions (si INCOMPLET)
1. {section}.{champ} — {question précise}
2. ...
```

---

## Règles absolues

- **JAMAIS** modifier le BLUEPRINT ou un autre fichier — lecture seule stricte
- **JAMAIS** deviner ou combler l'information manquante — poser des questions
- Être conservateur : en cas de doute, FAIL ou WARNING, pas PASS
- Le rapport doit être structuré et parseable — utiliser la structure exacte ci-dessus
- Compter les features par priorité : Critique/Critical, Important, Nice-to-have