Registro de entornos

El registro de entornos es el inventario de adaptadores que sirve como fuente de verdad para la CLI, la documentación, las pruebas de fixtures y la validación de los anclajes de convención. La fuente en tiempo de ejecución es src/apothem/lib/harness_registry.py; cada fila de abajo es rastreable hasta ese registro, hasta el capabilities.yml de cada adaptador y hasta el STANDARD-CONVENTION-PIN.md de cada adaptador.

Matriz del registroCopy Anchor Link

Soporte de cohortes de carga útilCopy Anchor Link

Los valores de estado son native, converted, support-tree, profile-projected, unsupported, not-applicable y discovery-pending.

Una cohorte converted se reescribe en el formato propio del entorno, y algunos campos de origen no tienen cabida en él. Para cada cohorte convertida de comandos, agentes o reglas, el capabilities.yml del adaptador lleva un mapa conversion_losses que indica qué ocurre con cada campo de frontmatter de origen:

Una prueba renderiza cada archivo convertido y comprueba los mapas contra la salida.

La tabla omite las celdas que el registro marca como not-applicable: las restricciones de herramientas en todos los entornos excepto Kimi Code (discovery-pending) y GLM (Z.ai) (unsupported), y la memoria en Claude Code, CodeBuddy, Codex, Hermes, Kiro, Open-Claw, OpenCode y Qwen Code.

Raíces compartidasCopy Anchor Link

Algunos destinos de instalación los cargan entornos distintos del que los escribe. El registro anota cada una de esas rutas en SHARED_ROOTS con un único propietario registrado (el adaptador para el que el proveedor documenta la ruta), los coinstaladores que escriben en ella los mismos archivos y los lectores cuya documentación de proveedor la carga por defecto, además de las páginas del proveedor que lo muestran y la fecha en que se consultaron.

Una ruta con coinstaladores es una carpeta de nivel de usuario en el directorio personal que varias instalaciones escriben con los mismos bytes. Una máquina con solo Cursor instalado no tiene ningún Codex que escriba ~/.agents/skills/, así que cada instalación que nombra la carpeta la escribe, y el registro de instalación cuenta las instalaciones que la usan. El propietario de referencia es el propietario registrado mientras use la carpeta y, si no, la instalación más antigua que la use; nada se mueve cuando se desinstala el propietario registrado. Una desinstalación elimina la carpeta solo cuando ninguna otra instalación la sigue usando (consulta uninstall). Instalar un lector no pone ningún archivo en la carpeta; instalar el propietario o un coinstalador pone el contenido de Apothem delante de cada lector.

~/.config/apothem/rules/ y ~/.config/apothem/templates/ contienen los archivos que citan las propias skills y archivos de instrucciones de Apothem. Ninguna otra herramienta los carga, así que no tienen lectores ni páginas de proveedor. CodeBuddy, Kiro y Trae también escriben una carpeta de skills propia (~/.codebuddy/skills/, ~/.kiro/skills/ y ~/.trae/skills/); solo esa herramienta la carga, así que no es una raíz compartida.

Un lector solo figura donde la documentación de su proveedor muestra una carga por defecto de esa ruta exacta. Un lector lleva una condición, y la nota de instalación la repite: Open-Claw indexa ~/.agents/skills/ solo bajo su directorio de estado predeterminado (omite la carpeta cuando OPENCLAW_STATE_DIR apunta a otro lugar). La documentación de Cursor enumera ~/.codex/agents/ como carpeta de compatibilidad con Codex, pero no dice qué formatos de archivo analiza Cursor allí, y una instalación de Codex escribe archivos TOML, así que no está confirmado si Cursor lee esos asistentes. La instalación de Cursor también escribe su propia copia de los asistentes en <project>/.cursor/agents/, que la precedencia del proveedor sitúa por encima de las carpetas que importa, así que en un proyecto instalado la copia nativa sustituye a la de ~/.claude/agents/.

Algunas herramientas no son lectoras de ~/.agents/skills/ de forma deliberada: la documentación de Antigravity, CodeBuddy, Kiro y Trae no dice que la carguen por defecto (Trae carga la carpeta .agents/skills/ del proyecto solo después de activar un ajuste), y por eso CodeBuddy, Kiro y Trae reciben una carpeta de skills propia. La documentación de Hermes la nombra solo como valor de ejemplo de skills.external_dirs. GitHub Copilot no es lector de ~/.claude/agents/: la documentación de VS Code enumera esa carpeta para el agente Claude de Anthropic, no para el agente que ejecuta GitHub Copilot.

El bloque de Apothem que un propietario escribe en un archivo de instrucciones compartido no nombra ninguna herramienta concreta como su lectora. tests/unit/test_shared_roots.py falla cuando los adaptadores que escriben un destino del registro no son exactamente su propietario y sus coinstaladores, y cuando un destino del registro con nombre de archivo de instrucciones entre herramientas (AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md) no tiene un propietario declarado. La única excepción es ~/.codex/AGENTS.md, cuya carga no documenta ningún otro entorno registrado.

Hooks de validaciónCopy Anchor Link

El registro se mantiene sincronizado mediante estas comprobaciones:

Referencia generada de adaptadores de entornoCopy Anchor Link