# demo-branding-auditor

**Familia**: B · Construcción
**Spec**: [`/.claude/agents/demo-branding-auditor.md`](../../.claude/agents/demo-branding-auditor.md)

## Cuándo invocarlo

- Un demo se ve mal con branding custom (tenant no ve sus colores/logo/fonts)
- Antes de marcar un demo como production-ready
- Audit periódico post-deploy para detectar drift con baseline F7
- Nuevo demo creado y hay que validar compliance antes de publicarlo
- Vistas de un módulo específico dentro de un demo muestran placeholder o colores del template

## Cuándo NO invocarlo

- Para crear branding desde cero para un tenant → es un input manual (colores + logo)
- Para crear un demo nuevo (comando `demo:create`) → workflow separado
- Para migrar skins legacy → comando `bewpro:migrate-demo-hardcodes`

## Inputs típicos

```
"Auditá `demo-photography-3`"

"Auditá todos los demos validados y emití reporte priorizado"

"Tenant X tiene logo default en vez del suyo"

"Auditá vistas de `products` en `demo-digital-agency-2`"
```

## Output esperado

1. **Scope auditado**
2. **Issues agrupados por severidad**:
   - 🔴 Crítico (visual roto)
   - 🟡 Drift (viola regla sin romper)
   - 🟢 Cosmético
3. **Por cada issue**: archivo:línea, snippet actual, diff propuesto
4. **Resumen**: conteo por severidad + si está production-ready
5. **Comandos sugeridos**: `bewpro:migrate-demo-hardcodes`, `bewpro:skin`

## Archivos que lee

- `resources/views/layout/front/headers/demo-*.blade.php`
- `resources/views/layout/front/footers/demo-*.blade.php`
- `public/template/css/demos/demo-*.css`
- `resources/views/modules/**/demos/demo-*/*.blade.php`
- `app/Services/{SiteConfigService,SkinColorService}.php`
- `app/helpers.php` (helpers de branding)
- `docs/bewpro2.0/branding/{proceso-branding.md, pipeline-provision.md, skin-css.md}`
- `docs/bewpro2.0/product-readiness/estandar-demo.md`

## Archivos que escribe (con confirmación)

- Diffs sobre los archivos auditados (siempre con aprobación por issue o batch explícito)
- Nunca escribe en `_archive/` ni en skins legacy

## Reglas de compliance (tabla)

| Ámbito | Regla |
|--------|-------|
| Blade | No hex hardcoded en `style=""`. Usar `var(--primary)`, etc. |
| Blade | Logos vía `site_asset_url('main_logo')`, NUNCA path directo |
| Blade | OG images vía `brand_og_image()` / `brand_twitter_image()` |
| Blade | Fonts: `var(--font-family-primary)` o `get_theme_font('primary')`, no hardcode |
| CSS demo | Solo CSS variables o aliases semánticos; no hex fijos salvo neutros absolutos |
| CSS demo | `--{color}` se genera desde SkinColorService, no fijo |
| Vistas módulo por demo | Mismo patrón — no introducir drift |

## Checklist de output

- [ ] Cada issue tiene archivo:línea preciso
- [ ] Cada issue tiene diff propuesto ejecutable
- [ ] Severidad asignada siguiendo la tabla
- [ ] Resumen final indica production-ready yes/no
- [ ] No se aplicaron fixes sin confirmación

## Baseline

Commit `0c820976 feat(F7): branding compliance across all demos` es el estado aprobado. Toda auditoría compara contra este baseline.

Skins archivados: `public/template/css/skins/_archive/` — no tocar.

## Relacionado

- Se invoca desde `core-architect` al validar demo de un core nuevo
- Se puede invocar standalone para audit periódico