# Proceso: renombrar el core `supplements-shop` → `shop` (core-only)

> **✅ EJECUTADO 2026-06-07** (commit 91971114 + migración DB prod). Verificado: 3 sitios vivos HTTP 200, core/shop.json + 6 seeds, 3 tenants→shop, integridad OK. Backup DB: `/home/bewpro22/rename-shop-backup-*.tsv`. **Pendiente opcional:** sync Airtable (`bewpro:factory:sync`) — SoT ya es la DB.

> Caso real (2026-06-07). El core `supplements-shop` funcionaba ya como tienda genérica
> (3 tenants vivos: Pinturería, Carnicería, Blue Bell — ninguno de suplementos). Se renombra
> el CORE a `shop`; el DEMO `demo-supplements-shop` **NO** se toca (es la capa que mira a los
> sitios vivos). `supplements-shop` pasa a ser una variante shop más bajo el core `shop`.

## Distinción clave
- **CORE** `supplements-shop` (preset, ~10 lugares, platform-only) → se renombra a `shop`.
- **DEMO** `demo-supplements-shop` (visual, ~25 archivos, lo usan los sitios vivos) → **queda igual**.
- Renombrar el core NO toca sitios vivos (el demo es la capa live-facing).

## Checklist de ejecución

### A. Definición (código/JSON)
- [ ] `core/supplements-shop.json` → `core/shop.json` (git mv; adentro `demo` queda `demo-supplements-shop`).
- [ ] 6 seeds `seeds/{blog,config,faqs,gallery,products,testimonials}-supplements-shop.json` → `-shop.json`.
- [ ] `catalog.json`: las 6 variantes (`dietary-supplements-store, natural-health-store, nutrition-store, sports-nutrition-store, supplements-shop, vitamins-supplements-store`) cambian `core: supplements-shop` → `shop`.
- [ ] `config/provision_demo_cores.php`: key del core `supplements-shop` → `shop` (bajo el demo, que no cambia).
- [ ] `DashboardController::MARKETPLACE_CORES`: `'supplements-shop' => 'Tienda de Suplementos'` → `'shop' => 'Shop'`.
- [ ] `CoreTemplateBuilder` (lista MARKETPLACE_CORES): `supplements-shop` → `shop`.
- [ ] `ValidateMarketProducts`: entrada `supplements-shop` → `shop` (name 'Shop', demo sigue `demo-supplements-shop`).

### B. Datos (DB prod)
- [ ] `products`: `UPDATE products SET core_slug='shop' WHERE core_slug='supplements-shop'` (producto `sitio-web-para-tienda`).
- [ ] `tenant_projects`: `UPDATE tenant_projects SET product_name='shop' WHERE product_name='supplements-shop'` (3 tenants vivos — solo tracking, sitio intacto).

### C. Airtable (legacy, baja prioridad)
- [ ] Products(core) + Shop Products → `bewpro:factory:sync` / a mano. SoT ya es la DB.

### D. Verificación
- [ ] `bewpro:integrity:audit` → `shop` válido, 0 product_name inválidos nuevos.
- [ ] Los 3 tenants resuelven core `shop` → demo `demo-supplements-shop` → módulos.
- [ ] `bewpro:validate-market-products` OK.
- [ ] Provisionar de prueba `bewpro:new shop` (o una variante) resuelve bien.

## Lo que NO se toca (y por qué)
- `demo-supplements-shop` y sus ~25 archivos (css, headers/footers, cart/checkout, schema, dynamic-headers): es la capa visual; los sitios vivos la referencian. Renombrar el demo sería un proyecto aparte con impacto en producción.
- `FactorySync` línea `demo-supplements-shop => retail-gastro`: es mapeo de DEMO→industria, no del core.

## Validación de arquitectura (lo que reveló el ejercicio)
Las 5 capas (Sistema→Demo→Módulo→Core→Shop Product) aguantan: se puede renombrar el core sin tocar sitios vivos porque el demo está desacoplado. El rename mejora el acoplamiento de nombres (antes core y demo se llamaban igual).