Livraison complète d’Atlas comme moteur conversationnel de BoostEcom

Date : 17 septembre 2026. Statut : plan de livraison, pas constat de livraison.

Demande : livrer l’ensemble dans une seule PR, en réutilisant la codebase, avec une conversation continue, des tâches en arrière-plan, une équipe d’agents, des artifacts, des sandboxes, les stores, la marketplace, les partenaires et toutes les surfaces de l’OS.

PR de travail : #1277. Référence auditée : main au commit 680f2b3d. Les ajouts Studio sont examinés séparément au commit e06b01e6 de cette PR. Aucun comportement en production n’est déduit de la seule présence d’un fichier.

Suivi (17 septembre 2026, soir). La PR #1277 est mergée ; le programme continue par PR successives, jamais dans une seule. Depuis l’audit : les six points de P00 listés en §2 sont fermés (sharp déclaré et les quatre défauts qu’il cachait, ai-platform/2750 ; composeProductImage classé safe_write dans la matrice), l’ancien système de workflow est supprimé et la porte du plan posée sur celui qui exécute (2703, lots 1 et 2), le Worktree lit, ouvre et enregistre (2712), le footer de la preview a ses deux familles (2713-2715), la première famille d’actions exécutables du plan existe (2728, ADR 0021). La PR de cohérence du chat et du kernel (branche claude/epic-franklin-qdfwc8) ferme le kernel double (ADR 0022 : un seul texte, plus de chargeur YAML ni de gardes isAtlasAvailable()), rapatrie le composeur 3 couches dans le pilier, convertit les 52 console.* restants du runtime, et archive trente items livrés mais restés ouverts. Les lots P01 à P17 restent à construire : rien ci-dessous n’est un constat de livraison.

Lecture rapide : état réel, architecture, 18 lots, jalons, couverture, 42 scénarios, preuves de fin.

1. Le résultat à livrer

L’utilisateur parle à @Atlas dans son espace de travail habituel. @Atlas comprend l’objectif, retrouve les informations utiles, découvre les capacités disponibles, compose plusieurs compétences et délègue le travail approprié. Il livre un résultat vérifié, consultable et modifiable dans le chat et les autres surfaces.

Une mission continue quand l’utilisateur change de page ou ferme son navigateur. Pendant son exécution, l’utilisateur peut discuter d’autre chose, corriger une consigne, demander l’avancement, suspendre ou annuler une branche, approuver une action et retrouver les résultats plus tard. Une fermeture de page est une déconnexion d’affichage, jamais une demande d’annulation.

Les outils, skills, prompts, MCP, connecteurs, workflows, agents et services humains rejoignent une même couche de capacités. Le chat, Workflow, WorkTree, Preview, les pages du store, la voix et l’API sont des portes d’entrée vers cette couche.

Critère de fin : chaque exigence du tableau de couverture et chaque scénario obligatoire de ce document dispose d’une preuve de fonctionnement. Un composant, un endpoint, une capture ou une réponse du modèle ne suffit pas.

Ce que signifie « sans limite » dans ce produit

• Aucune liste de capacités figée qui oblige à reconstruire le chat pour ajouter un métier.
• Aucune nouvelle conversation imposée parce que la fenêtre du modèle est pleine.
• Aucune dépendance à un bouton de toolbar pour rendre une capacité découvrable.
• Aucun travail durable dépendant de la présence du navigateur.
• Des extensions explicites pour les capacités nouvelles, plutôt qu’une promesse de pouvoir exécuter toute action imaginable.
• Les autorisations, les coûts, les API disponibles et les étapes nécessitant un humain restent des faits du système. @Atlas les traite dans le même parcours, avec reprise de la mission.

2. Ce qui existe et ce qui manque

Une grande partie des briques existe. Un taux de 75 % de l’expérience complète n’est pas démontré.

Le dépôt contient déjà le chat, la mémoire, les outils métier, les spécialistes, MCP, des jobs asynchrones, le provisioning Shopify, des surfaces de preview, un éditeur, un canvas et une marketplace. Ce capital est à conserver.

Le travail manquant se concentre sur des éléments très structurants : exécution universelle durable, composition de capacités, reprises après interruption, concurrence entre conversation et missions, installation transactionnelle, véritable environnement d’exécution de code, réservation humaine et cohérence des surfaces. Leur coût ne se déduit pas du nombre de composants déjà écrits.

L’audit est une lecture ciblée des chemins d’exécution et de leur documentation, complétée par les captures et la conversation jointes. Il ne constitue ni une recette de production ni une mesure de tous les services et comptes connectés.

Inventaire vérifié

« Présent » signifie que le code correspondant existe. « Partiel » signifie qu’un parcours manque ou conserve une limitation déterminante. « À construire » signifie que le contrat universel demandé n’est pas implémenté dans les chemins examinés.

Ce que la PR actuelle ne doit pas masquer

La PR #1277 n’est pas la livraison du programme complet. Son contrat d’architecture est un document, pas un executor.

Points concrets à traiter au lot P00 :

