# Plan d’implémentation frontend Devtools

> Archive historique conservée côté `TTM_API`.
>
> Source de vérité active : `C:\Users\VT\PhpstormProjects\ttm-dev-tools\docs\DEV_TOOLS_DEPLOYMENT_AUDIT.md` et `C:\Users\VT\PhpstormProjects\ttm-dev-tools\docs\README_DEV_TOOLS_UI.md`.
>
> Ce document décrit un plan frontend antérieur à l’extraction du `dev-tools` vers `ttm-dev-tools`. À utiliser seulement comme contexte d’archive.

## Cadre retenu

- La spec de référence est `docs/dev-tools/devtools-ui-spec-front.md`.
- Le frontend Devtools actuel **n’est pas** dans `ttm-shop-front` : il est rendu côté backend via une shell HTML Express + des scripts vanilla JS dans `shared/dev-tools-ui/`.
- Le plan ci-dessous vise donc une refonte **dans le repo existant**, sans imaginer une migration immédiate vers Vue/React.
- Le terme spec `Env` correspond aujourd’hui, dans le code réel, à la page `profiles`.
- Décision réaliste pour l’implémentation : **refondre d’abord la page `profiles` en UI `Env`**, puis ajouter un alias de route/nommage si on veut aligner l’URL et les DTO plus tard.

---

## 1. Cartographie des fichiers actuels

### 1.1 Fichiers shell / routing / structure de page

| Chemin | Rôle actuel | Pages / blocs concernés | Importance | Action recommandée |
|---|---|---|---|---|
| `src/modules/devTools/dev-tools.routes.ts` | Expose la page HTML `/dev/tools/:page` et les assets JS/CSS | toutes pages | central | modifier plus tard seulement si ajout d’un alias `env` |
| `src/modules/devTools/dev-tools.controller.ts` | Sert la page HTML et l’API `/api/dev-tools/overview` | toutes pages | central | laisser tel quel pour la refonte UI |
| `src/modules/devTools/dev-tools.page.ts` | Déclare les ids de pages autorisés et assemble la shell HTML | toutes pages | central | modifier pour ajouter de nouveaux roots de layout et, si choisi, un alias `env` |
| `src/modules/devTools/dev-tools.page.parts.ts` | Construit navigation, topbar, panneaux, modales, scripts | navigation, bandeau global actuel, zones de rendu principales | central | modifier fortement ; meilleur point d’ancrage structurel |

### 1.2 Fichiers UI frontend réellement actifs

| Chemin | Rôle actuel | Pages / blocs concernés | Importance | Action recommandée |
|---|---|---|---|---|
| `shared/dev-tools-ui/dev-tools-shared.js` | État global `app.state`, config de pages, helpers de statuts, tâches, chargement, profils, release | toutes pages | central | modifier fortement ; excellent point de centralisation de la normalisation UI |
| `shared/dev-tools-ui/dev-tools-realtime.js` | Hydrate l’overview via WS / HTTP fallback et applique les snapshots | toutes pages, fraîcheur / reconnexion / fallback | central | modifier pour alimenter fraîcheur globale + pipeline + blocage transverse |
| `shared/dev-tools-ui/dev-tools-renderers.js` | Orchestrateur de rendu principal `renderOverview()` | toutes pages | central | modifier pour insérer le rendu des nouveaux blocs transverses |
| `shared/dev-tools-ui/dev-tools-app.js` | Bootstrap, bindings statiques, actions globales, logique profils, lancement d’actions | toutes pages, modales, interactions haut niveau | central | modifier partiellement ; scinder la logique transverse hors du fichier |
| `shared/dev-tools-ui/dev-tools-overview-page.js` | Rend les pages Build / Deploy / Releases / Database / Profiles et leurs blocs principaux | Build, Déploiement, Releases, Base de données, Env/profiles | central | **scinder** ; fichier actuellement trop volumineux et mélange rendu transverse + pages |
| `shared/dev-tools-ui/dev-tools-runtime-view.js` | Rend la page Runtime : cartes service, détails runtime, investigation avancée | Runtime | central | modifier ; partiellement garder tel quel |
| `shared/dev-tools-ui/dev-tools-runtime.js` | Gère logs, terminal intégré, buffer, resize, fallback | Runtime | secondaire | laisser globalement tel quel, avec ajustements de statuts/labels |
| `shared/dev-tools-ui/dev-tools-command-modal.js` | Rend la modal de suivi de commande et son progress tracking | toutes pages via résultats/actions | secondaire | laisser tel quel au début, harmoniser les microcopies ensuite |
| `shared/dev-tools-ui/dev-tools.css` | Styles de la shell, cartes, runtime, détails, modales | toutes pages | central | modifier fortement pour bandeau, pipeline sticky, cartes primaires/secondaires/expertes |

### 1.3 Fichiers backend qui fabriquent les blocs visibles en UI

