Preuves
Les preuves fixent la barre qu’une task doit franchir avant de passer : un plan de test qu’un humain peut rejouer, et une preuve qui montre que le travail se comporte bien. La barre se règle par transition, et c’est le serveur qui la tient.
Les preuves s’exigent par transition
Il n’y a pas de politique de test à l’échelle du projet. Chaque transition d’un workflow porte les preuves qu’elle exige : vous pouvez demander une vidéo sur in_review → done sans la demander sur todo → in_progress. Elles se cochent dans l’éditeur de workflow, sous Proof required before transition.
| Preuve | Satisfaite quand |
|---|---|
branch | Une branche git est attachée à la task. |
pullRequest | Une pull request est attachée, quel que soit son état. |
tests | Au moins une preuve de test est revenue, et aucune n’a échoué. |
acceptanceCriteria | La demande porte au moins un critère, et aucun ne reste pending ou failed. |
testPlan | La task porte un plan de test dont chaque étape est tranchée. |
capture | Une preuve est attachée — de la nature qu’exige la technologie (ci-dessous). |
Sous une transition strict, une preuve manquante est refusée au change_task_status — le passage n’a pas lieu. Sous advisory, elle est consignée dans la piste d’audit à la place. L’agent interroge get_transition_policy d’abord : il ne modifie rien et répond ce qui manque encore, dans les mots que le refus emploierait.
Une capture se juge sur ce qu’elle montre
Une capture d’écran ne prouve rien d’une API, et un corps de réponse ne prouve rien d’un écran. C’est donc la technologie du dépôt — réglée dans Paramètres du projet → Repositories — qui décide la nature de preuve que la case capture accepte, et qui nomme l’outil qui la produit.
| Technologie | Outil | Ce qu’il faut attacher |
|---|---|---|
frontend | Playwright | Une capture d’écran, ou une vidéo quand le comportement n’existe qu’en mouvement. |
backend | cURL | La réponse elle-même — ligne de statut et corps, telle qu’elle revient. |
mobile | Maestro | Une capture d’écran, ou une vidéo pour un parcours qui traverse plusieurs écrans. |
mcp | Un appel LLM | La réponse que le tool a renvoyée, mot pour mot. |
documentation | Le document rendu | Le contenu tel qu’un lecteur le voit — le rendu interprété d’un .md, pas la source brute. |
monorepo | Découverte | Rien par lui-même : la task déclare ce qu’elle a touché (ci-dessous). |
Un ticket typé docs réclame le document quelle que soit la technologie du dépôt : ce qu’il livre est le document, et ce qui le prouve est son contenu. Un dépôt sans technologie n’exige rien de plus que la case elle-même — rien ne se durcit dans votre dos.
Un monorepo n’a pas de technologie propre
CodBoard ne lit jamais vos fichiers : il ne peut pas savoir quelles apps un changement a touchées. Sur un dépôt réglé en monorepo, l’agent les déclare avec set_task_technologies — et tant qu’il ne l’a pas fait, le passage est refusé en nommant la déclaration manquante. Chaque technologie déclarée exige ensuite une preuve de sa nature : toucher l’API et l’écran, et une seule réponse cURL ne suffit plus.
get_transition_policy({ id, toStatus: "in_review" }) { "proofExpectation": { "technologies": ["frontend", "backend"], "declared": true, "natures": ["visual", "response"], "recipes": [{ "tool": "playwright", … }, { "tool": "curl", … }] }, "missing": ["a capture of the nature the technology demands"], "wouldBlock": true }
Anatomie d’un plan de test
Un plan de test est une liste ordonnée d’étapes. Chaque étape associe une instruction, le résultat attendu et la preuve qui va avec, pour qu’un relecteur puisse rejouer la vérification au lieu de vous croire sur parole. Ce qui se regarde vit derrière une URL — CodBoard l’héberge pour vous si la capture est là où un navigateur ne va pas. Ce qui se lit est son propre texte, attaché tel qu’il a été enregistré.
Étape 1 Ouvrir /login en largeur mobile → le formulaire tient, pas de scroll horizontal capture jointeÉtape 2 curl -s -i http://localhost:3000/api/export → 200, content-type: text/csv, deux lignes réponse jointe
Les preuves se configurent sur les transitions d’un workflow, et la technologie sur le dépôt — dans CodBoard, jamais dans votre repo. L’agent les lit au démarrage de session et avant chaque passage.