# Lot 3 — Refonte UI Releases

> 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
- Redonner à la page `Releases` un centre de gravité unique.
- Faire lire immédiatement la page comme : release visé, activable ou non, action de bascule, résultat.
- Réduire fortement la concurrence visuelle de `Profils`, `Runtime`, de la preview détaillée et des détails techniques.
- Ne rien changer au métier, aux actions disponibles, au backend ni aux séparations de responsabilités déjà validées.

## Contrat produit de référence de la page Releases
- `Build` fabrique les artefacts d’un release.
- `Deploy` pousse une release déjà prête, finalise minimalement si nécessaire, puis confirme le résultat.
- `Database` migre explicitement si nécessaire.
- `Runtime` contrôle ou diagnostique si utile.
- `Env` configure.
- `Releases` gère la vie d’un release déjà présent côté cible :
  1. identifier quel release est visé ;
  2. vérifier s’il est réellement activable ;
  3. basculer `current` vers ce release, ou revenir au précédent ;
  4. confirmer le résultat utile ;
  5. éventuellement nettoyer les anciens releases.
- `Releases` n’est pas une page `Build`.
- `Releases` n’est pas une page `Deploy`.
- `Releases` n’est pas une page `Database`.
- `Releases` n’est pas une page `Runtime`.
- `Releases` n’est pas une page `Env`.
- `Releases` n’est pas une page d’audit technique large.
- Dans sa lecture la plus simple, `Releases` doit d’abord répondre à :
  1. quel release je vise ;
  2. est-il activable ;
  3. quelle action de bascule je peux lancer ;
  4. quel est le résultat ;
  5. si besoin, quel nettoyage reste disponible.

## Structure finale validée
1. `Releases`
   - titre + sous-titre court ;
   - contexte minimal `Release visé / Profil / État` ;
   - contrôles strictement utiles au ciblage du release.
2. `Release ciblé`
   - lecture compacte du release réellement visé ;
   - raccourcis utiles de sélection.
3. `Bascule du release`
   - `Activate` ;
   - `Rollback` ;
   - résultat utile directement rattaché.
4. `Diagnostic de layout`
   - bloc secondaire mais proche du cœur ;
   - sert à confirmer l’activabilité réelle avant bascule.
5. `Maintenance release`
   - `Cleanup releases` ;
   - preview éventuelle si elle reste utile.
6. `Secondaire / replié`
   - détails techniques ;
   - preview détaillée ;
   - profils détaillés ;
   - runtime ;
   - manifeste / projets / chemins complets.

## Renommages validés
- `Activation / releases` → `Releases`
- `Release sélectionné` → `Release ciblé`
- titre générique `Actions` sur la page `Releases` → remplacé par un titre orienté usage (`Bascule du release` ou équivalent de même niveau)
- groupe `Déploiement` dans les actions de la page `Releases` → supprimé comme vocabulaire de premier niveau sur cette page
- `Détail status CLI` → rétrogradé en détail technique secondaire
- `Runtime applicatif` sur `Releases` → ne doit plus exister comme bloc principal de page
- `Profils de déploiement` sur `Releases` → ne doit plus exister comme bloc principal de page

## Ce qui doit rester visible par défaut
- le titre `Releases` et un sous-titre court orienté action ;
- le release réellement visé ;
- le profil effectif seulement comme contexte minimal ;
- un état utile court : release résolu / current / rollback disponible / diagnostic à faire ou OK ;
- les raccourcis utiles de sélection de release (`current`, `dernier local`) si disponibles ;
- les actions principales de bascule :
  - `Activate` ;
  - `Rollback` ;
- le résultat utile le plus récent des actions principales ;
- le diagnostic de layout sous forme compacte ;
- l’action `Cleanup releases`, mais clairement secondaire par rapport à la bascule.

## Ce qui doit passer en secondaire / replié
- les détails complets du release ciblé ;
- le manifeste local ;
- les projets détaillés (`shared`, `api`, `front`) ;
- les chemins complets locaux et distants ;
- les détails preview ;
- le détail CLI / JSON brut ;
- les informations complètes de profil ;
- les informations runtime détaillées ;
- les remédiations longues ;
- les explications techniques longues.

## Ce qui doit sortir du premier niveau de lecture
- le bloc complet `Profils de déploiement` ;
- le bloc complet `Runtime applicatif` ;
- les guides de remédiation runtime ;
- les détails de configuration de profil ;
- les détails de santé runtime ;
- les détails preview Apache / VHost / DocumentRoot ;
- les cartes projet par projet du release ;
- les chemins techniques complets ;
- le JSON brut / status CLI détaillé ;
- toute lecture qui fait dériver la page vers `Deploy`, `Runtime`, `Env` ou un audit technique large.

## Zone haute cible
- Titre : `Releases`
- Sous-titre : `Bascule un release déjà présent sur la cible, puis relis le résultat.`
- Une seule zone haute.
- Ordre attendu :
  1. titre ;
  2. sous-titre ;
  3. `Release visé` ;
  4. `Profil` ;
  5. `État` ;
  6. champ `Nom du release` ;
  7. raccourcis `Utiliser current` / `Utiliser dernier local` si disponibles.
- La zone haute ne doit pas raconter le runtime, les profils détaillés, la preview détaillée, le manifeste, les projets ni les diagnostics techniques longs.
- `Projets ciblés` n’a pas vocation à rester un contrôle fort de cette zone sur `Releases` ; il parasite la lecture principale de bascule.

