zehuichan/vibe-harness

Notes d'Agent

Les Notes d'Agent maintiennent le corpus de décisions petit et faisant autorité : chaque note enregistre la justification que le code et la documentation ne peuvent pas porter, et rien d'autre. Les règles de mise en page, de classes et le format du fichier se trouvent dans .agents/notes/README.md ; cette compétence gère le flux de travail. Jugez chaque note sémantiquement ; le nombre de mots et l'ancienneté sont des aides à la découverte, jamais des critères. Ceci est un guide, pas une liste de contrôle.

Décider si une note est nécessaire

N'écrivez ou ne mettez à jour une note que pour une justification de décision durable : pourquoi un design a gagné, ce qu'il a abandonné, quelles alternatives ont perdu et pourquoi, et quelle vérification le verrouille. N'en écrivez pas pour des modifications mécaniques ou locales, y compris les changements d'interface utilisateur locale, ou pour des faits qui appartiennent au code, à la documentation de l'API, aux README ou à un livre de recettes.

• Une proposition de travail futur substantiel va dans proposées/<classe>/ ; une décision prise dans le changement actuel va dans implémentées/<classe>/.
• Si une note active couvre déjà la décision, mettez-la à jour au lieu de créer un doublon.
• Un retournement de décision est une nouvelle note qui référence l'ancienne ; ne modifiez jamais une note pour en faire une décision différente.

Rédiger la note

1. Choisissez la classe dans le tableau de .agents/notes/README.md et nommez le fichier aaaa-mm-jj-sujet-titre.md, en utilisant la date à laquelle le sujet a été proposé pour la première fois.
2. Utilisez l'en-tête exact et le squelette de section du cycle de vie du README. ## Alternatives envisagées est obligatoire : enregistrez chaque alternative authentique et pourquoi elle a perdu ; n'inventez jamais d'alternatives.
3. Rédigez les notes implémentées au présent comme une réalité livrée : pas de plans, de listes de contrôle d'acceptation ou de « devrait ». Conservez la vérification qui verrouille le comportement et toute lacune de couverture nommée.
4. Liez les autres notes et documents avec des liens Markdown relatifs. Suivez norme-prose et couper-fuite-cot : pas de chorégraphie de révision, de citations de session ou de narration de changement en dehors des propres sections d'historique de changement de la note.

Vérifier le remplacement pour chaque nouvelle note

Avant de rédiger, parcourez l'arborescence active (proposées/, implémentées/, rejetées/) pour trouver des notes couvrant la même décision, le même mécanisme ou la même alternative rejetée. Classez chaque correspondance pendant la rédaction de la nouvelle note :

• Remplacement complet d'une note implémentée : consolidez (le nouveau propriétaire préserve chaque justification, alternative, conséquence, vérification et lacune de couverture unique, puis l'ancienne note est supprimée et les liens entrants sont réparés) ou archivez-la dans le même changement.
• Remplacement partiel : gardez les deux actives, référencez-les mutuellement et mettez à jour chaque fait qui reste d'actualité.
• Proposition obsolète : déplacez-la vers rejetées/ avec une raison honnête d'une ligne.
• Rejet obsolète : supprimez-la lorsqu'elle n'empêche plus une erreur plausible.

Ne reportez pas une correspondance connue à un audit ultérieur.

Classifier les notes existantes par valeur future

Lors d'un audit ou d'un élagage, appliquez ces résultats par cycle de vie :

• Implémentées, supprimer : notes qui ne décrivent que de petits ajustements d'interface utilisateur ou des changements purement mécaniques. Réparez ou supprimez les liens entrants. Les corrections de bogues locales, les changements de performances, les nouvelles capacités et les décisions substantielles de comportement ou de propriété ne sont pas qualifiés simplement parce que leur mise en œuvre était petite. Appliquez ce test avant de conserver ou d'archiver.
• Implémentées, garder actives : justifications, alternatives, garanties négatives, sémantiques durables ou filaires, limites de propriété, règles de sécurité ou conditions de réintroduction susceptibles de guider un changement futur. Classez la décision, pas la taille de sa mise en œuvre : un renommage mécanique peut toujours enregistrer une règle de dénomination ou de compatibilité durable.
• Implémentées, archiver : une décision historique substantielle qui est complète et peu susceptible de guider un travail futur, mais dont la justification mérite encore d'être conservée.
• Proposées, ne jamais archiver : gardez une proposition active ; si elle ne vaut plus la peine d'être poursuivie, rejetez-la avec une raison honnête.
• Rejetées, conserver uniquement comme garde-fou : conservez un rejet uniquement tant que la proposition perdante reste une erreur tentante et significative et que la note explique pourquoi elle perd ; sinon, supprimez-la.

N'archivez pas pour atteindre un quota. Inspectez chaque note dans le périmètre, classifiez les groupes analogues sous un seul principe et enregistrez les décisions véritablement limites pour le rapport.

Calibrage : une note sur le style d'un contrôle de barre latérale réduite est supprimée, quelle que soit sa longueur ; une note établissant que les sessions sont basées sur des événements, ou désignant le propriétaire unique d'un répertoire de stockage, reste active, quelle que soit sa taille ; une note enregistrant pourquoi deux packages ne doivent pas être fusionnés reste comme garde-fou tant que leur fusion reste tentante.

Archiver une note implémentée

1. Déplacez la note complète, avec toute traduction correspondante, de implémentées/<classe>/ vers archivées/<classe>/.
2. N'apportez aucune modification au corps. Insérez uniquement Archivée : AAAA-MM-JJ immédiatement en dessous de Statut : implémentée dans chaque fichier de langue, avec la même date.
3. Recherchez les liens entrants dans la prose active. Redirigez-les vers l'autorité actuelle, redirigez-les vers le chemin archivé uniquement lorsque l'instantané historique est intentionnellement cité, ou supprimez-les. Ne vérifiez ni ne réparez jamais les liens sortant de la note archivée.

Après l'archivage, ne modifiez, ne déplacez, ne traduisez, ne reformatez et ne supprimez jamais la note. Les notes archivées restent des cibles de lien valides mais ne font pas autorité pour le comportement actuel.

Valider et signaler

Exécutez commands.docs-check du profil et git diff --check, et confirmez que chaque lien relatif modifié se résout. Signalez les notes créées ou mises à jour, les notes conservées actives, supprimées, archivées ou rejetées, et chaque cas limite avec le résultat choisi.