| Chemin | Rôle actuel | Pages / blocs concernés | Importance | Action recommandée |
|---|---|---|---|---|
| `src/modules/devTools/dev-tools.service.ts` | Compose tout l’`overview` envoyé au frontend | toutes pages | central | laisser structure générale, ajuster seulement si un nouveau champ transverse manque vraiment |
| `src/modules/devTools/dev-tools.runtime-overview.ts` | Monte le DTO `DevToolsOverviewDto` et les `actions` | toutes pages | central | laisser tel quel dans un premier temps |
| `src/modules/devTools/dev-tools.runtime-realtime.ts` | Construit l’overview et les snapshots temps réel | toutes pages | central | laisser tel quel au lot 1 |
| `src/modules/devTools/dev-tools.runtime-build-summary.ts` | Source du bloc build | Build | secondaire | laisser tel quel sauf si besoin d’un champ pour pipeline |
| `src/modules/devTools/dev-tools.runtime-deploy-summary.ts` | Source du contexte de déploiement | Déploiement, Releases | central | laisser tel quel au début |
| `src/modules/devTools/dev-tools.runtime-deploy-profile-summary.ts` | Source du contexte profil / cible | Déploiement, Runtime, Database, Env | central | garder ; base du bandeau global |
| `src/modules/devTools/dev-tools.runtime-deploy-profile-editor.ts` | Source de la page `profiles` actuelle | Env (future UI) | central | garder ; support de refonte `profiles` → `Env` |
| `src/modules/devTools/dev-tools.runtime-selected-release-summary.ts` | Source du release ciblé et de la preview | Build, Déploiement, Releases, Database | central | garder ; base du pipeline + bandeau global |
| `src/modules/devTools/dev-tools.runtime-remote-database-summary.ts` | Contexte DB cible | Base de données | central | garder |
| `src/modules/devTools/dev-tools.runtime-database-backup-summary.ts` | Diagnostic backup | Base de données | central | garder |
| `src/modules/devTools/dev-tools.runtime-prisma-runtime-summary.ts` | Diagnostic Prisma / migration | Base de données | central | garder |
| `src/modules/devTools/dev-tools.runtime-database-clone-artifact-summary.ts` | Artefact source du flux clone | Base de données | secondaire | garder |
| `src/modules/devTools/dev-tools.runtime-database-clone-target-summary.ts` | Qualification de la cible clone | Base de données | central | garder |
| `src/modules/devTools/dev-tools.runtime-database-clone-restore-summary.ts` | Autorisation / blocages de restauration | Base de données | central | garder |
| `src/modules/devTools/dev-tools.runtime-remote-api-summary.ts` | Contexte runtime API distant | Déploiement, Runtime | central | garder |
| `src/modules/devTools/dev-tools.runtime-api-runtime-diagnostic-summary.ts` | Diagnostic runtime API | Déploiement, Runtime | central | garder |
| `src/modules/devTools/dev-tools.runtime-front-static-host-summary.ts` | Diagnostic vhost/front statique | Runtime | secondaire | garder |
| `src/modules/devTools/dev-tools.runtime-front-api-proxy-summary.ts` | Diagnostic proxy front → API | Runtime | secondaire | garder |
| `src/modules/devTools/dev-tools.runtime-remote-storage-summary.ts` | Diagnostic stockage partagé | Runtime | expert | garder |
| `src/modules/devTools/dev-tools.runtime-release-layout-summary.ts` | Diagnostic activabilité release | Releases | central | garder |
| `src/modules/devTools/dev-tools.deploy-actions.ts` | Définit les actions, leurs pages et leur disponibilité | Build, Déploiement, Releases, Database | central | modifier seulement pour vrai renommage `profiles` → `env` |

### 1.4 Contrats de données partagés

| Chemin | Rôle actuel | Pages / blocs concernés | Importance | Action recommandée |
|---|---|---|---|---|
| `ttm-shared/src/dto/dev-tools.dto.ts` | DTO source de vérité de l’overview, actions, tâches, process | toutes pages | central | modifier plus tard seulement si la refonte nécessite de nouveaux champs ou le renommage `profiles` → `env` |
| `ttm-shared/src/schemas/dev-tools.schema.ts` | Validation des requêtes API devtools | actions / profils / terminal | secondaire | laisser tel quel tant que la refonte reste purement UI |

### 1.5 Identification précise demandée

#### Fichiers qui pilotent la structure globale des pages
- `src/modules/devTools/dev-tools.page.ts`
- `src/modules/devTools/dev-tools.page.parts.ts`
- `shared/dev-tools-ui/dev-tools-renderers.js`
- `shared/dev-tools-ui/dev-tools-shared.js`

#### Fichiers qui pilotent la navigation Devtools
- `src/modules/devTools/dev-tools.page.parts.ts` (`renderDevToolsNavigation()`)
- `shared/dev-tools-ui/dev-tools-overview-page.js` (`configurePageChrome()` active l’onglet courant)
- `src/modules/devTools/dev-tools.page.ts` (liste des pages autorisées)

