Aller au contenu

V3 — Vague 3

Commits de référence : - 5569f0c — « feat(sdlc): étendre checks automatisés à P4-DOR, P6 (PR+DoD), P8 » - 92e9f13 — « feat(sdlc): safeResolve en mode NEEDS-REVIEW (chemin hors projet = warn) » - 4a4df9a — « feat(sdlc): vague 3 — be.P2, us.P5-DOR, fe.P9-init, fe.P9-term automatisées »

Contexte

V2 avait posé l'infrastructure des portes exécutables mais ne couvrait pas toutes les portes. V3 étend la couverture aux portes P2 (cadrage IA du BE), P5 (DOR du Récit), P6 (PR + DoD), P8, P9 (initialisation et terminaison d'une Feature en MVP).

En parallèle, une difficulté émerge sur safeResolve — la fonction qui résout les chemins relatifs du projet. Un {id} dans un pattern de fichier peut renvoyer vers un chemin hors du dossier projet, ce qui en V2 faisait un fail silencieux. V3 le traite comme un warn qui déclenche NEEDS-REVIEW.

Voir aussi le document de spécification détaillé : docs/specs/next-gates-and-safeResolve.md.

Décisions structurantes

Décision 1 — Automatiser P5 (DOR du Récit) avec des checks INVEST

Un Récit ne peut passer REDIGE → READY (porte P5) qu'à trois conditions vérifiables :

  • Sa description respecte le template (sujet, intention, critères d'acceptation).
  • Ses critères d'acceptation sont testables (présence de verbes d'action mesurables).
  • Son parent FE est en statut CONCU ou au-delà.

Les checks INVEST complets (Independent / Negotiable / Valuable / Estimable / Small / Testable) n'ont pas été tous automatisés — seuls I, E, T. N et V restent des préconditions humaines.

Décision 2 — Automatiser P9 (initialisation et clôture MVP)

La porte P9 a deux faces : lancer un MVP (PRET_MVP → MVP_ACTIF) et le clôturer (MVP_ACTIF → REVUE_MVP). Les deux exigent la présence d'artefacts distincts :

  • Lancement : plan MVP, métriques cibles, horizon temporel.
  • Clôture : métriques collectées, journal des observations, hypothèse tenue ou non.

Décision 3 — safeResolve en mode NEEDS-REVIEW sur chemin hors projet

Si un check résout un pattern {id} vers un chemin qui échappe au projectRoot (ex: absolu, remonte par ../..), le comportement bascule :

  • V2 : fail silencieux (le fichier « n'existe pas »).
  • V3 : warn avec raison explicite (« chemin hors projet : /etc/passwd »).

Cette décision traite les projets dont le mapping {id} a été customisé vers un emplacement non standard — ils obtiennent une alerte claire, pas un échec cryptique.

Pivots

  • Envisagé : écrire un pack de checks INVEST complet en V3. Abandonné : N (Negotiable) et V (Valuable) ne sont pas décidables sans contexte humain. Retenu : automatiser I, E, T ; laisser N, V en préconditions humaines de la porte.
  • Envisagé : abort dur sur chemin hors projet. Abandonné : certains projets ont des mappings légitimes hors du dossier (mono-repo, symlinks). Retenu : warn + NEEDS-REVIEW, l'humain décide.

Artefacts produits

  • Checks P2, P5, P6, P8, P9-init, P9-term dans sdlc/schema.js
  • Fonction safeResolve améliorée dans sdlc/evaluator.js
  • Document de spec : docs/specs/next-gates-and-safeResolve.md
  • Support complet du verdict NEEDS-REVIEW dans la CLI

Leçons apprises

Les préconditions humaines ne sont pas un échec de l'automatisation

Vouloir tout automatiser est une tentation. V3 confirme : pour N et V (Negotiable / Valuable), le check automatisé produirait plus de faux positifs que de valeur. La préconditions humaine, répétée explicitement à chaque move, vaut mieux qu'un check lâche.

Un warn qui déclenche NEEDS-REVIEW vaut mieux qu'un fail qui bloque

Le piège du strict : on frustre l'utilisateur qui a une bonne raison de passer, on le pousse à --force, et le --force devient un réflexe au lieu d'une exception. Le mode NEEDS-REVIEW laisse la porte ouverte à une confirmation consciente.

Distinguer P9-init et P9-term est plus clair que P9 unique

À la réflexion, la porte P9 « MVP » avait deux mouvements distincts (lancer / clôturer). Les traiter comme deux transitions nommément distinctes (même porte dans le découpage logique, mais deux entrées dans TRANSITIONS) améliore la lisibilité de la CLI et la précision des checks.

Les specs longs méritent d'être conservés

Le document next-gates-and-safeResolve.md a été rédigé pendant la conception de V3, pas après. Il encode les hésitations, les options abandonnées, les pourquoi. Six mois après la livraison, il reste lisible et instructif — c'est ce qui justifie de l'intégrer à la living doc (via la section Visualisations) plutôt que de le considérer comme un brouillon jetable.

Voir aussi : V4 — As-is synthesis · V2 — Portes exécutables · ADR 0006.