Mosin112/build-prototype

Étape 4 · Prototype cliquable

Le prototype permet aux parties prenantes de ressentir les arbres comportementaux avant que l'ingénierie ne commence. Il s'agit d'une démonstration du contrat, pas d'un cahier des charges de conception : il doit montrer chaque branche, y compris les erreurs et les cas limites, pas seulement le chemin heureux.

À lire en premier : les arbres approuvés dans work/<item>/03-trees/, le concept, context/product.md et context/writing-style.md. Utilisez ../../examples/price-alerts/04-prototype/index.html (relatif à cette compétence) comme implémentation de référence de la structure ci-dessous.

Exigences

1. Un seul fichier autonome : work/<item>/04-prototype/index.html. Inlinez tout le CSS et le JS. Pas d'étape de build, aucune requête externe à l'exception des polices web optionnelles, afin qu'il puisse être ouvert depuis le disque, attaché à un ticket ou publié sous forme de lien.

2. Écrans : chaque état distinct est un élément avec data-screen="<id>". Un seul est visible à la fois. La navigation se fait via les propres boutons du prototype, comme le produit réel.

3. Contrôles de scénario : un panneau latéral, clairement séparé de l'interface utilisateur du produit, avec des bascules pour chaque état while et condition if dans les arbres (vérifié/non vérifié, limite atteinte, notifications désactivées, simuler un mouvement de prix…). Modifier une bascule doit changer ce que fait l'interface utilisateur du produit, afin que chaque branche soit accessible.

4. Carte de couverture : un bloc <script type="application/json" id="tree-coverage"> qui fait correspondre chaque ligne then et and de chaque arbre à l'écran qui la démontre :

   {
     "trees": {
       "functional/price-alert-creation": [
         { "line": "then the alert is saved as active", "screen": "alerts" },
         { "line": "and the alert's direction is set to above or below the current price", "screen": "alerts" }
       ],
       "functional/price-alert-trigger": [
         { "line": "then no further notification is sent", "screen": null, "reason": "Not visible: absence of a notification" }
       ]
     }
   }
   

   screen: null n'est autorisé qu'avec une reason (résultats en backend ou "rien ne se passe").

5. Panneau de couverture visible : affichez la carte de couverture dans le panneau latéral sous forme de liste de contrôle des lignes de l'arbre ; cliquer sur une ligne saute vers son écran avec le bon scénario défini. C'est ce qui fait du prototype un outil de révision.

6. Copie réaliste : utilisez les messages exacts des arbres. Marquez les données d'exemple comme des données d'exemple.

7. Marque : suivez les tokens de conception dans context/product.md ; sinon, utilisez un style neutre et accessible. Fonctionne à la largeur d'un téléphone. Focus clavier visible.

Vérification

Exécutez python3 .pm-harness/pm_check.py prototype work/<item>/03-trees work/<item>/04-prototype/index.html. Il échoue si une ligne de l'arbre est absente de la carte de couverture ou pointe vers un écran qui n'existe pas. Corrigez jusqu'à ce qu'il réussisse.

Validation

Faites parcourir au Chef de Produit l'arbre de Parcours dans le prototype, puis toute branche de son choix. Recueillez les retours. Si les retours modifient le comportement, mettez d'abord à jour les arbres, relancez la vérification des arbres, puis mettez à jour le prototype. Lorsque le Chef de Produit approuve, définissez stage: prototype dans 01-idea.md et proposez /pm-harness:create-eng-tickets. Si l'équipe du Chef de Produit utilise Figma pour la conception finale, mentionnez quels écrans un designer doit reprendre.