1. Le nouvel outil composeProductImage n’apparaît pas dans la matrice de risques du socle audité. Le comportement par défaut y est « destructive » et les skills peuvent donc le filtrer. Enregistrer sa politique et vérifier son exposition réelle.
2. Une assertion du test Studio cherche des backticks non échappés dans le texte source du prompt, qui contient des backticks échappés. La comparaison de chaînes échoue ; ce test n’est pas une preuve d’intégration.
3. Le compositeur vérifie les pixels opaques retenus par le masque. Il ne prouve pas que le masque contient tout le produit ni qu’il exclut tout l’arrière-plan. Le seuil actuel de 0,999 ne correspond pas non plus à une exigence littérale de 100 %.
4. L’ouverture d’un artifact reçu après le début du streaming doit être testée dans le composant monté. Une valeur defaultOpen initiale ne démontre pas cette transition.
5. Les vérifications locales précédentes étaient limitées. Les jobs CI observés se terminaient sans steps exécutées. Le dépôt décrit cette signature comme un épuisement de quota Actions ; elle ne valide aucun test.
6. Deux fichiers ajoutent un import direct de sharp, absent des dépendances directes du package audité. Déclarer explicitement la dépendance et vérifier le lockfile, la résolution sous pnpm et le build cible avant de valider le compositeur.

3. Architecture de livraison

La couche commune est un service serveur consommé par les surfaces, pas un deuxième chat ni une seconde bibliothèque de tools.

Objets et responsabilités

Les noms suivants désignent les modèles logiques à implémenter, pas des tables déjà présentes.

Adapter ToolApprovalRequest, Task, WorkflowRun, Conversation et Message avec des références vers le run, en conservant leur rôle métier. Ne pas détourner AgentRun, qui décrit les sessions de la flotte de développement, branches et PRs. Réutiliser StudioAsset et ScanArtifact via références ou adaptateurs, au lieu de recopier leurs objets métier dans de nouvelles tables.

Postgres reste la source de vérité du produit. Redis peut accélérer la diffusion ; Blob conserve les fichiers. Le journal est partitionnable/paginable et ses payloads sont bornés : ne pas stocker chaque gros résultat ni chaque token du modèle dans une ligne d’événement.

États et reprises

États proposés : queued, planning, running, waiting_for_user, waiting_for_approval, waiting_for_connection, waiting_for_human, waiting_for_children, paused, verifying, completed, failed, cancelled.

Chaque attente précise sa raison, sa condition de réveil et son expiration éventuelle. Un résultat partiel est représenté explicitement et n’est pas annoncé comme une réussite complète.

• Une transition terminale exige un résultat vérifié, une erreur explicite ou une annulation enregistrée.
• Une action avec issue incertaine conserve cette incertitude jusqu’à réconciliation.
• Une attente d’humain ne monopolise ni une fonction serveur ni un slot de calcul.
• Une reprise recharge les autorisations actuelles, les credentials et les versions nécessaires.
• Un redéploiement conserve le handler compatible avec les runs en cours, ou les place en pause explicite avant une migration. Il ne les redémarre pas silencieusement depuis le début.

Choix du moteur durable

Base de travail : un RunDriver sur Postgres et la file QStash existante, avec exécution en unités courtes et checkpoints. La file transporte les réveils ; elle ne remplace ni les états métier ni la déduplication des effets.

Le lot P00 compare cette base à Vercel Workflow sur un prototype réel : lancement, crash, reprise, attente d’approbation et reconnexion. Un seul driver sera retenu pour les nouveaux runs Atlas. Conserver les jobs métier existants et leurs adaptateurs quel que soit ce choix.

Critères de décision : compatibilité avec les versions verrouillées du dépôt, reprise démontrée, coût mesuré, fonctionnement sur les déploiements existants, secrets hors checkpoints et possibilité de réconcilier les effets externes. La décision et les versions sont consignées dans un ADR avant P04.

Cette vérification est nécessaire : le dépôt déclare AI SDK 6, alors que la documentation actuelle de WorkflowAgent utilise une famille de packages plus récente et Workflow 5 beta. Ne pas installer au hasard le package cité par un ancien commentaire.

4. Lots d’implémentation dans la PR unique

Les lots servent à organiser les commits et la revue. Ils ne créent pas dix-huit PRs. Les responsabilités désignent les piliers à faire relire ; elles n’impliquent pas que des agents ont été lancés.

P00. État de référence et correction des défauts connus

Pilote : ai-platform, avec QA. Dépendance : aucune.

• Transformer les captures et l’exemple de bague en fixtures de recette anonymisées.
• Inventorier les factories, skills, registres, actions de toolbar et endpoints ; relever tous les mocks, simulations, TODO d’exécution et actions sans consommateur.
• Corriger les six points de la PR listés plus haut, sans présenter le vertical Studio comme achevé avant validation.
• Mesurer sur main les appels outils, erreurs, latences et coûts des scénarios représentatifs.
• Faire le prototype comparatif du RunDriver et produire l’ADR.
• Vérifier versions installées, provider Sandbox, disponibilités du calendrier partenaire et environnements de recette. Une disponibilité non vérifiée reste visible dans le suivi.

Sortie exigée : un état initial reproductible, un driver choisi sur preuve, un test montrant qu’une demande de produit fidèle atteint réellement le compositeur et un état honnête des dépendances externes.

P01. Contrats, persistance et journal communs

Pilote : ai-platform + data-platform. Dépendance : P00.

• Implémenter les objets logiques de la section 3, les transitions validées et les index tenant/run/séquence/idempotence.
• Créer la transaction « message accepté + run + premier événement + outbox ».
• Exposer création, lecture, événements par curseur et commandes ; toute lecture et écriture est authentifiée et scoped.
• Définir les projections de Task, WorkflowRun, ledger et Message.parts sans doubles sources de vérité.
• Versionner les événements, plans et contrats d’outils ; accepter les anciennes parts en lecture.
• Respecter la procédure schema-first du dépôt : schéma Prisma, guard généré, contrôles de compatibilité et éventuelles EXTRA_STEPS. Aucun reset de base et aucune migration destructive implicite.

Ancrages : schéma, ledger, Task.

