Règles

Dix-sept règles, chacune avec un code stable. Une revue, un commit ou un message d'erreur cite le code (MF-007), jamais le titre : un titre se réécrit, un code ne bouge pas.

Chaque règle dit ce qui la fait respecter, et la distinction compte :

• machine : un hook, une permission ou la CI refuse la violation. Elle ne dépend de la mémoire de personne.
• skill : un skill du moteur s'arrête ou la constate au bon moment.
• revue : seule une relecture la tient. C'est la catégorie la plus fragile, et elle est dite comme telle.

MF-001 · Décider avant de construireCopier le lien de cette section

Règle. Un choix coûteux à défaire est décidé par écrit avant l'implémentation : schéma de données, authentification, paiement, choix d'un fournisseur, structure du code, tout ce qui touche plusieurs systèmes. La décision prend la forme d'une spec /architect (docs/specs/) ou d'un plan approuvé en mode Plan.

Pourquoi. Un agent à qui manque une décision l'invente, silencieusement, au milieu du code. Relire un plan de trente lignes coûte moins cher que défaire un diff de deux mille.

Tenue par. /develop s'arrête quand une décision structurante n'a pas de spec, et renvoie vers /architect. La revue vérifie qu'aucune décision n'a été prise en douce.

Exception. Construire sur une hypothèse est permis si l'humain le choisit : /develop l'enregistre comme spec Assumed, qui reste signalée tant que /architect ne l'a pas ratifiée. Une dette de décision visible vaut mieux qu'une décision cachée.

MF-002 · Un lot, une intentionCopier le lien de cette section

Règle. Un lot livre une seule capacité, décrite par ses critères d'acceptation. Ce qui est utile mais hors du lot se propose (/scope <l'idée>) et ne se code pas.

Pourquoi. Un lot qui fait trois choses se relit mal, se teste mal et se défait mal. C'est aussi la pente naturelle d'un agent : « tant que j'y suis ».

Tenue par. La revue, et /check review qui signale les changements sans lien avec la feature.

MF-003 · Jamais sur main ni sur developCopier le lien de cette section

Règle. Tout travail part d'une branche dédiée (feat/, fix/, chore/, refactor/, docs/, test/) et rejoint develop par pull request. main ne reçoit que develop, par pull request. Aucun commit ni push direct sur l'une ou l'autre, pas même un commit vide « pour vérifier ».

Pourquoi. develop est l'intégration, main la production. Un raccourci sur l'une ou l'autre fait entrer du code qu'aucune CI n'a jugé et qu'aucun humain n'a relu.

Tenue par. Trois couches, parce qu'aucune ne suffit seule :

• le hook Claude Code .claude/hooks/garde.mjs refuse le commit sur ces branches et le push vers elles ;
• le hook git .githooks/pre-push refuse la mise à jour directe de main et develop, pour tous les outils et tous les humains ;
• le workflow CI garde-flux.yml refuse une pull request vers main qui ne vient pas de develop.

Côté serveur, un ruleset GitHub sans contournement (/flow proteger) quand le plan GitHub le permet.

Exception. La création initiale de main et develop sur le dépôt distant (voir Démarrer).

MF-004 · Fusion sur CI verte uniquementCopier le lien de cette section

Règle. Lint, typage, tests, build et scan de secrets passent en CI avant toute fusion. Une CI rouge ne se contourne pas, elle se répare.

Pourquoi. « Ça marche sur ma machine » n'est pas un état du projet. La CI est le seul juge qui voit le même code pour tout le monde.

Tenue par. .github/workflows/ci.yml, et le ruleset qui exige le statut verify.

MF-005 · Une commande verify par projetCopier le lien de cette section

Règle. Le projet expose une commande unique, verify, qui enchaîne les contrôles disponibles (lint, typage, tests, build). L'agent la lance avant chaque pull request, et AGENTS.md la nomme.

Pourquoi. Une liste de cinq commandes à retenir finit toujours amputée d'une. Une seule commande se lance, ou ne se lance pas, et ça se voit.

