Onboarding : montrer la valeur avant de demander un compte

# Applique le guide « Onboarding : montrer la valeur avant de demander un compte » dans ton agent

## Objectif
Pars du plus petit résultat utile qu’une personne peut obtenir. Demande un compte quand un accès privé ou une sauvegarde entre appareils le nécessite. Distingue démonstration et travail enregistré ; explique ce qui survit au départ avant de demander un effort.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Choisis un essai invité, une première tâche guidée ou une connexion obligatoire sans perdre le travail.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Définir le premier résultat utile — Pour un planificateur de repas, le résultat peut être un menu hebdomadaire d’exemple. Ouvrir cinq diapositives est une activité, pas une preuve de valeur. Écris un résultat observable avant de concevoir l’accueil. Liste ses besoins : exemples, préférences, accès et persistance. Signale les données fictives et propose de recommencer. Ne remplis pas un nouveau compte avec un faux historique présenté comme réel.
- 2. Choisir la frontière du compte — Utilise une démonstration invitée pour explorer des données publiques jetables. Demande la connexion pour accéder à des données privées hébergées dont les droits dépendent de ton identité. Un travail privé conservé localement peut rester sans compte si sa protection locale suffit. Le parcours invité ne contourne jamais les autorisations. Explique pourquoi la connexion devient nécessaire : sauvegarder entre appareils, inviter ou consulter du contenu privé. Ne collecte pas de champs de profil inutiles pour remplir le parcours.
- 3. Exemple : essayer un menu — Sépare « Essayer un menu » et « Ouvrir mes menus ». Permets de remplacer un repas et consulter les courses. Centre l’action principale sur ce résultat plutôt que sur la visite de toutes les fonctions. À « Conserver ce menu », explique le stockage. Si la reprise invitée existe, transfère la version modifiée après connexion et réaffiche-la. Sinon annonce la limite avant saisie, sans abandon silencieux du travail.
- 4. Reprendre après interruption — Une introduction passée reste accessible dans l’aide. Conserve la destination après connexion. Si la session expire, distingue le brouillon local des données acceptées par le service. Si la connexion échoue, garde les champs autorisés du brouillon et un retour sûr. N’annonce pas une sauvegarde dans le compte avant confirmation du service. Explique les limites locales et des appareils partagés.
- 5. Vérifier la promesse — Exerce les parcours invité, retour et connexion échouée. Rouvre la saisie, utilise Retour et le clavier à largeur étroite. Vérifie les données conservées, pas seulement un libellé de succès. Ce guide cadre une décision produit, pas la sécurité d’identité ni une preuve de conversion. Une réussite automatisée établit le fonctionnement ; adoption et apprentissage demandent d’autres preuves.

## Critères d’acceptation — Vérifier dans ton produit
- Nomme le premier résultat utile.
- Identifie les données d’exemple.
- Explique pourquoi le compte est nécessaire.
- Conserve la saisie promise.
- Ne prétends pas réussir après une panne.
- Vérifie passer, retour et clavier.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Ancre le guide dans le projet

## Objectif
Transforme les étapes appliquées en conventions durables du dépôt.

## Contrôles
- Relie chaque décision prise à l’étape du guide qui la justifie.
- Ajoute la checklist aux revues concernées.
- Note les cas hors périmètre pour les guides voisins.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:66052e7152ce259606477d73c68251964c8759190719dd4a510f3a122acca7cc

# Diagnostique une application ratée du guide « Onboarding : montrer la valeur avant de demander un compte »

## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]

## Contrôles observables
- Rejoue les étapes dans l’ordre et note la première qui diverge :
- 1. Définir le premier résultat utile — Pour un planificateur de repas, le résultat peut être un menu hebdomadaire d’exemple. Ouvrir cinq diapositives est une activité, pas une preuve de valeur. Écris un résultat observable avant de concevoir l’accueil. Liste ses besoins : exemples, préférences, accès et persistance. Signale les données fictives et propose de recommencer. Ne remplis pas un nouveau compte avec un faux historique présenté comme réel.
- 2. Choisir la frontière du compte — Utilise une démonstration invitée pour explorer des données publiques jetables. Demande la connexion pour accéder à des données privées hébergées dont les droits dépendent de ton identité. Un travail privé conservé localement peut rester sans compte si sa protection locale suffit. Le parcours invité ne contourne jamais les autorisations. Explique pourquoi la connexion devient nécessaire : sauvegarder entre appareils, inviter ou consulter du contenu privé. Ne collecte pas de champs de profil inutiles pour remplir le parcours.
- 3. Exemple : essayer un menu — Sépare « Essayer un menu » et « Ouvrir mes menus ». Permets de remplacer un repas et consulter les courses. Centre l’action principale sur ce résultat plutôt que sur la visite de toutes les fonctions. À « Conserver ce menu », explique le stockage. Si la reprise invitée existe, transfère la version modifiée après connexion et réaffiche-la. Sinon annonce la limite avant saisie, sans abandon silencieux du travail.
- 4. Reprendre après interruption — Une introduction passée reste accessible dans l’aide. Conserve la destination après connexion. Si la session expire, distingue le brouillon local des données acceptées par le service. Si la connexion échoue, garde les champs autorisés du brouillon et un retour sûr. N’annonce pas une sauvegarde dans le compte avant confirmation du service. Explique les limites locales et des appareils partagés.
- 5. Vérifier la promesse — Exerce les parcours invité, retour et connexion échouée. Rouvre la saisie, utilise Retour et le clavier à largeur étroite. Vérifie les données conservées, pas seulement un libellé de succès. Ce guide cadre une décision produit, pas la sécurité d’identité ni une preuve de conversion. Une réussite automatisée établit le fonctionnement ; adoption et apprentissage demandent d’autres preuves.

## Causes possibles
- Une étape a été sautée ou exécutée hors ordre.
- Le besoin réel sort du périmètre du guide.
- Un critère de la checklist n’a jamais été vérifié.

## Corrections bornées
- Reprends uniquement l’étape divergente et ce qui en dépend.
- Documente l’écart si le périmètre du guide ne couvre pas le besoin.

## Vérification finale — Vérifier dans ton produit
- Nomme le premier résultat utile.
- Identifie les données d’exemple.
- Explique pourquoi le compte est nécessaire.
- Conserve la saisie promise.
- Ne prétends pas réussir après une panne.
- Vérifie passer, retour et clavier.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Préviens la prochaine dérive

## Objectif
Fais de la première étape divergente un contrôle explicite du projet.

## Contrôles
- Ajoute un contrôle ciblé sur l’étape qui a divergé.
- Vérifie la checklist sur un second cas réel.
- Documente la limite de périmètre rencontrée.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:cca6a9d286a3872abeddc00b757e998721cb4816090b8e806fe2e32e72d5e4fc