HomenShum/NodeKit

NodeKit Present

Transformez les artefacts de développement vérifiés en une présentation vivante. Traitez le diaporama comme une projection du journal des modifications, jamais comme une source indépendante d'affirmations.

Lisez le contrat histoire-changement avant de créer ou de mettre à jour des artefacts de présentation.

Workflow

1. Classez le niveau de changement. Ne créez pas de diaporama pour un travail trivial ; utilisez une carte de changement pour un correctif mineur, un mini-diaporama de 3 à 5 diapositives pour une fonctionnalité majeure, et un diaporama complet accompagné d'une annexe pour les releases ou les hackathons.
2. Créez ou mettez à jour changes/<change-id>/change.yaml. Enregistrez le public, le problème, l'état antérieur, la décision, les alternatives, les systèmes affectés, le workflow utilisateur, les exigences de preuve, les limitations et le niveau de présentation.
3. Capturez les preuves pendant que le travail se déroule : captures d'écran avant et après, commits exacts, identité de déploiement, tests, benchmarks, traces, artefacts, exportations et échecs connus. Conservez les reçus bruts.
4. Construisez un index des preuves. Attribuez à chaque affirmation matérielle un statut et des identifiants de preuve. Étiquetez distinctement les affirmations planifiées, déduites, assertées par l'utilisateur et mesurées.
5. Planifiez chaque diapositive avant de la rendre. Indiquez son objectif, la question du public, le message clé, le rôle narratif, le visuel dominant, les identifiants de preuve, le budget de densité et l'objectif des notes de l'orateur.
6. Utilisez le transport NodeSlide installé dans cet ordre : adaptateur natif du dépôt, CLI NodeSlide, MCP NodeSlide ou API du package. Inspectez d'abord les capacités et ne supposez jamais que les écritures hébergées, l'exportation ou l'approbation sont disponibles.
7. Proposez les modifications du diaporama par rapport à la version épinglée. Validez, comparez et appliquez via la politique de l'hôte ; ne contournez pas la gouvernance de NodeSlide par commodité.
8. Vérifiez chaque affirmation matérielle par rapport au commit ou au déploiement actuel. Rafraîchissez les captures d'écran et les métriques obsolètes. Gardez les limitations visibles.
9. Exportez le format modifiable demandé et rouvrez-le. Vérifiez le diaporama rendu, les notes de l'orateur, les liaisons source et tout allers-retours PPTX.
10. Dérivez le script de démonstration, la section README, les notes de version et le texte de soumission à partir de la même Histoire de Changement et du même Index de Preuves.

Un clip de démonstration est une visite guidée rendue, jamais un enregistrement d'écran

Cette section existe à cause d'un échec mesuré. Un déploiement en production a été vérifié le 11/11 avec un clip enregistré, et ce clip était une capture Playwright brute : pas de cadrage, pas de sous-titres, pas de streaming ni d'appels d'outils visibles, pas de diapositives. Les outils pour chacun de ces éléments existaient déjà et cette compétence n'en nommait aucun, donc ils ont été bricolés plutôt que bien utilisés.

FeatureClipStudio (feature-walkthrough-gif/) est le pipeline capture-vers-rendu, et il couvre les quatre choses qu'une capture brute n'a jamais :

ce qui manque à une capture brute	ce que fait le pipeline
se concentrer sur l'essentiel	caméra zoomant sur l'important, curseur animé glissant vers chaque clic avec une ondulation
l'explication	sous-titres par état des étapes
le travail visible	chargement et streaming capturés EN DIRECT — spinner tournant, résultats arrivant
les éléments internes lorsque l'affirmation en dépend	panneaux de preuves JSON/état brutes

npm run capture   # Playwright pilote le flux en direct et enregistre chaque état UI
npm run studio    # storyboard des états capturés
npm run render    # Remotion rend la visite guidée
npm run judge     # Gemini regarde le RENDU et le note

judge-video.mjs est la porte, et c'est celle qu'il faut exécuter avant de déclarer un clip terminé. Il regarde le MP4 rendu selon une grille anti-héros et renvoie des défauts horodatés à P0/P1/P2 — P0 bloque la publication. Son propre en-tête indique le point : le montage final cesse d'être celui que seuls les yeux humains vérifient. Jugez le MP4 plutôt que le GIF ; le GIF n'est pas un MIME vidéo pris en charge.

N'entrez pas dans une boucle de polissage de re-rendu pour des P2 que le juge a déjà validés.

Deux axes, et le second est celui qui échoue

judge-video.mjs note CRAFT — vérité du curseur, rythme, lisibilité, mouvement — et note séparément COMPREHENSION, les dix choses qu'un spectateur doit absolument retenir :

