codeArbiter: guía de decisión y primer uso — gobernanza de código con gates para Claude Code, Codex CLI y Pi

Para quién es

• Para desarrolladores y equipos que trabajan en Claude Code, Codex CLI o Pi y quieren que cada cambio pase un control obligatorio antes de entrar en la base de código: codeArbiter es una capa de gobernanza (governance layer) diseñada para esos tres hosts, y el título del repositorio oficial expresa su motivación: "When you can't trust yourself with your code base, trust Arbiter." (Cuando no puedes confiar en ti mismo con tu base de código, confía en Arbiter.)
• Una vez activado, cada intención que expreses al agente se enruta a un gated skill o a un reviewer agent; nada se commitea hasta que todos los gates estén en verde; las decisiones pasan por SMARTS; el registro de auditoría es append-only. Actúa a nivel de repositorio: el opt in aplica a un repositorio concreto. Quien necesite gates obligatorios antes del commit y decisiones trazables encuentra aquí justo eso. Append-only significa que los registros de auditoría solo pueden añadirse, nunca borrarse ni reescribirse.
• Encaja con usuarios prudentes que prefieren mirar antes de actuar: la documentación oficial deja claro que el plugin queda dormido tras la instalación y no hace nada con un repositorio hasta que ese repositorio se incluye mediante un opt in explícito; el texto original dice "That silence is intentional." (Ese silencio es intencionado.) La instalación por sí sola no cambia de inmediato el comportamiento actual del repositorio.
• Cuándo no encaja: flujos que no quieren un proceso con gates, tareas de análisis o reescritura puntual de código y máquinas cuyo entorno no cumpla los requisitos de la sección siguiente. Qué lenguajes de programación y tipos de proyecto admite no aparece en la documentación oficial: es desconocido, y eso influye directamente en si conviene elegirlo.
• Si se admiten otros hosts de agentes además de Claude Code, Codex CLI y Pi no se dice en las evidencias: desconocido.

Tu primer intento en 3 minutos

• Requisitos previos: Windows, macOS o Linux; lo oficial exige Pi 0.80.10, Node.js 22.19 o más reciente, Python 3 y Git, sin cuenta ni datos de ejemplo. Si falta cualquiera, completa el entorno antes de instalar.
• Dónde se instala: la vía de instalación oficial es el plugin marketplace de Claude Code. En Claude Code ejecuta estos dos comandos en orden: el primero añade arbiterForge/codeArbiter como fuente del marketplace y el segundo instala desde esa fuente el plugin llamado ca:

/plugin marketplace add arbiterForge/codeArbiter
/plugin install ca@codearbiter

• Señal de éxito tras instalar: hooks, commands, agents y el cableado del statusline se cargan automáticamente, y todos los comandos se resuelven bajo el espacio de nombres /ca:. Es decir, no hace falta cablear nada a mano tras instalar, y los comandos con el prefijo /ca: deberían reconocerse. En ese momento el plugin sigue dormido: es el comportamiento esperado, no una instalación fallida.
• Punto de confirmación clave: un repositorio solo entra en el flujo de gobernanza después de un opt in explícito; instalación completada no equivale a trabajo iniciado. El comando concreto para el opt in no aparece en la documentación oficial; cómo se ejecuta ese paso es desconocido. Guíate por las instrucciones del repositorio oficial y no inventes comandos.
• Primera tarea: tras el opt in, expresa al agente una intención normal de análisis o modificación de código y observa dos cosas: si la intención se enruta a un gated skill o a un reviewer agent, y si nada se commitea antes de que todos los gates estén en verde. Si la intención no se enruta, o hay commits con gates aún en rojo, el flujo de gobernanza no funciona como dice la documentación oficial. Qué comandos concretos existen bajo /ca: no consta en las evidencias; no se puede dar la lista literal.

Casos de uso

• Caso 1: activar commits con gates en un repositorio personal. Escenario: quieres que cada cambio pase un control automático antes del commit. Procedimiento: ejecuta los dos comandos de instalación de arriba en Claude Code para instalar el plugin ca, confirma que hooks, commands, agents y statusline se cargaron automáticamente y que los comandos /ca: se resuelven; después incluye el repositorio mediante el opt in y expresa al agente una intención de cambio. Qué esperar: la intención se enruta a un gated skill o a un reviewer agent, nada se commitea hasta que todos los gates estén en verde, las decisiones pasan por SMARTS y el registro de auditoría solo admite adiciones. Como el plugin queda dormido tras la instalación, todos los efectos de este caso empiezan en el paso de opt in; los comandos de instalación por sí solos no disparan ninguna acción de gobernanza. Si solo quieres ver cómo queda instalado, puedes detenerte en "carga automática, /ca: se resuelve" y observar; no hace falta apresurar el opt in.
• Caso 2: hacer trazables las decisiones de cambio del equipo. Escenario: trabajando varias personas, quieres que cada decisión de cambio quede documentada y que el historial no pueda reescribirse. Procedimiento: sobre un repositorio ya incluido mediante opt in, expresa al agente una intención de cambio y sigue el mismo flujo con gates. Qué esperar: las decisiones quedan registradas vía SMARTS, el registro de auditoría es append-only y lo ya escrito no se sobrescribe con operaciones posteriores. Cómo se interactúa exactamente con SMARTS y dónde se consultan los registros no consta en las evidencias; el alcance confirmado llega hasta ahí.

Límites de uso

• Efectos secundarios y puntos de confirmación: al instalar se cargan automáticamente hooks, commands, agents y el cableado del statusline; la documentación oficial lo describe como comportamiento propio de la instalación. El estado inicial es dormido; hasta que un repositorio se incluya mediante un opt in explícito, el plugin no hace nada con él, así que sin opt in no se puede verificar el efecto de gobernanza. Si el opt in se puede deshacer y cómo, no consta en las evidencias: desconocido; a quien le importe el coste de revertir debería aclararlo antes del opt in.
• Archivos, comandos y red: si lee o escribe tus archivos, qué comandos ejecuta y si accede a la red no aparece en la documentación oficial: desconocido; de ese silencio no se puede deducir que no exista ningún comportamiento así. Antes de conectarlo a un repositorio importante, prueba el opt in en un entorno desechable.
• Diferencias de plataforma y de cliente: la única vía de instalación dada textualmente por la documentación oficial es el plugin marketplace de Claude Code; Codex CLI y Pi figuran como hosts a los que sirve la capa de gobernanza, pero su forma de instalación no aparece en la documentación oficial: desconocido.
• Información clave sin confirmar: el comando concreto de opt in, la lista completa de comandos bajo el espacio de nombres /ca:, cómo es la interacción con SMARTS, los lenguajes y tipos de proyecto admitidos, el soporte más allá de Windows, macOS y Linux, y cómo desinstalarlo o desactivarlo temporalmente: nada de esto consta en las evidencias. Antes de adoptarlo, confirma cada punto en el repositorio oficial.