heithmurray/agent-skills

bcp-finish

L'étape de fin pour un travail réel. Un modèle l'a construit ; un modèle différent l'attaque ; l'Opérateur prend la décision. Basé sur le protocole Constructeur-Contestataire v1.7 (https://github.com/heithmurray/builder-challenger-protocol, CC BY 4.0, Heith Murray).

Quand

• Exécutez-le avant de demander une approbation de fin pour tout travail qui dépasse une modification rapide. N'attendez pas qu'on vous le demande.
• Ignorez-le pour les travaux rapides : évidents, petits et faciles à annuler. Une vérification ciblée suffit.
• Un seul sujet par exécution : la modification que vous êtes sur le point de remettre.

Rôles

• Constructeur : vous, l'agent qui a effectué le travail. Vous corrigez ou répondez à chaque objection.
• Contestataire : un modèle différent, exécuté en lecture seule. Il trouve des problèmes ; il ne modifie jamais de fichiers ni ne rédige de texte livrable.
• Opérateur : l'humain propriétaire du travail. Seul l'Opérateur approuve, accepte un risque, prolonge la limite de tours, émet un dépassement de vérité ou une REFRAME, ou statue sur le périmètre. Vous faites la liaison entre Constructeur et Contestataire, et vous pouvez émettre une RESET — [instruction] standard uniquement pour les violations de format.

Qui conteste qui

• Le Contestataire est toujours d'une famille de modèle différente de celle du Constructeur, démarré sans interface en mode lecture seule. Les appariements et les commandes exactes se trouvent dans references/tools.md.
• Utilisez le modèle par défaut configuré de chaque outil ; ne choisissez pas.
• Chaque appel est une session fraîche qui ne partage aucun historique. Donnez-lui l'intégralité de l'entrée du tour à chaque fois (voir Transmission).
• Accordez jusqu'à 10 minutes par appel. Chaque tour dure généralement 1 à 5 minutes.

Transmission (ce que reçoit le Contestataire)

À chaque tour, rédigez une invite contenant ces parties, dans l'ordre :

1. references/challenger-prompt.md, le fichier entier (le rôle, les règles et les formats).
2. TOUR [n] — SORTIE DU CONSTRUCTEUR — v1.[n-1].
3. Sujet : une phrase expliquant ce que cette modification doit accomplir, dans les mots de l'Opérateur si vous les avez, ainsi que les critères d'acceptation.
4. Où regarder : le chemin du dépôt, les commits de base et de tête, les commandes pour voir le diff (par exemple git diff <base>..<head>), et les fichiers importants.
5. Preuves du Constructeur : la vérification que vous avez effectuée et ses résultats.
6. À partir du tour 2 : votre Réponse du Constructeur (le format de réponse du Constructeur ci-dessous) et le dernier Registre des Objections du Contestataire, textuellement.

Rien d'autre. Pas de commentaires, pas de tours antérieurs au-delà du registre.

Le Contestataire peut lire des fichiers et exécuter des commandes en lecture seule pour prouver ses points. Les niveaux de preuve comptent : exécuter le code ou les calculs prime sur citer une source, qui prime sur une opinion.

La boucle

La limite de tours est de 5, sauf si l'Opérateur en a fixé une autre avant le tour 1. Lorsque la limite est atteinte sans APPROUVÉ, arrêtez-vous et demandez à l'Opérateur. L'Opérateur peut prolonger une fois, avec une raison : PROLONGATION — [tour actuel] à [nouvelle limite]. Raison : [le travail spécifique encore ouvert]. Il n'y a pas de seconde prolongation ; atteindre à nouveau la limite est un blocage.

1. Tour 1 : envoyez la transmission. Sauvegardez la réponse du Contestataire textuellement en tant que tour 1.

2. Verdict RÉVISER ou ÉCHEC : répondez dans le format de réponse du Constructeur :

   • Réponse au verdict.
   • Objections acceptées (par ID) : ce que vous avez modifié. Pour chacune : « Objection [ID] était de niveau [X]. Ma révision a changé [Y]. La proportion est appropriée parce que [Z]. »
   • Objections rejetées (par ID) : raisons, avec des preuves de niveau égal ou supérieur.
   • Contestation d'objection faible.
   • Réponses aux hypothèses.
   • Révisions effectuées.
   • Questions ouvertes restantes.

   Effectuez les révisions et validez-les sur la branche. Envoyez ensuite la transmission du tour suivant.

3. Une objection qui modifierait le périmètre, le comportement ou la conception n'est pas à corriger en silence. Arrêtez-vous et présentez-la à l'Opérateur comme une décision, avec le texte du Contestataire textuellement.

   • Une spécification ou un plan que vous avez rédigé vous-même ne règle pas le périmètre. Ne rejetez pas une objection en vous y référant. Seuls les mots de l'Opérateur ou une spécification approuvée par l'Opérateur comptent. Si le périmètre est la seule raison de rejeter, signalez-le comme « Décision de périmètre de l'Opérateur nécessaire. »

4. Verdict RÉUSSI ne compte qu'avec une Liste de Vérification de Validation complète où le nombre d'ouverts est nul et le verdict final est APPROUVÉ. Sinon, traitez-le comme RÉVISER.

5. Limite de tours atteinte sans APPROUVÉ : arrêtez-vous et présentez le registre ouvert à l'Opérateur. Si l'Opérateur prolonge (une fois), continuez. Sinon, ou à la limite prolongée, c'est un blocage : demandez au Contestataire une Déclaration de Position Finale d'un paragraphe, rédigez la vôtre, et présentez les deux à l'Opérateur.

6. AUTO-ÉCHEC : si l'approche elle-même est défaillante, dites-le avec les trois parties requises : (a) ce qui est défaillant, (b) pourquoi il a fallu la contestation pour le révéler, (c) ce qui ferait fonctionner une approche différente. Présentez-le à l'Opérateur.

Ne modifiez, ne réduisez ni n'adoucissez jamais une réponse du Contestataire. Ne prétendez jamais qu'une objection est résolue ; seul le registre du Contestataire peut la marquer comme résolue.

Où va l'enregistrement

• Si le travail a un dossier de modification ou un enregistrement de tâche, sauvegardez les tours dans ce dossier sous BCP-LEDGER.md : chaque réponse du Contestataire et chaque Réponse du Constructeur, dans l'ordre.
• Sinon, sauvegardez-les dans un dossier temporaire en dehors du dépôt et incluez le registre final dans votre rapport.
• Ne créez pas de nouveaux dossiers de premier niveau pour cela.

Rapport à l'Opérateur (approbation de fin)

• Les modèles utilisés pour le Constructeur et le Contestataire, et le nombre de tours.
• La version finale et le verdict final du Contestataire.
• Le Registre des Objections final, textuellement.
• Les concessions du Contestataire et son auto-évaluation des risques non soulevés, textuellement.
• Vos preuves de vérification.
• Chaque interprétation que vous avez faite lorsque la demande était ambiguë (par exemple « les jours 6–29 ne coûtent rien »), afin que l'Opérateur puisse confirmer ou corriger.
• Tout ce qui nécessite une décision de l'Opérateur : blocage, AUTO-ÉCHEC, décisions de périmètre, objections modifiant le périmètre, risques à accepter.
• Demandez ensuite go ou no-go. Le push, la fusion et la publication attendent le go de l'Opérateur.

Si le Contestataire ne peut pas s'exécuter

1. Réessayez une fois. Si une erreur de modèle mentionne un modèle non pris en charge, signalez-le ; ne changez pas de modèle en silence.
2. Si l'autre outil est toujours indisponible, exécutez la même boucle avec la commande en lecture seule sans interface de votre propre outil comme Contestataire (voir references/tools.md). C'est une session fraîche sans contexte partagé.
3. Étiquetez l'ensemble du résultat AUTO-CONTESTATION dans le rapport, et dites pourquoi le second modèle n'était pas disponible. Une auto-contestation partage les angles morts du Constructeur, donc l'Opérateur devrait lui accorder moins de poids.
4. Ne sautez jamais l'étape en silence.