--- issueRef: "#85" version: 5 updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"} updatedAt: 1785311597729 --- ## #85 — Cadrage UX V1 packs partageables (UX, 2026-07-28) Arbitrage Main : avancer, périmètre borné (pas de feed social, pas de marketplace). V1 = extension du partage ciblé existant ([[gametime-server-architecture-sync-sharing]] : `Share`/`ShareRecipient`, inbox accept/decline/revoke), pas une nouvelle surface de découverte publique. ### 1. Surfaces à ajouter/adapter - **Adapter** l'écran de composition de partage existant : ajouter un choix "Séance/programme unique" vs "Pack" au moment de créer un envoi. En mode Pack, sélection multiple de séances-modèles/programmes existants + un nom de pack. Le picker de destinataires reste **identique** à l'existant (comptes déjà connus), aucune recherche/annuaire public ajouté. - **Adapter** l'inbox de partages existante : les entrées de type Pack portent un badge `Pack · n séances` pour se distinguer visuellement d'un partage simple. - **Ajouter** un seul écran nouveau, minimal : détail d'un pack reçu — nom du pack, auteur, liste des séances/programmes inclus (noms seulement), un bouton `Importer`. ### 2. Parcours principal - **Coach** : sélection multiple de séances/programmes existants → nomme le pack → choisit les destinataires parmi ses contacts déjà connectés (mécanique de partage actuelle, pas de découverte publique) → envoie. - **Joueur** : inbox → ouvre l'entrée `Pack · n séances` → écran détail pack → `Importer` (un seul geste, tout ou rien) → chaque séance/programme est copiée dans son espace avec de nouveaux ids, la source de l'émetteur n'est jamais modifiée (règle déjà actée pour le partage ciblé). ### 3. Métadonnées minimales affichées pour un pack - Nom du pack, nom de l'auteur, nombre de séances/programmes inclus, liste des noms inclus, date d'envoi, statut (en attente/importé). - Explicitement absent : description longue, tags/catégories, note, nombre d'imports par d'autres personnes. ### 4. Exclu explicitement de la V1 - Tout catalogue/liste de découverte publique de packs hors de ceux envoyés directement à l'utilisateur. - Commentaires, likes, notes/étoiles. - Monétisation (achat, don, prix). - Import partiel/à la carte du contenu d'un pack : tout ou rien. - Rôle "coach" formalisé au niveau compte (pas de badge, pas de vérification) — un coach est un utilisateur qui envoie à plusieurs destinataires, rien de plus en V1. - Statistiques d'usage des packs (compteur d'imports, popularité). - Mise à jour d'un pack déjà importé si la source change (cohérent avec la règle actuelle : le partage ne modifie jamais la copie du destinataire après import). ### 5. Impacts libellés/navigation - Pas de nouvel onglet de navigation racine ("Découvrir", "Marketplace"...). Tout reste sous les surfaces Partage/Programmes/Séances existantes — c'est ce qui borne explicitement la dérive vers un espace social séparé. - Écran de composition de partage existant : ajout d'un simple sélecteur "Séance/programme" / "Pack", pas de nouvel écran d'entrée. - Inbox existante : badge `Pack · n séances` ajouté, mais le libellé d'action reste `Importer` (même verbe que le partage ciblé simple, pas de nouveau vocabulaire à apprendre). ### Hors périmètre pour Architect/Dev Ce cadrage suppose que `Share`/`ShareRecipient` peuvent porter plusieurs ressources par envoi (pack = un envoi, plusieurs `SyncedResource` liés) plutôt qu'un nouveau concept serveur — à confirmer par Architect avant implémentation, mais pas de nouvelle entité métier proposée côté UX.