choism4/oh-my-demo

Oh My Demo

Enregistrez l'application réelle en une seule prise. Évitez la post-production.

Considérez cette compétence comme une couche de répétition et de préparation autour de l'application hôte, et non comme un générateur d'applications factices. Préparez l'état de départ, les indices pour l'opérateur, le rythme, les fixtures déclarées et le chemin de réinitialisation afin que l'utilisateur puisse appuyer sur "enregistrer" et terminer la visite guidée sans devoir couper après les échecs. Préservez l'interface utilisateur de production, la navigation, les commandes, l'état local et la logique métier disponible. Remplacez uniquement la plus petite frontière lente, coûteuse, distante, instable ou inachevée nécessaire pour un enregistrement fiable.

Flux par défaut

Résolvez SKILL_ROOT vers le répertoire contenant ce fichier, puis exécutez la CLI fournie avec python3 "$SKILL_ROOT/scripts/oh_my_demo.py".

1. Inspectez le dépôt, son harnais de test, les fixtures existantes et le chemin exact visible par l'utilisateur à enregistrer. Inspectez l'état git et les diffs pertinents avant de modifier quoi que ce soit.

2. Créez une branche dédiée ou un espace de travail isolé. Ne mettez jamais de substitution de fixture réservée à la démo sur la branche de production.

3. Initialisez le kit du projet :

   python3 "$SKILL_ROOT/scripts/oh_my_demo.py" init . --name product-tour
   

4. Construisez un registre de vérité dans .oh-my-demo/manifest.json. Classez chaque affirmation comme :

   • real (réelle) : l'application visible exécute son implémentation de production.
   • simulated (simulée) : une frontière déclarée renvoie des données de fixture déterministes.
   • operator (opérateur) : assistance à l'enregistrement telle que le remplissage de texte, le rythme ou la réinitialisation ; n'incluez pas ces commodités dans le pourcentage de vérité.

5. Maintenez la part réelle pondérée à au moins 80%. Réduisez l'affirmation ou implémentez davantage du chemin réel lorsqu'une fonctionnalité phare simulée dépasserait le budget. Ne manipulez pas les pondérations pour le dissimuler.

6. Inventoriez chaque entrée, référence, fixture, résultat et référence de base. Copiez les ressources de démonstration sous .oh-my-demo/ ou une autre racine de manifeste plutôt que de les lier à des chemins absolus spécifiques à la machine d'un opérateur. Pour les grands médias, choisissez Git LFS ou un package d'artefact authentifié à somme de contrôle et matérialisez-le localement avant la vérification préliminaire.

7. Donnez aux contrôles visibles des cibles sémantiques stables. Privilégiez les identifiants d'accessibilité, les identifiants de test ou un registre hôte plutôt que des sélecteurs CSS générés ou des coordonnées.

8. Ajoutez uniquement le plus petit adaptateur hôte nécessaire pour amorcer l'état, restaurer une référence de base ou satisfaire le contrat de frontière de production. Gardez les noms spécifiques au produit en dehors du runtime réutilisable du manifeste.

9. Modélisez la prise comme des étapes conscientes de l'état et déclenchées explicitement. Centralisez les intervalles de saisie, le temps de chargement lisible, les révélations échelonnées et les repositionnements de la zone d'affichage. Ne passez jamais à l'étape narrative suivante sans déclenchement humain.

10. Exécutez les diagnostics et échouez en sécurité avant d'ouvrir l'application :

    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" doctor .
    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" status .
    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" check . --record
    

11. Répétez en parcourant l'application réelle visible à la vitesse de narration. Vérifiez les états en attente, les révélations de résultats, les mutations accumulées, la liaison audio/vidéo et la réponse de la zone d'affichage avant de passer à l'étape suivante.

12. Réinitialisez et répétez la prise identique au moins deux fois. Incluez au moins un passage opéré par un humain ; l'automatisation seule ne peut pas prouver que le public perçoit le comportement.

13. Liez les preuves au manifeste exact et validez-les :

    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" prove .
    

14. Exécutez une vérification ciblée avec la production désactivée. Confirmez que l'activation de la démo est désactivée par défaut et que les builds normaux ne résolvent pas silencieusement les données de fixture.