Tenue par. /flow installer crée le script, /flow controler signale son absence, la CI exécute les mêmes contrôles.

MF-006 · Les secrets restent hors de portéeCopier le lien de cette section

Règle. L'agent ne lit ni n'écrit les fichiers d'environnement réels (.env, .env.local, .env.*.local, .env.production). Seul .env.example, sans valeur, est versionné. Le code lit process.env sans jamais afficher une valeur. Une variable préfixée pour le client (NEXT_PUBLIC_, EXPO_PUBLIC_, VITE_) est publique : elle ne porte jamais de secret.

Pourquoi. Un secret lu par l'agent finit dans une transcription, un journal ou un commit. Un secret poussé sur un distant est compromis, même sur un dépôt privé, même retiré au commit suivant.

Tenue par. Les règles deny de .claude/settings.json, le .gitignore, et le scan de secrets de la CI.

Si ça arrive. Révoquer et régénérer le secret d'abord, nettoyer l'historique ensuite. Dans cet ordre.

MF-007 · Ce qui entre est unknownCopier le lien de cette section

Règle. Toute donnée venue de l'extérieur du serveur (formulaire, paramètre d'URL, corps de requête, réponse d'API tierce, webhook, fichier téléversé, stockage local du client) est unknown jusqu'à sa validation par un schéma, côté serveur, à la frontière. Un prix, un rôle, un statut de paiement ou un identifiant de propriétaire ne sont jamais crus sur parole : le serveur les relit depuis sa propre source.

Pourquoi. C'est la faute que les agents commettent par défaut : faire confiance au client parce que le client, c'est le code qu'ils viennent d'écrire.

Tenue par. La revue, /check review et /security-review. Pour le web TypeScript, Maedow Arch interdit en plus any et la double assertion (MA-005, MA-006).

MF-008 · L'autorisation se vérifie côté serveurCopier le lien de cette section

Règle. Chaque route, action serveur et requête protégée vérifie l'identité et le droit, à chaque accès. Masquer un bouton ou un lien n'est pas une protection. Avec une base exposée au client (Supabase), la sécurité au niveau des lignes (RLS) est activée sur chaque table, et ses règles sont testées.

Pourquoi. L'interface n'est qu'un client parmi d'autres. N'importe qui peut appeler l'API sans elle.

Tenue par. La revue, et des tests obligatoires pour trois cas : non authentifié, authentifié sans le droit, authentifié avec le droit.

MF-009 · Les migrations sont versionnées et immuablesCopier le lien de cette section

Règle. Tout changement de schéma passe par une migration versionnée dans le dépôt. Une migration appliquée ne se modifie jamais : on en écrit une nouvelle. Un changement de schéma se prépare en mode Plan (MF-001), et une migration destructive (suppression de colonne ou de table) se fait en deux temps : d'abord le code cesse de s'en servir, ensuite la donnée disparaît.

Pourquoi. Une migration modifiée après coup diverge entre les environnements, et la divergence ne se voit qu'en production.

Tenue par. La revue.

MF-010 · Fini veut dire prouvéCopier le lien de cette section

Règle. Une feature est finie quand chacun de ses critères d'acceptation a été constaté sur l'application qui tourne. Ce qui n'a pas pu être vérifié est écrit comme tel, jamais passé sous silence.

Pourquoi. Des tests verts prouvent que le code fait ce que les tests demandent. Ils ne prouvent pas que la page s'affiche, que le bouton est branché, ni que la feature correspond à ce qui avait été décidé.

Tenue par. /check verify, à partir du palier Alpha.

MF-011 · Un regard neuf avant de fusionnerCopier le lien de cette section

Règle. Aux paliers Beta et GA, le code est relu avant la pull request par un contexte qui ne l'a pas écrit : un autre modèle, ou un sous-agent sans l'historique de la session. Chaque constat est reproduit avant d'être corrigé, et seuls les problèmes confirmés se corrigent.

Pourquoi. Un modèle qui relit son propre travail partage ses angles morts. Et un relecteur, humain ou non, produit aussi des faux positifs : corriger sans reproduire, c'est parfois casser ce qui marchait.

