# Registre des décisions ouvertes · OTO Enterprise OS DTP > **But** — Punch-list unique, sourcée, des **décisions produit qui appartiennent à Michel** > (arbitrages de périmètre / dépendances runtime hors dépôt), consolidée depuis les journaux > de session où elles ont été *surfacées* au fil de l'eau. Ces items **ne sont pas des bugs > worker** : les corriger unilatéralement serait soit une invention de périmètre (#6), soit > une réécriture d'une source d'autorité. Ce registre **regroupe et source**, il ne tranche pas. > > **Portée** — CI dépôt **verte** : tous les jobs de `gate.needs` passent · tous les modules 4Big > au seuil `100/100`, verdict `PASS`. *(Décomptes exacts — dérivés et gatés — dans le README > `## État courant` et `qa/audit_4big/out/quality_report.json` ; jamais figés ici, ils dérivent > quand un gate ou un module est ajouté.)* Aucun de ces items > ne casse un gate ; ils concernent le **périmètre produit** et l'état runtime **hors dépôt** > (VPS `153.75.250.214` · `CLAUDE.md` #8), non vérifiable/éditable depuis le worker. > > **Mise à jour** — 2026-08-11 · session `20260811_025754` (ajout du **bloc V18** D-06→D-08 : > la séquence V18 moteur est intégralement suspendue à des arbitrages Michel — cf. audit de > migration). Base 2026-08-05 · session `20260805_014119`. Chaque ligne cite sa source exacte > et la session qui l'a surfacée en premier. **Ne pas re-surfacer** ces items en doublon (#5) : > pointer ici. > > **Réalignement de citations** — 2026-08-12 · session `20260812_123144` : deux citations `Constat` > pointaient un mauvais numéro de ligne après les fixes du jour (le décompte de décision reste > inchangé). D-02 `gate.py:142-145 → :164-167` (les gardes d'affichage `percent`/`overall` des > commits `85cd625`/`1992ee6` ont décalé `_cond_validation_wag`) ; D-01 `legal/confotur/README.md:8-17 > → :32-33` (bannière de statut V18 préfixée). Sweep des autres citations = résolvent (snapshots > V18/directives datés = stables). --- ## Légende statut - 🟠 **OUVERT** — décision produit en attente de Michel (ou d'un agent hors dépôt). - 🟢 **VÉRIFIÉ-SANS-SUITE** — soupçon investigué → aucun risque réel ; consigné pour ne pas ré-ouvrir. --- ## D-01 · 🟠 PIE : `contrats` attribué à `legal/confotur` qui ne génère pas ces contrats **Décision attendue** — Soit (a) construire un vrai module `contrats` (Promesa de compraventa · Fideicomiso d'adhésion · règlement HOA), soit (b) rebasculer l'attribution à `"module": null` comme les autres downstreams sans générateur (brochures/plans/rendus/bim). **Constat** — Le registre downstream PIE mappe `contrats → legal/confotur` : - `05_deliverables_mvp/pie/manifest/pie_spec.json:24` → `{ "cle": "contrats", "libelle": "Contrats types (Promesa · Fideicomiso · HOA)", "module": "legal/confotur" }` - Écho dans l'artefact gaté : `05_deliverables_mvp/pie/manifest/out/pie_manifest.json:165-166`, `out/MANIFEST.json:24`, et la table `README.md:48`. Or `legal/confotur` produit **uniquement le DocType Frappe de la demande CONFOTUR** (Ley 158-01), pas de gabarit Promesa/Fideicomiso/HOA : - `05_deliverables_mvp/legal/confotur/README.md:32-33` (sorties = `doctype_confotur_application.json` + `MANIFEST.json`, rien d'autre). **Incohérence interne** — le même registre utilise déjà `"module": null` pour tout downstream sans générateur (`pie_spec.json:22,27,28,29,30`). `contrats` est le seul downstream attribué à un module qui ne le produit pas. **Arbitrage de périmètre, pas une correction worker.** **Sources / surface** — décrit dans la mémoire projet `directive-vs-implementation` (« PIE SIGNAL »). Non édité : cf. convention *SURFACE, don't rewrite*. **Lien V18 (2026-08-11)** — L'audit de migration **remonte cet item au rang d'arbitrage V18** : `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` §12.4 (:216) demande à Michel de trancher le **périmètre de génération juridique (Section 13)** — « CONFOTUR seul (existant) ou aussi Promesa/Fideicomiso/HOA (aucun code aujourd'hui) » — et **pointe explicitement ici**. Même décision que D-01, désormais dans le chemin critique V18. Ne pas dédoubler : cet item **est** l'arbitrage Section 13. --- ## D-02 · 🟠 Financement bancaire : condition #4 encore sur `wag_validated_by` (humain), directive V10 la remplace par un audit IA signé **Décision attendue** — L'agent **OTO Auditeur Finances** (IA autonome, **hors dépôt**) doit exister/émettre un `audit.decision == APPROVED` signé pour que la condition #4 soit implémentable. Tant qu'il n'existe pas, le module ne peut pas migrer sans casser le gate de financement. **Constat** — La directive porte une couche `## PRÉCISION` (2026-08-03) qui **supersede** explicitement la validation humaine « conseiller WAG » par une décision d'agent IA : - `DIRECTIVE_FINANCEMENT_BANCAIRE_COMPLET_20260803.md:206-210` et `:275-279` → `condition_4_ok = audit and audit['decision'] == 'APPROVED' and audit['signature_valid']`. Le module livré implémente encore l'**ancienne** condition humaine : - `05_deliverables_mvp/crm/financement_bancaire/finlib/gate.py:164-167` → `_cond_validation_wag` teste `dossier.get("wag_validated_by")` (:165). - `05_deliverables_mvp/crm/financement_bancaire/financement_spec.json:157` (label « Validation manuelle WAG confirmée par le conseiller référent »). **Pourquoi worker n'édite pas** — la nouvelle condition dépend d'un producteur d'`audit` signé qui n'existe pas dans le dépôt ; migrer le gate maintenant le rendrait toujours-faux. **Arbitrage séquencement produit + dépendance agent hors dépôt.** **Sources / surface** — mémoire `directive-vs-implementation` (« V10/173726 SIGNAL »). --- ## D-03 · 🟠 Inventaire : `otoia/capabilities/chat.py` absent au chemin, alors que `CLAUDE.md` le liste comme capability canonique **Décision attendue** — Soit recréer `chat.py`, soit retirer `chat.py` de la liste des capabilities OTOIA canoniques dans `CLAUDE.md` §Architecture cible. **Constat** - `AGENTS_EXISTING_ASSETS.md:102` le déclare présent (« conversation »). - `CLAUDE.md:28` le liste (« aec.py + knowledge.py + prompt_engine.py + chat.py »). - Filesystem : `/opt/oto/otoia/capabilities/chat.py` **absent** (ni `.py` ni `.pyc`). - Auto-incohérence : le footer du même inventaire (L128) **omet déjà** `chat.py`. **Pourquoi worker n'édite pas** — corriger l'inventaire contredirait la constitution `CLAUDE.md` ; l'inverse toucherait la constitution. **À trancher par Michel.** (Distinct du `chatbot-lead` qui, lui, existe — ne pas confondre.) **Sources / surface** — **déjà surfacé** session `20260803_133718` (`05_activity_log/2026-08-03.md:1245-1250`). --- ## D-04 · 🟠 Inventaire : `config/projets_editor.py` « API GET/POST déjà en place » — source absente (claim runtime non réfutable) **Décision attendue** — Confirmer si l'API `projets_editor` tourne effectivement (déployée ailleurs sur le VPS) ou si le claim d'inventaire est obsolète. **Constat** - `AGENTS_EXISTING_ASSETS.md:127` : `/opt/oto/config/projets_editor.py (API GET/POST déjà en place)`. - Filesystem : aucun `projets_editor*` sous `/opt/oto` ; le sibling `projets_config.json` existe. - Le claim porte sur une **API VPS live** → **non réfutable** par la seule absence de source in-`/opt/oto` (peut tourner déployée ailleurs, #8). Non touché. **Sources / surface** — **déjà surfacé** session `20260803_133718` (`05_activity_log/2026-08-03.md:1251-1253`). --- ## D-05 · 🟢 Mobile : identifiant bundle `com.otov7.app` face au renommage OTOV7 → « OTO Enterprise OS » — VÉRIFIÉ, aucun risque **Verdict** — Le renommage produit **ne menace pas** l'App Store #32. L'`app.name` passe bien à « OTO Enterprise OS », mais tout identifiant de store est **quarantiné `null · a_confirmer`, jamais fabriqué**, et **découplé** du nom d'app par conception (#6/#8) : - `05_deliverables_mvp/mobile/app_config/mobile_spec.json` (`bundleIdentifier`/`package` en `a_confirmer`, « jamais fabriquée #6/#8 »). - `out/app_config.json` → `bundleIdentifier: null`, `package: null`. - Constante historique figée `com.otov7.app` : `DIRECTIVE_MOBILE_STORES_20260803.md:15-16`. Aucun chemin de code ne peut auto-muter le bundle id. La mise à jour réelle de #32 (si besoin) est **manuelle, hors dépôt**. Consigné ici pour éviter de ré-ouvrir le soupçon (mémoire `directive-vs-implementation` « mobile SIGNAL »). --- ## D-06 · 🟠 V18 : approbation de l'audit de migration — gate d'entrée de TOUTE la séquence moteur V18 **Décision attendue** — Michel doit **approuver l'audit de migration V12→V18** (ou demander révisions). Tant qu'il n'est pas validé, **aucune** phase de développement V18 ne peut démarrer : c'est le premier maillon d'une chaîne à validation par étape. **Constat** — Le GO signal de développement **n'active pas le code direct** ; il active une **séquence à validation** dont l'audit est l'étape 1 et son approbation l'étape 2 : - `V18_GO_SIGNAL_DEVELOPMENT_20260810.md:79-84` → « n'active PAS le code direct — il active la séquence : 1. Audit V12→V18 · 2. **Validation Michel de l'audit** · 3. Phase 1 · 4. Validation Michel Phase 1 · 5. Phase 2→15 avec validation à chaque phase ». - `DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md:90-91` → INTERDICTIONS ABSOLUES : « NE PAS coder avant l'audit ». - Livrable produit et en attente : `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` §12 (:207-218), recommandation + les 4 arbitrages Michel avant Phase 1. **Pourquoi worker n'avance pas** — Coder un moteur V18 avant l'approbation violerait la directive (« NE PAS coder avant l'audit ») et la séquence GO. **Blocage de gouvernance produit, pas un bug.** **Sources / surface** — surfacé session `20260811_022753` (`05_activity_log/2026-08-11.md`, production de l'audit) ; consolidé ici session `20260811_025754`. --- ## D-07 · 🟠 V18 : formules financières (DCF · IRR/VAN · DSCR/LTV/LTC) absentes des docs lisibles — moteurs 4/8 bloqués **Décision attendue** — Michel doit **fournir / rendre lisibles** les conventions financières exactes (échéancier DCF, actualisation IRR/VAN, ratios bancaires DSCR/LTV/LTC, Cost Plan/WBS) attendues pour les moteurs **Financial (4)** et **Bankability (8)**. Sans elles, coder ces moteurs = **inventer une convention financière** — interdit par #6, risque de migration le plus grave (R1 🔴). **Constat** - `05_deliverables_mvp/faisabilite/bancable/banclib/finance.py` est un **snapshot** (coût · revenu · marge · point d'équilibre en unités) : `grep` confirme **aucun** `DSCR`/`LTV`/`LTC`, aucune actualisation multi-période. - Écart détaillé : `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` §5 (:102-114) et le point de décision §12.2 (:214) ; risque R1 « inventer des formules » gravité 🔴 (:182), mitigation = **bloquer moteur 4/8 avant lecture des formules par Michel**. - Hypothèse déclarée §5 (:112) : les formules figurent **peut-être** dans la directive complète 57 chapitres et/ou les audits deep **root-owned illisibles** par le worker (#8). **Pourquoi worker n'édite pas** — L'architecture V12 « valeur = {formule + opérandes sourcés/null} » est le bon patron à **généraliser**, mais les formules elles-mêmes ne sont **pas dérivables** du code lisible. **Dépendance d'entrée + arbitrage produit.** **Sources / surface** — audit §5/§10-R1/§12.2 ; consolidé session `20260811_025754`. --- ## D-08 · 🟠 V18 : confirmer que le Master Intake A1-A20 est un sur-ensemble STRICT du `brief.json` V12 (rétro-compat parser) **Décision attendue** — Michel doit **confirmer** que le futur Master Data Model (A1-A20) **étend** le schéma d'entrée V12 sans en casser les clés — pour éviter la création d'une **2e base** (R2 🔴) et préserver le parser Publiciste / `projets_master` (R6). **Constat** - Recommandation data model : `OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md` §4 (:86-100) — « One Master Dataset · Multiple Outputs » ; V12 le respecte déjà (bancable consomme le **même** `brief.json` que le générateur). - Point de décision §12.3 (:215) : confirmer le **sur-ensemble strict**. Séquence Phase 1 §11 (:197) = étendre `brief.schema.json` → `master_intake.schema.json`, **rétro-compat garantie**, canoniques réimposés. - Risque R2 « créer une 2e base en dupliquant `brief.json` » gravité 🔴 (:183) ; mitigation = intake = sur-ensemble strict du `brief.schema.json`. **Pourquoi worker n'édite pas** — Décision d'architecture de données ; l'étendre présuppose la liste fine A1-A20, contenue dans la directive complète **non lisible** (§0 · #8). **À valider avant Phase 1.** **Sources / surface** — audit §4/§10-R2/§11/§12.3 ; consolidé session `20260811_025754`. --- ## Rappel de discipline - Ces items sont **surfacés, pas tranchés** : les éditer côté worker violerait #6 (invention) ou réécrirait une source d'autorité (`CLAUDE.md`, une directive datée). - **Ne pas re-signaler** en doublon dans les rapports quotidiens (#5) — **pointer ce registre**. - Rien ici ne bloque la CI dépôt (verte) ; tout relève du **périmètre produit** ou du **runtime hors dépôt** (VPS · #8).