Claude Code Harness Smoke Test : boucle de preuve de 15 minutes avant de faire confiance à un agent

Le premier vrai travail avec Claude Code n’a pas besoin d’une grande automatisation. Il a besoin d’un petit smoke test. Nomme les fichiers lisibles, les fichiers modifiables, les zones interdites et la preuve qui termine l’exécution.

L’intention est simple : savoir jusqu’où déléguer à un agent. Sur un site qui vend, la preuve doit inclure le PDF gratuit, Gumroad et la consultation, pas seulement un build local.

À lire aussi: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

Pourquoi ce modèle fonctionne

Un harness smoke test ne prouve pas que le modèle sera toujours sûr. Il prouve que l’environnement a des limites. Même une petite modification peut casser le formulaire PDF, le lien produit ou la consultation.

Quinze minutes se répètent facilement. On passe lecture, édition limitée, build, URL publique et capture avant d’élargir.

Flux de travail pratique

1. Écrire l’objectif en une phrase et limiter l’édition à trois fichiers
2. Déclarer secrets, paiement, données clients et déploiement comme zones interdites
3. Choisir avant l’édition la commande de preuve, le diff, l’URL et la capture
4. Pour articles et pages, vérifier PDF gratuit, Gumroad et consultation
5. Conserver la run card pour commencer le lendemain avec des preuves

Situation	Action sûre	Preuve
Nouvel article	Autoriser seulement corps et frontmatter; layouts et API restent en lecture	build et URL publique
Page produit	Modifier texte et ordre des cartes; vérifier chaque lien d’achat	contrôle Gumroad
Déploiement équipe	Commencer en lecture seule, puis autoriser une petite édition	diff et capture

Prompt et code à copier

Exécute un harness smoke test de 15 minutes pour ce dépôt. Ne fais pas encore de grande modification. Retourne objectif, fichiers modifiables, zones interdites, commandes de preuve, contrôles d'URL publique et CTA PDF gratuit/Gumroad/consultation.

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

Le code transforme une demande vague en run card. La même forme sert pour un modèle de PR, une checklist de publication ou une note avant consultation.

Trois exemples réels

Publication Astro

Limiter la modification au corps, heroImage et CTA. Un build vert ne suffit pas si le h1 public ou la CTA appartient à une autre page.

Petit changement UI

Même pour le texte d’un bouton, vérifier mobile et zone de clic. Si le bouton mène au produit, vérifier l’URL.

Première adoption équipe

Ne pas commencer par coder. Cartographier README, permissions, tests et zones interdites. Ce document devient l’ordre du jour.

Échecs à éviter

• Demander de tout améliorer élargit trop la portée.
• S’arrêter au build local masque les fallbacks et CTA obsolètes.
• Oublier Gumroad peut envoyer un débutant vers la mauvaise offre.

En multilingue, le slug peut être bon alors que le corps ou la CTA est ancien. Il faut regarder la page publique.

Relier PDF gratuit, Gumroad et consultation

Les lecteurs qui apprennent les commandes commencent par le cheatsheet gratuit. Pour permissions, CLAUDE.md, hooks, MCP ou CI, la Setup Guide est plus adaptée.

Pour les prompts de revue et debug répétés, utiliser 50 Prompt Templates. Pour un rollout d’équipe, passer par la consultation. Les options se comparent sur products.

À vérifier avant et après publication

Avant publication, vérifier frontmatter, heroImage, liens internes et Gumroad. Après publication, en mobile, regarder h1, début du texte et CTA. Un 200 ne suffit pas si c’est une page fallback.

Chiffres à suivre ensuite

Suivre recherche, démarrages PDF, clics Gumroad, visites produits et visites consultation. Si les PV montent sans clic produit, la CTA ne correspond pas au lecteur.

Revue opérationnelle de 30 minutes

Quand le harness smoke test passe en travail réel, la revue la plus utile arrive le lendemain. Lire le journal et noter portée autorisée, fichiers changés, commandes de preuve et pages publiques vues. Ne pas écrire seulement “vérifié”. Garder le reçu exact : h1 mobile, début du texte, zone CTA, lien Gumroad et chemin consultation.

Séparer confiance de l’opérateur et comportement lecteur. Côté opérateur, vérifier zones interdites, build, même slug public et absence de corps anglais dans les pages traduites. Côté lecteur, vérifier l’étape naturelle : PDF gratuit pour les commandes, Gumroad pour un blocage répété, consultation pour la conception du workflow.

Transformer la revue en une règle future. Ne pas ajouter dix règles après chaque souci. Ajouter une règle qui aurait évité l’erreur : demander avant un layout, cliquer chaque URL Gumroad en production, ou capturer le début du texte pour chaque langue. Une petite règle exécutée chaque jour vaut mieux qu’une longue politique.