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

---

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:8-17 (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.

---

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:142-145 → _cond_validation_wag teste dossier.get("wag_validated_by").
• 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 »).

---

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