tderoussel/build-de-nuit

Prompt de build de nuit

Le modèle complet se trouve dans references/overnight-build-template.md. Lisez-le avant de composer. Ne reconstruisez pas la structure des règles de mémoire — remplissez ses sections [ENTRE CROCHETS] à partir des spécificités de l'utilisateur, et conservez les modifications qu'il a apportées à sa propre copie.

Non négociable

Chaque sortie doit contenir la Règle 8 (survivre aux réinitialisations d'utilisation) et la section LANCEUR. Ce sont elles qui rendent le build redémarrable ; un prompt sans elles redémarre silencieusement de zéro après la première réinitialisation et gaspille une nuit.

Composer

1. Lisez le modèle. Si l'utilisateur conserve une copie modifiée, la sienne prime — conservez ses modifications.
2. Remplissez le cahier des charges — quoi construire, contexte, exigences de conception, exigences techniques, fonctionnalités par ordre de priorité, données d'exemple, déploiement, critères de succès. La spécificité est la clé ; un cahier des charges vague produit une nuit vague.
3. Définissez les phases — 4 à 8, chacune indépendamment réalisable et vérifiable, avec des allocations de temps qui totalisent le budget.
4. Remplissez le playbook de pivot avec les blocages spécifiques au projet en plus de ceux présents dans le modèle.
5. Demandez une fois quel lanceur ils souhaitent (A : planificateur OS · B : boucle bash · C : une tâche planifiée MCP) si la demande ne le précise pas. Demandez une fois — puis poursuivez.
6. Sortez sous la forme d'un seul bloc de code copiable, et rappelez-leur de l'enregistrer dans overnight-build-prompt.txt à la racine du projet avant de lancer.

Signalisation d'achèvement

Le prompt doit demander au build d'émettre BUILD_COMPLETE comme dernière ligne — l'exécuteur en boucle bash le cherche pour se terminer. Indiquez clairement, dans le prompt, que ne pas émettre BUILD_COMPLETE est correct lorsqu'un critère P0 n'est vraiment pas rempli. Un exécuteur qui se termine sur un build inachevé est pire qu'un qui continue.

Garde-fous

Un agent non supervisé n'a personne à qui demander, donc le prompt doit contenir ses propres limites.

Si la cible est une base de code de production existante, déduisez d'abord la propriété des fichiers et une liste À NE PAS FAIRE (la compétence fleet-brief produit les deux) et intégrez les vérifications de validation du projet dans la phase de test, de sorte que « fait » signifie vérifié plutôt que fusionné.

Ne laissez jamais un prompt de nuit autoriser l'application de migrations de base de données, le push de schéma, le déploiement via une CLI d'hébergement, l'achat ou la libération de numéros de téléphone ou de domaines, ou l'envoi de messages sortants à des contacts réels. Ceux-ci nécessitent un humain éveillé. Ajoutez les propres actions irréversibles du projet à cette liste.

Livrables que le build doit écrire

• BUILD_LOG.md — entrées de phase, décisions, pivots, problèmes connus, et blocs ## CHECKPOINT — <ISO> avec l'étape suivante exacte
• RESEARCH_NOTES.md — résultats de recherche avant le début de l'implémentation

Lors de la reprise, la toute première action du build est de lire BUILD_LOG.md de haut en bas et de continuer depuis le dernier point de contrôle — ne jamais re-rechercher, re-échafauder ou redémarrer.