#### Fichiers qui pilotent les cartes / blocs des pages
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-runtime-view.js`

#### Fichiers qui gèrent états, chargements, résultats, modales et actions
- `shared/dev-tools-ui/dev-tools-shared.js`
- `shared/dev-tools-ui/dev-tools-realtime.js`
- `shared/dev-tools-ui/dev-tools-app.js`
- `shared/dev-tools-ui/dev-tools-command-modal.js`
- `shared/dev-tools-ui/dev-tools-runtime.js`

#### Meilleurs points d’ancrage
- **Bandeau global** : structure dans `src/modules/devTools/dev-tools.page.parts.ts`, calcul des données dans `shared/dev-tools-ui/dev-tools-shared.js`, rendu dans un nouveau renderer dédié.
- **Pipeline transverse** : nouveau root à ajouter dans `src/modules/devTools/dev-tools.page.parts.ts`, calcul dans un nouveau view-model transverse branché sur `shared/dev-tools-ui/dev-tools-shared.js`.
- **Bloc `Prochain pas recommandé`** : nouveau root dans `src/modules/devTools/dev-tools.page.parts.ts`, calcul via un view-model transverse basé sur `overview`, `lastRealtimeEventAt`, diagnostics et tâches récentes.

---

## 2. Mapping spec → code

> Décision de mise en œuvre : dans ce codebase, les “composants frontend” seront des **fonctions de rendu vanilla JS** et non des composants Vue/React.

| Élément de spec | Où l’implémenter dans le code actuel | Fichier principal | Forme recommandée | Choix |
|---|---|---|---|---|
| bandeau global | remplacer le `globalContextBar` actuel par un vrai bandeau 2 lignes transverse | `src/modules/devTools/dev-tools.page.parts.ts` + nouveau renderer dans `shared/dev-tools-ui/` | nouveau root + renderer dédié + helpers de view-model | créer nouveau composant renderer |
| pipeline de promotion | ajouter un root sticky commun sous le bandeau / avant les blocs métier | `src/modules/devTools/dev-tools.page.parts.ts` + nouveau module `shared/dev-tools-ui/` | renderer transverse + calcul centralisé des 7 étapes | créer nouveau composant renderer |
| bloc `Prochain pas recommandé` | ajouter un root de bas de page commun, alimenté par le pipeline et les blocages | `src/modules/devTools/dev-tools.page.parts.ts` + nouveau module `shared/dev-tools-ui/` | carte transverse simple avec CTA | créer nouveau composant renderer |
| Build | repartir de `renderBuildSummary()`, `renderBuildTopbar()`, `renderActions()` | `shared/dev-tools-ui/dev-tools-overview-page.js` | refactor en plusieurs renderers Build | refactorer l’existant |
| Déploiement | repartir de `renderDeploySummary()` | `shared/dev-tools-ui/dev-tools-overview-page.js` | découper flux principal / résultat / suite / expert | refactorer fortement |
| Runtime | repartir de `renderProcesses()`, `renderRuntimeDetails()`, `renderLogsPanel()` | `shared/dev-tools-ui/dev-tools-runtime-view.js` | conserver la base et réordonner visuellement | refactorer l’existant |
| Base de données | extraire la logique actuellement concentrée dans `renderDatabaseSummary()` | `shared/dev-tools-ui/dev-tools-overview-page.js` puis nouveau `shared/dev-tools-ui/dev-tools-database-page.js` | split en page simple + expert accordion | créer nouveau fichier par extraction |
| Releases | repartir de `renderReleasesSummary()` | `shared/dev-tools-ui/dev-tools-overview-page.js` | découper cible / bascule / vérification / résultat / expert | refactorer fortement |
| Env | refondre la page `profiles` actuelle en UI `Env` | `shared/dev-tools-ui/dev-tools-overview-page.js` + `shared/dev-tools-ui/dev-tools-shared.js` + `src/modules/devTools/dev-tools.page.ts` | relabel UI d’abord, renommage technique ensuite | refactorer l’existant |
| états UI normalisés | centraliser les dérivations de statuts visuels | nouveau `shared/dev-tools-ui/dev-tools-view-model.js` ou `dev-tools-status.js` | fonctions de normalisation et mapping vers badges | créer nouveau module |
| règles de désactivation | déplacer les règles dispersées dans un helper unique | `shared/dev-tools-ui/dev-tools-shared.js` + nouveau module transverse | helpers `isPrimaryActionDisabled`, `getBlockingReason`, etc. | refactor + centralisation |
| blocs experts repliés | standardiser l’usage de `<details>` | `shared/dev-tools-ui/dev-tools-overview-page.js`, `shared/dev-tools-ui/dev-tools-runtime-view.js`, `shared/dev-tools-ui/dev-tools.css` | conteneur expert réutilisable | refactorer + composant renderer |

### Choix tranchés

1. **Ne pas migrer vers `ttm-shop-front`** pour cette refonte.
2. **Ne pas changer tout de suite l’API** juste pour le pipeline, le bandeau et le prochain pas : on peut dériver ces informations côté frontend à partir de l’overview existant.
3. **Traiter `Env` comme une refonte de `profiles`** au lot frontend, puis décider ensuite si l’URL/page id doit être renommé.
4. **Extraire la page DB** hors de `dev-tools-overview-page.js` : c’est le meilleur gain structurel immédiat.

---

## 3. Découpage en composants frontend

> Ici, “composant” = fonction de rendu JS + petit contrat d’entrée, compatible avec l’architecture actuelle.

### 3.1 Composants transverses recommandés

| Nom conseillé | Responsabilité | Props attendues | Pages | Nouveau / refactor |
|---|---|---|---|---|
| `renderDevToolsGlobalBanner(viewModel)` | rendre le bandeau global 2 lignes | `{ releaseLabel, remoteCurrentLabel, targetLabel, blockingReason, profileLabel, databaseLabel, freshnessLabel, realtimeLabel, toneByField }` | toutes | nouveau |
| `renderDevToolsPromotionPipeline(viewModel)` | rendre le rail sticky 7 étapes | `{ steps: Array<{ id, label, status, proof, ctaPage? }> }` | Build, Déploiement, Runtime, Base de données, Releases, Env | nouveau |
| `renderDevToolsNextStepCard(viewModel)` | rendre le bloc `Prochain pas recommandé` | `{ actionLabel, reason, ctaLabel, ctaHref, ctaActionId, blocked }` | toutes | nouveau |
| `renderDevToolsUnifiedStatusBadge(input)` | rendre un badge homogène pour tous les blocs | `{ kind, label, tone, detail? }` | toutes | nouveau |
| `renderDevToolsCurrentResultCard(input)` | standardiser le bloc “dernier résultat” | `{ title, task, emptyLabel, openOnFailure }` | toutes | nouveau |
| `renderDevToolsPrimaryActionCard(input)` | standardiser la carte d’action principale | `{ title, description, badge, pills, note, primaryButton, secondaryButtons? }` | Build, Déploiement, Database, Releases, Runtime | nouveau |
| `renderDevToolsExpertSection(input)` | encapsuler un bloc expert repliable | `{ title, description, contentHtml, defaultOpen }` | toutes | nouveau |

### 3.2 Composants / renderers par page

| Nom conseillé | Responsabilité | Props attendues | Pages | Nouveau / refactor |
|---|---|---|---|---|
| `renderBuildPageSections(overview)` | assembler contexte build, actions locales, résultat, expert | `{ overview, tasks, actions }` | Build | refactor |
| `renderDeployPageSections(overview)` | assembler contexte, flux principal, résultat, suite, expert | `{ overview, tasks, actions }` | Déploiement | refactor |
| `renderReleasesPageSections(overview)` | assembler release ciblée, bascule, vérification, résultat, maintenance | `{ overview, tasks, actions }` | Releases | refactor |
| `renderDatabasePageSections(overview)` | assembler version simple DB + expert DB | `{ overview, tasks, actions }` | Base de données | nouveau par extraction |
| `renderEnvPageSections(overview)` | assembler contexte env, actions, guidé, avancé, expert JSON | `{ overview }` | Env (`profiles`) | refactor |
| `renderRuntimePageSections(overview)` | assembler contexte runtime, cartes service, détails, investigation, expert | `{ overview, processes, tasks }` | Runtime | refactor |

### 3.3 Fichier réaliste pour porter ces composants

Choix recommandé :
- créer `shared/dev-tools-ui/dev-tools-layout.js` pour :
  - bandeau global ;
  - pipeline ;
  - prochain pas ;
  - badge unifié ;
  - bloc résultat courant ;
  - section expert.
- créer `shared/dev-tools-ui/dev-tools-view-model.js` pour :
  - dériver les statuts normalisés ;
  - calculer le pipeline ;
  - calculer le prochain pas ;
  - calculer la fraîcheur / reconnexion / fallback ;
  - centraliser les règles de désactivation.
- extraire plus tard la page DB dans `shared/dev-tools-ui/dev-tools-database-page.js`.

Pourquoi ce choix est le plus réaliste :
- il respecte la stack actuelle ;
- il évite de surcharger encore `dev-tools-overview-page.js` ;
- il crée un vrai socle transverse sans toucher immédiatement aux DTO backend.

---

## 4. Ordre d’implémentation recommandé

### Lot 1 : socle transverse

**Fichiers touchés**
- `src/modules/devTools/dev-tools.page.parts.ts`
- `src/modules/devTools/dev-tools.page.ts`
- `shared/dev-tools-ui/dev-tools-renderers.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `shared/dev-tools-ui/dev-tools-realtime.js`
- `shared/dev-tools-ui/dev-tools.css`
- `shared/dev-tools-ui/dev-tools-layout.js` *(nouveau)*
- `shared/dev-tools-ui/dev-tools-view-model.js` *(nouveau)*

