Audit de frontière BoostEcom (2026-10-08)

NOTE POST-NETTOYAGE (8 octobre 2026) : ce texte documente une architecture ou un audit historique, avant les PR #1717–#1724 et #1728. Les anciennes interfaces Growth/Cinema et l'ancien Studio marchand dans boostecom.app ont été retirés. Le contrat CURRENT est docs/architecture/shopify-media-boundary.md ; les capacités média Shopify et Orbit Studio sont distinctes. La validation des builds/tests/E2E reste déléguée à un autre agent.

Préparation non destructive ; ce document ne constitue pas un GO de cutover. Source figée : BoostEcom/boostecom.app@f3314e7b16506d0d985a9058ffe4b1dc465fd5c6 (main, arbre Git complet). Index exhaustif des chemins ciblés, SHA blobs, catégories et motifs : 2026-10-08-boostecom-boundary.manifest.json.

Inventaire précis

• .claude/skills/boostecom-content/** : 56 fichiers
• src/features/growth/** : 27 fichiers
• src/services/growth/** : 28 fichiers
• creative/** : 178 fichiers
• src/features/studio/** : 83 fichiers
• src/components/studio/** : 77 fichiers
• src/services/creative/** : 20 fichiers
• .claude/skills/boostecom-creative/** : 14 fichiers
• .claude/skills/boostecom-render/** : 2 fichiers
• Hot files et routes opérateur supplémentaires : 22 fichiers.
• Total classé : 507 fichiers, 140 « à migrer dans un autre dépôt », 19 « à conserver dans l’application », 155 « à examiner », 16 « à migrer dans Ecosystem », 177 « à supprimer après migration ».

Les catégories sont des destinations envisagées, pas des autorisations de suppression. Une classification conservatrice « à examiner » évite de détruire une capacité boutique portant le nom Studio/creative. L'inventaire recouvre également des tests, schemas et fichiers inertiels : aucun statut ne doit être interprété comme autorisation de déplacer les données associées.

Migré et vérifié

• PR #1688 (demo Paume Douce) et #1689 (film accueil/film v1) fusionnées. Ne pas réintroduire les sources.
• Dans BoostEcom/Ecosystem@Private/Studio/@BoostEcom/Development (commit 223b22b1), projects/creative-runtime/creative/ comporte 178 fichiers. Les 178 chemins de creative/ sur main existent dans cette copie ; 177 SHA de blobs sont identiques. Exception de contenu : creative/README.md. Vérifier le texte divergent avant retrait.
• Le workflow .github/workflows/creative-render.yml lit le runtime Media d'Ecosystem sur un SHA épinglé (d44b2914dad27b38e06fe66dc671473b69752e17), mais dispatch, Blob, rappel et secret appartiennent encore à l'app.
• Ecosystem n'a pas de branche main : sa branche par défaut est Private/Agents/@ClaudeCode/Development, sans rapport avec les médias. Les projets film/demo/runtime sont dans Private/Studio/@BoostEcom/Development ; Private/Studio/@Orbit/Development héberge le film Orbit, pas l'API du produit Orbit.
• BoostEcom/orbit.easyconnector.app@main contient un Studio autonome, ses routes /studio, la génération API et son propre moteur. Ne pas le confondre avec le studio interne de BoostEcom.
• BoostEcom/studio et docs/migration/plan-final-migration-studio.md ont répondu 404 sur la connexion GitHub disponible : existence hors périmètre de permission ou renommage possible ; destination Growth non prouvée.

Coupe fonctionnelle : garder / transférer / supprimer plus tard

Complément — audit des six dépôts et premières PR d'exécution (2026-10-08)

La liste des dépôts BoostEcom accessibles depuis l'intégration GitHub contient six dépôts : BoostEcom/boostecom.app, BoostEcom/Ecosystem, BoostEcom/orbit.easyconnector.app, BoostEcom/easyconnector.app, BoostEcom/docs.easyconnector.app, BoostEcom/discord-mcp. Aucun autre dépôt n'a été exposé par la connexion ; ne pas prétendre couvrir un dépôt masqué.

Les PR d'exécution citées ici sont draft, aucune fusion dans main ou bascule Postiz. L'intégration ne permet pas de valider les scénarios production ; ces validations seront réalisées par le propriétaire. Le GO du propriétaire du 2026-10-07 satisfait D-40, mais ne certifie pas automatiquement les autres points de growth-web/3114 et 3115. Les PR préparatoires et le nettoyage documentaire sans impact runtime peuvent avancer sans activer les suppressions risquées.

Postiz : consommateurs et risque d'écriture doublée

• src/features/studio/growth-writes.ts : sendRenderToPostiz et syncPostizPublications, droits platform.growth.manage, état scheduled / preuve published ; appel indirect depuis src/components/studio/ops-actions.ts, render-panel.tsx et growth-content.tsx.
• src/services/growth/postiz.ts : API Postiz ; features/growth/postiz-draft.ts construit les payloads ; creative/pipeline/postiz.mjs peut aussi écrire, tout comme les scripts boostecom-content/scripts/postiz-*.mjs. Ils doivent être inclus dans la stratégie de single writer.
• Valeurs POSTIZ_API_KEY / POSTIZ_API_URL déclarées dans src/env/server.ts, .env.example, src/services/env-audit.ts, src/config/provider-ledger.ts, sous-traitants légaux et runbooks. Conserver clés/permissions et ne pas tourner l'identifiant sans inventaire des lecteurs, choix D-28 et plan de rollback.
• growth-attribution, src/services/growth/attribution.ts, modèles GrowthUnit / AttributionEvent et UTM dépendent de la base de l'app : migration des fichiers ≠ migration des données ou de la tâche planifiée.

Verrous d'autorisation et critères d'acceptation

Le ticket backlog/growth-web/3115-c6-growth-et-postiz.md est toujours blocked. Il note un GO propriétaire écrit au 2026-10-07, ce qui règle uniquement D-40. Les autres portes exigées restent à prouver : 30 E2E verts, émancipation et 30 jours sans incident Studio, import fondateur E2E-26 et archive hors DB, décisions D-02 / D-03, ponts B1/B2/B3/B6 (B7/C-3), checklist Plateforme §6 verte, puis 3114, D-18 et D-28.

Ordre et retour arrière

1. Faire valider par les propriétaires les destinations Studio/Growth et la preuve d'accès au dépôt opérateur ; comparer les archives et SHA, préserver l'historique des commits et garder les liens de provenance.
2. Sur un environnement non-prod, tester génération image/vidéo sur deux boutiques distinctes, droits org/grant/platform-admin, références inter-boutiques refusées, journal delivered/failed, crédits, Blob, Workflow interactif et non interactif. Ne pas confondre test statique avec E2E.
3. Recenser tous les points de publication Postiz et geler les autres, valider un unique écrivain Studio puis importer les enregistrements/identifiants. Ne révoquer ni secret ni route tant que lecture et rollback non démontrés.
4. Exécuter les tests de migration / comparaison, puis seulement après GO de chaque ticket, faire des PR de suppression séparées (3114, 3115, interface Studio) avec snapshot de rollback et vérification du déploiement.
5. Rollback : rétablir la version de l'app par revert, réactiver l'ancien écrivain Postiz uniquement après avoir désactivé le nouveau, restaurer l'archive originale en cas de perte de données ; ne jamais faire deux auteurs sur la même file de publications.

Aucune suppression, rotation ni mutation de donnée de production n'est faite par cet audit.

Exécution GitHub vérifiée — 2026-10-08 (post-PR #1704)

• App #1699, #1700 et #1701 fusionnées : garde chat, alias Studio, thèse Shopify séparée du Growth opérateur.
• App #1703 fusionnée : suppression de toute l'arborescence creative/ en doublon, retrait des scripts creative:* racine, Media Desk désormais Blob/audit seulement ; workflow .github/workflows/creative-render.yml épinglé au commit Ecosystem 5d05c77ac0d9b58207afeeb3c833e17df2e56988.
• App #1704 fusionnée : retire aussi les variantes d'artefacts locaux et le ledger du contrat et de l'UI Media Desk.
• Ecosystem (branche Studio) #42, #43, #44, #45 fusionnées : runtime compatible sans ancien skill app, modules Growth purs, plans Q4 et verrou Postiz du pipeline creative.
• Ecosystem (branche Agents) #46 fusionnée : garde GROWTH_POSTIZ_WRITER_ENABLED=true sur les scripts de réécriture/suppression de brouillons de contenu. Gate non activé. L'écrivain Postiz actif reste l'application.

Non terminé / non autorisé par ces fusions : transfert en service autonome authentifié du cockpit opérateur /ops/creative/*, de src/features/studio/growth-writes.ts, des autres modules src/features/growth/** et src/services/growth/**, des tables GrowthUnit/ContentRender et de leurs preuves de publication, du cron d'attribution et du writer Postiz. Ces responsabilités ont encore des consommateurs vivants dans l'application ; enlever les fichiers ne constitue pas une bascule. Les conditions de growth-web/3114 et 3115 hors D-40 restent à satisfaire. Aucun E2E, TypeScript ou CI n'a été exécuté pendant cette vague (quota indisponible). Aucun secret ni donnée de production n'a été modifié.

L'inventaire initial de 507 fichiers ci-dessus est une photographie historique pré-suppression et non un état des chemins encore présents après ces PR.

Passe supplementaire : menus et panneaux Studio (2026-10-08)

Apres la scission des imports marchands (#1706 et #1707), les PR fusionnees #1710, #1711, #1712, #1713 et #1714 ont retire les lignes de navigation definitivement cachees, la modale Discord sans declencheur, les icones orphelines, les panneaux locaux de profil, d'abonnement, de recharge et le deuxieme panneau Production. Les lectures StudioHost de compte et d'abonnement, ainsi que les props non consommees, ont ete retirees. La vraie Production reste accessible dans la System marchande ; le pricing public, le checkout en cas de manque de credits, la session, les permissions, la galerie et les services de generation restent.

Ne pas confondre avec une fin de migration : le siège operateur est encore monte dans /ops/creative/*, les 15 bureaux operateurs sont encore importes dynamiquement par le Studio partage, et la base Growth, l'attribution, les secrets et l'ecrivain Postiz restent dans l'application. Dans Ecosystem, les modules Growth copies ne constituent pas encore un service de production autonome. Leurs migrations exigent un adaptateur de donnees et une strategie d'authentification ; l'absence de quota CI ne prouve pas ce cutover.

Decision proprietaire du 2026-10-08 : autorisation de nettoyer sans attendre les criteres E2E historiques ni l'usage CI, avec retour arriere par commit. Cette autorisation accelere les suppressions reversibles mais ne signifie pas que les imports resolvent, que Postiz n'a qu'un ecrivain ou que les donnees historiques sont transferees. Tant que ces points ne sont pas prouves, garder un unique ecrivain applicatif et ne pas declarer le projet termine.