designwithai-mcp 0.1.0

package/skills/review-data-security/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: review-data-security
+description: Juge la sécurité des données d'un produit — modèle d'autorisation table par table, secrets et frontière client/serveur, rôle privilégié, intégrité, sauvegardes et récupération. Multi-stack (Supabase, Firebase, Convex, Postgres + ORM). Invocable seul, sans lancer d'audit de production complet.
+version: 1.0
+category: data-security-expert
+role: Data & security expert
+execution_mode: authorization-and-data-audit
+supports: [ai-builder, traditional, hybrid]
+inputs: [code, backend, schema, env, bundle]
+outputs: [authorization-matrix, secret-inventory, recovery-status, risk-register]
+invoked_by: [review-ai-product]
+---
+
+# /review-data-security
+
+**Rôle** : Data & security expert · **Mode par défaut** : audit d'autorisation et de données.
+
+Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `SEC`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
+
+## Mission
+
+Répondre à une seule question, table par table : **qui peut lire quoi, qui peut écrire quoi, et qu'est-ce qui l'empêche ?** Le skill juge ce qu'il a inspecté. Il ne certifie jamais un produit « sécurisé » : il produit une matrice d'autorisation vérifiée, la liste nominative de ce qu'il n'a pas pu voir, et les risques ouverts que cela laisse.
+
+Ce skill porte **la grille sécurité et données de la maison**. `review-ai-product` l'exécute au lieu de la redécrire ; toute évolution de la grille se fait ici, et nulle part ailleurs.
+
+## Déclenchement
+
+Avant d'ouvrir un produit à de vrais utilisateurs, après une génération IA qui a créé des tables toute seule, à la reprise d'un produit dont personne n'a écrit les règles, ou quand une donnée d'un utilisateur est apparue chez un autre.
+
+- **Entrées minimales pour produire un verdict** : la liste des tables ou collections, les règles d'autorisation appliquées côté serveur, et la liste des variables d'environnement (noms, pas valeurs).
+- **Pour un audit complet** : le dépôt, le schéma, deux comptes de test, et l'accès en lecture à la configuration du backend.
+- **Sans ces entrées**, le skill rend `BLOCKED` et nomme ce qui manque. Voir *Refus honnête*.
+
+## Principe de sécurité
+
+- **Lecture seule, toujours.** Ne jamais modifier une règle d'autorisation, une donnée, un secret, une configuration d'authentification ou un déploiement. Un audit qui répare en passant efface la preuve du problème.
+- **Ne jamais faire figurer une valeur de secret** dans le rapport. On cite le **nom** de la variable, son emplacement et sa portée — jamais son contenu, même partiel, même expiré.
+- **Ne pas fabriquer la preuve.** Si la vérification demande de créer un compte de test ou d'exécuter une requête, la demander explicitement plutôt que de la simuler.
+
+## La grille — six invariants, un seul propriétaire
+
+Le backend change d'un produit à l'autre ; ce qu'il faut prouver ne change pas. Identifier d'abord le stack, puis chercher la forme concrète que chaque invariant y prend.
+
+| Invariant | Ce qu'il faut prouver | Forme selon le stack |
+|---|---|---|
+| **Modèle d'autorisation** | Une règle appliquée **côté serveur** décide qui lit et écrit quoi ; le client ne peut pas la contourner. | Supabase : RLS activée **et** policies par table. Firebase : security rules Firestore / Storage. Convex : contrôle d'identité dans chaque query et mutation publique. Postgres + Drizzle / Prisma / Neon : autorisation dans la couche serveur (route handler, service), jamais dans le composant. |
+| **Rôle privilégié serveur** | La clé qui outrepasse les règles n'existe jamais dans le bundle client. | Supabase : `service_role`. Firebase : Admin SDK, compte de service. Convex : actions et fonctions internes. SQL direct : `DATABASE_URL`. |
+| **Frontière client / serveur** | Toute écriture sensible passe par du code serveur qui valide ; le navigateur ne fait pas autorité. | Edge / cloud functions, route handlers, server actions, fonctions Convex, API interne. |
+| **Secrets et environnements** | Les secrets sont hors du code, distincts par environnement, et rotables sans redéploiement du client. | Variables serveur du host, secrets du BaaS, `.env` non commité. Vérifier ce que le préfixe public du framework expose. |
+| **Migrations et intégrité** | Le schéma est reproductible et les invariants de données tiennent dans le datastore, pas seulement dans l'écran. | SQL : migrations commitées, clés étrangères, `unique`, `check`, `not null`. NoSQL : règles de validation, forme documentée, réconciliation. |
+| **Sauvegarde et récupération** | Les données perdues peuvent revenir, et quelqu'un l'a déjà fait. | Sauvegarde automatique du BaaS, restauration à un instant donné, export vérifié. Une sauvegarde jamais restaurée n'est pas une sauvegarde. |
+
+## Le cœur : l'autorisation, table par table
+
+Une ligne par table ou collection, sans exception. Une table oubliée est une table non protégée.
+
+| Colonne | Ce qu'on y met |
+|---|---|
+| **Table** | Le nom exact. |
+| **Donnée** | Ce qu'elle contient, en clair : « les relevés d'un compte », « les jetons d'accès Figma ». |
+| **Personnelle ?** | Oui / non. Une donnée personnelle sans règle est bloquante, pas majeure. |
+| **Lecture** | Qui peut lire. « Le propriétaire », « tout compte connecté », « tout le monde ». |
+| **Écriture** | Qui peut créer, modifier, supprimer. Détailler si les trois diffèrent. |
+| **Règle appliquée où** | Le fichier et la ligne. « RLS `releves_select_own`, migration 2026…08.sql:14 ». |
+| **Preuve** | Comment ça a été vérifié : inspection du fichier, test à deux comptes, lecture de la console. |
+| **Verdict** | Vérifié / non vérifié / faille. |
+
+### La preuve qui compte
+
+- **Déclaré n'est pas appliqué.** Une policy écrite dans une migration jamais jouée en production ne protège rien. Vérifier l'état **du serveur qui répond**, pas seulement le dépôt.
+- **RLS activée n'est pas RLS suffisante.** Une table avec RLS mais sans policy est fermée ; une table avec une policy `using (true)` est ouverte. Lire la policy, pas l'interrupteur.
+- **Le test à deux comptes est la seule preuve directe.** Compte A crée une donnée, compte B tente de la lire et de la modifier. Tout le reste est de la preuve croisée, à marquer comme telle.
+- **La lecture n'est pas l'écriture.** Beaucoup de produits protègent `select` et laissent `update` ouvert. Chaque opération se vérifie séparément.
+- **Le stockage de fichiers est un datastore.** Buckets, dossiers et URLs signées suivent la même grille que les tables.
+
+### Ce qui finit dans le bundle
+
+- Repérer le préfixe public du framework — `NEXT_PUBLIC_`, `VITE_`, `REACT_APP_`, `PUBLIC_`, `EXPO_PUBLIC_` — et **lister tout ce qu'il exporte**. Ce qui porte ce préfixe est publié, par construction.
+- Distinguer ce qui est **public par conception** (clé anonyme d'un BaaS, identifiant de projet) de ce qui ne doit jamais sortir (rôle privilégié, clé d'API tierce, secret de signature, chaîne de connexion). Traiter une clé anonyme comme une fuite est un faux constat ; il décrédibilise le vrai.
+- Une clé anonyme n'est sûre **que si** les règles serveur tiennent. C'est le même constat vu des deux bouts : sans autorisation, la clé publique suffit à tout lire.
+- Chercher aussi les secrets écrits en dur : code source, fichier commité, note dans une maquette, texte visible d'une page.
+
+## Séquence d'audit obligatoire
+
+1. **Identifier le stack et l'environnement.** Quel backend, quels environnements existent, lequel répond à l'adresse auditée, et si les données sont réelles ou fictives.
+2. **Inventorier les tables.** Toutes, y compris celles créées par le générateur et jamais relues. Noter celles qui contiennent des données personnelles.
+3. **Lire les règles, une par une.** Pour chaque table : la règle, son fichier, sa ligne. Une table sans règle trouvée est notée comme telle, et la recherche est décrite.
+4. **Vérifier à deux comptes** ce qui peut l'être, en lecture et en écriture séparément.
+5. **Suivre le rôle privilégié.** Où la clé est stockée, quel code s'en sert, et si un chemin non authentifié y mène.
+6. **Ouvrir le bundle client.** Lister ce que le préfixe public expose ; chercher les secrets en dur.
+7. **Vérifier l'intégrité.** Migrations versionnées et jouées, contraintes qui tiennent les invariants, index sur les colonnes qui portent l'autorisation.
+8. **Vérifier la récupération.** Sauvegarde active, fréquence, portée, et **date de la dernière restauration réussie**.
+9. **Produire la matrice**, puis les risques, puis la liste nominative du non vérifié.
+
+## La règle de l'absence — le garde-fou de cet axe
+
+Ailleurs dans la maison, l'absence ne prouve jamais rien. **Ici, elle prouve parfois** — une table inspectée sans policy est une faille réelle, pas une lacune d'observation. C'est ce qui rend ce skill dangereux, et cette règle non négociable :
+
+> **L'absence ne fait preuve que si l'inspection a eu lieu et que son périmètre est écrit.**
+
+Concrètement :
+
+- « J'ai listé les 14 tables du schéma ; `messages` n'a aucune policy » → **constat**, avec la méthode d'inspection en preuve.
+- « Je n'ai pas vu de policy sur `messages` » sans dire ce qui a été inspecté → **non vérifié**, jamais un constat.
+- « Le dépôt ne contient pas de dossier de migrations » → constat seulement si le dépôt entier a été reçu ; sinon, accès manquant.
+- **Un extrait n'autorise aucune conclusion négative.** Trois fichiers reçus sur un dépôt de deux cents ne disent rien de ce que contiennent les 197 autres.
+- **Ne jamais écrire un constat dont la preuve est un compteur à zéro** ou une liste vide, sans dire d'où vient la liste et ce qu'elle couvre.
+
+La contrepartie est aussi stricte : **ne jamais transformer un non-vérifié en rassurance.** « Aucun problème trouvé sur les permissions » est interdit si les permissions n'ont pas été inspectées. Le silence se dit, il ne se déduit pas.
+
+## Sévérité sur cet axe
+
+Le verdict se **déduit** des sévérités, il ne se décide pas — même règle que partout ailleurs. Ce que cet axe précise, c'est ce qui mérite quel niveau.
+
+| Sévérité | Sur cet axe |
+|---|---|
+| **Bloquant** | Une table lisible ou modifiable par n'importe qui sans règle serveur. Un rôle privilégié ou un secret dans le bundle client. Des données personnelles sans contrôle d'accès. Aucune sauvegarde sur des données non reconstructibles. |
+| **Critique** | Une règle présente mais contournable (écriture ouverte, condition portée par le client). Un chemin non authentifié qui atteint le rôle privilégié. Un secret partagé entre production et développement. Une sauvegarde dont la restauration n'a jamais été testée. |
+| **Majeur** | Migrations non versionnées. Contrainte d'intégrité absente là où l'écran seul la tient. Pas d'index sur la colonne qui porte l'autorisation. Aucune rotation possible sans redéploiement. |
+| **Mineur** | Nommage de variables qui rend la portée ambiguë. Table de travail oubliée, vide et sans donnée personnelle. |
+| **Note** | Dette documentée, acceptée, avec sa condition de réévaluation. |
+
+**Un seul bloquant suffit à faire `FAIL`.** Aucune pondération par le reste : un produit dont les données sont lisibles par tous n'est pas « bon sauf sur un point ».
+
+## Refus honnête
+
+Le skill rend **`BLOCKED`** — et aucun autre verdict — quand il ne peut pas voir ce qu'il doit juger. Le refus n'est pas un échec du skill : c'est ce qui empêche un rapport rassurant sur du vide.
+
+Dans ce cas, la sortie contient :
+
+- **ce qui a été reçu**, nommément ;
+- **ce qui manque**, nommément et sous forme demandable : « la liste des tables », « le contenu du dossier `migrations` », « un second compte de test », « la liste des noms de variables d'environnement du serveur » ;
+- **les risques ouverts que cela laisse**, formulés comme des questions sans réponse, jamais comme des constats.
+
+Cas typiques : aucun accès au schéma ; une URL de production sans dépôt ni backend ; un dépôt sans la configuration du BaaS ; des règles fournies sans savoir si elles sont déployées.
+
+## Adaptation au mode de delivery
+
+- **AI Builder.** Le générateur crée des tables sans qu'on les relise : inventorier d'abord, et supposer qu'aucune n'a de règle tant qu'on ne l'a pas lue. Vérifier les appels directs du navigateur au datastore, et les tables ajoutées entre deux générations.
+- **Classique.** L'autorisation vit dans la couche serveur : vérifier qu'aucune route ne l'a contournée, et que les tests couvrent le refus autant que l'accès.
+- **Hybride.** Le risque est la double porte : une même table atteinte par une route serveur validée **et** par un appel client direct. Les deux chemins se vérifient.
+
+## Anti-patterns à refuser
+
+- Déclarer un produit sécurisé parce qu'aucun incident n'a eu lieu.
+- Conclure sur les permissions sans les avoir inspectées, dans un sens comme dans l'autre.
+- Traiter la clé anonyme d'un BaaS comme une fuite de secret.
+- Recopier la valeur d'un secret dans le rapport pour « prouver » la fuite.
+- Confondre RLS activée et table protégée.
+- Vérifier la lecture et conclure sur l'écriture.
+- Considérer une sauvegarde comme acquise sans date de restauration réussie.
+- Proposer une migration corrective sans sauvegarde, environnement de test et retour arrière.
+- Rendre un verdict global sur un extrait de dépôt.
+
+## Contrat de sortie exact
+
+```
+# Verdict
+- Verdict: PASS | PASS WITH FIXES | FAIL | BLOCKED
+- Stack identifié
+- Environnement audité (et s'il porte des données réelles)
+- Risques bloquants, en une ligne chacun
+
+# Couverture
+- Accès reçus
+- Méthode d'inspection (ce qui a été lu, et jusqu'où)
+- Vérifications à deux comptes réalisées
+- NON VÉRIFIÉ — liste nominative
+
+# Matrice d'autorisation
+Table | Donnée | Personnelle | Lecture | Écriture | Règle appliquée où | Preuve | Verdict
+
+# Frontière client / serveur
+- Exposé par le préfixe public
+- Public par conception (et pourquoi c'est acceptable ici)
+- Rôle privilégié : emplacement, code qui s'en sert, chemins d'accès
+- Secrets en dur trouvés (nom et emplacement, jamais la valeur)
+
+# Intégrité et récupération
+- Migrations: versionnées / jouées / écart entre dépôt et serveur
+- Contraintes portant les invariants
+- Sauvegarde: portée, fréquence, dernière restauration réussie
+
+# Risques
+SEC-XX | Sévérité | Localisation | Preuve | Impact | Correction | Critères | Confiance
+
+# Ce qu'il faut pour lever les BLOCKED
+- Accès manquant -> ce qu'il permettrait de juger
+```
+
+## Critères de qualité du skill
+
+- Chaque table du périmètre a une ligne, ou est nommée dans le non vérifié.
+- Aucun verdict de sécurité n'est rendu sur un axe non inspecté, dans un sens comme dans l'autre.
+- Chaque constat porte un fichier, une ligne ou une manipulation reproductible.
+- Aucune valeur de secret n'apparaît dans la sortie.
+- Le refus est complet : ce qui manque est demandable tel quel.
+- Le verdict se déduit des sévérités et n'est jamais pondéré par le reste du produit.
+
+## Exemple d'invocation
+
+```
+/review-data-security
+Produit: SaaS B2B en bêta privée
+Stack: Supabase (Postgres + RLS, Storage, Edge Functions)
+Accès: dépôt GitHub, Supabase en lecture seule, deux comptes de test
+Environnement: production, données réelles
+Objectif: décider si 100 utilisateurs peuvent être onboardés
+Contraintes: ne modifier aucune donnée, aucun secret, aucune règle
+```

