**# Lot 3 — Refonte UI Build

> 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
- Rendre la page `Build` plus compacte, plus lisible et plus scannable.
- Ne rien changer au métier, aux actions disponibles ou au backend.
- Faire lire immédiatement la page comme : construire des artefacts pour une release sélectionnée.

## Structure finale validée
1. `Build`
   - titre + sous-titre
   - ligne compacte `Release / Profil / Projets / État`
   - contrôles existants : release, projets, profil, appliquer, raccourcis release
2. `Contexte du build`
   - uniquement les indicateurs globaux fiables et non déjà présents dans les cartes
3. `Builds locaux`
   - cartes d’actions locales compactes
4. `Build distant API`
   - carte distante compacte, séparée

## Renommages validés
- `Build release` → `Build`
- `Release sélectionnée pour le build` → `Contexte du build`
- `Actions` → supprimé comme titre générique sur la page `Build`
- groupe `Déploiement` sur la page `Build` → `Builds locaux`
- groupe distant de la page `Build` → `Build distant API`

## Éléments à supprimer de la page actuelle
- le mot `Déploiement` dans le contenu de la page `Build`
- les introductions concurrentes
- les longs textes explicatifs dans le haut de page
- le paragraphe long du bloc `Release sélectionnée pour le build`
- la carte `Règle sécurité`
- la carte `Release` dans le bloc secondaire
- la grille des projets dans `Contexte du build`
- les rappels globaux répétés dans chaque carte locale
- les notes longues dans les cartes locales
- le titre générique `Actions`
- la phrase `Actions filtrées selon la page courante.`

## Zone haute cible
- Titre : `Build`
- Sous-titre : `Fabrique les artefacts pour la release sélectionnée.`
- Une seule zone haute.
- Ordre attendu :
  1. titre
  2. sous-titre
  3. ligne compacte `Release / Profil / Projets / État`
  4. champs `Nom de la release` et `Projets ciblés`
  5. boutons `Utiliser dernier local` / `Utiliser current distant`
  6. `Profil actif` + `Appliquer le profil`
  7. note de profil compacte si utile

## Bloc `Contexte du build` cible
- Bloc secondaire, compact, non introductif.
- Contient seulement :
  - `Snapshot local`
  - `Dernier build`
  - `État build` seulement si utile
- Ne contient plus :
  - boutons de sélection de release
  - release comme information principale
  - grille projet
  - règles globales
  - texte pédagogique long

## Cartes locales — règles validées
- Structure unique de chaque carte :
  1. titre
  2. badge d’état
  3. ligne courte de contexte
  4. message de blocage si présent
  5. bouton
  6. dernier résultat utile
- À garder : label, statut, bouton, dernier résultat utile.
- À retirer : `action.note`, rappels globaux, textes longs, duplications.
- À raccourcir : description et message de blocage.
- Toutes les cartes locales doivent avoir la même structure et la même densité.
- Si la règle `.env` reste affichée visuellement, elle ne doit apparaître qu’au plus une fois au niveau page.

## Bloc `Build distant API` — règles validées
- Rôle : isoler clairement l’action distante du bloc local, sans confusion avec `Deploy`.
- Structure finale du bloc :
  1. titre `Build distant API`
  2. aucune introduction générique
  3. une seule grille compacte
  4. une seule carte distante
- Structure finale de la carte distante :
  1. titre
  2. badge d’état
  3. description courte
  4. note courte spécifique si utile
  5. message de blocage si présent
  6. bouton
  7. dernier résultat utile
- Identique aux cartes locales : même conteneur, même hiérarchie visuelle, même position du badge, du bouton et du dernier résultat, même densité.
- Spécifique au distant : titre explicitement distant, description orientée build distant, note courte seulement si elle exprime un prérequis distant réel.
- Ne doit pas dupliquer : release sélectionnée, profil actif, projets ciblés, état global, `Snapshot local`, `Dernier build`, `État build`, règle `.env`, rappels globaux déjà visibles plus haut.

## Polish final réellement appliqué
- Le bloc des actions `Build` occupe la pleine largeur utile de la page.
- Les cartes locales sont encore plus compactes : padding réduit, largeur minimale abaissée, titres / descriptions / boutons resserrés.
- Le bloc de dernier résultat est rendu plus secondaire : fond allégé, bordure plus discrète, typo plus petite, badge d’état moins dominant.
- Les chemins techniques de `Contexte du build` restent visibles mais plus discrets : libellé court + chemin séparé, style monospace réduit, contraste abaissé.
- Le bouton `Rafraîchir` reste dans l’en-tête du bloc d’actions mais avec un rendu plus utilitaire et moins attractif visuellement.

## Séquence d’implémentation validée jusque-là
1. fusion de la zone haute
2. renommage / suppression des mauvais blocs
3. refonte du bloc `Contexte du build`
4. compactage des cartes locales
5. isolation du bloc `Build distant API`
6. polish visuel final minimal

## Contraintes à ne pas casser
- aucune feature nouvelle
- aucun refacto backend
- aucun changement métier
- aucune donnée inventée
- aucune duplication inutile
- aucun build sans release
- aucun `.env` dans une release
- aucun vocabulaire de `Deploy` dans la page `Build`
- aucun rappel global répété dans chaque carte
- les actions existantes restent identiques ; seule l’organisation visuelle et la microcopie changent**