Sortie exigée : même run relu après redémarrage, mêmes événements ordonnés sur deux clients, refus de lecture ou de commande depuis un autre tenant.

P02. Registre de capacités et découverte dynamique

Pilote : ai-platform + integrations. Dépendances : P00, P01.

• Normaliser outils natifs, skills de store, connecteurs, MCP, marketplace, workflows, agents et humains sous un descripteur commun.
• Déclarer identifiant stable, version, description, domaines, schémas, exigences, coût, latence, risque, vérificateur, supports d’idempotence et de compensation.
• Distinguer disponible, installé, connecté, autorisé et actif. Une capacité absente du tenant peut être découvrable comme option d’installation sans être exécutable.
• Découvrir d’abord les métadonnées, puis charger les schémas utiles. Appliquer la même sélection aux tools natifs, d’équipe et MCP.
• Préserver un chemin de découverte à chaque phase pour ne pas amputer les capacités. Les fenêtres initiales de 10–20 candidats et 2–8 outils actifs sont des hypothèses de mesure, pas des plafonds produit.
• Prioriser les outils métier pertinents ; rendre le GraphQL générique accessible comme recours explicite et audité.
• Faire dépendre chaque action de ses exigences réelles, plutôt que de l’état Shopify pour tout l’OS.
• En cas de connexion ou d’installation en cours de run, invalider le cache du tenant et rafraîchir le registre sans recommencer la mission.

Ancrages : filtre, tools, MCP, layer.

Sortie exigée : une demande utilisant commerce + recherche + Studio trouve les trois ; ajouter un MCP ne contourne pas la sélection ; un utilisateur sans Shopify conserve les capacités indépendantes de Shopify.

P03. Planification, boucle d’agent, réparation et vérification

Pilote : ai-platform. Dépendances : P01, P02, P06.

• Remplacer la sélection exclusive d’un skill par un plan d’objectif : sous-objectifs, dépendances, compétences, preuves attendues, étapes et critères de fin.
• Extraire le moteur du handler HTTP en modules réutilisables. Conserver les contrats AI SDK et la plomberie utile ; ToolLoopAgent est une option de factorisation, pas une preuve de durabilité.
• Utiliser prepareStep et activeTools en fonction du plan et des résultats observés, avec possibilité de replanifier.
• Remplacer le plafond universel de dix étapes par des enveloppes de calcul adaptées au run et une continuation persistante. Un budget atteint donne une suspension ou une fin explicite.
• Réparer les arguments invalides avant effet, avec essais bornés et schéma courant. Ne jamais « réparer » une permission refusée en élargissant les droits.
• Retourner des résultats d’outils typés et compacts : données utiles, evidenceRefs, artifactRefs, erreurs et état. Conserver les réponses volumineuses hors contexte.
• Vérifier les sorties : relecture d’une mutation Shopify, fichier réellement créé, booking fournisseur confirmé, mesures et sources présentes. Le modèle ne certifie pas seul une action.
• Classifier les échecs transitoires, permanents et à résultat incertain. Une erreur n’est ni cachée dans du prose ni annoncée comme une réussite.

Ancrages : handler, router, build tools.

Sortie exigée : un objectif multi-métier aboutit à des résultats vérifiés ; une erreur de schéma récupérable est corrigée ; une sortie non vérifiée reste indiquée comme telle.

P04. Exécution durable, scheduling et reprise après crash

Pilote : ai-platform + platform-ops + billing. Dépendances : P01, P06, décision P00.

• Dispatcher depuis l’outbox ; accepter un run une seule fois même si l’API ou la file reçoit deux fois la demande.
• Claim atomique avec lease et numéro de génération ; refuser les écritures d’un worker dont le lease a été remplacé.
• Checkpointer avant et après les frontières d’effets et à chaque étape significative. Découper les missions longues au lieu d’augmenter seulement maxDuration.
• Reconstruire les clients et les credentials dans le worker après revalidation des grants.
• Séparer req.signal du signal serveur d’annulation. Retirer req.signal ne suffit pas : le worker et ses reprises doivent survivre à la fonction HTTP.
• Réessayer les lectures et les actions idempotentes selon leur contrat ; enregistrer les effets non idempotents et les réconcilier avant tout retry.
• Gérer réveils programmés, récurrences, rappels et événements ; stocker fuseau, prochaine échéance et politique de rattrapage.
• Prévoir heartbeat, détection de runs bloqués, DLQ et relance contrôlée. Une indisponibilité de la file laisse un état queued traçable et une reprise par outbox.
• Réserver/compter les coûts au niveau du run et de ses enfants ; libérer les réservations non consommées sans effacer le coût d’appels déjà effectués.

Ancrages : jobs, route worker, runner de lancement.

Sortie exigée : fermer l’onglet, tuer un worker et redéployer n’entraînent ni perte du run ni double écriture métier. Un timeout après effet externe donne une réconciliation, pas un retry aveugle.

P05. Conversation concurrente et commandes en cours de travail

Pilote : ai-platform + app-shell. Dépendances : P01, P04, P06.

• Permettre plusieurs missions associées au même fil tout en gardant une réponse interactive courte.
• Persister chaque nouveau message et ses pièces jointes au moment de l’envoi. Ne plus associer un prompt en attente aux attachments présents lors de son envoi différé.
• Associer réponses et cards au bon message et au bon run ; gérer deux onglets et les complétions arrivant dans un ordre différent du lancement.
• Introduire les commandes « corrige », « fais plutôt », « où en es-tu », « pause », « reprends », « annule cette branche » et « rappelle-moi ».
• Appliquer les corrections à une version explicite du plan à une frontière sûre. Une action déjà effectuée requiert une compensation ou une nouvelle action, pas une réécriture de l’historique.
• Définir clairement pause du calcul, annulation du run, interruption de l’affichage et arrêt de la voix.
• À la reconnexion, charger snapshot puis événements après curseur, rattraper les trous et dédupliquer.
• Envoyer les notifications de fin via les canaux choisis par l’utilisateur ; le résultat reste dans le fil même sans notification externe.

