08.01 — Code : 99% Claude, 1% Igor, intelligence : 50-50#

README#

A note to the reader#
This project is an experiment in AI-driven test engineering. In the interest of honesty about how it was built:
Claude Code Human
Code written 99% 1%
Intelligence 50% 50%
Almost every line was machine-written. The judgement behind it — what to test, what to distrust, when to dig and when to stop — was shared.

	Claude Code	Human
Code written	99%	1%
Intelligence	50%	50%

`CLAUDE.md`#

CLAUDE.md est un contrat de travail avec Claude qui définit :

Où vivent les fichiers (layout src/).
Conventions de code (TYPE_CHECKING guard, log factories, etc.).
Hard-won rules (« No tricks or hacks », « Teach the pattern, not the symptom », etc.).
Patterns approuvés (data-driven, scenario fragments, dispatch tables).
Patterns interdits (JS-click pour bypasser, time.sleep pour masquer une race condition, etc.).

Ces lignes sont lues par Claude à chaque session (ouverture d’un “chat”) pour le cadrer.

`CLAUDE.slim.md`#

Version courte du CLAUDE.md.
Mêmes règles, mais sans exemples ni justifications, sans l’expertise : juste les règles.

Holy Book (chapitre “Utiliser Ocarina avec l’IA”) :

Slim quand le contexte est chargé ; complet pour l’onboarding et les revues. En cas de divergence, le complet l’emporte.

C’est un mécanisme de gestion de la fenêtre de contexte : quand Claude doit charger beaucoup d’autres choses (du code, des SFD, etc.), on lui donne slim.md pour économiser des tokens.

Rappel du Holy Book#

Les trois pierres ancestrales#

1. CLAUDE.md à la racine du projet.
2. skills/ avec un <nom>/SKILL.md par procédure.
3. Règle de vérification : toute affirmation sur le SUT vient d'une observation
   (sonde, gh api, curl -v), jamais d'une inférence.

Ce sont les trois piliers d’Ocarina pour implémenter la collaboration humain ↔ IA.

`CLAUDE.local.md`#

# Local machine config

## chromedriver

Path: `/path/to/chromedriver`

## Ocarina source repos (git clones)

- **ocarina**: `/path/to/ocarina`
- **ocarina-example**: `/path/to/ocarina-example`

Fichier gitignored.

→ Claude doit lire les paths dans CLAUDE.local.md plutôt que de les hard-coder ou les chercher.
Si le fichier manque : Claude doit le créer en posant des questions à l’utilisateur pour être guidé.

Empirisme#

Phrase rituelle citée dans le Holy Book :

« Juste remarque, je suppose. Je vérifie empiriquement. »

Avant d’écrire un test basé sur ce qu’on pense que le SUT fait, on vérifie via :

Une sonde (write-a-probe skill).
gh api pour lire le code source.
curl -v pour observer la réponse HTTP.

C’est ce qui distingue le projet IA des suites e2e classiques : on ne suppose pas !
On vérifie, puis on encode.

Remonter, ne pas appliquer#

Holy Book :

Remonter, ne pas appliquer. Les skills produisent ; l’utilisateur décide.

Claude peut :

Analyser le rapport du dernier run (skill review-report).
Suggérer une catégorisation des fails (intentional gap / cross-browser / real regression).
Proposer une mise à jour de IDENTIFIED_GAPS.md.

Mais Claude ne décide pas :

Quelle catégorie est correcte → l’humain valide.
Si un gap doit être ajouté → l’humain confirme.
Si on doit modifier la spec → l’humain approuve (le skill update-frd-and-tests produit une diff, l’humain merge).

« Les tests gap sont reformulés, pas basculés »#

Citation :

Les tests gap sont reformulés, pas basculés au vert. Inverser l’assertion, renommer, déplacer la ligne dans le doc de stratégie, consigner la date dans IDENTIFIED_GAPS.md. Le tout via update-frd-and-tests.

Si un gap test était rouge (CURA ne valide pas la date) et qu’un jour CURA est patché (la date est maintenant validée), alors :

❌ Mauvaise approche : supprimer le test, le mettre en vert, retirer l’assertion.
✅ Bonne approche : garder le test, inverser l’assertion (« on s’attend à ce que la validation marche »), renommer (« Date validation works » au lieu de « Date validation gap »), mettre à jour IDENTIFIED_GAPS.md avec date de fix.

→ L’historique des gaps est préservé. Aucune amnésie.

« Les signaux des watchers sont négatifs uniquement »#

Citation :

Les signaux des watchers sont négatifs uniquement. Un watcher qui émet « login réussi » casse le contrat.

Expliqué ici : ../02-ocarina/07-watcher.md
Existe explicitement comme règle de discipline pour Claude.

« Distribué quand une ressource est partagée »#

Distribué quand une ressource est partagée. Dès que plusieurs workers se partagent une ressource plafonnée par le SUT (sessions, créneaux, quotas), la coordination passe par des primitives distribuées. Sinon, un cache local en mémoire suffit — à condition que les clés soient garanties uniques et que leur génération soit thread-safe.

C’est ce qu’incarne ocarina-example (cf. ../07-ocarina-example/08-caches-locks.md) : dogpile.cache.memory ou Redis selon la portée.

« mtime, pas nom de fichier »#

Mtime, pas nom de fichier. Les suffixes UUID sont aléatoires ; pick-* trie par mtime.

C’est-à-dire : pour piocher le dernier rapport / log / screenshot, on ne trie pas par nom (les UUIDs sont aléatoires). On trie par mtime (date de modif).

Tous les skills pick-screenshots, pick-logs, pick-reports suivent cette convention.

Discipline#

L’enjeu : éviter que Claude n’hallucine.
Les règles ci-dessus sont des contre-poids cognitifs pour la machine.

Sans elles, l’IA serait tentée :

D’inventer un test au lieu de vérifier le SUT.
De masquer une régression en mettant le test au vert.
De suggérer un watcher positif (« login réussi ») pour avoir l’air rassurant.
D’utiliser un cache local pour un quota distribué.
De consommer énormément de tokens en navigant péniblement dans les screenshots, logs et rapports.

CLAUDE.md est un système immunitaire.