oto-enterprise-os-dtp/OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md

# 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/` | 622 (`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.*