# Lot 3 — Refonte UI Runtime

> 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 une refonte UI antérieure à l’extraction du `dev-tools` vers `ttm-dev-tools`. À utiliser seulement comme contexte d’archive.

## Objectif
- Recentrer la page `Runtime` sur le contrôle et le diagnostic opérationnel de l’environnement courant.
- Rendre immédiatement lisible la distinction entre `socle local` et `couche distante liée au profil courant`.
- Mettre les actions runtime de base (`vérifier`, `start`, `stop`, `restart`) au cœur normal de la page.
- Garder `console / logs / terminal` en secondaire.
- Reléguer clairement la maintenance runtime avancée (`vhost`, `proxy`, `ports`, `setup`, corrections structurelles) sans supprimer les capacités déjà présentes.

## Contrat produit de référence de la page Runtime
- `Build` fabrique.
- `Deploy` pousse / finalise minimalement / confirme.
- `Database` migre explicitement si nécessaire.
- `Runtime` contrôle et diagnostique si utile.
- `Env` configure.
- `Releases` gère la vie d’un release déjà présent côté cible.
- `Runtime` ne build pas.
- `Runtime` ne déploie pas.
- `Runtime` n’active pas un release.
- `Runtime` ne migre pas la base.
- `Runtime` ne configure pas l’environnement.
- `Runtime` n’est pas une console admin générique.

## Lecture cible
1. quel profil runtime est visé ;
2. quels services locaux sont présents et dans quel état ;
3. quels services distants du profil sont présents et dans quel état ;
4. quelles actions runtime de base sont disponibles ;
5. quels détails runtime utiles permettent de relire l’état ;
6. puis seulement la console, les logs et la maintenance avancée.

## Structure finale validée
1. `Runtime`
   - titre + sous-titre courts ;
   - contexte compact : profil, cible runtime, socle local, couche distante, état.
2. `Pilotage runtime normal`
   - `Socle local` visible quel que soit le profil ;
   - `Couche distante du profil courant` distincte mais légère ;
   - actions runtime de base au premier plan sur les cartes.
3. `Détails runtime utiles`
   - endpoint / health / dernière vérification / PID / raison lisible ;
   - visibles en soutien, sans devenir le centre de gravité.
4. `Console / logs / terminal`
   - bloc secondaire d’investigation ;
   - pas le cœur initial de lecture.
5. `Maintenance runtime avancée`
   - vhost, proxy, stockage partagé, setup, corrections structurelles ;
   - replié / secondaire.

## Ce qui doit rester visible par défaut
- le titre `Runtime` ;
- le sous-titre orienté contrôle / diagnostic ;
- le sélecteur de profil ;
- le contexte runtime compact ;
- les cartes du socle local ;
- les cartes de la couche distante du profil ;
- les actions runtime de base ;
- le dernier état utile par service.

## Ce qui doit passer en secondaire
- les détails techniques de service ;
- la console et le terminal ;
- les diagnostics structurels du front statique ;
- les opérations de réinstallation / correction.

## Ce qui doit être clairement relégué
- l’installation / mise à jour de vhost ;
- les diagnostics proxy et stockage ;
- les guides de remédiation avancée ;
- les réglages structurels de runtime.

## Séquence d’implémentation
1. poser le contexte runtime compact en haut de page ;
2. clarifier la lecture `socle local` puis `couche distante` ;
3. faire remonter les actions runtime de base sur les cartes ;
4. faire passer les détails runtime en soutien ;
5. reléguer `console / logs / terminal` ;
6. reléguer explicitement la maintenance runtime avancée.

## Contraintes à ne pas casser
- aucune feature nouvelle ;
- aucun refacto backend ;
- aucun changement métier ;
- aucune logique implicite ;
- aucune confusion avec `Build`, `Deploy`, `Database`, `Releases` ou `Env` ;
- pas de dashboard surconçu ;
- pas de deux gros panneaux massifs local / distant ;
- pas de console comme centre de gravité ;
- pas de setup runtime lourd au premier plan ;
- le pattern transverse des chargements explicites reste respecté.

## Complément du 2026-04-04 — Correctif de cohérence de profil runtime
- Les actions runtime distantes de l’API doivent désormais dériver **en priorité** de la configuration normalisée du profil actif (`deploy.targets.json` + override local), puis seulement des fallbacks d’environnement.
- Ce correctif évite les mélanges `test` / `production` observés sur `Runtime`, où le démarrage pouvait viser la stack production tout en gardant le `composeService` `node-docker` du profil test.
- La carte `API distante` affiche maintenant le **workdir applicatif réel** (`current/TTM_API`) au lieu d’un `stackDir` générique, afin de refléter le runtime effectivement piloté.

### État validé après correctif
- `test` : le contrôle runtime reste cohérent ; `Vérifier l’API distante` retourne bien un statut `running` sur `node-docker` avec port `8089`.
- `production` : `Lancer l’API distante` vise maintenant correctement le service `stackpos-api` (et non plus `node-docker`).
- `production` reste néanmoins **dégradé côté cible** : la vérification remonte encore `stackpos-prod-api` en `Restarting (1)` et la health `http://pluma-preprod.com:3010/health` ne répond pas depuis ce poste. Le blocage restant est donc environnemental / runtime distant, plus un mélange de profil dans l’UI ou les commandes générées.

### Chaîne de diagnostic production observée
1. panne initiale : le runtime actif chargeait `ttm-shared/dist/...` sans dépendance `zod` résolue côté release ;
2. hotfix de terrain appliqué sur le release courant : lien symbolique `ttm-shared/node_modules/zod -> ../../TTM_API/node_modules/zod` ;
3. panne suivante révélée : le release actif importe encore `node-pty` au boot via `dev-tools.service.ts`, ce qui casse le conteneur Linux sur `pty.node` absent ;
4. correctif source prêt localement : chargement paresseux du terminal manager seulement quand les dev-tools sont réellement activés ;
5. conséquence : pour assainir complètement `production`, il faut republier / préparer / activer un release contenant ce correctif source, car le release actif `20260404-000209` exécute encore l’ancienne version.