kaustubhupadhyaya/phone-reel-pipeline

Que fait phone-reel-pipeline ?

Le pipeline complet Android → reel Instagram. Le téléphone fournit les séquences (et eventuellement l'inspiration tendance) ; le PC réalise tout le montage ; le téléphone reçoit le reel final que l'utilisateur publie manuellement. Ce skill orchestre ses skills frères — il ne contient aucun script propre et ne duplique aucune de leurs logiques. Un seul appel exécute toute la chaîne : l'agent déverrouille lui-même le téléphone (code PIN du coffre, sans intervention manuelle) et navigue lui-même dans l'application Edits lorsque l'inspiration est souhaitée.

Skills frères dans ce dépôt — phone-reel-pipeline les achemine, ne les réimplémentez pas : phone-media-bridge gère la connexion de l'appareil plus le déverrouillage de l'écran de verrouillage plus l'extraction/le renvoi des médias, ig-edits-inspiration gère l'inspiration depuis l'application Edits (capture en lecture seule plus navigation autonome sur un téléphone déverrouillé), reel-maker gère la construction du reel sur PC (et délègue elle-même à clip-picker et video-tool-router — n'appelez jamais ces deux-là directement depuis ici). Lisez le SKILL.md du skill frère à son chemin relatif avant chaque phase ; leurs documentations sont faisant autorité pour les drapeaux, chemins et pièges.

Quand utiliser

Déclencheurs : "reel de bout en bout depuis le téléphone", "crée un reel à partir de mes séquences téléphoniques", "du téléphone au reel", "extrais du téléphone et crée un reel", ou toute tâche qui traverse appareil → PC → appareil en une seule exécution.

PAS pour :

• Montage purement PC avec des séquences déjà sur le disque et sans téléphone → invoquez reel-maker directement.
• Inspiration uniquement ("qu'est-ce qui est tendance", "feuille de route pour ce montage", pas de construction) → invoquez ig-edits-inspiration directement.
• Publication → toujours l'utilisateur, sur le téléphone, manuellement. Aucun skill dans ce dépôt ne publie, ne planifie ou ne télécharge quoi que ce soit — la publication automatique a été explicitement refusée.

Flux de travail

Phase 0 — Vérification de l'appareil + déverrouillage

