role-os 2.7.1 → 2.9.0

package/CHANGELOG.md

@@ -1,5 +1,43 @@
 # Changelog
 
+## 2.9.0
+
+### Added
+- **Crew dossier — a character sheet per role that configures it at run time.** Each of the 64 roles
+  (the 61 roles + 3 specialty auditors) gets a dossier: six aptitudes (rigor / pace / range /
+  skepticism / autonomy / candor, 0–5) mapped to real dispatch knobs, an 8-archetype **disposition**
+  layer carrying a behavioral instruction, a painted portrait, and a grade. A self-contained crew
+  gallery (`dossier/dossier.html`) renders each role's radar — its tuned build vs the canonical ideal.
+- **Operating Posture dispatch wiring (opt-in, non-breaking).** `src/dossier-block.mjs` injects an
+  "Operating Posture" block — the role's disposition prompt-delta + a posture line from its aptitudes —
+  into `buildRolePrompt` when a dossier exists; roles without one are byte-identical to before. Runtime
+  data ships in `src/role-dossiers.json`. Mirrors the existing knowledge-block injection pattern.
+- Aptitude profiles were calibrated like an instrument: a 10-archetype model → a 3-model cloud panel
+  (per-axis median consensus) → a different-family external-verifier pass breaking collisions → 64
+  unique, knob-faithful fingerprints.
+
+(Full suite 1404 tests green.)
+
+## 2.8.0
+
+### Added
+- **Capability gate — deterministic least-privilege on irreversible tool calls.**
+  `src/specialist/capability-gate.mjs`: a gated set of irreversible / world-touching actions
+  (npm/PyPI publish, `gh release` / `pr` / `repo edit`, `git push`, Pages deploy), a director-authored
+  `.claude/role-os/capabilities.json` grant manifest, and `capabilityGate()`. Opt-in
+  (`ROLEOS_CAPABILITY_GATE`, default OFF → pure no-op), **fail-closed** for the gated set, deterministic
+  (no model). Wired into `onPreToolUse` (deny path) + the generated PreToolUse hook (exit 2), alongside
+  the advisory / fail-open conformance floor. Bounds what a wrong verdict — an honest mistake or an
+  injected one — can DO; the preventive complement to the named-compensator rule (POLA / CaMeL).
+
+### Changed
+- **Wedge #1 conformance — live tool-contracts catalog rollout.** The deterministic schema + computable-
+  contract floor runs at the live `onPreToolUse` seam against `.claude/role-os/tool-contracts.json`
+  (advisory, fail-open), and generated hook scripts emit the current Claude Code wire protocol
+  (`hookSpecificOutput.additionalContext` + exit 0).
+
+(Full suite 1400 tests green.)
+
 ## 2.7.1
 
 ### Docs

package/README.es.md