Ancrages : queue, resume, transport.

Sortie exigée : l’utilisateur pose une question pendant un benchmark de plusieurs minutes, modifie le périmètre du benchmark, ferme la page puis retrouve la réponse et le livrable au bon endroit.

P06. Politique, autorisations et approbations avec reprise

Pilote : ai-platform + security-identity + billing. Dépendance : P01.

• Réutiliser la matrice de risques, les rôles, les scopes, le contrôle d’autonomie et les approbations existants.
• Lier l’accord à l’acteur, au tenant/store, au run/étape, à la version de capacité et à l’empreinte des arguments. Une modification invalide l’accord précédent.
• Projeter l’approbation dans les états natifs AI SDK 6 et reprendre côté serveur après la décision. Le clic client est une demande, jamais une autorité suffisante.
• Revalider droits, crédits, scopes et état du connecteur au moment de l’effet, y compris dans un agent enfant ou après plusieurs jours d’attente.
• Garantir une seule consommation par effet ; refus, expiration et double clic ont une issue stable.
• Montrer l’action et sa conséquence utile : cible, montant éventuel, publication, destinataire ou changement de permission. Éviter de demander un accord pour chaque lecture.
• Définir les comportements lors d’une révocation en plein run et maintenir les preuves/audit logs existants.

Ancrages : matrice, autonomie, wrapper.

Sortie exigée : « approuver » exécute l’action attendue sans nouveau prompt ; un autre utilisateur, un accord expiré ou des arguments altérés ne peuvent la déclencher.

P07. Équipe d’agents et délégation observable

Pilote : ai-platform. Dépendances : P02–P06.

• Réutiliser @Maya, @Marco, @Otis, @Faye et @Sam, leurs identités et les règles de délégation.
• Donner à chaque mission déléguée un run enfant, un objectif, un contexte borné, des capacités, un budget et un livrable attendu.
• Conserver les appels courts possibles, mais rendre les travaux longs détachables et reprenables.
• Gérer fan-out/fan-in, dépendances et échecs partiels ; @Atlas synthétise les résultats et pointe leurs artifacts.
• Exposer l’activité utile : qui travaille, sur quoi, avec quelles sources, ce qui attend et ce qui a été livré. Les traces internes du modèle ne sont pas le contrat d’observabilité.
• Propager correctement annulation, décisions et plafonds de coût. Empêcher les boucles de délégation et contrôler la concurrence.
• Isoler les modifications concurrentes d’un même objet : branches de workspace, versions attendues, conflit explicite avant publication.
• Permettre réaffectation, relance d’un enfant et passage à un humain avec le brief existant.

Ancrages : delegate tool, team, identités.

Sortie exigée : deux spécialistes travaillent en parallèle, une branche est corrigée sans perdre l’autre, et chaque coût/résultat reste attribué au bon agent.

P08. Conversation continue, mémoire et contexte

Pilote : ai-platform + data-platform. Dépendances : P01, P05.

• Réutiliser Conversation, Message, ConversationSummary, OrgFact, StoreFact, UserFact, MemoryEvent et les index vectoriels existants.
• Définir le fil stable par utilisateur/espace et les règles de changement de boutique. Une cible affichée dans l’UI ne change jamais rétroactivement le scope d’un run.
• Conserver l’historique durable et paginé ; compacter uniquement le contexte envoyé au modèle, avec références vers les messages d’origine.
• Dédupliquer l’ingestion et la résumer depuis une borne de séquence connue, afin que deux runs concurrents ne perdent pas mutuellement leurs mises à jour.
• Rendre extraction/indexation reprenables et observables. La mémoire actuelle est best-effort ; des retries durables sont nécessaires pour éviter des pertes silencieuses.
• Retrouver décisions, préférences explicites, artifacts, travaux en cours et faits métier pertinents. Ne pas injecter tout l’historique dans chaque appel.
• Traiter une correction explicite comme une décision datée, avec provenance et remplacement du fait actif ; ne pas inventer un fait manquant.
• Conserver les contrôles de modification, export et suppression. « Tout se mémorise » ne doit pas empêcher l’utilisateur d’effacer ou de désactiver une mémorisation.

Ancrages : mémoire, history, parts et résumés.

Sortie exigée : un long fil reste utilisable sans nouvelle session, retrouve une ancienne décision exacte et respecte une correction ou une suppression après réindexation.

P09. Artifacts typés, versionnés et rendus dans le fil

Pilote : ai-platform + design-system + data-platform. Dépendances : P01, P06.

• Définir des types pour image, vidéo, vectoriel, document, tableau, dataset, graphique, rapport, benchmark, code/diff, section/bloc Shopify, workflow, preview et reçu de rendez-vous.
• Décrire payload, provenance, statut de validation, version et actions possibles par type.
• Persister chaque artifact avant d’annoncer qu’il est livré. Référencer les assets métier existants au lieu de créer des copies divergentes.
• Un registre de renderers transforme les références d’artifacts en éléments AI Elements. Pas de JSON brut dupliqué ni de simple URL à la place d’une image.
• Permettre ouvrir, comparer les versions, modifier, télécharger, rattacher au store/projet et réutiliser dans une nouvelle mission.
• Protéger l’accès aux fichiers privés, renouveler les liens expirés et isoler les previews de contenu actif.
• Pour charts et benchmarks : conserver les données, unités, devise, période, source et fraîcheur. Les calculs sont reproductibles hors texte génératif.
• Gérer les anciennes parts et les types inconnus avec un fallback lisible ; une part invalide ne casse pas tout le message.

