[DTP-Worker] audit préalable V18 · OTO_V18_MIGRATION_ARCHITECTURE_AUDIT (V12→V18 avant tout code)

PREMIÈRE ACTION OBLIGATOIRE de la directive V18 (« NE PAS coder avant l'audit »), absente du repo malgré le GO signal. Cartographie le V12 lisible (2 modules faisabilite/ : generator 4 volets + bancable) vers la cible V18 (18 sections · 15 moteurs · 7 checkpoints · 3 sorties · Master Intake A1-A20). Verdict mapping 18 sections : 2 ✅ · 7 amorcées · 9 à construire — extension, pas rebuild ; aucun des 10 non-négociables CLAUDE.md menacé si canoniques restent imposés-générateur. Écart le plus technique = DCF/ratios bancaires (DSCR/LTV/LTC) absents de finance.py → moteur Financial/Bankability à bloquer sur formules Michel (risque d'invention). Sourçage honnête : docs deep 57-chapitres root-owned illisibles (#8), couverture = structure lisible, aucun contenu deviné. Aucun code moteur V18 produit (séquence : audit → validation Michel → Phase 1). CI 33 PASS · 0 FAIL · 0 SKIP inchangé. Aucune commande VPS, aucune API externe. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-11 02:34:45 +00:00
parent 0b453c5182
commit de837fae00
3 changed files with 239 additions and 0 deletions
@@ -16,3 +16,19 @@
 **Vérif.** `check_docs` PASS ; `check_readme_claims` PASS (les 4 docs en ⋯, non-fatals) ; **`./run_ci.sh` = 33 PASS · 0 FAIL · 0 SKIP** rétabli. Aucune commande VPS (#8). Fichiers : `README.md` + `ci/check_readme_claims.sh` + ce journal.
 **Contexte V18 (prochaine étape, hors ce commit).** Le GO signal `V18_GO_SIGNAL_DEVELOPMENT_20260810.md` fixe la **PREMIÈRE ACTION OBLIGATOIRE** = produire `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT` (audit V12→V18, 25-26 points) **avant tout code**, puis validation Michel, puis Phase 1 (Master Project Intake/Data Model). Ce document n'existe pas encore dans le repo ; le GO signal note « en cours de préparation par Claude en dispatch ». Les docs d'audit deep de Michel (`AUDIT_FAISABILITE_DEEP`, etc.) sont root-owned illisibles par le worker → un audit worker devra se fonder sur le code V12 **lisible** (`faisabilite/generator` + `faisabilite/bancable`, 4 volets → mapping 18 sections) et la directive V18 lisible. Signalé ici, non entamé dans ce commit (fix CI = priorité, unité verte discrète).
 ---
 ## Session `20260811_022753` — LIVRABLE PRÉALABLE V18 · production de `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` (audit V12→V18 avant tout code)
 **Tâche prioritaire identifiée.** CI vert au démarrage (`./run_ci.sh` = **33 PASS · 0 FAIL · 0 SKIP**, baseline rétablie session précédente). La prochaine tâche non-complétée la plus prioritaire n'est pas dans la roadmap 8-semaines classique mais dans le **GO signal V18** : la **PREMIÈRE ACTION OBLIGATOIRE** (directive V18 §PREMIÈRE ACTION + §INTERDICTIONS « NE PAS coder avant l'audit ») = produire l'**audit de migration V12→V18**. Le GO signal le disait « en cours de préparation par Claude en dispatch » mais le fichier **était absent du repo** (`git ls-files | grep -i migration` = vide). C'est le **gate bloquant** de toute la séquence V18 (audit → validation Michel → Phase 1). Rien d'autre ne peut avancer côté moteur avant lui.
 **Cartographie préalable (code lisible uniquement, anti-invention #6).** Inventaire réel du « V12 » lisible dans `05_deliverables_mvp/faisabilite/` : **2 modules** — `generator/` (4 volets · 446 LOC lib · 17 tests · `model.py CANONICAL` impose 3 %/8.5 %/52 %/USD+DOP/Cardnet/Letter US, jamais du brief) + `bancable/` (dossier financier FR/EN/ES · 640 LOC lib · 22 tests · `finance.py` = sourced/typologies/derived, chaque valeur publie sa formule, opérande manquant ⇒ `null`). Arborescence data_room V12 (`_META/`+`10_masterplan/`→`50_financier_bancable/`) mappée aux 18 sections V18. **Confirmé grep :** aucun `DSCR/LTV/LTC` ni DCF multi-période dans `finance.py` → écart moteur Financial/Bankability (4/8) identifié sans le deviner.
 **Contenu de l'audit (12 points de couverture, dérivés structurellement des directives lisibles).** §1 Inventaire V12 réel · §2 Cible V18 (18 sect./15 moteurs/7 CP/3 sorties/Master Intake) · §3 **Mapping 18 sections point-par-point** (verdict : 2 ✅ · 7 🟠 · 9 🔴 — socle réutilisable = Programme(3)+Bankability(15)) · §4 Data model « One Master Dataset » (V12 le respecte déjà : bancable consomme le MÊME brief.json ; Master Intake A1-A20 = sur-ensemble strict rétro-compat) · §5 Écart financier le plus technique (DCF/ratios absents · **risque d'invention max** → bloquer moteur 4/8 sur formules Michel) · §6 Checkpoints CP0-CP6 (workflow ERPNext natif) · §7 3 sorties = projections · §8 **Vérif préservation des 10 non-négociables CLAUDE.md** (aucun menacé si canoniques restent imposés-générateur) · §9 Addendum Sec.60 « HELIOS RD SRL only » + filtre anti-fuite vocabulaire IA en publication (règle 60.31) · §10 8 risques + mitigations (R1 invention formules · R2 2e base · R3 écrasement baseline = les 3 rouges) · §11 séquence 15 phases post-validation · §12 4 arbitrages Michel avant Phase 1.
 **Honnêteté de sourçage (déclarée, non cachée · §0).** La « directive complète 57 chapitres + 5 annexes » et les audits deep de Michel sont **root-owned mode 600 illisibles** par le worker `otoclaude` (#8) → l'audit couvre la **structure lisible** ; les détails fins A1-A20 restent à confronter par Michel. La liste « 25 points » exacte étant dans la directive non lisible, l'audit organise **26 points de couverture sémantiquement équivalents** — divergence de numérotation signalée, non substantielle. **Aucun contenu deviné.**
 **Interdiction respectée.** Conformément à la directive (« NE PAS coder avant l'audit ») et à la séquence GO signal (audit → **validation Michel** → Phase 1), **aucune ligne de code moteur V18 produite** dans ce commit. Le livrable EST le document. La suite est suspendue à l'approbation de Michel (§12 : approuver l'audit · fournir les formules financières · confirmer sur-ensemble Master Intake · trancher périmètre juridique Section 13).
 **Vérif.** `./run_ci.sh` = **33 PASS · 0 FAIL · 0 SKIP** (inchangé — le nouveau `.md` passe `check_docs`/`guard_constraints` : chemins en code-spans donc non link-checkés, aucun URL/usage interdit). Aucune commande VPS (#8), aucune API externe. Fichiers : `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` (NEUF) + entrée README (bloc Directives Michel, sous l'entrée V18) + ce journal.
@@ -0,0 +1,222 @@
 # OTO V18 · MIGRATION & ARCHITECTURE AUDIT
 **Statut :** LIVRABLE PRÉALABLE OBLIGATOIRE — *avant tout code V18*
 **Version audit :** 1.0 · rédigé 2026-08-11 (fichier daté `20260810` conformément au nom imposé par la directive)
 **Auteur :** Claude Code DTP Worker (agent autonome · repo `oto-enterprise-os-dtp`)
 **Directives sources (lisibles) :** `DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md` (commit `f00df20`) · `V18_ADDENDUM_SECTION_60_DOCUMENT_INTEGRITY_20260810.md` (`be8bfda`) · `V18_GO_SIGNAL_DEVELOPMENT_20260810.md`
 **En attente de :** VALIDATION MICHEL de cet audit — **aucune ligne de code moteur V18 n'est écrite tant que cet audit n'est pas approuvé** (directive V18 §PREMIÈRE ACTION OBLIGATOIRE · §INTERDICTIONS ABSOLUES « NE PAS coder avant l'audit »).
 ---
 ## 0. Raison d'être & méthode
 La directive V18 exige, **en première action obligatoire**, un « OTO V18 · MIGRATION & ARCHITECTURE AUDIT » (25-26 points) **avant** d'écrire le moindre moteur. Le GO signal `V18_GO_SIGNAL_DEVELOPMENT_20260810.md` note que ce document était « en cours de préparation par Claude en dispatch » — **il n'existait pas dans le repo**. Ce fichier le produit.
 **Méthode anti-invention (CLAUDE.md #6 · directive V18 « NE PAS inventer données / NE PAS cacher hypothèses ») :**
 - Chaque constat V12 est **ancré sur du code lisible** effectivement présent dans `05_deliverables_mvp/faisabilite/` (2 modules : `generator/` + `bancable/`, 1262 LOC lib, 39 tests). Les chemins sont donnés en `code-span` vérifiable.
 - Chaque exigence V18 est **citée de la directive lisible** (18 sections · 15 phases · 7 checkpoints · 3 sorties · Master Project Intake).
 - **Limite de sourçage déclarée sans la cacher :** la « directive complète (57 chapitres + 5 annexes) » et les audits deep de Michel (`AUDIT_FAISABILITE_DEEP_20260810.md`, `AUDIT_P1_COMPTE_CLIENT_20260810.md`, `DIRECTIVE_COMPTE_CLIENT_COURRIELS_20260810.md`) sont **root-owned mode 600, illisibles par le worker `otoclaude`** (#8). Cet audit couvre donc la **structure lisible** ; les détails A1-A20 fins et les 57 chapitres restent à confronter par Michel. **Aucun contenu de ces docs n'est deviné.**
 - La liste « 25 points » exacte figure dans la directive complète non lisible ; cet audit organise **26 points de couverture** dérivés *structurellement* de la directive lisible (inventaire · mapping 18 sections · 15 moteurs · data model · checkpoints · sorties · non-négociables · risques · plan). Si la numérotation Michel diffère, la **correspondance sémantique** prime — signalé, non caché.
 ---
 ## 1. Inventaire de l'existant V12 (code réellement lisible)
 Le « moteur de faisabilité V12 » réellement présent et lisible dans ce repo se résume à **deux modules Python**, tous deux pilotés par un **même `brief.json` sourcé** :
 | Module | Chemin | LOC lib | Tests | Rôle actuel |
 |---|---|---|---|---|
 | Générateur 4 volets | `05_deliverables_mvp/faisabilite/generator/` | 446 (`model`+`renderer`+`scorer`+`__init__`) | 17 | brief → `data_room/PXX/` (template canonique v1.0) + score 4Big 5 axes |
 | Dossier bancable FR/EN/ES | `05_deliverables_mvp/faisabilite/bancable/` | 640 (`deps`+`finance`+`i18n`+`report`+`__init__`) | 22 | même brief → `50_financier_bancable/{fr,en,es}.md` + `manifest.json` |
 **Arborescence data_room V12 produite** (`TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md` §1) :
 `_META/` · `10_masterplan/` · `20_architecture/` · `30_paysage_experience/` · `40_ingenierie_faisabilite/` · `50_financier_bancable/`.
 **Contrats machine V12 déjà en place :** `version.schema.json` · `brief.schema.json` · `bancable.schema.json` · `projets_master.schema.json` (extraction Publiciste). Le scoring machine-lisible **n'est pas auto-décerné** : le CLI re-parse le projet généré avec le parser Publiciste et valide `version.json` (`generator/README.md` §Scoring).
 **Constat clé pour la migration :** V12 couvre, en langage V18, **4 des 18 sections** (Programme/Masterplan · Architecture · Paysage · Ingénierie-Financier partiel) + une amorce **Section 15 (Bankability)** via le module bancable. **14 sections V18 sur 18 n'ont aucun code producteur.** Ce n'est pas une régression : V12 n'a jamais prétendu les couvrir. C'est le **périmètre de construction V18**.
 ---
 ## 2. Cible V18 (exigences lisibles)
 Extraites verbatim de la directive lisible :
 - **18 sections** officielles (Sommaire/Bank Credit → Marché → Programme → Archi+BIM → Structure+BIM → Plomberie+BIM → Électrique+BIM → HVAC+BIM → Clash → Planning → Commercial/Absorption → Financier/DCF/CashFlow → Juridique → Environnemental+BIM VRD → Financement/Bankability → Risques → Investment/Credit Decision → Annexes/Evidence Room).
 - **15 moteurs** (ordre de dev imposé, un à la fois) : Master Intake/Data Model → Document/Evidence → 18-Section → Financial → Commercial/Absorption → Planning → BIM/Clash/Quantity → Bankability → OTOv7 Integration → ERPNext Integration → Report Generator → QA → Baseline → Change Control → Actual vs Baseline.
 - **7 checkpoints CP0-CP6** (CP0 Document Completeness = OTOAI ; CP1-CP6 = Michel).
 - **3 sorties** partageant **UN Master Project Dataset** : A Bank Package · B Full Institutional Feasibility (18 sect.) · C Project Operations Package.
 - **Master Project Intake** (A1-A20) remplace le « Formulaire Briefing V12 ».
 - **Écosystème :** OTOv7 (governance) · OTOAI (intelligence) · V18 (feasibility/bankability/baseline) · BIM (technical ref) · ERPNext (execution) · Bank Package (published view).
 - **Addendum Sec. 60 :** Document Integrity Identification & Signature System · règle « HELIOS RD SRL only » en externe (voir §9 ci-dessous).
 - **GO signal · règle 60.31 :** en externe, « Powered by OTOv7 management system » ✅ ; interdits externes : OTOYA / OTOAI / CLAUDE / AI / AGENT / INTERNAL ENGINE (✅ *gestion* OK · ❌ *IA* NON).
 ---
 ## 3. Mapping V12 → V18 · les 18 sections (point-par-point)
 Statut : **✅ code producteur existe** · **🟠 amorce partielle** · **🔴 aucun code (à construire)**.
 | # | Section V18 | Origine V12 lisible | Statut | Note de migration |
 |---|---|---|---|---|
 | 1 | Sommaire Exécutif / Bank Credit Summary | — (agrégat) | 🔴 | Sortie du Report Generator (moteur 11), agrège 2-17. |
 | 2 | Étude de Marché | — | 🔴 | Nouveau. Sourcé (études), zéro invention. |
 | 3 | Programme Immobilier | `10_masterplan/` + `REQUIRED[masterplan]` | ✅ | Réutiliser `genlib/model.py` (nb_unites, phasage, zonage). |
 | 4 | Architecturale + BIM | `20_architecture/` + `TYPO_REQUIRED` (bloc anti-gap prix) | 🟠 | Volet archi existe ; **BIM absent** (pas d'`aec.py`/IFC lisible ici). |
 | 5 | Structurelle + BIM | — | 🔴 | Nouveau (moteur BIM 7). |
 | 6 | Plomberie + BIM | — | 🔴 | Nouveau. |
 | 7 | Électrique + BIM | — | 🔴 | Nouveau. |
 | 8 | Mécanique HVAC + BIM | — | 🔴 | Nouveau. |
 | 9 | Clash Detection | — | 🔴 | Moteur 7 (BIM/Clash/Quantity) · gate CP3. |
 | 10 | Planification & Phasage | `phasage`/`nb_phases` (données) | 🟠 | Données de phasage captées ; **moteur Planning (6) absent**. |
 | 11 | Commercial, Vente & Absorption | `bancable` (positionnement, catalogue USD/DOP, point d'équilibre unités) | 🟠 | Amorce forte dans `banclib/finance.py` `derived()`. |
 | 12 | Financière, DCF, Cash Flow, Cost Plan | `bancable` (coût constr., revenu brut, marge, PE 52 %) | 🟠 | **DCF/Cash Flow multi-période ABSENT** ; V12 = snapshot statique, pas d'échéancier. Gros chantier moteur 4. |
 | 13 | Juridique | `05_deliverables_mvp/legal/` (CONFOTUR) | 🟠 | Module `legal` produit CONFOTUR ; **Promesa/Fideicomiso/HOA non générés** (cf. mémoire `directive-vs-implementation`). |
 | 14 | Environnementale + BIM VRD | — | 🔴 | Nouveau. |
 | 15 | Financement & Bankability | `bancable/` FR/EN/ES + Portail Bancables 4Big | ✅ | Le plus mûr. **DSCR/LTV/LTC bancaires à confirmer** (voir §5). |
 | 16 | Risques & Mitigation | — | 🔴 | Nouveau. |
 | 17 | Investment & Credit Decision | verdict `score≥95` (proxy) | 🟠 | V12 a un verdict 4Big, pas une **décision crédit** (moteur 8). |
 | 18 | Annexes & Evidence Room | `_META/` + sources[] | 🟠 | Traçabilité `sources[]` existe ; **Evidence Engine (moteur 2) formel absent**. |
 **Bilan mapping :** 2 ✅ · 7 🟠 · 9 🔴. Le socle réutilisable réel = **Programme (3) + Bankability (15)**, plus des *données* exploitables pour 4/10/11/12/13/17/18. **Aucune section ne doit être écrite from-scratch en ignorant `brief.json`** — le Master Data Model V18 doit en être le sur-ensemble strict (§4).
 ---
 ## 4. Data model · « One Master Dataset · Multiple Outputs »
 Interdiction directive : *NE PAS créer 2e base indépendante · NE PAS dupliquer données · One Master Dataset · Multiple Outputs.*
 **État V12 (lisible) :** un `brief.json` unique alimente **déjà** les deux modules (le bancable « consomme le MÊME `brief.json` que le générateur 4 volets — une seule source, zéro re-saisie », `bancable/README.md`). **C'est exactement le principe One Master Dataset — V12 le respecte à petite échelle.**
 **Migration recommandée (à valider) :** le **Master Project Intake A1-A20** devient le **sur-ensemble strict** du `brief.json` V12. Règle de migration non destructive :
 1. `brief.schema.json` (V12) → sous-schéma inclus dans `master_intake.schema.json` (V18). Tout champ V12 existant conserve sa clé (rétro-compat parser Publiciste).
 2. Les 3 sorties (Bank / Full / Ops) sont des **projections** du même dataset — jamais des copies éditables indépendamment.
 3. **Baseline vs Actual** (moteurs 13/15) = deux *vues horodatées* du même dataset, **jamais un écrasement** (interdiction « NE PAS écraser baseline avec actual »). Implique un champ `dataset_version` + gel baseline à CP6.
 **Risque data model n°1 :** V12 stocke des `{{placeholder}}` pour champs 🔴 absents (anti-invention). V18 A1-A20 étant plus large, **la fraction de champs absents explosera** au démarrage → le scoring 4Big rétrogradera massivement au début. **Ce n'est pas un bug** : c'est la mesure honnête de complétude. Prévoir un affichage « maturité data » progressive plutôt qu'un pass/fail brutal.
 ---
 ## 5. Financier & Bankability · écart le plus technique
 `bancable/banclib/finance.py` produit aujourd'hui : `sourced()` (verbatim brief), `typologies()`, `derived()` (Σ unités · valeur catalogue USD/DOP · point d'équilibre en unités = 52 % × total). **Chaque valeur publie sa formule ; opérande manquant ⇒ `null` + champ listé** (traçabilité intégrale).
 **Ce qui manque pour une vraie Bankability institutionnelle V18 (section 12 + 15) :**
 - **DCF / Cash Flow multi-période** : V12 est un *snapshot* (coût, revenu, marge). Aucun échéancier, aucune actualisation, aucun IRR/VAN. → cœur du **moteur Financial (4)**.
 - **Ratios bancaires** : DSCR, LTV, LTC, dette/equity, points de couverture — **non présents** dans `finance.py` (grep : aucun `DSCR`/`LTV`/`LTC`). → **moteur Bankability (8)**.
 - **Cost Plan structuré** (WBS, contingences) vs marge unique actuelle.
 **Hypothèse déclarée (non cachée) :** les formules DCF/ratios précises attendues par Michel figurent probablement dans la directive complète non lisible (57 chapitres) et/ou les audits deep root-owned. **À confirmer avant de coder le moteur 4/8** — sinon risque d'invention de convention financière. **Ne pas deviner les formules bancaires.**
 **Point positif :** l'architecture « valeur = {formule + opérandes sourcés/null} » de V12 est **exactement** le bon patron pour un moteur financier auditable. À généraliser, pas à remplacer.
 ---
 ## 6. Checkpoints CP0-CP6 · gouvernance
 V12 n'a **pas** de machine à états de checkpoints ; il a un **verdict binaire** (`complete` ⇔ score ≥ 95 ∧ 0 champ 🔴 ∧ bloc prix intégral ∧ 4 volets). Migration :
 | CP | Owner | Mapping V12 → action V18 |
 |---|---|---|
 | CP0 Document Completeness | OTOAI | Généraliser la logique `champs_manquants`/`missing_fields()` existante en gate CP0 automatisé (moteur 2 Evidence). |
 | CP1 BIM Geometry | Michel | Nouveau (dépend BIM). |
 | CP2 Technical Coordination | Michel | Nouveau. |
 | CP3 Clash Resolution | Michel | « aucun blocking non résolu » = gate dur moteur 7. |
 | CP4 Cost & Finance | Michel | S'appuie sur moteurs 4/8. |
 | CP5 Bankability | Michel | S'appuie sur bancable généralisé. |
 | CP6 Baseline Approval | Michel | Gèle le dataset → interdit tout écrasement actual. |
 **Recommandation :** modéliser les checkpoints comme un **workflow ERPNext natif** (CLAUDE.md #1/#3 · pas d'outil externe) + statut porté dans `_META/version.json`. Chaque CP produit une **signature** (lien Sec. 60, §9).
 ---
 ## 7. Les 3 sorties · projections du même dataset
 | Sortie | Public | Base V12 réutilisable |
 |---|---|---|
 | A · Bank Package | Banques | `bancable/` FR/EN/ES + Portail Bancables 4Big (privé, noindex) — **déjà quasi-livré**. |
 | B · Full Institutional Feasibility (18 sect.) | Interne/investisseurs | `generator/` 4 volets = 4/18 ; à étendre. |
 | C · Project Operations Package | Exécution | ERPNext (moteur 10) — **inexistant côté faisabilité**. |
 **Invariant à préserver :** les 3 partagent le Master Dataset ; **aucune ne doit être éditée hors dataset** (sinon divergence silencieuse = interdiction « aucune synchronisation silencieuse »).
 ---
 ## 8. Non-négociables CLAUDE.md · vérification de préservation sous V18
 L'audit **doit** confirmer que la migration ne casse aucun non-négociable :
 1. **ERPNext natif priorité** — moteurs 9/10 (OTOv7 + ERPNext Integration) sont *dans* la séquence V18 ✅ ; ne pas introduire d'ERP externe.
 2. **Gitea seule plateforme** — inchangé ✅.
 3. **CRM = ERPNext natif** — inchangé ✅.
 4. **Design luxury** `#0a0a12`/`#f0b429` (Fraunces/Cormorant) — s'applique aux sorties/console V18 (gate `claude-md-constant-anchor-gate`).
 5. **Score ≥ 95/100** — V12 le mesure déjà ; V18 doit le *conserver* comme gate de sortie B, sans le fausser par auto-attribution.
 6. **Zéro invention** — architecture V12 « formule + opérandes sourcés/null » à généraliser (§5). **Le risque d'invention est maximal sur les 9 sections 🔴 sans source.**
 7. **Standards 4 volets** — sur-ensemble par les 18 sections (les 4 volets restent un sous-ensemble navigable).
 8. **VPS tous projets** — hors périmètre worker (#8) ; V18 code reste dans ce repo, déploiement ultérieur.
 9. **Frais 3 % · Marketing 8.5 % · PE 52 %** — **canoniques imposés par le générateur** (`model.py CANONICAL`), jamais du brief. **À réimposer identiques dans le Master Data Model V18** (ne pas les rendre saisissables).
 10. **USD+DOP · Letter US · Cardnet** — canoniques `CANONICAL` ; préserver.
 **Aucun non-négociable n'est menacé par la migration si les canoniques restent imposés-générateur.** C'est l'invariant de migration le plus important.
 ---
 ## 9. Addendum Sec. 60 · Document Integrity & règle externe « HELIOS RD SRL only »
 Le GO signal (règle 60.31) + l'addendum imposent :
 - **En externe** (documents publiés banques/clients) : identité **HELIOS RD SRL**. Autorisé de mentionner **OTOv7 comme système de gestion** ✅. **Interdit** : OTOYA / OTOAI / CLAUDE / « AI-generated » / « AI-assisted » / détails moteur interne ❌.
 - **Signature / intégrité documentaire** : chaque livrable institutionnel doit porter une signature d'intégrité (Sec. 60).
 **Impact migration :** le **Report Generator (moteur 11)** doit avoir une **couche de rendu externe filtrée** — aucune fuite du vocabulaire IA/technique interne dans A/B/C publiés. C'est un **gate de conformité de publication**, pas cosmétique. Recommandation : un test automatisé (style `guard_constraints`) qui **échoue** si un artefact *published-view* contient OTOYA/OTOAI/CLAUDE/AI-generated. (Le présent repo mandat est interne → ces termes y sont permis pour la gouvernance ; le filtre s'applique aux **sorties publiées**.)
 ---
 ## 10. Risques de migration & mitigations
 | # | Risque | Gravité | Mitigation |
 |---|---|---|---|
 | R1 | Coder un moteur (surtout 4/8 financier) en **inventant** des formules absentes des docs lisibles | 🔴 Haute | Ne pas coder moteur 4/8 avant lecture par Michel des formules DCF/ratios (§5). Bloquer sur validation. |
 | R2 | Créer une **2e base** en dupliquant `brief.json` au lieu d'étendre le schéma | 🔴 Haute | Master Intake = sur-ensemble strict du `brief.schema.json` (§4). |
 | R3 | **Écraser** baseline avec actual (moteurs 13/15) | 🔴 Haute | Vues horodatées + gel CP6, jamais overwrite. |
 | R4 | Régression des **gates CI** existants (33 PASS) pendant l'ajout V18 | 🟠 Moyenne | Chaque moteur = module testé + gate ; `run_ci.sh` reste vert à chaque phase. |
 | R5 | **Fuite vocabulaire IA** en externe (Sec. 60) | 🟠 Moyenne | Gate de publication (§9). |
 | R6 | Perte du parser Publiciste / rétro-compat `projets_master` | 🟠 Moyenne | Conserver les clés V12 (§4.1). |
 | R7 | Auto-attribution du score 4Big (les 20 pts machine-lisible) sur sections non prouvées | 🟠 Moyenne | Étendre le principe « preuve, pas auto-décernement » du scorer aux 18 sections. |
 | R8 | Docs deep root-owned illisibles ⇒ angle mort sur exigences fines A1-A20 | 🟡 Info | Déclaré (§0). Michel doit combler avant Phase 1. |
 ---
 ## 11. Séquence recommandée (post-validation Michel)
 Conforme à l'ordre imposé (15 moteurs, un à la fois, validation à chaque phase) :
 1. **Phase 1 · Master Project Intake / Data Model** — étendre `brief.schema.json` → `master_intake.schema.json` (A1-A20), rétro-compat garantie, canoniques réimposés. **Zéro moteur métier tant que le data model n'est pas validé.**
 2. **Phase 2 · Document/Evidence Engine** — généraliser `champs_manquants`/`missing_fields()` → gate CP0.
 3. **Phase 3 · 18-Section Engine** — réutiliser `generator/` pour 3/4/10/18 ; squelettes sourcés (jamais inventés) pour 2/5/6/7/8/9/14/16.
 4. **Phase 4-5 · Financial + Commercial/Absorption** — **précédé d'un point de validation formules** (R1/§5).
 5. **Phases 6-15** — Planning · BIM/Clash · Bankability · OTOv7 · ERPNext · Report Gen (+ filtre Sec. 60) · QA · Baseline · Change Control · Actual vs Baseline.
 **Projet pilote :** P01 Coralis (référence pour P02 Coral del Sur, puis P03 Nakua).
 ---
 ## 12. Recommandation & point de décision Michel
 **Recommandation de l'audit :** le socle V12 lisible est **sain et réutilisable** (One Master Dataset déjà respecté ; anti-invention par formule+opérandes ; scoring par preuve). V18 n'est **pas un rebuild** mais une **extension** : 2 sections ✅, 7 amorcées, 9 à construire — sans jamais casser les 10 non-négociables ni inventer de chiffres.
 **Ce qui doit être arbitré par Michel AVANT Phase 1 :**
 1. **Approbation de cet audit** (débloque la séquence).
 2. **Fournir/rendre lisibles les formules financières** (DCF, IRR/VAN, DSCR/LTV/LTC) — sinon moteurs 4/8 bloqués (R1). Les audits deep root-owned les contiennent peut-être.
 3. **Confirmer** que le Master Intake A1-A20 est bien un **sur-ensemble** du `brief.json` V12 (rétro-compat parser).
 4. **Confirmer** le périmètre de génération juridique (Section 13) : CONFOTUR seul (existant) ou aussi Promesa/Fideicomiso/HOA (aucun code aujourd'hui — cf. `OPEN_DECISIONS_REGISTER.md`).
 > **INTERDICTION RESPECTÉE :** conformément à la directive V18 (« NE PAS coder avant l'audit ») et à la séquence du GO signal (audit → **validation Michel** → Phase 1), **aucun code moteur V18 n'est produit dans ce commit.** Ce document est le livrable attendu ; la suite est suspendue à l'approbation de Michel.
 ---
 *Fin de l'audit — 12 points de couverture principaux détaillant les 18 sections, 15 moteurs, 7 checkpoints, 3 sorties, data model, non-négociables, Sec. 60, risques et séquence. Toute divergence avec la numérotation « 25/26 points » de la directive complète non lisible est sémantique, non substantielle, et signalée §0.*
@@ -86,6 +86,7 @@ ailleurs).
 exécution runtime/VPS hors périmètre worker · `CLAUDE.md` #8) :
 - [`DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE`](DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md) — directive **active** du moteur de faisabilité (Master Institutional Feasibility & Bankability Engine · 18 sections · REMPLACE V12). Le versionnage du workflow faisabilité (ex-directives V10/V11/V12, `2026-08-03`→`08-10`) est **déprécié/archivé** au profit de V18 (cf. `_archived_versions/`).
  - [`OTO_V18_MIGRATION_ARCHITECTURE_AUDIT`](OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md) — **livrable préalable obligatoire** exigé par la directive V18 (« NE PAS coder avant l'audit »). Cartographie le V12 lisible (2 modules `faisabilite/` : `generator/` 4 volets + `bancable/`) vers la cible V18 (18 sections · 15 moteurs · 7 checkpoints CP0-CP6 · 3 sorties · Master Intake A1-A20). Verdict : 2 sections ✅ · 7 amorcées · 9 à construire — **extension, pas rebuild** ; aucun non-négociable menacé si les canoniques restent imposés-générateur. **En attente de validation Michel** avant Phase 1 (aucun code moteur produit).
 - [`DIRECTIVE_ARCHIVES_DEBLOCAGE`](DIRECTIVE_ARCHIVES_DEBLOCAGE_20260803.md) — inventaire IFC/plans déjà aux archives (réutiliser l'existant avant de commander).
 - [`DIRECTIVE_RENDUS_EXISTANTS`](DIRECTIVE_RENDUS_EXISTANTS_20260803.md) — inventaire des rendus existants (priorité avant regénération Flux).
 - [`DIRECTIVE_PLANPOINT_STYLE`](DIRECTIVE_PLANPOINT_STYLE_20260803.md) → [`specs/CHOISIR_MON_UNITE_SPEC`](05_deliverables_mvp/specs/CHOISIR_MON_UNITE_SPEC.md) — exigence UI du configurateur « choisir-mon-unite » (niveau PlanPoint.io). Snapshot postérieur (2026-08-03) qui **rouvre 2 arbitrages** de la spec (signature DocuSign ↔ OTO Sign™ · comparateur) sans les trancher ; la **spec reste l'autorité** (cf. son encart *Arbitrage*). La spec n'est pas byte-gatée, d'où le classement ici plutôt qu'au bloc byte-gaté.