pardis/PRODUCTION.md

Validation avant production — Pardis

Vérifications exécutées dans cet environnement

• Dernière validation locale : 10 octobre 2026, avec npm run validate et la suite Playwright utilisant le Chromium Headless Shell installé via PARDIS_CHROME_PATH. Ces résultats ne remplacent pas une recette sur téléphones réels ni le résultat du workflow CI du commit publié.
• 272 tests unitaires et IndexedDB simulée passent (15 fichiers).
• npm run check : aucune erreur ni avertissement.
• Build PWA complet : sw.js, Workbox, manifeste et précache générés.
• L’importeur de la version précédente, extrait du commit avant l’évolution du format, refuse réellement un export v2 avec son message de mise à jour (sans importer les pauses comme travail).
• Cas couverts : 8h30 de travail / 30 minutes de pause, récapitulatif/copier et suggestions sans pause, reprise continue et discontinue à 18h, reprise avec dernier repas/pause, deux appels concurrents, aucune pause vide, refus de reprise passée, annulation transactionnelle sur erreur, repas automatique pendant une pause, clôture pendant une pause, ajout/correction/suppression sur journée close, import v1 et aller-retour v2, préservation des intervalles vides, écriture de réglages contre leur dernière valeur persistée et échec d’écriture.

Commande reproductible : npm ci puis npm run validate. La CI Gitea exécute déjà tests, vérification Svelte et build avant déploiement.

Parcours navigateur automatisés

Seize tests Playwright exécutent le build PWA réel dans Chrome, avec des profils éphémères et des fixtures synthétiques à 320 px. Ils couvrent consultation et correction, copie, statistiques, date et Retour après rechargement, focus et Échap (y compris les panneaux imbriqués), annulation et double appui, deux onglets, les reprises après repas/pause, export téléchargé puis vérifié, purge/restauration, erreur IndexedDB puis Réessayer, erreur de réglage avec champ restauré, ajout d’une pause dans un intervalle vide et rechargement hors ligne sous service worker. L’écran Données et sauvegardes est vérifié depuis les réglages et le rappel, avec Retour, rechargement, durée persistée et absence de débordement à 320 px. Le bandeau de sauvegarde est aussi testé avec une police agrandie.

Les trois parcours d’erreur ajoutés couvrent :

• Échec d’écriture de la conservation : erreur visible, champ restauré, base inchangée, valeur conservée après rechargement et nouvelle tentative réussie.
• Export JSON valide mais modifié : refus de vérification sans changement des journées, postes, réglages ou statut de sauvegarde ; le fichier original peut ensuite être vérifié.
• Échec de suppression des journées après écriture de la sauvegarde et suppression des postes : annulation de toute la transaction, y compris restauration de la sauvegarde précédente ; le dialogue reste ouvert et permet de réessayer.

Les captures MCP avaient été refusées par le contrôle d’autorisation. Les tests Playwright ont été autorisés comme vérification automatisée isolée : aucune trace, vidéo ou capture n’est produite, aucun contenu de page n’est transmis à MCP.

Commandes : npx playwright install chromium puis npm run validate:all. Un navigateur installé peut être choisi avec PARDIS_CHROME_PATH. La CI installe Chromium avec ses dépendances et lance les mêmes parcours. docker compose config --quiet a été validé avec des variables d’exemple. Cette sandbox ne pouvait pas lancer les conteneurs (socket Docker indisponible), mais l'opérateur confirme que le déploiement Docker de production et son job CI/CD fonctionnent et sont en service depuis plusieurs commits. La VM qui héberge l'instance reçoit une sauvegarde quotidienne. Celle-ci protège l'hébergement et le service de synchronisation, mais pas les données locales conservées dans les navigateurs des utilisateurs.

Vérifications sur appareils réels à terminer avant publication

