# Prompt maestro: Dashboard con integridad de datos y ruteo por categoría

 # Prompt maestro: Dashboard con integridad de datos y ruteo por categoría

Plantilla genérica. Sirve para cualquier dominio (bibliográfico, financiero, académico, producto, RRHH, etc.) siempre que el dataset tenga registros de tipos/categorías distintas que no deben mezclarse al calcular métricas.

## ROL

Actúa como analista de datos + diseñador de información + ingeniero frontend. Tu prioridad es la INTEGRIDAD DE LOS DATOS por encima de la estética. Un dashboard bonito sobre datos falsos es peor que no tener dashboard.

## OBJETIVO

Construir un dashboard {{HTML autónomo de un solo archivo | otro formato}} que responda a esta pregunta central:

«{{pregunta o decisión que el dashboard debe ayudar a resolver}}»

El dashboard puede tener **uno o más tracks de análisis** que no se mezclan entre sí. Define cuántos necesitas (mínimo 1, no hay obligación de tener 2):

- **Track {{A}} — {{nombre del grupo con métricas directas/verificables}}:** aplica a registros de tipo {{valor(es) del campo categoría}}. Métricas: {{lista de métricas a calcular}}.

- **Track {{B}} — {{nombre del grupo con métricas provisionales o complementarias}}** *(opcional — omite si tu dataset es homogéneo)*: aplica a registros de tipo {{valor(es) del campo categoría}}. Aporta: {{qué aporta — insumo cualitativo, filtro de calidad, alimentación de una matriz, etc.}}.

Si tu dataset NO tiene categorías que requieran tracks separados, elimina esta subsección y usa solo Fase 1 sin ruteo — no fuerces la estructura de dos tracks donde no aplica.

## PÚBLICO Y USO

- Audiencia: {{quién lo lee}}

- Contexto de uso: {{presentación, reunión de decisión, monitoreo continuo}}

- Nivel de detalle esperado: {{ejecutivo / técnico / mixto}}

## FUENTE DE DATOS

- Archivo(s): {{nombres y formato — CSV, XML, JSON, xlsx, API}}

- Campos disponibles: {{lista o "descúbrelos tú"}}

- Tamaño aproximado: {{n registros totales}}

- Fuente de verdad: {{cuál archivo manda si hay conflicto}}

- **Campo de categoría/tipo** *(solo si usas tracks):* {{nombre exacto del campo — ej. `type`, `category`, `status`}}. Obligatorio para el ruteo de Fase 0. Si no existe en la fuente, DETENTE y repórtalo.

---

## FASE 0 — AUDITORÍA DE CALIDAD + CLASIFICACIÓN Y RUTEO (obligatoria siempre, no solo si hay tracks)

### 0.1 Auditoría de calidad (obligatoria incluso con un solo track o dataset homogéneo)

1. Cuenta registros reales y compáralos contra cualquier cifra que el usuario haya dado (ej. "n registros depurados", "n casos válidos"). Si no coincide, DETENTE y muestra tabla comparativa (declarada vs. encontrada vs. diferencia).

2. Detecta corrupción antes de calcular nada: duplicados, valores en bloque sospechosamente idénticos, campos cuyo contenido no concuerda con su etiqueta (ej. categoría "X" con contenido de otra categoría), placeholders (`N/A`, `TBD`, `0000`, fechas imposibles), registros basura o de prueba.

3. Reporta esta auditoría como tabla, no como prosa: registros afectados, tipo de anomalía, decisión propuesta (excluir / corregir / mantener con advertencia).

4. **No avances a cálculo de métricas si hay corrupción sin resolver.** Pregunta al usuario qué hacer con los registros afectados — no los descartes ni los conserves por tu cuenta.

### 0.2 Clasificación y ruteo (obligatoria solo si definiste más de un track)

5. Cuenta registros reales por valor del campo de categoría. Reporta la distribución completa.

6. **Pregunta bloqueante — no la respondas por tu cuenta:** si la cifra del usuario podría ser (a) un subconjunto filtrado de un dataset mayor ya existente en otro proyecto/versión del usuario, o (b) un dataset independiente, pregúntalo explícitamente. No asumas cuál es.

7. Divide el dataset en listas según el campo de categoría, una por track definido arriba.

8. Reporta cualquier registro con categoría ambigua, nula, o que no calce en ningún track. No lo asignes por defecto — repórtalo aparte.

---

## FASE 1 — CÁLCULO DE MÉTRICAS POR TRACK

### Track {{A}} — métricas directas

Sobre los registros clasificados en este track:

- Para cada métrica en {{lista de métricas}}: define y documenta la fórmula/criterio usado, calculado enteramente desde campos presentes en la fuente.

- Una métrica se presenta como SÓLIDA solo si no requiere ningún dato inferido o supuesto no verificable.

- **No te detengas en el cálculo — interpreta.** Para cada métrica, declara: ¿el valor obtenido es alto, bajo, o esperado respecto a qué referencia (histórico propio, umbral definido por el usuario, distribución del resto del corpus)? Si no hay referencia disponible para comparar, dilo explícitamente — "sin punto de comparación" es una respuesta válida, un número aislado sin interpretación no lo es.

- Identifica outliers **dentro de la métrica misma**, no solo registros corruptos: valores que se alejan del resto de la distribución. Repórtalos aparte con el registro asociado — no los promedies silenciosamente con el resto.

### Track {{B}} — métricas provisionales o complementarias *(si aplica)*

Sobre los registros clasificados en este track:

- Para cada aspecto en {{tabla de aspectos candidatos — completar según dominio}}: documenta explícitamente si es un proxy, qué dato faltante le impide ser directo, y qué se necesitaría para promoverlo a sólido.

