# Lot 3 — Refonte UI Deploy

> 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
- Remplacer la logique précédente plus riche par un flux principal minimal.
- Rendre la page `Deploy` lisible comme : release déjà prête, cible / profil, envoi, finalisation optionnelle si nécessaire, résultat.
- Réserver `Database` à la migration explicite ensuite si nécessaire, et `Runtime` au contrôle / diagnostic utile ensuite si besoin.
- Ne rien changer au métier, aux actions disponibles, au backend ou au contrat CLI.

## Contrat produit de référence
- `Build` fabrique la release.
- `Deploy` prend une release déjà prête, la pousse vers la cible configurée, exécute la finalisation distante minimale si nécessaire, puis confirme le résultat côté fichiers / app.
- `Database` intervient ensuite si une migration est nécessaire.
- `Runtime` intervient ensuite si un test, un contrôle ou un diagnostic est utile.
- `Deploy` n’est pas une page `Build`.
- `Deploy` n’est pas une page `Database`.
- `Deploy` n’est pas une page `Runtime`.
- `Deploy` n’est pas une page d’audit technique large.
- Dans sa lecture la plus simple, `Deploy` doit d’abord répondre à :
  1. quelle release est envoyée ;
  2. sur quelle cible / quel profil ;
  3. quelle est l’action principale pour pousser ;
  4. si une finalisation est nécessaire ;
  5. quel est le résultat.

## Ce qui reste visible par défaut
- le titre `Deploy` et un sous-titre court orienté action ;
- la release visée ;
- la cible / le profil ;
- l’état distant utile avant action ;
- l’action principale pour pousser la release ;
- la finalisation optionnelle si elle doit encore être déclenchée explicitement ;
- le résultat utile le plus récent du flux principal ;
- un rappel court vers `Database` ensuite si migration nécessaire ;
- un rappel court vers `Runtime` ensuite si vérification / diagnostic utile.

## Ce qui passe en secondaire / replié
- le détail du status CLI ;
- les actions avancées isolées si elles restent nécessaires ;
- le détail de la release ciblée ;
- le détail des profils ;
- le contexte runtime ;
- les diagnostics techniques riches ;
- les détails preview ;
- les chemins complets et détails projet par projet.

## Ce qui sort du premier niveau de lecture
- les profils détaillés ;
- la release détaillée ;
- le contexte runtime détaillé ;
- les diagnostics techniques trop présents ;
- les actions avancées visibles comme un gros bloc de même rang que le flux principal ;
- les panneaux de maintenance ou d’audit qui ne servent pas directement à pousser puis finaliser ;
- toute lecture “page riche de contexte” avant la lecture “j’envoie cette release vers cette cible”.

## Structure finale validée
1. `Deploy`
   - titre + sous-titre court
   - contexte minimal `Release / Profil / État`
   - contrôles strictement utiles au flux
2. `Flux principal`
   - action principale d’envoi
   - finalisation optionnelle si nécessaire
   - lecture du résultat
3. `Suite logique`
   - renvoi court vers `Database` si migration nécessaire
   - renvoi court vers `Runtime` si vérification / diagnostic utile
4. `Secondaire / replié`
   - actions avancées si elles restent
   - release détaillée
   - profils détaillés
   - runtime détaillé

## Zone haute cible
- Titre : `Deploy`
- Sous-titre : `Pousse une release déjà prête vers la cible configurée.`
- Une seule zone haute.
- Ordre attendu :
  1. titre ;
  2. sous-titre ;
  3. release ;
  4. cible / profil ;
  5. état utile avant action ;
  6. contrôles minimums strictement utiles.
- La zone haute ne doit pas raconter la preview, le runtime, la release détaillée ni les diagnostics.

## Bloc principal cible
- Le bloc principal n’est plus une page riche hiérarchisée ; c’est un flux minimal centré sur `envoyer puis finaliser`.
- Il doit rendre évident :
  1. ce que j’envoie ;
  2. où je l’envoie ;
  3. quel bouton principal je clique ;
  4. si une finalisation est encore nécessaire ;
  5. ce qu’il s’est passé.
- Le flux principal doit être plus important visuellement que tout le reste.

## Place du résultat
- Le résultat du flux principal doit rester visible sans détour.
- Il doit être rattaché directement à l’action principale ou au flux principal.
- Il doit montrer clairement succès / erreur / blocage.
- Il ne doit pas être noyé dans un panneau technique plus large.

## Place des renvois vers Database / Runtime
- `Database` n’apparaît pas comme un sous-flux de `Deploy`.
- `Runtime` n’apparaît pas comme un sous-flux de `Deploy`.
- Ce sont des suites logiques explicites, courtes et secondaires :
  - `Database` ensuite si migration nécessaire ;
  - `Runtime` ensuite si vérification / diagnostic utile.

## Place des actions avancées si elles restent
- Les actions avancées ne doivent plus être un bloc fort de premier niveau.
- Si elles restent, elles doivent être secondaires, utilitaires et idéalement repliées.
- Elles ne doivent jamais concurrencer le flux principal.
- Elles ne doivent pas raconter une autre logique produit que `pousser puis finaliser`.

## Éléments à supprimer / alléger / masquer par défaut
- le détail des profils ;
- le détail de la release ciblée ;
- le contexte runtime détaillé ;
- le détail CLI / JSON brut ;
- les diagnostics techniques longs ;
- les détails preview ;
- les détails projet par projet ;
- les chemins techniques complets ;
- toute aide ou microcopie qui dilue la lecture `release → cible → envoi → finalisation → résultat`.

## Séquence d’implémentation
1. réduire la zone haute au contexte minimum strictement utile ;
2. recentrer la page sur un bloc principal minimal `envoyer puis finaliser` ;
3. rattacher clairement le résultat au flux principal ;
4. sortir `Database` et `Runtime` du cœur de la page pour en faire des renvois explicites ;
5. repousser tout le reste en secondaire / replié ;
6. 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 logique implicite ;
- aucune duplication CLI / backend / UI ;
- aucun build dans `Deploy` ;
- aucune migration DB dans `Deploy` ;
- aucune confusion entre `Deploy`, `Database`, `Runtime`, `Build` et `Env` ;
- aucun `.env` dans une release ;
- aucun build sans release ;
- les actions existantes restent identiques ; seule l’organisation visuelle et la microcopie changent.