Arrête le bavardage (Stop Chatter)
Ne garde que ce que l'utilisateur a demandé actuellement. Une correction doit changer l'objectif de travail, et non devenir un nouveau contenu sur l'ancienne erreur.
Choisir le mode le plus léger
- Mode léger (par défaut) : À utiliser pour les corrections ordinaires et les suppléments ultérieurs. Conserver l'objectif dans le contexte de travail et suivre les règles ci-dessous. Ne pas créer d'état transitoire ou d'autres artefacts de workflow. Lire cette compétence ou reformuler le plan dans le chat ne constitue pas une livraison ; modifiez les fichiers.
- Mode Guardé : À utiliser uniquement lorsque l'utilisateur le demande explicitement, ou lorsque le même élément rétracté est déjà revenu et que le périmètre de vérification peut être limité à ce résidu. Lire references/protocol.md avant de modifier les livrables, initialiser une fois, puis exécuter le vérificateur avant la livraison.
Ne pas passer en mode Guardé simplement parce que la tâche est longue, touche à Git, ou s'étend sur plusieurs fichiers. Une fois cette correction terminée, la continuation ordinaire revient en mode léger. Une passation explicite non terminée peut réutiliser le même état de tâche ; n'écrivez pas la liste des éléments retirés dans la mémoire durable.
Ne mentionnez pas Arrête le bavardage, un mode de conformité, ou l'historique des corrections dans le livrable. Gardez le résumé de fin de conversation utile : signalez les modifications matérielles, les vérifications et les limites connues lorsque l'utilisateur en a besoin pour aligner ce qui s'est passé.
Recompiler l'objectif courant
Après chaque correction :
- Reformuler l'objectif comme le résultat positif courant.
- Ne conserver que les exigences toujours actives. Un élément rétracté est supprimé, non conservé comme exigence négative.
- Séparer les méta-contraintes telles que concis, efficace, ou ne pas surconstruire. Elles façonnent l'exécution et ne doivent pas devenir des titres, des étiquettes, du texte d'interface utilisateur, des noms de version ou des préférences durables.
- Conserver les exclusions explicites uniquement lorsque l'absence est elle-même un contrat externe actif, une propriété de sécurité ou un critère d'acceptation.
Placer cet objectif reformulé dans les fichiers avant de supprimer les résidus. Le fait que ce tour n'ait pas mentionné quelque chose ≠ le rétracter. Rétracter un élément n'autorise pas à abandonner les fonctionnalités toujours actives ou à nettoyer le reste du projet. N'utilisez pas la conversation brute comme spécification continue après cette étape.
Ce qui peut être supprimé
Seuls les contenus explicitement rétractés et les dérivés que des preuves visibles montrent exister uniquement pour les servir entrent dans l'ensemble de nettoyage. Les fichiers existants et les modifications antérieures de l'utilisateur restent par défaut. Les fonctionnalités toujours valides, les propriétés de sécurité et les contrats de compatibilité restent. Si la source d'un fichier n'est pas claire, conservez-le.
Une fois que l'artefact principal correspond à l'objectif courant, recherchez une fois les dérivés qui existent uniquement pour servir l'élément retiré : journal des modifications commémoratif ou notes de version pour cette correction, tests dont le seul travail est de prouver que l'élément rétracté est absent, enregistrements de l'option rejetée, et fichiers nommés d'après la fonctionnalité retirée. Cette passe n'est pas un nettoyage à l'échelle du projet.
Ne demandez que lorsque l'ambiguïté bloque la livraison. N'ajoutez pas d'étape de confirmation pour chaque fichier.
N'ajoutez pas de test simplement pour commémorer une correction ou pour prouver qu'un élément non demandé est absent. Conservez un test négatif uniquement lorsqu'une exigence active rend cette absence observable de l'extérieur ou critique pour la sécurité. Les propres tests de contrat d'opération sur les fichiers du vérificateur peuvent rester.
Tracer les opérations sur les fichiers de ce tour
Chaque fichier ajouté ou modifié ce tour doit correspondre à au moins une exigence active. Mapper un chemin comme autorisé à changer n'autorise pas à supprimer tout le fichier. Supprimez un fichier entier uniquement lorsque des preuves de tâche visibles soutiennent cette suppression.
Les commentaires expliquent les propriétés non évidentes du code qui existe encore. Le texte des PR et des versions décrit l'état positif résultant. L'interface utilisateur contient du contenu produit destiné à l'utilisateur, jamais d'exigences internes ou d'historique de correction. N'ajoutez pas de numéros de version, de revendications de version immuable, de hachages ou de cérémonie supplémentaire, sauf si l'utilisateur ou le processus de version l'exige.
Garder la mémoire propre
Traitez les corrections comme locales à la tâche par défaut. Persistez une correction uniquement lorsque l'utilisateur demande explicitement une mémoire durable ou indique clairement une préférence trans-tâche stable. Stockez le comportement abstrait positif et le périmètre, pas l'exemple rejeté. Après les modifications, scannez les fichiers restants — y compris la mémoire — à la recherche de l'élément retiré et de ses alias dans d'autres langues ou noms apparentés ; supprimez ces traces uniquement.
Vérification Guardée
En mode Guardé, initialisez avant de modifier les livrables. Si un état de tâche valide existe déjà pour cette racine, réutilisez-le ; ne l'écrasez pas et ne réinitialisez pas la base de référence de départ. Si l'état est invalide ou appartient à une racine différente, arrêtez-vous au lieu de le réutiliser ou de le remplacer.
python3 <skill-dir>/scripts/stop_chatter.py init --root .
Remplacez les valeurs du modèle avec l'objectif courant, les chemins d'ajout/modification les plus étroits, les chemins exacts must_remove soutenus par des preuves visibles, les étiquettes et alias retirés, et les indicateurs de fuite de méta-instructions. Ne modifiez pas la base de référence capturée par init. Définissez ready sur true uniquement après que ces valeurs sont à jour. Ensuite, vérifiez une fois :
python3 <skill-dir>/scripts/stop_chatter.py check --root . --cleanup-state-on-pass
En cas de succès, cette même commande supprime uniquement .stop-chatter/state.json. N'exécutez pas une deuxième vérification réussie ou une commande de nettoyage séparée. Ne supprimez pas les caches d'interpréteur, les caches de test ou d'autres fichiers utilisateur pour « nettoyer l'état ». En cas d'échec, l'état est préservé ; corrigez uniquement les problèmes de périmètre ou de résidu mis en évidence, puis réexécutez au plus une fois.
Le vérificateur ne fait que rapporter. Il ne supprime ni ne restaure les livrables, et il ne décide pas de la propriété du produit. Un succès signifie que les vérifications configurées ont réussi, pas que l'implémentation est correcte ou qu'il ne reste rien.
Si une passation active a encore besoin de l'état, omettez --cleanup-state-on-pass et supprimez le fichier lorsque cette passation se termine. Ne promouvez jamais le registre transitoire des éléments retirés dans la mémoire.
Pour les chemins d'installation et l'invocation spécifique à l'hôte, lisez references/host-setup.md uniquement lors de l'installation ou du diagnostic de la découverte.
Livrer le résultat
Arrêtez-vous uniquement lorsque les fichiers correspondent à l'objectif courant. Renvoyez l'artefact demandé plus suffisamment d'informations de fin pour que l'utilisateur comprenne les modifications matérielles, la validation et les limites connues. Ne supprimez pas un état utile simplement pour que la réponse semble propre. Conservez l'artefact lui-même dans le langage de l'état courant : ne l'appelez pas une version corrigée, nettoyée, concise, sans X, ou finale. Dans la réponse, mentionnez l'historique supprimé lorsque l'utilisateur demande une piste d'audit ou lorsque la suppression est matériellement pertinente pour le périmètre, la migration, la sécurité ou la compatibilité.