- **"Provisional" no es suficiente por sí solo — cuantifica la incertidumbre.** Declara la dirección probable del sesgo (¿el proxy tiende a sobreestimar o subestimar?) y, si es posible, un rango plausible. Si no puedes estimar ni la dirección, dilo explícitamente en vez de dejar la etiqueta "provisional" sin contenido.

- Toda métrica provisional se etiqueta visualmente como tal en el dashboard — no se puede promover a sólida sin confirmación explícita del usuario.

- **No inventes un valor si el campo fuente no lo sostiene.** Se marca "no verificable", no se estima en silencio.

> Plantilla de tabla de aspectos candidatos (llenar por dominio, no dejar genérico):

>

> | Aspecto | Aplica a qué categorías | Qué aporta al análisis |

> |---|---|---|

> | {{aspecto 1}} | {{categorías}} | {{qué resuelve}} |

> | {{aspecto 2}} | {{categorías}} | {{qué resuelve}} |

---

## FASE 2 — VISUALIZACIÓN DE INTERSECCIONES *(opcional, solo si el proyecto lo requiere)*

Si el objetivo central necesita cruzar dos dimensiones (ej. categoría × enfoque, región × producto, equipo × riesgo):

- Conteo real de intersecciones entre {{dimensión 1}} y {{dimensión 2}}.

- Escala de color a definir según densidad esperada: {{ej. verde >X · ámbar Y-X · rojo 1-Y · gris 0}}.

- Declara en el dashboard qué celdas se alimentan de Track A (verificable) y cuáles de Track B (complementario) — para que el lector sepa qué tan sólida es cada celda.

- Aclara explícitamente qué significa una celda vacía o roja: ¿es una oportunidad, un riesgo, una ausencia neutra? No dejes que el lector lo infiera solo.

Si tu proyecto no necesita cruzar dos dimensiones, elimina esta fase.

---

## FASE 3 — DISEÑO DE CONTENIDO Y NARRATIVA

Estructura el dashboard en secciones numeradas: {{lista de secciones deseadas, o "propón tú la estructura óptima"}}. Si hay más de un track, debe quedar visualmente clara la separación entre ellos — sin convertirse en dos dashboards distintos.

Cada visualización:

- Título que diga QUÉ mide y leyenda que explique CÓMO leerla.

- Muestra vacíos y debilidades, no los esconde.

- Se calcula dinámicamente desde los datos embebidos, nunca con cifras hardcodeadas.

Narrativa:

- Voz humana, sin relleno ni frases de plantilla.

- Sección de procedencia/trazabilidad: de dónde vienen los datos, qué se filtró en Fase 0, qué queda provisional o no verificable, y por qué.

- Límites metodológicos declarados, no ocultos — incluyendo cualquier pregunta bloqueante de Fase 0 que siga sin resolver.

---

## FASE 3.5 — SÍNTESIS ANALÍTICA (obligatoria, cierra el círculo con el OBJETIVO)

Antes de pasar a implementación técnica, responde explícitamente — en texto, no solo en gráficos — la pregunta central declarada en OBJETIVO:

1. **Respuesta directa:** con la evidencia de Track A (y Track B si aplica), ¿cuál es la respuesta a «{{pregunta o decisión que el dashboard debe ayudar a resolver}}»? Una frase, sin rodeos.

2. **Nivel de confianza:** ¿esta respuesta se sostiene solo en métricas sólidas, o depende de las provisionales? Dilo explícitamente — no dejes que el lector asuma que todo el dashboard tiene el mismo peso de evidencia.

3. **Qué cambiaría la respuesta:** si las métricas provisionales se resolvieran en la dirección contraria a la esperada, ¿la respuesta de (1) cambia? Si sí, dilo — es información crítica para quien decide con esto.

4. **Qué no responde este dashboard:** limitaciones explícitas de alcance, no solo de dato faltante.

Esta fase es texto de síntesis, no una sección más del dashboard con gráficos — es la sección que le dice al lector "esto es lo que significa todo lo anterior", y va primero en la narrativa (Fase 3), no al final como nota al pie.

---

## FASE 4 — IMPLEMENTACIÓN TÉCNICA

- {{HTML+JS autónomo de un solo archivo | React | otro}}.

- Datos embebidos en el archivo, recalculables al recargar.

- Sin localStorage/sessionStorage si es artefacto.

- Tipografía y paleta: {{preferencia, o "legible y profesional"}}.

- Librería de gráficos: {{Chart.js / D3 / Recharts}}.

- Validar antes de entregar: ejecutar en entorno headless, 0 errores de runtime, los conteos por track renderizan por separado y suman correctamente al total de registros, ninguna cifra vieja queda residual.

---

## FASE 5 — ENTREGA

- Archivo final + resumen de:

  - Cifras canónicas por track/categoría.

  - Qué quedó verificado vs. provisional vs. no verificable.

  - Pendientes que requieren decisión del usuario — empezando por cualquier pregunta bloqueante de Fase 0 sin resolver.

- Decisiones de filtrado o derivación listadas para poder revertirlas.

---

## RESTRICCIONES GENERALES

- No avances de fase si la anterior dejó conflictos sin resolver — no se calculan métricas de Fase 1 sin haber cerrado Fase 0.

- Prefiere preguntar una vez con opciones claras a asumir y rehacer.

- Trazabilidad sobre vistosidad. Verdad incómoda sobre cifra cómoda.

- Antes de usar esta plantilla en un proyecto nuevo: completa TODOS los `{{placeholders}}`. Un placeholder sin llenar en producción es una instrucción ambigua, no una instrucción flexible.