G3 — Plan de fab FE arrêté¶
Cette porte regroupe 1 transition dans la machine d'états.
G3 — Plan de fab FE arrêté¶
Objet : Feature (fe)
Transition : IN_PROGRESS ● FAB_PLAN_EN_COURS → FAB_PLAN_ARRETE IN_PROGRESS ●
Préconditions¶
- PRD consolidé (problème, personas, critères de succès)
- Cas d'usage structuré (Given/When/Then)
- Actions identifiées et décomposées
- User Stories INVEST créées (Indépendant, Négociable, Valuable, Estimable, Small, Testable)
- USs ordonnancées en plan de fab
- Critères d'acceptance feature définis
- Estimate squad disponible
- Dépendances inter-features identifiées
Artefacts gelés (passage COLD)¶
- PRD → COLD (cadrage figé pour ce PI)
- Spec FE → COLD (périmètre contractualisé pour ce PI)
- Plan de fab → IMMUTABLE
- Liste US → COLD
Invariants cross-objets¶
| id | kind | allowed / min |
|---|---|---|
us-min-3 |
minChildCount |
min : 3 |
Checks automatisés¶
| id | kind | path / key / allowed |
|---|---|---|
prd-exists |
fileExists |
.product/.features/{id}/prd.md |
prd-meta |
frontmatterHas |
.product/.features/{id}/prd.md · keys : problem_statement, user_personas, success_criteria |
feature-spec |
fileExists |
.product/.features/{id}/spec.md |
feature-plan-fab |
fileExists |
.product/.features/{id}/plan-fab.md |
feature-meta |
frontmatterHas |
.product/.features/{id}/spec.md · keys : acceptance_criteria, estimate |
Commande CLI¶
Notes et annotations¶
Le PRD, artefact LIVING pré-G3 (v3)¶
Depuis la v3 (ADR-0009), chaque Feature
traverse un statut intermédiaire PRD_EN_COURS avant d'entrer dans FAB_PLAN_EN_COURS.
Le prd.md y est rédigé en mode LIVING : le PRD peut encore évoluer pendant
toute la phase de décomposition (FAB_PLAN_EN_COURS). C'est à G3 — et seulement à
G3 — qu'il est figé en COLD, en même temps que spec.md, plan-fab.md et la liste
des USs INVEST.
Le PRD répond à trois questions avant toute décomposition technique :
- Problème (
problem_statement) — quelle friction métier on résout, pour qui, avec quel impact mesurable si on ne fait rien. - Personas (
user_personas) — qui bénéficie directement, qui subit l'existant, qui opère la bascule. - Critères de succès (
success_criteria) — ce qui doit être vrai à la fin du cycle pour que la Feature soit considérée réussie (distinct des OKRs BE).
Ces trois clés sont exigées en frontmatter par le check prd-meta au passage de G3.
Pourquoi à ce moment du cycle ?¶
Le PRD s'insère entre le plan de dév BE (G2, use cases macro) et la décomposition FE en actions + USs (G3). Avant G2, on raisonne en fonctions métier ; entre G2 et G3, on cadre chaque Feature comme un produit à part entière ; après G3, on fabrique.
Placer le PRD ailleurs — en amont de G2 ou fondu dans spec.md — revient à mélanger
deux grains de décision différents : le cadrage stratégique (BE) et le cadrage produit
(FE). La v3 sépare ces grains sans introduire de porte supplémentaire.
Migration v2 → v3¶
La transition directe fe.NOT_STARTED → fe.FAB_PLAN_EN_COURS reste disponible
(deprecated: true) pour que les Features ouvertes sous v2 puissent continuer leur
cycle sans être rejetées par le validator. Les nouvelles Features doivent passer
par PRD_EN_COURS. Cette transition legacy sera retirée dans une v3.x ultérieure.
Squelette de prd.md¶
Le template consumer est fourni dans meta/template-prd.md (copié par
scripts/bootstrap.js dans .meta/ du projet hôte).