# core-architect

**Familia**: A · Producto y Marketplace
**Spec**: [`/.claude/agents/core-architect.md`](../../.claude/agents/core-architect.md)

## Cuándo invocarlo

- Un shop product no encaja en ningún core existente → necesitás un preset nuevo
- Hay que ajustar un core existente (agregar/quitar módulo, cambiar demo, retocar schema)
- Auditar un core para validar que cumple estándar actual (`bewpro2.0/product-readiness/estandar-demo.md`)
- Diseñar un bundle técnico premium (más módulos, demo más visual)

## Cuándo NO invocarlo

- Para empaquetar una variante comercial sobre un core existente → `product-packager`
- Para crear un demo visual desde cero → proceso `demo:create` + doc `guia-nuevo-demo.md`
- Para crear un módulo funcional nuevo → `module-scaffolder`

## Inputs típicos

```
"Diseñá un core preset para podcasters profesionales"

"Ajustá el core `agency` para agregar módulo `testimonials`"

"Necesito un core para estudios de arquitectura sustentable con galería de proyectos y blog de materiales"

"Auditá `bp-dinamic` — ¿cumple el estándar actual?"
```

## Output esperado

1. **Análisis de reuso** — ¿hay un core existente que ya lo resuelva?
2. **JSON del core** (si amerita nuevo) siguiendo estructura canónica
3. **Justificación** de cada decisión (demo, módulos, schema, paleta)
4. **Validación** (demo existe, módulos registrados, logo_pack existe)
5. **Next steps** (invocar `content-seeder`, `demo-branding-auditor`, correr `bewpro:sync-brand-defaults`)

## Archivos que lee

- `database/seeders/products/core/*.json` (los 21 existentes)
- `database/seeders/products/core/seeds/*.json` (patrón de seeds)
- `config/demos.php`, `config/cd-system.php`
- `app/Services/SkinColorService.php`
- `docs/bewpro2.0/product-readiness/{estandar-demo.md, estado-productos.md}`
- `docs/bewpro2.0/arquitectura-tecnica-cms.md`

## Archivos que escribe (con confirmación)

- `database/seeders/products/core/{slug}.json` (nuevo)
- `database/seeders/products/alias-matrix.json` (si hay combos módulo×industria nuevos)

## Estructura canónica de un core JSON

```json
{
  "core_slug": "...",
  "demo": "demo-xxx",
  "skin": "auto | light | dark",
  "modules": ["services", "faqs", ...],
  "modules_navigation": { "services": { "header": true, "footer": true }, ... },
  "fonts": { "primary": "...", "secondary": "...", "tertiary": "..." },
  "schema_type": "ProfessionalService | RealEstateAgent | Restaurant | Person | ...",
  "brand_defaults": {
    "colors": { "primary": "...", "secondary": "...", "tertiary": "...", "quaternary": "...", "dark": "...", "light": "..." },
    "logo_pack": "..."
  },
  "header": { "cta_button": { "label": "...", "url_type": "module | url | anchor", "url_value": "..." } }
}
```

## Checklist de validación del output

- [ ] Demo referenciado existe en `config/demos.php`
- [ ] Cada módulo de `modules[]` está registrado en `config/cd-system.php`
- [ ] `schema_type` es un tipo válido de schema.org
- [ ] Paleta tiene los 6 colores canónicos (primary, secondary, tertiary, quaternary, dark, light)
- [ ] `logo_pack` existe en `public/cd-project/img/logos/` o es un pack nuevo documentado
- [ ] `modules_navigation` tiene entrada para cada módulo activo
- [ ] `cta_button.url_type` coincide con url_value (ej: si es `module`, url_value es un slug de módulo)

## Flujo típico

1. Usuario: "Core para podcasters"
2. Agente busca reuso en los 21 cores → `personal-brand` cubre 70%, pero falta testimonials+references
3. Agente propone nuevo core `podcaster-pro` extendiendo personal-brand
4. Agente emite JSON + justificación
5. Usuario confirma → agente escribe `core/podcaster-pro.json`
6. Agente sugiere invocar `content-seeder` para seeds y `demo-branding-auditor` para el demo

## Relacionado

- Delega a `content-seeder` para generar seeds iniciales
- Delega a `demo-branding-auditor` para validar el demo
- Es invocado por `product-packager` cuando ningún core existente matchea