V2 — Portes exécutables¶
Commit de référence : eeb9edd — « feat(sdlc): portes exécutables — préconditions automatisées + invariants parent-enfant »
Contexte¶
À la sortie de V1, les portes P1 à P10 existaient dans la documentation (sdlc/SDLC.md) mais pas dans le code. sdlc/sdlc.js autorisait les transitions sans vérifier leurs préconditions. Résultat : on pouvait faire passer un BE en statut CADRE_IA sans que hypothesis.md existe, un FE en READY sans que son BE parent soit validé.
La V2 traite ce décalage : les portes deviennent exécutables. Chaque porte sait ce qu'elle exige et refuse mécaniquement les transitions qui ne l'honorent pas.
Décisions structurantes¶
Décision 1 — Deux catégories de checks : invariants et checks¶
- Invariants : règles structurelles (le parent existe, est vivant, est du bon type). Échec d'un invariant = NO-GO automatique.
- Checks : règles de contenu (tel fichier existe, tel champ est rempli, telle métrique a une valeur). Échec d'un check = signalement, mais NO-GO seulement si qualifié d'obligatoire.
Cette distinction permet de durcir progressivement : on peut ajouter des checks sans qu'ils bloquent immédiatement les projets existants.
Décision 2 — Trois verdicts : GO, NEEDS-REVIEW, NO-GO¶
- GO : tous les checks obligatoires passent, aucun warning.
- NEEDS-REVIEW : checks obligatoires OK, mais warnings présents. La CLI demande une confirmation explicite de l'humain avant le
move. - NO-GO : au moins un check obligatoire échoue. La CLI refuse (sauf
--forcetracé).
Décision 3 — L'evaluator est un module séparé¶
sdlc/evaluator.js est distinct de sdlc/sdlc.js. L'evaluator prend en entrée {type, from, to, objectId, registry, projectRoot} et retourne {results, summary, verdict}. Cette séparation permet de tester les règles sans passer par l'exécution complète de la CLI.
Pivots¶
- Envisagé : un DSL YAML pour décrire les checks. Abandonné : plus de fichiers à maintenir, perte du pouvoir expressif de JS (conditions, boucles, accès au filesystem). Retenu : les checks sont définis en JavaScript dans
schema.js. - Envisagé : vérification stricte de tous les invariants à chaque commande CLI. Trop coûteux pour
status. Retenu : vérification à la transition uniquement, et une commandevalidatepour audit ponctuel.
Artefacts produits¶
sdlc/evaluator.js— évaluateur des portes- Ajout de
preconditions,invariants,checks,freezeaux transitions danssdlc/schema.js snapshotdes checks écrit dans l'historique des objets (traçabilité du verdict au moment de la décision)- Extension de
sdlc/sdlc.jspour afficher le verdict en temps réel et bloquer les NO-GO
Leçons apprises¶
L'automatisation ne remplace pas le jugement — elle le soutient¶
Un verdict automatisé n'autorise ni n'interdit seul. Il informe la décision humaine. La checklist interactive de move reste le moment de gravure — l'automatisation fait gagner du temps en signalant les angles morts, pas en décidant à la place.
NEEDS-REVIEW est la catégorie la plus précieuse¶
Le piège du binaire GO/NO-GO : tout warning qui n'est pas bloquant est ignoré. Le verdict intermédiaire NEEDS-REVIEW oblige l'humain à prendre position sur le warning — soit il le traite, soit il documente pourquoi il passe outre. C'est là que la qualité se joue.
Les invariants structurels doivent être triviaux à vérifier¶
Les invariants parent-enfant (un FE a un parent BE vivant, un US a un parent FE vivant) sont des one-liners en JS, mais ils couvrent 80% des incohérences observées en projet. ROI exceptionnel.
Le snapshot des checks dans l'historique est sous-estimé¶
Conserver, dans l'historique de chaque objet, le snapshot des checks au moment de la transition permet, six mois plus tard, de comprendre pourquoi une décision a été prise. Sans ça, on ne peut qu'extrapoler.
Voir aussi : V3 — Vague 3 · V1 — Bootstrap · Les 10 portes · ADR 0004.