Vérifier les éléments probants

Qu’un Agent dise « implémenté » ne suffit pas. Chaque explication vient avec ses éléments probants : le code qu’il a lu, les tests qu’il a lancés, les traces d’exécution et les captures d’écran, à un clic pour les vérifier. Quand quelqu’un pose la question, vous pouvez montrer l’endroit exact.

Ce que contiennent les éléments probants

Ouvrez « Éléments probants » dans la note. Les types d’éléments habituels sont :

4export const GRACE_DAYS = 7;56export function openGrace(subscription, failedAt) {7  if (subscription.graceEndsAt !== undefined) {8    return { ...subscription, lastChargeAttemptAt: failedAt };9  }10  return {11    ...subscription,12    graceEndsAt: addDays(failedAt, GRACE_DAYS),13    lastChargeAttemptAt: failedAt,14  };15}1617export function inGrace(subscription, now) {18  return subscription.graceEndsAt !== undefined19    && now < subscription.graceEndsAt;20}

Les sorties de commande, les diffs et les captures d’écran viennent des traces que l’Agent a laissées pendant l’implémentation. Noea garde, pour chaque tour, les commandes lancées et les captures d’écran prises, si bien qu’une explication peut les citer directement.

Regarder un emplacement de code

Un emplacement de code au milieu d’une phrase s’affiche en général comme le nom d’une fonction ou d’une variable, par exemple openGrace ; sinon il s’affiche comme une pastille « fichier:ligne », par exemple grace.ts:6-18. Si une explication cite deux fichiers du même nom, la pastille ajoute le dossier parent.

Posez le pointeur sur un nom ou une pastille pour voir le chemin complet, la plage de lignes et le symbole. Cliquez dessus et le panneau de code s’ouvre à droite sur ce fichier, aux lignes citées. Si le fichier est encore tel qu’un tour d’implémentation l’a laissé, les changements de ce tour sont superposés au fichier entier, ce qui permet de voir quel tour a écrit ces lignes. Le menu contextuel permet d’ouvrir le fichier avec l’application par défaut, de l’afficher dans le Finder ou de copier son chemin.

Si le code a bougé depuis, les numéros de ligne de la pastille et l’endroit où elle mène suivent sa position actuelle. Si le code cité a changé et que seul son nom est retrouvé, la pastille est atténuée ; si le fichier a disparu ou si le code est introuvable, la pastille est atténuée et barrée, et le survol en donne la raison. Dans les deux cas, l’explication doit très probablement être analysée à nouveau.

Jusqu’où vont les éléments probants

Quand vous regardez un élément, commencez par distinguer de quel type il s’agit :

Expliquer et Analyse reposent surtout sur la lecture du code et des éléments existants ; ils ne relancent pas les tests, les builds ou l’application à chaque fois. L’Agent ne vérifie quelque chose que lorsque la lecture du code ne suffit pas à établir un fait dont dépend la conclusion. De bons éléments probants disent ce qu’ils n’ont pas vérifié, par exemple « Non lancé contre le vrai prestataire de paiement ; les résultats des prélèvements viennent d’une doublure de test. » Quand les éléments sont minces, qu’aucune implémentation n’a été trouvée ou que l’intention est ambiguë, les éléments probants et les points d’attention doivent le dire clairement plutôt que d’offrir une conclusion qui n’a que l’air d’être certaine.

Gardez aussi en tête qu’une explication est un compte rendu d’analyse avec ses éléments probants, et non un certificat. Qu’un Agent vérifie l’implémentation d’un autre Agent ne rend pas le résultat plus sûr en soi. La valeur des éléments probants, c’est que vous pouvez les ouvrir et les vérifier, et non que l’explication dise « confirmé ».

Captures d’écran et interface

Certains comportements ne se règlent pas par le code seul, par exemple savoir si un avis apparaît vraiment dans l’interface. Si l’Agent a pris une capture d’écran pendant l’implémentation, l’explication peut la lister comme élément probant, par exemple « Pendant la période de grâce, un avis apparaît en haut de la page de réglages de l’équipe. »

Cliquez sur la miniature pour l’agrandir. Notez quelle page elle montre, dans quel état, et quelle exécution l’a laissée : une capture d’écran prouve à quoi ressemblait l’interface à ce moment-là ; si le code a changé depuis, l’interface a pu changer aussi.

Vérifier élément par élément

Quand vous vérifiez les éléments probants, demandez-vous pour chacun :

• Cette référence pointe-t-elle vers ce dont parle cette partie de l’intention ?
• Quels cas les tests couvrent-ils, et les cas limites en font-ils partie ?
• Le résultat appuie-t-il vraiment la conclusion de l’explication ?
• Les éléments probants disent-ils ce qui n’a pas été vérifié ?

Par exemple, les éléments de la période de grâce disent « tests de la période de grâce lancés : les 6 passent », tandis que les points d’attention notent qu’« aucun test ne couvre le cas où la troisième tentative réussit. » Vous savez désormais que ce chemin repose sur la seule lecture du code, sans exécution pour le prouver.

Quand les éléments probants ne suffisent pas

S’il manque un cas essentiel, survolez le paragraphe, cliquez sur « Poser une question à ce sujet » à sa gauche et demandez à l’Agent de le vérifier :

Ajoutez un test : la troisième tentative réussit au jour 6 de la période de grâce, donc l’abonnement revient à la normale et n’est pas rétrogradé. Donnez-moi le résultat une fois lancé.

Quand l’Agent a terminé, Noea explique le tour de lui-même ; si vous avez désactivé cela, cliquez sur « Analyse » à gauche du paragraphe. La nouvelle explication liste cette exécution comme élément probant.

Si la conclusion de l’explication ne correspond pas à ses éléments probants, ou si vous pensez que l’Agent a mal lu votre intention, posez aussi la question ici, et ne changez pas votre intention pour l’adapter au code. Voir Consigner ce que vous avez tranché.