Blomios
53b4957bc6
Ajoute les notes mémoire d'architecture, de philosophie de la couche online et d'UX pour le client online, clôture le ticket #64, reflète les tickets #46/#54/#57/#62, ajoute le cadrage des tickets #65 à #70. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.9 KiB
2.9 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| gametime-online-layer-philosophy | memory note gametime-online-layer-philosophy |
|
GameTime — Philosophie de la couche online (compte, sync, partage)
Décision produit posée par l'utilisateur pour le ticket #57, à respecter par tous les tickets futurs touchant au serveur/à la synchronisation/au compte utilisateur (notamment #63 et la suite).
Principe directeur
L'application reste offline-first en priorité, la couche online est un complément transparent, jamais une dépendance bloquante. Référence produit explicite : Hevy.
- La connexion à un compte est toujours optionnelle. L'app doit être pleinement utilisable sans jamais se connecter.
- Si le serveur est indisponible (pas de réseau, serveur down, timeout...), aucune popup d'erreur, aucun blocage, aucun message intrusif ne doit apparaître à l'utilisateur pendant son usage normal. L'absence de connectivité doit être silencieuse pour les fonctionnalités de base.
- Le serveur sert l'application, jamais l'inverse : en cas de divergence de structure de données entre le client (source de vérité fonctionnelle) et le serveur, c'est le serveur qui doit être adapté pour accepter la donnée du client, pas le client qui doit se plier au serveur. (Exemple concret déjà identifié : le schéma serveur des exercices doit être mis à jour pour accepter les étapes ajoutées côté client par le chantier #54, la forme serveur ayant été figée avant ce chantier.)
Ce qui doit toujours rester stocké en local (jamais uniquement distant)
Tout ce qui est nécessaire au bon affichage/fonctionnement normal de l'app doit avoir une copie locale à jour, sans dépendre d'un appel réseau pour s'afficher correctement :
- Exercices, programmes, séances-modèles, historique de séances (déjà le cas, c'est la base offline-first existante).
- Statistiques calculées, si/quand elles existeront.
- Données de profil utilisateur une fois connecté : pseudo, photo de profil, et toute autre donnée de compte affichée dans l'UI — gardées en cache local pour un affichage instantané et cohérent même hors ligne, sans jamais afficher une valeur fausse ou périmée qui induirait l'utilisateur en erreur (mieux vaut réafficher la dernière valeur connue que d'afficher une erreur ou un vide trompeur).
Comment appliquer ce principe
- Toute UI liée au compte/sync (menu "Profil", statut de connexion, etc.) doit être conçue comme une couche additive et discrète, jamais comme un gate ou une interruption du parcours principal.
- Les échecs réseau/sync doivent être gérés silencieusement en arrière-plan (retry différé, file d'attente, etc.) — voir gametime-server-architecture-sync-sharing pour le protocole de sync LWW déjà défini côté serveur, qui doit être consommé côté client dans cet esprit.
- Ne jamais bloquer une action locale (créer un exercice, terminer une série, etc.) en attendant une confirmation serveur.