Code Guardian 17.13 : est terminé ce qui est prouvé

L'agent annonce « tests au vert », mais l'exécution des tests n'a jamais eu lieu. À partir de Code Guardian 17.13, une telle tâche ne se clôt plus. Ce tour d'horizon des versions 17.10 à 17.13 répond à une seule question : à quoi voyez-vous que le résultat est juste ?

Vous trouverez l'article sur la version précédente ici : Code Guardian 17.9 : nouveautés.

Ce que vous devriez faire maintenant

1. Uniquement pour les utilisateurs de Codex avec des valeurs de profil personnalisées : notez vos valeurs dans agents/cg-*.toml. Une mise à jour les réinitialise.
2. Installez la mise à jour avec bash install.sh. Les nouveaux avis prennent effet immédiatement.
3. Utilisateurs de Codex : saisissez ensuite de nouveau vos valeurs.
4. Créez votre prochaine tâche avec aufgabe.py neu ; aufgabe.py est l'outil des dossiers de tâche. Le nouveau dossier porte automatiquement la mention « Graph: ja ».

Quand une tâche est-elle considérée comme terminée dans Code Guardian ?

Depuis la version 17.13, chaque nouveau dossier de tâche contient un graphe de travail de six nœuds. Ces six nœuds, c'est vous qui les prouvez ; la clôture, c'est Code Guardian lui-même qui l'inscrit.

Chaque nœud est ouvert, affirmé, prouvé ou sans objet. « Affirmé » signifie : inscrit comme terminé, mais sans justificatif vérifié. Cela ne clôt rien, car une ligne écrite à la main ne prouve rien.

Un nœud n'est prouvé que s'il repose sur un justificatif : un fichier journal avec exit=0, un commit ou un « sans objet » motivé. Le journal et le commit doivent être plus récents que le démarrage du graphe, c'est-à-dire le moment où le dossier a reçu son graphe.

À la clôture, Code Guardian revérifie tous les nœuds. Si une preuve manque, il affiche « NICHT FERTIG: N Graph-Knoten ohne Beleg ». Une simple affirmation ne clôt aucune tâche.

Pour vous, cela signifie : « terminé » est vérifiable. Un tiers voit dans le dossier ce qui a été contrôlé et avec quoi.

Comment prouver un nœud

1. Consulter l'état, en lecture seule : aufgabe.py graph --id <id>.
2. Choisir un justificatif par nœud, avec aufgabe.py beleg --id <id> --knoten <knoten> et exactement l'une de ces indications :
   • --datei <protokoll> : la dernière ligne non vide doit porter exit=0, et le fichier doit être plus récent que le démarrage du graphe.
   • --sha <sha> : le commit doit être plus récent que le démarrage du graphe et se trouver dans une branche ou un tag.
   • --entfaellt <grund> : sans motif, le nœud reste ouvert.
   • Cas particulier du contrôle préalable : ici, --rot <protokoll> prouve l'exécution rouge avant la modification, dont le code de sortie est différent de 0.
3. Clôturer avec aufgabe.py abschliessen.

Après un git commit, le hook prouve lui-même le nœud edit si le commit date d'au plus dix minutes. L'exécution des tests (suite), il ne la prouve jamais.

Si NICHT FERTIG s'affiche : aufgabe.py abschliessen indique, pour chaque nœud manquant, l'appel correspondant de aufgabe.py beleg. Exécutez-le, puis clôturez de nouveau. Attention : abschliessen ne lit que la section ## Erkenntnisse. Les constats placés sous un titre personnalisé ne comptent pas.

Mon travail en cours sera-t-il bloqué ?

Non. Le blocage ne s'applique qu'aux nouveaux dossiers portant « Graph: ja ». Les dossiers existants reçoivent le graphe et un simple avis.

Trois avis sont nouveaux : [graph], [wiederaufnahme] et [abbruch]. Le dernier signale un sous-agent de contrôle interrompu, qui disparaissait jusqu'ici sans bruit. Aucun de ces avis ne bloque quoi que ce soit.

