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

41 lines
3.6 KiB
Markdown

---
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.