15. Rapportez trois listes distinctes : comportements réels, frontières simulées et commodités d'opérateur. Classez comme travail produit de suivi uniquement les affirmations produit simulées, pas les contrôles de démo.

Surfaces intégrées

Utilisez la CLI comme colonne vertébrale déterministe :

• init : crée .oh-my-demo/manifest.json, evidence.json et fixtures/.
• doctor : diagnostique Python, l'espace de travail git, la branche, le manifeste, l'outillage multimédia et l'activation explicite.
• status : affiche le budget de vérité pondéré et les frontières simulées.
• check : vérification préliminaire de la branche, de la révision de base, des actifs, des hachages, de la durée des médias, des plages de fin, des métadonnées de rotation, des chemins Unicode et de la liaison des fixtures.
• prove : exige deux passes de réinitialisation et rejeu, une passe d'opérateur visible par un humain, une liaison de résumé du manifeste et une isolation de la production désactivée.

Utilisez le raisonnement de la compétence pour inspecter et modifier l'application hôte. Ne prétendez pas que la CLI peut implémenter elle-même des adaptateurs spécifiques à un framework.

Contrat d'exécution

Gardez le vocabulaire d'actions réutilisable restreint :

focus, set-value, type-text, click, submit, navigate, wait, resolve-fixture, repeat, reset, assert et invoke-adapter.

Mappez les opérations du domaine aux adaptateurs appartenant à l'hôte. Une édition de canevas, une amorce de base de données, une insertion de chronologie, un geste mobile ou une commande TUI reste un invoke-adapter ; l'implémentation hôte possède ses types réels et son comportement.

Pour les champs de texte, résolvez une cible de texte déclarée ou un élément éligible focalisé, rejetez les champs sensibles, focalisez-le, mettez à jour via le chemin d'état contrôlé du framework lorsqu'il est disponible, et soumettez uniquement lorsqu'il est explicitement demandé.

Contrat de sécurité

• Exigez une activation explicite à l'exécution et une branche de démo dédiée.
• Exigez un déclencheur humain pour chaque étape enregistrée.
• Interdisez la publication en direct, la messagerie, la facturation, le débit ou tout autre effet secondaire distant à partir de flux scénarisés.
• Ne contournez jamais les contrôles d'authentification, d'autorisation, de politique de modèle, de comptabilité de jetons, de signature ou de version.
• Ne remplissez jamais les mots de passe, jetons, données de paiement, codes de récupération ou champs de type secret.
• Réinitialisez uniquement l'état déclaré dans le manifeste ou un instantané versionné appartenant à l'hôte. Ne ciblez jamais un répertoire personnel, une racine de dépôt, une variable non résolue, un caractère générique ou un chemin en dehors de la racine déclarée.
• Considérez une fixture comme une preuve du chemin consommateur uniquement, jamais comme une preuve que son producteur distant fonctionne.
• Masquez les éléments de débogage uniquement lorsqu'ils ne sont pas pertinents pour l'affirmation produit. Ne masquez jamais un fait pertinent pour ce qui est communiqué au public.

Routage des références

Lisez references/distribution.md pour décider comment la compétence, la CLI, le kit de projet et les adaptateurs hôtes se répartissent les responsabilités.

Lisez references/manifest-schema.md lors de la création ou de l'extension de .oh-my-demo/manifest.json.

Lisez references/adapters-and-safety.md avant d'implémenter un adaptateur hôte, une frontière de fixture, un chemin de réinitialisation ou une intégration de champ de texte.

Lisez references/rehearsal.md avant la première exécution complète, après une prise échouée ou lorsqu'une mutation réussit mais n'est pas perceptible.

Lisez references/evidence-schema.md avant de déclarer la démo reproductible ou de remplir .oh-my-demo/evidence.json.

Porte d'achèvement

Ne considérez pas la configuration comme terminée tant que toutes les conditions suivantes ne sont pas remplies :

• doctor, status et check réussissent sur la branche de démo dédiée ;
• la part réelle pondérée est d'au moins 80% ;
• chaque affirmation simulée a une provenance, un point d'injection étroit, son équivalent de production et une assertion visible ;
• la réinitialisation restaure le même état initial deux fois ;
• au moins une répétition opérée par un humain est perceptible à la vitesse de narration ;
• prove réussit par rapport au résumé final du manifeste ;
• le mode démo est confirmé désactivé dans le chemin de production.