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