michel/oto-enterprise-os-dtp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
04f4c217782e7d9a21202802a2d707ed35adfd60
oto-enterprise-os-dtp/03_agents/faisabilite/AGENT.md
T
Claude Code DTP Worker 3710253c02 [DTP-Worker 20260806_104533] FIX couverture · oracle orphelin brief.schema.json câblé à un test → le SEUL des 26 *.schema.json non enforced 
Constat: faisabilite/generator/brief.schema.json, documenté « Contrat d'entrée »
et sibling de version/projets_master (tous deux test-enforced), n'était validé
par AUCUN test — _validate_brief() ne garde que le code projet, jamais la forme
complète du brief; un brief drifté hors contrat passait inaperçu.

Fix (teeth): test_input_briefs_validate_against_brief_schema valide les 2 fixtures
contre brief.schema.json via le validateur maison Publiciste (zéro-pip, toujours
exécuté, pas de skip sous python -S). Conformité pré-vérifiée sous validateur
maison ET oracle jsonschema. L'« incomplet » est conforme au sens schéma
(null admis) — incomplet seulement au sens sémantique (prix→placeholders #6).

Cascade régénérée (générateurs, jamais à la main #6): regression_plan/run/MANIFEST
16→17 · totaux 624→625 exécutés / 607→608 passés / 17 skippés · quality_report
evidence 16→17. Prose gatée réalignée (le gate check-readme-claims a mordu):
README module + fiches faisabilite/qa/erpnext_backend. Prose ungatée: GAP_ANALYSIS
16→17 + nouveau bloc daily_report (blocs currency antérieurs = snapshots datés,
non réécrits).

0 gate ajouté (#5) · 0 chiffre à la main (#6) · 0 commande VPS (#8).
run_ci.sh = 33 PASS · 0 FAIL · 0 SKIP.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-06 10:56: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 17
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