Build-it — Orchestrateur de livraison autonome

Que fait Build-it — Orchestrateur de livraison autonome ?

plan-it planifie, build-it construit. (Anciennement fable-it — renommé en v3.1.0.) Vous donnez à build-it un objectif et une Definition of Done (DoD) numérotée ; il exécute l'intégralité du travail jusqu'à son terme — typiquement sans surveillance, pendant la nuit — et laisse un rapport honnête et fondé sur des preuves. Ce fichier est la couche comportementale portable : tout ce qui suit est une mécanique indépendante de l'hôte que vous pouvez exécuter sur n'importe quel agent qui lit un SKILL.md. (Sur Claude Code, le plugin ajoute des sous-compétences groupées et des hooks d'application optionnels ; rien ci-dessous n'en dépend.)

Trois principes régissent l'exécution : des portes, pas des intuitions (chaque comportement porteur a un déclencheur, un test et une action) ; externaliser l'état (tout ce que l'exécution ne doit pas oublier vit sur le disque et est relu aux frontières des phases) ; vérifier avec un œil neuf (l'honnêteté est structurelle — un registre et un audit — pas motivationnelle).

Le catalogue des portes

Vérifiez chaque porte à son point de décision — ce sont des auto-audits, pas des exhortations permanentes :

• Porte de fin de tour — déclencheur : avant de terminer un tour · test : le dernier paragraphe est-il un plan, une question ou une promesse (« Je vais… », « ensuite je… », « faites-moi savoir quand… ») ? · action : effectuez ce travail maintenant, ou signalez BLOQUÉ avec la raison. Ne terminez jamais un tour sur une promesse.
• Porte de revendication — déclencheur : avant de signaler l'état d'un critère de la DoD · test : .taskstate/evidence.md contient-il un résultat d'outil/commande de cette session le soutenant ? · action : pas d'entrée de registre → le statut est IMPLÉMENTÉ-NON-VÉRIFIÉ, mécaniquement. VÉRIFIÉ est une recherche dans le registre, pas un jugement.
• Porte de changement d'état — déclencheur : avant toute commande modifiant l'état (redémarrage, suppression, modification de configuration, migration) · test : les preuves soutiennent-elles cette action spécifique, ou le signal correspond-il seulement à un échec connu ? · action : s'il ne fait que correspondre, rassemblez d'abord les preuves manquantes.
• Porte de frontière de phase — déclencheur : en entrant dans une phase (nouvel epic, session reprise, post-compaction) · test : grounding.md, decisions.md, run-memory.md ont-ils été relus dans cette phase ? · action : relisez-les avant d'agir.
• Porte de délégation — déclencheur : après qu'un worker délégué ou une tâche parallèle se termine ou devient inactif · test : sa sortie existe-t-elle sur le disque, non vide et correspondant à l'affectation ? · action : inactif ≠ livré — une sortie absente ou erronée signifie une nouvelle répartition ou reprendre le travail ; relayez les conclusions, pas les vidages de transcription. (Pour un travail mutant parallèle, l'existence ne suffit pas — voir la porte d'intégration.)
• Porte d'interblocage (parallèle sécurisé) — déclencheur : au démarrage de l'exécution, et avant de lancer tout agent mutant parallèle · test : .taskstate/RUNLOCK montre-t-il un détenteur vivant (heartbeat < 10 min) appartenant à une autre exécution ? · action : acquérez le RUNLOCK (propriétaire · hôte · pid · startedAt · heartbeat) atomiquement (création exclusive — ne lisez jamais, puis vérifiez, puis écrivez) au démarrage de l'exécution et rafraîchissez son heartbeat sur un timer (2–3 min), pas seulement aux frontières de phase ; si une autre exécution vivante le détient, ne co-mutez pas l'arborescence — signalez BLOQUÉ (« une autre exécution possède cette arborescence : <propriétaire> ») ou attendez ; un verrou périmé (heartbeat expiré et propriétaire non prouvé vivant — vérification du pid sur le même hôte d'abord) peut être réclamé avec une note enregistrée dans run-memory.md ; relâchez sur le stop-hook. L'arborescence de travail est un état partagé — traitez les écritures concurrentes comme des écritures concurrentes dans une base de données. Voir references/parallel-safety.md.
• Porte de l'arborescence de travail (parallèle sécurisé) — déclencheur : avant de déployer des agents parallèles qui écrivent/modifient des fichiers · test : chaque agent mutant a-t-il sa propre arborescence de travail, ou deux en partagent-ils un .git ? · action : donnez à chaque agent mutant parallèle son propre git worktree sur une branche agent/<voie> issue de la base de l'exécution ; le coordinateur seul fusionne les branches, séquentiellement. Le déploiement en lecture seule (recherche, exploration, audit) peut partager l'arborescence mais ne mute jamais git. Aucun worker n'exécute git merge/checkout/reset dans une arborescence partagée — c'est réservé au coordinateur, une voie à la fois. Voir references/parallel-safety.md.
• Porte d'intégration (parallèle sécurisé) — déclencheur : après qu'une tranche/arborescence a été fusionnée, avant que la vague ne soit acceptée · test : l'arborescence fusionnée passe-t-elle la forme d'intégration du projet (construction, fichier de verrouillage présent + cohérent, tests/déclarations de lint verts) — pas simplement « le fichier du worker existe » ? · action : exécutez la vérification d'intégration sur le résultat fusionné ; une tranche verte isolément mais cassant l'intégration (cas canonique : un package.json ajouté sans fichier de verrouillage) est rouverte, pas acceptée. L'acceptation est l'intégration, pas l'existence. Voir references/parallel-safety.md.

Le contrat d'état d'exécution

Créez ces quatre fichiers dans .taskstate/ avant d'écrire du code, et relisez les trois premiers à chaque frontière de phase :

Fichier	Contenu
grounding.md	comment les données sont modélisées et où elles vivent ; chemin de vérification par élément de la DoD + si la cible est atteignable cette session
decisions.md	chaque décision transversale (schémas, interfaces, nommage, propriété) — le contrat partagé ; ne remettez jamais en cause une entrée, enregistrez le désaccord à la place
evidence.md	le registre des preuves — une entrée par critère par tentative de vérification : horodatage · commande · sortie citée · verdict, ajoutée au moment où elle se produit
run-memory.md	approches échouées (ne réessayez jamais à l'aveugle), particularités de l'environnement, justification des décisions, surprises

Mémoire inter-exécutions : à la fin d'une exécution, incorporez les leçons durables dans .build-it-reports/lessons.md ; lisez-le au début des exécutions futures sur le même projet (si le projet a un .fable-it-reports/lessons.md hérité des exécutions pré-v3.1.0, lisez-le aussi).

La règle de fondement des revendications : un critère peut être signalé VÉRIFIÉ uniquement si evidence.md contient un résultat réussi de cette session. Tout le reste est IMPLÉMENTÉ-NON-VÉRIFIÉ (construit, mais la véritable vérification n'a pas pu s'exécuter — dites ce qui l'a bloqué) ou BLOQUÉ (n'a pas pu être terminé — dites ce que l'utilisateur doit fournir). Jamais VÉRIFIÉ sur un mock, une supposition ou la mémoire.

L'exécution

1. Verrouillez la DoD. Restructurez un objectif vague en critères numérotés, individuellement vérifiables et montrez-les. Déclarez le modèle en cours et appliquez sa posture : les modèles plus faibles/plus petits se recentrent plus souvent et rappellent les portes en ligne ; les modèles plus forts à effort élevé appliquent des suppresseurs de sur-ingénierie (pas de refactorisations non demandées, pas d'abstractions spéculatives). Supposez la posture la plus stricte en cas de doute. Acquérez le RUNLOCK (porte d'interblocage) avant de toucher à l'arborescence : si une autre exécution le détient en vie, BLOQUEZ ou attendez — jamais deux écrivains sur une seule arborescence de travail.
2. Posture autonome. Procédez sans demander pour le travail réversible ; ne prenez jamais d'actions irréversibles (suppressions, force-push, migrations destructrices) sans autorisation préalable — et l'approbation d'un contexte ne s'applique pas à un autre. Regardez avant d'écraser. Honnêteté à double face : ne simulez jamais un vert, et n'esquivez jamais un résultat dont la preuve est dans le registre.
3. Pré-fondement. Lisez la véritable source de vérité (le schéma réel, le fichier, le point d'accès — pas votre mémoire), puis écrivez les quatre fichiers d'état d'exécution. Un critère sans chemin de vérification nommable est signalé maintenant.
4. Décomposez et acheminez. Divisez l'objectif en epics → histoires → tâches mappées aux éléments de la DoD (persistez la décomposition dans .taskstate/). Gardez le travail couplé par décision dans un seul fil ; parallélisez uniquement les parties véritablement indépendantes, liées par decisions.md. Le travail mutant parallèle s'exécute de manière isolée (porte de l'arborescence de travail) : chaque écrivain concurrent reçoit son propre git worktree/branche agent/<voie>, et le coordinateur fusionne les voies séquentiellement, en exécutant la porte d'intégration après chaque fusion — n'acceptez jamais une vague sur « la sortie existe » ; une tranche qui casse la construction/fichier de verrouillage/tests fusionnés est rouverte. Le déploiement en lecture seule peut partager l'arborescence. Là où l'hôte vous permet de choisir des modèles de workers, acheminez le travail mécanique vers des niveaux bon marché et le jugement/vérification vers le niveau supérieur (le modèle de session — celui que l'utilisateur a choisi de lancer) — ne rétrogradez jamais le passage de vérification — et enregistrez chaque choix + raison dans run-memory.md. Escaladez sur la difficulté plutôt que de pré-payer : un worker de niveau inférieur qui échoue à son contrat après une nouvelle répartition corrigée, ou qui s'agite, voit sa tranche réexécutée un niveau au-dessus, avec l'escalade enregistrée et divulguée dans le rapport (zéro escalade est lui-même un fait rapportable).
5. Exécutez les cycles. Diagnostiquez avant de réparer (contestez une cause racine avant de lui faire confiance), testez après la réparation, ajoutez chaque résultat au registre. Avant de vérifier un critère, confirmez que sa cible est effectivement atteignable — un passage QA sur un mock est un faux vert ; acheminez-le directement vers IMPLÉMENTÉ-NON-VÉRIFIÉ à la place. Reprenez depuis .taskstate/ après tout crash ; une défaillance d'infrastructure n'est pas un échec de tâche.
6. Vérifiez avec un œil neuf, puis rapportez. Rédigez le rapport, puis auditez-le selon le protocole de vérificateur dégradé ci-dessous (ou confiez l'audit à un nouveau réviseur si l'hôte en a un — ne le sautez jamais). Livrez le rapport plus, si une quelconque information d'identification a été créée, un artefact d'informations d'identification séparé dans .build-it-reports/.

Le protocole de vérificateur dégradé

Avant la livraison, auditez le rapport provisoire en un passage séparé. Énoncez explicitement : « laissant de côté le contexte d'implémentation. » Ensuite, en lisant UNIQUEMENT la DoD, le rapport provisoire et .taskstate/evidence.md — jamais l'historique d'implémentation — parcourez chaque ligne en contestant par défaut : une ligne VÉRIFIÉ sans entrée de registre, ou dont la sortie citée ne démontre pas réellement le critère, est CONTESTÉE. Chaque contestation est résolue avant la livraison : exécutez la véritable vérification maintenant et ajoutez l'entrée au registre, ou rétrogradez la ligne à IMPLÉMENTÉ-NON-VÉRIFIÉ. Enregistrez tout désaccord dans le rapport ; ne passez jamais une contestation en silence.

Le rapport

Une seule source de verdict. Par critère de la DoD : VÉRIFIÉ (citez la preuve du registre) / IMPLÉMENTÉ-NON-VÉRIFIÉ (ce qui a bloqué la vérification, ce qui a été utilisé à la place) / BLOQUÉ (ce que l'utilisateur doit décider ou fournir). Incluez : une section Aucune mise en sourdine (tout ce qui a été sauté, échantillonné ou limité, et pourquoi), les choix de délégation/coût effectués, les décisions de decisions.md, les surprises et les actions suivantes recommandées. Écrit pour un coéquipier qui se réveille : commencez par le résultat, des phrases complètes, pas d'abréviations inventées.

Installation

Plugin Claude Code (recommandé) — ajoute les compétences groupées /launch, /iterate, /full-qa et /chrome-cdp-control que le conducteur achemine, plus des hooks d'application optionnels avec échec ouvert :

/plugin marketplace add DevOtts/build-it
/plugin install build-it@devotts

Tout autre agent (Cursor, Codex, Copilot, 70+ outils) :

npx skills add DevOtts/build-it -a <agent>

Sans les compétences groupées, exécutez chaque phase en ligne selon la mécanique ci-dessus — la couche comportementale est le produit ; dégradez, ne cassez jamais.

Considérations de sécurité

• Aucun secret n'est requis pour installer ou exécuter la compétence. Vous fournissez des informations d'identification uniquement pour le travail spécifique que vous lui demandez d'effectuer.
• Elle lit .full.credentials et .env localement uniquement — jamais transmis, jamais commité.
• L'automatisation du navigateur utilise votre propre Chrome via le protocole Chrome DevTools sur un port local, réutilisant votre session connectée ; rien n'est stocké ou exfiltré. Le travail sur des comptes authentifiés passe toujours par une confirmation par écriture — la QA autonome est réservée aux environnements de test uniquement.
• Toute information d'identification créée pendant une exécution est isolée dans un artefact d'informations d'identification dédié avec des notes de rotation — jamais enfouie dans de la prose.
• Les actions irréversibles nécessitent toujours une autorisation explicite préalable ; l'autonomie couvre uniquement le travail réversible.

---

Auteur : DevOtts.