Claude Code DTP Worker
a39dc28f59
Complétude≠exactitude (même classe que le fix CRM/financement précédent). Diff
05_deliverables_mvp/*/ vs tables des 13 fiches : demo/scenarios est un livrable
produit (générateur demo_scenario_gen.py · 39 tests · out/{run_sheet,MANIFEST} ·
README déjà gaté · job CI demo-scenario-tests) mais recensé dans AUCUNE fiche
(grep demo|scenario sur 03_agents/*/AGENT.md = 0). Livrable transverse SANS agent
propre : README « Sprint 7 (CRM+Faisabilité) » + roadmap L68 l'assignent aux DEUX.
- Fiche CRM : sous-section « Livrable transverse · Sprint 7 » + table 1-ligne
AUTO-GATÉE (label scenarios/ · chemin demo/scenarios ∈ plan.suites · cellule
Tests recomputée depuis regression_plan.json par le row_re générique de
check_readme_claims — la ligne HÉRITE du gate, 0 gate ajouté #5). Framée honnête :
PAS un livrable CRM propre mais méta-générateur qui COMPOSE l'amont, source
distincte du trio + du financement (laissés INTACTS).
- Fiche Faisabilité : cross-réf en prose (0 chiffre redupliqué #5) vers la fiche CRM
+ README module ; bancable alimente S-P07-BANQUIER.
Auto-gates franchis (3 axes) : Tests 39==source(39) · verbes build|validate==
subparsers · citation roadmap l.68==roadmap · job CI==ci.yml · check_docs cross-refs OK.
2 fichiers touchés + log. 0 chiffre inventé (#6) · 0 production éditée · 0 gate ajouté
(#5) · 0 commande VPS (#8). CI 33 PASS · 0 FAIL · 0 SKIP.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
148 lines
8.9 KiB
Markdown
148 lines
8.9 KiB
Markdown
# 🏗️ Faisabilité Agent · Génération + Maintenance faisabilités canoniques
|
|
|
|
**Rôle** : Cet agent OTOIA génère et maintient à jour toutes les faisabilités de projets sur le **modèle canonique le plus récent**. Élimine les faisabilités obsolètes ou hétérogènes.
|
|
|
|
## Mission
|
|
1. **Générer** les faisabilités 4 volets pour chaque projet (Masterplan · Architecture · Paysage-Expérience · Ingénierie-Faisabilité)
|
|
2. **Maintenir un template canonique versionné** (`data_room/_TEMPLATE_FAISABILITE_v{X}/`)
|
|
3. **Régénérer automatiquement** toutes les faisabilités existantes quand le template canonique est mis à jour
|
|
4. **Propager les workflow updates** à toutes les faisabilités actives
|
|
5. **Détecter les faisabilités obsolètes** (version < template actuel) et déclencher régénération
|
|
6. **Score qualité 4Big ≥ 95/100** obligatoire
|
|
|
|
## Livrables Faisabilité réellement produits (`05_deliverables_mvp/faisabilite/`)
|
|
|
|
Générateurs déterministes **in-repo** (périmètre worker · `CLAUDE.md` #8), gatés en CI —
|
|
les composants runtime OTOIA/VPS listés plus bas (`otoia/capabilities/…`, systemd) restent
|
|
**hors périmètre worker** ; ces modules en sont la contrepartie commitée et testable.
|
|
|
|
| Module | Sprint | Rôle | Entrée CLI | Job CI | Tests |
|
|
|---|---|---|---|---|---|
|
|
| [`TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md`](../../05_deliverables_mvp/faisabilite/TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md) | 1 (roadmap L41-46) | **Template canonique v1.0** — contrat des 4 volets + champs obligatoires (§Livrable S1 ci-dessous) | — (doc contrat) | `check-docs` | — |
|
|
| [`generator/`](../../05_deliverables_mvp/faisabilite/generator/README.md) | 2 (roadmap L44) | **Générateur 4 volets** : `brief.json` → `data_room/PXX/` (template v1.0), round-trip via le parser Publiciste | `faisabilite_gen.py score\|scaffold\|generate\|batch` | `faisabilite-gen-tests` | 16 |
|
|
| [`bancable/`](../../05_deliverables_mvp/faisabilite/bancable/README.md) | 3 (roadmap L46) | **Dossier bancable trilingue** : `brief.json` → `50_financier_bancable/{fr,en,es}.md` + manifest, figures sourcées verbatim + agrégats recalculés | `bancable_gen.py build\|validate` | `bancable-tests` | 22 |
|
|
|
|
**Anti-invention (#6)** : `generator` et `bancable` ne **fabriquent aucun chiffre** — les figures
|
|
sont citées verbatim depuis le `brief.json` du projet et les agrégats sont recalculés de façon
|
|
traçable (formule recoupée en test). Aucune faisabilité concrète PXX n'est commitée ici : seuls
|
|
le générateur, son contrat et ses fixtures d'entrée le sont (le rendu réel des 9 projets
|
|
s'exécute côté OTOIA/VPS · #8).
|
|
|
|
**Livrable transverse Sprint 7 (co-porté avec CRM).** Le module
|
|
[`demo/scenarios`](../../05_deliverables_mvp/demo/scenarios/README.md) — méta-générateur
|
|
qui **compose** en run-sheet de pitch les livrables amont, dont `bancable` côté
|
|
faisabilité (scénario `S-P07-BANQUIER`) — matérialise la roadmap Sprint 7 (« CRM +
|
|
Faisabilité : scénarios démo P07 banquier / P05 client », L68). Sa ligne recensée et
|
|
**auto-gatée** (cellule Tests) vit dans la fiche CRM
|
|
([`03_agents/crm/AGENT.md`](../crm/AGENT.md), §« Livrable transverse · Sprint 7 ») —
|
|
source unique, non redupliquée ici (#5).
|
|
|
|
## Faisabilité = SSOT · Project Identity Engine (Annexe 12 · V10.1)
|
|
|
|
Le [`DIRECTIVE_PIE_PROJECT_IDENTITY_ENGINE_20260803.md`](../../DIRECTIVE_PIE_PROJECT_IDENTITY_ENGINE_20260803.md)
|
|
(Michel · 2026-08-03) désigne **cet agent** comme la **source unique de vérité (SSOT)** de
|
|
toute la stack : la faisabilité est le *Project DNA*, et aucun livrable downstream (brochure,
|
|
kit banquier, contrat, page projet, section app…) ne doit être recréé à la main si la donnée
|
|
existe déjà ici. Le module commité [`pie/manifest`](../../05_deliverables_mvp/pie/manifest/README.md)
|
|
livre le **P0** de la directive — le **schéma Project Master Data** + le **manifest de
|
|
dépendances** `faisabilité → livrables downstream`, versionnable et cross-vérifié. Ainsi, toute
|
|
modification de faisabilité déclenche la **régénération sélective** des seuls livrables concernés
|
|
(règles de synchronisation portées par le manifest). Les comptes exacts (groupes Master Data,
|
|
règles de synchronisation, registre downstream) **font foi dans le README du module** — cet
|
|
agent en est la source, pas la copie.
|
|
|
|
## Sources canoniques
|
|
> **Chemins VPS runtime — hors périmètre worker (#8), non commités in-repo** (préfixe
|
|
> absolu `/opt/oto/…`, placeholder de version `{X}`). La **contrepartie commitée,
|
|
> testée et gatée** du template canonique est
|
|
> [`TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md`](../../05_deliverables_mvp/faisabilite/TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md)
|
|
> (table §Livrables ci-dessus) — **la référence de vérité pour le worker** ; les
|
|
> chemins ci-dessous décrivent l'emplacement runtime OTOIA/VPS où l'agent exécute.
|
|
- `/opt/oto/otoia/capabilities/knowledge/faisabilite_4_volets_standard.md` (STANDARD OFFICIEL)
|
|
- `/opt/oto/data_room/_TEMPLATE_FAISABILITE_v{X}/` (template versionné)
|
|
- `/opt/oto/data_room/PXX/00_brief/` (données projet)
|
|
|
|
## Structure faisabilité (4 volets standard)
|
|
```
|
|
data_room/PXX/
|
|
├── _META/
|
|
│ └── version.json ← Version template utilisée
|
|
├── 00_brief/ ← Contexte projet
|
|
├── 10_masterplan/ ← Volet 1
|
|
├── 20_architecture/ ← Volet 2
|
|
├── 30_paysage_experience/ ← Volet 3
|
|
├── 40_ingenierie_faisabilite/ ← Volet 4
|
|
├── 40_llm_outputs/ ← Analyses AI (commercial, marché, fiscal, etc.)
|
|
├── 50_financier_bancable/ ← One-pager + rapports FR/EN/ES
|
|
└── 60_photos_site/ ← Rendus
|
|
```
|
|
|
|
## Règles absolues
|
|
- ❌ Zéro faisabilité version < template canonique en production
|
|
- ❌ Zéro faisabilité manuellement éditée sans mise à jour du template
|
|
- ✅ Chaque faisabilité stocke sa version template dans `_META/version.json`
|
|
- ✅ Régénération = 100% automatique via OTOIA, jamais manuel
|
|
|
|
## Workflow versioning
|
|
|
|
### Trigger : Template canonique mis à jour
|
|
1. **Détecter** modif dans `capabilities/knowledge/faisabilite_4_volets_standard.md`
|
|
2. **Bump version** template (v1.0 → v1.1)
|
|
3. **Lister** toutes les faisabilités en production (data_room/PXX/)
|
|
4. **Pour chaque projet** :
|
|
a. Lire brief + données existantes du projet
|
|
b. Régénérer 4 volets avec nouveau template
|
|
c. Régénérer 40_llm_outputs (commercial · marché · directeur · etc.)
|
|
d. Régénérer 50_financier_bancable (one-pager + rapports FR/EN/ES)
|
|
e. Update `_META/version.json`
|
|
f. Archiver ancienne version dans `_ARCHIVES/PXX_v{N}_YYYYMMDD/`
|
|
g. Score qualité 4Big ≥ 95/100 obligatoire
|
|
5. **Notifier Publiciste Agent** → régen site public
|
|
6. **Log + WhatsApp Michel** notification
|
|
|
|
### Trigger : Nouveau projet créé
|
|
1. Créer structure `data_room/PXX/` avec template dernière version
|
|
2. Générer les 4 volets (Masterplan · Architecture · Paysage · Ingénierie)
|
|
3. Générer analyses AI (commercial, marché, fiscal, RH, juridique, etc.)
|
|
4. Générer rapports bancables FR/EN/ES + one-pager
|
|
5. Score qualité 4Big ≥ 95/100 avant marquer projet comme "faisabilité complète"
|
|
|
|
## Gap actuel identifié (2026-07-29)
|
|
|
|
**Constat audit :**
|
|
- ✅ P01, P08, P09 : prix documentés dans commercial.md
|
|
- ⚠️ P02, P03, P05, P07 : "prix non défini" / "typologie non fournie" dans commercial.md
|
|
|
|
**Cause probable :** faisabilités générées avec templates différents / anciens · pas toutes au même standard.
|
|
|
|
**Action correctrice (priorité)** :
|
|
1. Fixer le template canonique v1.0 avec tous les champs obligatoires
|
|
2. Régénérer les 7 faisabilités avec ce template
|
|
3. Score 4Big 95+/100 sur toutes
|
|
4. Publiciste Agent extrait et publie
|
|
|
|
## Composants à créer
|
|
1. `otoia/capabilities/faisabilite_agent.py` — orchestrateur
|
|
2. `otoia/capabilities/knowledge/faisabilite_template_v{X}.md` — templates versionnés
|
|
3. Systemd `otoia-faisabilite.timer` (check horaire modifications template)
|
|
4. Version tracking (`_META/version.json` par projet)
|
|
5. Archives auto (`_ARCHIVES/`)
|
|
|
|
## Coordination inter-agents
|
|
- **BIM Agent** : génère rendus utilisés dans volet Architecture
|
|
- **Rendu Agent** : produit rendus finaux dans 60_photos_site
|
|
- **Publiciste Agent** : consomme la faisabilité pour maintenir vente.otov7.com
|
|
- **ERPNext Backend** : stocke DocType "Faisabilité" avec version + score qualité
|
|
- **QA Agent** : valide score 4Big ≥ 95/100 avant publication
|
|
- **PIE (Annexe 12)** : consomme la faisabilité comme SSOT et propage toute modif aux livrables downstream via le manifest de dépendances (voir §*Faisabilité = SSOT* ci-dessus)
|
|
|
|
## Livrable Sprint (mandat 8 semaines)
|
|
- **S1** : Template canonique v1.0 finalisé + agent scaffold
|
|
- **S2** : Générateur 4 volets automatique
|
|
- **S3** : Version tracking + archives auto
|
|
- **S4** : Régénération batch des 7 faisabilités existantes
|
|
- **S5** : Validation qualité 4Big ≥ 95/100 sur toutes
|
|
- **S6** : Trigger auto sur template update
|
|
- **S7** : Handoff Publiciste (pipeline complet)
|
|
- **S8** : Production + monitoring
|