---
name: investigar-cliente
description: Método del agente Investigador (equipo v6 del Generador EVOLink). Estudia al cliente y su nicho, vuelca la web actual si existe, y busca y extrae referencias de diseño por su cuenta hasta dejar una cola de candidatas con ficha de veto rápido. Úsala al arrancar /generar, antes de la dirección de arte. Triggers: "investiga este cliente", "busca referencias para", "estudia el nicho de".
---

# investigar-cliente — método del Investigador

Primer paso del flujo `/generar` (v6). Sustituye la elección manual de URLs por búsqueda y extracción autónoma, con una red de seguridad: gate de admisión automático + **veto humano rápido** (spec v6 §2.2). Determinista primero (gate, ficha), juicio del modelo solo en qué buscar y qué encaja.

## 1. Entrada

- `clientes/<id>/brief.md` (del Auditor): sector, zona, público, tono, gaps.
- `docs/bloques/3-generador/referencias/indice-referencias.md`: inventario ya admitido (no se re-busca lo que ya está).
- URL de la web actual del cliente, si el brief la trae.

## 2. Paso 1 — Volcado de la web actual (si existe)

Si el brief trae una URL de la web actual del cliente:
1. `playwright-cli` captura pantallas (móvil + escritorio) y navega las páginas principales. Patrón: reconocimiento antes de acción — navegar, capturar/inspeccionar, y solo entonces registrar evidencia (nunca actuar a ciegas).
2. `extract-design-system` sobre esa URL → paleta/tipografía real ya en uso (aunque sea floja, informa qué NO repetir).
3. Lista qué fotos, textos y datos son reutilizables (trabajos reales, logo, teléfono, zona).

Salida: `clientes/<id>/web-actual.md` (paleta detectada, fotos reutilizables con ruta/URL, textos reutilizables, veredicto de qué se aprovecha).

Si NO hay web actual: escribe `clientes/<id>/web-actual.md` con una sola línea: "Sin web previa — sin activos reutilizables."

## 3. Paso 2 — Estudio de nicho y competencia

Identifica 2-3 negocios del mismo sector y zona (o sector similar si la zona es muy local) con web activa. Por cada uno, anota en 2-3 líneas: qué hace bien, qué hace mal, qué elemento es portable (nunca clonar). No se guardan como referencias de diseño salvo que también pasen el gate del paso 4.

## 4. Paso 3 — Búsqueda y extracción autónoma de referencias

Reutiliza la tabla de perfiles EVOLink (`director-arte §3`) para saber qué perfil aplica al cliente y qué fuentes prioriza ese perfil (despensa > Awwwards > lapa.ninja > Dribbble, `director-arte §5`). Para cada candidata nueva que no esté ya en `indice-referencias.md`:
1. `extract-design-system <url>` → tokens reales.
2. `seo-audit` ligero (o revisión de Lighthouse básica) para descartar páginas pesadas que no sirven de idioma portable.
3. Aplica el gate de admisión (§5 abajo).

## 5. Gate de admisión automático (determinista, pre-filtro — mismo criterio que `indice-referencias.md`)

Entra a la cola de candidatas solo si: (a) web real en producción · (b) sistema coherente (escala tipográfica, ritmo, paleta 3-5 colores) · (c) pasa el detector anti-slop (`impeccable`) · (d) ≥1 idea portable a sitio rápido · (e) mapea a un perfil EVOLink. Awwwards nominada = buen candidato por defecto, pero "idioma, no peso" si el valor es WebGL pesado.

## 6. Ficha de veto rápido (salida para VETO 1)

Una línea por candidata, formato fijo (la columna Captura es OBLIGATORIA: ruta relativa al repo de la screenshot que el socio abrirá para vetar):

```
| # | Nombre | Nicho/perfil | Qué enseña (rol) | Fuente (URL) | Captura (ruta) |
```

Vuelca a `clientes/<id>/veto-1-referencias.md`, con una línea de cabecera "**Archivos a revisar:**" que apunte a la carpeta `clientes/<id>/screenshots/` y a este mismo archivo. El socio responde con algo como "ok 1, 3, 5"; solo lo admitido se formaliza en `indice-referencias.md` (vía `añadir-referencia`), nunca antes. Guarda TAMBIÉN capturas de los competidores estudiados (paso 2) en `screenshots/` — el socio puede promover cualquiera de ellas a candidata durante el veto.

## 7. Salida

- `clientes/<id>/investigacion.md`: resumen de cliente + nicho + competencia (2-4 líneas de síntesis para el director de arte).
- `clientes/<id>/web-actual.md`: activos reutilizables (o "sin web previa").
- `clientes/<id>/veto-1-referencias.md`: cola de candidatas para VETO 1.

## 8. Reglas duras

- Nunca decides dirección de arte, diales ni motion (es `director-arte`).
- Nunca generas HTML (es `constructor`).
- Nunca añades una referencia al índice definitivo sin que pase VETO 1.
- Cero herramientas de pago; cero instalación global (el proyecto usa `playwright-cli` ya disponible, nunca un CLI nuevo instalado a nivel de sistema).

## 9. Fuente y créditos

Plantilla `agent-browser` (vercel-labs) escaneada en un directorio temporal fuera del repo (nunca importada). **Adoptado:** el patrón de reconocimiento-antes-de-acción (navegar → inspeccionar/capturar → recién entonces registrar evidencia) y la idea de checkpoint explícito antes de una acción con coste (admitir una referencia = VETO 1). **Descartado:** el CLI en sí (`agent-browser` exige `npm install -g` — instalación global que el proyecto prohíbe) y toda su capa de automatización de apps de escritorio/Slack/nubes, irrelevante aquí; se usa `playwright-cli`, ya adoptado por el proyecto.

> Cross-links: `director-arte` (perfiles y roles de referencia), `indice-referencias.md` (gate + inventario definitivo), `añadir-referencia` (formalización tras VETO 1).