codeArbiter: guia de decisão e primeiro uso — governança de código com gates para Claude Code, Codex CLI e Pi

Para quem é

• Para desenvolvedores e equipes que trabalham em Claude Code, Codex CLI ou Pi e querem que toda alteração passe por uma verificação obrigatória antes de entrar na base de código: o codeArbiter é uma camada de governança (governance layer) desenhada para esses três hosts, e o título do repositório oficial exprime a motivação: "When you can't trust yourself with your code base, trust Arbiter." (Quando você não consegue confiar em si mesmo com a sua base de código, confie no Arbiter.)
• Depois de ativado, cada intenção expressa ao agente é roteada para um gated skill ou um reviewer agent; nada é commitado enquanto todos os gates não estiverem verdes; as decisões passam pelo SMARTS; o registro de auditoria é append-only. Ele atua no nível do repositório: o opt in vale para um repositório específico. Quem precisa de gates obrigatórios antes do commit e de decisões rastreáveis é exatamente o público-alvo. Append-only significa que os registros de auditoria só podem ser adicionados, nunca apagados ou reescritos.
• Adequado para usuários cautelosos que preferem ver antes de agir: a documentação oficial deixa claro que o plugin fica dormente após a instalação e não faz nada com um repositório até que esse repositório seja incluído por um opt in explícito; o texto original diz "That silence is intentional." (Esse silêncio é intencional.) A instalação por si só não muda de imediato o comportamento atual do repositório.
• Quando não é adequado: fluxos que não querem um processo com gates, tarefas pontuais de análise ou reescrita de código e máquinas cujo ambiente não atenda aos requisitos da próxima seção. Quais linguagens de programação e tipos de projeto ele atende não aparece na documentação oficial: é desconhecido, e isso influencia diretamente se vale a pena escolhê-lo.
• Se outros hosts de agentes além de Claude Code, Codex CLI e Pi são suportados, as evidências não dizem: desconhecido.

Sua primeira tentativa em 3 minutos

• Pré-requisitos: Windows, macOS ou Linux; o requisito oficial é Pi 0.80.10, Node.js 22.19 ou mais recente, Python 3 e Git, sem conta nem dados de exemplo. Se faltar qualquer um, complete o ambiente antes de instalar.
• Onde instalar: o caminho de instalação oficial é o plugin marketplace do Claude Code. No Claude Code, execute os dois comandos abaixo em ordem — o primeiro adiciona arbiterForge/codeArbiter como fonte do marketplace e o segundo instala dessa fonte o plugin chamado ca:

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

• Sinal de sucesso após a instalação: hooks, commands, agents e a fiação do statusline são carregados automaticamente, e todos os comandos são resolvidos sob o namespace /ca:. Ou seja, não é preciso ligar nada à mão depois de instalar, e os comandos com o prefixo /ca: devem ser reconhecidos. Nesse momento o plugin ainda está dormente: é o comportamento esperado, não uma falha de instalação.
• Ponto de confirmação essencial: um repositório só entra no fluxo de governança depois de um opt in explícito; instalação concluída não é o mesmo que trabalho iniciado. O comando concreto do opt in não aparece na documentação oficial; como executar esse passo é desconhecido. Siga as instruções dentro do repositório oficial e não chute comandos.
• Primeira tarefa: depois do opt in, expresse ao agente uma intenção comum de análise ou modificação de código e observe dois pontos: se a intenção é roteada para um gated skill ou um reviewer agent, e se nada é commitado antes de todos os gates ficarem verdes. Se a intenção não for roteada, ou se houver commit com gates ainda vermelhos, o fluxo de governança não está funcionando como descrito oficialmente. Quais comandos concretos existem sob /ca: não consta nas evidências; não dá para reproduzi-los ao pé da letra.

Casos de uso

• Caso 1: ativar commits com gates em um repositório pessoal. Cenário: quer que toda alteração passe por uma checagem automática antes do commit. Como fazer: execute os dois comandos de instalação acima no Claude Code para instalar o plugin ca, confirme que hooks, commands, agents e statusline foram carregados automaticamente e que os comandos /ca: são resolvidos; depois inclua o repositório via opt in e expresse ao agente uma intenção de alteração. O que esperar: a intenção é roteada para um gated skill ou um reviewer agent, nada é commitado antes de todos os gates ficarem verdes, as decisões passam pelo SMARTS e o registro de auditoria só aceita acréscimos. Como o plugin fica dormente após a instalação, todos os efeitos deste caso começam no passo do opt in; os comandos de instalação, por si só, não disparam nenhuma ação de governança. Se você só quer ver como fica instalado, pode parar em "carregamento automático, /ca: resolve" e observar; não precisa apressar o opt in.
• Caso 2: tornar rastreáveis as decisões de alteração da equipe. Cenário: com várias pessoas colaborando, quer que cada decisão de alteração fique registrada e que o histórico não seja reescrito. Como fazer: em um repositório já incluído via opt in, expresse ao agente uma intenção de alteração e siga o mesmo fluxo com gates. O que esperar: as decisões ficam registradas via SMARTS, o registro de auditoria é append-only e o que já foi escrito não é sobrescrito por operações posteriores. Como é a interação exata com o SMARTS e onde consultar os registros não consta nas evidências; o alcance confirmado termina aqui.

Limites de uso

• Efeitos colaterais e pontos de confirmação: na instalação, hooks, commands, agents e a fiação do statusline são carregados automaticamente; é o comportamento que a documentação oficial descreve como próprio da instalação. O estado inicial é dormente; até que um repositório seja incluído por um opt in explícito, o plugin não faz nada com ele, então sem opt in não há como verificar o efeito da governança. Se o opt in pode ser desfeito e como, não consta nas evidências: desconhecido; quem se importa com o custo de reverter deve esclarecer isso antes do opt in.
• Arquivos, comandos e rede: se ele lê ou escreve seus arquivos, quais comandos executa e se acessa a rede não aparece na documentação oficial: desconhecido; desse silêncio não se pode deduzir que não exista nenhum comportamento desse tipo. Antes de ligá-lo a um repositório importante, experimente o opt in em um ambiente descartável.
• Diferenças de plataforma e de cliente: o único caminho de instalação dado literalmente pela documentação oficial é o plugin marketplace do Claude Code; Codex CLI e Pi constam como hosts atendidos pela camada de governança, mas o modo de instalação dos dois não aparece na documentação oficial: desconhecido.
• Informações-chave ainda não confirmadas: o comando concreto do opt in, a lista completa de comandos sob o namespace /ca:, como funciona a interação com o SMARTS, as linguagens e os tipos de projeto atendidos, o suporte além de Windows, macOS e Linux, e como desinstalar ou desativar temporariamente: nada disso consta nas evidências. Antes de adotar, confirme ponto a ponto no repositório oficial.