Ancrages : renderer, AI Elements, Studio.

Sortie exigée : une image, un graphique, un diff et un rapport se rouvrent après rechargement avec le même contenu, leurs sources et leurs actions.

P10. Sandboxes de calcul et WorkTree opérationnel

Pilote : ai-platform + platform-ops + security-identity. Dépendances : P04, P06, P09.

• Ajouter un provider d’environnement isolé pour exécuter du code, manipuler des fichiers, installer les dépendances autorisées et démarrer une preview.
• Évaluer Vercel Sandbox sur le projet réel ; encapsuler le provider pour ne pas lier les artifacts à une session éphémère.
• Associer workspace, fichiers, commandes, processus, logs et références de sauvegarde au tenant et au run.
• Conserver les fichiers durables et la provenance des versions en dehors d’un processus de preview. Tester arrêt, expiration et reprise selon la version du provider retenue.
• Raccorder WorkTree : arborescence, chargement, édition, diff, sauvegarde, annulation locale, tests, console et erreurs. Le nom WorkTree dans l’UI ne suffit pas à prouver l’existence d’un git worktree.
• Séparer brouillons utilisateur et écritures d’agents ; gérer conflit de version, application sélective et restauration.
• Faire du terminal une véritable capacité serveur : stdout/stderr et code de sortie réels, annulation de processus, pas de faux écho réussi.
• Restreindre credentials, accès réseau et ressources à l’environnement de la mission. Aucun secret du store n’est injecté par défaut dans un projet généré.
• Exposer la preview comme artifact réouvrable depuis chat, éditeur et pages. Une sandbox expirée propose reprise/restauration, pas un écran vide.

Ancrages : éditeur, preview. Le REPL du footer a été retiré.

Sortie exigée : @Atlas crée un petit outil interactif, l’exécute, corrige une erreur réelle, présente sa preview et permet une modification manuelle conservée après reconnexion.

P11. Stores, thèmes, sections, blocs et toolbar de preview

Pilote : ai-platform + integrations + commerce-systems + app-shell. Dépendances : P02, P04, P06, P09 ; P10 pour les previews de code.

• Adapter les exécuteurs de provisioning et de lancement déjà présents au suivi universel.
• Exposer création de store, connexion, état du pool, transfert et checkpoints dans la conversation, avec reprise après une action humaine ou l’arrivée d’une capacité du pool.
• Générer sections/blocs Liquid, fichiers JSON de thème, styles et assets via des artifacts/diffs versionnés.
• Valider syntaxe, schéma de section, références d’assets et rendu sur un thème de développement avant toute publication.
• Raccorder sélection DOM, capture, diagnostics, navigation, viewport, reload, DevTools, thème sélectionné et contexte des pages à des actions ayant un effet observable.
• Conserver une seule identité de thème/preview entre WorkTree, StoreBrowser et chat ; la cible de publication est explicite.
• Respecter le garde du thème MAIN et la politique de publication. Relecture des fichiers et vérification du rendu après application ; rollback vers une version identifiée.
• Distinguer sandbox de code, storefront de dev, thème draft et store publié. Chacun a son propre moteur de preview et ses propres possibilités d’écriture.
• Fermer le sujet d’origine dédiée et des permissions du proxy pour les contenus non fiables avant exposition des previews arbitraires.

Ancrages : theme tools, theme-assets API, StoreBrowser, provisioning.

Sortie exigée : « crée ce bloc, montre-le, modifie ce détail » fonctionne dans chat/WorkTree/preview ; seul le thème ciblé est modifié et une restauration vérifiée est possible.

P12. Canvas Workflow et exécution universelle

Pilote : ai-platform. Dépendances : P01–P04, P06, P09.

• Conserver l’éditeur v2 existant ; ne pas réintroduire le canvas supprimé.
• Unifier le document Workflow, les templates du chat et les routes existantes. Versionner le graphe et migrer les graphes legacy avec une issue explicite pour les types non convertibles.
• Faire compiler les nœuds en étapes/capacités du run commun : outils, agents, skills, MCP, conditions, jointures, attente, approbation, mémoire, artifacts et humains.
• Implémenter les sorties conditionnelles réelles, nœuds ignorés, dépendances, fan-out/fan-in, erreurs, retries et reprises partielles. Une condition ne peut pas seulement produire le texte « false » puis laisser toutes les branches tourner.
• Raccorder image et mémoire aux vraies capacités ; un type sans executor est indisponible ou refusé avant démarrage, jamais déclaré completed après pass-through.
• Créer le run avant exécution et streamer le même journal que le chat. L’exécution continue après fermeture du canvas.
• Planifier les triggers manuels, horaires, webhook et métier, avec déduplication et contrôle de scope.
• Permettre à @Atlas de créer, expliquer et modifier le workflow ; changer le graphe d’un run en cours crée une nouvelle version appliquée à une frontière contrôlée.

Ancrages : v2, execute API, templates. L'ancien run n'est plus un ancrage : il est supprime avec le reste du systeme legacy (ai-platform/2703, lot 2).

Sortie exigée : un workflow créé dans le chat s’ouvre et s’exécute dans le canvas ; un workflow créé dans le canvas est pilotable depuis le même fil ; une branche non choisie n’a aucun effet.

