Registro de harnesses

O registro de harnesses é o inventário de adaptadores que serve como fonte de verdade para a CLI, a documentação, os testes de fixtures e a validação dos pins de convenção. A fonte em tempo de execução é src/apothem/lib/harness_registry.py; cada linha abaixo é rastreável até esse registro, até o capabilities.yml de cada adaptador e até o STANDARD-CONVENTION-PIN.md de cada adaptador.

Matriz do registroCopy Anchor Link

Suporte a cohorts de payloadCopy Anchor Link

Os valores de status são native, converted, support-tree, profile-projected, unsupported, not-applicable e discovery-pending.

Um cohort converted é reescrito no formato próprio do harness, e alguns campos de origem não têm lugar nele. Para cada cohort convertido de comandos, agentes ou regras, o capabilities.yml do adaptador carrega um mapa conversion_losses que informa o que acontece com cada campo de frontmatter de origem:

Um teste renderiza cada arquivo convertido e confere os mapas contra a saída.

A tabela omite as células que o registro marca como not-applicable: restrições de ferramentas em todos os harnesses, exceto Kimi Code (discovery-pending) e GLM (Z.ai) (unsupported), e memória em Claude Code, CodeBuddy, Codex, Hermes, Kiro, Open-Claw, OpenCode e Qwen Code.

Raízes compartilhadasCopy Anchor Link

Alguns alvos de instalação são carregados por harnesses diferentes daquele que os grava. O registro anota cada um desses caminhos em SHARED_ROOTS com um proprietário registrado (o adaptador para o qual o fornecedor documenta o caminho), os coinstaladores que gravam os mesmos arquivos nele e os leitores cuja documentação do fornecedor o carrega por padrão, além das páginas do fornecedor que o mostram e da data em que foram obtidas.

Um caminho com coinstaladores é uma pasta de nível de usuário no diretório pessoal que várias instalações gravam com os mesmos bytes. Uma máquina com apenas o Cursor instalado não tem um Codex para gravar ~/.agents/skills/, de modo que cada instalação que nomeia a pasta a grava, e o livro-razão de instalação conta as instalações que a usam. O proprietário de referência é o proprietário registrado enquanto ele usa a pasta e, caso contrário, a instalação mais antiga que a usa; nada muda quando o proprietário registrado é desinstalado. Uma desinstalação remove a pasta somente quando nenhuma outra instalação ainda a usa (veja uninstall). Instalar um leitor não coloca nenhum arquivo na pasta; instalar o proprietário ou um coinstalador coloca o conteúdo do Apothem diante de cada leitor.

~/.config/apothem/rules/ e ~/.config/apothem/templates/ contêm os arquivos que as skills e os arquivos de instruções do próprio Apothem citam. Nenhuma outra ferramenta os carrega, então eles não têm leitores nem páginas do fornecedor. CodeBuddy, Kiro e Trae também gravam uma pasta de skills própria (~/.codebuddy/skills/, ~/.kiro/skills/ e ~/.trae/skills/); somente essa ferramenta a carrega, então ela não é uma raiz compartilhada.

Um leitor só é listado onde a documentação do seu fornecedor mostra um carregamento padrão desse caminho exato. Um leitor traz uma condição, e a nota de instalação a repete: Open-Claw indexa ~/.agents/skills/ somente sob o seu diretório de estado padrão (ele ignora a pasta quando OPENCLAW_STATE_DIR aponta para outro lugar). A documentação do Cursor lista ~/.codex/agents/ como uma pasta de compatibilidade com o Codex, mas não diz quais formatos de arquivo o Cursor interpreta ali, e uma instalação do Codex grava arquivos TOML, então não está confirmado se o Cursor lê esses auxiliares. A instalação do Cursor também grava sua própria cópia <project>/.cursor/agents/ dos auxiliares, que a precedência do fornecedor classifica acima das pastas que ele importa, de modo que, em um projeto instalado, a cópia nativa prevalece sobre a de ~/.claude/agents/.

Algumas ferramentas deliberadamente não são leitoras de ~/.agents/skills/: a documentação do Antigravity, do CodeBuddy, do Kiro e do Trae não diz que elas a carregam por padrão (o Trae carrega a pasta .agents/skills/ do projeto somente depois que uma configuração é ativada), e é por isso que CodeBuddy, Kiro e Trae recebem uma pasta de skills própria. A documentação do Hermes a nomeia apenas como um valor de exemplo para skills.external_dirs. O GitHub Copilot não é leitor de ~/.claude/agents/: a documentação do VS Code lista essa pasta para o agente Anthropic Claude, não para o agente que o GitHub Copilot executa.

O bloco do Apothem que um proprietário grava em um arquivo de instruções compartilhado não nomeia nenhuma ferramenta específica como sua leitora. tests/unit/test_shared_roots.py falha quando os adaptadores que gravam um alvo do registro não são exatamente o seu proprietário e os seus coinstaladores, e quando um alvo do registro cujo nome é o de um arquivo de instruções entre ferramentas (AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md) não tem um proprietário declarado. A única exceção é ~/.codex/AGENTS.md, cujo carregamento nenhum outro harness registrado documenta.

Hooks de validaçãoCopy Anchor Link

O registro permanece sincronizado por meio destas verificações:

Referência gerada de adaptadores de harnessCopy Anchor Link