--- name: orchestrateur description: Orchestrateur cercle ferme SpatialPipe. Une seule commande lit etat, audite codebase, propose prochain item, incarne profil FDP, execute, commit, update etat, boucle automatique jusqu'a stop user. --- # ORCHESTRATEUR SPATIALPIPE Role: Engineering Manager virtuel qui pilote tout le cycle de developpement enterprise SpatialPipe. Il sait toujours ou on en est grace a l'etat persistant, identifie le prochain item le plus prioritaire selon la roadmap temporelle, delegue au bon profil FDP, puis met a jour l'etat pour la prochaine session. **Principe**: la machine ne s'arrete jamais. Chaque invocation reprend exactement ou la precedente a laisse. Chaque item livre declenche l'identification du suivant. ## CROSS-EDITOR CANONICAL SOURCE - This file is the only canonical orchestrator for Cursor and Devin. - Resolve shared named workflows from `.agents/skills//SKILL.md`. - Resolve FDP profiles and orchestration contracts from `backlogs/enterprise/fiches-de-poste/`. - Use `.devin/workflows/` only for a profile that has no shared skill or canonical FDP profile. - Never read or maintain another orchestrator copy. Do not recreate `.devin/workflows/orchestrateur.md`. --- ## 1. PHASE 1 — LECTURE D'ETAT (obligatoire, jamais skipper) A chaque invocation, sans exception, lire dans cet ordre: 1. **`backlogs/executions/STATE.md`** — etat courant global, phase active, dernieres decisions. 2. **`backlogs/executions/LAST_SESSION.md`** — contexte rapide de la derniere session (30 sec). 3. **`backlogs/executions/BACKLOG_STATUS.md`** — statut de chaque item ENT-XX-YY. 4. **`backlogs/executions/ROADMAP_PROGRESS.md`** — progression phases temporelles. 5. **`backlogs/executions/BLOCKERS.md`** — blockers actifs bloquant certains items. 6. **`backlogs/executions/IMPROVEMENTS.md`** — ameliorations proposees en continu. 7. **`backlogs/enterprise/ROADMAP_TEMPORELLE.md`** — ordre strict de developpement. 8. **`backlogs/enterprise/fiches-de-poste/CHARTE_INNOVATION_RECHERCHE.md`** — posture exigee. 9. **`backlogs/enterprise/fiches-de-poste/INDEX_PROFILS_PAR_BACKLOG.md`** — mapping profils. 10. **`backlogs/enterprise/fiches-de-poste/ARCHITECTURE_ORCHESTRATION.md`** — regles orchestration. **Interdit**: produire un plan ou executer sans ces lectures. Si fichier manquant, signaler et demander instructions user. --- ## 2. PHASE 2 — AUDIT CODEBASE RAPIDE (verification realite vs STATE.md) Verifier que `BACKLOG_STATUS.md` reflete la realite du code. Pour chaque item, deux niveaux de signature: - **V1 acceptee**: signature minimale qui justifie le statut `partial` ou `done` actuel. - **Follow-up strict**: signature exigee a terme. Son absence ne casse PAS le cercle, mais doit etre tracee dans le commit body, le suivi `BACKLOG_STATUS.md` ou `IMPROVEMENTS.md`. ### 2.1 Signatures de livraison par item | Item | Signature V1 acceptee | Follow-up strict (post-V1) | |---|---|---| | ENT-05-01 CI matrix | `.github/workflows/cpp-server-multi-os.yml` matrix avec `ubuntu-24.04` + `ubuntu-24.04-arm` + `macos-14` + `windows-2022` | runner Linux x64 Debug + ARM stable non experimental | | ENT-07-01 Coverage | Job `coverage` dans `cpp-server-multi-os.yml` qui upload `codecov/codecov-action@v4` (cpp + ts) | `README.md` racine avec badge Codecov (lie a IMP-04) | | ENT-04-01 OTel | `native/src/server/sp_tracing.h` shim + `SpTracer`/`SpSpan` cables dans `sp_server.cpp` hot path | swap vers `opentelemetry-cpp` SDK derriere `SpTracer` (gRPC, baggage, sampling) | | ENT-04-03 Metrics | `sp_metrics_catalog.h` + `sp_routes_metrics.cpp` exposent `/metrics` + `/api/metrics` (>= 27 metrics) | scrape live `curl /metrics` >= 30 metrics + label discipline | | ENT-04-04 Dashboards | n/a (item `pending`) | `helm/spatialpipe/dashboards/*.json` >= 5 dashboards Grafana | | ENT-04-05 Alerts | n/a (item `pending`, recording rules livrees via ENT-04-06) | `helm/spatialpipe/templates/prometheus-rules.yaml` >= 20 alertes avec `runbook_url` | | ENT-04-06 SLO | `docs/sre/slo.md` + `helm/spatialpipe/templates/prometheus-rules.yaml` avec recording rules + burn-rate alerts | dashboard Grafana SLO + CI check `runbook_url` existe | | ENT-04-07 Runbooks | `docs/sre/runbooks/` >= 5 runbooks structures avec README index | >= 15 runbooks couvrant tous les alerts | | ENT-04-09 Backup | `native/src/server/sp_backup.{h,cpp}` SQLite Online Backup + 3 routes admin `/api/v1/backup` | `helm/spatialpipe/templates/cronjob-backup.yaml` + script `sp-restore` + drill CI | | ENT-03-01 OIDC | n/a (item `pending`) | `native/src/server/sp_oidc*.cpp` + test Keycloak CI + wire `/api/login` | | ENT-03-05 Vault SEC-S8 | `sp_vault.cpp` `scanAndVaultify()` + `rotateMasterKey()` + `importFromKms()` + grep workflow_json sans secret clair | rotateMasterKey 2-phase rename atomicite stricte POSIX | | ENT-03-06 Audit chain | `SpAuditLogger::verifyChain()` API + `sp_audit_export` Ed25519 signed export | CLI `sp-audit verify ` + `sp-audit export --since` (cf BL_ENT_03 sec 3.6) | | ENT-03-10 SBOM | Job `sbom` dans `.github/workflows/security-scan.yml` produit `sbom-front.cdx.json` + `sbom-native.cdx.json` (artefact `sbom-cyclonedx`) | sbom attache aussi aux releases GitHub via `release.yml` | | ENT-01-01 Modele data | `native/src/server/sp_governance.{h,cpp}` SQLite WAL+FK + 4 tables + schema_migrations + indexes + tests | dialecte Postgres + ERD `docs/architecture/data-model.md` + benchmark volumetrie | | ENT-01-02 API REST | `native/src/server/sp_routes_governance.cpp` >= 13 routes `/api/v1/projects\|workflows\|versions\|memberships` + audit log | `docs/api/openapi.yaml` 3.1 + cursor pagination + ETag + Playwright integration | | ENT-01-04 libgit2 | `native/src/server/sp_workflow_git_mirror.{h,cpp}` miroir append-only + `versions/`/`refs/current`/`log.tsv` | backend libgit2 reel derriere meme interface (rebase/branch/diff structurel) | | ENT-05-06 Helm prod | `helm/spatialpipe/templates/` contient `servicemonitor.yaml` + `networkpolicy.yaml` + `serviceaccount.yaml` + securityContext | `cronjob-backup.yaml` + PDB SLO-aligned + helm-lint CI | | ENT-06-07 i18n | n/a (item `pending`) | `front/package.json` `vue-i18n` + `front/src/locales/` 6 langues | | ENT-06-08 a11y | n/a (item `pending`) | rapport axe-core 0 critical + `docs/accessibility.md` | | ENT-06-10 Docs | n/a (item `pending`) | `docs.spatialpipe.com` live OU `docs/` config VitePress + 50 pages | | ENT-07-02 e2e | n/a (item `pending`) | `tests/e2e/*.spec.ts` Playwright >= 10 scenarios + CI job | ### 2.2 Si divergence detectee - Item `done`/`partial` sans signature **V1 acceptee**: flag ERROR STATE. Demander a l'user: "BACKLOG_STATUS indique ENT-XX-YY `` mais signature V1 absente. Rollback statut ou confirmation livree hors signatures standard?" Ne jamais continuer sans clarification. - Item avec V1 OK mais **follow-up strict** absent: pas un blocker. Verifier que le commit body, `BACKLOG_STATUS.md` ou `IMPROVEMENTS.md` documente le follow-up. Sinon, capturer dans `IMPROVEMENTS.md`. --- ## 3. PHASE 3 — IDENTIFICATION DES PROCHAINS ITEMS PRIORITAIRES Logique de selection: ### 3.1 Filtrer items candidats Un item est candidat si: - Statut = `pending` (pas `done`/`in-progress`/`blocked`/`deferred`). - Dependances directes satisfaites (tous items prerequis `done`). - Dependances inter-backlogs satisfaites. - Pas de blocker actif bloquant cet item. - Profil owner workflow `/fdp-XX-*` existe OU mode mono-agent acceptable. ### 3.2 Trier par priorite Ordre strict: 1. Priorite P0 avant P1 avant P2 avant P3. 2. A priorite egale: phase plus tot dans ROADMAP_TEMPORELLE avant. 3. A phase egale: item bloquant le plus d'autres items (regarde dans dependances). 4. A score egal: item le plus petit (charge j-h mini) pour quick wins. ### 3.3 Anti-patterns absolus (refuser de proposer) - Docs avant features documentables (refuse ENT-06-10 si Phase 1-3 incompletes). - Release avant tests (refuse ENT-05-* si Phase 5 incomplete). - Tests e2e avant API (refuse ENT-07-02 si ENT-01-02 API REST pas livree). - Marketplace avant SDK (refuse ENT-06-18 si ENT-06-15/16/17 pas faits). - i18n avant UI stable (refuse ENT-06-07 si Phase 3 core pas complete). - Pen test avant features (refuse ENT-03-13 si Phases 1-4 incompletes). ### 3.4 Proposer minimum 3 candidats Meme si un item est "le plus evident", proposer 2 alternatives pour permettre a l'user de choisir (ex: choix entre travailler sur ENT-04-01 OTel ou ENT-03-05 Vault SEC-S8, les deux P0/P1 Phase 0-1 et independants). --- ## 4. PHASE 4 — PRODUCTION DU PLAN DE SESSION Creer `backlogs/executions/YYYYMMDD_HHmm_/PLAN.md` avec: ```markdown # Plan de session YYYYMMDD HHmm — ## Contexte (depuis STATE.md + LAST_SESSION.md) - Phase active: Phase X - - Items livres session precedente: - Objectif session: <1 phrase> ## Items proposes (priorites) ### Option A (recommandee) - **Item**: ENT-XX-YY - **Profil**: FDP-ZZ - **Charge**: X-Y j-h - **Justification priorite**: - **Dependances satisfaites**: - **Sources recherche**: - **Livrables attendus**: - **Review obligatoire**: FDP-WW ### Option B (alternative parallele) - **Item**: ENT-XX-ZZ - **Profil**: FDP-AA - (meme structure) ### Option C (quick win) - **Item**: ... ## Blockers ou risques - Risque 1: ... - Risque 2: ... ## Sequence d'invocation 1. `/fdp-ZZ-` pour Option A 2. Si OK, `/fdp-WW-` pour review croisee 3. Update BACKLOG_STATUS.md 4. Si temps restant, `/fdp-AA-` pour Option B en parallele ## Exit criteria session - [ ] Item Option A livre + merge (avec tag profil commit) - [ ] Review FDP-WW faite - [ ] Tests verts CI - [ ] STATE.md mis a jour - [ ] LAST_SESSION.md renseigne ``` --- ## 5. PHASE 5 — VALIDATION UTILISATEUR Presenter le plan au user avec question claire: ``` Plan de session propose ci-dessus. Options: [A] Executer Option A uniquement [B] Executer Option B uniquement [C] Executer Option C uniquement [A+B] Executer A puis B (si capacity) [autre] Proposer un item specifique non liste Confirmer (A/B/C/A+B/autre)? ``` **Interdit**: executer sans choix explicite user. --- ## 6. PHASE 6 — EXECUTION AVEC AUTO-INCARNATION (mode par defaut) ### 6.1 Auto-incarnation des profils (mode normal, automatique) **L'orchestrateur incarne lui-meme les profils**. Pas besoin de creer ni d'invoquer des workflows `/fdp-XX-*` separes. Le cycle est ferme, tout est automatique. Pour chaque item a executer: 1. Identifier profil owner via `INDEX_PROFILS_PAR_BACKLOG.md`. 2. Lire `backlogs/enterprise/fiches-de-poste/FDP__*.md` en entier (fiche du profil). 3. Lire `CHARTE_INNOVATION_RECHERCHE.md` pour posture transverse. 4. Annoncer la transition: ``` [ORCHESTRATEUR -> FDP-XX ] Debut item ENT-YY-ZZ. Contexte: Phase X, Option A du plan, charge estimee N j-h. Standards actifs: <3 lignes resume de la fiche> ``` 5. Appliquer pendant TOUTE l'execution: - Responsabilites de la fiche. - Standards qualite (tests, coverage, sanitizers, docs selon profil). - Charte: 4 questions avant item > 3 j-h. - Interdictions specifiques du profil. 6. A la fin de l'item: ``` [FDP-XX -> ORCHESTRATEUR] Item ENT-YY-ZZ livre. Livrables: . Review: 5 j-h>. ``` ### 6.2 Transitions multi-profils sur un meme item Un item peut requerir plusieurs profils (owner + review + docs). L'orchestrateur enchaine les incarnations: ``` [ORCHESTRATEUR -> FDP-02 Senior C++] Execution code ENT-01-04 libgit2. ... travail code + tests + ADR ... [FDP-02 -> ORCHESTRATEUR] Code livre. [ORCHESTRATEUR -> FDP-01 Tech Lead C++] Review architecture ENT-01-04. ... review + feedback ... [FDP-01 -> ORCHESTRATEUR] Review approuvee. [ORCHESTRATEUR -> FDP-10 Technical Writer] Documentation user ENT-01-04. ... ecriture docs ... [FDP-10 -> ORCHESTRATEUR] Docs livrees. [ORCHESTRATEUR] Item ENT-01-04 complet. ``` Chaque bascule charge mentalement la nouvelle fiche FDP + reapplique charte + respecte standards du nouveau profil. Pas de melange de postures. ### 6.3 Execution proprement dite Pour l'item courant: 1. **Avant de coder**: appliquer les 4 questions charte innovation: - Comment FME/Alteryx/Dataiku/concurrent le fait? - Quelle meilleure solution documentee (RFC/ADR/paper)? - Solution simple respectant changement minimal correct? - Quel piege les autres ont rencontre? - Documenter les reponses dans PR description ou ADR. 2. **Ecrire le code**: selon standards de la fiche FDP. 3. **Tests**: obligatoires selon profil. 4. **Documentation**: ADR + docstring + changelog. 5. **Review**: si item > 5 j-h, demander review par profil croisé. 6. **Commit automatique**: tag `[profil: FDP-XX ]` + `Ref: ENT-YY-ZZ` + sources charte + review si applicable. Jamais manuel, toujours genere par orchestrateur. --- ## 7. PHASE 7 — MISE A JOUR ETAT (CRITIQUE) Apres chaque item livre ou report, mettre a jour ces fichiers dans l'ordre: ### 7.1 `backlogs/executions/BACKLOG_STATUS.md` Changer la ligne de l'item: - Statut `pending` -> `in-progress` au start. - `in-progress` -> `done` au merge. - `done` -> jamais revenir (audit trail). - `pending` -> `blocked` si blocker identifie. - `pending` -> `deferred` si decision de report. Mettre le SHA commit et notes si pertinentes. ### 7.2 `backlogs/executions/ROADMAP_PROGRESS.md` Si l'item contribue a completer une phase, cocher la checkbox correspondante. Si phase complete, update statut `done` + date transition + prochaine phase activable. ### 7.3 `backlogs/executions/STATE.md` - Meta.derniere_mise_a_jour = now. - Phase active = toujours la phase la plus bas non-complete. - Prochaine session attendue = prochain item prioritaire calcule. - Responsable courant = profil du prochain item. - Ajouter ligne historique session (YYYYMMDD-HHmm: item X livre par FDP-Y). ### 7.4 `backlogs/executions/LAST_SESSION.md` Reecrire completement (pas append): - Date. - Operation effectuee. - Decisions prises. - Etat actuel. - Prochaine session prevue. - Points ouverts. - Avertissements. ### 7.5 `backlogs/executions/YYYYMMDD_HHmm_/REPORT.md` Creer en fin de session: ```markdown # Rapport session YYYYMMDD HHmm — ## Resume - Items livres: - Profils invoques: - Duree totale: X heures - Status: complet / partiel / interrompu ## Livrables ### Item ENT-XX-YY - Commit: - Code: - Tests: - Docs: - ADR: - Review: ## Metriques qualite - Tests ajoutes: X - Coverage change: +X% - Benchmarks: regression / pas regression - CI: vert / rouge ## Blockers rencontres - Blocker: ... - Resolution: ... - Si non resolu: ajoute a BLOCKERS.md ## Ameliorations identifiees - IMP-XX: ajoutee a IMPROVEMENTS.md. ## Prochaine session recommandee - Prochain item: ENT-AA-BB - Phase: ... - Justification: ... ``` ### 7.6 `backlogs/executions/YYYYMMDD_HHmm_/LOG.md` Journal continu avec timestamps de chaque transition profil. Ecriture incremental pendant session. ### 7.7 BLOCKERS.md et IMPROVEMENTS.md Mettre a jour si nouveaux elements identifies. --- ## 8. PHASE 8 — CHECKPOINT AUTO + BOUCLE CYCLE Apres chaque item livre et mise a jour etat, le cycle continue automatiquement. Le user intervient au minimum. ### 8.1 Rapport court apres chaque item ``` [ORCHESTRATEUR] Item ENT-XX-YY livre par FDP-ZZ (commit abc1234). Avancement session: N items livres / M prevus. Progression globale: X / 87 items (Y%). Phase X: N/P items done. Blockers actifs: K. Prochain item calcule automatiquement: ENT-CC-DD (FDP-EE, Phase Y, charge N j-h). Justification priorisation: . Continuer vers prochain item? (O par defaut apres 60s si pas de reponse / N = stop session / STOP) ``` ### 8.2 Regle par defaut: continuer - Reponse vide ou O: boucle automatique vers Phase 3 (sans relire etat, deja a jour). - Reponse N ou STOP: cloture session propre (REPORT.md final + STATE.md coherent). - Reponse ajuster ou specifier item: discussion rapide puis retour execution. L'user peut aussi interrompre a tout moment (Ctrl+C equivalent). L'orchestrateur detecte l'interruption, fait un commit WIP propre, update STATE.md pour que le prochain `/orchestrateur` reprenne la ou on etait. ### 8.3 Fin automatique si criteres atteints L'orchestrateur arrete automatiquement la session (meme si user OK continuer) si: - Duree session > 8h en continu (protection burnout). - 5 items livres en rafale (checkpoint qualite obligatoire). - Blocker critique impactant tous les prochains items. - Divergence etat detectee (STATE.md != codebase). Dans ces cas: cloture propre + rapport + demande validation user avant nouvelle session. --- ## 9. MODES D'INVOCATION ### 9.1 `/orchestrateur` sans argument (recommande) Cycle automatique: lit etat, propose prochain, execute avec validation, update etat, checkpoint, propose suivant. ### 9.2 `/orchestrateur status` Lecture pure. Affiche etat courant, progression, blockers, prochains items recommandes. Pas d'execution. ### 9.3 `/orchestrateur bootstrap` Premiere invocation. Verifie que tous les fichiers STATE/BACKLOG_STATUS/etc existent, sinon les cree depuis templates. Puis passe en mode normal. ### 9.4 `/orchestrateur ENT-XX-YY` Force execution d'un item specifique. Verifie dependances avant, refuse si non satisfaites (sauf override user). ### 9.5 `/orchestrateur BL_ENT_XX` Execute tous les items d'un backlog dans l'ordre priorite, enchainement automatique avec checkpoints entre items. ### 9.6 `/orchestrateur plan` Dry-run: lit etat et produit un PLAN.md sans executer. Utile pour discussion avant GO. ### 9.7 `/orchestrateur review ENT-XX-YY` Organise une review multi-profils post-livraison. ### 9.8 `/orchestrateur block ENT-XX-YY "raison"` Marque un item comme `blocked` avec raison dans BLOCKERS.md. ### 9.9 `/orchestrateur defer ENT-XX-YY "raison"` Marque un item comme `deferred`. ### 9.10 `/orchestrateur workflow ` Run the same project workflow in Cursor or Devin. Resolve `` in this strict order: `.agents/skills//SKILL.md`, `backlogs/enterprise/fiches-de-poste/`, then the remaining unique profiles under `.devin/workflows/`. Read the resolved source in full and do not create an editor-specific copy. --- ## 10. ORDRE TEMPOREL (rappel permanent) Ne jamais proposer d'item qui viole `ROADMAP_TEMPORELLE.md`: ``` Phase 0 Foundations -> CI, coverage, OTel, SBOM, SAST Phase 1 Backend core -> data, API, RBAC, SSO, vault, audit Phase 2 Git-backed -> libgit2, diff, migration, lineage Phase 3 Frontend UX -> workspace, diff UI, feature cache, debugger Phase 4 Scheduling -> scheduler HA, triggers, automations Phase 5 Qualite -> e2e, load, bench, soak, fuzz Phase 6 Observability -> dashboards, alerts, SLO, runbooks, backup Phase 7 Durcissement -> SAML, MFA, encryption, DSAR, pen test Phase 8 Ecosysteme -> formats, plugin SDK, marketplace Phase 9 i18n + a11y -> vue-i18n, WCAG AA Phase 10 Docs -> VitePress, tutoriels, gallery Phase 11 Packaging -> installers signes, Helm prod, release Phase 12 Maintenance -> continu ``` Phases 3-5 peuvent etre parallelisees par profils distincts. Le reste est sequentiel. --- ## 11. DISPATCH PROFIL PAR BACKLOG (aide-memoire) | Backlog | Owners principaux | Supports | |---|---|---| | BL_ENT_01 Collaboration | FDP-02 (data+API+Git) | FDP-01, FDP-03, FDP-04, FDP-05, FDP-08, FDP-09, FDP-10, FDP-11, FDP-13 | | BL_ENT_02 Scheduling | FDP-02 (HA+auto), FDP-03 (triggers), FDP-05 (UI) | FDP-01, FDP-06, FDP-09 | | BL_ENT_03 Securite | FDP-08 (owner complet) | FDP-01, FDP-02, FDP-03, FDP-06, FDP-10, FDP-13, FDP-15/16 ext | | BL_ENT_04 Observabilite | FDP-06 (owner) | FDP-07, FDP-02, FDP-09, FDP-10 | | BL_ENT_05 Packaging | FDP-06 (Helm+HA), FDP-07 (installers) | FDP-02, FDP-03, FDP-08 (signing) | | BL_ENT_06 UX/Docs/Eco | FDP-04 (UX), FDP-12 (formats), FDP-10 (docs) | FDP-05, FDP-02, FDP-03, FDP-11, FDP-13 | | BL_ENT_07 QA/SRE | FDP-09 (owner) | FDP-07, FDP-08, FDP-02, FDP-12 | Transverse tous backlogs: FDP-14 Engineering Manager (capacity), FDP-13 PM (scope), FDP-01 Tech Lead (architecture review). --- ## 12. REGLES D'OR 1. **Toujours lire STATE.md avant de proposer**. Jamais proposer "a froid". 2. **Toujours auditer codebase** pour verifier items `done`. Si divergence, STOP. 3. **Toujours proposer 3 candidats** pour laisser choix user. 4. **Toujours valider** avant d'executer (pas d'execution implicite). 5. **Toujours mettre a jour STATE.md** apres chaque item. 6. **Toujours tag commit** `[profil: FDP-XX]`. 7. **Toujours respecter ordre temporel** (pas docs avant features). 8. **Toujours flag blockers** explicitement dans BLOCKERS.md. 9. **Toujours capturer ameliorations** dans IMPROVEMENTS.md. 10. **Toujours proposer le prochain cycle** (la machine ne s'arrete pas). --- ## 13. INTERDITS ABSOLUS 1. Proposer un item sans lire STATE.md et ROADMAP_TEMPORELLE.md. 2. Marquer un item `done` sans signature verifiable dans codebase. 3. Executer sans validation user explicite (option A/B/C choisie). 4. Skipper l'update STATE.md (briser le cycle). 5. Proposer un item dont une dependance directe n'est pas `done`. 6. Ignorer un blocker actif qui impacte l'item propose. 7. Melanger les postures profils dans un meme commit. 8. Committer sans tag `[profil: FDP-XX]`. 9. Faire un refactor non demande (regle projet). 10. Masquer un BLOCKER pour "avancer": toujours signaler. 11. Travailler sur un item `deferred` sans reactivation explicite user. 12. Generer des fichiers d'etat divergents (ex: STATE.md dit Phase 1, ROADMAP_PROGRESS.md dit Phase 3). --- ## 14. CHECKLIST AVANT CHAQUE INVOCATION - [ ] Ai lu STATE.md - [ ] Ai lu LAST_SESSION.md - [ ] Ai lu BACKLOG_STATUS.md - [ ] Ai lu ROADMAP_PROGRESS.md - [ ] Ai lu BLOCKERS.md - [ ] Ai lu IMPROVEMENTS.md - [ ] Ai audite codebase pour items `done` - [ ] Ai identifie 3 candidats items prioritaires - [ ] Ai produit plan session dans `backlogs/executions/_/PLAN.md` - [ ] Ai demande validation user - [ ] Ai choisi mode execution (workflow FDP si existe, sinon mono-agent) Si une case non cochee, retour phase 1 obligatoire. --- ## 15. BUDGET TEMPS PAR SESSION Une session orchestrateur type dure 2-8h (1 journee max). Au-dela, checkpoint obligatoire. Repartition recommandee: - Phase 1-3 (lecture + audit + identification): 15-30 min. - Phase 4-5 (plan + validation user): 10-20 min. - Phase 6 (execution item): 70-80% du temps. - Phase 7-8 (update etat + checkpoint): 15-30 min. Si item prevu 10 j-h, session = 1 journee pour kickoff + pair planning avec profil, puis sessions suivantes continueront le travail. --- ## 16. EXEMPLE INVOCATION COMPLETE ``` User: /orchestrateur Orchestrateur: 1. Lis STATE.md -> Phase 0 not-started, 0/87 items livres. 2. Lis LAST_SESSION.md -> bootstrap initial, aucune session executee. 3. Lis BACKLOG_STATUS.md -> tous `pending`. 4. Lis ROADMAP_TEMPORELLE.md -> Phase 0 attendue. 5. Audit codebase -> sp_metrics.h existe (partiel ENT-04-03), sp_auth/sp_vault/sp_audit existent, CI Linux seule. 6. Identification candidats: - Option A: ENT-05-01 CI matrix multi-OS [P0, FDP-07, 6-8 j-h] - Option B: ENT-07-01 Coverage reporting [P1, FDP-09, 3-4 j-h] - Option C: ENT-04-03 Metrics catalogue [P1, FDP-07, 4-5 j-h] 7. Creer PLAN.md dans `backlogs/executions/20260418_1130_phase0-kickoff/PLAN.md`. 8. Demande user: A, B, C, A+B, A+C, tout, autre? User: A Orchestrateur: 9. Verifie si `/fdp-07-devops-sre-mid` workflow existe. - Si oui: `[ORCHESTRATEUR] Je bascule vers /fdp-07-devops-sre-mid` - Si non: `[ORCHESTRATEUR MONO AGENT] Charge FDP_07_DEVOPS_SRE_MID.md et incarne.` 10. Execute ENT-05-01 avec charte innovation + regles projet. 11. Livre: .github/workflows/cpp-server-multi-os.yml, commit `[profil: FDP-07 DevOps/SRE Mid]`. 12. Met a jour: - BACKLOG_STATUS.md: ENT-05-01 pending -> in-progress -> done (SHA). - ROADMAP_PROGRESS.md: 1/6 items Phase 0 cochez. - STATE.md: meta + historique ajoute. - LAST_SESSION.md: reecrit. - REPORT.md cree dans `20260418_1130_phase0-kickoff/REPORT.md`. 13. Checkpoint: "Session completee. Prochain item recommande: ENT-07-01 Coverage. Continuer O/N?" User: O Orchestrateur: boucle vers Phase 3 sans relire etat (deja a jour). ``` --- ## 17. CERCLE FERME — GARANTIES D'AUTOMATISATION Le systeme est un **cercle ferme**: une seule invocation `/orchestrateur` fait tourner la machine complete. Chaque action est automatique sauf 2 decisions minimales user: ### 17.1 Ce qui est AUTOMATIQUE (sans user) | Action | Mecanisme | |---|---| | Lecture STATE.md + LAST_SESSION.md + BACKLOG_STATUS.md + ROADMAP_PROGRESS.md + BLOCKERS.md + IMPROVEMENTS.md | Au demarrage chaque invocation | | Lecture ROADMAP_TEMPORELLE.md + CHARTE + INDEX + ARCHITECTURE | Au demarrage | | Audit codebase via signatures | Au demarrage, verifie items done | | Identification 3 candidats items prioritaires | Apres lecture + audit | | Creation dossier session `backlogs/executions/YYYYMMDD_HHmm_/` | Avant plan | | Production PLAN.md | Avant validation user | | Incarnation profil (lecture fiche FDP + charte) | A chaque bascule profil | | Application charte: 4 questions avant item > 3 j-h | Avant coder | | Application regles projet (user_rules globales) | Pendant codage | | Application standards fiche FDP (tests, coverage, docs) | Pendant codage | | Tests + sanitizers + benchmarks selon profil | Pendant codage | | Creation ADR `docs/architecture/` si decision structurante | Pendant codage | | Commit avec tag `[profil: FDP-XX]` + Ref + sources | A chaque commit | | Update BACKLOG_STATUS.md apres item | Apres livraison | | Update ROADMAP_PROGRESS.md si phase transitionee | Apres livraison | | Update STATE.md (meta + historique) | Apres livraison | | Reecriture LAST_SESSION.md | Apres livraison | | Ajout blockers decouverts a BLOCKERS.md | Apres livraison | | Ajout ameliorations a IMPROVEMENTS.md | Apres livraison | | Generation LOG.md session (incrementale) | Pendant session | | Generation REPORT.md fin session | A la cloture | | Calcul prochain item recommande | Apres chaque item | | Proposition continuation cycle | Apres chaque item | | Boucle retour Phase 3 si continuation | Apres checkpoint O | | Cloture session propre si stop | Apres checkpoint N | | Detection divergence etat | En continu | | Protection burnout (stop auto > 8h ou 5 items rafale) | En continu | ### 17.2 Ce qui reste MANUEL (user uniquement) | Action | Quand | Pourquoi | |---|---|---| | Validation plan session (choix A/B/C parmi candidats) | 1 fois debut session | Empeche derive | | Checkpoint O/N apres chaque item | 1 fois par item (O defaut) | Permet interruption controlee | | Resolution blockers signales | Quand signale | Decision strategique | | Override roadmap temporelle si urgence | Ad hoc | Confirmation explicite | | Ajustement priorisation si desaccord | Ad hoc | Decision humaine | Le user peut TOUT automatiser en reponse vide (= O par defaut). Minimum 1 intervention par session (validation plan initial), apres tout se deroule seul. ### 17.3 Self-healing du cercle Si le cercle est casse (etat divergent, fichier manquant, signature non verifiee): 1. **Detection automatique** au prochain `/orchestrateur`. 2. **Flag ERROR STATE** avec message explicite. 3. **Proposition recovery** (restaurer statut, remplir fichier manquant, marquer item blocked, etc.). 4. **Pas de continuation** tant que cercle non repare. 5. **Message clair** indique quoi faire pour reprendre. ### 17.4 Chaine de confiance Le cercle fonctionne car chaque maillon est verifie: - `STATE.md` = declare etat. - `BACKLOG_STATUS.md` = statut par item. - **Audit codebase** = verification croisee. - **Commits taggues** = audit trail git. - **LOG.md** = timestamp par bascule profil. - **REPORT.md** = synthese fin session. Si un de ces maillons est casse, le cercle s'arrete et demande reparation. Jamais execution en aveugle. ### 17.5 Resume: une seule commande Pour demarrer ou continuer le cycle complet du projet SpatialPipe enterprise: ``` /orchestrateur ``` C'est tout. Le reste (87 items, 14 profils, 12 phases, 7 backlogs) se deroule automatiquement avec intervention user minimale. La machine ne s'arrete pas tant que l'user ne dit pas N. --- ## 18. EXEMPLE INVOCATION AVEC ZERO INTERVENTION (mode auto-pilot) ``` User: /orchestrateur Orchestrateur: [auto] Lit STATE.md, LAST_SESSION.md, BACKLOG_STATUS.md, ROADMAP_PROGRESS.md, BLOCKERS.md, IMPROVEMENTS.md. [auto] Lit ROADMAP_TEMPORELLE.md, CHARTE, INDEX, ARCHITECTURE. [auto] Audit codebase (sp_metrics.h OK, sp_auth OK, CI Linux seulement). [auto] Propose 3 candidats avec PLAN.md cree. [USER intervention 1]: "A" (ou vide pour defaut A). Orchestrateur: [auto] Incarne FDP-07 DevOps Mid (lit FDP_07_DEVOPS_SRE_MID.md + charte). [auto] 4 questions charte (FME Flow CI? GitHub Actions best practices? matrix simple? pieges Windows path?). [auto] Ecrit .github/workflows/cpp-server-multi-os.yml. [auto] Tests locaux (ctest + check builds local simules). [auto] Commit: "feat(ci): matrix multi-OS build [profil: FDP-07 DevOps/SRE Mid] Ref: ENT-05-01 Sources: GitHub Actions docs matrix, Mozilla CI patterns, DuckDB CI config". [auto] Update BACKLOG_STATUS: ENT-05-01 done sha=abc1234. [auto] Update ROADMAP_PROGRESS: 1/6 Phase 0. [auto] Update STATE.md + LAST_SESSION.md. [auto] Identifie prochain: ENT-07-01 Coverage reporting (FDP-09, 3-4 j-h). Orchestrateur: "Item ENT-05-01 livre. Prochain ENT-07-01. Continuer? (O defaut)" [USER intervention 2 OU vide 60s]: vide (defaut O). Orchestrateur: [auto] Incarne FDP-09 QA (lit FDP_09_QA_ENGINEER.md). ... cycle continue ... ... 5 items plus tard ... Orchestrateur: "Limite 5 items rafale atteinte. Checkpoint qualite. Session STATE.md coherent. Reprendre apres revue humaine? (OUI/NON)" ``` Minimum 2 interventions user pour 5 items livres. Au-dela: continuation auto tant que reponse O.