• Sur petit téléphone (320 px), parcourir Récap → Voir les détails → Corriger, retourner au récapitulatif et vérifier date, copie et statistiques.
• Au clavier, vérifier les pages Détails, Automatismes, Jours non travaillés et Données et sauvegardes, le focus initial, Tab et Maj+Tab dans chaque dialogue, Échap et restitution au bouton d’origine. Inclure remplacement et purge.
• Vérifier Retour du navigateur et Retour de la PWA depuis les pages filles des réglages et du récapitulatif.
• Annuler la reprise depuis chacun des deux boutons : aucun changement. Double appui et deux onglets réels : un seul poste de reprise.
• Installer la PWA puis démarrer hors ligne, suspendre et rouvrir. Tester une mise à jour sans interrompre une journée active.
• Exporter sur iOS/Safari et Android/Chrome, vérifier le fichier téléchargé, restaurer par fusion puis remplacer sur un profil de test.
• Simuler IndexedDB inaccessible : erreur visible et Réessayer.
• Vérifier les libellés d’ajustement de l’import sur un historique endommagé.
• Vérifier les dates affichées avant purge et récupérer sa sauvegarde.
• Depuis les réglages puis le rappel, ouvrir Données et sauvegardes, modifier la durée, recharger et vérifier sa persistance sans suppression de journées.

Consigner la recette manuelle

Utiliser des profils et des données de test. Pour Android/Chrome et iOS/Safari, prendre une version stable actuelle et consigner les versions exactes. Aucun de ces contrôles n’a été exécuté sur appareil réel dans cet environnement.

Environnement	Appareil et versions OS/navigateur	Date	Résultat
Android / Chrome, PWA installée	À renseigner	—	À effectuer
iOS / Safari, ajout à l’écran d’accueil	À renseigner	—	À effectuer
Chromium sur ordinateur, navigation au clavier	À renseigner	—	Recette manuelle à effectuer

Pour chaque environnement, relever les résultats d’export/vérification/import (fusion et remplacement), démarrage hors ligne, suspension/réouverture, Retour et affichage étroit. Pour les dialogues de remplacement et de purge, relever aussi le focus initial, Tab/Maj+Tab, Échap et la restitution du focus. Une mise à jour doit être proposée sans interrompre une journée active. Ne cocher les vérifications qu’après leur exécution ; consigner les anomalies avec le parcours et les versions utilisées.

Suivi de fiabilité et limites connues

• La purge au lancement est désactivée pour protéger les imports anciens. La purge manuelle conserve une sauvegarde dans IndexedDB, récupérable depuis Données et sauvegardes. Modifier la durée de conservation ne supprime rien. Cette copie n’est pas une sauvegarde externe et disparaît si les données du site sont effacées. Une seule sauvegarde avant purge est conservée.
• La date du dernier export préparé n’est pas une preuve que le téléchargement a été conservé : le navigateur ne confirme pas cette étape automatiquement. Une date distincte est marquée vérifiée après relecture du fichier téléchargé et comparaison de son empreinte complète. Le rappel se déclenche après sept jours sans export vérifié. La restauration par import et la récupération après purge sont testées, mais conserver une copie externe reste nécessaire.
• Les journées dont tous les postes sont automatiques sont signalées comme déduites et à vérifier. Leur statut métier reste « terminée » ; une étape formelle de validation et son intégration aux statistiques restent à définir. Cette fonctionnalité reste au backlog ; la finalisation actuelle conserve les règles de calcul existantes.
• Tester les navigateurs et téléphones réellement ciblés avec une matrice de versions, notamment changement d’heure, minuit et suspension prolongée.
• Le nom IndexedDB TimeLogDB et l’identifiant timelog-export restent stables pour préserver les données. Les noms visibles et les icônes utilisent Pardis.
• Avant changement de domaine : exporter sur l’ancien domaine, vérifier le fichier, ouvrir le nouveau domaine, importer et comparer journées, postes et réglages. Les données locales et le service worker ne migrent pas entre origines.
• La configuration Caddy conserve les règles de revalidation HTML/service worker et de cache des fichiers hachés ; vérifier les en-têtes sur le domaine publié.