En outre, la fausse alerte de la clôture (la limite de fichiers d'une tâche) dans les dépôts imbriqués est corrigée.

Pour vous, cela signifie : l'obligation de preuve ne concerne que les tâches que vous créez à nouveau. Tout le reste continue comme avant.

Comment savoir d'où vient un constat ?

La revue connaît désormais le niveau de risque H. Il s'applique lorsqu'une modification touche la liste de blocage, c'est-à-dire des domaines comme la base de données, le paiement, le déploiement et les secrets. Il s'applique aussi lorsque l'analyse des motifs de code sensibles pour la sécurité renvoie une valeur supérieure à 0.

Dans ce cas, les bras de relecture, c'est-à-dire les agents de contrôle indépendants, travaillent avec une profondeur de réflexion plus élevée (xhigh). Dans le bloc de clôture, le voyant « Risiko H » s'allume. Après trois tours de revue à froid, un plafond de tours s'applique : la revue ne tourne pas indéfiniment en rond.

Chaque constat s'accompagne d'un classement du type d'erreur, avec un motif de recherche pour les endroits où la même erreur peut encore se cacher. S'y ajoute l'origine : propre, préexistante ou indéterminée. L'origine ne change aucun verdict. Elle montre seulement si la trouvaille provient de votre modification.

Avant toute modification d'une architecture existante, Code Guardian exige en outre une fiche de synthèse à sept champs.

Pour vous, cela signifie : les modifications risquées sont contrôlées plus en profondeur, et vous voyez tout de suite si un constat est le vôtre.

Mes chiffres sont-ils justes quand je travaille avec des copies de travail ?

Oui, c'est le but de ces modifications : vos constats et vos chiffres portent sur votre code et non plus sur des copies de celui-ci. Celui qui travaille avec des copies de travail Git sous .claude/worktrees/ obtenait jusqu'ici des chiffres faussés.

Depuis la version 17.12, les copies de travail ne sont plus comptées en double. Sept outils ont été adaptés, auxquels s'ajoutent des corrections pour Windows concernant la recherche de clones et le contrôle des dépendances.

La version 17.13 poursuit : d'autres outils de contrôle, dont la recherche de cicatrices, l'inventaire des plans et les analyses pour PHP, Python, JS et HTML, ignorent les copies de travail et le cache PHPStan. Les outils n'héritent en outre plus de GIT_DIR et de GIT_WORK_TREE.

Exception : la recherche de secrets et la détection de textes juridiques continuent volontairement de contrôler les copies de travail.

Pour vous, cela signifie : si vous travaillez sous .claude/worktrees/, vous n'avez rien à faire. Les outils adaptés ignorent d'eux-mêmes les copies.

Code Guardian peut-il apprendre tout seul ?

Depuis la version 17.11, il existe le skill auto-self-improve. Il fait de lui-même un retour en arrière une fois le travail accompli. Il est désactivé par défaut, consigne tout avant chaque modification et ne touche à aucun verrou de protection. Depuis la version 17.12, il attend tant qu'une question qui vous est adressée reste ouverte.

Pour l'activer : dans ~/.claude/code-guardian.conf, définissez la ligne auto_self_improve = true. La valeur par défaut est false.

Également depuis la version 17.11 : le skill autorun pour un travail sans surveillance et un avis en cas de boucle, qui rend visible une étape qui échoue sans cesse. Aucun des deux ne déclenche de verrou de protection, et l'avis ne bloque rien.

Pour vous, cela signifie : vous décidez si le retour en arrière se fait automatiquement. Sans votre réglage, tout reste comme avant.

Pourquoi un verrou m'arrête-t-il, et pourquoi moins souvent ?

Les verrous sont les blocages de protection placés devant les commandes risquées. Un arrêt doit avoir une raison, une commande inoffensive n'en a aucune.

Depuis la version 17.10, les verrous de migration et de déploiement reconnaissent un appel à distance même lorsque ssh n'apparaît pas littéralement dans la commande, mais provient d'une variable. Jusqu'ici, une migration ou un déploiement sur une machine distante passait alors sans arrêt. Le verrou de suppression reconnaît la suppression à distance via une variable ssh, y compris derrière timeout.

En même temps, il y a moins de fausses alertes :

• Un grep en lecture sur un script de déploiement est autorisé (17.11).
• Un nom de déploiement dans un littéral ne compte plus comme un déploiement (17.11).
• Une charge utile ssh entièrement entre guillemets, qui ne supprime qu'un fichier jetable créé par vous-même, ne déclenche plus d'alerte (17.10).

Les textes de refus du verrou de suppression sont plus clairs. Le verrou demande maintenant confirmation lorsqu'un nombre de la commande ne se lit pas sans ambiguïté (par exemple nan ou inf), au lieu de deviner.

Pour vous, cela signifie : moins d'arrêts sur des commandes inoffensives, plus d'attention face aux vrais risques.

Quelles limites restent ouvertes ?

Nous les nommons ouvertes :

• Obligation de preuve : elle ne s'applique qu'aux nouveaux dossiers portant « Graph: ja ». Ce que vous pouvez faire : recréez vos tâches importantes, l'obligation s'y appliquera alors.
• Variable ssh : elle est reconnue à sa graphie, et toutes les graphies ne sont pas couvertes. Ce que vous pouvez faire : pour les commandes risquées, écrivez ssh littéralement dans la commande au lieu de l'appeler via une variable.
• Rapport d'autorisation : les verrous de migration et de déploiement acceptent encore un rapport écrit par vous-même. La faille est prévue pour une prochaine version. Ce que vous pouvez faire : relisez vous-même les rapports d'autorisation d'un œil critique.
• Windows : une exécution terminée normalement ne compte plus comme interrompue. La limite connue : une exécution qui s'interrompt exclusivement au niveau du lanceur Windows sous Git bash n'est plus reconnue comme interrompue après la correction. Ce que vous pouvez faire : en cas d'interruption de ce type, vérifiez vous-même la sortie.
• Codex : sous Codex, le niveau de risque H est seulement signalé et ne relève rien. Ce que vous pouvez faire : réglez vous-même la profondeur de réflexion dans le profil.

Pour vous, cela signifie : pour une migration et un déploiement, ne vous fiez pas uniquement à un rapport d'autorisation.

Qu'est-ce qui change pour les utilisateurs de Codex ?

La sortie Codex reçoit le graphe de travail avec obligation de preuve ainsi que les indications d'origine. S'y ajoutent trois différences :

• Le niveau de risque H est seulement signalé, il ne relève rien. La profondeur de réflexion des bras de relecture se règle vous-même dans le profil.
• Une mise à jour écrase les profils d'agent agents/cg-*.toml et réinitialise les valeurs personnalisées. Les étapes 1 et 3 ci-dessus sont prévues pour cela.
• La mesure des coûts affichait jusqu'ici avec session-cost --geld un zéro silencieux au lieu des valeurs. Désormais, les quantités de tokens proviennent des messages de Codex.

Pour vous, cela signifie : notez les valeurs de votre profil avant la mise à jour et saisissez-les de nouveau ensuite.

Qu'apporte Code Guardian de mesurable ?

État de la mesure comparative : la dernière exécution valide, du 15.10.2026, mesure la v17.10 : en moyenne 5,9 avec contre 5,2 sans Code Guardian. La valeur est un score par tâche, plus élevé signifie meilleur. La valeur p est de 0,017, le résultat est « prouvé ».

Pour les versions 17.11 à 17.13, il n'existe pas encore de mesure propre. Au total, il y a 10 comparaisons valides.

Vous trouverez plus d'informations sur le produit sur la page produit.

Questions fréquentes sur Code Guardian 17.13

Que faire en cas de NICHT FERTIG ?

Exécutez l'appel que aufgabe.py abschliessen indique pour chaque nœud manquant. Clôturez ensuite de nouveau.

Comment activer le retour en arrière automatique ?

Dans ~/.claude/code-guardian.conf, définissez la ligne auto_self_improve = true. Il ne touche à aucun verrou de protection et ne modifie rien d'irréversible.

Que se passe-t-il après trois tours de revue à froid ?

Le voyant affiche « Rundendeckel 3 Runden — Ansatz überdenken ». Repensez alors l'approche au lieu de lancer un quatrième tour.

Dois-je tenir compte de quelque chose en tant qu'utilisateur de Codex ?

Oui : les étapes 1 et 3 ci-dessus et la profondeur de réflexion des bras de relecture dans le profil.

Remarque sur la version 17.11

Dans la note sur la version 17.11, deux indications étaient inexactes : les trois agents de revue n'étaient pas nouveaux, et la fiche de synthèse comporte sept champs.

Sources

• Journal des modifications de Code Guardian 17.10 à 17.13 (paquet Claude et paquet Codex), dans le portail client
• Mesure comparative du fabricant, exécution du 15.10.2026

État au 26.10.2026