oto-enterprise-os-dtp/05_deliverables_mvp/pie/manifest/README.md

PIE · Manifest de dépendances · Annexe 12 · V10.1

Directive : DIRECTIVE_PIE_PROJECT_IDENTITY_ENGINE_20260803.md (Michel · 2026-08-03) · Auto-score 4Big : 96/100 (≥95 requis · CLAUDE.md #5).

Rôle

Le Project Identity Engine (PIE) pose la faisabilité comme Project DNA · source unique de vérité (SSOT) : aucun livrable downstream (brochure, kit banquier, site, app, contrat…) ne doit être recréé à la main si la donnée existe déjà dans la faisabilité, et toute modification de la faisabilité régénère sélectivement les livrables concernés.

Ce module livre le P0 de la directive : le schéma Project Master Data + le manifest de dépendances (§88 de la directive) — le graphe faisabilité → livrables downstream versionnable, cross-vérifié.

Ce que ce worker ne fait pas (côté agents · VPS · CLAUDE.md #8) : le storage réel /opt/oto/data/pie/{code}/, la génération effective des Brand Books / logos (Flux) / PDF, et l'écriture dans ERPNext / Speckle. Ici : uniquement le contrat de dépendances, à consommer par ces agents.

Sortie (out/, commité)

Fichier	Contenu
pie_manifest.json	12 groupes Master Data · 4 règles de synchronisation · 13 livrables downstream · workflow 10 étapes · 9 marques · storage layout
MANIFEST.json	Traçabilité : sources d'ancrage + comptes dérivés + références des modules gated

Contenu (transcrit VERBATIM de la directive — zéro invention · #6)

• Project Master Data — 12 groupes (§16-29) : identité, localisation, architecture, unités, budget, marketing, BIM, finances, juridique, images, services, calendrier.
• Règles de synchronisation — 4 déclencheurs (§82-86) : prix → brochures · kit banquier · contrats · site · app · typologie → plans · rendus · fiche unité · BIM · amenities → brochures · site · slogan · brand book · livraison → calendrier · brochures · trackers chantier.
• Workflow — 10 étapes (§108-133), de la validation faisabilité à la publication.
• Marques — 9 projets (§90-102), codes ancrés à CLAUDE.md §Projets.

Downstream déjà gated par un module MVP (4/13)

Livrable	Module implémenteur
Kit banquier	faisabilite/bancable
Contrats types	legal/confotur
Page projet (site)	publiciste
Section app mobile	mobile/app_config

Les 9 autres (brand book, logos, brochures PDF, plans, rendus, fiche unité, BIM, slogan, calendrier, trackers chantier) sont marqués a_construire (P1-P4 de la directive) — aucun sur-engagement.

Invariants (schéma + 10, ré-affichés à l'exécution)

1. Schéma draft-07 de pie_manifest.json.
2. 12 groupes Master Data, clés uniques == ensemble canonique (§16-29).
3. 4 règles sync, triggers == {prix, typologie, amenities, livraison} (§82-86).
4. Intégrité référentielle : chaque downstream + trigger_group pointe du réel.
5. Registre downstream : statut cohérent (gated ⇔ module non nul).
6. Chaque module downstream non nul est un répertoire de livrable réel (FS).
7. Workflow = étapes 1..N contiguës et uniques.
8. Codes marques ⊆ CLAUDE.md §Projets (ancrage constitution).
9. annexe (12) + version_workflow (V10.1) verbatim dans la directive.
10. Storage layout hors-repo (/opt/oto/data/pie/…) — jamais le out/ du module (#8).

Usage

python3 pie_manifest_gen.py validate   # schéma + 10 invariants, sans écrire
python3 pie_manifest_gen.py build      # écrit out/pie_manifest.json + out/MANIFEST.json
python3 -m unittest discover -s tests -v

Sortie déterministe (tri stable, aucun horodatage) → re-générable byte-identique, gaté par ci/check_artifacts.sh.