Luijaa/web-template

Pre-PR check

Realiza todos los puntos e informa en una tabla de aprobado/reprobado con evidencia (comandos y resumen de resultados).

1. make check debe pasar completamente (docs-check, lint + SAST, test, build, license) — excepto en estos 2 casos:

   • PR solo de documentación (docs(design): …, ADR, docs): basta con que make docs-check pase.
   • Repositorio que aún no ha elegido stack (el target imprime not configured — ADR-0001 aún no aceptado): ese target se reporta como N/A (aún no configurado), no se considera aprobado ni es motivo para detener el proceso — está prohibido modificar la receta para que haga exit 0 y así forzar la aprobación.

   Además, ejecutar make e2e si se cambia algo que el usuario ve (agregar/modificar e2e al respecto) y make dast si se modifica middleware, encabezados, cookies, páginas de error o rutas nuevas.

2. git diff origin/main...HEAD --stat — verificar que solo se tocan archivos relacionados con la tarea. No debe haber archivos no deseados (salidas de compilación, .env, archivos personales).

3. Logs temporales olvidados: git diff origin/main...HEAD | grep -n '\[DBG-' no debe encontrar coincidencias (fix-bug punto 3).

4. Buscar secretos en el diff: git diff origin/main...HEAD | grep -nEi '(api[_-]?key|secret|token|password|BEGIN .*PRIVATE KEY)' — si se encuentra, detener y notificar.

5. Las nuevas variables de entorno deben estar incluidas en .env.example.

6. Dependencias agregadas/actualizadas (revisar diff de lockfile, go.mod, Dockerfile FROM): la versión y la licencia deben coincidir con docs/dependencies.md y deben mencionarse en la descripción del PR.

7. Migraciones nuevas (si las hay): deben poder ejecutarse y revertirse.

8. Documentación: actualizar README, docs, ADR (docs/adr/) según los cambios; los nuevos términos del dominio deben estar en CONTEXT.md y los nombres en el código deben coincidir con CONTEXT.md.

9. Revisar según el skill review (Claude Code: subagente reviewer; otros agentes: leer .agents/skills/review/SKILL.md y auto-revisar el diff) y corregir los elementos marcados como "debe corregirse" antes de continuar.

10. El mensaje de commit debe seguir Conventional Commits y la rama no debe ser main.

11. La descripción del PR debe incluir Closes #<issue> (si no hay issue, crear uno primero) y un encabezado ## CHANGELOG (categoría + 1 línea en tailandés desde la perspectiva del usuario, o -) — no modificar CHANGELOG.md directamente (docs/release.md).

12. Si se toca la interfaz de usuario: no debe haber texto hardcodeado, las claves de traducción deben estar completas en todos los idiomas, no deben usarse valores de color directos, y debe verse correctamente en modo th/en × claro/oscuro (docs/ui.md).

Si algún punto no pasa, no se debe abrir el PR; hay que corregirlo primero o reportar qué impide continuar.