Postura agnóstica respecto al host

Apothem se diseñó en torno a un único principio: tu configuración de gobernanza debería sobrevivir a cualquier entorno de ejecución de asistente concreto. El perfil compartido de Apothem es un archivo YAML validado por esquema en ~/.config/apothem/profile.yaml o --profile PATH; los conjuntos de Apothem empaquetados aportan comandos, reglas, skills, hooks, plantillas, líneas de estado, output-styles y definiciones de delegación. Los adaptadores por entorno bajo src/apothem/harnesses/<harness>/ traducen esas entradas al formato que requiere cada entorno compatible:

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

La idea centralCopy Anchor Link

El agnosticismo respecto al host significa que tu intención —quién eres, cómo quieres que se comporten los asistentes, las reglas que deben seguir— vive en un único lugar que ningún entorno posee. Los entornos son consumidores intercambiables de esa intención. Cuando llega un nuevo asistente, lo adoptas añadiendo un adaptador, no reescribiendo tu configuración. Cuando un asistente que usabas deja de interesarte, lo descartas sin perder la gobernanza que construiste. El perfil es el activo; el entorno es un destino de renderizado. Un entorno puede usarse para programar, chatear, trabajar en equipo, investigar o escribir: el perfil es agnóstico respecto a para qué sirve el entorno.

Esto es una inversión deliberada. El camino habitual es configurar cada herramienta directamente, lo que deja tu inversión a merced de la longevidad y el formato de esa herramienta. Apothem trata la configuración como capital portátil y el entorno como una terminal desechable.

El problemaCopy Anchor Link

Cada entorno de ejecución de asistente tiene su propio formato de configuración:

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

Sin Apothem, mantienes N archivos de configuración separados que se desvían entre sí con el tiempo.

La solución de 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/
         +---> ...

Editas el perfil compartido una vez y luego ejecutas apothem update --harness <name> o apothem update --harness all --project <path> para propagar el cambio. apothem harnesses list imprime el conjunto registrado.

Por qué "apothem"Copy Anchor Link

El nombre codifica la arquitectura. En geometría, un apotema es la perpendicular desde el centro de un polígono regular hasta el punto medio de uno de sus lados: la distancia única desde el núcleo hasta cada arista, idéntica en todas las direcciones. Ese es el diseño: un perfil compartido en el centro, diecisiete entornos equidistantes en el perímetro, cada materialización a la misma distancia de la fuente de verdad. El núcleo no cambia cuando cambia una arista; las aristas comparten una única relación con el núcleo. Como cada entorno procede de un único perfil, la deriva es detectable (apothem status informa de ella) y corregible (apothem update la vuelve a materializar).

Garantías de portabilidadCopy Anchor Link

Los comandos y los ayudantes marcados con portability: universal se traducen a cada entorno cuya entrada en el registro admite una superficie de comandos (convertida o de subárbol de soporte); los entornos sin ella no reciben comandos. El motor no evalúa el marcador. Los comandos y los ayudantes marcados con portability: project-specific pueden requerir documentación de anulación por entorno en el cuerpo del archivo.