**Objectifs**
- ajouter les roots structurels `globalBannerRoot`, `promotionPipelineRoot`, `nextStepRoot` ;
- créer le view-model transverse ;
- rendre le bandeau global, le pipeline et le bloc `Prochain pas recommandé` sur toutes les pages du parcours ;
- normaliser badges, fraîcheur, reconnexion, fallback et blocages globaux.

**Bénéfice produit**
- lisibilité immédiate ;
- parcours transverse visible sans ouvrir plusieurs blocs ;
- base réutilisable pour toutes les pages.

**Risques éventuels**
- casse visuelle du header / sticky ;
- duplication temporaire avec `pageContextSummary` ;
- microcopies incohérentes si la normalisation n’est pas centralisée dès ce lot.

**Dépendances**
- aucune dépendance backend bloquante si le pipeline est dérivé depuis l’overview actuel.

### Lot 2 : pages critiques

**Fichiers touchés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-runtime-view.js`
- `shared/dev-tools-ui/dev-tools-layout.js`
- `shared/dev-tools-ui/dev-tools-view-model.js`
- `shared/dev-tools-ui/dev-tools-database-page.js` *(nouveau)*
- `shared/dev-tools-ui/dev-tools.css`

**Objectifs**
- refondre `Build`, `Déploiement`, `Base de données`, `Releases` en respectant l’ordre des blocs de la spec ;
- faire de `Runtime` une page cohérente avec le même socle transverse ;
- isoler la page DB en version simple + expert.

**Bénéfice produit**
- les pages du pipeline principal deviennent immédiatement opérables ;
- la page DB devient enfin lisible sans perdre le mode expert ;
- les CTA principaux/secondaires deviennent stables.

**Risques éventuels**
- régression sur les boutons si les ids DOM changent ;
- oubli d’un binding `data-run-action-id` ;
- perte de certains détails techniques actuellement noyés dans de gros blocs.

**Dépendances**
- nécessite le lot 1 pour éviter de re-coder bandeau/pipeline/next step dans chaque page.

### Lot 3 : harmonisation finale

**Fichiers touchés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `shared/dev-tools-ui/dev-tools.css`
- `src/modules/devTools/dev-tools.page.ts`
- `src/modules/devTools/dev-tools.page.parts.ts`
- `src/modules/devTools/dev-tools.routes.ts` *(si alias `env`)*
- `src/modules/devTools/dev-tools.deploy-actions.ts` *(si vrai renommage de page)*
- `ttm-shared/src/dto/dev-tools.dto.ts` *(si vrai renommage `profiles` → `env`)*

**Objectifs**
- harmoniser la page `profiles` en `Env` ;
- finaliser les labels exacts de la spec ;
- nettoyer les anciennes zones redondantes (`pageContextSummary`, anciens callouts qui doublonnent le bandeau) ;
- décider si le renommage technique `profiles` → `env` est effectué.

**Bénéfice produit**
- cohérence finale ;
- surface UI compréhensible sans connaissance historique des lots précédents.

**Risques éventuels**
- changement de route / page id plus sensible ;
- impact sur actions et tests si `profiles` devient `env` trop tôt.

**Dépendances**
- dépend des lots 1 et 2.

---

## 5. Quick wins immédiats

### 5.1 Modifications les plus rentables

1. **Ajouter le bandeau global transverse** sans toucher au backend.
2. **Créer un badge d’état unifié** à partir de `app.statusClass()` pour arrêter les variations visuelles page par page.
3. **Ajouter le bloc `Prochain pas recommandé`** même avec une première heuristique simple.
4. **Mettre tous les blocs experts derrière un `<details>` uniforme**.
5. **Aligner les titres / sous-titres exacts de la spec** dans `app.pageConfigs`.

### 5.2 Celles qui améliorent vite la lisibilité

- remplacer le `globalContextBar` actuel par un vrai bandeau 2 lignes ;
- faire apparaître un rail pipeline sticky ;
- sortir le “dernier résultat” en carte dédiée au lieu de le laisser noyé dans les gros panneaux ;
- renommer visuellement `Profils` en `Env` dans la navigation, sans casser encore la route technique.

### 5.3 Celles qui réduisent vite le risque UX

- centraliser les désactivations des CTA principaux ;
- afficher un `Blocage : ...` unique en haut ;
- propager `reconnexion…` / `fallback HTTP` / `données à rafraîchir` de façon uniforme ;
- éviter que les boutons experts ressemblent aux CTA principaux.

### 5.4 Faisables sans grosse refonte structurelle

- mise à jour de `pageConfigs` ;
- nouveau renderer de badge ;
- nouveau renderer de résultat courant ;
- accordéon expert standard ;
- nouveau root `nextStepRoot` tout en bas de `renderDevToolsPanels()`.

---

## 6. Détail page par page

### 6.1 Page `Build`

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-shared.js`
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `src/modules/devTools/dev-tools.page.parts.ts`
- `src/modules/devTools/dev-tools.runtime-build-summary.ts`
- `shared/dev-tools-ui/dev-tools.css`