P13. Installation conversationnelle de packages

Pilote : ai-platform + marketplace + integrations. Dépendances : P02, P04, P06.

• Définir un manifeste par version : éditeur, type, capacités, schémas, dépendances, scopes, configuration, coût éventuel, provenance et actions d’installation/désinstallation.
• Adapter séparément chaque format : skill, prompt, tool natif, MCP, connecteur OAuth/API, workflow et agent. Un prompt installé ne reçoit aucun privilège supplémentaire.
• Réutiliser registry Skill, store skills, catalogues, McpConnector et services OAuth ; ne pas traiter leurs stockages différents comme une installation déjà unifiée.
• Dans le fil : rechercher, comparer, montrer les permissions utiles, installer, connecter si nécessaire, tester la connexion, activer puis reprendre le run.
• Garder l’URL de retour et la corrélation run/install pendant OAuth ; accepter le callback de façon idempotente. Les secrets sont saisis hors texte conversationnel.
• Gérer mise à jour, rollback, désactivation, révocation, dépendance manquante et installation partielle. Refuser les versions incompatibles avant activation.
• Permettre découverte MCP des ressources/prompts pertinents lorsque le transport le supporte, en plus des outils ; ne pas présumer que tous les serveurs offrent toutes les primitives.
• Passer les packages contenant du code par une exécution isolée et une politique d’installation. Une fiche marketplace n’autorise pas l’exécution de code côté serveur de l’app.
• Respecter les validations d’achat et de scopes ; une étape externe obligatoire conserve son état d’attente et son bouton de reprise.

Ancrages : skills tools, registry API, MCP API, connecteurs.

Sortie exigée : demander un outil absent conduit à une installation réelle puis à son utilisation dans le même run ; désinstaller le rend immédiatement non exécutable, y compris dans un enfant.

P14. Marketplace humaine, partenaires et rendez-vous

Pilote : marketplace + ai-platform + integrations. Dépendances : P04, P06, P09, P13 pour la connexion calendrier.

• Réutiliser profils, rôles délégués, recherche marketplace, leads, deals, commandes et messages existants.
• Construire le brief avec objectif, contexte autorisé, références d’artifacts, livrables et critères de validation.
• Découvrir un partenaire approprié ; distinguer profil publié, disponibilité connue et service effectivement réservable.
• Implémenter un adaptateur réel de disponibilités et réservation, ou le service interne correspondant. Tester fuseaux, changement d’heure, durée, conflits et validité du créneau.
• Préparer la prise de rendez-vous dans le chat ; confirmer destinataire, créneau et effet selon la policy ; enregistrer référence externe et état de réservation.
• Un lien Calendly, un lead ou un email envoyé ne devient pas « rendez-vous confirmé » sans confirmation du système concerné.
• Gérer annulation, déplacement, rappels, refus, expiration et absence de disponibilité, sans doublons d’invitation.
• Donner au partenaire uniquement l’accès délégué nécessaire ; afficher le brief partagé et gérer sa révocation.
• Suivre le travail humain, intégrer la livraison comme artifact et permettre corrections/validation dans le fil.
• Si le service est payant, rattacher au parcours de commande/approbation existant ; ne pas recréer le ledger marketplace.

Ancrages : marketplace, tools, leads, accès délégué.

Sortie exigée : un vrai partenaire de recette reçoit un brief autorisé, un créneau est réservé et relu chez le fournisseur, puis une modification est répercutée une seule fois dans le run.

P15. Métiers e-commerce, recherche, intelligence et Studio

Pilote : ai-platform + commerce-systems + intelligence. Dépendances : P02–P09.

• Adapter toutes les factories existantes au registre, en priorisant catalogue, thèmes, opérations, analytics, knowledge, intelligence, CRO/AOV/AEO, Studio et marketplace.
• Rendre la génération image/vidéo/vectoriel découvrable par intention, sans dépendance au bouton. Conserver les préférences explicites comme contraintes ou hints selon leur sens.
• Relier les recherches web et données marchandes à des preuves datées et à des résultats lisibles ; distinguer mesures, estimations et absence de données.
• Produire analyses, graphs et benchmarks reproductibles : mêmes périodes, unités et définitions, provenance et possibilité d’export.
• Assurer la traçabilité Studio : références produit, brief, concept éventuel, coût, droits d’accès, artifact et validation. Un test d’image simple n’impose pas de construire une campagne entière.
• Pour le cas de la bague : fournir automatiquement un résultat composite final dans le chat ; ne pas déléguer à l’utilisateur une opération que la nouvelle capacité sait faire.
• Définir deux modes explicites : conservation exacte des pixels source dans la zone produit, ou transformation/rendu à fidélité évaluée. Une nouvelle pose, une nouvelle vue 3D, un redimensionnement ou un étalonnage ne peuvent pas être certifiés comme égalité de tous les pixels source.
• Dans le mode exact : pas de resampling/correction du produit, contrôle d’égalité strict sur la zone opaque préservée, protection du masque et validation séparée du détourage. Retenter ou permettre correction du masque sans régénérer le produit.
• Pour image/vidéo transformée : expliciter la transformation et son statut QA ; aucune métrique d’identité sémantique ne se substitue à une garantie pixel à pixel.
• Vérifier les effets métier : draft créé, asset sauvegardé, ressource relue. Une analyse ou une proposition ne vaut jamais publication.

Ancrages : tools, Studio build, compositeur, intelligence.

