motion-retrospective

Rétrospective Motion

Chaque projet terminé devrait laisser l'agent meilleur qu'il ne l'a trouvé. Lorsqu'un rendu est confirmé, passez en revue l'ensemble de la construction pendant que les preuves sont encore dans l'exécution (les commandes traitées sont supprimées après 7 jours) et transformez-les en connaissances que la prochaine session pourra réutiliser.

Déclencheur

Lancez cette compétence dans le même tour où l'utilisateur confirme un rendu/export final, par exemple : "渲染好了 / 导出了 / 就这版 / ship it / looks good, exporting". Le pont ajoute également bridgeHealth.retrospective au résultat de toute commande de rendu comme rappel. N'attendez pas qu'on vous le redemande.

Étapes

1. Collectez. Notez quand la session a commencé, puis exécutez :

   python3 tools/retrospective.py --slug <nom-du-projet> --since <début de session ou p. ex. 6h> [--match "<nom du comp principal>"]
   

   Cela écrit cases/_inbox/<date>-<slug>/ avec TIMELINE.md, FAILURES.md, scripts/ (chaque script mutant réussi, dédoublonné) et stats.json.

2. Capturez des preuves. Prenez 4 à 6 images du rendu final (captureFrame ou tools/run_capture.sh) et construisez une planche contact avec tools/sheet.py. Sauvegardez dans evidence/. Ne commettez jamais la vidéo, le .aep, les images ou polices du client.

3. Passez en revue la chronologie. Pour chaque série de commandes, notez :

   • ce que l'utilisateur a demandé (d'après la conversation), ce qui a changé, et quel script l'a fait ;
   • le mécanisme, pas seulement l'apparence (structure du rig, expression, valeurs clés, ordre des calques) ;
   • les chiffres qui ont fait fonctionner (durées, influence de l'easing, décalages, tailles) ;
   • chaque échec dans FAILURES.md : sa cause et la correction.

4. Séparez en recettes. Un projet contient généralement plusieurs techniques réutilisables. Donnez à chacune son propre dossier cases/<catégorie>/<technique>/ (catégories : text-animation, shape-animation, ui-animation, transitions, effects) avec RECIPE.md, un .jsx nettoyé et réutilisable, PROMPT_TEMPLATE.md et des preuves. Conservez un index de projet dans cases/projects/<projet>/RECIPE.md qui les relie, comme sync-dubbing-studio. Séparez les noms de calques spécifiques au projet de la méthode transférable.

5. Promouvez les règles. Copiez tout ce qui s'applique au-delà de ce projet dans skill/SKILL.md : nouveaux pièges (坑位速查), nouvelles traductions des retours utilisateur (反馈翻译表) et l'index des recettes. Cochez ou ajoutez des éléments dans LEARNING_MAP.md. Mettez à jour le nombre de cas et le tableau des projets dans README.md / README.zh-CN.md lorsqu'ils changent.

6. Publiez.

   tools/publish_case.sh cases/<catégorie>/<technique> "ce qui a été appris" --push
   

   Le script nettoie les chemins /Users/<nom>/, refuse les fichiers vidéo/audio/.aep, exécute tools/health_check.py, commit et pousse. Ne poussez automatiquement que si le propriétaire du dépôt a opté (MOTION_AGENT_AUTO_PUBLISH=1, ou s'il l'a demandé) ; sinon, commitez et demandez.

7. Rapportez à l'utilisateur en quelques lignes : combien de recettes ont été ajoutées, quelles règles ont été promues, et le lien du commit.

Barre de qualité

• Une recette nomme le mécanisme et donne les chiffres que quelqu'un peut reproduire.
• Chaque piège explique ce qui a cassé, pourquoi, et la correction.
• Aucun actif client, chemin privé ou matériel non publié dans le dépôt public.
• Si le projet n'a rien appris de nouveau, dites-le et ajoutez uniquement les preuves à un cas existant.