oto-enterprise-os-dtp/05_deliverables_mvp/OPEN_DECISIONS_REGISTER.md

# 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).
>
> **Ajout** — 2026-08-12 · session `20260812_160204` : **D-09** (séparateur de milliers divergent
> entre surfaces de rendu monétaire publiciste / faisabilité). Arbitrage de présentation
> stakeholder ; ni un bug worker ni gaté (aucune sortie formatée n'est un artefact commité) —
> **surfacé, pas tranché**.

---

## 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`.

---

## D-09 · 🟠 Présentation : séparateur de milliers divergent entre les deux surfaces de rendu monétaire (publiciste = espace · faisabilité = virgule)

**Décision attendue** — Michel (ou le design system) doit **fixer la convention canonique** du
séparateur de milliers pour les montants **face au stakeholder**, puis harmoniser les deux
rendeurs sur ce choix. Options : (a) **espace** partout (`USD 8 560 000`), aligné sur l'exemple
public du design system ; (b) **virgule US** partout (`USD 8,560,000`), aligné sur la graphie des
`data_room` sources ; (c) convention **par audience** (espace pour le marketing public, virgule
pour le dossier technique/banquier) — statu quo assumé et documenté.

**Constat** — deux modules rendent le **même montant** différemment, tous deux face au stakeholder :
- **Publiciste** (HTML marketing public) → **espace** :
  `05_deliverables_mvp/publiciste/lib/generator.py:34-39`
  (`_fmt_usd`/`_fmt_dop` = `f"{value:,.0f}".replace(",", " ")`) ⟹ `USD 8 560 000`.
- **Faisabilité** (rapport de faisabilité + bancable) → **virgule** :
  `05_deliverables_mvp/faisabilite/generator/genlib/renderer.py:28-37` (`_money`, docstring `:29`
  « USD 250,000 ») et `05_deliverables_mvp/faisabilite/bancable/banclib/report.py:21-32`
  (`_money`/`_int` = `,.0f` / `:,`, **sans** `replace`) ⟹ `USD 8,560,000`.

**Signaux partiels (pas de règle dure)** — le design system illustre le format public avec un
**espace** (`OTO_DESIGN_SYSTEM_v1.md:89-90`, « ### Séparateur privilégié » → ex. « dès 145 000 USD »),
ce que suit le publiciste ; mais les fixtures `data_room` sources écrivent en **virgule US**
(`publiciste/fixtures/data_room/P01/20_architecture/architecture.md:11` → « USD 150,000 »), ce que
suit la faisabilité. À noter aussi : l'exemple du design system place le **montant avant la devise**
(`145 000 USD`), alors que **les deux** modules mettent la devise **en tête** (`USD …`) — donc aucun
des deux ne calque l'exemple à la lettre. Aucune directive datée ne tranche le séparateur.

**Pourquoi worker n'édite pas** — Choisir un séparateur unique impose une **convention de présentation
transverse** (arbitrage design/audience), non une correction ponctuelle ; l'imposer unilatéralement
réécrirait implicitement une règle du design system ou la graphie des sources (#6). Les deux rendeurs
sont **internes-cohérents et testés** ; aucune sortie formatée n'est un **artefact commité** (les
`out/` des deux modules ne stockent que des nombres bruts — le formatage vit dans le HTML/rapport
généré au runtime VPS · #8), donc **aucun gate n'est concerné**.

**Sources / surface** — surfacé session `20260812_160204` (balayage des spécificateurs de format
`:g`/`:,`/`:f` de production, frère de l'arc « `:g` lossy » des commits `e7cc3c4`/`5af86e3`). Les deux
`:g` de production restants sont bornés + annotés sûrs (`crm/commissions/commlib/finance.py:86`
percent 0-100 · `faisabilite/bancable/banclib/finance.py:143` unités bornées) — hors périmètre de D-09.

---

## 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).