**Composants à modifier**
- `renderBuildTopbar()`
- `renderBuildSummary()`
- branche `build` de `renderActions()`

**Composants à créer**
- `renderDevToolsCurrentResultCard()`
- `renderDevToolsPrimaryActionCard()`
- `renderBuildPageSections()`

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Build
4. `Contexte du build`
5. `Builds locaux`
6. `Dernier résultat de build`
7. `Build distant API`
8. `Détails du build` (expert)
9. `Prochain pas recommandé`

**CTA principaux / secondaires à corriger**
- principal unique visible : `Build complet`
- secondaires visibles : `Build shared`, `Build API`, `Build front`, `Utiliser dernier local`, `Utiliser current distant`
- expert : `Build API distant`, `Rafraîchir`

**États à normaliser**
- `Prêt` / `Bloqué` sur le bloc principal build ;
- blocage si release vide ;
- `Obsolète` si release ciblée a changé depuis le dernier build.

**Points de vigilance**
- aujourd’hui `renderActions()` affiche plusieurs cartes au même niveau ; il faudra clairement distinguer le CTA principal ;
- `pageContextSummary` ne doit plus être la source principale du contexte Build ;
- conserver les `data-fill-release-name` existants.

### 6.2 Page `Déploiement`

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `src/modules/devTools/dev-tools.page.parts.ts`
- `src/modules/devTools/dev-tools.runtime-deploy-summary.ts`
- `src/modules/devTools/dev-tools.runtime-selected-release-summary.ts`
- `src/modules/devTools/dev-tools.runtime-deploy-profile-summary.ts`

**Composants à modifier**
- `renderDeployTopbar()`
- `renderDeploySummary()`
- branche `deploy` de `renderActions()`

**Composants à créer**
- `renderDeployPageSections()`
- `renderDevToolsCurrentResultCard()`
- `renderDevToolsExpertSection()`

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Déploiement
4. `Contexte de déploiement`
5. `Envoyer la release`
6. `Dernier résultat de déploiement`
7. `Suite logique`
8. `Actions avancées de déploiement` (expert)
9. `Prochain pas recommandé`

**CTA principaux / secondaires à corriger**
- principal unique : `Envoyer la release`
- secondaires : `Vérifier avant envoi`, `Envoyer + finaliser`
- experts : `Sync seul`, `Finaliser seul`, détails techniques

**États à normaliser**
- `Bloqué` si release non prête, cible incohérente, dry-run bloquant ;
- `En cours` si `deploy-sync-prepare` ou action liée est pending ;
- `Prêt` si contexte release + cible + runtime sont cohérents.

**Points de vigilance**
- `renderDeploySummary()` mélange actuellement flux principal, contexte, runtime API, release ciblé et détails secondaires ;
- ne pas casser les listeners existants `data-run-action-id`, `data-switch-profile-name`, `data-fill-release-name` ;
- éviter de laisser le diagnostic runtime devenir visuellement principal.

### 6.3 Page `Runtime`

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-runtime-view.js`
- `shared/dev-tools-ui/dev-tools-runtime.js`
- `shared/dev-tools-ui/dev-tools-realtime.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `src/modules/devTools/dev-tools.runtime-remote-api-summary.ts`
- `src/modules/devTools/dev-tools.runtime-api-runtime-diagnostic-summary.ts`
- `src/modules/devTools/dev-tools.runtime-front-static-host-summary.ts`
- `src/modules/devTools/dev-tools.runtime-front-api-proxy-summary.ts`
- `src/modules/devTools/dev-tools.runtime-remote-storage-summary.ts`

**Composants à modifier**
- `renderProcesses()`
- `renderRuntimeDetails()`
- `renderLogsPanel()`
- `getRuntimeRealtimeStatus()`

**Composants à créer**
- `renderRuntimePageSections()`
- `renderDevToolsCurrentResultCard()` pour le résultat courant service/action
- `renderDevToolsExpertSection()` pour maintenance avancée

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Runtime
4. `Contexte runtime`
5. `Pilotage runtime`
6. `État détaillé runtime`
7. `Investigation avancée`
8. `Maintenance runtime avancée` (expert)
9. `Prochain pas recommandé`

**CTA principaux / secondaires à corriger**
- principal unique par carte service : `Vérifier`
- secondaires : `Démarrer`, `Arrêter`, `Redémarrer`
- experts : terminal, logs, diagnostics structurels

**États à normaliser**
- `reconnexion…`, `fallback HTTP`, `données à rafraîchir` ;
- `Bloqué` si profil/cible incohérents ;
- `Obsolète` si les checks ne sont plus frais.

**Points de vigilance**
- ne pas dégrader la console xterm ;
- conserver la logique de `selectedLogsProcessKey` ;
- la page Runtime a déjà une bonne séparation primaire / secondaire / expert : il faut surtout la rendre cohérente avec le socle transverse.

### 6.4 Page `Base de données`

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `src/modules/devTools/dev-tools.runtime-remote-database-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-backup-summary.ts`
- `src/modules/devTools/dev-tools.runtime-prisma-runtime-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-artifact-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-target-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-restore-summary.ts`

**Composants à modifier**
- `renderDatabaseSummary()`
- branche `database` de `renderActions()`

**Composants à créer**
- `shared/dev-tools-ui/dev-tools-database-page.js`
- `renderDatabasePageSections()`
- `renderDatabaseSimpleCards()`
- `renderDatabaseExpertSection()`

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Base de données
4. `Contexte DB cible`
5. `Diagnostic DB`
6. `Sécurité / Backup`
7. `Migration du release`
8. `Dernier résultat DB`
9. `Préparer une base non-prod`
10. `Prochain pas recommandé`
11. `Mode expert DB`

**CTA principaux / secondaires à corriger**
- principal unique : `Migrer le release`
- secondaires : `Tester la connexion`, `Créer un backup`, `Préparer la base non-prod`
- experts : `Restaurer une base cible`, setup DB, maintenance DB

