Exécuter un plan. Conserver chaque tentative.

1. Choisir un journal de départ

Téléchargez le journal de démarrage et placez-le dans le dossier private de votre copie du projet, sous le nom runner-demarrage.json. Vous pouvez d’abord l’importer dans le Journal de collecte du site pour relire la question, les scénarios et sa configuration. Ses deux emplacements restent vides ; télécharger ou importer ce fichier ne lance aucun essai.

Pour votre propre travail, complétez un protocole dans le Studio et joignez les cas utiles, puis téléchargez sa session JSON. La commande init prépare un journal avec la configuration Cloudflare explicite du runner. Elle garde le cadrage du Studio ; les paramètres réellement envoyés devront être relus dans le plan. Choisissez des chemins de sortie neufs pour conserver les étapes précédentes.

npm run runner -- help

npm run runner -- init --studio private/session-studio.json --out private/journal-cloudflare.json

2. Préparer puis lire les requêtes exactes

La commande plan prépare un dossier local sans appel à un modèle. L’exemple choisit une comparaison, limite les sorties à 128 tokens par appel et réserve au maximum quatre tentatives, reprises comprises. Les deux requêtes initiales ne deviennent pas quatre essais prévus : le plafond garde une marge pour une reprise explicitement décidée.

Ouvrez private/essai-01/plan.md et plan.json : relisez chaque requête, le modèle, les paramètres, les emplacements et l’empreinte SHA-256 affichée. Le runner reprend les textes français des copies de cas jointes ; il ne traduit pas et ne réutilise pas implicitement un prompt saisi dans une ancienne tentative. Les emplacements déjà occupés doivent faire l’objet d’un autre choix de bloc ou d’un nouveau journal.

La seed du plan détermine le mélange des comparaisons. L’ordre A/B ou B/A de chaque comparaison reste celui préparé dans le Studio. Cette seed d’ordre est distincte d’une éventuelle seed transmise au fournisseur. Aucune des deux ne garantit que le service renverra deux fois les mêmes mots.

npm run runner -- plan --in private/runner-demarrage.json --out private/essai-01 --max-calls 4 --max-tokens 128 --timeout-ms 30000 --seed 20260908 --start 1 --pairs 1

3. Comprendre ce qui sera envoyé

Cette version utilise seulement @cf/meta/llama-3.2-3b-instruct, via l’API REST Cloudflare Workers AI. Elle traite les prompts français joints, sans historique de conversation ni outils. Le corps de chaque requête contient le texte de la variante, les instructions système si vous en avez renseigné et les paramètres acceptés par le runner. Une configuration contenant un historique ou des outils est refusée plutôt qu’ignorée.

Le jeton API sert à autoriser la requête auprès de Cloudflare. Gardez CF_API_TOKEN et CF_ACCOUNT_ID dans l’environnement de votre terminal ; ne les copiez ni dans les scénarios, ni dans le journal, ni dans le site. Les réponses et les reçus sont conservés dans le dossier local d’exécution. Le journal exporté permet la lecture dans le navigateur ; conservez son dossier compagnon pour retrouver les traces réseau.

Utilisez des scénarios synthétiques que vous avez relus. Le plan peut contenir tout ce que vous avez ajouté aux textes sources ou aux instructions : son acceptation porte sur ces données exactes. La comparaison locale dans le navigateur et l’exécution distante par le terminal sont deux traitements différents.

4. Vérifier le compte et les limites

Cloudflare documente une allocation de 10 000 neurones par jour, réinitialisée à 00:00 UTC. Sur Workers Free, les opérations au-delà de l’allocation échouent ; Workers Paid peut facturer les dépassements. Vérifiez l’offre réellement active et l’usage du compte dans votre tableau de bord. Référence consultée le 8 septembre 2026 : la page tarifaire officielle reste la source à revoir avant une campagne.

Le runner exige CF_ACCOUNT_PLAN=free et le drapeau --free-account-confirmed pour une commande d’exécution. Ces déclarations ne vérifient pas votre abonnement. Le plafond local d’appels ne connaît pas les autres usages du même compte et ne réserve pas une partie du quota quotidien. La consommation éventuellement rapportée par le fournisseur et une estimation locale ne sont pas une facture vérifiée.

Le code borne les sorties à 1024 tokens par appel au maximum et les réponses HTTP à 65 536 octets. Les textes destinés au Journal restent limités à 12 000 caractères. Un dépassement ou une réponse incomplète doit garder son état explicite ; une sortie coupée ne devient pas un texte intégral certifié.

5. Accepter le plan relu, puis lancer

