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`](../../../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`](../../faisabilite/bancable/README.md) |
| Contrats types | [`legal/confotur`](../../legal/confotur/README.md) |
| Page projet (site) | [`publiciste`](../../publiciste/README.md) |
| Section app mobile | [`mobile/app_config`](../../mobile/app_config/README.md) |

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

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