**États à normaliser**
- `Bloqué` si DB non confirmée / release inconnu / diagnostic critique ;
- `Warning` si backup pas récent ;
- `Prêt` si connexion + Prisma + backup acceptable.

**Points de vigilance**
- la page actuelle mélange simple, clone, maintenance, contexte technique et résultats ;
- les ids de boutons DB sont nombreux et déjà bindés explicitement ;
- il ne faut pas rendre la restauration plus proéminente que la migration canonique.

### 6.5 Page `Releases`

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `src/modules/devTools/dev-tools.runtime-release-layout-summary.ts`
- `src/modules/devTools/dev-tools.runtime-selected-release-summary.ts`
- `src/modules/devTools/dev-tools.runtime-deploy-summary.ts`

**Composants à modifier**
- `renderReleasesTopbar()`
- `renderReleasesSummary()`
- branche `releases` de `renderActions()`

**Composants à créer**
- `renderReleasesPageSections()`
- `renderDevToolsCurrentResultCard()`
- `renderDevToolsExpertSection()`

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Releases
4. `Release ciblée`
5. `Bascule du release`
6. `Vérification d’activation`
7. `Dernier résultat de bascule`
8. `Maintenance release`
9. `Détails techniques release` (expert)
10. `Prochain pas recommandé`

**CTA principaux / secondaires à corriger**
- principal : `Activer ce release`
- secondaire : `Revenir au release précédent`, `Vérifier la présence du release`
- expert : `Activer + smoke`, `Nettoyer les anciens releases`, preview

**États à normaliser**
- `Bloqué` si release absent côté distant ou diagnostic critique ;
- `Prêt` si layout OK et release activable ;
- `Obsolète` si cible/release a changé depuis le dernier diagnostic.

**Points de vigilance**
- `renderReleasesSummary()` est déjà proche de la cible ;
- attention à ne pas enterrer le diagnostic de layout s’il reste nécessaire avant activation ;
- le bloc preview doit rester secondaire.

### 6.6 Page `Env` (refonte de `profiles`)

**Fichiers existants concernés**
- `shared/dev-tools-ui/dev-tools-overview-page.js`
- `shared/dev-tools-ui/dev-tools-app.js`
- `shared/dev-tools-ui/dev-tools-shared.js`
- `src/modules/devTools/dev-tools.page.ts`
- `src/modules/devTools/dev-tools.page.parts.ts`
- `src/modules/devTools/dev-tools.runtime-deploy-profile-editor.ts`
- `src/modules/devTools/dev-tools.runtime-deploy-profile-summary.ts`

**Composants à modifier**
- `pageConfigs.profiles`
- `renderProfilesEditor()`
- navigation `Profils`
- logique de sélection / duplication / ouverture / sauvegarde

**Composants à créer**
- `renderEnvPageSections()`
- `renderEnvContextCard()`
- `renderEnvGuidedFormSection()`
- `renderEnvAdvancedSection()`
- `renderEnvExpertJsonSection()`

**Logique d’ordre des blocs à ajuster**
1. bandeau global
2. pipeline
3. header Env
4. `Environnement courant`
5. `Actions d’environnement`
6. `Configuration guidée`
7. `Configuration avancée`
8. `Mode expert JSON`
9. `Prochain pas recommandé`

**CTA principaux / secondaires à corriger**
- principal : `Enregistrer`
- secondaires : `Ouvrir`, `Créer`, `Dupliquer`, `Activer cet environnement`
- experts : `Mode expert JSON`, `Voir les couches`

**États à normaliser**
- validation formulaire / JSON ;
- sauvegarde en cours ;
- brouillon vs existant ;
- couche `base` vs `local-override`.

**Points de vigilance**
- le backend et les DTO parlent encore de `profiles` ;
- le guided form actuel est riche : le bon plan est de **reclasser** visuellement avant de réinventer ;
- ne pas casser l’autosave déjà présent tant qu’il n’est pas explicitement retiré.

---

## 7. Focus spécial Base de données

### 7.1 Fichiers actuels impliqués

Frontend :
- `shared/dev-tools-ui/dev-tools-overview-page.js` (`renderDatabaseSummary()`)
- `shared/dev-tools-ui/dev-tools-shared.js`
- `shared/dev-tools-ui/dev-tools.css`
- `src/modules/devTools/dev-tools.page.parts.ts`

Backend / données :
- `src/modules/devTools/dev-tools.runtime-remote-database-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-backup-summary.ts`
- `src/modules/devTools/dev-tools.runtime-prisma-runtime-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-artifact-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-target-summary.ts`
- `src/modules/devTools/dev-tools.runtime-database-clone-restore-summary.ts`
- `src/modules/devTools/dev-tools.service.ts`

### 7.2 Quoi garder

À garder quasiment tel quel côté données :
- `databaseSummary`
- `databaseBackupDiagnosticSummary`
- `prismaRuntimeDiagnosticSummary`
- `databaseCloneArtifactSummary`
- `databaseCloneTargetSummary`
- `databaseCloneRestoreSummary`

À garder côté UI :
- la logique de bouton existante par id ;
- le découpage sécurité / backup / migration déjà présent dans les données ;
- la hiérarchie de sécurité prod/non-prod déjà embarquée.

### 7.3 Quoi scinder

Le `renderDatabaseSummary()` actuel doit être scindé en sous-renderers :

1. `renderDatabaseTargetContext()`
2. `renderDatabaseDiagnosticCard()`
3. `renderDatabaseBackupCard()`
4. `renderDatabaseMigrationCard()`
5. `renderDatabaseCurrentResultCard()`
6. `renderDatabaseNonProdPrepCard()`
7. `renderDatabaseExpertAccordion()`

Décision réaliste : extraire ces fonctions dans `shared/dev-tools-ui/dev-tools-database-page.js` et garder dans `dev-tools-overview-page.js` seulement l’appel d’orchestration.

### 7.4 Quoi passer en expert replié

À mettre dans `Mode expert DB` fermé par défaut :
- clonage avancé détaillé ;
- restauration DB explicite ;
- artefacts d’export détaillés ;
- setup DB (`database-install-defaults-extra-file`, `database-prepare-backup-directory`) ;
- maintenance DB et résultats techniques détaillés ;
- contexte technique réel d’accès DB.

