Utiliser Ocarina avec l'IA

Un setup de travail : un cycle de test complet construit avec Claude Code et Ocarina, contre la démo publique Katalon CURA.

📖 Munissez-vous de l'exemple avec IA comme référence.

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.

CLAUDE.md

Deux variantes. CLAUDE.md est complet (règles + organisation du projet, hiérarchie, conventions, forme CI, gabarit de PR). CLAUDE.slim.md ne contient que les règles. Slim quand le contexte est chargé ; complet pour l'onboarding et les revues. En cas de divergence, le complet l'emporte.

Les étapes d'onboarding (venv, pip install, la batterie de skills copiée dans Claude Code, ruff / mypy / pre-commit, smoke-check du runner) vivent dans setup-environment.

Les règles :

Les tests de sécurité sont fonctionnels et statiques, jamais actifs. Pas de payloads, pas de requêtes forgées, pas de manipulation du DOM via DevTools. Les scénarios black-hat passent par une UI normale.

Utiliser des constantes. Les valeurs nommées ne sont pas inlinées.

Les datasets sont des décisions humaines. Proposer, PAS exécuter.

Vérifier empiriquement le comportement du SUT. Sonde, gh api, ou curl -v. Jamais d'inférence. Re-dériver à chaque fois : une sonde ne répond que pour ce qu'elle a exécuté ; un diagnostic antérieur ne répond que pour cette exécution-là.

Chaque règle contient un "pourquoi" d'une ligne.

skills/

Un fichier Markdown par skill, frontmatter YAML + corps. Dix familles.

Review (13)

Lectures statiques ; remontent des constats.

• review-spec-gaps — questions de clarification sur les SFD.
• review-watcher-misuse — watcher.report(...) principe de « négatif uniquement ».
• review-compartmentalisation-leaks — URLs, sélecteurs, nombres magiques aux mauvais endroits.
• review-dead-code — connecteurs / POMs / scénarios / suites / fragments / constantes non utilisés ; au cas par cas : supprimer, mettre en incubateur (<racine-source>/incubator/, arbre de dépendances préservé), ou conserver.
• review-report — classifie chaque FAIL / SKIP d'une exécution.
• Et : review-type-ignore, review-match-candidates, review-unverified-transitions, review-submit-dispatchers, review-comment-drift, review-suite-stability, review-intent-collisions, review-watcher-emissions.

Analyse (4)

• analyse-flakiness — élargit le filet des erreurs transitoires ; les morts chroniques sont de vraies flakes.
• analyse-fixture-flakiness — instrumente setup/teardown ; rend visibles les contaminations entre tests.
• analyse-watcher-flakiness — analyse la fiabilité des watchers.
• analyse-screenshot-flakiness — regroupe par (test, étape, navigateur), détecte les différences.

Black-hat (6)

• business-attack-ideation — faire tomber le produit.
• incoherence-attack-ideation — chaque étape légale prise isolément, incohérent quand combinées pour construire un ensemble invalide.
• persistence-attack-ideation — tentatives répétées sur une action bloquée.
• permission-appropriateness-audit — le modèle d'accès est-il lui-même approprié ?
• bfcache-exposure-ideation — attaques BFCache.
• lateral-resource-ideation — IDOR via la barre d'adresse uniquement.

Comprehend (4)

• assess-test-base — catalogue la base de test.
• assess-ecosystem — recherche publique bornée, plafonnée par budget de tokens.
• understand-sut-constraints — bornes SUT qui cassent les tests parallèles.
• understand-ocarina — parcourt la doc.

Pick (3)

Par mtime, jamais par nom de fichier.

• pick-screenshots, pick-logs, pick-reports.

Author (8)

Chacun produit un livrable.

• empiricism — vérifier avant d'encoder ; ne pas écraser un test gap en échec intentionnel.
• write-a-probe — script jetable, gitignored.
• write-test-strategy — génère le document de stratégie de test à partir de la suite (scope, types, tables de couverture, arbre du cycle, pass/fail, gaps, matrice CI).
• extend-coverage — étend la couverture à partir du patrimoine existant.
• update-frd-and-tests — propage une mise à jour de spec.
• manual-reproduction-guide — repro exécutable par un humain.
• manage-backlog — BACKLOG.md.
• pr-report — rapport de PR adapté au type.

Refactor (2)

• refactor-fragmentation — DRY selon préférence utilisateur.
• introduce-pom-retries — retries internes aux POMs, avec dédoublement (first-try + with-retries).

State (1)

• question-state — interroger l'environnement avant de croire un résultat.

Setup (1)

• setup-environment — venv, outillage de dev, la batterie de skills Ocarina copiée dans le répertoire de skills de Claude Code, chemins de drivers dans CLAUDE.local.md, boucle pré-commit, smoke-check du runner.

Run (1)

• propose-visual-review — avant un lancement local, propose --not-headless (regarder le navigateur exécuter) vs headless (comme en CI). Compose la commande ; l'utilisateur la lance.

Chaînes récurrentes

Cycle en échec : review-report → analyse-* → write-a-probe → trouvailles propagées dans IDENTIFIED_GAPS.md / les SFD / un commentaire de scénario → sonde supprimée.

Scénario black-hat prometteur : empiricism → extend-coverage (souvent en échec intentionnel).

Changement de spec : update-frd-and-tests (SFD d'abord, tests ensuite). Les tests gap sont reformulés, pas basculés.

Nouvelle primitive Ocarina : understand-ocarina d'abord, écriture ensuite.

Lorsque l'on est sur le point de lancer une exécution : propose-visual-review — headed (--not-headless) ou headless (comme en CI) ? Compose la commande ; l'utilisateur la lance.

Discipline

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

Empirique plutôt qu'assertif. Toute affirmation SUT est observée, citée, datée. Phrase rituelle : « Juste remarque, je suppose. Je vérifie empiriquement. »

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.

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

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.

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

Ce que ce setup n'est pas

• Ne génère pas de tests de façon autonome.
• Ne patche pas les hallucinations en CI ; un échec déclenche review-report + analyse-*.
• Ne réécrit pas la spec ; seul update-frd-and-tests le fait, avec une ligne de révision.
• Ne fait pas de tests de sécurité actifs. Jamais.

Ressources exposées

• https://mojo-molotov.github.io/ocarina-holy-book/llms.txt
• https://mojo-molotov.github.io/ocarina-holy-book/llms-full.txt
• https://mojo-molotov.github.io/ocarina-holy-book/CLAUDE.md
• https://mojo-molotov.github.io/ocarina-holy-book/CLAUDE.slim.md
• https://mojo-molotov.github.io/ocarina-holy-book/ocarina-ru.pdf
• https://mojo-molotov.github.io/ocarina-holy-book/ocarina-en.pdf
• https://mojo-molotov.github.io/ocarina-holy-book/ocarina-fr.pdf

---

Oh wow !
Tu l'as déjà bien bidouillé à ta sauce, lecteur Mojo.

---

"On Earth and Space, he has all the tricks."

― ▒▒█𝚃𝙾𝙿 𝚂𝙴𝙲𝚁█𝚃 // 𝚂𝙲𝙸 // 𝙽▒▒▒▒𝙾𝙵𝙾𝚁𝙽