nikserg/skim

Mettre à jour les éléments de démonstration de Skim

Régénère la vidéo de démonstration du produit et les captures d'écran d'interface claire/sombre qui sont livrées avec la page d'accueil. Tout est piloté par la véritable interface utilisateur Skim fonctionnant contre une couche Tauri IPC simulée (demo/mock/), de sorte qu'aucun compte, boîte mail ou modèle réel n'est jamais touché.

Sorties, toutes publiées dans docs/ :

• skim-demo.mp4 — la visite guidée scénarisée des fonctionnalités (1280×800)
• skim-light.jpg, skim-dark.jpg — captures d'écran de l'interface, 800 px de large

Ne pas commit ou push

Cette compétence met uniquement à jour les fichiers sur le disque. N'exécutez pas git add, git commit ou git push. L'utilisateur examine lui-même les ressources régénérées et décide ce qu'il conserve — ce sont des fichiers binaires qui produisent de gros diffs, et une exécution qui semble correcte selon le code de sortie peut toujours être visuellement erronée. Laisser l'arbre de travail sale est le résultat correct.

Ne touchez à git que si l'utilisateur le demande explicitement dans la même requête (par exemple « régénère et commite-les »). Sinon, terminez en indiquant que les fichiers sont mis à jour et non stagingés.

Exécution

Depuis la racine du dépôt :

npm run demo

