# SSTM — Journal Phase 4 (design)

> Compagnon de `PLAN.md`, dédié uniquement à la refonte visuelle. Règle identique : on met à jour ce fichier après chaque étape (choix tranché, fichiers touchés, reste à faire).

## Principe directeur

Aucune couleur, rayon, ombre ou police en dur dans les vues. Tout passe par des **variables CSS (tokens)** centralisées dans un seul dossier. Changer de direction visuelle plus tard = éditer ce dossier, jamais les ~130 vues de l'appli.

```
public/css/design/
  tokens.css        ← la seule source de vérité (couleurs, espacements, rayons, ombres, polices)
  components.css     ← boutons, badges, tableaux, modales, cartes — tous en var(--...)
  layout.css          ← topbar, sidebar, grilles de page
themes/ (optionnel, si on garde plusieurs jeux de tokens choisissables)
  cadran.css / registre.css / piste.css   ← ne redéfinissent QUE les variables, jamais un composant
```

`tokens.css` est chargé après le CSS existant (AdminLTE/Bootstrap 4) dans `public/index.php`, et **surcharge** progressivement — pas de réécriture big-bang du framework CSS existant.

## Étape 1 — Détachement d'AdminLTE (fait, socle) — 20/07/2026

Retour de l'utilisateur sur l'étape précédente : refus de l'approche "on repeint AdminLTE avec des variables CSS" (jugée superficielle). Nouvelle consigne : détacher réellement le socle d'AdminLTE, reconstruire menu/topbar/boutons/tableaux/modales/champs avec du HTML neuf, ne garder que **4 directions** (Majorelle, Pupitre, Irisé, Aurore — Borne KM et Ticket Thermique abandonnées).

