Postura agnóstica de host

Como o Apothem alcança uma postura agnóstica de host via o perfil compartilhado e os adaptadores de ferramenta.

O Apothem é projetado em torno de um único princípio: sua configuração de governança deve sobreviver a qualquer runtime individual de assistente. O perfil compartilhado do Apothem é um arquivo YAML validado por schema em ~/.config/apothem/profile.yaml ou --profile PATH; os cohorts empacotados do Apothem fornecem comandos, regras, skills, hooks, templates, statuslines, output styles e definições de delegação. Adaptadores por ferramenta sob src/apothem/harnesses/<harness>/ traduzem essas entradas para o formato que cada ferramenta suportada requer:

Claude Code, Cursor, Gemini CLI, GitHub Copilot, Codex, Windsurf,
OpenCode, Antigravity, Open-Claw, Hermes, Qwen Code,
CodeBuddy, Kiro, Trae, Zed

A ideia central

A agnosticidade de host significa que sua intenção — quem você é, como você quer que os assistentes se comportem, as regras que eles devem seguir — vive em um único lugar que nenhuma ferramenta individual possui. As ferramentas são consumidoras intercambiáveis dessa intenção. Quando um novo assistente chega, você o adota adicionando um adaptador, não reescrevendo sua configuração. Quando um assistente que você usava cai em desuso, você o descarta sem perder a governança que construiu. O perfil é o ativo; a ferramenta é um alvo de renderização. Uma ferramenta pode ser usada para programar, conversar, trabalhar em conjunto, pesquisar ou escrever — o perfil é agnóstico quanto à finalidade da ferramenta.

Esta é uma inversão deliberada. O caminho comum é configurar cada ferramenta diretamente, o que torna seu investimento refém da longevidade e do formato daquela ferramenta. O Apothem trata a configuração como capital portátil e a ferramenta como um terminal descartável.

O problema

Toda ferramenta tem seu próprio formato de configuração:

Claude Code:    CLAUDE.md + settings.json
Cursor:         .cursor/rules/*.mdc
GitHub Copilot: .github/copilot-instructions.md
Windsurf:       .devin/rules/
Codex:          AGENTS.md

Sem o Apothem, você mantém N arquivos de configuração separados que divergem ao longo do tempo.

A solução do Apothem

One shared Apothem profile (YAML) + packaged cohorts
    identity.name
    preferences.style
    rules[]
         |
         v
    Adapter layer (HarnessAdapter protocol — src/apothem/harnesses/<harness>/)
         |
         +---> Claude Code adapter   -> ~/.claude/
         +---> Cursor adapter        -> .cursor/rules/*.mdc
         +---> Copilot adapter       -> .github/copilot-instructions.md
         +---> Windsurf adapter      -> .devin/rules/
         +---> ...

Você edita o perfil compartilhado uma vez e, em seguida, executa apothem update --harness <name> ou apothem update --harness all --project <path> para propagar a mudança. apothem harnesses list imprime o conjunto registrado.

Por que "apothem"

O nome codifica a arquitetura. Em geometria, um apótema é a perpendicular do centro de um polígono regular ao ponto médio de um de seus lados — a única distância do núcleo até cada aresta, idêntica em todas as direções. Esse é o design: um perfil compartilhado no centro, dezessete ferramentas equidistantes no perímetro, cada materialização à mesma distância da fonte da verdade. O núcleo não muda quando uma aresta muda; as arestas compartilham uma única relação com o núcleo. A divergência é estruturalmente impossível.

Garantias de portabilidade

Regras marcadas como portability: universal têm tradução garantida para toda ferramenta suportada. Regras marcadas como portability: project-specific podem exigir documentação de override por ferramenta no corpo da regra.