Sortie exigée : « analyse mon produit, compare trois concurrents, propose des angles, produis les créas et prépare la campagne sans publier » suit plusieurs capacités et rend des livrables vérifiables.

P16. Chat, toolbar et cohérence de toutes les surfaces

Pilote : ai-platform + app-shell + design-system. Dépendances : intégration progressive de P05–P15.

• Reprendre la référence jointe : progression compacte, sources/documents consultés, artifacts inline, actions utiles et conversation lisible.
• Corriger le double chrome/en-tête signalé dans les captures, les blocs « Impossible d’afficher cette partie », le Markdown suréchappé et les outils affichés deux fois.
• Conserver les détails techniques accessibles dans l’inspecteur sans les imposer à la lecture du fil.
• Assurer les transitions streaming, attente, résultat, erreur, reprise et changement de version dans les composants déjà montés.
• Relier toutes les commandes de toolbar au registre et au contexte réel. Les tests vérifient l’effet serveur et sa persistance, pas seulement qu’un clic ouvre un panneau.
• Réutiliser les contrats UIMessage.parts, DefaultChatTransport, AI Elements et les stores partagés ; éviter un deuxième protocole propre à chaque surface.
• Garder le contexte du message à l’envoi : organisation, store, thème, sélection DOM, fichiers, modèle, autonomie et cible de correction.
• Tester responsive, clavier, focus, lecteurs d’écran, autoscroll et navigation pendant streaming. Les six langues de l’app doivent rester cohérentes.
• Afficher ce qui est disponible et expliquer une dépendance manquante au moment utile ; aucun bouton actif ne promet une action simulée.

Ancrages : chat runtime, composer, bridge, preview.

Sortie exigée : mêmes état, artifact, cible et action depuis chat, Workflow, WorkTree, preview et pages ; retour de navigation sans perte de progression.

P17. Recette, observabilité, déploiement et retrait des doublons

Pilote : QA + ai-platform + platform-ops ; revue des piliers touchés. Dépendance : tous les lots.

• Transformer les scénarios ci-dessous en tests comportementaux et evals, avec fixtures stables et contrôles réels sur environnements de recette.
• Corréler run, étape, appel modèle, tool, facture, artifact et erreur ; exclure secrets et payloads privés inutiles des logs.
• Mesurer taux de succès vérifié, refus justifiés, doublons, qualité de sélection, coût, latence, retard de file et délai de propagation des événements.
• Tester charge, chaos, reprise après déploiement, longues attentes, multi-store et accès concurrents.
• Activer progressivement par feature flags serveur et tenant ; conserver une seule autorité d’exécution pour chaque famille de runs.
• Supprimer les simulations, chemins de lancement concurrents et prompts devenus contradictoires après migration.
• Fournir runbooks : worker indisponible, queue saturée, connecteur expiré, résultat externe incertain, run bloqué, artifact expiré, restauration de workspace.
• Fermer la PR seulement après les preuves et gates de la section 8. Le merge et le déploiement production restent des gestes distincts de la préparation de la PR.

Sortie exigée : aucun scénario obligatoire non traité, aucune simulation vendue comme exécution, validation indépendante de la seule réponse d’@Atlas.

5. Ordre de livraison et dépendances

P02 et P08 peuvent avancer après leurs propres dépendances, sans attendre artificiellement tout J2. L’ordre des jalons est celui des démonstrations et de la revue, pas une obligation de sérialiser toutes les modifications.

Premier parcours vertical à fermer : lancer un audit réel, obtenir son run immédiatement, discuter pendant qu’il travaille, fermer la page, retrouver son rapport inline, corriger une consigne et relancer seulement l’étape nécessaire. Cette démonstration valide le socle commun avant d’y raccorder tous les métiers.

Aucune date de livraison globale ni proportion d’effort n’est certifiée par cet audit. Estimer les lots après J0, en séparant réutilisation, intégration, nouveau code, recette et dépendances de compte. Les preuves, et non le nombre de lignes modifiées, font avancer le plan.

6. Matrice de couverture de la demande

Recette exhaustive de la toolbar

P00 produit la liste dérivée de tous les contrôles réellement présents. Pour chaque contrôle, enregistrer identifiant, composant, contexte lu, endpoint/capacité, permission, effet, état persistant et test. La liste suivante fixe les familles minimales ; elle ne remplace pas l’inventaire dérivé.

7. Scénarios d’acceptation de bout en bout

Tous sont à valider. Les environnements de recette, doubles déterministes et tests live sont indiqués dans les preuves. Un test live ne doit pas publier sur un store réel ni inviter un partenaire non prévu pour la recette.

Les cas A02/A03 doivent inclure contours fins, surfaces réfléchissantes, ombres, source mal cadrée et détails d’identité. L’égalité de quelques pixels retenus n’est pas une validation suffisante du produit entier.

8. Vérification, mesures et critères de livraison

Types de preuves

• Tests unitaires sur transitions, déduplication, sélection de capacités, application des corrections et policy.
• Tests d’intégration avec Postgres et le dispatcher : transactions, contention, outbox, leases et redémarrages.
• Tests de contrat d’adaptateurs : outil, MCP, package, calendrier, Shopify, Sandbox, événements et artifacts.
• E2E navigateur sur chat/canvas/WorkTree/preview, incluant fermeture/réouverture et états arrivant pendant le montage.
• Evals sur demandes multi-métiers, choix de capacités, vérification et mémoire ; modèle/version, jeux d’entrée et coût consignés.
• Recette live limitée aux comptes et stores de test explicitement configurés, avec résultats externes relus.
• Tests de charge et de panne sur le socle durable. Les contrôles portant seulement sur des chaînes de code ne remplacent aucun de ces parcours.