persona · purpose · use_case · feature_clarity · full_interaction
responsiveness · flow · result · non_expert_sense · transfer

Ils sont orthogonaux, et un montage peut être bien fait et incompréhensible. Mesuré sur un vrai rendu : le craft a passé avec un verdict de publish, et la compréhension a obtenu un score de 1 sur tous les dix — rien d'absent, rien d'explicite, tout simplement implicite — avec le juge indiquant 0:06 comme le moment où un non-expert était perdu ("concepts d'architecture de couches et sorties de logs de terminal").

non_expert_sense est le test de la mère et il BLOQUE tout seul, quels que soient les totaux. Une porte qui laisse passer une vidéo que son propre juge dit incompréhensible pour un non-initié n'est pas une porte. Les scores uniformes sur tous les dix sont signalés plutôt que moyennés, car "tous les 1" signifie tout implicite et rien énoncé, ce qui est un constat et non un passage moyen.

LA BOUCLE EST LA DÉFAUT, pas une vérification finale : rendre, juger, lire ce qui manque, remonter, juger à nouveau. Trois montages sur un même film l'ont fait passer de 10/20 à 13/20 et, plus utilement, ont dit au créateur que l'histoire avait été construite autour du mauvais moment — quelque chose qu'aucune auto-révision n'avait fait émerger. Arrêtez-vous lorsque la compréhension est claire et que les défauts restants sont des P2.

NodeSlide pour le diaporama, NodeVideo pour les preuves au niveau de l'image — une image présentée comme le produit en fonctionnement doit être liée au déploiement dont elle provient, et presentedAs permet de le vérifier.

D'où proviennent les vidéos de référence

Mobbin fonctionne pour l'interface utilisateur car c'est un corpus que l'on OBSERVE et que l'on CITE, jamais que l'on copie. La vidéo a besoin de la même discipline et se divise en deux types, qui ne sont pas interchangeables :

RÉFÉRENCES DE FLUX — ce qu'un vrai produit fait réellement, étape par étape. Page Flows est l'analogue direct : des parcours utilisateur enregistrés plutôt que des captures d'écran, plus de 20 000 applications, organisées par tâche — inscription, mise à niveau, annulation — incluant la boîte de dialogue de consentement, la validation de champ, l'état vide et l'écran de succès. Son propre cadrage est la règle anti-héros vue de l'autre côté : Mobbin montre la destination, Page Flows montre le voyage. ScreensDesign couvre l'intégration et les paywalls avec des signaux de revenus attachés. Utilisez-les pour répondre à "quels états un flux réel de ce type contient-il, et lesquels est-ce que je saute ?"

RÉFÉRENCES DE MÉTIER — comment un film de lancement est construit. Commencez par YouTube. Le juge lit directement une URL YouTube — vérifié : Gemini en a regardé une et a décrit ses premières secondes et sa durée à partir de la seule URL, sans téléchargement. Donc une référence est CITÉE, jamais copiée, ce qui dissout entièrement la question de licence et fait du localisateur une URL plus un horodatage :

L'agent construit son propre corpus plutôt que d'attendre qu'on lui en donne un. yt-dlp RECHERCHE sur YouTube et lit les métadonnées ; rien n'est téléchargé, et Gemini regarde l'URL :

node find-references.mjs "Raycast product demo" "Linear product demo"   # recherche, triage, observation
node judge-video.mjs out/demo.mp4                                       # corpus utilisé automatiquement
node judge-video.mjs out/demo.mp4 --no-reference                        # désactivation

find-references.mjs effectue un TRIAGE AVANT de dépenser des tokens : tout ce qui dépasse 180s est rejeté par défaut comme étant de la mauvaise forme et du mauvais coût pour une courte visite guidée, avec la raison imprimée. Mesuré sur un vrai run — une démo first-party de 39s a coûté 3,9k tokens de prompt, une de 18 minutes 102k. Il écrit ensuite references/video/<id>.json : des faits atomiques horodatés (0:07 motion — les touches deviennent vertes à la pression), hookSeconds, statesShown, whatToSteal et whatNotToSteal, plus une liste notRun pour tout ce qu'il n'a pas pu déterminer. Des faits, jamais des adjectifs — un fait note un candidat, un adjectif ne le peut pas.

Le verdict gagne un bloc reference — singleMoment, statePacing, motionPurpose, whatToSteal et whatNotToSteal — avec un horodatage requis pour chaque affirmation concernant la référence. Chaque film de lancement de produit digne d'être étudié est déjà sur YouTube et constitue la source principale ; les bibliothèques organisées ci-dessous sont une couche de découverte par-dessus, utile pour TROUVER des candidats plutôt que pour les regarder.

