La migration initiale FFActions -> FrameShift est considérée comme terminée.
Le projet actif n’est plus un squelette de migration :
- la structure
src/FrameShift/est la base réelle ; - les actions principales sont branchées ;
- l’installateur Inno Setup est aligné sur la surface active ;
- les anciens projets sous
references/restent de la lecture seule.
Ce document sert désormais de rappel d’architecture et de garde-fou post-migration, pas de checklist d’action à migrer une par une.
Base active validée :
- le launcher
Programdécoupé en plusieurs fichierspartialpour séparer entrypoint, parsing CLI, batch, préflight IA,Image to PDFet pickers ; ActionRegistry.cspour la surface des actions core ;FfmpegRunner.cspour tous les appels FFmpeg ;FfprobeRunner.cspour tous les appels FFprobe, y compris Media Info ;ProgressForm.cspour la progression partagée des actions classiques et deremove-background;DownloadModelForm.cscomme downloader IA partagé ;installer/FrameShift.isspour le packaging et l’intégration Explorer.
UI partagée active :
FrameShiftTheme.csFrameShiftUiMetrics.csFrameShiftUiLayout.csFrameShiftUiFactory.csFrameShiftEditorShellUi.csFrameShiftCropEditorUi.csFrameShiftWindowChrome.cs
Le modèle dominant est :
- entrée
Program - ouverture éventuelle d’un formulaire WinForms
- sérialisation des options dans
ActionOptionKeys - validation et exécution par une action core
Ce schéma couvre aussi bien :
- les actions batch avec options partagées ;
- les actions mono-fichier avec picker ;
- les modules interactifs comme
Image to PDF.
Batch avec file Windows active :
convert-videoconvert-audioconvert-imageextract-audioextract-frames
Batch différé avec picker avant progression :
convert-videoconvert-audioconvert-imageextract-audio
extract-frames peut rejoindre la file batch mais n’a pas de picker partagé.
Les autres actions restent principalement mono-fichier, soit par dépendance UI, soit parce que le contrat batch n’a pas encore été durci.
remove-background suit maintenant le même principe de progression partagée que les autres lots :
- une seule fenêtre de progression ;
- file visible ;
- erreurs reportées dans la queue ;
- préflight du modèle avant lancement si nécessaire ;
- continuation du batch sur fichier corrompu.
separate-audio suit aussi ce schéma :
- picker si les stems ou le moteur ne sont pas déjà fournis ;
- préflight du modèle CPU ou GPU selon le routage demandé ;
- progression commune ;
- continuation du batch sur erreur fichier.
Image to PDF :
- module interactif ;
- routé par
FrameShift.exe; - UI dédiée ;
- export final core ;
- support WebP actif via FFmpeg côté launcher/UI et validation core alignée.
Media Info :
- action visible côté produit ;
- probe via
FfprobeRunner.TryProbeMediaInfoAsync(...); - rendu via
MediaInfoFormatter; - affichage WinForms requis.
La migration initiale est finie, mais il reste de la consolidation :
- documentation à maintenir au rythme du code ;
- couverture de tests encore partielle sur certains branchements ;
- certaines actions ont une entrée CLI mais pas une couverture headless complète ;
- duplication résiduelle légère dans les scripts, helpers ou formulaires.
À partir de maintenant :
- le code actif fait foi ;
references/sert uniquement de contexte ;- toute nouvelle capacité doit être branchée jusqu’au publish et à l’installateur ;
- toute promesse documentaire doit être vérifiée contre les fichiers
Program*.cs,ActionRegistry.csetinstaller/FrameShift.iss.