## Bloc principal cible
- Le bloc principal doit être un bloc de pilotage de bascule, pas un panneau d’inspection riche.
- Il doit rendre évident :
  1. quel release est prêt à être basculé ;
  2. si l’activation est possible ;
  3. quelle action principale cliquer ;
  4. comment revenir en arrière ;
  5. ce qu’il s’est passé au dernier run.
- Le bloc principal doit être visuellement plus fort que tout le reste.
- Sa lecture cible :
  - `Activate` comme action principale de bascule vers le release visé ;
  - `Rollback` comme action de retour ;
  - résultat directement visible juste dessous.
- `Cleanup` ne doit pas concurrencer ce bloc.

## Place du diagnostic de layout
- Le diagnostic de layout est l’étape de validation la plus proche du cœur de la page, mais ce n’est pas lui la finalité.
- Il doit être visible sans être plus fort que l’action de bascule.
- Il doit répondre simplement à : `ce release est-il réellement prêt pour une bascule ?`
- Il ne doit pas être dupliqué lourdement : pas un gros bloc riche + une carte d’action de même importance + des rappels multiples.
- Sa restitution cible :
  - statut global ;
  - release diagnostiqué ;
  - nombre d’erreurs et d’avertissements ;
  - horodatage ;
  - remédiation prioritaire courte si utile.
- Les détails complets de diagnostic doivent être secondaires.

## Place de l’activation / rollback / cleanup
- `Activate` et `Rollback` forment le cœur opératoire de la page.
- `Activate` doit être l’action principale.
- `Rollback` doit rester immédiatement accessible, mais visuellement secondaire à `Activate`.
- `Cleanup releases` est une action de maintenance :
  - légitime sur la page ;
  - mais secondaire ;
  - jamais au même rang que `Activate` / `Rollback`.
- `Activate + smoke` ne doit pas devenir le centre de la page si cela brouille la lecture de base. La lecture prioritaire reste `bascule puis résultat`.
- Le résultat utile doit être rattaché directement aux actions de bascule, pas noyé dans un autre panneau.

## Place éventuelle de la preview
- La preview peut rester rattachée à `Releases`, car elle concerne un release donné.
- Mais elle ne doit pas faire dévier la page vers un sous-produit à part entière.
- Elle doit être :
  - secondaire ;
  - compacte ;
  - idéalement repliée ou intégrée à une zone de maintenance release.
- Elle ne doit pas concurrencer le ciblage du release, le diagnostic de layout ni `Activate` / `Rollback`.
- Ses détails techniques complets doivent sortir du premier niveau de lecture.

## Place des profils / runtime / détails techniques
- `Profils` n’est pas le sujet central de `Releases`.
- `Runtime` n’est pas le sujet central de `Releases`.
- Les détails techniques ne sont pas le sujet central de `Releases`.
- Donc :
  - aucun bloc `Profils de déploiement` de premier niveau ;
  - aucun bloc `Runtime applicatif` de premier niveau ;
  - aucun gros panneau technique visible d’emblée.
- Au mieux :
  - rappel contextuel minimal du profil actif en haut ;
  - détails repliés si encore nécessaires ;
  - renvoi vers les pages dédiées si besoin.
- Toute logique de configuration, de diagnostic runtime ou d’audit détaillé doit être rétrogradée ou externalisée dans la lecture.

## Éléments à supprimer / alléger / masquer par défaut
- le titre `Activation / releases` ;
- le groupe `Déploiement` dans les actions de la page `Releases` ;
- le bloc principal `Profils de déploiement` ;
- le bloc principal `Runtime applicatif` ;
- les remédiations runtime longues visibles par défaut ;
- la preview détaillée visible par défaut ;
- les projets détaillés du manifeste visibles par défaut ;
- le manifeste local visible par défaut ;
- le `Détail status CLI` visible par défaut ;
- les chemins techniques complets visibles par défaut ;
- les libellés et microcopies qui racontent une autre page que `Releases` ;
- les duplications de lecture du même objet : release courant, diagnostic layout, preview, détails de release ;
- le contrôle `Projets ciblés` comme élément important du premier niveau de lecture.

## Séquence d’implémentation
1. réduire la zone haute au contexte minimal strictement utile pour cibler un release ;
2. faire remonter le bloc principal de bascule (`Activate` / `Rollback` / résultat) ;
3. repositionner le `Diagnostic du layout release` juste autour du cœur, sans en faire le sujet principal ;
4. rétrograder `Cleanup` et la preview en maintenance secondaire ;
5. sortir `Profils`, `Runtime` et les détails techniques du premier niveau de lecture ;
6. supprimer les doublons et les intitulés qui font fuir la page vers `Deploy` ;
7. faire le polish final minimal sans réenrichir la page.

## Contraintes à ne pas casser
- aucune feature nouvelle ;
- aucun refacto backend ;
- aucun changement métier ;
- aucune modification des actions existantes ;
- aucune confusion entre `Build`, `Deploy`, `Database`, `Runtime`, `Env` et `Releases` ;
- aucun build dans `Releases` ;
- aucun déploiement complet dans `Releases` ;
- aucune migration DB dans `Releases` ;
- aucun diagnostic runtime large comme cœur de page ;
- aucune logique implicite nouvelle ;
- aucune duplication inutile des mêmes informations ;
- aucun chargement silencieux ;
- le pattern transverse des chargements explicites reste respecté ;
- les actions existantes restent identiques ; seule l’organisation visuelle et la microcopie changent.