Exécutez adb devices -l. Localisez adb via la chaîne des scripts pont (drapeau --adb, variable d'environnement ADB, PATH, puis solution de repli WinGet platform-tools). Si la liste des appareils est vide, ARRÊTEZ-VOUS et imprimez cette liste de vérification pour l'utilisateur :

1. Sans fil : téléphone sur le même Wi-Fi que le PC, débogage sans fil ACTIVÉ (re-associer avec le code + adb connect <ip>:<port> si la connexion est perdue).
2. USB : câble compatible données (pas de charge uniquement), mode Transfert de fichiers (MTP), débogage USB activé, invite d'empreinte RSA acceptée sur le téléphone.

Si l'appareil apparaît comme unauthorized, ne continuez pas — demandez à l'utilisateur d'accepter l' invite RSA sur le téléphone, puis ré-exécutez adb devices -l. Continuez uniquement une fois que l'appareil apparaît comme device. Déverrouillez ensuite pour l'exécution autonome (aucune intervention manuelle nécessaire) :

C:\Python314\python.exe %USERPROFILE%\GitHub\editor-pack\skills\phone-media-bridge\scripts\unlock.py

ALREADY_UNLOCKED → continuez. VAULT_ENTRY_MISSING → collectez phone-1:password via la popup du coffre (python "%USERPROFILE%\.agents\skills\secure-vault\vault.py" gui --request "phone-1:password"), puis ré-exécutez. Règles complètes dans phone-media-bridge Phase 0b.

Phase 1 — Inspiration (OPTIONNELLE, uniquement si l'utilisateur souhaite des montages guidés par les tendances)

Posez une question : guidé par les tendances (inspiration Edits) ou construction directe (lien de référence ou libre) ? Si l'utilisateur souhaite un guidage par les tendances, déléguez à ig-edits-inspiration : elle capture depuis l'application Edits (capture en lecture seule privilégiée ; navigation UI autonome autorisée sur le téléphone déverrouillé selon sa doctrine) et renvoie une recette formatée pour reel-maker. Cette recette devient la spécification de construction pour la Phase 3. Demander à l'utilisateur de naviguer lui-même dans Edits est la solution de repli rapide, pas une exigence — l'agent conduit lorsque l'utilisateur ne l'a pas fait. Si l'utilisateur ignore l'inspiration, passez directement à la Phase 2 — reel-maker Phase 1 accepte déjà un lien de référence, donc tout lien fourni par l'utilisateur voyage avec la délégation inchangé.

Phase 2 — Extraction des médias

Déléguez à phone-media-bridge : exécutez son étape d'inventaire, puis affichez à l'utilisateur un résumé compact par dossier (nom du dossier, nombre de clips, taille totale — pas un listing complet des fichiers) et posez UNE question (sélection multiples) concernant les dossiers/clips à extraire. Exécutez ensuite son étape d'extraction. Les séquences extraites atterrissent dans la jonction skills\phone-media-bridge\scripts\phone_pull (physiquement sur D:\EditorPackArchive). Les séquences restent sur D: — les éditeurs lisent depuis là, ne les copiez jamais sur C:. Reprise sûre : si le téléphone est débranché en cours d'extraction, ré-exécutez l'extraction ; voir Pièges.

Phase 3 — Construction sur PC

Invoquez le flux reel-maker avec la recette de la Phase 1 (ou lien de référence) plus le dossier de séquences de la Phase 2. reel-maker délègue à clip-picker + video-tool-router elle-même — ne dupliquez pas ce routage ici. Deux choses à transmettre explicitement : (a) les séquences téléphoniques sont souvent HEVC/HDR, donc la protection video-tool-router HLG 10 bits s'applique (mappage tonal avant correction des couleurs/gravure des sous-titres, sinon les couleurs se délavent) ; (b) le décodage HEVC est lent, donc attendez-vous à ce que la Phase 3 domine le temps d'exécution (voir les pièges de clip-picker).

Phase 4 — Renvoi (BARRIÈRE D'APPROBATION)

RÈGLE STRICTE : NE JAMAIS renvoyer quoi que ce soit vers le téléphone sans l'approbation explicite de l'utilisateur pour ce fichier exact lors de cette exécution. Terminer la Phase 3 n'implique PAS la autorisation de renvoyer. Arrêtez-vous à la fin de la Phase 3 et rapportez le(s) chemin(s) local(aux) sur PC, la durée et la taille ; demandez "renvoyer vers le téléphone ?" et continuez uniquement sur un oui. Une instruction générique "crée des reels" ne compte jamais comme une approbation de renvoi.

Une fois approuvé, déléguez à l'étape de renvoi de phone-media-bridge (push_reel.py) : renvoyez le fichier reel_<nom>_vN.mp4 terminé vers /sdcard/Movies/Reels sur le téléphone. Vérifiez que le fichier existe sur l'appareil (adb shell ls) et rapportez sa taille en octets par rapport à la copie PC.

Phase 5 — Remise (l'utilisateur publie)

Exécutez l'étape de phone-media-bridge qui ouvre Instagram sur le téléphone (push_reel.py --open-app). Puis ARRÊTEZ-VOUS : l'UTILISATEUR publie, manuellement, dans l'application Instagram. JAMAIS de publication automatique — explicitement refusée. Rapportez : le chemin du reel (chemin téléphone + chemin PC), le numéro de version, et une courte liste de ce qu'il faut vérifier avant de publier (légendes lisibles, audio présent, rapport d'aspect correct).

Sortie

• reel_<nom>_vN.mp4 sur le téléphone (/sdcard/Movies/Reels/) + la copie PC conservée dans le dossier du projet (versionnée ; ne jamais écraser v1).
• Un rapport de statut de bout en bout : par phase : réussi / ignoré / échoué, durées horloge murale par phase, quel skill frère a géré chaque phase, et mises en garde honnêtes (voir ci-dessous). Exemple de forme : Phase 0 réussie (appareil <serial>, déverrouillé via coffre, 5s) → Phase 1 ignorée (l'utilisateur a choisi construction directe) → Phase 2 réussie (3 clips, 1,2 Go, 4 min) → Phase 3 réussie (reel_<nom>_v1.mp4, 22 min) → Phase 4 réussie (renvoi vérifié, tailles correspondantes) → Phase 5 remise (Instagram ouvert, utilisateur doit publier).

Pièges

• Jonction manquante après un clone frais : skills\phone-media-bridge\scripts\phone_pull est une jonction vers D:\EditorPackArchive et ne survit pas à un clone frais — recréez-la selon la documentation de phone-media-bridge avant la Phase 2.
• Téléphone débranché en cours d'exécution : les extractions sont sûres (ré-exécutez l'étape d'extraction) ; les renvois ne le sont pas — ré-exécutez push_reel.py et revérifiez avec adb shell ls.
• Téléphone se verrouillant à nouveau en cours d'exécution : unlock.py définit un maintien d'éveil + délai de 30 min, mais un redémarrage ou un verrouillage manuel réarme l'écran de verrouillage — ré-exécutez unlock.py (le code PIN reste dans le coffre, aucune action utilisateur nécessaire) et continuez.
• Le décodage HEVC est lent (piège de clip-picker) : les feuilles de contact et le score de mouvement sur les séquences téléphoniques prennent plus de temps que sur du H.264 — dites-le dès le départ, ne réduisez pas l'échantillonnage pour compenser.
• Ne publiez jamais automatiquement : pas d'automatisation UI du flux de publication Instagram, pas de planification, pas de téléchargements. Ouvrir l'application pour l'utilisateur est la dernière étape automatisée.

Règles de rapport honnête

• Rapportez ce qui a été réellement vérifié vs supposé, par phase : numéro de série de l'appareil vu dans adb devices -l (pas "téléphone connecté"), déverrouillage vérifié via dumpsys (pas "téléphone ouvert"), tailles des fichiers extraits correspondantes (pas "fichiers copiés"), renvoi vérifié avec adb shell ls + correspondance de taille, Instagram ouvert (pas "reel publié").
• Si une phase a été ignorée (ex. pas d'inspiration), dites-le explicitement — n'impliquez jamais que sa sortie existe.
• Honnêteté temporelle : rapportez la durée horloge murale mesurée par phase ; le temps de transcodage/score HEVC est un vrai travail, pas une surcharge à cacher.
• Signalez les défauts de qualité plutôt que de les livrer silencieusement : sélections tremblantes, HDR délavé, limites de republication d'audio emprunté (les règles Phase 5 de reel-maker s'appliquent).