### 7.5 Implémentation concrète version simple + expert

#### Version simple
Afficher au premier niveau uniquement :
- `Contexte DB cible`
- `Diagnostic DB`
- `Sécurité / Backup`
- `Migration du release`
- `Dernier résultat DB`
- `Préparer une base non-prod`
- `Prochain pas recommandé`

#### Version expert
Sous un seul accordéon :
- `Clonage avancé`
- `Restauration DB`
- `Artefacts d’export`
- `Setup DB`
- `Maintenance DB`
- résultats bruts détaillés

### 7.6 Risques de régression à surveiller

- perdre un binding sur `databaseCloneReadTargetButton`, `databaseCloneRestoreButton`, `databaseRunBackupButton`, `databaseMigrateReleaseButton` ;
- rendre la restauration trop visible par rapport au chemin canonique `database-migrate-release` ;
- casser la logique de protection non-prod ;
- changer l’ordre des tâches “résultat récent” et afficher le mauvais dernier résultat.

---

## 8. États UI et source de vérité

### 8.1 Où sont gérés les états actuels

**Source frontend principale**
- `shared/dev-tools-ui/dev-tools-shared.js` via `app.state`

**Hydratation / fraîcheur / fallback**
- `shared/dev-tools-ui/dev-tools-realtime.js`

**États d’action et interactions**
- `shared/dev-tools-ui/dev-tools-app.js`
- `shared/dev-tools-ui/dev-tools-runtime.js`

**Mapping brut de statuts**
- `shared/dev-tools-ui/dev-tools-shared.js`
  - `app.statusClass()`
  - `app.taskStatusLabel()`
  - `app.getRuntimeRealtimeStatus()`
  - `app.getRuntimeOverviewSummary()`

**Source backend de vérité métier**
- `src/modules/devTools/dev-tools.service.ts`
- `src/modules/devTools/dev-tools.runtime-overview.ts`
- `ttm-shared/src/dto/dev-tools.dto.ts`

### 8.2 Où naissent les incohérences possibles

1. **Statuts visuels calculés localement page par page**
   - `renderBuildTopbar()`, `renderDeployTopbar()`, `renderReleasesTopbar()`, `renderDatabaseTopbar()`, `renderRuntimeTopbar()` fabriquent chacun leur propre `stateLabel`.
2. **Règles de désactivation dispersées**
   - `app.getBuildActionBlockReason()` ne couvre que le build ;
   - `renderDatabaseSummary()` désactive directement plusieurs boutons ;
   - `renderProcesses()` a sa propre logique service par service.
3. **Fraîcheur non normalisée transversalement**
   - le runtime sait dire `Temps réel actif` / `Reconnexion…` / `Mode fallback`,
   - mais pas le reste des pages.
4. **Mismatch entre statuts métier DTO et statuts UX de la spec**
   - DTO : `running`, `failed`, `warn`, `not-configured`, `degraded`, etc.
   - spec : `Prêt`, `Bloqué`, `Obsolète`, `En cours`, `Non requis`, etc.

### 8.3 Où centraliser la normalisation des statuts

Choix recommandé : **nouveau fichier `shared/dev-tools-ui/dev-tools-view-model.js`**.

Il doit contenir :
- `getGlobalBannerViewModel(overview, state)`
- `getPipelineViewModel(overview, state)`
- `getNextStepViewModel(currentPage, overview, state)`
- `normalizeUiTone(input)` → `normal | warning | critique`
- `normalizeStepStatus(input)` → `Non commencé | En cours | Prêt | Bloqué | Obsolète | Non requis`
- `getFreshnessState(input)`
- `getBlockingReason(input)`
- `isSensitiveActionAllowed(input)`

### 8.4 Implémentation propre demandée

#### `normal / warning / critique`
- `normal` : pas de blocage, données fraîches, diagnostic OK ou acceptable
- `warning` : reconnecting, fallback HTTP, donnée obsolète, diagnostic incomplet
- `critique` : incohérence structurelle, cible invalide, DB non qualifiée, release absente côté distant

#### `prêt / bloqué / obsolète / en cours`
- `Prêt` : tous les prérequis métier de l’action sont satisfaits
- `Bloqué` : au moins un prérequis critique manque
- `Obsolète` : preuve existante mais invalidée par changement de release / profil / cible
- `En cours` : action ou vérification associée toujours pending

#### `fraîcheur / reconnexion / fallback`
- calculé à partir de :
  - `app.state.realtimeConnected`
  - `app.state.lastRealtimeEventAt`
  - les timestamps métier (`checkedAt`, `lastCheckAt`, `preparedAt`, etc.)
- règles réalistes :
  - socket absent → `fallback HTTP`
  - socket présent mais disconnected → `reconnexion…`
  - dernière mise à jour trop ancienne → `données à rafraîchir`
  - sinon `vérifié il y a X s`

---

## 9. Plan de tickets frontend

### Ticket 1 — Ajouter les roots transverses de layout Devtools
- **Objectif** : préparer la shell pour le bandeau global, le pipeline et le prochain pas.
- **Fichiers principaux** :
  - `src/modules/devTools/dev-tools.page.parts.ts`
  - `src/modules/devTools/dev-tools.page.ts`
- **Dépendances** : aucune
- **Complexité estimée** : S
- **Résultat visible attendu** : trois nouveaux emplacements stables dans toutes les pages.