Tenue par. /check review, qui écrit ses constats dans docs/reviews/.

MF-012 · Un bug se reproduit avant de se corrigerCopier le lien de cette section

Règle. Une correction commence par une reproduction déterministe et se termine par un test de régression qui échouait avant et passe après. La correction est minimale : pas de refonte ni de nouveauté glissée avec elle.

Pourquoi. Une correction qu'on ne sait pas expliquer est un bug qu'on n'a pas encore trouvé.

Tenue par. /debug, puis /test.

MF-013 · La documentation se consulte, elle ne se suppose pasCopier le lien de cette section

Règle. Avant d'utiliser l'API d'une bibliothèque, d'un framework ou d'un service, l'agent en consulte la documentation actuelle (Context7, ou la documentation officielle), et installe les versions courantes plutôt que celles de sa mémoire.

Pourquoi. La connaissance d'un modèle a une date. Les bibliothèques, non : une API renommée ou dépréciée produit un code qui compile parfois, et qui échoue en silence.

Tenue par. La revue. C'est une règle de discipline, et elle est fragile.

MF-014 · Pas de brique sans goulot mesuréCopier le lien de cette section

Règle. Cache, file d'attente, réplique de lecture, microservice, sharding ou tout autre élément d'infrastructure n'entrent dans le projet qu'avec la mesure qui les justifie, citée dans la spec. Un seul serveur et une seule base suffisent à des milliers d'utilisateurs.

Pourquoi. Chaque brique ajoute de la complexité, de la maintenance et des données potentiellement périmées. L'ajouter avant le besoin, c'est payer le coût sans le bénéfice.

Tenue par. La revue. L'ordre des étapes et leurs signaux sont dans Tenir la charge.

MF-015 · Le contexte durable vit dans AGENTS.mdCopier le lien de cette section

Règle. AGENTS.md porte ce qu'un agent doit savoir à chaque session et ne peut pas déduire du code : stack décidée, commandes, conventions, pièges. Il reste court. CLAUDE.md n'est qu'un pointeur vers lui. Les généralités (« écris du code propre ») n'y entrent pas. Il est mis à jour après chaque lot.

Pourquoi. Tous les outils lisent AGENTS.md. Un contexte trop long dilue l'attention de l'agent ; un contexte périmé l'induit en erreur, ce qui est pire que pas de contexte.

Tenue par. /audit le crée, /sync le maintient après chaque lot.

MF-016 · L'irréversible se confirmeCopier le lien de cette section

Règle. Une opération qu'on ne peut pas défaire demande une confirmation humaine au moment où elle s'exécute : suppression récursive, git reset --hard, git push --force-with-lease, DROP ou TRUNCATE, suppression d'une branche distante. Deux opérations sont refusées sans appel : git push --force et tout contournement des hooks (--no-verify).

Pourquoi. Une confirmation coûte trois secondes. Une perte de données, une réécriture d'historique partagé ou un garde-fou désactivé coûtent des heures, parfois tout.

Tenue par. Le hook .claude/hooks/garde.mjs, qui répond « demander » ou « refuser » avant l'exécution.

MF-017 · Écrire justeCopier le lien de cette section

Règle. Français correct partout où un humain lira : interface, documentation, commentaires, commits, pull requests. Pas de tiret cadratin pour accoler une incise ou une explication (texte — suite) : on construit la phrase avec deux-points, virgule, parenthèses, ou deux phrases. Un message de commit est une phrase au présent qui dit ce qui est désormais vrai (« Le panier refuse une quantité supérieure au stock »), sans trailer d'attribution (Co-Authored-By) ni mention d'outil.

Pourquoi. L'historique et la documentation sont lus plus souvent qu'ils ne sont écrits. Et l'historique d'un dépôt est signé par son auteur, pas par ses outils.

Tenue par. Le hook .githooks/commit-msg refuse le trailer d'attribution, la mention d'outil et le tiret cadratin dans les messages de commit. Ailleurs, la revue. Cette règle prime sur le format de commit que proposent les skills installés.