ADRADR-0029 · BoostEcom opere le growth et le storefront, Shopify garde la logistique commerce

ADR-0029 — BoostEcom opere le growth et le storefront, Shopify garde la logistique commerce

Le cockpit store est structure en quatre modes (Preview · Builder · Workflow · Studio). La tentation, une fois shopifyAdminGraphQL ouvert, est de laisser @Atlas tout faire dans Admin : fulfillment, stocks, refunds…

Statut

Accepté · 2026-09-22

Piliers : ai-platform, integrations, commerce-systems

Contexte

Le cockpit store est structure en quatre modes (Preview · Builder · Workflow · Studio). La tentation, une fois shopifyAdminGraphQL ouvert, est de laisser @Atlas tout faire dans Admin : fulfillment, stocks, refunds, payments, shipping zones, policies. Shopify fait deja ces surfaces correctement. Les reconstruire ou les piloter depuis le chat dilue le produit, augmente le risque (argent / stock / legal) et contredit le positionnement : completer Shopify sur ce qu'il ne fait pas bien (contenu structure, creatifs, automation growth, diagnostic storefront), pas le remplacer.

Décision

BoostEcom est le cockpit d'operation growth et storefront sur Shopify. Shopify Admin reste le systeme de verite pour :

  • commandes (create / edit / cancel / capture / mark paid)
  • fulfillment et tracking
  • niveaux de stock / inventory adjustments
  • paiements et payment terms
  • shipping / delivery profiles
  • returns / refunds operations
  • shop policies comme reglages operationnels

@Atlas et le MCP store peuvent lire ces signaux (Insights, risques stock, anomalies revenus) pour diagnostiquer et aiguiller. Ils ne executent pas ces mutations. Les ecritures autorisees restent le perimetre storefront : theme, contenu catalogue (titres, descriptions, SEO, metafields merchandising), pages, articles, menus, redirects, publications liees au contenu, creatifs Studio, workflows growth.

Les connectors et MCP alimentent les quatre piliers ; ils ne deviennent pas un Admin alternatif.

Alternatives écartées

OptionPourquoi non
Laisser shopifyAdminGraphQL tout muter avec approbation humaineL'approbation ne change pas le produit : on devient un Admin parallele, plus lent.
Ajouter un 5e mode Orders / InventoryContredit le framing a quatre piliers et duplique Shopify.
Interdire aussi les lectures orders / inventoryCasse Insights, Systems et le diagnostic. La lecture est du carburant, pas de l'operation.
Interdire productUpdate entierementproductUpdate porte le merchandising et le SEO, coeur Builder / growth.

Conséquences

  • Un marchand qui demande « rembourse cette commande » est renvoye vers Shopify Admin, avec un diagnostic si besoin.
  • Le wizard peut toujours rediger des pages de politique (contenu) ; ce n'est pas l'API de reglages shop policies.
  • Elargir la regex d'interdiction est le reflexe par defaut quand un nouveau champ GraphQL logistique apparait.

Comment c'est appliqué

  • Predicat unique : src/features/ai/agents/shopify-ops-boundary.ts
  • Refuse hard dans shopify-admin.ts (chat) et register-tools.ts (MCP)
  • Kernel @Atlas : section « Territoire Shopify Admin »
  • Fragments orchestrator : handler-prompt-fragments.ts (plus de « ne gate rien »)
  • OAuth : scopes write_orders / write_fulfillments / write_inventory / write_shipping absents de oauth-scopes.ts (lectures seules)
  • Client MCP Shopify : createFulfillment / cancelFulfillment stubbes
  • Garde : src/test/shopify-ops-boundary.test.ts
Was this page helpful?