package/skills/review-data-security/evals/cases.json

@@ -0,0 +1,138 @@
+[
+  {
+    "id": "sec-conformant-supabase-tenu",
+    "skill": "review-data-security",
+    "kind": "conformant",
+    "delivery_mode": "hybride",
+    "artifact": "MATÉRIAU REÇU\n- Dépôt complet (git clone, 214 fichiers).\n- Projet Supabase en lecture seule (schéma, policies, configuration Auth, Storage).\n- Deux comptes de test fournis : test-a@exemple.fr, test-b@exemple.fr.\n- Liste des noms de variables d'environnement du serveur et du client.\n\nSCHÉMA — 4 tables dans le schéma public\n  releves            relevés de compteur d'un compte        RLS: activée\n  compteurs          compteurs déclarés par un compte       RLS: activée\n  profils            nom d'affichage et préférences         RLS: activée\n  invitations        invitations envoyées par un compte     RLS: activée\n\nPOLICIES, telles que retournées par le serveur\n\n  releves_select_own   SELECT  using (auth.uid() = user_id)\n  releves_insert_own   INSERT  with check (auth.uid() = user_id)\n  releves_update_own   UPDATE  using (auth.uid() = user_id) with check (auth.uid() = user_id)\n  releves_delete_own   DELETE  using (auth.uid() = user_id)\n  compteurs_all_own    ALL     using (auth.uid() = user_id) with check (auth.uid() = user_id)\n  profils_select_own   SELECT  using (auth.uid() = id)\n  profils_update_own   UPDATE  using (auth.uid() = id) with check (auth.uid() = id)\n  invitations_select   SELECT  using (auth.uid() = inviteur_id)\n  invitations_insert   INSERT  with check (auth.uid() = inviteur_id)\n\nVÉRIFICATION À DEUX COMPTES (exécutée)\n  A crée un relevé -> id 41. B tente select id 41 -> 0 ligne.\n  B tente update id 41 -> 0 ligne affectée. B tente delete id 41 -> 0 ligne affectée.\n  Même séquence sur compteurs et profils : aucun accès croisé.\n\nVARIABLES D'ENVIRONNEMENT\n  Client (préfixe NEXT_PUBLIC_) : NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY\n  Serveur uniquement : SUPABASE_SERVICE_ROLE_KEY, ANTHROPIC_API_KEY, RESEND_API_KEY\n\nRECHERCHE DE SECRETS EN DUR\n  grep sur le dépôt (service_role, sk_, secret, BEGIN PRIVATE KEY) : aucune occurrence\n  hors .env.example, qui ne contient que des noms et des valeurs factices.\n  Bundle client construit (out/) : SUPABASE_SERVICE_ROLE_KEY absent.\n\nRÔLE PRIVILÉGIÉ\n  Utilisé dans supabase/functions/ingest-audit/index.ts et analyze-url/index.ts,\n  toutes deux derrière une vérification de session (userFromRequest -> 401 sinon).\n  Aucune route du client ne l'atteint.\n\nMIGRATIONS\n  supabase/migrations/ : 6 fichiers commités. Comparaison avec le schéma du\n  serveur : identiques, aucune table hors migration.\n\nCONTRAINTES\n  releves.user_id -> auth.users(id) ON DELETE CASCADE, not null\n  releves.compteur_id -> compteurs(id), not null\n  unique (compteur_id, date_releve)\n  index idx_releves_user_id sur user_id\n\nSAUVEGARDE\n  Sauvegarde quotidienne automatique, rétention 7 jours, restauration à un\n  instant donné activée. Dernière restauration testée le 02/07/2026 sur un\n  projet de recette, réussie.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": [
+        "la clé anonyme est exposée dans le bundle client",
+        "une clé Supabase se trouve dans le code du navigateur",
+        "aucune sauvegarde des données n'est configurée",
+        "une table reste sans règle d'autorisation",
+        "le rôle privilégié atteint depuis le client",
+        "le schéma n'est pas reproductible faute de migrations versionnées"
+      ],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "Produit tenu, et surtout tenu de façon PROUVÉE : les quatre tables ont leurs policies, la vérification à deux comptes a eu lieu en lecture ET en écriture, le rôle privilégié ne vit que dans des fonctions serveur authentifiées, les migrations correspondent au serveur, la restauration a été testée à une date nommée. Le piège du cas est la clé anonyme dans le bundle : elle y est PAR CONCEPTION et n'est un risque que si les règles serveur cèdent — ce qui n'est pas le cas ici. La rapporter comme une fuite est le faux constat le plus fréquent de cet axe, et il décrédibilise les vrais."
+    }
+  },
+  {
+    "id": "sec-conformant-firebase-tenu",
+    "skill": "review-data-security",
+    "kind": "conformant",
+    "delivery_mode": "ai-builder",
+    "artifact": "MATÉRIAU REÇU\n- Dépôt complet (git clone, 96 fichiers).\n- Console Firebase en lecture seule : règles Firestore et Storage, App Check, comptes de service.\n- Deux comptes de test fournis.\n- Liste des noms de variables d'environnement.\n\nCOLLECTIONS\n  users/{uid}                 profil du compte\n  users/{uid}/dossiers/{id}   dossiers d'un compte\n  partages/{id}               partages explicites entre comptes\n  public_config/{id}          configuration lue par tout le monde, aucune donnée personnelle\n\nRÈGLES FIRESTORE, telles que déployées\n\n  match /users/{uid} {\n    allow read, write: if request.auth != null && request.auth.uid == uid;\n    match /dossiers/{id} {\n      allow read, write: if request.auth != null && request.auth.uid == uid;\n    }\n  }\n  match /partages/{id} {\n    allow read: if request.auth != null &&\n      (request.auth.uid == resource.data.emetteur || request.auth.uid == resource.data.destinataire);\n    allow create: if request.auth != null && request.auth.uid == request.resource.data.emetteur;\n    allow update, delete: if request.auth != null && request.auth.uid == resource.data.emetteur;\n  }\n  match /public_config/{id} { allow read: if true; allow write: if false; }\n\nRÈGLES STORAGE\n  match /pieces/{uid}/{fichier} {\n    allow read, write: if request.auth != null && request.auth.uid == uid;\n  }\n\nVÉRIFICATION À DEUX COMPTES (exécutée)\n  B tente de lire users/A et users/A/dossiers : permission refusée.\n  B tente d'écrire dans pieces/A/ : permission refusée.\n  B lit public_config : autorisé, conforme à l'intention (aucune donnée personnelle).\n\nAPP CHECK\n  Activé et appliqué sur Firestore et Storage.\n\nVARIABLES D'ENVIRONNEMENT\n  Client : NEXT_PUBLIC_FIREBASE_API_KEY, NEXT_PUBLIC_FIREBASE_PROJECT_ID,\n           NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN\n  Serveur uniquement : FIREBASE_SERVICE_ACCOUNT_JSON, STRIPE_SECRET_KEY\n\nADMIN SDK\n  Initialisé dans app/api/ uniquement (3 route handlers), jamais importé depuis\n  un composant client. Recherche d'import côté client : aucune occurrence.\n\nRÈGLES ET INDEXES VERSIONNÉS\n  firestore.rules, storage.rules et firestore.indexes.json commités.\n  Comparaison avec les règles déployées : identiques.\n\nSAUVEGARDE\n  Export planifié quotidien vers un bucket dédié, rétention 30 jours.\n  Dernière restauration testée le 14/06/2026 sur un projet de recette, réussie.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": [
+        "la clé API Firebase est exposée dans le bundle",
+        "la collection publique est lisible par tout le monde",
+        "aucune règle sur le stockage des fichiers",
+        "changer de backend pour un outil réputé plus sûr",
+        "aucune sauvegarde des données n'est configurée"
+      ],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "Le même verdict sur un autre stack : la grille doit tenir hors de Supabase. Deux pièges ici. La clé API Firebase est publique par conception — c'est un identifiant de projet, pas un secret ; la traiter comme une fuite est un contresens documenté. Et la collection public_config est lisible par tout le monde INTENTIONNELLEMENT, ce que le matériau dit et que la règle en écriture confirme (write: if false). Un juge qui rapporte une lecture ouverte sans regarder ce qu'elle contient applique la règle sans la comprendre."
+    }
+  },
+  {
+    "id": "sec-obvious-generateur-ouvert",
+    "skill": "review-data-security",
+    "kind": "obvious-defect",
+    "delivery_mode": "ai-builder",
+    "artifact": "MATÉRIAU REÇU\n- Dépôt synchronisé depuis le générateur (git clone, 78 fichiers).\n- Projet Supabase en lecture seule (schéma, policies, configuration).\n- Un seul compte de test.\n- Liste des noms de variables d'environnement du client et du serveur.\n\nSCHÉMA — 5 tables dans le schéma public\n  profils        nom, email, téléphone, adresse       RLS: DÉSACTIVÉE\n  messages       messages échangés entre comptes      RLS: DÉSACTIVÉE\n  commandes      commandes et montants                RLS: activée\n  produits       catalogue public                     RLS: activée\n  admin_logs     journal d'administration             RLS: DÉSACTIVÉE\n\nPOLICIES, telles que retournées par le serveur\n  commandes_select_all   SELECT  using (true)\n  produits_select_all    SELECT  using (true)\n  (aucune autre policy sur ce projet)\n\nVÉRIFICATION AVEC LA CLÉ ANONYME (exécutée depuis un navigateur, sans session)\n  select * from profils  -> 1 284 lignes retournées, avec emails et téléphones.\n  update profils set nom = 'test' where id = <un autre compte> -> 1 ligne modifiée.\n  select * from messages -> 9 032 lignes retournées.\n  select * from commandes -> 4 110 lignes retournées (policy using true).\n\nVARIABLES D'ENVIRONNEMENT\n  Client (préfixe VITE_) : VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY,\n                           VITE_SUPABASE_SERVICE_ROLE_KEY, VITE_OPENAI_API_KEY\n  Serveur : (aucune)\n\nRECHERCHE DE SECRETS EN DUR\n  src/lib/admin.ts:12 — chaîne commençant par « eyJ… » affectée à une constante\n  nommée serviceKey, utilisée dans un composant rendu côté navigateur.\n  Bundle client construit (dist/) : la valeur de VITE_SUPABASE_SERVICE_ROLE_KEY\n  est présente dans dist/assets/index-4f2a.js.\n\nMIGRATIONS\n  Aucun dossier de migrations dans le dépôt. Les tables ont été créées depuis\n  l'interface du générateur. Aucun historique de schéma.\n\nCONTRAINTES\n  Aucune clé étrangère. messages.destinataire_id : colonne texte, sans contrainte.\n  Aucun index en dehors des clés primaires.\n\nSAUVEGARDE\n  Plan gratuit : aucune sauvegarde automatique, aucune restauration à un instant\n  donné. Aucun export manuel trouvé. Les données de production sont réelles.",
+    "golden": {
+      "expected_findings": [
+        "la table profils est lisible et modifiable sans aucune règle serveur",
+        "emails et téléphones accessibles depuis le navigateur sans session",
+        "la table messages reste ouverte à la lecture de tous",
+        "le rôle privilégié service_role est publié par une variable du client",
+        "la clé de service se retrouve dans le bundle construit",
+        "une clé de service écrite en dur dans un composant rendu côté navigateur",
+        "la policy des commandes accepte toute requête sans condition",
+        "aucune sauvegarde sur des données de production réelles",
+        "aucune migration versionnée : le schéma n'est pas reproductible",
+        "aucune clé étrangère ni contrainte tenant l'intégrité des données"
+      ],
+      "forbidden_findings": [
+        "la clé anonyme est exposée dans le bundle client",
+        "revoir la performance des requêtes",
+        "conseiller une réécriture complète du produit plutôt que de fermer les tables ouvertes",
+        "changer de générateur pour un autre outil"
+      ],
+      "expected_verdict": "FAIL",
+      "should_refuse": false,
+      "note": "L'application générée dans son pire état, et tout est PROUVÉ : les requêtes anonymes ont été exécutées et ont rendu 1 284 lignes de données personnelles. L'absence de règle est ici un constat légitime parce que l'inspection a eu lieu et que son périmètre est écrit — c'est la distinction que ce skill doit tenir. Plusieurs bloquants, donc FAIL sans pondération possible. Le piège maintenu : la clé anonyme reste hors constat, même sur un produit catastrophique. Ce qui la rend dangereuse ici, c'est l'absence de règles, et c'est ce constat-là qui est attendu."
+    }
+  },
+  {
+    "id": "sec-subtle-ecriture-ouverte",
+    "skill": "review-data-security",
+    "kind": "subtle-defect",
+    "delivery_mode": "hybride",
+    "artifact": "MATÉRIAU REÇU\n- Dépôt complet (git clone, 187 fichiers).\n- Projet Supabase en lecture seule.\n- Deux comptes de test fournis.\n- Liste des noms de variables d'environnement du serveur et du client.\n\nSCHÉMA — 3 tables dans le schéma public\n  releves      relevés de compteur d'un compte      RLS: activée\n  compteurs    compteurs déclarés par un compte     RLS: activée\n  profils      nom d'affichage                      RLS: activée\n\nPOLICIES, telles que retournées par le serveur\n  releves_select_own    SELECT  using (auth.uid() = user_id)\n  releves_insert_own    INSERT  with check (auth.uid() = user_id)\n  releves_update_any    UPDATE  using (true) with check (true)\n  releves_delete_own    DELETE  using (auth.uid() = user_id)\n  compteurs_all_own     ALL     using (auth.uid() = user_id) with check (auth.uid() = user_id)\n  profils_select_own    SELECT  using (auth.uid() = id)\n  profils_update_own    UPDATE  using (auth.uid() = id) with check (auth.uid() = id)\n\nVÉRIFICATION À DEUX COMPTES (exécutée)\n  A crée un relevé -> id 88. B tente select id 88 -> 0 ligne.\n  B tente update id 88 (index et date) -> 1 ligne modifiée, valeurs remplacées.\n  B tente delete id 88 -> 0 ligne affectée.\n\nVARIABLES D'ENVIRONNEMENT\n  Client (préfixe NEXT_PUBLIC_) : NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY\n  Serveur uniquement : SUPABASE_SERVICE_ROLE_KEY, RESEND_API_KEY\n\nRECHERCHE DE SECRETS EN DUR\n  Aucune occurrence dans le dépôt ni dans le bundle construit.\n\nRÔLE PRIVILÉGIÉ\n  Utilisé dans une seule fonction serveur, derrière vérification de session.\n\nMIGRATIONS\n  supabase/migrations/ : 9 fichiers commités.\n  Comparaison dépôt / serveur : les deux derniers fichiers (008_index_releves.sql,\n  009_contrainte_unique.sql) ne sont pas appliqués sur le serveur de production.\n\nCONTRAINTES\n  releves.user_id -> auth.users(id), not null\n  Aucun index sur releves.user_id (l'index est dans la migration non appliquée).\n  Aucune contrainte d'unicité sur (compteur_id, date_releve) : la migration\n  correspondante n'est pas appliquée non plus. Trois relevés en double observés.\n\nSAUVEGARDE\n  Sauvegarde quotidienne automatique, rétention 7 jours.\n  Dernière restauration testée le 03/06/2026, réussie.",
+    "golden": {
+      "expected_findings": [
+        "la policy de modification des relevés accepte n'importe quel compte connecté",
+        "un compte modifie les relevés d'un autre compte, vérifié à deux comptes",
+        "deux migrations commitées ne sont pas appliquées sur le serveur",
+        "aucun index sur la colonne qui porte l'autorisation",
+        "la contrainte d'unicité manquante laisse passer des relevés en double"
+      ],
+      "forbidden_findings": [
+        "prétendre que les relevés ne sont protégés par aucune politique serveur",
+        "la clé anonyme est exposée dans le bundle client",
+        "aucune sauvegarde des données n'est configurée",
+        "affirmer que les profils sont consultables par des comptes tiers"
+      ],
+      "expected_verdict": "PASS WITH FIXES",
+      "should_refuse": false,
+      "note": "Le produit a l'air tenu et il l'est presque : RLS partout, lecture correctement fermée, secrets propres, sauvegarde restaurée. La faille tient dans un seul mot d'une seule policy — using (true) sur UPDATE — et la vérification à deux comptes la démontre. C'est le cas qui punit le juge qui vérifie la lecture et conclut sur l'écriture. Une seule sévérité critique et trois majeures, donc PASS WITH FIXES : le produit peut avancer après un lot de corrections identifiées."
+    }
+  },
+  {
+    "id": "sec-out-of-scope-lenteur-et-textes",
+    "skill": "review-data-security",
+    "kind": "out-of-scope",
+    "delivery_mode": "hybride",
+    "artifact": "MATÉRIAU REÇU\n- Dépôt complet (git clone, 132 fichiers).\n- Projet Supabase en lecture seule.\n- Deux comptes de test fournis.\n- Traces de requêtes du tableau de bord et rapport de build du bundle.\n\nSCHÉMA — 3 tables dans le schéma public\n  factures     factures d'un compte        RLS: activée\n  paiements    paiements d'un compte       RLS: activée\n  profils      profil du compte            RLS: activée\n\nPOLICIES, telles que retournées par le serveur\n  factures_all_own    ALL  using (auth.uid() = user_id) with check (auth.uid() = user_id)\n  paiements_all_own   ALL  using (auth.uid() = user_id) with check (auth.uid() = user_id)\n  profils_all_own     ALL  using (auth.uid() = id) with check (auth.uid() = id)\n\nVÉRIFICATION À DEUX COMPTES (exécutée)\n  Aucun accès croisé en lecture, création, modification ni suppression.\n\nVARIABLES D'ENVIRONNEMENT\n  Client : NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY\n  Serveur uniquement : SUPABASE_SERVICE_ROLE_KEY, STRIPE_SECRET_KEY\n\nRECHERCHE DE SECRETS EN DUR\n  Aucune occurrence dans le dépôt ni dans le bundle construit.\n\nMIGRATIONS\n  12 fichiers commités, tous appliqués sur le serveur. Contraintes et index\n  présents sur les colonnes d'autorisation.\n\nSAUVEGARDE\n  Quotidienne, rétention 30 jours, restauration testée le 21/07/2026, réussie.\n\nTRACES DE REQUÊTES — écran « Mes factures »\n  1 requête liste des factures (24 lignes), puis 24 requêtes de détail paiement,\n  une par facture, exécutées en série. Temps total observé : 3,8 s.\n\nRAPPORT DE BUILD\n  dist/assets/index-9c31.js : 1,9 Mo non compressé.\n  Trois bibliothèques de graphiques différentes incluses.\n\nTEXTES DE L'ÉCRAN\n  En cas d'échec du paiement, la page affiche « Une erreur est survenue »\n  sans indiquer la cause ni la suite à donner.",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": [
+        "vingt-quatre requêtes de détail exécutées en série",
+        "le bundle dépasse un méga-octet",
+        "trois bibliothèques de graphiques incluses",
+        "le message d'erreur ne dit pas quoi faire",
+        "revoir la pagination de la liste des factures"
+      ],
+      "expected_verdict": "PASS",
+      "should_refuse": false,
+      "note": "Backend irréprochable, et le matériau pose sous le nez du juge trois problèmes bien réels qui ne lui appartiennent pas : une cascade de requêtes et un bundle lourd (better-performance), un message d'erreur muet (better-states et better-writing). Sortir du périmètre ici, même en ayant raison sur le fond, échoue le cas : c'est ainsi qu'un juge devient un avis général de plus. Le signaler comme dépendance vers un autre skill est en revanche permis — ce n'est pas un constat."
+    }
+  },
+  {
+    "id": "sec-insufficient-adresse-seule",
+    "skill": "review-data-security",
+    "kind": "insufficient",
+    "delivery_mode": "ai-builder",
+    "artifact": "MATÉRIAU REÇU\n- Une adresse de production : https://mon-app-generee.lovable.app\n- Rien d'autre.\n\nCE QUI A ÉTÉ TENTÉ\n  Ouverture de la page d'accueil : l'application se dessine dans le navigateur.\n  Aucun dépôt fourni, aucun accès au backend, aucun compte de test.\n  Aucune liste de variables d'environnement.\n\nCE QUI EST OBSERVABLE DEPUIS LE NAVIGATEUR\n  Le bundle client contient une adresse de projet Supabase et une clé commençant\n  par « eyJ », dont le contenu décodé indique le rôle « anon ».\n  Aucune requête n'a été émise vers le backend : le juge n'a pas de compte.\n\nDEMANDE INITIALE\n  « Est-ce que mes données sont sécurisées ? Je veux ouvrir à 200 utilisateurs\n  la semaine prochaine. »",
+    "golden": {
+      "expected_findings": [],
+      "forbidden_findings": [
+        "aucune règle d'autorisation n'a été trouvée",
+        "la base de données n'est pas protégée",
+        "aucun secret exposé sur ce produit",
+        "les données semblent correctement isolées",
+        "une clé Supabase se trouve dans le code du navigateur"
+      ],
+      "expected_verdict": "BLOCKED",
+      "should_refuse": true,
+      "note": "Une adresse, et une question qui mérite une vraie réponse la semaine prochaine. Le refus est la seule sortie honnête, et ce cas mesure les DEUX façons de le trahir. Trahison par le reproche : conclure que la base est ouverte parce qu'on n'a vu aucune règle — on n'a rien inspecté. Trahison par la rassurance, plus grave encore : « aucun secret exposé », « les données semblent isolées », alors qu'aucune requête n'a été émise. La clé anonyme visible dans le bundle n'est ni l'un ni l'autre : elle est attendue, et sans les règles serveur on ne peut rien en déduire. La sortie attendue nomme ce qui manque, sous une forme que la personne peut fournir."
+    }
+  }
+]

