Bibliotheque systeme — le registre des 24 composants

Une ligne par composant de la data source Notion 🧩 Bibliotheque systeme — Prompts, Scripts & Automatisations (collection://794b3bd2-9603-483c-bd54-38e446d5d8f0), avec l'endroit exact ou il vit dans ce depot.

C'est la source. studio-agency-os.md porte le recit et compte ; il compte d'apres ce fichier. Deux endroits qui comptent la meme chose, c'est le probleme que ce registre corrige.

Garde : src/test/studio-library-register.test.ts verifie qu'il y a bien 24 lignes, que chaque chemin cite existe, et que le compteur du recit correspond. Un registre qui rouille se lit comme a jour, c'est pire que pas de registre.

Pourquoi il existe

Le chantier 3.10 pose une regle : un composant ne doit jamais exister aux deux endroits, et chaque composant cable sort de Notion. Quatorze sur vingt-quatre sont cables (le compte de la table plus bas : 2 en code, 12 en prompt ; cette phrase a dit « Dix-sept » puis « Dix-neuf » avant que le plan C, retire le 2026-09-26 par l'ADR 0043, emporte cinq composants de code) ; aucun n'etait sorti, parce que rien ne disait ou il etait parti. Quelqu'un qui ouvre Prompt — Hook Writer e-commerce dans Notion n'avait aucun moyen de savoir qu'il vit dans l'etape IDEATE de creative-ads/prompt.md. Il le modifie dans Notion, et la divergence commence la.

Le registre

Legende de la colonne Etat : ✅ code = regle executable · ✅ prompt = instruction d'un skill · 📄 doc = decrit ici et nulle part ailleurs (rien a executer) · ❌ = pas implemente, ou ❌ retire : implemente puis supprime avec le plan C (ADR 0043), garde ici pour que le composant Notion ne soit pas recable par erreur.

Compte : 24. ✅ code 2 · ✅ prompt 12 · 📄 doc 5 · ❌ 5.

Deux chiffres, et ils ne disent pas la meme chose :

• 19 executes — les composants qui sont devenus une regle ou une instruction que la machine applique (✅ code + ✅ prompt). C'est le compteur que porte studio-agency-os.md.
• 24 sortis de Notion : tous, depuis l'item 0033. Les cinq composants d'orchestration sont radies par le fait d'etre documentes ici : ils n'ont plus besoin de vivre la-bas.

Les cinq composants d'orchestration

Ils decrivent des choses deja codees, eparpillees sur des crons, des skills, le schema et le cockpit. Aucun fichier ne disait « voici la chaine et voici ou chaque maillon vit ». Les voici, et c'est ce qui permet de les radier de Notion.

1. Automation Master Flow — Lead → Learning

Declencheur : changement de statut / gate atteint. Gates humaines : Brand System, concept final, QA. (qualification, claims et envoi client sont partis avec le plan C, ADR 0043.)

La chaine du SOP, maillon par maillon, avec ce qui l'execute :

Les trois gates restantes existent toutes, et aucune n'est franchissable par une machine : chacune est une ecriture derriere une permission studio.*.

Il n'y a pas d'orchestrateur unique, et il ne doit pas y en avoir. Le pseudo-flow Notion decrit un script qui enchaine les 18 etapes. Ce depot le refuse pour une raison precise : six des maillons sont des decisions humaines, et un moteur qui « attend » a six endroits est un moteur qui passe son temps arrete, avec, en prime, un etat de progression a maintenir en double du statut des entites. Ici l'etat est le statut (ConceptStatus, StudioAssetStatus), et il n'y a plus aucun automate : le tick de cadence est parti avec le plan C.

Le seul maillon qui progressait tout seul, open-creative-drop (un drop et trois Task par cycle), est supprime avec le plan C (ADR 0043).

2. Process — Creative Mass Engine Cadence

Gate : aucun volume sans hypothese ; QA obligatoire ; chaque batch doit produire un learning exploitable.

Cinq rythmes dans le SOP. Ce qui existe :

Store.creativeCadence, la cadence de livraison au client, est retiree du schema avec le plan C (ADR 0043) ; la colonne reste orpheline en base jusqu'a son DROP operateur.

Les trois rythmes longs sont des revues, pas de la production. Les cabler avant d'avoir tenu le rythme court plusieurs fois serait exactement ce que le SOP interdit ailleurs : automatiser une chose qui n'a pas encore tourne a la main.

3. Catalogue des competences / agents

Treize competences au SOP. Le routeur de skills (skills/router.ts) selectionne un seul skill par message : treize petits skills se disputeraient hook, angle, avatar, et le classifieur trancherait au hasard. Les competences sont donc des etapes a l'interieur de skills, pas des skills.

A ne pas confondre avec le roster produit (agents/identity-registry.ts) : @Atlas, Maya, Marco, Otis, Faye, Sam sont les agents que la plateforme vend a ses utilisateurs. Les treize competences ci-dessus sont le decoupage interne du Studio. Les deux listes n'ont pas a se correspondre.

4. Logique — Omnichannel Creative Intelligence

Gate : la strategie centrale reste identique ; seule l'execution change selon le canal.

CORE   = Product × Avatar × Angle × Objection × Proof × Offer × Learning
VIDEO  = CORE + Hook + Script + Format + Placement
PDP    = CORE + Decision Job + Slide Order + Visual Hierarchy + Buy-box
ICON   = CORE + Benefit/Feature + Visual Metaphor + UI Context
EMAIL  = CORE + Lifecycle Stage + Subject/Lead + CTA
LANDING= CORE + Page Intent + Section Sequence + CTA

Le CORE porte sept termes. Depuis l'item 0035 ils sont tous quelque part :

Canaux : VIDEO est creative-ads, PDP et ICON sont pdp-conversion. EMAIL et LANDING n'ont pas de skill : le SOP les vend (« declinaisons reutilisables pour paid social, email, landing pages ») et rien ne les produit.

La regle « ne jamais recreer une strategie isolee par canal » est deja tenue par la structure : les deux skills existants lisent le meme CreativeConcept et le meme brandKit.

Elle ne tenait toutefois qu'en lecture. Jusqu'a l'item 0036, rien ne pouvait ecrire un CreativeConcept : les sept termes existaient, la table qui les porte n'avait aucun createur appele, et « les deux skills lisent le meme concept » decrivait deux lecteurs d'une table vide. L'outil saveCreativeConcept est ce qui fait exister la ligne, et il ecrit sans jamais valider : VALIDATED n'est pas dans son schema d'entree, donc la gate humaine reste la seule facon d'y arriver.

5. Logique — Value Density & Cost Advantage

Gate : ne jamais baisser le prix si marge, QA ou capacite se degradent sous le standard.

Value Density = valeur utile livree / cout client

Le cockpit (features/studio/cockpit.ts) mesure sept KPIs (onze jusqu'au retrait du plan C, qui a emporte les quatre KPIs de drop), tous derives a la lecture. Trois portent le denominateur et un seul approche le numerateur :

La valeur livree n'est pas mesurable ici et ne le sera pas. Elle vit chez le client (ROAS, CPA, conversion), et le Studio ne l'observe que lorsque la marque la partage : c'est-a-dire dans CreativeLearning, avec la distinction measured / asserted de l'item 0031. Un KPI « Value Density » calcule a partir de donnees que nous n'observons pas serait precisement le genre de chiffre invente que le SOP interdit partout ailleurs.

Le gate reste donc un arbitrage humain, adosse a deux verrous qui, eux, sont dans le code : Store.marginViable et Store.capacityValidated, deux des onze conditions du Go/No-Go. Baisser un prix sous le standard n'est pas empeche par une formule ; c'est empeche par un GO qui ne se leve plus.

6. Offer Architecture, ce qui reste humain

Le composant 19 est code pour sa partie verifiable (oneShotFoundation[], contentFactory[], la condition offerScope), et son gate, « aucune brique recurrente sans besoin recurrent reel ; aucune refonte one-shot sans changement concret », ne l'est pas. Il ne peut pas l'etre : rien dans les donnees ne distingue un besoin recurrent reel d'un besoin recurrent vendu. C'est une question posee au commercial, pas au systeme.

Les trous, et ou ils sont suivis