codeArbiter : guide de décision et de première utilisation — une gouvernance du code par gates pour Claude Code, Codex CLI et Pi

À qui ça s'adresse

• Aux développeurs et équipes qui travaillent dans Claude Code, Codex CLI ou Pi et veulent que chaque modification passe un contrôle obligatoire avant d'entrer dans la base de code : codeArbiter est une couche de gouvernance (governance layer) conçue pour ces trois hôtes, et le titre du dépôt officiel énonce sa motivation : « When you can't trust yourself with your code base, trust Arbiter. » (Quand vous ne pouvez pas vous faire confiance avec votre base de code, faites confiance à Arbiter.)
• Une fois activé, chaque intention exprimée à l'agent est routée vers un gated skill ou un reviewer agent ; rien n'est commité tant que tous les gates ne sont pas au vert ; les décisions passent par SMARTS ; la piste d'audit est en append-only. Il opère à l'échelle du dépôt : l'opt in vaut pour un dépôt donné. Ceux qui ont besoin de gates obligatoires avant commit et de décisions traçables sont exactement le public visé. Append-only signifie que les entrées d'audit ne peuvent qu'être ajoutées, jamais supprimées ni réécrites.
• Convient aux utilisateurs prudents qui préfèrent regarder avant d'agir : la documentation officielle indique clairement que le plugin reste en sommeil après l'installation et ne fait rien pour un dépôt tant que celui-ci n'a pas été explicitement opt in. Le texte original dit « That silence is intentional. » (Ce silence est volontaire.) L'installation en elle-même ne change pas immédiatement le comportement existant du dépôt.
• Quand ce n'est pas adapté : les contextes qui ne veulent pas d'un flux à gates, les besoins d'analyse ou de réécriture ponctuelle du code, et les machines dont l'environnement ne satisfait pas les exigences de la section suivante. Quels langages de programmation et quels types de projets il prend en charge, la documentation officielle ne le dit pas : c'est inconnu, et cela influence directement le choix de l'adopter ou non.
• La prise en charge d'autres hôtes d'agents que Claude Code, Codex CLI et Pi n'est pas mentionnée dans les éléments disponibles : inconnu.

Votre première tentative en 3 minutes

• Prérequis : Windows, macOS ou Linux ; les exigences officielles sont Pi 0.80.10, Node.js 22.19 ou plus récent, Python 3 et Git, sans compte ni données d'exemple. S'il manque un seul de ces éléments, complétez d'abord l'environnement avant d'installer.
• Où installer : le chemin d'installation officiel est le plugin marketplace de Claude Code. Dans Claude Code, exécutez les deux commandes suivantes dans l'ordre — la première ajoute arbiterForge/codeArbiter comme source du marketplace, la seconde installe depuis cette source le plugin nommé ca :

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

• Signal de succès après installation : les hooks, commands, agents et le câblage du statusline se chargent automatiquement, et toutes les commandes se résolvent sous l'espace de noms /ca:. Autrement dit, aucun câblage manuel n'est nécessaire après l'installation, et les commandes préfixées par /ca: devraient être reconnues. À ce stade, le plugin reste en sommeil : c'est un comportement attendu, pas un échec d'installation.
• Point de confirmation clé : un dépôt n'entre dans le flux de gouvernance qu'après un opt in explicite ; installation terminée ne veut pas dire travail lancé. La commande concrète d'opt in n'apparaît pas dans la documentation officielle ; la façon de réaliser cette étape est inconnue. Tenez-vous-en aux instructions du dépôt officiel et n'imaginez pas de commande vous-même.
• Première tâche : après l'opt in, exprimez à l'agent une intention banale d'analyse ou de modification de code, puis observez deux points — l'intention est-elle routée vers un gated skill ou un reviewer agent ; rien n'est-il commité tant que tous les gates ne sont pas au vert. Si l'intention n'est pas routée, ou si un commit passe alors que des gates sont encore rouges, le flux de gouvernance ne fonctionne pas comme décrit officiellement. Quelles commandes précises existent sous /ca:, les éléments disponibles ne le disent pas — impossible de les donner au mot près.

Cas d'usage

• Cas 1 : activer des commits à gates sur un dépôt personnel. Scénario : chaque modification doit passer un contrôle automatique avant le commit. Méthode : exécutez les deux commandes d'installation ci-dessus dans Claude Code pour installer le plugin ca, vérifiez que hooks, commands, agents et statusline se sont chargés automatiquement et que les commandes /ca: se résolvent, puis déclarez le dépôt par un opt in, et enfin exprimez une intention de modification à l'agent. À attendre : l'intention est routée vers un gated skill ou un reviewer agent, rien n'est commité tant que tous les gates ne sont pas au vert, les décisions passent par SMARTS, et la piste d'audit n'accepte que des ajouts. Le plugin étant en sommeil après l'installation, tous les effets de ce cas commencent à l'étape d'opt in ; les commandes d'installation ne déclenchent elles-mêmes aucune action de gouvernance. Si vous voulez seulement voir à quoi ressemble l'outil une fois installé, vous pouvez vous arrêter à l'étape « chargement automatique, /ca: se résout » et observer — pas besoin de précipiter l'opt in.
• Cas 2 : rendre traçables les décisions de modification de l'équipe. Scénario : en collaboration à plusieurs, chaque décision de modification doit être documentée et l'historique ne doit pas pouvoir être réécrit. Méthode : sur un dépôt déjà opt in, exprimez une intention de modification à l'agent et suivez le même flux à gates. À attendre : les décisions sont enregistrées via SMARTS, la piste d'audit est en append-only, et les entrées déjà écrites ne sont pas écrasées par les opérations ultérieures. La manière précise d'interagir avec SMARTS et l'endroit où consulter les enregistrements ne sont pas documentés dans les éléments disponibles ; le périmètre confirmé s'arrête là.

Limites d'usage

• Effets secondaires et points de confirmation : l'installation charge automatiquement les hooks, commands, agents et le câblage du statusline — c'est le comportement documenté officiellement au moment de l'installation. L'état initial est le sommeil ; tant qu'un dépôt n'a pas été explicitement opt in, le plugin ne fait rien pour lui, donc sans opt in impossible de vérifier l'effet de gouvernance. Savoir si l'opt in est réversible et comment l'annuler n'est pas documenté : inconnu ; les utilisateurs sensibles au coût d'un retour arrière doivent clarifier ce point avant l'opt in.
• Fichiers, commandes et réseau : s'il lit ou écrit vos fichiers, quelles commandes il exécute, s'il accède au réseau — la documentation officielle n'en dit rien : inconnu ; on ne peut pas en déduire qu'il n'a aucun comportement de ce genre. Avant de le brancher sur un dépôt important, essayez l'opt in dans un environnement jetable.
• Différences de plateforme et de client : le seul chemin d'installation donné mot pour mot par la documentation officielle est le plugin marketplace de Claude Code ; Codex CLI et Pi sont bien cités comme hôtes servis par la couche de gouvernance, mais leur mode d'installation n'apparaît pas dans la documentation officielle : inconnu.
• Informations clés non confirmées : la commande concrète d'opt in, la liste complète des commandes sous l'espace de noms /ca:, la manière d'interagir avec SMARTS, les langages de programmation et types de projets pris en charge, le support au-delà de Windows, macOS et Linux, la désinstallation ou la désactivation temporaire — rien de tout cela n'apparaît dans les éléments disponibles. Avant d'adopter l'outil, vérifiez chaque point sur le dépôt officiel.