Le bloc « apply_plan » existant de check_readme_claims.sh (bloc 2) ne gate QUE la
ligne AGRÉGÉE « Génération réelle » (8 comptes consolidés). Les 3 colonnes
d'identité de la table run-book (README:38-46) sont data-derived de
out/apply_plan.json (byte-gaté par check_artifacts) : # = order · Responsable =
responsable (worker/vps/worker+vps) · Dépend de = les n°s d'ordre des depends_on.
Elles étaient un WILDCARD. PIÈGE : check_artifacts ne prouve QUE apply_plan==build
(byte-for-byte) et le bloc de comptes est aveugle à l'identité des lignes → passer
le Responsable de l'étape 4 (worker+vps→vps) ou retirer une dépendance de l'étape 6
(4,5→4) laissait la prose périmée pendant que l'artefact dit autre chose. Un
responsable périmé (étape VPS attribuée au worker) ou une dépendance périmée (Role
Profile importé AVANT les Role) est un hazard réel — le risque même que le run-book
veut prévenir — qu'aucune suite tests/ (qui teste des fonctions, pas la table
commitée) n'attrape. Même classe que la colonne « Type » de roleprofile_gen et la
table demo/scenarios.
Nouveau sous-bloc « 2bis) apply_plan — TABLE Run-book » : (1) IDENTITÉ par étape —
chaque ligne porte EXACTEMENT #=order + Responsable=responsable + Dépend de=n°s
d'ordre des depends_on (deps extraits par digits ⇒ robuste au séparateur/em-dash) ;
colonne « Étape » libre (paraphrase). (2) IDENTITÉ d'ensemble — {ordres des lignes}
== {ordres artefact} sans doublon (aucune ligne FANTÔME, aucune étape MANQUANTE).
Cohérences croisées (mordent un plan INTERNEMENT incohérent) : ordres contigus 1..N ·
responsable ∈ {worker,vps,worker+vps} · toute dépendance pointe en ARRIÈRE
(n° < n° de l'étape). Un claim absent échoue AUSSI.
8 morsures vérifiées : README étape4 responsable worker+vps→vps (câblage) · README
étape6 Dépend de 4,5→4 (dep manquante) · README étape3 1,2→1,2,5 (dep fantôme) ·
ligne FANTÔME #7 (7≠6) · étape 5 SUPPRIMÉE (INTROUVABLE + 5≠6) · artefact étape2
responsable vps→worker (README stale) · artefact étape2 dep en AVANT (graphe
incohérent) · artefact étape1 responsable hors domaine (robot) ; restauré = green :
6 lignes == 6 étapes · responsables/deps == artefact · ordres 1..6 · exit 0.
État courant : aucune valeur périmée (anti-invention #6, rien à réécrire) — le
défaut est la surface ungated. ci/README.md (table + détail « 2ᵉ surface
rbac/apply_plan ») mis à jour · working tree byte-restauré · 7 gates re-verts.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OTO Enterprise OS · Digital Twin Platform (DTP)
Mandat de refactoring 8 semaines ou moins : unifier BIM (Blender/Bonsai/IFC/Speckle),
ERPNext v15 natif, la Console Helios (luxury dark+doré) et les faisabilités 4 volets
niveau 4Big, pilotés par l'agent orchestrateur OTOIA. Vision et contraintes
NON-NÉGOCIABLES : CLAUDE.md.
Point d'entrée de ce dépôt de mandat. Il indexe les artefacts et rapporte l'état courant. Chaque chiffre ci-dessous est sourcé vers un artefact commité (anti-invention
CLAUDE.md#6) ; ce README n'introduit aucune donnée nouvelle.
Navigation
| Zone | Contenu |
|---|---|
CLAUDE.md |
Vision · 10 contraintes NON-NÉGOCIABLES · entités · projets · VPS |
04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md |
Plan 8 sprints · gains d'accélération (~47%) · métriques succès MVP |
AGENTS_EXISTING_ASSETS.md |
Modules OTOV7 réutilisés par agent (source des refactorings) |
PORTAIL_BANCABLES_4BIG.md |
Cadre de bancabilité 4Big |
02_master_prompt/ |
Prompt maître du mandat |
03_agents/ |
Fiches des 13 agents (rôle · livrables · coordination) |
05_deliverables_mvp/ |
Livrables (générateurs déterministes + hand-off out/) |
05_deliverables_mvp/GAP_ANALYSIS_SPRINT1.md |
Audit d'assets + gap analysis (Sprint 1) |
05_activity_log/ |
Journal de session horodaté |
.gitea/workflows/ci.yml · ci/ |
Gate CI Gitea Actions + guards locaux |
tests/ |
Baseline E2E Playwright |
Les 13 agents
Faisabilité & 3D : bim · ifc_speckle ·
rendu · faisabilite ·
publiciste
Plateforme : erpnext_backend ·
frontend_console · crm ·
onapi_legal · seo ·
mobile
Transverses : devops · qa
État courant (sourcé)
- Qualité 4Big : 22/22 modules gated à 100/100 (seuil 95 ·
CLAUDE.md#5), verdictPASS— sourceqa/audit_4big/out/quality_report.json. - Régression : 22 suites gated couvertes bijectivement vs CI ; le compte de tests
agrégé faisant autorité est produit par
qa/regression run(non commité par design) — planqa/regression/out/regression_plan.json. - Recette roadmap : 15 promesses (8 livrables sprint + 7 métriques MVP), 15
in_repoprouvées (chacune traçant ses items hors-périmètre worker · #8 · ex. M5 « app publiée 2 stores »), verdicttrue— sourceqa/acceptance/out/acceptance_matrix.json. - Guards :
ci/guard_constraints.sh+ci/check_docs.shverts.
Périmètre worker (in-repo) vs VPS
Ce dépôt produit des générateurs déterministes et leurs hand-off out/, gatés en CI.
Le déploiement réel (bench migrate, import fixtures, câblage nginx/systemd, builds stores,
indexation, voix Amélie) s'exécute sur le VPS 153.75.250.214 et reste hors périmètre
worker (CLAUDE.md #8). Le plan d'activation ordonné est le run-book
devops/deploy_runbook.
Git — Gitea uniquement
Dépôt de mandat : michel/oto-enterprise-os-dtp sur Gitea (153.75.250.214:3015).
JAMAIS GitHub / GitLab / Bitbucket (CLAUDE.md #2, garde ci/guard_constraints.sh).