Avant cette étape, ouvrez le plan produit, vérifiez les textes et ses limites, puis relevez son empreinte. Remplacez manuellement EMPREINTE_SHA256_DU_PLAN dans la commande ci-dessous par la valeur de ce plan précis. Ne recopiez pas une empreinte trouvée dans un autre dossier. Pour réviser le plan, créez un nouveau dossier et relisez-le ; ne modifiez pas plan.json à la main. L’empreinte protège la correspondance du fichier accepté, pas la qualité de sa méthode.

Cette commande effectue les appels distants. Une seule requête est traitée à la fois. Les tentatives et les points de reprise sont écrits localement : contrairement aux ateliers du navigateur, le runner conserve son avancement sur disque. Une réponse reçue n’est pas automatiquement sélectionnée pour la Revue et n’est pas présentée comme relue humainement.

npm run runner -- run --dir private/essai-01 --accept-plan "EMPREINTE_SHA256_DU_PLAN" --free-account-confirmed

6. Traiter une interruption sans effacer la tentative

Après une interruption, reprenez le même dossier. Une requête dont l’envoi a commencé peut avoir été traitée par le fournisseur alors que votre machine n’a pas reçu la réponse. Cet état demeure incertain : recommencer peut consommer une nouvelle fois le quota. Il n’existe pas de relance automatique destinée à faire disparaître cette incertitude.

Vous pouvez reconnaître cette incertitude sans refaire l’appel : la commande acknowledge ajoute votre raison, conserve le reçu incertain et ne rembourse pas sa place dans le plafond. Remplacez UUID_DE_LA_TENTATIVE par l’identifiant relevé dans votre rapport. La commande resume peut ensuite traiter les requêtes jamais commencées. Reconnaître l’incertitude ne crée ni réponse manquante ni preuve de ce qui s’est passé chez le fournisseur.

Examinez le reçu et son état avant de décider d’une reprise. Une nouvelle tentative doit référencer celle qu’elle reprend et garder une raison. Les erreurs, les délais dépassés et les réponses précédentes restent des pièces du dossier. Une série de tentatives jusqu’à obtenir la formulation souhaitée ne constitue pas la répétition prévue dans le protocole.

Si un arrêt brutal laisse le dossier verrouillé, vérifiez d’abord que le processus précédent est arrêté. La commande unlock refuse d’agir si son identifiant de processus est encore présent ; elle consigne votre raison et n’effectue aucun appel. Libérer ce verrou ne résout pas une tentative incertaine : relisez ensuite le rapport pour décider de la suite.

npm run runner -- acknowledge --dir private/essai-01 --attempt "UUID_DE_LA_TENTATIVE" --reason "Incertitude reconnue ; continuer sans réexécuter cet appel"

npm run runner -- resume --dir private/essai-01 --accept-plan "EMPREINTE_SHA256_DU_PLAN" --free-account-confirmed

npm run runner -- retry --dir private/essai-01 --attempt "UUID_DE_LA_TENTATIVE" --reason "Raison de la reprise après examen du reçu" --accept-plan "EMPREINTE_SHA256_DU_PLAN" --free-account-confirmed

npm run runner -- unlock --dir private/essai-01 --reason "Ancien processus arrêté et dossier vérifié"

7. Revenir au journal, puis à la Revue

Gardez une copie JSON du dossier d’exécution avec ses reçus détaillés. Exportez aussi le journal vers un nouveau fichier JSON, puis importez ce compagnon dans la Collecte. Vous y retrouvez les tentatives, leurs textes et leur provenance déclarée. Choisissez explicitement les réponses A et B que vous souhaitez relire et préparez le dossier de Revue. Le rapport du runner décrit l’exécution ; il ne calcule pas une asymétrie de jugement.

Pour reprendre votre sauvegarde sur une autre machine, restore recrée un dossier neuf à partir du rapport JSON complet. Le plan, son empreinte, les reçus et les tentatives sont conservés ; aucun appel n’est envoyé. Utilisez ensuite resume avec --dir private/essai-restaure et l’empreinte de ce plan relu. Un appel commencé sans résultat durable reste incertain et doit être examiné avant de continuer. Le simple journal destiné à la Collecte ne remplace pas cette sauvegarde complète.

Pour examiner une modification de consigne ou de configuration, conservez une référence et préparez un autre journal pour le rejeu. Le Retest rapproche ensuite les quatre textes et leurs conditions. Les fichiers ne démontrent ni une origine certifiée, ni une causalité, ni la validité d’un benchmark. Les limites, les contrôles et les lectures humaines restent nécessaires.

npm run runner -- report --dir private/essai-01 --out private/dossier-essai.json

npm run runner -- restore --in private/dossier-essai.json --out private/essai-restaure

npm run runner -- export-journal --dir private/essai-01 --out private/journal-apres-essai.json

npm run runner -- report --dir private/essai-01 --out private/rapport-essai.md