La cadena mínima de verificación antes de publicar

Por qué esto importa

Cuando Codex cambia código, conviene pedirle que cierre el trabajo con evidencia. Esa evidencia puede ser un test, un typecheck, un build o una revisión visual. Cada una cubre un riesgo diferente.

Piénsalo como revisar un documento antes de enviarlo: primero miras errores básicos, luego revisas que el contenido diga lo correcto, después confirmas que abre bien y al final lo miras como lo verá otra persona.

La cadena en simple

1. Typecheck

   Revisa que TypeScript entienda el código. Detecta, por ejemplo, campos que no existen, valores nulos mal usados o funciones llamadas con parámetros incorrectos.

2. Tests unitarios

   Ejecutan casos pequeños y repetibles. Sirven para comprobar reglas de negocio, servicios, guards, stores o utilidades sin abrir la app completa.

3. Build

   Confirma que Angular puede empaquetar la aplicación. Un build puede fallar aunque los tests pasen, por ejemplo por problemas de SSR, budgets o imports.

4. E2E o revisión en navegador

   Abre la app como usuario. Sirve para comprobar navegación, llamadas a servicios, estados finales, errores de consola y problemas visuales que los tests unitarios no ven.

Comandos típicos

npm pkg get scripts

# Si el repo los tiene:
npm run typecheck
npm run test:ci
npm run build

# Cuando el cambio afecta una pantalla o flujo:
npm run start

Por qué npm run start importa en el flujo

`npm run start` suele ejecutar el servidor de desarrollo del proyecto. En Angular, ese servidor compila y sirve la aplicación, y vuelve a compilar cuando cambian archivos. Eso lo vuelve clave cuando el cambio toca pantallas, rutas, formularios, estados visuales o navegación. El build dice “la app se puede empaquetar”; start permite comprobar “la app se puede usar”.

En la práctica, este comando abre la puerta a la revisión de flujo: Codex puede inspeccionar la ruta local, Playwright puede navegarla, y el equipo puede confirmar que las acciones llaman a los servicios esperados, que la pantalla cambia de estado y que no hay textos cortados, errores de consola, enlaces rotos o problemas en mobile.

Dónde entra Playwright

Playwright entra cuando necesitamos comprobar la aplicación en un navegador real. No reemplaza al typecheck, los tests unitarios ni el build: los complementa. Su valor está en validar que un flujo completo funcione: la persona hace una acción, la app llama a los servicios correctos, el backend responde, el estado cambia y la UI lo muestra bien.

1. Cuando cambia un flujo completo

   Si tocamos login, catálogo, checkout, creación de entidades, permisos o tenants, vale la pena recorrer la acción completa como usuario y validar el resultado.

2. Cuando importan los servicios

   Playwright puede esperar respuestas de red y confirmar que una acción disparó el endpoint correcto, con el estado esperado y sin errores visibles.

3. Cuando importa responsive

   Playwright permite revisar desktop y mobile. Esto ayuda a detectar problemas de spacing, textos largos, botones fuera de pantalla o navegación incómoda.

4. Cuando queremos evidencia visual

   Una captura o snapshot deja registro del resultado. Sirve para comparar antes/después y para explicar por qué el cambio está listo.

5. Cuando validamos producción

   En rutas públicas o SSR, la revisión debe incluir refresh directo, HTML renderizado y assets JS/CSS respondiendo correctamente.

Abre la ruta real en navegador con Playwright.
Ejecuta el flujo como usuario.
Revisa que la acción llame al servicio esperado y que la respuesta sea correcta.
Valida el estado final en la UI, desktop y mobile.
Busca textos cortados, elementos superpuestos, errores de consola y problemas de navegación.
Si detectas algo, dime el archivo probable antes de editar.
Al final resume qué viste y qué evidencia queda.

Cómo nos ayuda la IA Codex en nuestros proyectos

En todos nuestros proyectos, por ejemplo en el help center y en el backoffice, Codex nos ayuda a revisar código real antes de publicarlo. No reemplaza la revisión humana: acelera la lectura del proyecto, propone cambios pequeños y deja evidencia con typecheck, tests, build o revisión visual.

1. Prompt 1: auditar antes de cambiar

   En `neges-backffice`, pídele a Codex que revise el feature antes de tocar código. Para un caso real, puede mirar `src/app/features/products/`, `src/app/shared/ui/`, servicios, stores y specs existentes.

Audita este feature antes de cambiarlo.
Identifica patrones de rutas, componentes, servicios, stores, estilos y tests.
Usa como referencia los archivos existentes de products, shared/ui, core/auth y core/tenant.
No implementes todavía: primero dime qué patrón seguirías y qué riesgo conviene verificar.

1. Prompt 2: pedir un cambio reversible

   Después pide un cambio pequeño, por ejemplo ajustar un texto de validación en `src/app/features/products/products.form.ts` y revisar si corresponde actualizar `products.form.spec.ts`. Al ser un cambio acotado, se puede volver atrás sin mezclarlo con otras tareas.

Haz un cambio pequeño y reversible en el copy de validación de productos.
Revisa src/app/features/products/products.form.ts y su spec.
Muestra el diff de los archivos modificados.
Después ejecuta npm run typecheck y dime si también corresponde correr npm run test:ci.
Si esto era solo para mostrar el flujo, revierte únicamente los archivos que acabas de tocar.

1. Mostrar exactamente dónde cambió

   Antes de hablar del resultado, muestra el diff. Así la conversación se mantiene concreta: qué archivo cambió, por qué cambió y qué comportamiento cubre.

git diff -- src/app/features/products/products.form.ts src/app/features/products/products.form.spec.ts

1. Cerrar con evidencia

   Ejecuta `npm run typecheck`. Si el cambio toca reglas o servicios, suma `npm run test:ci`. Si toca publicación o SSR, cierra con `npm run build:prod` o revisión en navegador.

npm run typecheck
npm run test:ci
npm run build:prod

Cómo decidir cuánto verificar

No todos los cambios necesitan la misma profundidad. Cambiar un texto puede requerir build. Cambiar auth, tenants o checkout merece tests y revisión en navegador.

Recursos relacionados