Cibles initiales à mesurer, pas performances déjà obtenues

Ces seuils sont des critères de validation de cette livraison, pas une promesse de disponibilité absolue de services tiers. Le lot P00 précise matériel, charge, taille de données et modalités de mesure ; toute modification ultérieure d’un seuil est justifiée et visible.

Gates du dépôt

Exécuter les gardes rapides prescrits, puis fleet:scope, lint, typecheck, tests et evals concernés. Ajouter build pour les changements de routes et de frontières client/serveur ; db:guard:check dès que le schéma change. Vérifier les six langues et la documentation de capacités.

Le programme touche plusieurs piliers et des hot files. Déclarer Cross-pillar et Hot-file dans la PR, vérifier les collisions avant modification des fichiers partagés et faire relire les portions correspondantes. La demande explicite d’une PR unique justifie l’intégration commune ; elle ne désactive pas les contrôles.

Les nouveaux modèles suivent le schéma et le guard du dépôt. Les colonnes requises ajoutées à des modèles existants ont un default ou restent optionnelles. Une mutation d’une base partagée nécessite une cible et une portée confirmées avant exécution.

Preuve de fin par lot

Chaque lot coche séparément :

1. Code implémenté et branché au chemin réellement utilisé.
2. Ancienne simulation ou voie concurrente retirée/migrée.
3. Tests comportementaux passés.
4. Trace de run, artifact ou référence externe vérifiable.
5. Coût et risques documentés.
6. UI et reprise après navigation validées.
7. Documentation et scénario de recette mis à jour.

Un lot peut être « code prêt » et « recette non validée ». Ne jamais transformer ces deux états en un unique « done ».

9. Stratégie de PR, rollout et rollback

Une PR, une revue organisée

Étendre #1277 avec ce programme sous un item d’intégration parent. L’item 2716 reste la preuve du premier travail Studio, pas la preuve que tout le programme est terminé. Avant les changements au-delà du plan, synchroniser le backlog d’intégration avec cette portée pour que les outils de suivi ne prétendent pas le contraire.

Organiser les commits par lots et dépendances, avec un index dans la description de PR. Les adaptateurs métiers sont ajoutés après les contrats, sans réécriture générale simultanée.

La description distingue toujours :

• présent sur main ;
• code ajouté sur la branche ;
• vérifié par tests/recette ;
• restant à implémenter ;
• dépendance de compte/service encore non vérifiée.

Migration et activation

1. Ajouter schéma et contrats compatibles ; conserver les anciens enregistrements.
2. Observer la sélection de capacités en mode comparaison sans exécuter deux fois les effets.
3. Activer le nouveau driver pour des tenants de recette, puis des missions contrôlées.
4. Basculer les créations de runs ; terminer les anciens runs avec leur version.
5. Convertir les graphes legacy et raccorder les surfaces au journal.
6. Activer les nouvelles familles de packages et partenaires une fois leur recette terminée.
7. Généraliser quand la matrice passe ; retirer les chemins devenus inutiles après la fenêtre de compatibilité requise.

Un rollback stoppe les nouvelles admissions dans le chemin défaillant. Il préserve les runs, événements et artifacts déjà écrits, termine/réconcilie les actions en vol et permet de reprendre via un worker compatible. Il ne remet pas automatiquement un run durable sur l’ancien handler HTTP.

Conserver les snapshots/fichiers avant mutation. Une compensation métier n’est pas nécessairement possible : dans ce cas l’interface montre l’effet effectué et la prochaine action disponible, sans prétendre l’avoir annulé.

10. Dépendances à fermer pendant P00

Ce sont des tâches du plan, pas des demandes de permission pour commencer sa rédaction.

11. Documentation officielle et recalibrage technique

Lecture effectuée pendant cet audit. Les extraits d’API sont vérifiés contre le tag ai@6.0.285, cohérent avec la version déclarée dans le dépôt ; le lockfile reste la source de la version effectivement installée.

• AI SDK 6 : contrôle de boucle : prepareStep et activeTools permettent la sélection par étape. Cette mécanique ne fournit pas à elle seule la persistance d’un run.
• AI SDK 6 : approbation des outils : needsApproval, addToolApprovalResponse et continuation automatique. Le contrôle d’accès reste à appliquer côté serveur.
• AI SDK 6 : reprise de stream : différencier déconnexion et arrêt explicite, avec persistance et commande serveur.
• WorkflowAgent, documentation actuelle : évolution de l’API à examiner dans P00, pas un remplacement supposé compatible avec le dépôt.
• Vercel Workflows : exécution avec reprise, attentes et événements persistants. Le choix du provider ne supprime pas l’idempotence métier ni le contrat produit.
• Vercel Sandbox et snapshots : environnement isolé pour code, fichiers et previews. Valider le cycle de persistance avec la version retenue.

Le canvas v2 provient déjà d’un prototype v0 ; son README indique exactement ce qui a été porté et ce qui reste simulé. S’appuyer sur ce code et ses contrats plutôt que présumer que l’intégration de v0 apporte automatiquement un moteur de production.

12. Décision de livraison

Le projet part d’une plateforme riche. La priorité est de relier ses capacités à une exécution commune, persistante et vérifiable, puis de fermer chaque parcours utilisateur.

Le résultat demandé est la totalité de la matrice, pas uniquement le Studio ni un document d’architecture. Ce plan constitue la feuille de route de cette livraison dans la PR unique. À la date de rédaction, les cases de recette restent à valider ; aucun taux global d’achèvement de 75 % ou de garantie à 100 % n’est affirmé.