Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Preuves d'exécution

Statut : Actif Portée : état actuel Dernière revue : 2026-08-25 Responsable : runtime AX Code

Chaque session AX Code est enregistrée pendant qu’elle s’exécute. Cette page couvre les commandes qui transforment cet enregistrement en quelque chose que vous pouvez revoir, comparer, exporter et annuler.

Utilisez-la lorsqu’un agent a terminé et que vous devez répondre : qu’a-t-il fait, quel était le risque, comment cela se compare-t-il à une autre tentative, et comment revenir en arrière ?

Ce qui est enregistré

Pendant une exécution, AX Code écrit deux choses indépendantes :

• Un journal d’événements typé — décisions de routage, activité du modèle, frontières d’étapes, appels d’outils et résultats d’outils. C’est la source de graph, replay, compare, trace et audit.
• Des instantanés de fichiers — capturés dans un magasin d’objets Git qui vit hors de votre dépôt, sous le répertoire de données d’AX Code, en utilisant refs/snapshots/<hash>. Votre arbre de travail et le .git/ de votre projet ne sont pas modifiés pour les stocker.

Les deux sont locaux. Rien n’est téléversé.

Reconstruire une exécution

ax-code graph <sessionID>

Reconstruit la session comme un graphe d’exécution : durée, résumé de risque, comptes de jetons, agents utilisés, et chaque étape avec ses appels d’outils et ses chronométrages.

## Session ses_01H8XK

Duration: 9m 54s | Risk: HIGH (53/100) | Tokens: 167,650 in / 18,494 out
Agents: architect

### Step 1 (8s) | tokens: 12263/587

- read: api.ts → ok (5ms)
- grep: rateLimit → ok (12ms)

--format sélectionne des sorties alternatives, y compris Mermaid et une vue de topologie, lorsque vous voulez le graphe dans un autre outil.

Notez qu’il s’agit du graphe d’exécution de session — ce que l’agent a fait. Ce n’est pas le graphe de code du dépôt ; celui-ci est ax-code index et la couche d’intelligence du code.

Comparer deux exécutions

ax-code session compare <sessionA> <sessionB>
ax-code session compare <sessionA> <sessionB> --deep

Signale le delta de risque, les fichiers modifiés, les comptes d’échecs d’outils, le chemin de décision suivi par chaque exécution, et les comptes par type d’événement. --deep ajoute une analyse de divergence au niveau des étapes par comparaison de rejeu.

Cela compare des exécutions, pas le code source. Cela répond à « la deuxième tentative a moins bien scoré — où a-t-elle divergé », et non à « montre-moi le diff de code ».

Un usage typique consiste à choisir entre deux stratégies pour la même tâche :

  Risk Comparison
  ----------------------------------------
  Score: 53 → 93 (+40) ↑
  Level: HIGH → CRITICAL
  Files: 8 → 25
  Failures: 0 → 15

Inspecter le journal d'événements enregistré

ax-code session replay <sessionID> --mode summary
ax-code session replay <sessionID> --mode verify
ax-code session replay <sessionID> --mode reconstruct
ax-code session replay <sessionID> --mode export

verify vérifie la cohérence du journal enregistré. reconstruct reconstruit le flux d’étapes à partir des événements. export écrit un paquet de rejeu portable.

Le rejeu reconstruit ; il ne réexécute pas. Il ne relance pas les modèles, ne réinvoque pas les outils et ne reproduit pas l’état externe. Le mode execute prépare un flux reconstruit pour une comparaison programmatique avec l’original et est destiné aux tests, pas à relancer le travail.

Lire les signaux de risque

ax-code risk <sessionID>
ax-code risk <sessionID> --explain
ax-code risk <sessionID> --json

Le score est une heuristique déterministe dérivée des signaux enregistrés, notamment le nombre de fichiers modifiés, le fait que le changement couvre plusieurs zones de premier niveau, le nombre d’appels d’outils échoués, le fait qu’une validation ait tourné, l’existence d’un instantané de diff, l’ampleur de la surface d’API touchée, la façon dont l’exécution s’est terminée (une porte d’achèvement bloquée ou une fin par limite d’étapes ou par blocage ajoutent toutes deux du poids), et le fait que des chemins sensibles à la sécurité aient été touchés. Chaque facteur contributif est listé avec son poids, ainsi que des atténuations suggérées.

