Code Guardian 17.16 : terminé seulement avec preuve, et une faille dans les verrous

Quand une tâche est-elle terminée ? Depuis la 17.15, les nouveaux dossiers de tâche ne se ferment que lorsque chaque critère obligatoire est prouvé. Deuxième raison de lire cette mise à jour : les verrous pour la suppression, le déploiement et la migration présentent une faille, et la 17.16 a corrigé la note à ce sujet. Ce tour d'horizon des versions 17.14 à 17.16 indique quand une tâche est considérée comme terminée, ce que les verrous interceptent désormais, quelle faille subsiste et ce que vous devriez faire au préalable.

L'article consacré à la version précédente se trouve ici : Code Guardian 17.13 : nouveautés.

Ce que vous devriez faire maintenant

1. Exécutez l'installateur. Lors de la mise à jour, il signale une par une chaque fichier d'un skill d'accompagnement modifié ou complété en local.
2. Vérifiez que Python 3.9 ou une version plus récente est installé. Si python3 est absent, une ligne [toolchain] avec la correction apparaît à chaque modification de code.
3. Créez votre prochaine tâche avec aufgabe.py neu. Le nouveau dossier porte des critères d'acceptation.
4. Faites passer par beleg-lauf.py les exécutions de tests qui doivent servir de preuve. Le journal est alors scellé.
5. Écrivez les commandes de suppression, de déploiement et de migration sans bloc redirigeant, ou vérifiez-les vous-même. Les formes concernées figurent dans la section « Quelles limites restent ouvertes ? ».

Quand une tâche se ferme-t-elle désormais ?

Depuis la 17.15, les nouveaux dossiers de tâche (aufgabe.py neu) portent des critères d'acceptation. Ils sont figés et scellés avant votre premier commit. aufgabe.py abschliessen ne ferme la tâche que lorsque chaque critère obligatoire est prouvé.

Ce que cela signifie pour vous : « terminé » exige une preuve pour chaque critère obligatoire. Une simple affirmation ne suffit pas.

Comment un journal de tests devient-il une preuve ?

Le nouvel outil beleg-lauf.py scelle un journal de tests avec l'état du contenu de votre arbre de travail. Si l'arbre change pendant l'exécution, la preuve est considérée comme périmée. Les tests ignorés (SKIP) ne prouvent rien. Si HEAD pointe entre-temps sur un autre commit, par exemple après un rebase, le refus nomme précisément ce cas.

S'y ajoutent des cas d'acceptation cachés. Un critère de type review · holdout ne vaut que par des cas qu'un sous-agent tout neuf écrit après le figement et qui ne sont pas visibles pendant le développement. Chaque cas exige un journal scellé.

Ce que cela signifie pour vous : lancez l'exécution de tests qui doit servir de preuve via beleg-lauf.py et ne modifiez rien dans l'arbre de travail pendant ce temps. Ne comptez pas sur des tests ignorés.

Que peuvent faire les deux nouveaux skills ?

Le paquet Claude compte désormais 31 skills, contre 29 auparavant. Les deux nouveaux ne démarrent que sur votre appel et figurent sur la liste de blocage du verrou d'écriture. Lors d'une exécution sans surveillance, ils ne peuvent pas être outrepassés.

goalengine

• Ce qu'il fait : il transforme une intention d'objectif en contrat d'objectif aux versions fixes. Un contrat n'est valable qu'après validation explicite d'une version nommée et il est ensuite figé. Un critère n'est considéré comme rempli qu'avec une preuve : un commit, un journal avec exit=0, une URL ou une vérification manuelle nommée. Lors de la validation, il fournit un prompt /goal prêt à copier.
• Ce qu'il ne fait pas : aucun hook n'impose le contrat.
• Où le voir : le poste de pilotage dispose des nouveaux onglets « Goal Engineering » et « Todos » pour chaque projet. Vos objectifs se trouvent dans le dossier .goals/ du projet concerné ; sous ~/.claude/goals/ ne figure que la liste des projets ayant des objectifs.

