27 comprobaciones · la definición de terminado de la guía, en público
La barra de calidad
Qué significa «terminado» para todo lo que publicas. Cada comprobación explica por qué importa, cómo comprobarla y qué pedirle a tu agente.
Revisión antes de publicar: copia para tu agente
Antes de fusionar, revisa el proyecto con la barra de calidad de Agentic Makers: Funciona · Segura · Gestiona errores · Rápida · Accesible y adaptable · Privada · Fácil de encontrar. Indica para cada punto si pasa o no, con palabras sencillas y cómo lo comprobaste, y propón un arreglo para lo que falle. No fusiones hasta que yo lo diga.
01 Funciona
Probada en local y en la vista previa
Por qué: Si no la has recorrido tú, nadie lo ha hecho.
Cómo comprobarlo: Abre la vista previa en un equipo y en un teléfono y haz lo que haría una persona real.
Dame una lista de lo que debería probar en la vista previa antes de publicar.Lint, tipos y tests pasan
Por qué: Las comprobaciones automáticas detectan errores antes que tus visitantes.
Cómo comprobarlo: Tu agente las ejecuta antes de cada push; la pull request las muestra en verde.
Ejecuta lint, tipos y tests y dime el resultado en una línea cada uno.Coincide con SPEC.md
Por qué: La especificación es la promesa; la app debe cumplirla.
Cómo comprobarlo: Compara cada imprescindible de la especificación con la app.
Compara la app con SPEC.md y haz una lista de lo que falta o sobra.SPEC.md y tasks/todo.md coinciden con lo construido
Por qué: Tu siguiente sesión empieza leyendo estos dos archivos.
Cómo comprobarlo: Las tareas terminadas están marcadas y cualquier cambio de idea figura en SPEC.md.
Actualiza SPEC.md y tasks/todo.md para que coincidan con lo que hemos construido hoy.Commits pequeños en una rama, fusionados mediante pull request
Por qué: main sigue publicada y funcionando en todo momento.
Cómo comprobarlo: Los cambios están en una rama con una pull request y una vista previa funcionando.
Confirma que estamos en una rama con todo guardado en commits y subido con push.02 Segura
Sin secretos en el código, los commits, los logs ni el chat
Por qué: Una clave filtrada permite a cualquiera gastar tu dinero o leer tus datos.
Cómo comprobarlo: Los secretos solo viven en Vercel y en .env.local; .env* está en .gitignore; nada secreto empieza por NEXT_PUBLIC_.
Revisa el código y el historial en busca de algo que parezca un secreto y confirma que los archivos .env se ignoran. No muestres valores.Cada endpoint comprueba quién pregunta y valida la entrada
Por qué: Cada Server Action y Route Handler es una puerta pública.
Cómo comprobarlo: Cada uno comprueba la sesión y los permisos, valida la entrada con un esquema y después toca la base de datos.
Haz una lista de todos los endpoints y confirma que cada uno comprueba la sesión y valida su entrada.Límites de uso en inicios de sesión y llamadas a la IA
Por qué: Sin límites, un script puede adivinar contraseñas o gastar tu crédito de IA.
Cómo comprobarlo: Los endpoints de inicio de sesión y de IA tienen límites guardados en la base de datos.
Comprueba que los endpoints de inicio de sesión y de IA tienen límites de uso y dime cuáles son.Consultas parametrizadas y una rama de base de datos separada para desarrollo
Por qué: Evita la inyección SQL y mantiene las pruebas locales lejos de los datos reales.
Cómo comprobarlo: Las consultas usan parámetros, nunca concatenación de texto, y .env.local apunta a una rama de desarrollo de Neon.
Comprueba que todas las consultas usan parámetros y confirma que en local no usamos la base de datos de producción.Cabeceras de seguridad (CSP) y CORS ajustado
Por qué: Protege el navegador de quien visita tu web frente a scripts inyectados y clickjacking.
Cómo comprobarlo: La configuración de Next.js envía Content-Security-Policy, X-Content-Type-Options y frame-ancestors 'none'.
Revisa nuestras cabeceras de seguridad y confirma que CSP y la protección contra marcos están activas.La salida del modelo y los textos de error se tratan como no confiables
Por qué: Las respuestas de la IA y los logs pueden contener texto inesperado o inyectado.
Cómo comprobarlo: La salida del modelo se valida y escapa antes de mostrarla o usarla; las llamadas a la IA se hacen solo en el servidor.
Confirma que todas las llamadas a la IA se hacen en el servidor con max_completion_tokens y salida validada.03 Gestiona errores
Mensajes amables, nunca trazas de error
Por qué: La gente debe saber qué pasó y qué hacer, sin ruido técnico.
Cómo comprobarlo: Los errores esperados se muestran como mensajes sencillos; los formularios conservan lo escrito.
Provoca cada error esperado (entrada incorrecta, elemento inexistente) y enséñame lo que vería la gente.Límites de error con «Reintentar» y un código de referencia
Por qué: Los errores inesperados ocurren; la página no debería quedarse en blanco.
Cómo comprobarlo: Existen error.tsx por sección principal y global-error.tsx; la gente ve un código de referencia corto.
Comprueba que cada sección principal tiene un límite de error con Reintentar y un código de referencia.Página 404 útil (not-found.tsx) cuando falta un enlace
Por qué: Un enlace roto debe guiar de vuelta, no dejar a nadie perdido.
Cómo comprobarlo: Existe not-found.tsx y enlaza a las secciones principales.
Abre una dirección que no exista en la vista previa y enséñame la página 404.Logs estructurados sin datos personales
Por qué: Los logs explican qué se rompió; nunca deben filtrar secretos ni datos personales.
Cómo comprobarlo: Una línea JSON por evento con nivel, mensaje e id de petición; sin secretos, emails, prompts ni respuestas.
Revisa nuestros logs: una línea JSON por evento y ningún secreto ni dato personal.Alertas de errores antes de que llegue gente real
Por qué: Deberías enterarte de un problema antes de que te lo cuenten.
Cómo comprobarlo: Un sistema de seguimiento de errores (por ejemplo, el plan gratuito de Sentry) te envía una alerta.
Configura el seguimiento de errores con alertas, siguiendo la skill de observabilidad.Respaldo de IA probado
Por qué: Si el proveedor principal de IA no responde, tu función debería seguir respondiendo.
Cómo comprobarlo: En una vista previa, apunta el cliente de Tokentide a una dirección inexistente: Gateway debe responder.
Prueba nuestro respaldo de IA en una vista previa y dime si todas las peticiones tuvieron respuesta.04 Rápida
Buenas Core Web Vitals
Por qué: Las páginas lentas pierden visitas y salen peor en los buscadores.
Cómo comprobarlo: Haz una prueba de Lighthouse en la vista previa, en un teléfono.
Pasa Lighthouse a la vista previa en un teléfono y explícame las tres mejoras más importantes.Imágenes con tamaño y comprimidas
Por qué: Las imágenes enormes son la causa más común de páginas lentas.
Cómo comprobarlo: Las imágenes tienen dimensiones y formatos modernos, para que nada salte al cargar.
Comprueba que cada imagen tiene dimensiones explícitas y un formato moderno.Carga de datos en paralelo y componentes de cliente pequeños
Por qué: Las páginas cargan antes cuando el servidor pide los datos en paralelo y envía menos JavaScript.
Cómo comprobarlo: Las consultas independientes corren en paralelo y solo las partes interactivas usan use client.
Comprueba que nuestras páginas cargan los datos en paralelo y mantienen la lógica fuera de los componentes pequeños.05 Accesible y adaptable
Funciona desde un teléfono pequeño hasta una pantalla grande
Por qué: La mayoría abrirá tu enlace en un teléfono.
Cómo comprobarlo: Sin desplazamiento lateral a 320 px de ancho; zonas táctiles de al menos 44 px.
Revisa la app a 320 px, 768 px y 1440 px de ancho y arregla lo que se rompa.Se puede usar con teclado y con lector de pantalla
Por qué: La accesibilidad es para todo el mundo, y a menudo es obligatoria.
Cómo comprobarlo: Recorre cada control con el tabulador; contraste del texto de al menos 4,5:1; las imágenes tienen texto alternativo.
Pasa una comprobación de accesibilidad (axe) y arregla cada problema grave.Respeta la reducción de movimiento y los temas claro y oscuro
Por qué: Las animaciones y los modos oscuros sin contraste pueden hacer que la app no se pueda usar.
Cómo comprobarlo: Las animaciones respetan prefers-reduced-motion y ambos temas mantienen un contraste de 4,5:1.
Comprueba que se respeta el movimiento reducido y que el contraste cumple en modo claro y oscuro.06 Privada
Solo recoge lo que necesita
Por qué: Los datos que no recoges no se pueden filtrar.
Cómo comprobarlo: Haz una lista de cada dato personal, para qué se necesita y cuánto tiempo se guarda.
Haz una lista de cada dato personal que guarda la app, para qué y durante cuánto tiempo.Sin datos personales en los prompts de IA salvo que hagan falta
Por qué: Lo que entra en un prompt sale de tu app.
Cómo comprobarlo: Los prompts se revisan y los datos personales se ocultan.
Revisa nuestros prompts en busca de datos personales y oculta lo que no haga falta.07 Fácil de encontrar
Título, descripción y un encabezado claro en cada página
Por qué: Los buscadores y los asistentes de IA necesitan saber de qué trata cada página.
Cómo comprobarlo: Cada página tiene un título único, una descripción y un solo H1.
Comprueba que cada página tiene un título único, una meta descripción y un solo H1.Sitemap, robots.txt y noindex en vistas previas configurados
Por qué: Solo tu web publicada en Production debe salir en los buscadores, nunca las vistas previas de prueba.
Cómo comprobarlo: Production sirve sitemap.xml y robots.txt; las vistas previas envían X-Robots-Tag: noindex.
Confirma que nuestro sitemap y robots.txt funcionan y que las vistas previas tienen noindex.