Recette

Comment vérifier qu'un ticket a été livré comme demandé.

Chaque chapitre couvre un écran et contient des scénarios numérotés : un objectif, le rôle qui l'exécute, les données à mettre en place, les étapes, et le résultat observable attendu. La table Traçabilité par ticket part du ticket et renvoie vers les scénarios à rejouer ; elle est générée, ne la modifiez pas à la main.

Avant de rejouer un scénario à la main, regardez Couverture automatisée : ce que les suites de tests prouvent déjà n'a pas besoin d'être repassé.

Les chapitres

• Connexion — se connecter, échouer proprement, assumer une identité depuis le back-office.
• Mot de passe oublié — demander un lien, le consommer, gérer un lien expiré.
• Portail — navigation, bascule Manager / Mon espace, topbar, et le cloisonnement d'un compte salarié.
• Annuaire Utilisateurs — effectifs, recherche, filtre, ouverture d'une fiche.
• Fiche salarié — les six volets et qui peut écrire dans chacun.
• Bibliothèque Postes — le catalogue de modèles d'horaires d'un encadrant, et son cloisonnement par compte.
• Bibliothèque ▸ Trames — la bibliothèque personnelle de cycles de travail d'un manager, composés à partir de ses postes.
• Planification — l'assistant qui rattache une trame à des salariés réels, datés.
• Planning manager — la grille salariés × jours, ses panneaux et ses filtres. Le seul chapitre qui se joue en deux modes : sur les données réelles pour la lecture d'une semaine planifiée et pour l'unique bouton qui écrit — l'Enregistrer de « Modifier le poste » — et sur un jeu simulé pour les situations que la base ne sait pas encore produire (absences, journée coupée, astreintes, collision de codes). Chaque scénario dit lequel des deux il demande.
• Référentiel organisationnel — le seul chapitre qui se joue dans le back-office : créer et modifier un établissement sans intervention technique.

Monter un environnement de recette

cp .env.example .env      # une seule fois
make up                   # démarre la stack
make migrate              # applique les migrations
make seed-demo            # compte de démonstration : i.aubert / demo1234
make seed-establishments  # sites, établissements, services, codes de paye
make seed-workforce       # une cohorte de salariés, pour que l'annuaire ait des données
make seed-employees       # rattache un salarié au compte de démonstration
make seed-counters        # compteurs congés / CET / annualisation
make seed-postes          # bibliothèque de postes du compte de démonstration
make seed-trames          # une trame de démonstration (nécessite seed-postes)

Chaque scénario rappelle en tête les seeds dont il dépend. Rejouer une commande de seed est sans danger : elles sont idempotentes.

Adresses

Les hôtes sont définis par votre .env, pas figés : FRONTEND_HOST pour l'application, API_HOST pour l'API et le back-office (/admin/). Les valeurs livrées par .env.example sont monoutil.localhost et api.monoutil.localhost ; une installation existante peut en avoir d'autres. En cas de doute : grep HOST .env.

Comptes et rôles

Les droits ne viennent pas d'un champ sur le compte mais de rôles attribués par établissement (apps/roles). Trois profils suffisent à couvrir ce que les scénarios distinguent :

Profil	Rôle	Ce qui le caractérise
Administrateur	Admin	compte is_staff : le back-office, et l'écriture sur tous les volets de la fiche
Encadrant	Manager n1	ouvre l'annuaire et toutes les fiches, sans être is_staff — n'écrit que sur Urgence et Lieux de travail & équipes
Salarié	Salarié	Mon espace seulement : ni annuaire, ni fiche d'autrui

make seed-workforce crée Léa Martins avec le rôle Manager n1 : c'est le profil « encadrant non-is_staff » des scénarios.

Viewports

Les scénarios marqués mobile se jouent en 390 × 844, la référence tenue par les tests end-to-end. Le seuil de bascule est 768 px — au-dessus, l'écran est en version bureau.

Exemptions

Ce que la recette ne couvre pas volontairement. make docs-check lit cette liste : une entrée retirée d'ici doit gagner un scénario.

• e2e/gallery.spec.ts — la galerie du design system (/__gallery) est un outil de développement, pas un écran du produit. Elle n'a pas de recette manuelle ; sa spec garde les composants sous surveillance.
• e2e/equipes.spec.ts — régression pour un plantage Base UI (erreur #18) du sélecteur d'établissement de Bibliothèque ▸ Équipes ▸ Créer une équipe, découvert en environnement déployé, sans ticket associé. La spec garde ce composant sous surveillance plutôt que de rejouer un scénario produit — même raisonnement que gallery.spec.ts. Le reste de l'écran Équipes n'a pas encore de chapitre de recette (créé par #55, sans l'un) ; hors périmètre de ce correctif.
• APAJH-192 — la planification quotidienne de l'import CEGI est un comportement d'exploitation sans interaction d'écran. Pytest vérifie son horaire et son innocuité sans nouveau fichier ; les journaux Celery confirment son exécution.