Audit du Creative & Growth OS : 18 septembre 2026

Perimetre : tout ce qui, dans ce depot, produit, range, paie, relit, distribue ou mesure une creative, pour la plateforme elle-meme comme pour un store client. Seize sous-systemes lus en parallele par autant de lecteurs independants (le tableau « La carte » ci-dessous les enumere, et c'est lui qui fait foi sur le compte), chaque affirmation MISSING / REDUNDANT / SAFE_TO_REMOVE / MISPLACED qui decide du plan contre-verifiee par un sceptique a trois lentilles (autre nom, implementation partielle, preuve fausse), puis une synthese et une critique de completude. La decision qui en sort est l'ADR 0024 ; ce document est la preuve, l'ADR est la regle.

Ce qui a ete trouve, en une phrase

Le depot ne manque pas d'un Studio : il en a deux qui ne se parlent pas (le Studio vendu, sur l'AI Gateway, avec ledger, QC et lineage ; et la production de la plateforme, sur Remotion et ElevenLabs, sans ligne en base ni cout enregistre), et les sept capacites media du premier vivent hors du registre que l'ADR 0023 a fait adopter par le canvas, le MCP et l'API, donc aucune grammaire autre que le chat ne sait generer.

La methode, et ce qu'elle ne couvre pas

• Codebase first. Aucune affirmation de ce document ne vient du brief ; chacune cite un fichier. Quand un lecteur a dit MISSING, un sceptique a cherche le concept sous un autre nom, sous forme partielle, et a relu la preuve. Les affirmations qui n'ont pas ete contre-verifiees sont marquees comme telles dans la gap analysis : elles sont des constats d'inventaire, pas des verdicts.
• Les captures de reference ne sont pas dans le depot. Le brief s'appuie sur plus de vingt captures d'un studio generatif du marche ; trois sont decrites textuellement (Replace, Motion, Cinematic > Scenes). La matrice ecran ci-dessous est un squelette construit sur ces descriptions et sur les primitives existantes. La parite d'interaction attend les captures reelles, versionnees dans le depot (elles sont un prerequis nomme, pas un detail).
• Les moteurs sont ceux du depot, et la liste est fermee. AI Gateway (Vercel), ElevenLabs, Remotion, Playwright (les captures du produit reel), Postiz, Datafast. Le studio generatif dont viennent les captures est une reference d'ergonomie, jamais un fournisseur : rappele le 2026-09-18, « on reproduit, en aucun cas on va l'utiliser ». Une capacite que nos moteurs ne servent pas est nommee et desactivee, pas sous-traitee.
• Pas de recommandation sur l'argent. Le plan qui inclut la generation video, qui paie la production de la plateforme, le cout de gros reel d'une image, la licence Remotion : chiffres et options sont dans le registre des decisions, jamais tranches ici.

Les deux Studios, mesures

Les trois planes de creative-media-os.md §2 tenaient ces deux pipelines a distance par doctrine (« un render A n'ecrit jamais un StudioAsset »). L'ADR 0024 garde l'intention (ne jamais melanger la production de la plateforme et celle d'un client) et change le mecanisme : le scope, pas le pipeline.

La carte, par sous-systeme

Seize lectures. Les fichiers pivots, et ce que chaque sous-systeme decide :

La frontiere Founder / Store, couche par couche

La plateforme n'est nommee par aucun identifiant, et ce n'est pas un oubli : PLATFORM_ORG_ID et Organization.kind ont ete rejetes trois fois (acces-delegue-et-frontiere-studio.md, ADR 0013, ADR 0024). Le profil existe comme un contexte derive a trois couches :