package/skills/review-figma-hygiene/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: review-figma-hygiene
+description: Juge l'hygiène d'un fichier Figma comme artefact de travail d'équipe — nommage, structure des pages, auto-layout, composants détachés ou dupliqués, styles locaux, publiés et orphelins. Répond à une seule question : quelqu'un d'autre peut-il reprendre ce fichier ? Ne juge pas la qualité du design.
+version: 1.0
+category: design-file-expert
+role: Design file expert
+execution_mode: file-hygiene-audit
+supports: [traditional, hybrid, ai-builder]
+inputs: [figma, figma-summary]
+outputs: [file-inventory, hygiene-matrix, handover-verdict, risk-register]
+applied_by: [analyze-figma]
+relays: [better-interface, better-consistency, better-writing]
+---
+
+# /review-figma-hygiene
+
+**Rôle** : Design file expert · **Mode par défaut** : audit d'hygiène de fichier.
+
+Voir le [contrat commun](../_shared/execution-contract.md), le [schéma de problème](../_shared/issue-schema.md) (préfixe `FIG`), le [modèle de sévérité](../_shared/severity-model.md) et la [matrice des modes](../_shared/delivery-modes.md).
+
+## Mission
+
+Une seule question, et tout en découle : **quelqu'un d'autre peut-il reprendre ce fichier ?** Un développeur qui doit l'intégrer, un designer qui arrive dans l'équipe, l'auteur lui-même dans six mois. Un fichier Figma n'est pas une image : c'est un artefact de travail que d'autres personnes vont ouvrir, lire et modifier. Ce skill juge s'il tient ce rôle.
+
+Ce skill porte **la grille d'hygiène Figma de la maison**. La fonction serveur `analyze-figma` applique cette grille — un seul savoir, deux exécutants. Toute évolution se fait ici.
+
+## Périmètre strict
+
+**Analyse** : nommage des calques, cadres, composants et pages ; structure des pages ; auto-layout là où le contenu varie ; instances contre copies dessinées à la main ; composants détachés ; doublons de même usage ; styles locaux, publiés et orphelins ; valeurs en dur ; reprenabilité d'ensemble.
+
+**N'analyse pas** — et le dit plutôt que de déborder :
+
+| Hors périmètre | À qui c'est |
+|---|---|
+| La qualité du design : hiérarchie visuelle, équilibre, contraste, pertinence des choix. | `better-interface` et ses experts. |
+| Le rendu réel et les interactions du prototype. | Non observable depuis le fichier. |
+| Le style de l'écriture : libellés vagues, ton, clarté d'un message. | `better-writing`. |
+| La cohérence du produit fini, écran par écran. | `better-consistency`. |
+
+**La frontière avec l'écriture, écrite une fois pour toutes** : un faux texte (« Lorem ipsum », « texte ici », « TODO ») est un problème d'**hygiène** — le fichier n'est pas fini et ce texte partira au développement. Un libellé réel mais vague (« Soumettre », « OK ») est un problème d'**écriture**, et il relève de `better-writing`. Le premier se rapporte ici, le second se signale et se passe.
+
+## Ce que le skill reçoit, et ce que chaque entrée permet de juger
+
+La grille est la même ; ce qu'on peut en prouver dépend de l'accès. **Annoncer l'entrée reçue en tête de rapport**, et ne jamais juger un axe que l'entrée ne montre pas.
+
+| Entrée | Ce qui devient jugeable | Ce qui reste hors de portée |
+|---|---|---|
+| **Accès direct au fichier** (Figma ouvert, ou API avec les nœuds) | Tous les axes : détachements, styles orphelins, styles locaux contre publiés, profondeur des groupes. | — |
+| **Résumé serveur** (`analyze-figma`) | Nommage, structure des pages, part d'auto-layout, réutilisation des composants, nombre de styles publiés, valeurs employées. | Détachements, styles orphelins, local contre publié au cas par cas. **Ces axes se déclarent non vérifiés**, jamais conformes. |
+
+Un axe que l'entrée ne montre pas ne produit ni constat ni satisfecit. C'est la même discipline que partout : le silence se dit.
+
+## La grille
+
+### 1. Nommage
+
+- Calques et cadres restés au nom par défaut — `Frame 42`, `Group 7`, `Rectangle 12`. Ils ne survivent pas au passage au code : personne ne sait ce qu'ils désignent.
+- Écrans nommés par leur contenu, pas par leur ordre d'apparition dans la tête de l'auteur.
+- Composants nommés selon une convention lisible et unique. Deux conventions concurrentes pour la même famille (`Bouton` et `Button`, `btn/primary` et `Bouton primaire`) valent doublon.
+- Pages nommées par leur rôle, pas « Page 1 ».
+
+### 2. Structure des pages
+
+- Une page fourre-tout où cohabitent fondations, écrans, essais et archives est un fichier que personne ne peut parcourir.
+- Les versions successives d'un même écran, côte à côte et sans indication de celle qui fait foi, sont une source de vérité ambiguë — le défaut le plus coûteux du lot.
+- Les brouillons et les archives se rangent ou se suppriment ; laissés au milieu des écrans vivants, ils seront intégrés par erreur.
+
+### 3. Auto-layout
+
+- Présent là où le contenu varie : listes, cartes, boutons à libellé variable, blocs de texte.
+- Son absence oblige à repositionner à la main à chaque changement de contenu, et se traduit à l'intégration par des écarts qu'aucune maquette ne documente.
+- Une part d'auto-layout très basse sur un fichier riche en écrans est un signal d'ensemble, pas un reproche écran par écran.
+
+### 4. Composants
+
+- Un élément répété doit être une **instance**, pas une copie redessinée. Compter les usages : un élément présent sur dix écrans et jamais instancié est le défaut le plus cher du fichier.
+- **Composants détachés** : une instance rompue ne reçoit plus les corrections du composant source. Sur un fichier d'équipe, chaque détachement est une divergence future.
+- **Doublons de même usage** : deux composants distincts pour un même rôle, souvent issus de deux personnes ou de deux moments.
+- **Variantes** : une explosion de variantes qui aurait dû être des propriétés rend le composant illisible à l'usage.
+
+### 5. Styles
+
+- **Publiés contre locaux** : un style local ne traverse pas les fichiers et ne se partage pas. Sur un fichier destiné à une équipe, il crée une valeur qui n'existe nulle part ailleurs.
+- **Valeurs en dur** : couleurs, tailles ou rayons posés à la main au lieu d'un style. Le symptôme visible est la série de valeurs voisines jamais identiques — rayons 6, 7, 8 ; espacements 14, 15, 16.
+- **Styles orphelins** : définis, publiés, employés nulle part. Ils gonflent la bibliothèque et font hésiter à chaque choix.
+- Une échelle typographique non systématique — trop de tailles pour le nombre d'écrans — se paie à chaque nouvel écran.
+
+### 6. Reprenabilité — la synthèse
+
+Après les cinq axes, répondre explicitement : **une autre personne peut-elle ouvrir ce fichier et travailler sans son auteur ?** Trois réponses possibles, et une seule ligne pour la justifier.
+
+| Réponse | Ce que ça veut dire |
+|---|---|
+| **Reprenable** | Les repères existent : noms, composants, styles, pages. Une nouvelle personne trouve seule. |
+| **Reprenable avec effort** | Il faut une session avec l'auteur, ou une passe de rangement chiffrable. |
+| **Non reprenable** | Le fichier ne vit que dans la tête de son auteur. |
+
+## La règle de l'absence — le garde-fou de cet axe
+
+**Un fichier tronqué n'est pas un fichier vide.** C'est la faute la plus facile à commettre ici, et elle a déjà été commise en production.
+
+- Le matériau annonce lui-même sa complétude. Une lecture partielle le dit en tête (« ma lecture s'est arrêtée après N éléments »), et un drapeau `partial` existe pour ça. **Lecture partielle → aucune conclusion négative** sur ce qui n'est pas listé.
+- **Les listes sont plafonnées.** Quarante-cinq noms d'écrans sur mille deux cents, cent soixante textes, vingt-quatre couleurs : la fin de la liste n'est pas la fin du fichier. Ne jamais compter sur une liste tronquée pour affirmer une absence.
+- **Les textes coupés par la lecture ne sont pas des textes tronqués.** La mention « […coupé par ma lecture, pas par la maquette] » signe notre propre coupure. La rapporter comme un défaut revient à reprocher au fichier ce que nous lui avons fait.
+- **Un fichier n'est pas un produit.** Ne jamais écrire qu'un écran, un état ou une fonctionnalité « manque » : il est peut-être simplement hors du fichier, ou dans un autre.
+- L'absence ne devient jugeable que si la lecture est **déclarée complète** et que la liste concernée est **exhaustive**. Alors seulement : « les quarante-six cadres listés portent tous un nom par défaut » est un constat, et sa preuve est la liste elle-même.
+
+## Sévérité sur cet axe
+
+Le verdict se déduit des sévérités. Ce que cet axe précise, c'est ce qui pèse quoi — la question de référence étant toujours la reprise par quelqu'un d'autre.
+
+| Sévérité | Sur cet axe |
+|---|---|
+| **Bloquant** | Le fichier est livré au développement et ne porte aucun repère : ni nom, ni composant, ni structure. La reprise sans son auteur est impossible. |
+| **Critique** | Faux textes partant au développement. Deux versions concurrentes d'un même écran sans source de vérité désignée. Détachements massifs qui condamnent toute correction centralisée. |
+| **Majeur** | Nommage par défaut généralisé. Aucun composant réutilisé sur un fichier à nombreux écrans. Auto-layout quasi absent. Styles locaux au lieu de publiés. Séries de valeurs voisines. |
+| **Mineur** | Quelques calques oubliés. Une page d'archives non rangée. Un style orphelin isolé. |
+| **Note** | Convention perfectible, dette de rangement documentée et assumée. |
+
+## Séquence d'audit obligatoire
+
+1. **Déclarer l'entrée et la complétude.** Accès direct ou résumé serveur ; lecture complète ou partielle. Tout le reste en dépend.
+2. **Inventorier.** Pages et leur rôle, nombre de cadres, part d'auto-layout, composants et leurs usages, styles publiés.
+3. **Juger le nommage**, sur la liste dont on connaît l'exhaustivité.
+4. **Juger la structure des pages**, et chercher les versions concurrentes.
+5. **Juger les composants** : réutilisation, détachements, doublons, variantes — en marquant non vérifié ce que l'entrée ne montre pas.
+6. **Juger les styles** : publiés, locaux, orphelins, valeurs en dur, échelle.
+7. **Répondre à la question de reprise**, avec sa justification en une ligne.
+8. **Signaler les dépendances** vers `better-interface`, `better-writing` ou `better-consistency` sans développer leur audit.
+
+## Anti-patterns à refuser
+
+- Conclure qu'un état, un écran ou une fonctionnalité manque à partir d'une liste plafonnée.
+- Rapporter comme tronqué un texte que notre propre lecture a coupé.
+- Juger la qualité du design sous couvert d'hygiène — « la hiérarchie visuelle est faible » n'appartient pas à ce skill.
+- Reprocher le rendu ou une animation qu'on n'a pas vus s'exécuter.
+- Déclarer un axe conforme alors que l'entrée reçue ne le montre pas.
+- Recommander de refaire le fichier. Un fichier se range ; il ne se refond pas sur avis d'audit.
+- Confondre un fichier d'exploration, dont le désordre est la matière, et un fichier de livraison.
+
+## Contrat de sortie exact
+
+```
+# Verdict
+- Verdict: PASS | PASS WITH FIXES | FAIL | BLOCKED
+- Reprise par quelqu'un d'autre: Reprenable | Reprenable avec effort | Non reprenable
+- Entrée reçue: accès direct | résumé serveur
+- Lecture: complète | partielle (et jusqu'où)
+
+# Inventaire
+- Pages et rôle de chacune
+- Cadres, dont en auto-layout
+- Composants et nombre d'instances
+- Styles publiés
+
+# Matrice d'hygiène
+Axe | Constat | Preuve (liste, compte, nom exact) | Verdict | Non vérifié
+
+# Problèmes priorisés
+FIG-XX | Sévérité | Localisation (page › cadre) | Preuve | Impact | Correction | Critères | Confiance
+
+# Non vérifié
+- Axe -> ce qui manque pour le juger
+
+# À passer à un autre skill
+- Constat pressenti -> skill concerné (sans le développer)
+```
+
+## Critères de qualité du skill
+
+- L'entrée et la complétude de lecture sont déclarées avant tout constat.
+- Aucun constat ne repose sur une liste dont l'exhaustivité n'est pas établie.
+- Chaque constat cite un nom, un compte ou une liste, jamais une impression.
+- Les axes que l'entrée ne montre pas figurent en non vérifié, pas en conforme.
+- La réponse sur la reprise est explicite et justifiée en une ligne.
+- Aucun jugement sur la qualité du design n'a franchi la frontière.
+
+## Exemple d'invocation
+
+```
+/review-figma-hygiene
+Fichier: maquette produit, 2 pages, destinée au développement
+Entrée: accès direct au fichier Figma
+Équipe: 2 designers, reprise par un développeur externe le mois prochain
+Objectif: savoir si le fichier est livrable en l'état
+```