Notes d'Agent

Lisez les règles des Notes d'Agent avant d'agir. Les Notes d'Agent préservent les décisions revisitables ; elles ne remplacent pas le code courant, la documentation de référence, les problèmes ou la discussion des PR.

Classer le changement

Chaque PR rédigée par un humain déclare une Note d'Agent ou une raison explicite N/A. Les PR rédigées par l'automatisation (workflows de repository et Dependabot) sont exemptées de cette exigence de métadonnées, non de la validation normale.

Le nom de classe désigne le sujet de la décision ; il ne force pas chaque note à commencer comme proposée. Choisissez le cycle de vie initial selon que la cible a besoin d'un accord humain avant implémentation et selon que la décision a déjà été déployée.

• Utilisez N/A pour une modification locale ou mécanique qui restaure un contrat existant sans compromis durable.
• Rédigez une note bug-fix implémentée dans la même PR quand la réparation change l'échec, la compatibilité, la sécurité, la concurrence, l'atomicité, le cycle de vie ou un autre choix susceptible d'être annulé sans sa cause profonde.
• Une petite décision complétée de test ou autre decision durable qui ne répond pas au seuil Spec-first peut entrer sa classe propriétaire comme implémentée.
• Commencez le travail substantiel sur les features, l'architecture, les processus et les simplifications par une Spec proposée.
• Commencez n'importe quelle classe comme proposée quand le comportement, la propriété, les CA, les alternatives ou les risques ont besoin d'un accord humain avant implémentation.

Vérifier l'arbre actif d'abord

Cherchez par domaines, noms de mécanisme, chemins et alternatives rejetées. Classifiez le résultat comme nouveau, même propriétaire, supersession partielle ou supersession complète. Mettez à jour le propriétaire existant quand possible. Les supersessions partielles restent actives et cross-liées. La supersession complète doit préserver chaque rationale unique, alternative, conséquence et fait de vérification ; supprimer une ancienne note demande une approbation humaine explicite.

Il n'y a pas encore de cycle de vie archived/. Ne pas archiver par âge, statut de fusion, code déplacé ou formulation obsolète. Gardez les propriétaires courants factuels ; gardez les notes complètement supercédées actives et cross-liées jusqu'à ce qu'un design d'archive séparé et approuvé fournisse une recherche first-active, la découverte successeur et les matching gates.

Pile Spec-first

1. Créez la branche Spec du bas et la note bilingue proposée.
2. Donnez aux critères d'acceptation observables des IDs AC contigus et un propriétaire de vérification.
3. Créez la Spec PR via gh-create-pr ; Spec PR est This PR.
4. Inspectez les reviews GitHub et demandez une review APPROVED explicite dont l'id commit égale le Spec head courant. L'approbation ne demande pas de fusion.
5. Après Approbation, créez les couches d'implémentation avec gh-stack. Chaque PR lie la Spec et liste sa couverture AC.
6. Un changement matériel de comportement, propriété, CA, alternative ou risque appartient à la branche Spec. Rebase upstack et demandez l'Approbation à nouveau.
7. La couche finale déplace les trois artefacts de paire vers implemented/, réécrit la réalité déployée au temps présent et mappe chaque CA à une preuve réelle.

Avant de décider l'étape 7, lancez gh stack view --json. Si elle sort 2, suivez la procédure de découverte à distance de la skill gh-stack ; les métadonnées locales manquantes ne prouvent pas que la PR est autonome. Pour une pile, inspectez la couche courant et chaque PR d'implémentation downstack, puis aggrégez seulement les CA soutenus par une vérification réellement exécutée. Les couches intermédiaires gardent la note proposée ; seule la couche finale dont la preuve cumulative couvre chaque CA approuvé effectue la transition. N'inférez pas la finalité de l'ordre des branches seul.

Après gh stack sync, relancez pnpm change:scope sur chaque base live PR et relancez seulement les vérifications invalidées par le scope réécrit. Une sync réussie n'est pas une validation.

Rejet

Seule une décision humaine explicite déplace une note proposée vers rejet. La discussion, le silence et CHANGES_REQUESTED ne le font pas. Préservez une note rejetée seulement quand sa preuve empêche une erreur répétée plausible ; sinon fermez l'exploration non fusionnée sans ajouter de bruit au repository. Arrêtez et fermez toute couche d'implémentation après rejet.

Validation

Pour un mouvement de cycle de vie, lancez pnpm agent-notes:check-transition --base <verified-spec-ref> en plus de pnpm docs:check-notes, l'écriture/vérification scoped pairing, pnpm docs:check et git diff --check. Le vérificateur de transition valide la direction déclarée et le mapping AC ; il ne décide jamais du rejet ou la complétude de pile. Rapportez seulement la preuve réellement exécutée.