@@ -89,9 +89,22 @@ Las ejecuciones se guardan en el disco (`.claude/runs/`), por lo que las sesione
 
 Role OS puede consultar a un **analista de presupuesto de tokens** local en cada paso de la distribución y adjuntar una previsión de gasto orientativa al manifiesto: opcional (`ROLEOS_BUDGET_CONSULT`), orientativa (nunca bloquea una distribución) y con un mecanismo de seguridad que vuelve a una línea de base determinista. Desactivado por defecto; la previsión es local y gratuita. Consulte el [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
 
+## Supervisión de las llamadas a herramientas
+
+Role OS verifica y controla las llamadas a herramientas en el punto `PreToolUse`, de forma determinista, sin utilizar ningún modelo en la ruta principal:
+
+- **Monitor de conformidad** (asesoramiento, permite el acceso por defecto) — un esquema determinista + comprobaciones de contrato computables verifican una llamada propuesta con respecto a su contrato de herramienta catalogado y adjuntan un veredicto asesor sobre una llamada *comprobada* como no conforme; nunca bloquea. Un límite opcional para LLM (`ROLEOS_CONFORMANCE_CONSULT`) gestiona el residuo genuinamente semántico.
+- **Control de capacidades** (bloquea por defecto, `ROLEOS_CAPABILITY_GATE` opcional, desactivado por defecto) — control determinista del principio de mínimo privilegio en acciones *irreversibles* (publicación en npm/PyPI, `gh release`, `git push`, edición de repositorios, despliegue de Pages). Se deniega una acción controlada a menos que el administrador haya concedido su capacidad en `.claude/role-os/capabilities.json`, por lo que un paso incorrecto (un error honesto o uno provocado) no puede desencadenar una acción irreversible no autorizada. El complemento preventivo de la regla del compensador nombrado. Consulte el [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/).
+
+## Expediente de la tripulación
+
+Cada rol tiene un **expediente**, una ficha de personaje que también sirve como configuración para el tiempo de ejecución. Seis aptitudes (Rigurosidad, Ritmo, Alcance, Escepticismo, Autonomía, Sinceridad) se corresponden con parámetros reales; una capa de **disposición** de ocho arquetipos (Escéptico, Constructor, Investigador, Rebelde…) incluye una instrucción conductual; y cada rol tiene un retrato pintado y una calificación. Consulte toda la tripulación como una galería (`dossier/dossier.html`); el radar de cada rol muestra su configuración ajustada en comparación con su ideal canónico.
+
+Cuando un rol tiene un expediente, el sistema inyecta una **postura operativa**, que es la instrucción conductual de la disposición más una línea de postura de las aptitudes del rol; así, la ficha realmente configura el rol. Es opcional y aditivo: los roles sin un expediente se comportan exactamente como antes. Consulte el [manual](https://mcp-tool-shop-org.github.io/role-os/handbook/crew-dossier/).
+
 ## Estado de la implementación a nivel de organización
 
-El estado de la implementación a nivel de organización (cola, decisiones, registros de auditoría, paquetes de bloqueo por repositorio) se encuentra en un repositorio privado independiente: [`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout). Este repositorio es el producto; ese repositorio es el estado operativo.
+El estado de implementación a nivel de organización (cola, decisiones, registros de auditoría, paquetes de bloqueo por repositorio) se encuentra en un repositorio **privado** e interno de la organización (`role-os-rollout`). Este repositorio es el producto; ese repositorio es el estado operativo.
 
 ## Memoria y continuidad
 

package/README.fr.md

@@ -13,16 +13,16 @@
   <a href="https://mcp-tool-shop-org.github.io/role-os/"><img src="https://img.shields.io/badge/Landing_Page-live-brightgreen" alt="Landing Page"></a>
 </p>
 
-Un système d’exploitation multi-Claude qui affecte du personnel, dirige, valide et exécute des tâches à travers 61 contrats de rôles spécialisés. Il crée des paquets de tâches, assemble l’équipe appropriée en fonction de critères de correspondance de rôles, détecte les problèmes avant l’exécution, redirige automatiquement les tâches en cas de blocage ou de rejet, et exige des preuves structurées pour chaque décision. Il inclut une répartition dynamique pour les missions à grande échelle — un dépôt de 10 composants devient automatiquement 28 étapes d’audit, au lieu de 6.
+Un système d’exploitation multi-Claude qui affecte du personnel, répartit les tâches, valide et exécute le travail à travers 61 contrats de rôles spécialisés. Il crée des ensembles de tâches, assemble l’équipe appropriée en fonction de critères définis, détecte les problèmes avant l’exécution, redirige automatiquement vers une solution lorsque le travail est bloqué ou rejeté, et exige des preuves structurées pour chaque décision. Il comprend une répartition dynamique pour les missions à grande échelle — un dépôt de 10 composants devient automatiquement 28 étapes d’audit, au lieu de 6.
 
 ## Ce qu’il fait
 
-Role OS est la méthode professionnelle pour utiliser multi-Claude. Il prévient les défaillances spécifiques que les flux de travail d’IA génériques produisent :
+Role OS est la méthode professionnelle pour utiliser multi-Claude. Il prévient les défaillances spécifiques que produisent les flux de travail d’IA génériques :
 
-- **Dérive** — les rôles restent dans leur domaine d’intervention. Le produit ne se redéfinit pas. L’interface ne redéfinit pas la portée. Le backend n’invente pas la direction du produit.
-- **Achèvement incorrect** — la définition de « terminé » est concrète. Les tâches qui masquent des lacunes, omettent la vérification ou résolvent un problème différent sont rejetées.
+- **Dérive** — les rôles restent dans leur domaine d’expertise. Le produit ne se redéfinit pas. L’interface utilisateur ne redéfinit pas la portée. La partie serveur n’invente pas l’orientation du produit.
+- **Achèvement incorrect** — la définition de ce qui est terminé est précise. Le travail qui dissimule des lacunes, omet des vérifications ou résout un problème différent est rejeté.
 - **Contamination** — les projets dérivés ou hérités conservent des éléments d’identité. Role OS détecte et rejette la dérive inter-projets en termes de terminologie, d’éléments visuels et de modèles mentaux.
-- **Progrès basé sur des impressions** — chaque transfert est structuré. Chaque décision est liée à des preuves. « Cela semble terminé » n’est pas un état valide.
+- **Progrès basé sur le ressenti** — chaque transfert est structuré. Chaque décision est liée à des preuves. « Ça a l’air terminé » n’est pas un état valide.
 
 ## Comment il fonctionne
 
@@ -45,10 +45,10 @@ roleos start "something completely novel"
 **L’échelle de repli :**
 
 1. **Mission** — lorsque la tâche correspond à un flux de travail récurrent et éprouvé (correction de bug, traitement, lancement de fonctionnalité, documentation, sécurité, recherche, brainstorming, audit approfondi, test en conditions réelles). Chaîne de rôles connue, flux d’artefacts, branches d’escalade et définitions honnêtes et partielles.
-2. **Paquet** — lorsque la tâche appartient à une famille connue, mais ne correspond pas à une mission complète. 10 paquets d’équipe calibrés avec sélection automatique et protections contre les incompatibilités.
-3. **Routage libre** — lorsque la tâche est nouvelle, mixte ou incertaine. Il évalue les 61 rôles en fonction du contenu du paquet et assemble une chaîne dynamique.
+2. **Ensemble** — lorsque la tâche appartient à une famille connue mais ne correspond pas entièrement à un modèle de mission. 10 ensembles d’équipes calibrées avec sélection automatique et protections contre les incompatibilités.
+3. **Répartition libre** — lorsque la tâche est nouvelle, mixte ou incertaine. Évalue tous les 61 rôles par rapport au contenu de l’ensemble et assemble une chaîne dynamique.
 
-Le système ne force jamais une tâche à passer par une abstraction incorrecte. Il explique pourquoi il a choisi chaque niveau et propose des alternatives.
+Le système ne force jamais le travail à travers une abstraction incorrecte. Il explique pourquoi il a choisi chaque niveau et propose des alternatives.
 
 **Une seule commande pour lancer l’exécution :**
 
@@ -77,52 +77,65 @@ roleos block 2 "waiting for API spec"
 roleos reopen 0 "found issue in review"
 ```
 
-Les exécutions sont conservées sur le disque (`.claude/runs/`), de sorte que les sessions interrompues reprennent en douceur. Chaque étape comprend des instructions pour l’opérateur : ce qui doit être produit, les sections requises et les conditions d’arrêt.
+Les exécutions sont conservées sur le disque (`.claude/runs/`), de sorte que les sessions interrompues reprennent sans problème. Chaque étape comprend des instructions pour l’opérateur : ce qui doit être produit, les sections requises et les conditions d’arrêt.
 
-**Une fois la tâche routée :**
+**Une fois la tâche répartie :**
 
 1. **Chaque rôle produit un transfert** — une sortie structurée avec des éléments de preuve qui réduisent l’ambiguïté pour le rôle suivant.
-2. **Un critique examine par rapport au contrat** — accepte, rejette ou bloque en fonction de preuves structurées, et non d’une simple impression.
-3. **Le routage de reprise se fait automatiquement** — les tâches bloquées ou rejetées sont redirigées vers le bon responsable avec une raison, un type de reprise et l’artefact requis.
+2. **Un critique examine par rapport au contrat** — accepte, rejette ou bloque en fonction de preuves structurées, et non d’une impression.
+3. **La reprise se fait automatiquement** — le travail bloqué ou rejeté est redirigé vers la personne responsable avec une explication, un type de reprise et l’artefact requis.
 
 ## Répartition tenant compte du budget
 
-Role OS peut consulter un **analyste de budget de jetons** local pour chaque étape de répartition et joindre une prévision de dépenses indicative au manifeste — optionnel (`ROLEOS_BUDGET_CONSULT`), à titre indicatif (il ne bloque jamais une répartition) et, en cas d’échec, il revient à une base de référence déterministe. Désactivé par défaut ; la prévision est locale et gratuite. Voir le [manuel](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
+Role OS peut consulter un **analyste de budget de jetons** local pour chaque étape de répartition et joindre une prévision de dépenses indicative au manifeste — optionnel (`ROLEOS_BUDGET_CONSULT`), indicatif (il ne bloque jamais une répartition) et en cas d’échec, il revient à une base de référence déterministe. Désactivé par défaut ; la prévision est locale et gratuite. Voir le [manuel](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
 
-## État du déploiement à l’échelle de l’organisation
+## Supervision des appels d’outils
 
-L’état du déploiement à l’échelle de l’organisation (file d’attente, décisions, enregistrements d’audit, paquets de verrouillage par dépôt) est stocké dans un dépôt privé distinct : [`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout). Ce dépôt est le produit ; ce dépôt est l’état opérationnel.
+Role OS vérifie et contrôle les appels d’outils au niveau de `PreToolUse` — de manière déterministe, sans modèle sur le chemin critique :
+
+- **Surveillance de la conformité** (indicatif, en cas d’échec, il revient à une base de référence) — un schéma déterministe + des seuils de contrat calculables vérifient un appel proposé par rapport à son contrat d’outil catalogué et joignent une évaluation indicative sur un appel *manifestement* non conforme ; il ne bloque jamais. Un plafond LLM optionnel (`ROLEOS_CONFORMANCE_CONSULT`) gère les éléments sémantiques restants.
+- **Contrôle des capacités** (en cas d’échec, optionnel `ROLEOS_CAPABILITY_GATE`, désactivé par défaut) — privilèges minimums déterministes sur les actions *irréversibles* (publication npm/PyPI, `gh release`, `git push`, modifications du dépôt, déploiement de Pages). Une action contrôlée est refusée à moins que le responsable n’ait accordé sa capacité dans `.claude/role-os/capabilities.json`, de sorte qu’une étape incorrecte — une erreur honnête ou une injection malveillante — ne puisse pas déclencher une action irréversible non autorisée. Le complément préventif à la règle du compensateur nommé. Voir le [manuel](https://mcp-tool-shop-org.github.io/role-os/handbook/).
+
+## Dossier de l’équipe
+
+Chaque rôle possède un **dossier** : une fiche de personnage qui sert également de fichier de configuration en cours d’exécution. Six aptitudes (Rigueur, Rythme, Portée, Scepticisme, Autonomie, Franchise) correspondent à des paramètres réels ; une couche de **disposition** comportant huit archétypes (Sceptique, Constructeur, Enquêteur, Iconoclaste…) contient une instruction comportementale ; et chaque rôle possède un portrait peint et une note. Parcourez toute l’équipe comme dans une galerie (`dossier/dossier.html`) : le radar de chaque rôle affiche sa configuration personnalisée par rapport à son idéal canonique.
+
+Lorsqu’un rôle possède un dossier, la fonction d’affectation injecte une **posture opérationnelle** : l’instruction comportementale de la disposition, ainsi qu’une ligne de posture tirée des aptitudes du rôle ; ainsi, la fiche configure réellement le rôle. Optionnel et cumulatif : les rôles sans dossier se comportent exactement comme auparavant. Voir le [manuel](https://mcp-tool-shop-org.github.io/role-os/handbook/crew-dossier/).
+
+## État de déploiement au niveau de l’organisation
+
+L’état du déploiement à l’échelle de l’organisation (file d’attente, décisions, enregistrements d’audit, paquets de verrouillage par dépôt) est stocké dans un **référentiel privé** distinct, interne à l’organisation (`role-os-rollout`). Ce référentiel est le produit ; ce référentiel contient l’état opérationnel.
 
 ## Mémoire et continuité
 
-Role OS ne possède ni ne duplique la couche de mémoire. Là où la mémoire du projet Claude existe, c’est le système de continuité canonique — les faits du dépôt, les décisions, les points en suspens et l’historique du traitement s’y trouvent.
+Role OS ne possède ni ne duplique la couche de mémoire. Là où la mémoire du projet Claude existe, c’est le système de continuité canonique — les faits du dépôt, les décisions, les points en suspens et l’historique des traitements s’y trouvent.
 
 Role OS s’intègre à la mémoire du projet Claude. Il ne la remplace pas.
 
-## Traitement complet et vérification avant lancement
+## Traitement complet et vérification finale
 
-Le traitement complet est un protocole canonique en 7 phases défini dans la mémoire du projet Claude (`memory/full-treatment.md`). Role OS route et examine les traitements à l’aide de contrats de rôles, de transferts et de contrôles — il ne redéfinit pas le protocole.
+Le traitement complet est un protocole canonique en 7 phases défini dans la mémoire du projet Claude (`memory/full-treatment.md`). Role OS répartit et examine les traitements à l’aide de contrats de rôles, de transferts et de contrôles critiques — il ne redéfinit pas le protocole.
 
-La **vérification avant lancement** est le contrôle de qualité en 31 étapes qui s’exécute avant le traitement complet. Les contrôles stricts A à D doivent être réussis avant le début de tout traitement. Référence canonique : `memory/shipcheck.md`.
+La **vérification finale** est la grille de qualité en 31 éléments qui s’exécute avant le traitement complet. Les étapes A à D doivent être franchies avant que tout traitement ne commence. Référence canonique : `memory/shipcheck.md`.
 
-Ordre : vérification avant lancement d’abord, puis traitement complet. Pas de version 1.0.0 sans avoir réussi les contrôles stricts.
+Ordre : vérification finale d’abord, puis traitement complet. Pas de version 1.0.0 sans avoir réussi les étapes obligatoires.
 
-## 61 rôles répartis en 10 paquets
+## 61 rôles répartis en 10 ensembles
 
-| Paquet | Rôles |
+| Ensemble | Rôles |
 |------|-------|
 | **Core** (3) | Orchestrateur, stratège produit, critique |
-| **Engineering** (7) | Développeur frontend, ingénieur backend, ingénieur de test, ingénieur de refactorisation, ingénieur de performance, auditeur de dépendances, examinateur de sécurité |
+| **Engineering** (7) | Développeur frontend, ingénieur backend, ingénieur de test, ingénieur de refactoring, ingénieur de performance, auditeur des dépendances, examinateur de sécurité |
 | **Design** (2) | Concepteur d’interface utilisateur, gardien de la marque |
-| **Marketing** (1) | Rédacteur de contenu de lancement |
-| **Treatment** (7) | Chercheur de dépôt, traducteur de dépôt, architecte de documentation, conservateur de métadonnées, auditeur de couverture, vérificateur de déploiement, ingénieur de publication |
+| **Marketing** (1) | Rédacteur pour les lancements |
+| **Treatment** (7) | Chercheur sur les dépôts, traducteur pour les dépôts, architecte de la documentation, conservateur des métadonnées, auditeur de la couverture, vérificateur du déploiement, ingénieur en charge des versions |
 | **Product** (3) | Synthétiseur de commentaires, priorisateur de feuille de route, rédacteur de spécifications |
-| **Research** (4) | Chercheur UX, analyste concurrentiel, chercheur de tendances, synthétiseur d’entretiens avec les utilisateurs |
-| **Growth** (4) | Stratège de lancement, stratège de contenu, responsable de la communauté, responsable du triage du support |
-| **Deep Audit** (4) | Auditeur de composants, auditeur de la vérité des tests, auditeur des interfaces, synthétiseur d’audit |
-| **Swarm** (7) | Coordinateur de l’équipe, agent backend de l’équipe, agent de liaison de l’équipe, agent de tests de l’équipe, agent d’infrastructure de l’équipe, agent frontend de l’équipe, synthétiseur de l’équipe |
+| **Research** (4) | Chercheur UX, analyste concurrentiel, chercheur sur les tendances, synthétiseur d’entretiens avec les utilisateurs |
+| **Growth** (4) | Stratège pour les lancements, stratège en matière de contenu, responsable de la communauté, responsable du tri des demandes d’assistance |
+| **Deep Audit** (4) | Auditeur des composants, auditeur de la véracité des tests, auditeur des interfaces, synthétiseur d’audits |
+| **Swarm** (7) | Coordinateur de l’essaim, agent backend de l’essaim, agent de pont de l’essaim, agent de test de l’essaim, agent d’infrastructure de l’essaim, agent frontend de l’essaim, synthétiseur de l’essaim |
 
-Chaque rôle dispose d’un contrat complet : mission, quand l’utiliser, quand ne pas l’utiliser, entrées attendues, sorties requises, norme de qualité et déclencheurs d’escalade. Chaque rôle peut être affecté — `roleos route` peut en recommander l’un ou l’autre en fonction du contenu du paquet.
+Chaque rôle est associé à un contrat complet : mission, cas d’utilisation, moments où il ne doit pas être utilisé, entrées attendues, sorties requises, niveau de qualité et déclencheurs d’escalade. Chaque rôle peut être affecté — `roleos route` peut en recommander n’importe lequel en fonction du contenu du paquet.
 
 ## Démarrage rapide
 
@@ -165,52 +178,52 @@ roleos packs list
 
 ## Quand ne pas utiliser Role OS
 
-- Corrections ponctuelles, fautes de frappe ou bogues évidents
+- Corrections sur une seule ligne, fautes de frappe ou bogues évidents
 - Recherche exploratoire sans résultat défini
-- Travail qui tient dans l’esprit d’une seule personne en 5 minutes
-- Corrections d’urgence qui doivent être déployées avant la fin du processus de révision
-- Projets où la rapidité est plus importante que la structure
+- Travail qui peut être réalisé par une personne en 5 minutes
+- Correctifs d’urgence qui doivent être déployés avant la fin du processus d’examen
+- Projets où vous privilégiez la rapidité à la structure
 
 ## Preuves
 
-Role OS a été testé avec trois configurations différentes dans deux référentiels structurellement distincts :
+Role OS a été testé avec trois types de projets différents dans deux dépôts structurellement différents :
 
-**Test 001 — Travail sur une fonctionnalité** (écran de l’équipe, Star Freight)
+**Projet 001 — Travail sur une fonctionnalité** (écran Crew, Star Freight)
 - Chaîne de 7 rôles, 45 scénarios de test, 0 conflits de rôles
-- Empêche la contamination provenant d’une branche ancestrale, détecte les inventions en ligne, met en évidence les obstacles réels
+- A empêché la contamination provenant d’un ancêtre du fork, a détecté une invention en ligne et a mis en évidence les blocages réels
 
-**Test 002 — Travail d’intégration** (liaison CampaignState, Star Freight)
-- Chaîne de 5 rôles, résolution d’une discontinuité architecturale sans recours à des solutions de contournement
-- Les tests anti-contournement prouvent que le chemin actif est réel, et non un simple espace réservé
+**Projet 002 — Travail d’intégration** (liaison CampaignState, Star Freight)
+- Chaîne de 5 rôles, a résolu un problème architectural sans recourir à des solutions de contournement
+- Les tests anti-contournement ont prouvé que le chemin actif est réel et non un simple espace réservé
 
-**Test 003 — Travail sur l’identité** (purge de la contamination, Star Freight)
-- Chaîne de 6 rôles, 51 scénarios de test, y compris une défense durable contre la contamination dans l’environnement CI
-- Correction des dérives héritées sans entraîner une refonte complète
+**Projet 003 — Travail sur l’identité** (suppression de la contamination, Star Freight)
+- Chaîne de 6 rôles, 51 scénarios de test, y compris une défense durable contre la contamination dans le CI
+- A corrigé les incohérences héritées sans entraîner une refonte importante
 
-**Test de portabilité** (cohérence de la persona, humour basé sur les capteurs)
-- Même structure de base, langage/domaine/pile technologique différents
-- Adapté avec des modifications contextuelles uniquement, sans modifications du contrat de base
+**Test de portabilité** (cohérence des personas, humour sensoriel)
+- Même structure, langue/domaine/pile différents
+- Adopté avec seulement des modifications contextuelles — aucune modification du contrat principal
 
 **Traitement complet FT-001** (portlight-desktop)
-- Traitement en 7 phases avec les rôles du « Treatment Pack »
-- La validation du « Shipcheck » a été prouvée, aucun conflit de rôles
+- Traitement en 7 phases avec les rôles du pack de traitement
+- La validation avant le déploiement a été prouvée, aucun conflit de rôle
 
 **Traitement complet FT-002** (studioflow)
-- Même « Treatment Pack », référentiel structurellement différent (espace de travail créatif par rapport à un jeu)
-- Le « Treatment Pack » est portable, aucune modification du contrat n’est nécessaire
+- Même pack de traitement, dépôt structurellement différent (espace de travail créatif par rapport à un jeu)
+- Le pack de traitement est portable — aucune modification du contrat n’est nécessaire
 
-**Session de brainstorming réussie** (sujet du marché MCP)
-- Chaîne de 9 rôles, 4 analystes en parallèle, examen croisé + réfutation du graphique des litiges
-- 4 défis lancés, 3 revendications affinées, 1 non résolue — une pression saine, pas d’impasse
+**Session de brainstorming réussie** (sujet du marché MCP server)
+- Chaîne de 9 rôles, 4 analystes en parallèle, examen croisé + réfutation du graphique des désaccords
+- 4 défis lancés, 3 revendications affinées, 1 non résolu — une pression saine, pas d’impasse
 - Plus de 16 liens de traçabilité à partir des artefacts rendus vers les atomes de la couche de vérité
-- Chaîne de traçabilité complète prouvée : vérité → atomes → litige → synthèse → expansion → jugement → rendu → traçabilité
+- Chaîne complète de traçabilité prouvée : vérité → atomes → désaccord → synthèse → expansion → jugement → rendu → traçabilité
 
-## Propriétés essentielles
+## Propriétés principales
 
 Elles sont non négociables. Si une modification affaiblit l’une d’entre elles, rejetez-la.
 
 - Les limites des rôles sont respectées
-- La révision est rigoureuse
+- L’examen est rigoureux
 - L’escalade reste honnête
 - Les paquets restent testables
 - La portabilité nécessite une adaptation contextuelle, et non une chirurgie du cœur
@@ -255,54 +268,54 @@ role-os/
 
 ## Sécurité
 
-Role OS fonctionne **uniquement en local**. Il copie les modèles Markdown et écrit les fichiers de paquets/décisions dans le répertoire `.claude/` de votre référentiel. Il n’accède pas au réseau, ne gère pas les secrets et ne collecte pas de données de télémétrie. Aucune opération dangereuse — par défaut, toutes les écritures de fichiers utilisent l’option « skip-if-exists ». Voir [SECURITY.md](SECURITY.md) pour la politique complète.
+Role OS fonctionne **uniquement en local**. Il copie les modèles Markdown et écrit les fichiers de paquets/décisions dans le répertoire `.claude/` de votre dépôt. Il n’accède pas au réseau, ne gère pas les secrets et ne collecte pas de données de télémétrie. Aucune opération dangereuse — par défaut, toutes les écritures de fichiers utilisent l’option « ignorer si existant ». Consultez le fichier [SECURITY.md](SECURITY.md) pour connaître la politique complète.
 
 ## Le système d’exploitation
 
 | Couche | Ce qu’il fait | Statut |
 |-------|-------------|--------|
-| **Routing** | Attribue un score à chacun des 61 rôles en fonction du contenu du paquet, explique les recommandations et évalue la confiance | ✓ Déployé |
-| **Chain builder** | Assemble des chaînes ordonnées par phase à partir des rôles notés, en privilégiant le type de paquet plutôt qu’en se limitant aux modèles | ✓ Déployé |
-| **Conflict detection** | Validation en 4 passes : conflits importants, séquence, redondance, lacunes de couverture. Suggestions de correction. | ✓ Déployé |
-| **Escalation** | Acheminement automatique du travail bloqué/rejeté/divisé vers le bon résolveur avec la raison et l’artefact requis | ✓ Déployé |
-| **Evidence** | Preuves structurées et spécifiques aux rôles dans les décisions. Vérifications de suffisance. 12 types de preuves. | ✓ Déployé |
+| **Routing** | Attribue un score à chacun des 61 rôles en fonction du contenu du paquet, explique les recommandations et évalue la confiance. | ✓ Déployé |
+| **Chain builder** | Assemble des chaînes ordonnées par phase à partir des rôles notés, avec une préférence pour le type de paquet plutôt que pour un modèle prédéfini. | ✓ Déployé |
+| **Conflict detection** | Validation en 4 étapes : conflits importants, séquence, redondance, lacunes de couverture. Suggestions de correction. | ✓ Déployé |
+| **Escalation** | Achemine automatiquement les travaux bloqués/rejetés/divisés vers le bon résolveur avec une explication et l’artefact requis. | ✓ Déployé |
+| **Evidence** | Preuves structurées tenant compte du rôle dans les décisions. Vérifications de suffisance. 12 types de preuves. | ✓ Déployé |
 | **Dispatch** | Génère des manifestes d’exécution pour multi-claude. Profils d’outils par rôle, invites système, budgets. | ✓ Déployé |
-| **Trials** | Ensemble complet prouvé : 30 tâches « or » + 5 tests négatifs. 7 tests de paquets terminés. | ✓ Terminé |
-| **Team Packs** | 10 paquets calibrés avec sélection automatique, protections contre les incompatibilités et solution de repli à routage libre. | ✓ Déployé |
-| **Outcome calibration** | Enregistre les résultats de l’exécution, ajuste les pondérations des paquets/rôles en fonction des résultats et modifie les seuils de confiance. | ✓ Déployé |
-| **Mixed-task decomposition** | Détecte le travail composite, le divise en paquets enfants, assigne des paquets et conserve les dépendances. | ✓ Déployé |
-| **Composite execution** | Exécute les paquets enfants dans l’ordre des dépendances, avec transfert d’artefacts, récupération des branches et synthèse. | ✓ Déployé |
+| **Trials** | Ensemble complet prouvé : 30/30 tâches réussies + 5/5 essais négatifs. 7 essais de pack terminés. | ✓ Terminé |
+| **Team Packs** | 10 packs calibrés avec sélection automatique, protections contre les incompatibilités et repli en cas de routage libre. | ✓ Déployé |
+| **Outcome calibration** | Enregistre les résultats des exécutions, ajuste les pondérations des packs/rôles à partir des résultats et modifie les seuils de confiance. | ✓ Déployé |
+| **Mixed-task decomposition** | Détecte le travail composite, divise en paquets enfants, assigne des packs et conserve les dépendances. | ✓ Déployé |
+| **Composite execution** | Exécute les paquets enfants dans l’ordre des dépendances avec transfert d’artefacts, récupération de branche et synthèse. | ✓ Déployé |
 | **Adaptive replanning** | Les modifications de portée, les découvertes ou les nouvelles exigences en cours d’exécution mettent à jour le plan sans redémarrer. | ✓ Déployé |
 | **Session spine** | `roleos init claude` crée les fichiers CLAUDE.md, /roleos-route, /roleos-review, /roleos-status. `roleos doctor` vérifie la configuration. Les cartes de routage prouvent l’engagement. | ✓ Déployé |
-| **Hook spine** | 5 hooks de cycle de vie (SessionStart, PromptSubmit, PreToolUse, SubagentStart, Stop). Application consultative : rappels de la carte de routage, validation de l’utilisation des outils, injection du rôle du sous-agent, audit de l’achèvement. | ✓ Déployé |
-| **Artifact spine** | Contrats d’artefacts par rôle. Contrats de transfert de paquets. Validation structurelle. Vérifications de l’exhaustivité de la chaîne. Les rôles en aval ne devinent jamais ce qu’ils ont reçu. | ✓ Déployé |
-| **Mission library** | 9 missions nommées (feature-ship, bugfix, treatment, docs-release, security-hardening, research-launch, brainstorm, deep-audit, dogfood-swarm). Chacune déclare le paquet, la chaîne de rôles, le flux d’artefacts, les branches d’escalade et une définition honnête et partielle. | ✓ Déployé |
-| **Mission runner** | Créer des exécutions, parcourir les étapes avec un état suivi, terminer/échouer avec un rapport honnête. Propagation des étapes bloquées, avertissements d’escalade hors chaîne, réouverture de la dernière étape. | ✓ Déployé |
-| **Unified entry** | `roleos start` décide automatiquement de la mission, du paquet ou du routage libre. Échelle de repli avec des scores de confiance, des alternatives et une détection composite. | ✓ Déployé |
-| **Persistent runs** | `roleos run` crée des exécutions stockées sur disque. `resume`, `next`, `explain`, `complete`, `fail`. Interventions : reroutage, escalade, nouvelle tentative, blocage, réouverture. Guide spécifique à chaque étape. Mesure du frottement. | ✓ Déployé |
-| **Brainstorm** | Architecture à deux couches : vérité (schémas natifs des rôles, atomes de provenance, graphique des litiges d’examen croisé) + rendu (5 voix distinctes, interdictions lexicales, transcription du débat). Les liens de traçabilité prouvent que chaque revendication rendue correspond à un atome de vérité. Session réussie prouvée. | ✓ Déployé |
-| **Deep Audit** | Audit de dépôt basé sur le manifeste : décomposer le dépôt en composants, affecter N auditeurs + M auditeurs de tests de validation + K auditeurs de points de jonction à partir du graphe de dépendances, synthétiser en un verdict classé et un plan d’action. L’affectation dynamique s’adapte à la taille du dépôt (formule : 2N + K + 3). Exécution native avec validation des artefacts à chaque étape. | ✓ Déployé |
-| **Dogfood Swarm** | Convergence en plusieurs étapes : trois étapes de vérification (bogues/sécurité → proactivité → humanisation), puis étape des fonctionnalités. Propriété exclusive des fichiers, validations après chaque cycle, points de contrôle utilisateur. La détection automatique du domaine génère les manifestes. Pont de preuves vers les laboratoires de test. | ✓ Déployé |
-
-## 9 missions
-
-| Mission | Paquet | Rôles | Quand l’utiliser |
+| **Hook spine** | 5 hooks du cycle de vie (SessionStart, PromptSubmit, PreToolUse, SubagentStart, Stop). Application consultative : rappels sur les cartes de routage, validation avant l’utilisation des outils, injection du rôle d’un sous-agent, audit de la complétion. | ✓ Déployé |
+| **Artifact spine** | Contrats d’artefacts par rôle. Contrats de transfert de pack. Validation structurelle. Vérifications de l’exhaustivité de la chaîne. Les rôles en aval ne devinent jamais ce qu’ils ont reçu. | ✓ Déployé |
+| **Mission library** | 9 missions nommées (fonctionnalité principale, correction de bugs, traitement, publication de la documentation, renforcement de la sécurité, lancement d’une recherche, séance de brainstorming, audit approfondi, phase de test interne). Chacune définit le groupe, la chaîne de rôles, le flux des éléments, les branches d’escalade et une définition partielle mais précise. | ✓ Déployé |
+| **Mission runner** | Exécutez des tests, parcourez les étapes en suivant l’état, terminez ou échouez avec un compte rendu précis. Propagation d’étape bloquée, avertissements de dépassement du nombre maximal d’étapes, réouverture de la dernière étape. | ✓ Déployé |
+| **Unified entry** | La commande `roleos start` détermine automatiquement le mode de routage à utiliser : mission, ensemble ou libre. En cas d’échec, elle utilise une série d’options de repli avec des niveaux de confiance, des itinéraires alternatifs et une détection combinée. | ✓ Déployé |
+| **Persistent runs** | « `roleos run` » crée des exécutions dont les données sont stockées sur disque. « `resume` », « `next` », « `explain` », « `complete` », « `fail` ». Interventions possibles : redirection, escalade, nouvelle tentative, blocage, réouverture. Instructions spécifiques à chaque étape. Mesure des frottements. | ✓ Déployé |
+| **Brainstorm** | Architecture à deux niveaux : vérité (schémas natifs liés aux rôles, éléments de provenance, graphe des arguments contradictoires) + rendu (5 voix distinctes, interdictions lexicales, transcription du débat). Les liens de traçabilité prouvent que chaque affirmation rendue correspond à un élément de vérité. Test réussi et validé. | ✓ Déployé |
+| **Deep Audit** | Audit du dépôt basé sur le manifeste : décomposer le dépôt en composants, affecter N auditeurs, M auditeurs chargés de vérifier la conformité et K auditeurs chargés d’examiner les interfaces à partir du graphe des dépendances, synthétiser les résultats pour obtenir un classement et un plan d’action. L’affectation dynamique s’adapte à la taille du dépôt (formule : 2N + K + 3). Exécution native avec validation des artefacts à chaque étape. | ✓ Déployé |
+| **Dogfood Swarm** | Convergence en plusieurs étapes : trois phases de développement (correction des bugs/sécurité → approche proactive → amélioration de l’expérience utilisateur), puis phase d’ajout de fonctionnalités. Propriété exclusive des fichiers, validation à chaque étape du processus, points de contrôle pour les utilisateurs. Détection automatique du domaine qui génère les manifestes. Liaison vers les environnements de test internes (dogfood-labs). | ✓ Déployé |
+
+## 9 missions
+
+| Mission | Ensemble | Rôles | Quand l’utiliser ? |
 |---------|------|-------|-------------|
-| `feature-ship` | Fonctionnalité | 5 | Livraison complète d’une fonctionnalité : portée → spécification → implémentation → test → revue |
-| `bugfix` | Correction de bogue | 4 | Diagnostiquer la cause première, corriger, tester, vérifier |
-| `treatment` | Traitement | 4 | Vérification avant publication + amélioration + documentation + vérification CI + revue |
-| `docs-release` | Documentation | 2 | Rédiger/mettre à jour la documentation, notes de publication |
-| `security-hardening` | Sécurité | 4 | Modèle de menace, audit, correction des vulnérabilités, réaudit, vérification |
-| `research-launch` | Recherche | 4 | Formuler la question, effectuer des recherches, documenter les résultats, prendre une décision |
-| `brainstorm` | Brainstorming | 9 | Analyse structurée et multiperspective avec désaccord et verdict traçables |
-| `deep-audit` | Audit approfondi | 5 (échelles) | Audit de dépôt basé sur le manifeste : le nombre de travailleurs s’adapte à la taille du graphe du dépôt via une affectation dynamique |
-| `dogfood-swarm` | Essaim | 8 (échelles) | Convergence en plusieurs étapes : vérification-a → vérification-b → vérification-c → fonctionnalité → synthèse finale |
+| `feature-ship` | fonctionnalité ; mettre en avant ; figurer dans | 5 | Déploiement complet des fonctionnalités : définition du périmètre → spécifications → mise en œuvre → tests → évaluation |
+| `bugfix` | correction de bug | 4 | Identifier la cause profonde, corriger, tester, vérifier. |
+| `treatment` | traitement | 4 | Vérification du code source + correction + documentation + vérification par l’intégration continue + relecture |
+| `docs-release` | documents | 2 | Rédiger et mettre à jour la documentation, les notes de version. |
+| `security-hardening` | sécurité | 4 | Analyse des risques, audit, correction des vulnérabilités, nouvel audit, vérification. |
+| `research-launch` | recherche | 4 | Définir la problématique, mener des recherches, consigner les résultats, prendre une décision. |
+| `brainstorm` | session de brainstorming / séance de remue-méninges | 9 | Enquête structurée et multidimensionnelle, permettant de suivre les désaccords et d’aboutir à une conclusion. |
+| `deep-audit` | audit approfondi | 5 (gammes) | Audit de dépôt pris en charge par Manifest : le nombre d’utilisateurs participant à l’audit s’adapte à la taille du graphe du dépôt grâce à une répartition dynamique des tâches. |
+| `dogfood-swarm` | essaim | 8 (gammes) | Convergence en plusieurs étapes : état de santé A → état de santé B → état de santé C → caractéristique → synthèse finale. |
 
-Chaque mission comprend des définitions honnêtes et partielles : lorsque le travail est interrompu, le système documente ce qui a été réalisé et ce qui reste à faire, au lieu de prétendre que tout est terminé.
+Chaque tâche comprend une description précise et honnête de l’état d’avancement : lorsque la progression est interrompue, le système enregistre ce qui a été réalisé et ce qui reste à faire, au lieu de prétendre que la tâche est terminée.
 
-### Mission de brainstorming
+### Session de brainstorming sur la mission
 
-Pas de « brainstorming par IA ». La mission de brainstorming consiste en des **rôles spécialisés encadrés par la loi, avec un désaccord et un résultat traçables.**
+Pas de « séances de remue-méninges sur l’IA ». La mission de la séance de remue-méninges consiste à définir des **rôles spécialisés encadrés par la loi, avec un processus clair permettant d’identifier les désaccords et aboutissant à une décision définitive.**
 
 ```bash
 roleos run "explore product directions for a developer tool discovery platform"
@@ -310,19 +323,19 @@ roleos run "explore product directions for a developer tool discovery platform"
 #   Chain: 4 Analysts (parallel) → Normalize → Cross-Examine → Rebut → Synthesize → Expand → Judge
 ```
 
-**Ce qui la rend différente :**
+**Qu’est-ce qui le distingue ?**
 
-- **Niveau 1 (vérité) :** Quatre analystes émettent des schémas propres à leur rôle (ContextMap, UserValueMap, MechanicsMap, PositioningMap) : pas de texte partagé. Chaque rôle applique des restrictions : phrases interdites, types de revendications interdits, partitions d’entrée filtrées. Les atomes contiennent des informations sur leur provenance. Un graphe d’interrogation croisée dirigé produit des défis ciblés. Les analystes d’origine défendent, affinent ou retirent leurs affirmations sous la pression.
+- **Niveau 1 (vérité) :** Quatre analystes émettent des schémas spécifiques à leur rôle (ContextMap, UserValueMap, MechanicsMap, PositioningMap), et non un texte partagé. Chaque rôle est soumis à des contraintes visant à éviter les angles morts : expressions interdites, types d’affirmations interdits, partitions d’entrée filtrées. Les éléments de données contiennent des informations sur leur origine. Un graphique d’interrogation croisée dirigée permet de formuler des questions ciblées. Les analystes initiaux défendent leurs positions, les affinent ou s’en désistent sous la pression.
 
-- **Niveau 2 (présentation) :** Cinq voix humaines distinctes (Note de synthèse, Notes de terrain, Schéma du système, Résumé des revendications, Transcription de l’interrogatoire) avec des interdictions lexicales empêchant la convergence des voix. La synthèse utilise la vérité, jamais le texte déjà présenté. Les deux niveaux sont toujours disponibles.
+- **Couche 2 (rendu) :** Cinq voix humaines distinctes (Note de service, Observations sur le terrain, Schéma du système, Exposé des faits, Transcription d’un contre-interrogatoire), avec des restrictions lexicales empêchant la convergence des voix. La synthèse déforme la vérité, sans jamais produire un texte cohérent. Les deux couches sont toujours accessibles.
 
-- **Chaîne de traçabilité :** Chaque phrase présentée peut être retracée jusqu’à un atome du niveau de vérité. Les directions de synthèse citent les atomes. Les cibles de l’interrogatoire sont des identifiants de revendications réels. Le graphe de désaccord est le résultat, et non le texte.
+- **Chaîne de traçabilité :** Chaque phrase générée peut être retracée jusqu’à un élément fondamental de la couche de vérité. Les instructions de synthèse font référence à ces éléments. Les interrogatoires visent des identifiants de revendications réels. Le graphique des litiges est le résultat, et non le texte lui-même.
 
-**Prouvé :** Exécution de référence v0.4 : chaîne de traçabilité complète vérifiée. Voir [`examples/golden-run.md`](examples/golden-run.md) pour la chaîne d’artefacts complète.
+**Validé :** version 0.4, exécution de référence – l’intégrité de la chaîne de traçabilité a été vérifiée. Consultez le fichier [`examples/golden-run.md`](examples/golden-run.md) pour obtenir la liste complète des éléments constitutifs.
 
-### Mission d’audit approfondi
+### Mission d’audit approfondie
 
-Pas un simple scan de surface. La mission d’audit approfondi **décompose un dépôt en composants délimités et affecte des auditeurs spécialisés à une échelle déterminée par le propre graphe de dépendances du dépôt.**
+Il ne s’agit pas d’une simple analyse superficielle. La mission d’audit approfondi décompose le dépôt en composants distincts et affecte des auditeurs spécialisés, en fonction de l’échelle déterminée par le graphe de dépendances du dépôt.
 
 ```bash
 roleos run "deep audit this repo" --manifest=audit-manifest.json
@@ -330,19 +343,19 @@ roleos run "deep audit this repo" --manifest=audit-manifest.json
 #   Steps: Component Auditor ×6 + Test Truth Auditor ×6 + Seam Auditor ×8 + Synthesizer + Action Plan + Critic = 23 steps
 ```
 
-**Ce qui la rend différente :**
+**Qu’est-ce qui le distingue ?**
 
-- **Affectation dynamique :** le nombre de travailleurs n’est pas fixe. Un dépôt de 10 composants avec 5 clusters de limites produit 28 étapes (2 × 10 + 5 + 3). Un dépôt de 3 composants produit 12 étapes. La formule d’adaptation est : `2N + K + 3`, où N = composants, K = limites.
-- **Parcelles basées sur le manifeste :** un fichier `audit-manifest.json` définit les composants (avec les chemins de fichiers, le nombre de lignes, les descriptions) et les limites (de/à avec les descriptions de l’interface). Chaque auditeur ne reçoit que sa parcelle.
-- **Quatre archétypes de rôles :** Auditeur de composants (vérité du code par module), Auditeur de tests de validation (tests qui prouvent par rapport aux tests qui existent), Auditeur de points de jonction (limites d’intégration du graphe de dépendances), Synthétiseur d’audit (verdict classé + plan d’action à partir de toutes les parcelles).
-- **Validation des artefacts à chaque étape :** `validateArtifact()` est déclenché à la fin de chaque étape dans les deux chemins d’exécution. Les résultats sont joints aux objets d’étape. Le système sait si chaque artefact a respecté son contrat.
-- **Honnêteté partielle :** lorsque le budget ou la portée empêchent l’achèvement, les résultats par composant sont valides individuellement. Le système synthétise à partir de ce qui a été réalisé, sans jamais prétendre à une couverture complète.
+- **Répartition dynamique** : le nombre d’agents n’est pas fixe. Un dépôt de 10 composants avec 5 groupes de limites produit 28 étapes (2 × 10 + 5 + 3). Un dépôt de 3 composants en produit 12. La formule de mise à l’échelle est « 2N + K + 3 », où N = nombre de composants, K = nombre de limites.
+- **Ensembles de données basés sur un manifeste** : un fichier `audit-manifest.json` définit les composants (avec les chemins d’accès aux fichiers, le nombre de lignes et les descriptions) et les limites (de/vers, avec des descriptions des interfaces). Chaque auditeur ne reçoit que son ensemble de données.
+- **Quatre archétypes de rôles** : Auditeur de composants (vérification du code par module), Auditeur de la validité des tests (tests qui prouvent par rapport aux tests existants), Auditeur des points d’intégration (limites d’intégration à partir du graphe de dépendances), Synthétiseur d’audit (résultat classé + plan d’action à partir de tous les ensembles de données).
+- **Validation des artefacts à chaque étape** : la fonction `validateArtifact()` est exécutée à la fin de chaque étape dans les deux chemins d’exécution. Les résultats sont associés aux objets d’étape. Le système sait si chaque artefact a respecté son contrat.
+- **Résultats partiels honnêtes** : lorsque le budget ou la portée empêche l’achèvement, les résultats par composant sont valides individuellement. Le système synthétise à partir de ce qui a été achevé et ne prétend jamais avoir couvert tous les aspects.
 
-**Prouvé :** Exécution native du Runner : 18 tests sur un manifeste réel, cycle de vie complet vérifié, y compris la réouverture en cas d’escalade et l’échec partiel. La formule d’adaptation a été vérifiée pour les manifestes de 3/6/10/15 composants.
+**Résultats confirmés :** Exécution d’un test de validation effectué par un utilisateur natif – 18 tests réalisés sur des exemples réels, vérification complète du cycle de vie, y compris la réouverture en cas d’escalade et la gestion des échecs partiels. La formule de mise à l’échelle a été validée pour les exemples comportant 3, 6, 10 ou 15 composants.
 
-### Mission d’essaim de test en interne
+### Mission consistant à déployer un essaim de drones
 
-Pas un simple analyseur en une seule passe. La mission d’essaim de test en interne **exécute un protocole de convergence en plusieurs étapes qui fait passer un dépôt de « fonctionnel » à « prêt pour la production » en trois étapes de vérification et en livrant des fonctionnalités de manière itérative.**
+Il ne s’agit pas d’un outil d’analyse statique en une seule passe. La mission « dogfood swarm » exécute un protocole de convergence multipasse qui fait passer un dépôt de l’état « fonctionnel » à l’état « prêt pour la production », en trois étapes et grâce à des livraisons itératives de fonctionnalités.
 
 ```bash
 roleos swarm
@@ -351,20 +364,20 @@ roleos swarm
 #   Domain agents: 3-5 parallel per wave (exclusive file ownership)
 ```
 
-**Ce qui la rend différente :**
+**Qu’est-ce qui le distingue ?**
 
-- **Système de validation en trois étapes** — L’étape A corrige les bogues et les problèmes de sécurité (boucle jusqu’à 0 CRITICAL + 0 HIGH). L’étape B applique un renforcement proactif (les utilisateurs examinent les résultats). L’étape C rend le code plus convivial — messages d’erreur qui aident les utilisateurs, commentaires sur la reconnexion, états de chargement, accessibilité. Chaque étape est une approche distincte, et non la même analyse répétée.
-- **Propriété exclusive des fichiers** — chaque agent de domaine possède des fichiers spécifiques via `swarm-manifest.json`. Aucun agent ne modifie le même fichier. Pas de conflits de fusion. Pas de surcharge de coordination.
-- **Contrôles de construction** — l’analyse statique, la vérification des types et les tests doivent être réussis après chaque cycle. Le système détecte automatiquement le système de construction (Node, Rust, Python, Go) et exécute les commandes appropriées.
-- **Points de contrôle utilisateur** — Health-B et la validation des fonctionnalités nécessitent l’approbation explicite de l’utilisateur avant l’exécution. Le système présente les résultats, et l’utilisateur décide de ce qui doit être construit.
-- **Convergence itérative** — les étapes sont répétées en cycles jusqu’à ce que les conditions de sortie soient remplies ou que le nombre maximal d’itérations soit atteint. Chaque cycle réévalue tout à partir de zéro afin de détecter les régressions introduites par les corrections précédentes.
-- **Détection automatique du domaine** — `roleos swarm manifest --generate` détecte le type de dépôt (CLI, web, bureau, MCP, monorepo) et génère des affectations de domaine non superposées.
+- **Étape d’évaluation en trois phases** : la phase A corrige les bogues et les problèmes de sécurité (boucle jusqu’à ce qu’il n’y ait plus 0 CRITICAL + 0 HIGH). La phase B applique un renforcement proactif (les utilisateurs examinent les résultats). La phase C améliore le code en le rendant plus convivial : messages d’erreur qui aident les utilisateurs, commentaires sur la reconnexion, états de chargement, accessibilité. Chaque étape est une approche distincte, et non la même analyse répétée.
+- **Propriété exclusive des fichiers** : chaque agent de domaine possède des fichiers spécifiques via `swarm-manifest.json`. Aucun agent n’édite le même fichier. Pas de conflits de fusion. Pas de surcharge de coordination.
+- **Contrôles avant la compilation** : l’analyse statique + la vérification du type + les tests doivent être réussis après chaque vague. Le système détecte automatiquement le système de compilation (Node, Rust, Python, Go) et exécute les commandes appropriées.
+- **Points de contrôle utilisateur** : la phase d’évaluation Health-B et la phase de livraison des fonctionnalités nécessitent l’approbation explicite de l’utilisateur avant l’exécution. Le système présente les résultats, et l’utilisateur décide ce qui doit être compilé.
+- **Convergence itérative** : les étapes sont répétées en boucle avec les vagues jusqu’à ce que les conditions de sortie soient remplies ou qu’un nombre maximal d’itérations soit atteint. Chaque vague effectue une nouvelle vérification à partir de zéro afin de détecter les régressions introduites par les corrections précédentes.
+- **Détection automatique du domaine** : `roleos swarm manifest --generate` détecte le type de dépôt (CLI, web, bureau, MCP, monorepo) et génère des affectations de domaine non superposées.
 
-**Résultats prouvés :** claude-collaborate (2026-03-28) — 35→129 tests, 106 problèmes de validation corrigés, version v1.1.0 publiée. Protocole v2.0 avec 9 phases.
+**Résultats prouvés** : claude-collaborate (2026-03-28) — 35 → 129 tests, 106 problèmes d’évaluation corrigés, v1.1.0 publié. Protocole v2.0 avec 9 phases.
 
 ## Statut
 
-Stable et prêt à être déployé. Consultez le fichier [CHANGELOG](CHANGELOG.md) pour obtenir l’historique complet des versions et les modifications apportées à chaque version.
+Stable et prêt à être déployé. Consultez le fichier [CHANGELOG](CHANGELOG.md) pour obtenir l’historique complet des versions et les modifications apportées dans chaque version.
 
 ## Licence