Cote store, le scope tient a chaque couche, et par des mecanismes differents (c'est la solidite et le cout) : le where Prisma d'appartenance (garde par tenant-pages-scope-by-membership.test.ts), la porte cross-tenant du chat (handler-gates.ts : storeAccess.orgId !== activeOrgId → 403), AtlasToolContext, les chargeurs Studio qui prennent storeId dans le where, le prefixe Blob stores/<storeId>/studio, le bearer MCP lie a un seul storeId, le namespace vectoriel par store, et la frontiere /collab (le mandataire n'entre pas cote user, garde par collab-never-reaches-the-user-side.test.ts).

Trois trous, mesures, et ce sont eux que l'ADR 0024 ferme :

1. studio-references.ts autorise par hote, pas par scope : .public.blob.vercel-storage.com en entier, donc l'URL publique d'un asset d'un autre store passe l'allowlist. Aucun test ne prouve que generateImage du store A ne peut pas referencer le store B.
2. Le prefixe studio/unassigned : un rendu sans store est facture a l'organisation, ecrit publiquement, liste nulle part, supprimable par personne. Trois sites d'ecriture, zero lecteur.
3. La production de la plateforme est hors tenant : pas de StudioAsset, pas de ligne Credit, pas de QC. loadQcBoard() sans orgId reste d'ailleurs une signature qui embrasse la plateforme entiere, meme si plus aucun appelant de production ne l'utilise ainsi.

Deux gardes citees par le code n'existent pas sur le disque : delegate-has-no-floor.test.ts (referencee par deux docblocks de lib/security/) et surfaces-import-their-capabilities.test.ts (annoncee par l'ADR 0023, par features/ai/tools/CLAUDE.md et par ai-platform/2764). Une regle citee et absente est plus couteuse qu'une regle jamais ecrite : elle se lit comme tenue.

Les capacites, et ou elles manquent

L'ADR 0023 a fait du registre src/features/ai/tools/ la liste unique : 26 familles, une etape par famille, un risque par outil, trois lecteurs (createAtlasTools, describeAtlasTools, probeToolContext) et un catalogue servi par store a GET /api/workflow/v2/capabilities.

Les sept capacites creatives n'y sont pas :

Et le rendu Remotion (launchTemplateRender) n'est atteignable que par deux server actions, l'une requireAdmin, l'autre platform.content.operate. La matrice cible, capacite produit contre implementations :

L'identite visuelle : le mot est deja pris

Dans ce depot, avatar designe l'avatar marketing, la cible d'une creative : CreativeConcept.marketingAvatar (« "women 25-34" is not an avatar »), StudioAsset.persona, l'axe de variante persona, le plancher AVATAR_FLOOR = 2 du Go/No-Go, les « Avatar Cards » du skill creative-ads. Et AgentPersona plus identity-registry.avatar designent les agents IA. Trois occupants pour un mot.

Le personnage reutilisable du brief (le fondateur, un porte-parole, un personnage de marque, avec ses references, ses versions, ses attributs et sa voix) n'existe nulle part : aucun modele, aucun type, aucun outil, aucun ecran. Ce qui en tient lieu :

• une reference de generation est une position d'attachement ou une URL sur allowlist, jamais un identifiant ; aucune grammaire @ n'existe cote Studio (resolveMention, parseMentions : zero occurrence) ;
• le kit de marque (StoreContext.modules.brandKit) porte nom, ton, audience, palette, typo, logo, et aucun personnage ;
• la voix est une seule valeur d'environnement, ELEVENLABS_VOICE_ID, pour toute la plateforme ; la doc promet « voix A ≠ voix C » que rien n'implemente ;
• StudioAssetKind.LIPSYNC n'a aucun producteur ;
• le consentement de clonage vocal existe, mais dans un script CLI hors application (creative/pipeline/tts.mjs), sur un fichier du depot.

D'ou StudioIdentity (ADR 0024 §6) : un objet distinct, scope comme un asset, reference par son identifiant, resolu par le meme resolveur, avec son consentement. Deux questions restent ouvertes, de gouvernance : le scope (store, comme StudioAsset, ou organisation, pour qu'une agence reutilise un porte-parole sur plusieurs marques) et le droit a l'image d'une personne reelle cote client.

Les surfaces : quinze pages, sur quatre racines gardees differemment

Ce n'est pas une constellation de pages inutiles : les chargeurs sont deja partages (features/studio/boards.ts, board.ts, cockpit.ts servent les pages d'organisation, les pages /admin, la QC de /ops, la file personnelle ~/me, les outils du chat et la route REST). Le noyau commun que la cible demande existe donc deja pour les boards. Ce qui se duplique est ailleurs :

