Directives pour l’agent de codage

Le fichier AGENTS.md à la racine du dépôt constitue le contrat compact, toujours chargé, destiné aux assistants de codage IA. Cette page fournit des détails utiles pour certaines tâches, mais ne devrait pas consommer le budget de prompt de chaque session.

Ces règles s’appliquent quelle que soit la taille du modèle ou l’endroit où il s’exécute. Les profils d’invite compacts peuvent modifier la quantité de contexte chargée de manière anticipée ; ils n’affaiblissent pas les exigences en matière de sécurité, de confidentialité, d’autorisation ou de contribution.

Comment utiliser cette page

Commencez par la carte d’architecture et de contribution. Son tableau de chemins de modification oriente chaque tâche vers la documentation actuelle d’architecture, de fondation, de test, de sécurité et de maintenance. Revenez ici uniquement pour les sujets spécifiques aux agents ci-dessous.

Exemples de source unique de vérité

Aucune donnée d’état ne doit résider dans deux emplacements gérés indépendamment. Si une information existe déjà dans la configuration, le schéma, l’état d’exécution ou une définition générée, déterminez-la ou dérivez-la à partir de cette source au lieu de la copier dans un autre champ.

Avant d’ajouter un champ de structure, un champ de canal ou de handle, un champ de schéma ou une entrée de configuration, indiquez l’une de ces réponses :

1. “Ceci est la source de vérité, créée ici.” Indiquez ce qu’elle représente.
2. “La source de vérité est <path> ; cela la dupliquerait.” Résolvez-la depuis cet emplacement au moment de son utilisation.

Ne reportez pas le nettoyage de l’état dupliqué à une étape ultérieure. Un instantané réservé au redémarrage reste un état dupliqué.

Exemples interdits :

• un canal mettant en cache les utilisateurs autorisés tandis que la configuration active en est propriétaire ;
• une énumération et une liste de variantes maintenue à la main séparément ;
• un instantané de configuration clonant les champs que le runtime peut lire depuis la configuration active ;
• copie d’un identifiant de fournisseur dans un autre champ d’exécution.

Je vois que votre message est incomplet. Pourriez-vous fournir le texte à traduire ?

• resolveurs sous forme de closures sur Arc<RwLock<Config>> ;
• Config emprunté ou paramètres de configuration typés ;
• vues à la demande qui ne sont pas conservées au-delà de l’opération ;
• macros ou générateurs qui émettent plusieurs surfaces à partir d’une seule entrée.

Architecture et propriété

ZeroClaw est un runtime d’agent Rust-first, orienté traits. Les traits d’extension principaux se trouvent dans crates/zeroclaw-api/src/ :

• model_provider.rs (ModelProvider)
• channel.rs (Channel)
• tool.rs (Tool)
• memory_traits.rs (Memory)
• observability_traits.rs (Observer)
• runtime_traits.rs (RuntimeAdapter)
• peripherals_traits.rs (Peripheral)

Ne maintenez pas ici un autre inventaire de crates ou de dépôts. Utilisez Crates pour la propriété et la direction des dépendances, les membres du workspace dans le fichier Cargo.toml racine pour l’appartenance actuelle, et la carte d’architecture pour les chemins de modification des providers, canaux, outils, plugins, runtime et configuration.

Stabilité et risque

Les définitions des niveaux de stabilité et la politique de gestion des versions sont disponibles dans FND-001. Les fichiers AGENTS.md locaux aux composants et les manifestes du registre de plugins constituent le modèle de propriété cible. Tant que chaque composant n’en possède pas un, le tableau ci-dessous est la source canonique pour les attributions actuelles ; ne le copiez pas dans un autre agrégat géré manuellement.

Attributions de stabilité actuelles

Les composants stables suivent la politique de changements incompatibles. Les composants bêta peuvent introduire des changements incompatibles dans une version MINOR accompagnés de notes de journal des modifications. Les composants expérimentaux n’offrent aucune garantie de stabilité. Les niveaux sont promus, jamais rétrogradés, par une décision délibérée de l’équipe.

Le routage du risque lié aux changements est fondé sur les conséquences, et non sur le chemin. Utilisez le guide des labels des mainteneurs pour les définitions de référence : risk:low couvre la documentation, les fixtures et les métadonnées mécaniques sans effet sur la production, la compatibilité, le build, la release ou la gouvernance ; risk:medium couvre les travaux comportementaux ordinaires ; et risk:high couvre les limites concrètes liées à la confiance, aux identifiants, à la compatibilité, à la gouvernance ou à l’autorité de publication. domain:security est indépendant de risk:* et identifie une frontière de sécurité effective.

Une PR portant soit risk:high, soit domain:security nécessite une revue approfondie et deux approbations indépendantes de la Core Team avant sa fusion. En cas d’incertitude, classez le risque au niveau supérieur. Les éléments de preuve de validation et de retour arrière doivent correspondre au rayon d’impact réel, et pas seulement au nombre de lignes modifiées. Consultez Comment contribuer pour les modalités des PR et Tests pour la taxonomie de validation.

Découverte de compétences

Les compétences de l’assistant de codage appartenant au dépôt résident dans .claude/skills/. Inspectez les fichiers */SKILL.md disponibles et chargez uniquement la compétence correspondant à l’opération demandée. Ne maintenez pas un second catalogue de compétences dans cette page ; le répertoire est l’inventaire courant et chaque fichier de compétence possède son propre flux de travail.

Documents opérationnels protégés

Ces fichiers sont utilisés par des compétences ou des outils de développement. Ne les déplacez pas et ne les supprimez pas sans mettre à jour leurs consommateurs et les directives du dépôt.

Localisation et confidentialité

Le texte destiné aux utilisateurs et les règles de journalisation uniquement en anglais restent dans le fichier AGENTS.md racine. Le Wiki et la documentation interne des développeurs sont également uniquement en anglais. Pour les contrats complets, consultez Confidentialité et discipline relative aux PII et Documentation et traductions.

Pour aller plus loin

• Carte de l’architecture et des contributions
• Comment contribuer
• Règles de confidentialité et de PII
• Tests
• Vue d’ensemble de l’architecture
• Demandes de tirage de remplacement
• Politique d’audit