Postura agnóstica de host

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 harness sob src/apothem/harnesses/<harness>/ traduzem essas entradas para o formato que cada harness suportado requer:

Claude Code, Cursor, Gemini CLI, GitHub Copilot, Codex, Windsurf,
OpenCode, Antigravity, Open-Claw, Hermes, Qwen Code,
CodeBuddy, Kiro, Trae, Zed, GLM (Z.ai), Kimi Code

A ideia centralCopy Anchor Link

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 nenhum harness individual possui. Os harnesses são consumidores 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; o harness é um alvo de renderização. Um harness pode ser usado para programar, conversar, trabalhar em conjunto, pesquisar ou escrever — o perfil é agnóstico quanto à finalidade do harness.

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 o harness como um terminal descartável.

O problemaCopy Anchor Link

Todo harness 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 ApothemCopy Anchor Link

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"Copy Anchor Link

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 harnesses 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. Como cada harness deriva de um único perfil, a divergência é detectável (apothem status a reporta) e corrigível (apothem update rematerializa a configuração).

Garantias de portabilidadeCopy Anchor Link

Comandos e auxiliares marcados como portability: universal são traduzidos para cada harness cuja entrada no registro suporta uma superfície de comandos (convertida ou em subárvore de suporte); harnesses sem uma não recebem comandos. O motor não avalia o marcador. Comandos e auxiliares marcados como portability: project-specific podem exigir documentação de override por harness no corpo do arquivo.