Cela enchaîne trois étapes : demo:record (Playwright pilote l'interface réelle → demo/output/raw.webm) → demo:encode (ffmpeg → MP4, copié dans docs/) → demo:shots (les deux thèmes → docs/).

Si seule une partie de l'interface a changé, exécutez uniquement ce qui est nécessaire — c'est plus rapide et maintient les ressources non concernées identiques octet par octet :

• npm run demo:shots — captures d'écran uniquement (interface statique, couleurs, changements de mise en page)
• npm run demo:record && npm run demo:encode — vidéo uniquement (flux, comportement de l'IA)

Prérequis : npm install et ffmpeg dans le PATH. L'exécution complète prend quelques minutes ; l'enregistrement est la partie la plus lente.

npm run demo commence par demo:browser (playwright install chromium) — une opération sans effet lorsque le navigateur est déjà présent. Si une exécution échoue avec « Executable doesn't exist at ...chromium_headless_shell-NNNN », cela signifie que la version du navigateur Playwright n'est pas synchronisée avec la version de la bibliothèque (un bump ^ le corrige, et le headless shell est un téléchargement séparé de Chromium). Exécuter npm run demo:browser, ou l'intégralité de npm run demo, résout le problème — inutile de le déboguer comme un problème de démo. Les scripts individuels demo:record / demo:shots ignorent cette vérification.

Vérifier avant de signaler un succès

Une exécution peut se terminer avec le code 0 et produire une vidéo cassée. Une commande simulée non gérée renvoie undefined plutôt que de lever une exception, ce qui s'affiche sous la forme d'un volet vide au lieu d'une erreur — faites donc confiance à vos yeux, pas au code de sortie.

1. Confirmez que les trois fichiers dans docs/ ont des dates de modification récentes.
2. Vérifiez les dimensions : captures d'écran 800 px de large, MP4 1280×800.
3. Extrayez des images de l'ensemble du MP4 et regardez-les réellement. Échantillonnez par fraction plutôt que par secondes fixes — la durée de la visite guidée change à chaque ajout de scène ou ajustement du rythme, donc les horodatages codés en dur se périment :

   dur=$(ffprobe -v error -show_entries format=duration -of csv=p=0 docs/skim-demo.mp4)
   for k in 1 2 3 4 5 6 7; do
     ffmpeg -y -hide_banner -loglevel error \
       -ss $(echo "$dur * $k / 8" | bc -l) -i docs/skim-demo.mp4 -frames:v 1 /tmp/f$k.png
   done
   

   Chaque image doit montrer un volet rempli, et les scènes d'IA doivent contenir leur texte diffusé en continu. demo/output/progress.log nomme chaque scène à sa fin, ce qui permet de faire correspondre une image défectueuse à l'étape qui l'a produite.
4. Visualisez les deux captures d'écran — vérifiez particulièrement la sombre (les corps d'e-mails sont rendus dans une iframe sandboxée avec leur propre logique de thème et peuvent devenir sombre-sur-sombre).

Signalez quels fichiers ont changé et ce que vous avez vu. Si une scène semble incorrecte, corrigez-la plutôt que de la livrer.

Quand la visite guidée se casse après un changement d'interface

Le bac à sable repose sur deux contrats. Le message d'échec vous indique lequel a bougé :

Noms des commandes IPC (demo/mock/tauri-core.ts). Le mock implémente invoke() avec un switch sur les noms de commandes reflétant src/lib/api.ts. Si une commande a été renommée ou ajoutée, ajoutez le case correspondant. Symptôme : un volet vide ou des données manquantes plutôt qu'un crash.

Sélecteurs et libellés en anglais (demo/record.mjs). La visite guidée clique sur des éléments comme .row, .quick-btn:has-text("Summarize"), .ai-input .instruction. Des classes CSS renommées ou des chaînes modifiées dans src/lib/i18n/locales/en.json cassent l'étape correspondante, et le message d'expiration du délai nomme le sélecteur qui a échoué. La démo force locale: "en", donc ce sont les libellés en anglais qui comptent.

Il en va de même pour les fixtures : demo/mock/data.ts fait correspondre les chaînes ai.prompt_* pour décider quelle réponse scénarisée un prompt rapide obtient, et la visite guidée attend des mots distinctifs de ces réponses ("sync", "yours", "4.2"). Reformulez une fixture et l'attente qui en dépend expire.

Toutes les données des fixtures et chaque réponse d'IA scénarisée se trouvent dans demo/mock/data.ts — c'est le fichier à modifier lorsque vous souhaitez que la démo montre quelque chose de différent (différents e-mails, un résumé différent, une réponse rédigée différente).

Éléments non évidents qui vous surprendront lors de l'édition de record.mjs :

• Le corps du compositeur est un <textarea>. Son contenu diffusé en continu est sa valeur, pas son texte — attendez avec waitValue, pas waitText.
• .compose-window textarea correspond également à la zone d'instruction IA (elle vient en premier dans le DOM). Utilisez .compose-window > textarea pour le corps.
• Les scènes de composition naviguent par hash et doivent appeler page.reload() après — un goto basé uniquement sur le hash ne remonte pas la SPA, donc le compositeur n'apparaît jamais.
• Sauvegardez la vidéo avec video.saveAs() avant browser.close(), sinon elle échoue avec « target closed ».

Rythme et thèmes

Les valeurs par défaut sont réglées pour une vidéo d'accueil lisible. Remplacez-les par exécution avec des variables d'environnement (toutes en ms) : DEMO_READ (temps d'arrêt par écran), DEMO_BEAT (entre les actions), DEMO_TYPE (délai de frappe), et DEMO_AI_TYPING / DEMO_AI_THINK / DEMO_AI_STEP (cadence du flux IA). Utile lorsqu'une scène semble précipitée après y avoir ajouté du contenu.

Les thèmes sont à deux axes — "<cold|warm>-<light|dark>", par exemple warm-light (le thème par défaut de l'application). Les deux scripts imposent le thème via localStorage (skimdemo.theme), que le mock renvoie depuis get_settings :

• La vidéo est figée sur warm-light ; remplacez avec DEMO_THEME=cold-dark npm run demo:record.
• Les captures d'écran rendent warm-light → docs/skim-light.jpg et warm-dark → docs/skim-dark.jpg (le tableau SHOTS dans demo/screenshots.mjs fait correspondre thème → nom de fichier).

Attention aux valeurs anciennes à un seul axe : "light" et "dark" sont toujours analysées, mais sont mappées sur la palette cold, donc les passer rend silencieusement la mauvaise température au lieu d'échouer.

DEMO_PREBUILT=1 sert une construction statique depuis demo/dist-demo au lieu du serveur de développement — pratique dans les environnements contraints ou sans tête.

Plus de détails se trouvent dans demo/README.md.