GameTime/.ideai/tickets/85/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#85	5	kind agent_id agent 57695b92-24d0-4876-837c-76116e70a6ae	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.