Audit de retrait des Studios de boostecom.app — 2026-10-08

Périmètre propriétaire clarifié oralement le 2026-10-08. L'objectif n'est pas de conserver le Studio marchand dans BoostEcom. Les deux Studios créatifs — interne et marchand — doivent sortir de boostecom.app, après preuve que les fonctions créatives utiles existent dans BoostEcom/orbit.easyconnector.app / BoostEcom/docs.easyconnector.app et que les films et le runtime archivables vivent dans BoostEcom/Ecosystem. À conserver dans BoostEcom : Marketplace, Registry, Chat, algorithmes, Intelligence, Workflow, Preview, éditeurs, Builder, Mirror et l'opérationnel Shopify. Ne pas détruire de fonctionnalité primaire en confondant son nom avec Studio.

Frontière produit explicite — décision propriétaire du 2026-10-08

Ce classement l'emporte sur les anciennes formulations « garder le Studio marchand dans BoostEcom » des tickets C hérités. La seule présence du mot studio dans un chemin ou un outil ne définit pas son propriétaire. Distinguer le public cible, le point d'entrée et les dépendances métier.

Constats de code qui justifient la séparation

• src/features/ai/tools/studio-media-tools.ts dans BoostEcom enregistre actuellement generateImage, composeProductImage, generateVector, generateVideo et les opérations de livraison/concepts. Leurs factories utilisent ctx.storeId ainsi que l'enveloppe organisation/utilisateur et les images jointes. Ce chemin chat Shopify reste ; il ne doit pas être supprimé avec les pages Studio.
• src/features/ai/chat/runtime/tool-media.ts rend les médias générés dans la conversation Chat. src/features/ai/orchestrator/runtime/studio-capabilities.ts arme Image/Vidéo/Vecteur à partir de l'intention et des modes du composer. Ces comportements Shopify font partie du contrat de non-régression.
• src/features/ai/tools/studio-voice-tools.ts utilise encore le journal et le service de synthèse vocale pour des générations avec storeId. À découpler avant de retirer src/services/creative/**, pas à jeter en bloc.
• src/services/growth/postiz.ts, src/features/growth/postiz-draft.ts et .claude/skills/boostecom-content/scripts/postiz-*.mjs sont encore dans BoostEcom. backlog/growth-web/3115-c6-growth-et-postiz.md reconnaît que la migration est bloquée et recommande d'éviter deux writers Postiz simultanés. Portage interne vers Ecosystem demandé par le propriétaire ; pas de preuve actuelle que le portage soit déjà terminé.
• BoostEcom/orbit.easyconnector.app dispose d'actions apps/web/src/cockpit/studio-actions.ts pour image, vidéo, voix, édition, suppression, références, avatar ; packages/engine/src/generation/** gère sa génération et packages/remotion/** son rendu. Cette copie sert les utilisateurs Orbit, pas les boutiques Shopify de BoostEcom.

Dépendance Shopify confirmée : la retirer du Studio sans supprimer la capacité

• Dans src/features/ai/workflow/v2/lib/workflow-capabilities.ts, ai.generate-image et ai.generate-video sont déclarées state: "available" (nœuds aiImage et aiVideo) ; memory.scoped, à l'inverse, reste planned. Ne pas confondre disponibilité déclarée et exécution E2E en production, mais ne pas effacer les deux nœuds.
• src/features/ai/workflow/v2/server/execute.ts importe actuellement editStudioImage, generateStudioImage, generateStudioVideo depuis @/components/studio/actions. C'est un import de logique fonctionnelle Shopify depuis un répertoire UI Studio en voie de retrait. C'est une dépendance technique à extraire vers un service partagé propre à BoostEcom, pas une raison de retirer la fonction et pas une migration dans Orbit.
• Le chat a son propre chemin src/features/ai/tools/studio-media-tools.ts et le rendu de ses résultats src/features/ai/chat/runtime/tool-media.ts; ces deux parcours doivent rester opérationnels pour les tenants Shopify.
• Critère de suppression du dossier src/components/studio/** : zéro import actif de @/components/studio/actions depuis Workflow, Chat ou Shopify et des tests réussis de génération depuis chat et depuis nœuds aiImage / aiVideo. Conserver les contrôles orgId, storeId, droits, crédits, journal et Blob à comportement identique.

Conditions de non-régression séparées

• BoostEcom : génération d'image et de vidéo depuis une conversation Atlas pour un storeId autorisé ; sortie visible dans le chat et dans l'historique Shopify attendu.
• BoostEcom : nœuds Shopify image/vidéo dans Workflow exécutables, permissions et coûts préservés, ainsi que Preview/Builder/Mirror/Registry/Marketplace/Intelligence.
• Ecosystem : films historiques/Remotion déjà migrés localisés et intègres ; nouvelle migration Growth/Postiz + contenus internes, secrets et external state vérifiés ; propriétaire du writer Postiz exclusif.
• Orbit : création du Studio marchand et interne nécessitant une interface Orbit, galerie, concepts, QC, coûts, permissions et retours de rendu vérifiés ; documentation alignée sur le runtime.
• Tous : analyses des dépendances et contrats d'API entre les trois espaces achevées avant suppressions. Ne pas prétendre « tout est migré » sur la seule présence des fichiers.

Références GitHub effectivement relues

• Application : BoostEcom/boostecom.app@07d1d13ca14256f07de4e017817fbf4356edbfeb.
• Orbit : BoostEcom/orbit.easyconnector.app@40b760585bd0af20e99f782dff0eaeb03c696b77.
• Docs : BoostEcom/docs.easyconnector.app@f221224da8cbfd8b63d266be9598f5f79b351dd5.
• Runtime Studio extrait vers Ecosystem : d44b2914dad27b38e06fe66dc671473b69752e17. La PR applicative #1691, fusionnée, fait pointer .github/workflows/creative-render.yml vers ce commit ; le workflow ne lance plus le runtime local. Cela ne prouve pas à lui seul qu'un rendu en production a réussi.
• Docs de migration Orbit : source-baseline, legacy-inventory, legacy-studio-retirement, legacy-studio-unmigrated-paths.

Important : ne pas confondre deux migrations

Les documents Orbit comparent le dépôt historique BoostEcom/studio.boostecom.app, figé au commit 94d051c..., à Orbit. Leur inventaire de 214 chemins sans correspondance 1:1 décrit ce dépôt historique, pas le Studio de BoostEcom/boostecom.app. Le texte dit lui-même que ces chemins ne sont pas tous des fonctions absentes. Nous n'avons pas encore de preuve de parité exhaustive entre BoostEcom.app et Orbit. L'ancienne checklist ne peut donc pas tenir lieu de feu vert pour supprimer tous les chemins Studio de la plateforme.

Inventaire mesuré des fichiers suivis sur les commits ci-dessus

Correspondances constatées dans le code Orbit (présence, pas encore preuve de parité)

• Studio UI, projets, onglets, galerie : apps/web/src/components/studio/**, apps/web/src/app/(dashboard)/studio/**, apps/web/src/cockpit/gallery.ts, apps/web/e2e/studio-tabs.spec.ts.
• Images / vidéo / modèles / voix : packages/engine/src/generation/**, apps/web/src/services/creative/templates.json, apps/web/src/services/creative/voiceover-models.ts, tests apps/web/e2e/studio-end-to-end.spec.ts.
• Remotion, Cinema, rendu asynchrone et retour de fin de rendu : packages/remotion/**, packages/cinema/**, packages/engine/src/render/{dispatch,callback}.ts, .github/workflows/render.yml.
• Revue et concepts : apps/web/src/app/(dashboard)/studio/[product]/(board)/review/page.tsx et concepts/page.tsx ; apps/web/e2e/studio-tabs.spec.ts.
• Documentation métier : docs.easyconnector.app/studio/**, help-center/academy/studio/**, engineering/migration/**.

Contradiction à résoudre avant d'appeler la migration complète

La page Docs studio/overview.mdx annonce quatre onglets « Créer, Bibliothèque, Validation, Croissance », mais apps/web/e2e/studio-tabs.spec.ts vérifie trois onglets « Create, Review, Concepts » et l'absence d'un onglet « Library ». Une galerie peut exister dans la page sans être un onglet autonome, mais la documentation n'est pas synchronisée avec le comportement testé. Il faut vérifier la fonctionnalité attendue, pas seulement les noms.

Contrôles fonctionnels indispensables avant retrait complet

• Création marchand : génération image/vidéo/voix, budgets/crédits, limites de formats, erreurs, annulations et idempotence réellement testés dans Orbit, et comparés aux anciennes capacités marchandes dans BoostEcom.
• Bibliothèque et provenance : assets historiques, URLs Blob, filtres, détails, versions, galerie, QC/validation, partage et rétention.
• Concepts et apprentissages : concept, variantes, validation, taxonomie, attribution, boucles d'amélioration ; identifier explicitement les fonctions volontairement abandonnées.
• Cinema & captures : scènes, ProductFilm/UiShot, capture produit, rendu et callback avec un lancement réel, pas uniquement lecture des fichiers de configuration.
• Permissions et intégrations : séparation tenant/organisation, Studio interne vs marchand, appels API/MCP, secrets et webhooks propres à Orbit.
• État durable : export du tenant fondateur (data-platform/3122) réellement exécuté/vérifié, import Orbit le cas échéant, nombres de lignes et blobs cohérents. Fusion de #1693 = script prêt, pas preuve d'export exécuté.
• App primaire : chaque import direct ou indirect vers src/components/studio, src/features/studio, src/services/creative, src/lib/studio est classé : (a) purement créatif à retirer, (b) fonction Shopify à préserver hors Studio, (c) chemin de transition vers Orbit. Les modules Bulletin / Growth / Postiz sont ciblés pour extraction interne vers Ecosystem lorsqu'ils appartiennent à la production BoostEcom ; les dépendances Chat/Workflow Shopify sont isolées et préservées, sans suppression aveugle.
• Docs actualisées : écarts docs ↔ comportement Orbit résolus, nouvelles destinations documentées.

Retrait prévu de BoostEcom, une fois la parité démontrée

1. Supprimer creative/** (178 fichiers de copie locale) et les skills Studio .claude/skills/boostecom-creative/** (14) et boostecom-render/** (2), ainsi que leurs scripts/tests/docs exclusivement locaux ; ne jamais laisser une commande qui invoque un fichier retiré.
2. Retirer les pages et composants Studio interne et marchand de l'app, après vérification de la destination Orbit et suppression des imports/appels restants.
3. Retirer les services/API/permissions/tables exclusivement Studio selon leurs dépendances et preuves d'export ; aucun DROP ni effacement Blob automatique. Préserver les fonctions métier Shopify et leurs données.
4. Retirer les anciens gardes obsolètes ; conserver ou transposer les tests des contrats métier encore nécessaires à BoostEcom.
5. Exécuter des tests de non-régression sur les modules primaires et vérifier qu'il ne reste aucun chemin ou appel vers l'ancien Studio.

État au 2026-10-08 : audit GitHub partiel documenté ; parité BoostEcom.app → Orbit non prouvée de A à Z. Aucune suppression des deux Studios ne doit être annoncée comme terminée. Ce document sépare les constats vérifiés du travail restant et ne requalifie pas une absence de fichier en preuve de migration.