Ce qui a été fait :
- **Menu, topbar, panneau réglages entièrement reconstruits** (`app/views/layout/{header,top_bar,left_bar,footer}.php`) : classes neuves `ssm-*`, plus aucune classe/structure AdminLTE (`.main-header`, `.main-sidebar`, `.nav-sidebar`, `.control-sidebar`, `.wrapper`...). Comportements (repli du menu, panneau réglages coulissant, recherche) réimplémentés en JS simple, sans les widgets `data-widget="..."` d'AdminLTE.
- **Composants d'action reconstruits** : `dt_btn()`, `dt_btn_group()`, `dt_btn_lien()`, `dt_btn_dropdown_confirm()`, `dt_btn_dropdown_date()`, `dt_badge()` (`vendor/function.php`) et `Model::btn_group()` (partagé par 16 modèles) émettent désormais des classes `ssm-btn`/`ssm-pill`/`ssm-menu` neuves — pas une surcharge de `.btn`/`.badge`/`.dropdown`. Comme ces helpers sont le point de passage central de la Phase 3.5, le changement se propage automatiquement à la quasi-totalité des boutons d'action de l'appli.
- **Tableaux** : `init_datatable()` (`public/js/ajax.js`) pilote désormais un rendu (`dom`) et des classes (`ssm-table`, `ssm-dt-wrapper`) propres, plus de dépendance visuelle à `dataTables.bootstrap4.css`.
- **`public/css/design/shell.css`** (nouveau) : CSS complet de l'ossature (sidebar, topbar, panneau réglages).
- **`public/css/design/components.css`** : réécrit de zéro (pas de surcharge `!important` d'AdminLTE) — boutons, pastilles, tableaux, modales, champs, cartes.
- **`database/migrations/006`** : mis à jour au fil de l'eau (colonne renommée `mode_theme` suite à un conflit de nom sur la base réelle ; jeu final réduit aux 4 directions).
- **`vendor/function.php::style()`** : la direction est désormais **toujours** définie (`majorelle` par défaut) — le nouveau socle en a besoin systématiquement pour s'afficher correctement ; les anciens styles dark/blue basculent automatiquement dessus.

**Ce qui reste volontairement en place (garde-fou, pas un oubli)** : `adminlte.min.css`/`adminlte.min.js` restent chargés, uniquement pour les ~100 vues qui utilisent encore des composants AdminLTE (`small-box`, `info-box`, `callout` — tableaux de bord/statistiques) et n'ont pas encore été reprises. Elles gardent leur ancien rendu visuel en attendant leur tour, module par module — les retirer d'un coup aurait cassé leur mise en page. À signaler si l'une d'elles doit être priorisée.

Testé : 4 directions × mode clair/sombre, sur 12+ pages réelles (Clients, Règlements, Produits, Employés, Comptes PS, Chèques/LCN, Bons de commande, Banque, Utilisateurs, Historique, Déclarations, Salaires) + endpoints AJAX (données DataTable, notifications) — aucune erreur, nouveau balisage confirmé.

## Étape 0 — Direction visuelle : les 6 retenues, choix par utilisateur (dépassé, voir Étape 1 ci-dessus)

- **20/07/2026** — Le client a aimé les 6 directions (Borne KM, Ticket Thermique, Majorelle, Pupitre, Irisé, Aurore) : décision de les rendre **toutes** sélectionnables par utilisateur plutôt que d'en trancher une seule. Voir commits `66de04b` + `633c62c` :
  - Table `parametre_style` étendue (migration 006) + colonne `mode` (clair/sombre) sur `parametre_style_user`.
  - `public/css/design/tokens.css` (6 palettes complètes, clair+sombre) et `public/css/design/components.css` (mappe les vraies classes Bootstrap/AdminLTE/`dt_btn`/`dt_badge` déjà utilisées partout — boutons, badges, tableaux DataTables, modales, sidebar, formulaires, dropdowns — sur les tokens). Tout est scopé sous `body[data-design="..."]` : les styles historiques dark/blue restent 100 % intacts si aucune direction n'est choisie.
  - Sélecteur étendu dans le panneau "Thème Couleur" (`footer.php`) : 6 nouvelles options + bascule Clair/Sombre.
  - Testé sur 7 pages réelles à travers les 8 styles (dark, blue + les 6 directions) + bascule de mode — aucune régression, aucune requête SQL supplémentaire (le style reste mis en cache session, une requête par connexion).
  - CSS minifié (16,6 Ko → 14,8 Ko, fichiers statiques, mis en cache navigateur).
  - **Reste à faire** : c'est un socle (Étape 1 du plan) appliqué globalement via des sélecteurs CSS génériques — pas encore une revue fine vue par vue. Si un composant précis rend mal avec une direction donnée, le signaler pour un ajustement ciblé dans `components.css`.

## Étape 0bis — Direction visuelle (historique, dépassé par la décision ci-dessus)

- [x] Artifact de présentation avec 3 propositions (Cadran / Registre / Piste), composants réels de l'appli (tableau règlements, pastilles, boutons, formulaire, modale de clôture), toutes construites sur variables CSS : voir lien partagé le 19/07/2026.
- [ ] **Décision utilisateur** : proposition retenue (ou fusion/variante) → à noter ici.
- [ ] Valider la palette définitive (couleurs sémantiques succès/attention/danger comprises) + la paire de polices.

## Étape 1 — Socle technique des tokens

- [ ] Créer `public/css/design/tokens.css` avec la palette validée (mode clair + mode sombre si retenu).
- [ ] Créer `public/css/design/components.css` : réécrire `.btn`, `.badge`, `.dropdown`, `table.dataTable`, `.modal`, `.card` en s'appuyant uniquement sur les tokens (surcharge d'AdminLTE, pas de remplacement).
- [ ] Charger les deux fichiers dans le layout global (`app/views/inc/header.php` ou équivalent).
- [ ] Vérifier sur 2-3 pages témoins (Reglement, ClientEtat, ComptesPs) qu'aucune régression visuelle bloquante n'apparaît.

## Étape 2 — Layout global

- [ ] Login
- [ ] Top bar (+ branding par tenant : logo/couleur depuis `parametre_station`, cf. PLAN.md Phase 1)
- [ ] Menu latéral (`left_bar()`)
- [ ] Dashboard (`home/Home.php`)

## Étape 3 — Refonte module par module (ordre par usage)

- [ ] Compte journalier
- [~] Ventes / Clients — **Clients/Cartes/Encaissements/Grand Livre traités le 21/07/2026, voir `SKILL_MODULE_VENTE.md`** (recette à répliquer). Reste dans le module vente : Reglements/Reglement/Factures/Avoirs/Livre pas encore repassés avec la meme recette (menu_client.php les inclut déjà mais ils n'ont pas encore `#ssm_module_content`/`.ssm-panel`/plein écran/toolbar impression).
- [ ] Coffre
- [ ] Achats
- [ ] Stocks
- [ ] Point de vente
- [ ] Comptabilité
- [ ] Employés
- [ ] Modules secondaires (restaurant, service, carte_fournisseur, cmi, ont, paramètres…)

## Étape 4 — Impressions / factures

- [ ] Gabarit unique paramétré par le branding du tenant (logo, couleurs), lisible en PDF/impression papier — indépendant des tokens d'écran (l'imprimé a ses propres contraintes : noir sur blanc, pas de couleurs de fond).

## Étape 5 — Nettoyage

- [ ] Supprimer le CSS mort une fois chaque module basculé.
- [ ] Vérifier accessibilité de base (focus visible, contraste) sur les composants réécrits.

## Journal

