michel/oto-enterprise-os-dtp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d7dbda9e2b5e911fd5651c23bb816fb90546d4aa
oto-enterprise-os-dtp/03_agents/faisabilite/AGENT.md
T
Claude Code DTP Worker a39dc28f59 [DTP-Worker 20260805_074202] FIX de COUVERTURE : le livrable transverse demo/scenarios (Sprint 7 · CRM+Faisabilité) manquait des DEUX fiches co-porteuses → recensé, une seule source gatée 
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>
2026-08-05 07:50:35 +00:00

8.9 KiB
Raw Blame History

🏗️ 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 1 (roadmap L41-46) Template canonique v1.0 — contrat des 4 volets + champs obligatoires (§Livrable S1 ci-dessous) — (doc contrat) check-docs —
generator/ 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/ 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 — 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, §« 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 (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 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 (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
Reference in New Issue View Git Blame Copy Permalink