C’est une aide à la revue. Ce n’est pas une probabilité, une confiance calibrée, ni une affirmation que le code est sûr. Un score LOW sur un changement non vérifié signifie encore que le changement n’est pas vérifié.

Annuler avec précision

Les instantanés de fichiers fonctionnent dans les dépôts Git et les répertoires de projet ordinaires lorsque Git est installé et que snapshot est activé. AX Code garde son magasin Git d’instantanés hors de votre projet ; il ne crée pas de répertoire de projet .git. Les règles d’ignorance et les exclusions de chemins non pris en charge s’appliquent encore.

Le retour arrière du TUI annule les messages et les changements de fichiers capturés. Avec snapshot: false, ou pour des tours plus anciens qui n’ont jamais capturé de ligne de base, il ne peut annuler que les messages ; les modifications de fichiers restent sur le disque. Activer les instantanés maintenant ne peut pas reconstruire des contenus de fichiers antérieurs. Un tour capturé sans changement de fichier n’a rien à restaurer non plus.

ax-code session rollback <sessionID> --list      # show recoverable points
ax-code session rollback <sessionID> --dry-run   # show what would change
ax-code session rollback <sessionID> --step 4    # restore one step
ax-code session rollback <sessionID>             # restore the whole session

--list combine des événements d’étape durables avec le détail du graphe d’exécution, afin que vous puissiez cibler une étape précise plutôt que d’annuler toute l’exécution. --dry-run utilise le même planificateur de retour arrière que l’application et liste les sessions déléguées dont le registre de fichiers contribue au résultat.

Le retour arrière suit les sessions enfants imbriquées lorsqu’elles ont écrit dans le répertoire de travail exact du parent. Il restaure leurs changements de fichiers après la frontière tout en conservant leurs transcriptions. Les descendants qui s’exécutent dans un autre worktree ou répertoire sont exclus, et le retour arrière échoue en mode fermé si une session incluse est encore en cours.

Frontières à connaître avant de vous y fier : le retour arrière restaure à partir d’instantanés pris pendant l’exécution. Un fichier qui n’a jamais été instantané — parce qu’il a été modifié hors de la session, ou qu’il n’était pas dans un état récupérable — ne peut pas être restauré ainsi. Utilisez d’abord --dry-run pour tout ce qui est conséquent.

Essayer une autre stratégie

ax-code session branch <sessionID>
ax-code session branch <sessionID> --from <messageID>

Fourche l’état stocké de la session afin qu’une deuxième tentative parte d’un point choisi au lieu de repartir de zéro.

Cela fourche l’état de session — messages et objectifs. Ce n’est pas une branche Git ni un worktree. Pour des candidats Git isolés, voir Changements multi-modèles vérifiés.

Diagnostiquer

ax-code session trace <sessionID>
ax-code session trace <sessionID> --logs

Diagnostics appuyés sur le rejeu, avec une chronologie notée selon le risque. --logs bascule vers l’analyse héritée du fichier journal au lieu des événements de rejeu, ce qui est utile lorsque vous enquêtez sur un problème opérationnel plutôt que de revoir un changement.

Exporter les preuves

ax-code audit export --all --since 2026-08-01     # JSON Lines
ax-code audit export --all --risk HIGH            # filter by minimum risk
ax-code audit report <sessionID>                  # Markdown report
ax-code audit otlp <sessionID>                    # OpenTelemetry spans
ax-code audit prune --days 90                     # delete old events

JSONL et OTLP rendent l’enregistrement d’exécution consommable par votre propre pipeline de revue ou d’observabilité. Le rapport Markdown est destiné aux humains qui joignent des preuves à une demande d’intégration ou à un dossier de changement.

Le parcourir

ax-code run-report                 # latest session
ax-code run-report --index         # session index

Ouvre le rapport d’exécution local dans un navigateur, avec le résumé de l’exécution, la chronologie, les changements, l’état de validation, le détail du risque, les informations de branche et les points de retour arrière. Le serveur ne se lie qu’à la boucle locale.

Pages liées

• Assurance d’objectif — contrôles d’acceptation exécutables et fraîcheur des sources pour les objectifs longs
• Pourquoi AX Code — à quoi sert cette couche de preuves
• Changements multi-modèles vérifiés — produire des candidats qui valent la comparaison
• Couche sémantique — enveloppes de provenance sur les réponses du graphe et de LSP
• Rapport d’exécution — la vue au niveau de l’espace de travail et le rapport par session