Code Guardian 17.17 : « terminé » signifie désormais : objectif mesuré

Avec la 17.17, une tâche peut porter une preuve centrale : une preuve qui mesure l'objectif lui-même. Une telle tâche n'est considérée comme terminée que lorsque la preuve centrale est mesurée au vert. Après chaque ajustement, l'agent s'arrête et demande si autre chose doit suivre. Les petites modifications reçoivent un contrôle plus léger. En revanche, une faille de la 17.16 n'est pas corrigée, et cet article explique ce que cela signifie pour vous.

L'article sur les versions précédentes se trouve ici : Code Guardian 17.14 à 17.16 : les nouveautés.

Ce que vous devriez faire maintenant

1. Exécutez l'installateur. Il sauvegarde avant remplacement les définitions d'agents modifiées localement et vous les signale.
2. Vérifiez que jq est installé. Sans jq, tous les verrous ne contrôlent pas (voir ci-dessous).
3. Si le service Leitstand (Claude Code) tourne chez vous, redémarrez-le une fois et rechargez les onglets Leitstand ouverts. D'ici là, la page et le service ne correspondent pas.
4. Créez la prochaine tâche avec une preuve centrale.
5. Vérifiez vous-même les commandes de suppression, de déploiement et de migration placées dans un bloc suivi d'une redirection. Les formes figurent dans la dernière section.

Qu'est-ce qu'une preuve centrale ?

La preuve centrale est l'unique preuve qui mesure l'objectif de la tâche lui-même. Les nouveaux dossiers de tâche peuvent en porter une.

• aufgabe.py neu --kriterien-entfaellt ne fonctionne plus qu'avec --kernprobe "<text> | lauf | <kommando>".
• aufgabe.py abschliessen bloque tant que la preuve centrale est rouge, n'a jamais été mesurée ou est périmée.
• Si elle reste rouge et qu'une réponse de l'agent ne l'a pas mesurée, l'agent reçoit à la saisie suivante une ligne [kern].

Un rouge qui ne mesure rien de l'objectif ne compte pas. C'est le cas, par exemple, d'un programme introuvable, d'un mauvais chemin pytest ou d'un échafaudage de test manquant. À la définition, cela se termine par un code de sortie 2 et une indication. À la mesure, on lit « rot (Bedienfehler) ».

De plus, les exécutions de tests de phpunit, pest, paratest et php artisan test ne prouvent plus rien lorsqu'elles n'ont exécuté aucun test. Cela vaut aussi avec un code de sortie 0. Derrière des enveloppes comme composer test ou bash -c, l'outil ne le détecte pas.

Pour vous, cela signifie : « terminé » signifie que l'objectif lui-même a été mesuré, et pas seulement quelque chose autour.

Pourquoi l'agent s'arrête-t-il après chaque ajustement ?

Après chaque ajustement, l'agent montre ce qui a changé et comment cela a été vérifié. Puis il demande : « D'autres ajustements ou clôture ? » L'audit, la revue à froid, la documentation et le commit s'exécutent ensuite une fois pour l'ensemble du lot. Vous les lancez d'un mot.

Les verrous Bash restent armés. Il y a des exceptions :

• En autopilote, avec « sans questions » et sans terminal, la clôture s'exécute comme avant, à chaque modification.
• Les corrections d'erreurs dans le flux DEBUG s'exécutent comme avant, d'un seul tenant.
• Les workers pilotés par un orchestrateur ne s'arrêtent pas.

Pour vous, cela signifie : vous regroupez plusieurs ajustements, et l'audit et la revue s'exécutent une fois pour tous.

Quelle revue s'exécute quand ?

L'outil pruef-bedarf.py indique, pour chaque étape de contrôle et avec le motif, si elle est nécessaire. Les zones sensibles conservent les deux revues, même pour une modification d'une seule ligne. La liste de blocage couvre des zones sensibles comme la connexion, le paiement, le schéma de base de données, le déploiement, les dépendances et les secrets.

Rien de tout cela ne bloque. aufgabe.py abschliessen affiche le besoin et compte chaque semaine combien de fois une revue s'est exécutée sous le seuil. L'arbitre est le 15e agent de contrôle ; dans la 17.16, il y en avait 14.

Pour vous, cela signifie : les petites modifications sans zone sensible ne reçoivent plus de gros contrôle. Les modifications sensibles ne sont pas allégées.

Un verrou m'arrête-t-il maintenant plus souvent ?

À deux endroits, oui.

• Une commande qui commence par une variable, par exemple $X rm -rf …, est examinée comme si la variable n'était pas là. Si la valeur est inconnue devant des arguments de suppression, le verrou pose la question.
• Une copie par ssh depuis le répertoire personnel du serveur vers une destination extérieure à celui-ci, par exemple un répertoire web, est considérée comme un déploiement.

Cela a été mesuré sur un ensemble de commandes réelles. Aucune commande auparavant bloquée ne passe désormais.

Pour vous, cela signifie : plus de questions pour ces deux formes, mais aucune nouvelle perméabilité.

Quelles autres nouveautés ?

