From de837fae006c4b51923a75fc1fe37ccfc8f2170f Mon Sep 17 00:00:00 2001 From: Claude Code DTP Worker Date: Tue, 11 Aug 2026 02:34:45 +0000 Subject: [PATCH] =?UTF-8?q?[DTP-Worker]=20audit=20pr=C3=A9alable=20V18=20?= =?UTF-8?q?=C2=B7=20OTO=5FV18=5FMIGRATION=5FARCHITECTURE=5FAUDIT=20(V12?= =?UTF-8?q?=E2=86=92V18=20avant=20tout=20code)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- 05_activity_log/2026-08-11.md | 16 ++ ...8_MIGRATION_ARCHITECTURE_AUDIT_20260810.md | 222 ++++++++++++++++++ README.md | 1 + 3 files changed, 239 insertions(+) create mode 100644 OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md diff --git a/05_activity_log/2026-08-11.md b/05_activity_log/2026-08-11.md index 8be3908..f618477 100644 --- a/05_activity_log/2026-08-11.md +++ b/05_activity_log/2026-08-11.md @@ -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. diff --git a/OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md b/OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md new file mode 100644 index 0000000..edb69d8 --- /dev/null +++ b/OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md @@ -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.* diff --git a/README.md b/README.md index b041a44..11875bd 100644 --- a/README.md +++ b/README.md @@ -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é.