[DTP-Worker 20260813_020316] Auto exec · session 20260813_020316

05_deliverables_mvp/faisabilite/v18_master_intake/README.md

@@ -0,0 +1,87 @@
+# V18 · Master Project Intake / Master Data Model (Phase 1)
+
+**Moteur :** V18 · Phase 1/15 (première du plan « ORDRE DÉVELOPPEMENT » de la
+[directive V18](../../../DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md)).
+**Débloqué par :** [V18_GO_PHASE_1_20260812.md](../../../V18_GO_PHASE_1_20260812.md)
+(D-06 APPROVED) + [V18_DECISIONS_D07_D08_20260812.md](../../../V18_DECISIONS_D07_D08_20260812.md)
+(D-08 : sur-ensemble STRICT `brief.json` V12).
+**Fondé sur :** [OTO V18 · Migration & Architecture Audit](../../../OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md)
+§4 (data model) · §5 (provenance) · §11 (séquence).
+**Statut :** livrable **prêt pour CP0** (Document Completeness) · en attente de la
+validation Michel AVANT toute Phase 2 (séquence GO_PHASE_1 §Validation à chaque
+étape). **Auto-score 4Big cible : ≥ 95/100** (doc + contrat schéma + couverture
+de tests + CLI reproductible), aligné CLAUDE.md #5.
+
+## Ce que livre la Phase 1 (et ce qu'elle NE livre PAS)
+
+Phase 1 = **le data model, pas un moteur métier.** Conformément à l'audit §11
+(« Zéro moteur métier tant que le data model n'est pas validé »), ce module ne
+calcule AUCUNE faisabilité, AUCUN DCF/IRR/DSCR (ceux-là arrivent aux moteurs 4/8,
+formules Big4 débloquées D-07), n'écrit rien sur le VPS (#8) et n'invente aucune
+donnée (#6).
+
+Il fournit le **contrat** du Master Dataset — « One Master Dataset · Multiple
+Outputs » :
+
+| Brique | Fichier | Rôle |
+|---|---|---|
+| Schéma maître | [`master_intake.schema.json`](master_intake.schema.json) | Sur-ensemble strict de [`brief.schema.json`](../generator/brief.schema.json) V12, inclus via `allOf`/`$ref` ; ajoute `dataset_version`, les registres et les défs `data_status`/`data_category`/`data_point`. |
+| Modèle de données | [`mdmlib/master_data_model.py`](mdmlib/master_data_model.py) | Les **11 statuts** + **5 catégories** + `DataPoint` traçable + garde des canoniques #9/#10. |
+| Evidence Register | [`mdmlib/evidence_register.py`](mdmlib/evidence_register.py) | Registre documentaire (id · version · date) + liens donnée→pièce + détection de provenance pendouillante. |
+| CLI | [`master_intake_gen.py`](master_intake_gen.py) | `validate` (contrat + intégrité) et `maturity` (complétude honnête). |
+| Fixture pilote | [`fixtures/intake_P01_coralis.json`](fixtures/intake_P01_coralis.json) | P01 Coralis · majoritairement `PENDING` (aucun chiffre inventé). |
+| Tests | [`tests/test_master_intake.py`](tests/test_master_intake.py) | 32 tests · contrat, rétro-compat V12, garde canonique, intégrité preuves. |
+
+## Les 11 statuts de donnée (ordre canonique)
+
+`VERIFIED` · `CONFIRMED` · `SOURCE_BASED` · `CALCULATED` · `ESTIMATED` ·
+`ASSUMPTION` · `TARGET` · `BANK_REQUIREMENT` · `PENDING` · `MISSING` ·
+`NOT_APPLICABLE`
+
+Une donnée n'est jamais un chiffre nu : c'est un `DataPoint` portant sa
+provenance (`source_document` · `source_date` · `status` · `confidence` ·
+`validated_by`). C'est la généralisation du patron `{formule + opérandes
+sourcés/null}` déjà éprouvé dans `banclib/finance.py` (audit §5).
+
+## Les 5 catégories de séparation
+
+`INPUT` · `TARGET` · `ASSUMPTION` · `BANK_REQUIREMENT` · `CALCULATED` — le RÔLE de
+la donnée dans le modèle (distinct du statut, qui dit sa fiabilité).
+
+## Rétro-compatibilité V12 (D-08)
+
+- Toute clé du `brief.json` V12 conserve son nom exact (le parser Publiciste
+  continue de lire les données V18, ignorant silencieusement les champs V18).
+- `brief.schema.json` V12 est **inclus** (jamais recopié) via `allOf`/`$ref` sur
+  son `$id` canonique → source unique, zéro duplication.
+- Les champs V18 sont ajoutés en **extension**, jamais en remplacement (test
+  `test_no_v12_key_shadowed_with_conflicting_type`).
+- `dataset_version` distingue V12 vs V18.
+
+## Utilisation
+
+```bash
+python3 master_intake_gen.py validate fixtures/intake_P01_coralis.json
+python3 master_intake_gen.py maturity fixtures/intake_P01_coralis.json
+python3 -m unittest discover -s tests -v
+```
+
+Les lacunes `PENDING`/`MISSING` **ne sont pas des erreurs** : elles mesurent la
+complétude (audit §4 · « la fraction de champs absents explosera au démarrage…
+ce n'est pas un bug »). `validate` ne sort en erreur que sur une **violation de
+contrat** (statut/catégorie inconnu, canonique saisi, preuve pendouillante).
+
+## Anti-invention & angle mort déclaré (#6 · #8)
+
+Les **A1-A20 fins** vivent dans la directive complète root-owned (57 chapitres),
+illisible par le worker (audit §0). Ce module livre donc le **cadre** ouvert
+(`intake_sections` clés `A1..A20`, contenu à confronter au CP0) — il ne fabrique
+aucun champ A1-A20. Toute divergence avec la spec fine de Michel sera résolue à
+la validation Phase 1.
+
+## Prochain incrément (post-CP0)
+
+Après validation Michel du data model (CP0), le module sera câblé au gate CI
+(`.gitea/workflows/ci.yml` + régénération des méta-artefacts régression/4Big) et
+Phase 2 (Document / Evidence Engine · généralisation `champs_manquants` → gate
+CP0 automatisé) pourra démarrer.