Le coût est réel : une référence de 18 minutes a mesuré 102k tokens de prompt. Préférez un extrait de 30 à 90 secondes, et passez au maximum deux ou trois références.

FlowJam est une bibliothèque de vidéos SaaS et de lancement de produits triées sur le volet ; la bibliothèque de Tella et les analyses de Vidico publient des exemples avec le raisonnement attaché. Utilisez-les pour le rythme, le moment unique et là où le mouvement fait le travail par opposition à la décoration.

Ne collez aucun des deux types dans la grille d'évaluation sous forme de prose. Enregistrez-les comme on enregistre une observation Mobbin : un fait atomique, avec un locatorDescription qui pour la vidéo est un HORODATAGE, cité à l'URL source. L'affirmation est "à 0:12 l'état de chargement est maintenu pendant 1,4s avant le résultat", pas "leur rythme est bon". Une règle dérivée d'une observation horodatée peut être notée ; un adjectif ne le peut pas.

Licence : observez et attribuez, jamais ne ré-hébergez. licenceMode dans le schéma d'observation est une valeur unique énumérée à dessein — l'étendre à une nouvelle classe de source est une révision de licence et une modification délibérée du schéma, pas une chaîne de caractères tapée.

Un film de lancement est dirigé, puis rendu — le contrat vidéo-lancement

Tout ce qui précède juge un montage qui existe déjà. Un film de LANCEMENT échoue plus tôt que cela : il est construit autour du mauvais moment, ou livré après le lancement, et aucune boucle de juge ne peut rattraper ni l'un ni l'autre. Étudié en direct chez Motion Studio (films de lancement pour startups de niveau YC) : leur processus est Direction → Premier brouillon → Révisions → Livraison, et "un réalisateur humain prend chaque décision de goût". Cet ordre est le produit. nodekit launch-video le porte comme un contrat révocable, de sorte qu'un agent de codage piloté parcourt les étapes au lieu de sauter à npm run render :

nodekit launch-video declare --application <slug> --out launch-video.json
# 1 BRIEF      remplir le produit, l'histoire (mots des parties prenantes), le public, launchDate, canaux
# 2 DIRECTION  singleMoment, beats ordonnés, références via find-references.mjs (faits
#              horodatés, jamais d'adjectifs), durationTargetSeconds ≤ 180 — puis un HUMAIN approuve
# 3 BROUILLONS capture → studio → rendu (FeatureClipStudio ou NodeVideo), judge-video.mjs sur
#              le MP4, enregistrer le cycle : cut, judge scores, humanNotes, disposition
# 4 LIVRAISON  finalCut + judgeReceipt + approbation humaine, deliveredAt AVANT launchDate
nodekit launch-video check --contract launch-video.json   # refuse à chaque sortie d'étape

Ce que le check refuse, et pourquoi chaque refus existe :

• des brouillons avant une direction approuvée — le premier montage s'aligne sur une direction, il n'en découvre pas une ; un rendu fait avant le retour de la direction est la facture de révision.
• une affirmation de référence sans horodatage — "leur rythme est bon" ne peut pas être noté ; "à 0:12 l'état de chargement dure 1,4s" le peut.
• un cycle final échouant à non_expert_sense — le test de la mère bloque la livraison seul, même règle que la boucle du juge ci-dessus ; le contrat en fait une sortie d'étape plutôt qu'un conseil.
• deliveredAt après launchDate — un film de lancement livré après le lancement est une rétrospective.
• la livraison sans approbation humaine — le juge est consultatif ; la décision de goût est une personne.

La boucle du juge reste la boucle interne de l'étape 3 exactement comme décrit ci-dessus. Le contrat ajoute ce que la boucle seule n'a jamais retenu : les étapes dans l'ordre, l'humain aux deux portes du goût, et la date.

Voie parallèle

Pour une implémentation importante, exécutez le travail de présentation comme une voie principalement en lecture à côté de la construction et de l'assurance qualité. Rédigez le problème et l'architecture tôt ; remplacez les espaces réservés uniquement par des preuves vérifiées issues des étapes ultérieures. Bloquez la release uniquement en cas d'affirmations non étayées, de preuves requises manquantes, de preuves obsolètes ou d'un export défaillant.

Langage d'achèvement

• Dites drafted lorsque les plans de diapositives existent.
• Dites evidence-bound lorsque chaque affirmation matérielle renvoie à une preuve actuelle.
• Dites export-verified uniquement après que le résultat demandé s'est rouvert avec succès.
• Dites release-ready uniquement lorsque la preuve de l'application et la preuve de la présentation passent toutes deux.

Ne transformez pas un test unitaire vert en affirmation de production, un HTTP 200 en preuve navigateur, ou un jugement de modèle consultatif en verdict faisant autorité.