- **19/07/2026** — Présentation de 3 directions visuelles (Cadran/Registre/Piste) sous forme d'artifact interactif, construites entièrement sur variables CSS pour valider l'approche token-based avant tout code dans le projet. Fichier de secours `public/design-propositions.html` créé pour consultation directe (l'utilisateur n'a pas aimé les 3 propositions — un brief pour une direction plus radicale a été rédigé pour une consultation externe).
- **20/07/2026** — Chantier préalable (hors Phase 4 à proprement parler, mais prérequis) : nettoyage de la mécanique `header`/`top_bar`/`left_bar`/`footer`, demandé par l'utilisateur avant d'attaquer le visuel. Voir commit `665a2a4` :
  - `app/controllers/Layout.php` créé : toute la logique (utilisateur, style, résolution du menu actif/ouvert) centralisée en un point ; le menu latéral devient un tableau déclaratif (`Layout::menu_config()`) au lieu de 480 lignes de PHP répétitif.
  - Templates déplacés de `public/inc/` vers `app/views/layout/` et vidés de toute logique métier (les anciens fichiers renommés `public/inc/x*.php` en backup, non routés).
  - Notifications de la top bar (badges) + cartes "Comptes ouverts"/"Stock" du panneau droit : passées en chargement AJAX différé (`/Home/notifications`) au lieu de bloquer chaque page avec ~25-40 requêtes SQL.
  - `style()` mis en cache session (1 requête par connexion au lieu d'1 par page).
  - Testé sur ~15 pages (dont sous-menus profonds, page avec breadcrumb personnalisé, bascule du menu, changement de thème avec vérification du cache) — rendu visuel strictement identique, tout reste opérationnel.
  - Objectif atteint pour la Phase 4 : le futur redesign du layout (Étape 2) se fera désormais sur 4 templates courts et propres au lieu de ~1200 lignes mélangées, et ajouter/modifier une entrée de menu ne touche plus qu'un tableau PHP.

- **21/07/2026** — Module Vente (Clients/Cartes/Encaissements/Grand Livre) traité de bout en bout, module de référence pour la suite. **Recette complète documentée dans `SKILL_MODULE_VENTE.md`** (à lire avant de reproduire sur un autre module) ; résumé ici :
  - Card-dans-card supprimée (Clients.php) au profit du couple `.ssm-tabs` + `.ssm-panel` unique.
  - Filtres/actions rendus vraiment responsives (largeur uniforme en mobile, alignement label/select) et repositionnés de façon robuste (`.ssm-panel-toolbar`/`.ssm-panel-actions`, jamais de découpage `col-md-x` fragile).
  - Sélecteur de lignes DataTable (10/20/50/100/Tout) activé et restylé à la même hauteur que la recherche ; en-tête de tableau **sticky** (a nécessité de retirer `overflow:hidden` de `.ssm-panel`, voir piège documenté dans le skill).
  - Bouton **plein écran** par panel : déplacement réel du DOM vers `<body>` (pas juste `position:fixed` en place — la sidebar/topbar passaient par-dessus sinon), styles critiques posés en inline `!important` via JS pour ne plus dépendre de la cascade CSS, animation d'entrée/sortie, repère "où on est" affiché en plein écran.
  - **Impression/export génériques** : modale commune (titre, filtres, pagination, colonnes à cocher), boutons statiques au niveau du tableau (`ssm_table_toolbar()`), sans toucher aux mécanismes métier déjà existants (Grand Livre garde son rapport dédié avec récap de solde).
  - **Navigation AJAX inter-pages** entre les 4 pages du module, sans rechargement complet : `Controller::view()` sait renvoyer un fragment (en-tête `X-Ssm-Nav`), `#ssm_module_content` isole la partie qui se recharge (le sous-menu reste affiché, jamais recréé), sélecteurs select2 réinitialisés automatiquement. Sous-menu doté d'un **thumb glissant** (segmented control, piste avec fond/ombre, easing à rebond) dont la direction pilote l'animation d'entrée/sortie du contenu (l'ancien card sort dans le même sens que le nouveau entre).
  - Modale "Réglage carte" et page "Situation client" alignées sur l'identité visuelle établie (étaient restées à l'ancien style).
  - **Hors design, corrigé au passage** : perf critique sur Encaissements (requête UNION 8 branches sans index, exécutée jusqu'à 3× par appel — bloquait le serveur), voir migration `007` + commit `ab0b6f1`.
  - Nombreux allers-retours de débogage réel (capturés dans le skill pour ne pas les refaire) : bug de cache navigateur sur `ajax.js` (pas de `?v=` avant), clé DataTables `oLanguage` vs `language`, conflits de spécificité CSS `:has()`, `cache:false` de jQuery qui cassait le routeur.