codeguard-master

• Ce qu'il fait : il observe les projets de votre machine que vous lui indiquez (sans liste, ceux qui ont des objectifs goalengine). À intervalle fixe, il recueille l'état de la situation sans modèle.
• Ce qu'il ne fait pas : il n'intervient pas sur un simple soupçon. Seulement lorsqu'un déclencheur fixe se rallume, un modèle sans outils choisit quelques mesures, avec un écart minimal et un budget quotidien. Les textes sortants proviennent uniquement de modèles fixes. S'il se trompe trop souvent, il passe en mode signalement seul.
• Ce que cela coûte : la cadence via launchd, vous la configurez vous-même, et chaque exécution de modèle coûte des tokens.

Ce que cela signifie pour vous : les deux skills sont des offres. Sans votre appel, il ne se passe rien.

Qu'est-ce qui change dans la vérification après chaque modification de fichier ?

Depuis la 17.14, elle s'exécute dans un seul processus python3, le module hooks/_cg_reminder.py. Auparavant, elle lançait environ 115 processus auxiliaires. Les textes et l'ordre des avertissements restent identiques. Vous n'avez rien à faire : la vérification s'exécute d'elle-même après chaque modification, elle n'a besoin que de python3 (voir l'étape 2 ci-dessus).

Résultat sous Windows : dans le cas typique (médiane), la vérification est de 2,4 à 7,7 fois plus rapide qu'auparavant. Seuls les fichiers Markdown restent inchangés.

Objectif et état : sous Windows, la vérification ne doit guère durer plus longtemps que sous Linux et macOS. Concrètement : sur 100 appels, 95 durent au plus 1,25 fois la durée du plus lent des deux autres systèmes. Pour les scripts shell et Markdown, c'est le cas d'après la mesure provisoire. L'état des autres langages figure dans la section « Quelles limites restent ouvertes ? ».

Autres changements de la 17.14 que vous remarquerez :

• [security-shape] ne signale plus les formes sensibles pour la sécurité que dans les lignes écrites par la modification. L'avertissement ne s'applique qu'à PHP, Python, JavaScript, TypeScript et Vue.
• Le nouvel avertissement [plan-abweichung] signale, une fois par fichier et par session, lorsque vous modifiez un fichier de code qui ne figure dans aucune TRACE ouverte. Il ne bloque jamais.
• log-inventur.py inventur trouve les sources de journaux et indique quel fichier est AKTUELL (à jour) et lequel est VERALTET (périmé).

Un verrou m'arrête-t-il désormais plus souvent ?

Là où quelque chose passait jusqu'ici entre les mailles, oui. Là où il arrêtait à tort, moins souvent.

Plus strict depuis la 17.15 :

• Les verrous de suppression et de migration examinent un programme transmis par pipe à un interpréteur comme un programme passé après -c.
• Un commentaire d'échappatoire ne libère plus rien lorsqu'il est suivi d'une ligne exécutable.
• Un rapport de déploiement ne vaut plus que pour les cibles de sa ligne Target:.

Les verrous reconnaissent désormais :

• rsync, scp et sftp vers une adresse IPv6,
• un script de déploiement via stdin ou précédé d'une option de shell,
• un interpréteur avec un fichier .sql.

Deux conséquences de cette rigueur, le linter SQL et env -S, figurent dans la liste des limites ouvertes plus bas.

Moins de fausses alertes : la simple lecture et les fichiers de configuration ne comptent plus comme « écrit et lancé ». Les commandes de lecture de npm et de composer ne comptent plus comme écrivantes, et des mots comme « form » ou « platform » ne comptent plus comme commande de suppression. Un message de commit contenant un guillemet échappé ne déclenche plus de fausse alerte non plus.

Nouveau : lorsque le même refus de verrou ou la même erreur d'outil survient pour la troisième fois, Code Guardian indique une fois l'issue prévue. L'avertissement ne bloque jamais.

Par ailleurs, les agents de vérification disposant d'un accès au shell n'écrivent plus dans votre arbre de travail. Les essais git en écriture ne s'exécutent plus que dans un dépôt jetable.

Ce que cela signifie pour vous : davantage de refus pour les formes nouvellement reconnues, moins pour la simple lecture. À la troisième interruption identique, Code Guardian indique l'issue.

Quelles corrections sont incluses ?

Ce sont des corrections et non de nouvelles capacités :

• Lors de la mise à jour, le bytecode Python ne compte plus comme fichier modifié en local d'un skill d'accompagnement.
• aufgabe.py trouve aussi le dossier de tâche depuis une copie de travail git (signalement d'un client).
• Rappel d'audit : il n'apparaît plus pour les fichiers du scratchpad ou de $TMPDIR.
• Le démarrage de session arrive de nouveau en entier : l'ancrage, le nombre de todos et l'avertissement de dérive figurent de nouveau dans le contexte.
• L'affichage du quota dans le poste de pilotage montre aussi une mesure récente lorsque Claude Code ne fournit que la valeur hebdomadaire.
• Code Guardian n'affiche plus l'indication sur /clear après abschliessen que si la session ne détient plus de tâche ouverte.

Nouveau en outre : avec aufgabe.py uebergabe, vous écrivez un fichier de passation à la fin de la session.

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

La version Codex reçoit les critères d'acceptation, beleg-lauf.py, les verrous plus stricts et la vérification en un seul processus. Les skills goalengine et codeguard-master n'y existent pas. Autres différences :

• Un appel PowerShell en lecture avec $env: ou Select-String n'est plus arrêté comme env -S.
• Les essais git en écriture des agents de vérification disparaissent et sont signalés dans le rapport comme non exécutés.
• L'installateur rejette un CODEX_HOME relatif, y compris avec --probe, et ce avant le premier accès en écriture. Définissez-le sur un chemin absolu, par exemple $HOME/.codex, ou laissez-le vide.

Quelles limites restent ouvertes ?

Cette liste est l'endroit complet de toutes les réserves de cet article.

• Commandes dans un bloc avec redirection derrière : la note de la 17.15 ne mentionnait ici qu'une écriture rare pour le verrou de migration. C'était trop restreint, et la 17.16 corrige les textes ; le comportement des verrous est resté le même. Les verrous de suppression, de déploiement et de migration ne voient pas les commandes dans un bloc dont l'entrée n'est redirigée qu'après le bloc. La même instruction sans bloc, ils la reconnaissent. Sont concernées ces formes :

  { befehl; } < eingabe
  ( befehl ) < eingabe
  while read zeile; do befehl; done < eingabe
  if bedingung; then befehl; fi < eingabe

  La correction arrive dans la version suivante. D'ici là, écrivez les commandes risquées sans bloc redirigeant ou vérifiez vous-même la suppression, le déploiement et la migration dans un tel bloc.
• Linter SQL : même un simple linter avec un fichier .sql est arrêté. La version n'indique aucune issue.
• env -S : avec d'autres mots, il provoque une demande de confirmation dans le paquet Claude et un blocage sous Codex. Là encore, la version n'indique aucune issue.
• Temps d'exécution sous Windows : pour PHP, Python, JavaScript et CSS, l'objectif n'est pas encore atteint. La base macOS de la mesure provisoire a été mesurée sous charge ; une nouvelle mesure sur une machine au repos est prévue pour la prochaine version. La validation de l'objectif est planifiée de façon ferme pour la prochaine version et n'est pas comptée comme terminée.
• Codex : les cas d'acceptation cachés (review · holdout) n'y sont pas disponibles.

Ce que cela signifie pour vous : la validation est devenue démontrable, les verrous sont plus étanches. Une faille subsiste jusqu'à la version suivante, et nous la nommons.

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

Sources

• Changelog Code Guardian 17.14–17.16 (paquet Claude et paquet Codex), dans le portail client

État au : 04.11.2026