Registre des environnements

Le registre des environnements est l'inventaire des adaptateurs qui fait foi, utilisé par la CLI, la documentation, les tests de fixtures et la validation des épinglages de convention. La source d'exécution est src/apothem/lib/harness_registry.py ; chaque ligne ci-dessous est traçable jusqu'à ce registre, jusqu'au capabilities.yml propre à chaque adaptateur et jusqu'au STANDARD-CONVENTION-PIN.md de chaque adaptateur.

Matrice du registreCopy Anchor Link

Prise en charge des cohortes de charge utileCopy Anchor Link

Les valeurs d'état sont native, converted, support-tree, profile-projected, unsupported, not-applicable et discovery-pending.

Une cohorte converted est réécrite dans le format propre à l'environnement, et certains champs source n'y ont pas leur place. Pour chaque cohorte convertie de commandes, d'agents ou de règles, le capabilities.yml de l'adaptateur porte un mappage conversion_losses qui indique ce qu'il advient de chaque champ de frontmatter source :

Un test rend chaque fichier converti et vérifie les mappages par rapport à la sortie.

Le tableau omet les cellules que le registre marque not-applicable : les restrictions d'outils sur chaque environnement sauf Kimi Code (discovery-pending) et GLM (Z.ai) (unsupported), et la mémoire sur Claude Code, CodeBuddy, Codex, Hermes, Kiro, Open-Claw, OpenCode et Qwen Code.

Racines partagéesCopy Anchor Link

Certaines cibles d'installation sont chargées par d'autres environnements que celui qui les écrit. Le registre consigne chacun de ces chemins dans SHARED_ROOTS avec un unique propriétaire enregistré (l'adaptateur pour lequel l'éditeur documente le chemin), les co-installateurs qui y écrivent les mêmes fichiers et les lecteurs dont la documentation éditeur le charge par défaut, ainsi que les pages de l'éditeur qui le montrent et la date à laquelle elles ont été récupérées.

Un chemin avec des co-installateurs est un dossier de niveau utilisateur dans le répertoire personnel que plusieurs installations écrivent avec les mêmes octets. Une machine sur laquelle seul Cursor est installé n'a pas de Codex pour écrire ~/.agents/skills/, de sorte que chaque installation qui nomme le dossier l'écrit, et le journal d'installation compte les installations qui l'utilisent. Le propriétaire de référence est le propriétaire enregistré tant qu'il utilise le dossier, et sinon la plus ancienne installation qui l'utilise ; rien ne bouge lorsque le propriétaire enregistré est désinstallé. Une désinstallation ne supprime le dossier que lorsqu'aucune autre installation ne l'utilise encore (voir uninstall). Installer un lecteur ne place aucun fichier dans le dossier ; installer le propriétaire ou un co-installateur place le contenu d'Apothem devant chaque lecteur.

~/.config/apothem/rules/ et ~/.config/apothem/templates/ contiennent les fichiers que citent les skills et les fichiers d'instructions propres à Apothem. Aucun autre outil ne les charge, ils n'ont donc ni lecteurs ni pages d'éditeur. CodeBuddy, Kiro et Trae écrivent aussi un dossier de skills qui leur est propre (~/.codebuddy/skills/, ~/.kiro/skills/ et ~/.trae/skills/) ; seul cet outil le charge, ce n'est donc pas une racine partagée.

Un lecteur n'est listé que là où sa documentation éditeur montre un chargement par défaut de ce chemin exact. Un lecteur est soumis à une condition, que la note d'installation répète : Open-Claw n'indexe ~/.agents/skills/ que sous son répertoire d'état par défaut (il ignore le dossier lorsque OPENCLAW_STATE_DIR pointe ailleurs). La documentation de Cursor liste ~/.codex/agents/ comme dossier de compatibilité Codex mais ne dit pas quels formats de fichier Cursor y analyse, et une installation Codex écrit des fichiers TOML, de sorte qu'il n'est pas confirmé que Cursor lise ces auxiliaires. L'installation Cursor écrit aussi sa propre copie <project>/.cursor/agents/ des auxiliaires, que l'ordre de priorité de l'éditeur place au-dessus des dossiers qu'il importe, de sorte que dans un projet installé, la copie native l'emporte sur celle issue de ~/.claude/agents/.

Certains outils ne sont délibérément pas lecteurs de ~/.agents/skills/ : la documentation d'Antigravity, de CodeBuddy, de Kiro et de Trae ne dit pas qu'ils le chargent par défaut (Trae ne charge le dossier .agents/skills/ du projet qu'après l'activation d'un réglage), ce qui explique pourquoi CodeBuddy, Kiro et Trae reçoivent un dossier de skills qui leur est propre. La documentation d'Hermes ne le nomme que comme valeur d'exemple pour skills.external_dirs. GitHub Copilot n'est pas lecteur de ~/.claude/agents/ : la documentation de VS Code liste ce dossier pour l'agent Claude d'Anthropic, pas pour l'agent qu'exécute GitHub Copilot.

Le bloc Apothem qu'un propriétaire écrit dans un fichier d'instructions partagé ne désigne aucun outil unique comme son lecteur. tests/unit/test_shared_roots.py échoue lorsque les adaptateurs qui écrivent une cible du registre ne sont pas exactement son propriétaire et ses co-installateurs, et lorsqu'une cible du registre nommée comme un fichier d'instructions inter-outils (AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md) n'a aucun propriétaire déclaré. La seule exception est ~/.codex/AGENTS.md, dont aucun autre environnement enregistré ne documente le chargement.

Hooks de validationCopy Anchor Link

Le registre reste synchronisé grâce à ces vérifications :

Référence générée des adaptateurs d'environnementCopy Anchor Link