Bug Receipt
Sortie obligatoire de clôture
Pour chaque décision de clôture de bug ou d'incident, retournez le reçu complet ci-dessous comme résultat entier visible par l'utilisateur, même lorsque 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 de la prose.
BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED
Problem <défaut observé et comportement attendu>
Baseline <interaction ou commande échouée et résultat décisif ; ou non exécuté>
Root cause <mécanisme prouvé ; ou hypothèse non prouvée>
Change <modification responsable ; ou aucune>
Proof <vérification fournie ou exécutée : résultat ; inclure chaque couche décisive>
Gaps <aucune ; ou preuve manquante exacte et unique prochaine expérience/package>
Source exécuté maintenant | fourni | mixte
Utilisez non exécuté, non prouvé ou aucune explicitement. N'omettez jamais une ligne pour donner l'impression que le reçu est complet.
Établir la frontière des preuves
Avant de modifier, enregistrez le problème observé, le comportement attendu, la vérification directe la plus solide et la source de la preuve : exécuté maintenant, fourni ou mixte. Ne sous-entendez jamais que la preuve fournie a été exécutée lors de l'exécution en cours.
Gardez les preuves minimales en matière de confidentialité. Occultez les identifiants, jetons, cookies, données personnelles, URL privées et charges utiles sensibles ; ne conservez que les identifiants et extraits nécessaires pour reproduire ou corréler la panne.
Reproduisez la panne avec la vérification sûre la plus étroite lorsque c'est possible. Si la reproduction n'est pas disponible, conservez la preuve obtenue et plafonnez le résultat à PARTIAL ou BLOCKED.
Tracer et réparer
- Suivez le chemin du propriétaire en direct, de l'entrée au symptôme.
- Séparez les faits observés, les inférences limitées et les lacunes.
- Exigez un emplacement concret ou une transition d'exécution avant de nommer la cause racine.
- Effectuez la modification responsable la plus petite ; évitez les nettoyages non liés, les nouvelles tentatives, les replis silencieux et les exceptions spécifiques à un montage.
Ne convertissez pas un correctif plausible, un journal obsolète, une lecture de source ou une construction 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 ou de régression la plus proche ;
- passerelle de construction ou d'intégration affectée ;
- chemin réel UI, API, persistance, concurrence ou runtime lorsque l'affirmation franchit cette frontière.
Utilisez ces frontières décisives :
| Surface | Preuve directe requise |
|---|---|
| Logique ou test échoué | L'entrée échouée originale ou le test ciblé passe maintenant |
| Comportement UI | Interaction réelle plus observation console et réseau pertinente |
| API ou intégration | Requête, réponse et comportement du service responsable |
| Persistance | Aller-retour écriture/lecture ou rechargement à travers le chemin du propriétaire réel |
| Concurrence ou cycle de vie | Déclenchement concurrent répété ; succès zéro ou un ; preuve de ligne affectée et de transaction ; invariant final |
| Bloqueur intersystème | Une requête/réponse échouée assainie avec horodatage ou ID de requête, journaux de périphérie et d'application, et journaux du fournisseur d'identité lorsque la trace atteint ce propriétaire |
Attribuer le statut
VERIFIED: base de référence 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 non concluante.BLOCKED: une condition externe spécifique empêche la reproduction, la réparation ou la preuve.
Pour PARTIAL ou BLOCKED, nommez l'expérience minimale unique ou le package de preuves corrélé qui comble la lacune décisive. N'inventez jamais de commande, d'observation, de nombre, d'emplacement ou de résultat.
Pour un reçu lisible par machine ou une intégration CI, lisez references/receipt-contract.md et conformez-vous à ses champs JSON, son marqueur de source de preuve, sa règle de compatibilité et ses 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 ce répertoire de compétence. Ne validez pas le reçu généré à moins que l'utilisateur ne le demande.