Quelle racine devient le Studio de la plateforme ? La question est tranchee par une contrainte que le depot porte deja : /admin est garde au bord sur User.role === "ADMIN" (src/proxy.ts), donc une page qui doit s'ouvrir a quelqu'un qu'on recrute ne peut pas y vivre. C'est exactement pourquoi la QC creative a demenage vers /ops (security-identity/0605). La fabrique suit le meme chemin : la porte de production de la plateforme est /ops, avec une permission platform.* ; /admin/creative garde ce qui est du ressort du proprietaire seul. Ce qui est deja vrai a moitie (la QC est sous /ops, la fabrique sous les deux) devient une regle.

Les moteurs, et pourquoi la liste est fermee

Six moteurs, et aucun autre : AI Gateway de Vercel (Nano Banana Pro pour l'image, Veo 3.1 Fast pour la video, un seul catalogue dans config/ai-models.ts), ElevenLabs (voix), Remotion (composition deterministe, ADR 0017), Playwright (creative/pipeline/capture.mjs, sur une allowlist : c'est la marche « produit reel » de la hierarchie de l'ADR 0017, celle qui passe avant toute imitation), Postiz (distribution), Datafast (mesure).

Les captures qui ont servi de reference viennent d'un studio generatif du marche. Elles sont une reference d'ergonomie : la forme des controles, la facon de poser un slot, la maniere de dire une limite. Pas un fournisseur. Tranche le 2026-09-18, et c'est coherent avec l'ADR 0017 qui avait deja refuse un moteur generatif pour montrer le produit.

Ce que cela change pour l'architecture, et c'est le point utile : l'abstraction provider ne sert pas a ajouter des fournisseurs. Elle sert a ce qu'une capacite produit (« anime ce personnage ») soit nommee une fois, et que l'UI, le canvas, le MCP et l'API ne sachent pas si elle est servie par une option de Veo, par une composition Remotion, ou par rien. Les trois capacites decrites par les captures et que nos moteurs ne servent pas aujourd'hui (mouvement d'un personnage, remplacement d'un personnage dans une video source, enchainement de scenes) sont donc planned : visibles, desactivees, avec leur raison. C'est exactement ce que the-studio-runs-what-it-declares impose deja au canvas, et ce que le depot refuse de faire autrement (un controle qui semble agir sans agir).

Les ecarts

Les inventaires de session ne sont pas versionnes, donc leurs totaux ne sont derives de rien et ne sont pas repris ici : ce qui tient dans ce document est une preuve fichier:ligne par ligne, verifiable au clone. Le tableau garde les entrees qui decident du plan. La colonne « confirme par » compte les lecteurs independants qui sont arrives a la meme conclusion depuis un angle different, ce qui vaut mieux qu'un vote unanime d'un seul.

Les entrees non reprises ici (menage local, prose perimee, doublons de lecteurs) restent dans les inventaires de la session ; elles ne changent pas le plan.

Ce qui se renomme, se fusionne ou disparait

Ce qu'on clone, composer par composer

La consigne est explicite : on reproduit ce que ces studios font tous, on n'utilise aucun d'eux. Ce qui se clone est la forme des controles, la facon de poser un slot, la maniere de dire une limite, l'endroit ou vit le cout. Ce qui reste le notre est le moteur, le nom de la capacite et la porte.

La regle qui gouverne toute cette section, prise telle quelle du brief : l'interface est definie par la capacite, jamais par un formulaire universel. Pas d'invite quand la capacite n'en accepte pas ; pas de duree manuelle quand la sortie suit sa source ; pas de selecteur de format quand la sortie suit sa source. Un controle qui ne pilote rien est la faute que ce depot corrige deja ailleurs (la toolbar de la preview rendait ses commandes dans les quatre modes et trois d'entre eux n'agissaient sur rien).

Sept composers, et ce que nos moteurs en servent reellement :

Deux consequences qu'on ne veut pas manquer :

1. Cinq composers sur sept sont servables par nos moteurs, et deux d'entre eux ne demandent que d'exposer ce que le code type deja (l'image de fin) ou de composer ce que Remotion sait faire (le multi-plan, le retiming). Le clone n'est donc pas un exercice d'imitation : c'est surtout du cablage.
2. Les deux qui restent sont declares, pas caches. Une capacite planned qui dit pourquoi vaut mieux qu'une absence : c'est la difference entre « le produit ne sait pas encore » et « le produit ne sait pas ».

Les elements sauvegardes, et la grammaire @

C'est le systeme que les trois composers a mentions supposent, et il n'existe pas : aucune grammaire de mention cote Studio, aucune table d'element sauvegarde. Les types que le brief enumere, confrontes a ce que le depot porte deja :

La regle qui en sort : un element sauvegarde est un actif de la bibliotheque plus un role donne par le slot. Pas une seconde taxonomie. C'est ce qui evite d'avoir a inventer un objet « StartFrame » distinct d'une image.

La definition d'une capacite

Le brief propose une forme, et le depot en porte deja les trois quarts, eparpilles. Ce que la famille studio-media (tranche 1) doit rassembler, avec pour chaque champ ce qui le tient aujourd'hui :

L'interface du Studio se derive de ces definitions. C'est exactement ce que le canvas fait deja pour les 87 autres capacites : son formulaire de noeud est genere depuis l'inputSchema. La generation rejoint ce mecanisme au lieu d'en inventer un.

Les slots, comme primitive

Huit slots nommes par le brief, zero composant dans le depot. Chacun doit connaitre ses types acceptes, son nombre maximum, sa taille, sa duree maximum, sa portee (le scope, c'est la tranche 3), son etat de televersement, son apercu, son retrait, son remplacement, et le selecteur d'actif deja sauvegarde.

C'est la primitive qui manque le plus, parce que les sept composers ne different presque que par elle : image d'ouverture, image de fin, references image, references video, references audio, personnage, video source, video de mouvement.

Le vocabulaire de mouvement

Le brief enumere dix-sept primitives de motion design (mise au point, deplacement de curseur, clic, revelation, decalage, modale, panneau, surlignage, bulle, frappe de texte, revelation de graphique, compteur, element partage, transition de scene, sous-titre, cadre de navigateur, cadre d'appareil). Le depot en porte dix, et aucune de ces dix-sept par son nom : SafeZone, HookText, KineticText, ProductWindow, BrandBackground, Glow, Notification, Chart, CTA, ChapterCard.

Le recouvrement est reel mais partiel : KineticText couvre la frappe de texte, Chart la revelation de graphique, ProductWindow s'approche du cadre de navigateur. Manquent surtout celles qui montrent un PRODUIT en action : mise au point, curseur, clic, element partage entre deux plans. C'est ce qui separe une video « jolie » d'une demonstration, et c'est exactement la marche que l'ADR 0017 place en haut de sa hierarchie.

La matrice ecrans : un squelette, et ce qui lui manque

Les captures de reference ne sont pas dans le depot. Cette matrice est construite sur les composers decrits textuellement par le proprietaire et sur les primitives qui existent. Elle dit ce qu'il faudra verifier, pas ce qui est decide. Les versionner (sous docs/references/creative-composers/) est un prerequis nomme de la parite d'interaction, pas une formalite.

Etat des primitives, mesure :

Les etats a couvrir, pour chaque composer : survol, selection, desactive, televersement en cours, au-dela de la limite, solde insuffisant, en generation, echoue, termine. Aucun n'est teste visuellement aujourd'hui.

Les trois composers decrits, et ce que la codebase peut en tenir :

La regle qui en sort : l'UI est derivee de la capacite, jamais un formulaire universel. Un controle que la capacite n'accepte pas ne s'affiche pas ; une limite s'affiche dans le slot (« jusqu'a 4 », « 30 s max ») ; et rien n'affiche un pourcentage que personne ne connait.

Les tranches

Chaque tranche est verticale (elle produit un resultat observable), elle reutilise le maximum, et elle nomme sa garde. L'ordre est celui des dependances, pas celui de l'envie.

Tranche 1 : la generation entre dans le registre

Resultat observable : depuis le chat, rien ne change ; depuis le canvas, un noeud « Generer une image » s'execute reellement ; depuis le catalogue servi par store, generateImage apparait avec son etat.

Tranche 2 : une generation est une ligne, et un job

Resultat observable : un clip de huit secondes qui met quatre minutes arrive ; l'operateur voit « en cours » puis le fichier ; rien n'est facture si rien n'est livre.

Tranche 3 : le scope, ferme

Resultat observable : le store A ne peut plus referencer un asset du store B ; un rendu sans store est refuse avant la depense.

Tranche 4 : la plateforme devient un tenant de son Studio

Resultat observable : un rendu Remotion de la plateforme apparait dans une bibliotheque avec son cout, son statut de relecture et son concept, comme celui d'un client.

Tranche 5 : les capacites que nos moteurs ne servent pas, nommees

Resultat observable : « anime ce personnage avec ce mouvement » repond « pas encore, voici pourquoi » au lieu de ne rien dire ; et ce que Veo ou Remotion savent reellement faire est branche.

Tranche 6 : l'identite visuelle

Resultat observable : « genere avec @<identite> » produit le meme personnage deux fois ; sa voix le suit.

Tranche 7 : la surface

Resultat observable : les composers decrits existent, un seul formulaire, une seule galerie, une carte d'asset.

Tranche 9 : rejouer, verrouiller, versionner

Resultat observable : « refais exactement ca pour la feature B » fonctionne ; « ne change plus cette image » tient ; une recette qui bouge ne reecrit pas le passe.

Six exigences du brief tiennent ensemble parce qu'elles ont toutes le meme prerequis, et c'est pour cela qu'elles sont une tranche et non six : sans les parametres d'une generation en base (tranche 2), on ne peut ni rejouer, ni verrouiller ce qui a produit, ni dire avec quelle version d'une recette un artefact a ete fait.

Tranche 8 : la boucle

Resultat observable : une hypothese produit des creatives, elles partent par canal, ce qui revient se rattache a l'hypothese.

Le master prompt, section par section : ou chaque exigence vit

Le brief compte 105 sections. Un audit qui n'en couvre que les plus visibles laisse croire que le reste est prevu. Ce tableau dit, groupe par groupe, ou l'exigence est portee (une section de ce document, un point de l'ADR 0024, un item), et ce qui n'est porte nulle part encore, avec l'endroit ou ca ira. Une lecture prealable vaut pour tout le tableau : la reference d'ergonomie du brief (le studio generatif tiers) est une reference, jamais un moteur. Ses sections 26 et 93 (lire sa documentation, en deriver une matrice provider) sont remplacees par la meme matrice derivee de NOS six moteurs, sur consigne du 2026-09-18 : ses modeles sont ceux que l'AI Gateway sert deja.

Ce que ce tableau laisse honnetement dehors : le registre de connaissance (51-53), la QA semantique (63) et le pipeline voix-comme- horloge (48). Aucun des trois n'est oublie, aucun n'a d'item, et les trois dependent d'une tranche qui n'est pas livree.

Risques

• La tranche 1 touche le chemin le plus chaud du produit. Deplacer sept outils, c'est risquer de casser le chat. Ce qui l'attenue : les fabriques ne sont pas reecrites, et le test de parite est ecrit avant le deplacement, pas apres.
• AtlasToolContext est un type partage par 26 familles. Lui ajouter deux champs oblige chaque construction de contexte a repondre. C'est voulu (le depot le dit deja pour isPlatformAdmin), mais c'est une PR large.
• La tranche 4 rend visible une depense qui ne l'etait pas. Le cockpit d'economie affichera une marge differente le jour ou la production interne y entre. C'est une correction, pas une regression, et il faut le dire avant.
• Un provider de plus est une surface d'attaque et une facture. Cle serveur seulement, scope non accordable par defaut, plafond ecrit.
• Le squelette d'UI sans les captures est une invitation a deviner. Il est marque comme tel a trois endroits pour que personne ne le lise comme une specification.

Ce qui attend une decision de gouvernance

Aucune de ces questions n'est tranchable par un agent : chacune engage un prix, un contrat, une depense ou un risque juridique. Une question sans item type: "decision" n'atteint jamais le registre, donc le proprietaire ne la voit pas : les cinq qui n'en avaient pas en ont un, et la section 8 de docs/ops/operator-decisions.md les porte avec leur recommandation.

Ce que le backlog en fait

Huit items de travail, un par tranche executable plus les deux que la tranche 2 tire derriere elle, cinq items type: "decision" pour les questions qui n'appartiennent a aucun agent, et six items existants dont la relation a la cible est desormais explicite plutot que devinee.

Les items ouverts par cet audit

La tranche 5 (nommer ce que nos moteurs ne servent pas) et la tranche 8 (la boucle) n'ont pas d'item de travail : la premiere est une evaluation qui tient dans 2780 une fois la famille en place, la seconde attend 2781 et 2783 pour avoir un maillon a rattacher.

Les items existants, replaces