Reçu de bogue

Sortie de clôture obligatoire

Pour chaque décision de clôture de bogue ou d'incident, retournez le reçu complet ci-dessous comme résultat entier présenté à l'utilisateur, même si l'utilisateur demande une réponse concise ou ne nomme pas ce format. La concision raccourcit les valeurs des champs ; elle ne supprime ni ne renomme jamais une ligne. Ne remplacez pas le reçu par du texte descriptif.

BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED

Problem    <observed defect and intended behavior>
Baseline   <failing interaction or command and decisive result; or not run>
Root cause <proven mechanism; or unproven hypothesis>
Change     <responsible change; or none>
Proof      <supplied or executed check: result; include every decisive layer>
Gaps       <none; or exact missing proof and single next experiment/package>
Source     executed now | supplied | mixed

Utilisez not run, unproven ou none explicitement. Ne supprimez jamais une ligne pour que le reçu semble complet.

Établir la limite des preuves

Avant de modifier, enregistrez le problème observé, le comportement attendu, la vérification directe la plus solide et la source des preuves : executed now, supplied ou mixed. Ne laissez jamais entendre que les preuves fournies ont été exécutées lors de l'exécution actuelle.

Reproduisez la défaillance avec la vérification la plus étroite et sûre possible. Si la reproduction n'est pas disponible, conservez les preuves obtenues et limitez le résultat à PARTIAL ou BLOCKED.

Tracer et réparer

1. Suivez le chemin du propriétaire en direct, de l'entrée au symptôme.
2. Séparez les faits observés, les inférences bornées et les lacunes.
3. Exigez un emplacement concret ou une transition d'exécution avant de nommer la cause racine.
4. Apportez la modification responsable la plus petite ; évitez le nettoyage sans rapport, les nouvelles tentatives, les rétrofallbacks silencieux et les exceptions spécifiques à la fixture.

Ne convertissez pas un correctif plausible, un journal périmé, une lecture de source ou une compilation réussie en preuve du comportement visible par l'utilisateur.

Fermer la boucle de preuve

Exécutez uniquement les vérifications requises par le contrat affecté :

• reproduction originale ou vérification d'acceptation directe ;
• vérification négative la plus proche ou test de régression ;
• gate de compilation ou d'intégration affectée ;
• chemin d'exécution, d'UI, d'API, de persistance, de concurrence ou d'exécution réel lorsque la réclamation traverse cette limite.

Utilisez ces limites décisives :

Attribuer le statut

• VERIFIED : baseline observée, cause concrète, modification responsable, toutes les vérifications déclarées réussies, aucune lacune matérielle.
• PARTIAL : des preuves utiles existent, mais une couche de preuve requise est manquante ou inconclusive.
• BLOCKED : une condition externe spécifique empêche la reproduction, la réparation ou la preuve.

Pour PARTIAL ou BLOCKED, nommez la seule expérience minimale ou le package de preuves corréglées qui ferme la lacune décisive. N'inventez jamais une commande, observation, décompte, emplacement ou résultat.

Pour un reçu lisible par machine ou une intégration CI, consultez references/receipt-contract.md et conformez-vous à ses champs JSON et invariants de statut.

Lorsqu'un artefact JSON est demandé, partez de assets/receipt.template.json, écrivez-le dans un chemin appartenant à la tâche et validez-le avec node scripts/validate-receipt.mjs <receipt.json> depuis le répertoire de cette skill. Ne commitez pas le reçu généré sauf si l'utilisateur le demande.

Source et licence

Publié à l'origine sur https://github.com/lMysticl/bug-receipt sous la licence MIT.