Auditoria Profunda

Auditoría profunda — El auditor quisquilloso

> "La app compila, los tests pasan, la validación visual aprueba todos los flujos. Aun así, el usuario configura 50% de comisión en Ajustes, y el motor sigue calculando 30% porque el valor está hardcodeado en el código. Eso es lo que esta skill caza."

Mientras validacion-visual pregunta "¿la app funciona?", ésta pregunta "¿la app respeta lo que el usuario le dice?". Es la diferencia entre un botón que abre un modal (visible) y una configuración que se guarda pero nunca se aplica (invisible, y la que hace que un cliente pierda la confianza).

---

Las 5 dimensiones

D1 — Coherencia configuración ↔ comportamiento

¿Cuando el usuario cambia un ajuste, ese cambio realmente afecta la feature que depende de él?

Método (A/B sistemático): por cada configuración detectada — capturar el valor actual → cambiarlo → ejecutar la feature que debería leerlo → comparar el resultado → si NO cambió cuando debía cambiar, es un bug (valor hardcodeado o config ignorada) → restaurar el valor original.

Hallazgos típicos: "tarifa por km configurable, pero el motor usa un valor fijo en el código"; "toggle 'enviar email' configurable, pero el flag se ignora en la acción del servidor".

D2 — Persistencia

¿Lo que el usuario guarda sigue ahí tras refrescar, cerrar sesión, volver a entrar, o abrir en otro dispositivo?

Método: guardar → ver el mensaje de éxito → refrescar y verificar → cerrar sesión y volver a entrar y verificar → confirmar con una query directa a la base que el dato realmente llegó. El bug clásico: la UI dice "guardado" pero la acción del servidor nunca hizo el UPDATE.

D3 — Permisos / RLS

¿Un usuario solo ve y edita lo suyo, sin filtrarse a datos de otros?

Método (dos usuarios A y B): A crea un recurso → capturar su ID → entrar como B → intentar acceder por URL directa al recurso de A (no debería verse) → intentar modificarlo/borrarlo → confirmar que los listados de B no muestran nada de A. Si la app es multi-tenant, cruzar tenants. El bug clásico: la API no valida ownership en el servidor — basta pegar la URL.

D4 — Casos extremos

¿La app maneja los límites del rango, o se rompe / produce resultados absurdos?

• Numéricos: 0, negativos, decimales minúsculos, valores enormes, NaN/Infinity.
• Texto: vacío, solo espacios, emojis y acentos (ñ, Á), comillas/backticks, cadenas de 10.000 caracteres.
• Fechas: pasadas/futuras extremas, fecha imposible (31 de febrero), choques de zona horaria.
• Combinaciones imposibles: fecha fin < fecha inicio, descuento de 150%, tarifa 0 en campo obligatorio.

Hallazgos típicos: "tarifa 0 → división por cero → pantalla blanca"; "descuento 150% → totales negativos aceptados"; "fecha de 1900 → métricas en NaN".

D5 — Coherencia dashboard ↔ base de datos

¿Lo que muestra la UI coincide con lo que realmente hay en la base?

Método: por cada KPI/contador/listado, leer el número de la UI y compararlo con una query directa (SELECT count(*), SELECT sum(...) con los filtros equivalentes). Si no coinciden, es un bug (caché desactualizado, agregación incorrecta, o filtro distinto entre la UI y la base).

---

El flujo

1. Detectar el alcance: la app completa, o lo que el usuario indique. Si no está claro, preguntar — nunca asumir.
2. Setup (si hay auth): usuario QA primario + un segundo usuario para las pruebas de permisos (D3). Borrar al final.
3. Recorrer las 5 dimensiones con navegador real + queries directas a la base para contrastar UI contra datos.
4. Loop bug-arreglo-revalidación: diagnosticar la causa raíz (no parchar), arreglar, re-validar. Pausar y preguntar si el bug exige una decisión de arquitectura, toca datos reales de producción, o se sale del alcance.
5. Limpieza OBLIGATORIA: todo registro de prueba borrado, toda configuración tocada restaurada a su valor original, la base idéntica al estado previo.
6. Reporte + autorización. El push/deploy final SIEMPRE lo autoriza el dueño.

---

Reglas duras

1. Caza coherencia, no solo funcionamiento — el valor hardcodeado que ignora la config es el bug estrella.
2. Contrastar SIEMPRE la UI contra la base de datos real, no confiar en lo que dice la pantalla.
3. Loop bug-arreglo-revalidación hasta que una pasada salga limpia.
4. Restaurar toda configuración tocada durante el A/B testing — la base queda idéntica.
5. Pausar por decisión de arquitectura / datos reales / fuera de alcance, no por dificultad.
6. El push/deploy lo autoriza el dueño.

---

Anti-patrones (prohibidos)

• "El botón guarda y muestra éxito, listo." → Falta confirmar que el dato llegó a la base Y que se aplica.
• "Probé con valores normales." → Los bugs viven en los extremos (0, negativos, vacío, fechas imposibles).
• "El dashboard muestra un número, le creo." → Contrastarlo con la base; el caché miente.
• "Cambié la config para probar y la dejé así." → Restaurar siempre el valor original.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: LalakinSkywalker
• Source: LalakinSkywalker/bluntag-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.