### Ticket 2 — Créer le view-model transverse Devtools
- **Objectif** : centraliser bandeau global, pipeline, prochain pas, fraîcheur et blocages.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-view-model.js` *(nouveau)*
  - `shared/dev-tools-ui/dev-tools-shared.js`
  - `shared/dev-tools-ui/dev-tools-realtime.js`
- **Dépendances** : ticket 1
- **Complexité estimée** : M
- **Résultat visible attendu** : les mêmes règles de statuts s’appliquent à toutes les pages.

### Ticket 3 — Créer les renderers UI transverses
- **Objectif** : rendre visuellement bandeau global, pipeline sticky, bloc prochain pas, badge unifié et conteneur expert.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-layout.js` *(nouveau)*
  - `shared/dev-tools-ui/dev-tools-renderers.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 1 et 2
- **Complexité estimée** : M
- **Résultat visible attendu** : le socle transverse spec apparaît partout.

### Ticket 4 — Refonte page Build selon la spec
- **Objectif** : distinguer contexte, CTA principal, résultat courant, secondaire, expert, prochain pas.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools-layout.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : M
- **Résultat visible attendu** : page Build lisible avec un seul CTA principal visible.

### Ticket 5 — Refonte page Déploiement selon la spec
- **Objectif** : remettre le flux principal au centre et pousser l’expert dans un accordéon.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools-layout.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : M
- **Résultat visible attendu** : page Déploiement structurée en contexte → action principale → résultat → suite → expert.

### Ticket 6 — Extraire la page Base de données dans un renderer dédié
- **Objectif** : sortir la logique DB monolithique de `dev-tools-overview-page.js`.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-database-page.js` *(nouveau)*
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : L
- **Résultat visible attendu** : code DB maintenable et structure simple/expert alignée sur la spec.

### Ticket 7 — Refonte page Base de données simple + expert
- **Objectif** : exposer clairement `Diagnostic DB`, `Sécurité / Backup`, `Migration du release`, `Préparer une base non-prod`, puis `Mode expert DB`.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-database-page.js`
  - `shared/dev-tools-ui/dev-tools-layout.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : ticket 6
- **Complexité estimée** : L
- **Résultat visible attendu** : page DB opérable sans lecture technique exhaustive.

### Ticket 8 — Refonte page Releases selon la spec
- **Objectif** : clarifier `Release ciblée`, `Bascule`, `Vérification d’activation`, `Résultat`, `Maintenance`, `Expert`.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools-layout.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : M
- **Résultat visible attendu** : la page Releases devient directement actionnable.

### Ticket 9 — Harmoniser la page Runtime avec le socle transverse
- **Objectif** : aligner Runtime sur l’ordre spec sans casser logs/terminal.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-runtime-view.js`
  - `shared/dev-tools-ui/dev-tools-runtime.js`
  - `shared/dev-tools-ui/dev-tools-layout.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : M
- **Résultat visible attendu** : runtime cohérent avec bandeau, pipeline, prochain pas et séparation primaire/secondaire/expert.

### Ticket 10 — Refondre `profiles` en UI `Env`
- **Objectif** : reclasser la page actuelle `profiles` selon la spec `Env`.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools-app.js`
  - `shared/dev-tools-ui/dev-tools-shared.js`
  - `shared/dev-tools-ui/dev-tools.css`
- **Dépendances** : tickets 2 et 3
- **Complexité estimée** : L
- **Résultat visible attendu** : page `Env` utilisable sans exposer d’emblée le JSON expert.

### Ticket 11 — Renommage technique optionnel `profiles` → `env`
- **Objectif** : aligner routes, ids de page et DTO avec la terminologie UI finale.
- **Fichiers principaux** :
  - `src/modules/devTools/dev-tools.page.ts`
  - `src/modules/devTools/dev-tools.page.parts.ts`
  - `src/modules/devTools/dev-tools.routes.ts`
  - `src/modules/devTools/dev-tools.deploy-actions.ts`
  - `ttm-shared/src/dto/dev-tools.dto.ts`
- **Dépendances** : ticket 10
- **Complexité estimée** : M
- **Résultat visible attendu** : URL et navigation cohérentes avec la spec `Env`.

### Ticket 12 — Durcir les règles de désactivation et la propagation des blocages
- **Objectif** : empêcher toute action sensible active en état `Bloqué`.
- **Fichiers principaux** :
  - `shared/dev-tools-ui/dev-tools-view-model.js`
  - `shared/dev-tools-ui/dev-tools-shared.js`
  - `shared/dev-tools-ui/dev-tools-overview-page.js`
  - `shared/dev-tools-ui/dev-tools-runtime-view.js`
- **Dépendances** : tickets 2 à 10
- **Complexité estimée** : M
- **Résultat visible attendu** : les CTA principaux suivent enfin des règles stables et prédictibles.

---

## 10. Conclusion opérable

### Les 5 premiers tickets à faire

1. **Ajouter les roots transverses de layout Devtools**
2. **Créer le view-model transverse Devtools**
3. **Créer les renderers UI transverses**
4. **Refonte page Déploiement selon la spec**
5. **Extraire puis refondre la page Base de données**

### Meilleur ordre réel d’exécution

1. ticket 1 — roots structurels
2. ticket 2 — normalisation / bandeau / pipeline / prochain pas
3. ticket 3 — renderers + CSS transverse
4. ticket 5 — Déploiement
5. ticket 6 — extraction DB
6. ticket 7 — DB simple + expert
7. ticket 8 — Releases
8. ticket 4 — Build
9. ticket 9 — Runtime
10. ticket 10 — Env (`profiles` refondu)
11. ticket 12 — durcissement global des désactivations
12. ticket 11 — renommage technique optionnel `profiles` → `env`

### Points où il faut être prudent pour éviter de casser l’UI actuelle

1. **Ne pas changer les ids DOM existants tant que les bindings JS n’ont pas été migrés**.
   - Exemple : boutons DB / terminal / modales.
2. **Ne pas renommer immédiatement `profiles` en `env` au niveau backend**.
   - Faire d’abord le renommage visuel UI.
3. **Ne pas déplacer la logique xterm/logs hors de `dev-tools-runtime.js` au début**.
   - Cette zone fonctionne et est sensible.
4. **Ne pas disperser la normalisation des statuts dans chaque renderer**.
   - Le view-model transverse doit être la seule porte d’entrée.
5. **Ne pas rendre les blocs experts visibles par défaut**.
   - La spec impose leur repli systématique.

### Décision finale recommandée

Le plan le plus réaliste est :
- construire d’abord un **socle transverse** dans la shell actuelle ;
- refondre ensuite les pages du pipeline principal (`Déploiement`, `Base de données`, `Releases`, puis `Build`) ;
- traiter `Runtime` et `Env` sans changer de stack ;
- ne faire le renommage technique `profiles` → `env` qu’en fin de chaîne, si nécessaire.