Travailler par lots

Le développement par lots est le cœur de la SR Method. Il transforme une conversation ouverte avec Codex en une suite d'unités de travail nommées, bornées, vérifiables et reprises proprement.

Parler en lots

L'utilisateur doit apprendre à parler à Codex en lots :

cadre ce lot
donne le plan du lot
exécute ce lot
mets ce lot en user_testing
les tests E2E de ce lot sont validés
passe-le en done
propose le prochain lot

Pourquoi les lots changent la qualité

• ils limitent le scope ;
• ils donnent un identifiant stable ;
• ils permettent de reprendre une session ;
• ils distinguent code terminé et produit validé ;
• ils rendent visible ce qui reste à tester.

Regrouper plusieurs lots en passes SR

Depuis SR 3.2.0, un projet peut aussi utiliser docs/codex/SR_PASSES.yaml.

Une passe SR ne remplace pas les lots. Le lot reste l'unité atomique : périmètre, critères d'acceptation, chemins autorisés, stop conditions, statut et mémoire de tâche. La passe sert à orchestrer plusieurs lots liés quand ils partagent un socle, un preflight, des dépendances ou une validation E2E commune.

Une passe doit rendre explicites :

• les lots inclus et leur ordre d'exécution ;
• la raison du regroupement ;
• les dépendances entre lots ;
• le preflight commun ;
• les validations humaines nécessaires ;
• les secrets, accès, actions externes ou migrations ;
• la stratégie E2E : par lot, groupée en fin de passe ou non requise ;
• les conditions d'arrêt.

Avant une exécution multi-lots significative, Codex doit appliquer le Pass Planning Gate. Si SR_PASSES.yaml existe ou vient d'être créé, Codex doit le valider avec :

python3 scripts/codex/validate_pass_contract.py --file docs/codex/SR_PASSES.yaml --lots-file docs/codex/SR_LOTS.yaml

Après la création de plusieurs lots, utilisez le prompt :

Utilise docs/codex/prompts/08_define_sr_passes_from_lots.md pour proposer les passes SR à partir de SR_LOTS.yaml. Ne modifie pas le code applicatif.

Cycle de vie standard

proposed -> planned -> validated -> in_progress -> user_testing -> done

En cas de problème :

user_testing -> reopened -> in_progress -> user_testing -> done

Règle importante

Un lot n'est pas automatiquement done parce que Codex a fini de coder. Si une validation réelle est nécessaire, Codex doit placer le lot en user_testing.

Après un test E2E validé par l'utilisateur, l'utilisateur demande explicitement à Codex de passer le lot en done.

Plan complet du lot avant code

Avant toute modification, Codex doit produire un plan validable :

• Lot ID ;
• objectif vérifiable ;
• contexte court ;
• périmètre inclus ;
• hors périmètre ;
• hypothèses ;
• sources à lire ;
• skills méthode et métier ;
• fichiers candidats ;
• risques identifiés ;
• stratégie d'implémentation ;
• vérifications prévues ;
• tests E2E utilisateur ;
• conditions d'arrêt ;
• statut attendu après exécution.

Prompts utiles

Cadre ce besoin comme un lot SR. Ne code rien. Donne objectif, périmètre, hors périmètre, critères d'acceptation, sources à lire, risques, vérifications et tests E2E.

Donne-moi le plan complet du lot [LOT-ID] avant de coder. Je veux valider le périmètre, les sources, les fichiers candidats, les vérifications et les tests E2E.

Exécute le lot [LOT-ID] en respectant les gates SR. Mets à jour la mémoire SR, les contrats et donne les tests E2E utilisateur.

Les tests E2E du lot [LOT-ID] sont validés par l'utilisateur. Mets le lot en done, mets à jour SR_LOTS.yaml, la task memory, les contrats si nécessaire, puis propose le prochain lot prioritaire.

Le test E2E du lot [LOT-ID] échoue sur [description]. Rouvre le lot, applique le Fact Gate, diagnostique avant de corriger.