acceptance-contract

Que fait acceptance-contract ?

Utilisez cette compétence avant toute implémentation lorsqu'un brief, un ticket, un email, un README, un bundle zip ou un dossier de preuves doit être transformé en critères d'acceptation exécutables.

Première commande pour le travail d'implémentation :

skills/acceptation-contrat/run.sh ensure <zip|répertoire|fichier> \
  --out /tmp/acceptation-contrat \
  --nom-projet essai-oai \
  --mode-but creer

ensure est le garde mécanique : il valide un acceptance_bundle.json existant, l'extrait automatiquement s'il manque, et échoue en bloc lorsque le bundle source fourni a changé depuis que le contrat figé a été écrit. Son reçu JSON inclut un compteur acceptation_contrat.progress.v1 avec pourcentage, verifications, en_attente et prochaines_etapes. N'implémentez pas à partir d'un brief tant que ensure ne retourne pas statut=REUSSI et que le compteur de progression n'indique pas ce qui reste.

Passez en entrée le brief client, le bundle zip, ou le répertoire de spécifications intentionnellement préparé. La CLI refuse par défaut les racines de dépôt afin que les fichiers d'implémentation ne deviennent pas silencieusement la source d'acceptation. Utilisez --allow-repo uniquement lorsque l'humain demande explicitement un contrat à l'échelle du dépôt.

Pour les briefs clients à haut risque, lancez une revue en table ronde de second niveau $ask sur le brief/zip plus acceptance_bundle.json avant l'implémentation. Incluez WebGPT comme l'un des relecteurs lorsqu'il est disponible. Demandez simplement : "Ces exigences contractuelles sont-elles correctes, et avons-nous oublié quelque chose ?" Exigez que les relecteurs vérifient si une quelconque obligation du client manque dans le contrat figé, en particulier les classes de représentation, les valeurs typées, les conditions limites et les modes de défaillance disqualifiants. La revue est une preuve consultative ; les barrières déterministes restent les arbitres RÉUSSI/ÉCHEC. La revue essai-oai a révélé que la couverture scalaire typée doit également exiger l'équivalence canonique : les chaînes de politique formatées, les scalaires numériques uniquement digitaux, les formes décimales, la notation scientifique et les valeurs numériques SQLite ne peuvent pas être des univers d'acceptation séparés.

Ce qu'il fait

skills/acceptation-contrat/run.sh extraire <zip|répertoire|fichier> \
  --out /tmp/acceptation-contrat \
  --nom-projet essai-oai \
  --mode-but creer

Produit :

• acceptance_bundle.json — source de vérité validée par Pydantic
• acceptance_report.json — JSON create_report.report.v1
• acceptance_report.md — rendu via $create-report
• BUT_IMMUABLE.projet.md — texte provisoire du but ou proposition d'amendement

Commandes :

• extraire écrit toujours un nouveau bundle/rapport provisoire à partir de la source fournie.
• ensure valide ou crée le bundle figé et rejette les hashs de source obsolètes.
• valider valide uniquement un acceptance_bundle.json existant et affiche le compteur de progression.
• statut lit un acceptance_bundle.json existant et affiche uniquement le compteur de progression lisible par machine.

Politique de but

Le comportement par défaut est provisoire, pas de mutation.

• --mode-but creer écrit un nouveau projet de but immuable.
• --mode-but amender écrit une proposition d'amendement, pas une modification silencieuse.
• --mode-but aucun extrait les exigences sans texte de but.

Un véritable but immuable doit être créé ou amendé uniquement après approbation humaine. Cette règle existe parce que l'essai-oai a échoué lorsque des tests définis par l'implémentation ont remplacé le brief client.

Périmètre

Cette compétence extrait des exigences claires et sourcées à partir de fichiers locaux fournis. Elle ne prétend pas que le contrat extrait est complet lorsque le bundle source est ambigu. L'ambiguïté devient questions_ouvertes[] et un rapport à modifier. Elle refuse les racines de dépôt par défaut car l'essai-oai a échoué lorsque des vérifications en forme de code ont remplacé le brief livré.

Pour Battle, passez le acceptation_bundle.json résultant comme acceptance_floor de l'arène et mappez chaque cas_acceptation[].id sur un ou plusieurs identifiants de cas générateur dans le profil de campagne Battle via required_case_ids. Ces cas mappés sont le socle contractuel qui doit passer avant que les attaques par fuzz ou hors contrat puissent être créditées. Ne faites pas inventer les exigences par Battle.