• Lien avec l'objectif : l'outil todo_ziel.py rattache les points ouverts aux objectifs de .goals/index.json. La liste des tâches montre les points sans objectif, le démarrage de session mentionne l'objectif.
• Leitstand : le nouvel onglet « Git » montre, par projet, les branches et les worktrees, quelle session travaille sur quoi et ce qui n'est pas encore dans main. Il ne fait que lire, n'a pas besoin de réseau et ne modifie rien.
• CodeGuardMaster : il affiche une notification sur l'ordinateur lorsqu'une question qui vous est adressée reste ouverte trop longtemps ou qu'une preuve centrale reste longtemps rouge. Sous macOS, il utilise osascript, sous Linux notify-send, sinon seulement le fichier meldungen.md.
• Détecteur de migrations : il signale dropForeign, dropUnique et dropPrimary comme [constraint]. Avec un down() vide s'ajoute [irreversible], code de sortie 1.
• design-beweis : il mesure les pages protégées par Basic-Auth via CG_DESIGN_HTTP_USER et CG_DESIGN_HTTP_PASS, uniquement vers sa propre adresse. Une session d'application se transmet avec --sitzung.
• session-orchestrator : chaque session peut porter un rôle librement formulé (rolle setzen selbst "<text>", cinq lignes au maximum). Il survit à la compaction. Après /clear, il a le plus souvent disparu.

Le paquet Claude compte désormais 5 modes, 7 gates, 15 hooks, 22 détecteurs, 31 skills, 15 agents de contrôle et 82 outils.

Quelles corrections sont incluses ?

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

• Le DECISION GATE affiche de nouveau la boîte de dialogue de question après le remplacement de guillemets. Jusqu'ici, la question était transmise sans dialogue.
• Le détecteur de migrations signalait jusqu'ici silencieusement les migrations Alembic comme « rien trouvé ». Elles apparaissent désormais comme UNSEEN et font passer l'exécution au rouge. Leur contenu n'est pas encore analysé.
• Quand jq manquait, l'installateur affirmait jusqu'ici que plus rien n'était contrôlé. C'était faux. L'avertissement indique désormais ce qui s'applique : les quatre verrous de commandes pour la suppression, le déploiement, la migration et le secret dans un commit bloquent toujours. Les autres ne contrôlent pas du tout sans jq, notamment le verrou d'écriture pour les exécutions sans surveillance. Le message mentionne 11 sur 15.
• Le détecteur de tests JS mute désormais réellement les fichiers dont le nom contient des caractères spéciaux, par exemple pages/[id].vue. Auparavant, l'exécution sans mutation était considérée comme réussie.
• Les détecteurs de tests JS et PHP terminent une exécution de mutation sans rapport lisible avec le code de sortie 2 (« Mutation nicht gemessen ») au lieu du code 0.
• En mode auto de Claude Code, l'autopilote n'est pas armé. La documentation le dit désormais.

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

La version Codex reçoit la preuve centrale, le point d'arrêt, les verrous renforcés et les corrections des détecteurs. On y trouve aussi design-beweis (non remesuré spécifiquement sous Codex), PATHEXT et les mentions légales autrichiennes. Différences avec Claude Code :

• Il n'y a pas d'arbitre. Pour la logique, la limite y est de 100 lignes.
• Le relecteur de plan est supprimé pour les petits plans : au plus deux consommateurs, un point d'entrée, pas de liste de blocage.
• Le point d'arrêt est supprimé « dans une exécution sans terminal avec les validations désactivées ».
• Le session-orchestrator, et donc les rôles par session, n'existe pas dans le paquet Codex.
• L'onglet Leitstand « Git », CodeGuardMaster, la ligne [kern], l'indication d'objectif au démarrage de session, l'avertissement jq, la remarque sur le mode auto et la correction du DECISION GATE ne font partie que de la version Claude.
• L'accueil Codex mentionne 81 outils.

Quelles limites restent ouvertes ?

Voici les principales limites ouvertes. D'autres figurent dans le changelog du portail client.

• Commandes dans un bloc suivi d'une redirection : l'article de la 17.16 annonçait la correction de cette faille dans la version suivante. Cela n'a pas été fait dans la 17.17. Vérification faite : les verrous de suppression, de déploiement et de migration s'y comportent comme dans la 17.16. Ils ne reconnaissent toujours pas ces commandes sous toutes leurs formes. Il n'y a pas de nouvelle échéance. Pour les commandes de cette forme, ne vous fiez pas aux verrous, mais vérifiez-les vous-même avant de les valider. Voici les formes concernées :

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

• Autopilote et point d'arrêt : lorsque l'autopilote est armé, l'indication n'écarte pas d'elle-même le point d'arrêt. L'exception ne figure que dans le texte de l'indication.
• CodeGuardMaster : si une exécution se bloque, le service ne démarre pas de seconde exécution sous macOS. Le blocage ne se signale pas de lui-même.

Pour vous, cela signifie : la recette est plus étroitement liée à l'objectif, le contrôle suit la taille de la modification. Une faille dans les verrous reste ouverte, et vous la vérifiez vous-même.

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

Sources

• Changelog Code Guardian 17.17 (paquet Claude et paquet Codex), dans le portail client

Version : 10.11.2026