# Slidia v2 — Étape 1 : le socle **Date :** 2026-07-31 **Branche :** `slidia_v2` **Statut :** design validé, en attente de relecture --- ## 1. Contexte Slidia doit être remis au niveau de Moodia et Scormia, sur deux axes : la qualité de la génération IA et la cohérence de l'interface. Le chantier est découpé en trois étapes séquentielles : | Étape | Contenu | Spec | |---|---|---| | **1. Socle** | Composants Twig partagés, recherche/pagination en repository, couche Responses API et comptage des tokens | **ce document** | | 2. Slidia IA | `gpt-5-mini`, réécriture des prompts, mode « format précis », import et condensation de PDF | à venir | | 3. Slidia UI | Refonte de l'accueil, page de choix de méthode, nettoyage, recherche Moodia | à venir | Le socle ne produit **aucun changement visible** pour l'utilisateur. Il installe les fondations dont dépendent les étapes 2 et 3. --- ## 2. Portée ### Dans la portée - Un trait de recherche partagé pour les repositories, et le passage de Slidia et Moodia à une pagination SQL. - Cinq composants Twig extraits du markup Scormia, plus un contrôleur Stimulus de recherche. - L'extension de `callResponsesApi()` : sorties structurées, effort de raisonnement, détection de troncature. - Un accumulateur de consommation de tokens couvrant tous les appels d'une génération. - Les tests unitaires correspondants. ### Hors portée - **Scormia n'est pas modifié.** Son markup et son repository servent de référence ; ils restent en l'état. Une migration ultérieure vers les composants partagés reste possible, à rendu strictement identique. - Aucun changement de modèle IA, de prompt ou d'interface : c'est l'objet des étapes 2 et 3. - Le mode « Standard / Approfondi » et la condensation de PDF relèvent de l'étape 2 ; le socle se contente de rendre leur implémentation possible. --- ## 3. Décisions actées | Sujet | Décision | |---|---| | Modèle Slidia | `gpt-5-mini` (étape 2), `gpt-5-nano` sur les tâches mécaniques | | Pagination | **9 éléments par page** pour Slidia, Moodia et Scormia — valeur unique, aucune différence entre outils | | Recherche | Côté serveur, en repository, pour Slidia comme pour Moodia | | Accent Slidia | Ambre `#F59E0B` — inchangé | | Décompte des tokens | Basé sur l'`usage` réel renvoyé par OpenAI à chaque appel, additionné jusqu'à la fin de la génération. Aucun coefficient par modèle. | | Tokens de raisonnement | Décomptés | | `entity-card` | Retenu, bien qu'un seul outil le consomme dans cette étape | | Épinglage Slidia | Supprimé (entité, API, interface) — voir 4.2 bis | --- ## 4. Recherche, filtrage et pagination en repository ### 4.1 Le trait partagé `ScormiaModuleRepository::applySearch()` fait déjà le travail correctement : comparaison en `LOWER()`, échappement des métacaractères LIKE (`%`, `_`, `!`) via `ESCAPE '!'`, absence de filtre si la chaîne est vide. Ce comportement est extrait sans modification sémantique. **Fichier :** `src/Repository/Concern/LikeSearchTrait.php` ```php namespace App\Repository\Concern; use Doctrine\ORM\QueryBuilder; /** * Recherche plein-texte simple, partagée par les bibliothèques d'outils. * * Les métacaractères LIKE saisis par l'utilisateur sont échappés via ESCAPE '!' : * sans cela, un « % » dans la recherche remonterait toute la table. */ trait LikeSearchTrait { /** * @param string ...$fields Champs à interroger, préfixés de leur alias (ex. 'p.title'). * Plusieurs champs sont combinés en OR. */ private function applyLikeSearch(QueryBuilder $qb, ?string $search, string ...$fields): void } ``` Le nommage du paramètre est `:search`. Le trait ne fait rien si `$search` est vide ou si `$fields` est vide. **Scormia n'adopte pas le trait dans cette étape** (consigne : ne rien toucher). Sa méthode privée reste en place et produit exactement le même SQL. ### 4.2 Les repositories `SlidiaPresentationRepository` gagne : ```php /** @return SlidiaPresentation[] */ public function findByUserPaginated( User $user, int $offset, int $limit, ?int $templateId = null, ?string $search = null, ): array public function countByUser( User $user, ?int $templateId = null, ?string $search = null, ): int ``` `$templateId` : `null` = tous les masques ; un entier = ce masque ; la constante `SlidiaPresentationRepository::NO_TEMPLATE` = les présentations sans masque. La recherche porte sur `p.title`. `findByUser()` est conservée : elle sert à l'export et au tableau de bord. `App\Repository\Moodia\MoodiaCourseRepository` gagne le même couple. Le travail y est plus léger qu'attendu : `findByUserWithFilters()` construit déjà un `QueryBuilder` et exprime le filtre de type en SQL (`c.generationType = :type`), tout comme le filtre de statut. Il suffit donc d'en extraire la construction de requête, puis d'ajouter la recherche, l'`offset`, le `limit` et la méthode de comptage. Cela supprime le chargement intégral suivi d'un `array_slice()` en PHP dans `MoodiaController::index` : **le filtrage et la pagination passent en SQL.** `findByUserWithFilters()` est conservée pour ses appelants existants. ### 4.2 bis — Suppression de l'épinglage Slidia affiche aujourd'hui deux sections, « Épinglés » puis « Tous les autres », sur une page non paginée. Ce découpage devient incohérent dès qu'on pagine, et ni Moodia ni Scormia n'ont d'équivalent. **Décision retenue : l'épinglage est supprimé**, au même titre que les catégories. Portée de la suppression : - champ `pinned` de `SlidiaPresentation`, avec migration ; - clé `pinned` acceptée par `PATCH /api/slidia/presentations/{id}` ; - sections `pinnedSection` / `othersSection` du listing et entrée « Épingler » du menu contextuel (étape 3) ; - tri : il ne reste que `ORDER BY p.updatedAt DESC`, identique à Moodia et Scormia. Le socle se contente de ne pas réintroduire la notion dans les nouvelles méthodes de repository. Le retrait effectif de l'entité, de l'API et de l'interface est réalisé à l'étape 3, avec celui des catégories, dans une migration unique. ### 4.3 Pagination unifiée Nouvelle constante `AppLimits::TOOL_LIBRARY_PER_PAGE = 9`, utilisée par Moodia et Slidia. Supprimées : - `AppLimits::MOODIA_COURSES_PER_PAGE` (valait déjà 9) - `SlidiaConfig::PRESENTATIONS_PER_PAGE` (valait 30, jamais lue) `ScormiaController::PER_PAGE` reste tel quel : sa valeur est déjà 9, le comportement est identique. Son alignement sur la constante partagée est laissé à une passe ultérieure. ### 4.4 Les contrôleurs Les contrôleurs lisent les paramètres de requête, les valident et délèguent. Aucune logique de filtrage ne doit y subsister. - Le numéro de page est borné : `max(1, min($totalPages, $page))`. - Les compteurs d'onglets restent absolus, indépendants de la recherche — comportement Scormia, à reproduire à l'identique. - Les paramètres de requête sont propagés dans les liens d'onglets et de pagination (motif `qp` de `scormia/index.html.twig`). --- ## 5. Composants Twig Cinq composants, modelés sur le markup Scormia. Chacun est documenté en tête de fichier avec le tableau de paramètres, conformément à la convention du répertoire. ### 5.1 `_organisms/tool-header/` — en-tête d'outil Bloc Twig `actions`, donc utilisé via `{% embed %}`. | Paramètre | Type | Défaut | Rôle | |---|---|---|---| | `icon` | string | requis | Nom d'atome (`bubul-slidia`…) | | `title` | string | requis | Nom de l'outil | | `description` | string | `null` | Phrase de présentation | | `color` | objet | `null` | Entrée de `tool_color_details` ; si absent, les classes `primary` globales | | `badge` | objet | `null` | `{label, variant}` — le badge `BETA` de Scormia | | `cost` | objet | `null` | `{value, unit}` — le coût médian en tokens de Moodia | | `primaryAction` | objet | `null` | `{label, href, icon, disabled, tooltip}` | | `class` | string | `''` | Classes additionnelles | Le bloc `actions` prend le pas sur `primaryAction` quand il est défini : c'est ainsi que Slidia ajoutera « Mes masques » à côté de « Créer une présentation ». Rendu : le `
` de Scormia, avec la pastille 16×16 en dégradé, le titre `text-2xl sm:text-3xl font-bold font-secondary`, et le coût affiché en `hidden lg:inline-flex` comme chez Moodia. ### 5.2 `_organisms/tool-toolbar/` — barre de filtres et de recherche Blocs `leading` et `trailing`, donc `{% embed %}`. **Les deux sont optionnels** : c'est ce qui permet à chaque outil d'avoir des filtres plus ou moins riches sans dupliquer la barre. | Paramètre | Type | Défaut | Rôle | |---|---|---|---| | `filters` | tableau | `null` | Transmis tel quel à `filter-tabs` | | `active` | string | `null` | Filtre actif | | `name` | string | `'filter'` | Nom du groupe de filtres | | `search` | objet | `null` | Transmis tel quel à `search-input` | | `class` | string | `''` | Classes additionnelles | Rendu : `flex flex-col md:flex-row md:items-stretch gap-3 md:gap-4 mb-6`, le bloc `leading` en `shrink-0`, le bloc `trailing` en `flex-1 md:max-w-md md:ml-auto`. Par défaut, `leading` rend `filter-tabs` si `filters` est fourni et `trailing` rend `search-input` si `search` est fourni. Slidia surchargera `leading` pour y placer son filtre de masque. ### 5.3 `_molecules/search-input/` — le champ de recherche Extraction fidèle du champ de `scormia/index.html.twig` : `h-12 rounded-full bg-white border border-black/[0.08]`, icône positionnée en absolu, `data-turbo-permanent`. | Paramètre | Type | Défaut | |---|---|---| | `placeholder` | string | `'Rechercher…'` | | `value` | string | `''` | | `name` | string | `'q'` | | `id` | string | requis (pour `data-turbo-permanent`) | | `action` | string | `null` — valeur de `data-action` | | `class` | string | `'flex-1 md:max-w-md md:ml-auto'` | `relative` est posé en dur sur le conteneur, hors du paramètre `class` : c'est lui qui ancre l'icône positionnée en absolu. Le rendre surchargeable casserait la mise en page dès qu'un outil ajusterait la largeur du champ. **La molécule `_molecules/search-bar/` existante n'est pas réutilisée.** Elle n'est appelée nulle part, et elle embarque un `