Las pruebas y la evidencia

Probar sigue este orden, y cada pieza se apoya en la anterior:

02 criterios → 06 casos CP-NN → brief «a construir» → pruebas → evidencias/ → 07

Los casos salen de los criterios de aceptación del 02, nunca del código: una prueba escrita desde lo que el código hace pasa igual cuando el código está mal.

El 06: casos en lenguaje de negocio

06-plan-pruebas.md lo lee el dueño de negocio, así que no lleva jerga. Cada caso CP-NN dice:

Campo	Para qué
Valida	Qué `RF` y `RN` cubre. De acá se cuenta la cobertura, criterio por criterio
Tipo	Quién lo ejecuta: «Funcional / UAT» va al plan del usuario; «Técnico», «API» o «Base de datos» los verifican el desarrollador o la automatización
Prioridad	`P0`–`P3`. No es una etiqueta: es una compuerta
Usuario / rol	Con qué usuario se ejecuta. La E2E corre con el mismo
Navegación	Por dónde llega el usuario a la pantalla

Los pasos llevan datos literales —«escriba REG-2026-014», nunca «un código válido»— y el ejemplo numérico de cada regla de negocio.

Prioridad	Cuándo	Qué provoca
`P0`	Dinero, seguridad, integridad de datos, obligación regulatoria, o algo que ya se rompió antes	En rojo o sin resultado en el 07, frena el Pull Request
`P1`	Recorrido principal o lógica compleja	Con menos del 80 % resuelto, pasa con reservas
`P2` · `P3`	Secundaria · deseable	Se informa

La duda entre P0 y P1 se resuelve con una pregunta: si falla en producción el lunes a las 9, ¿se revierte el despliegue? Marcar todo P0 no hace nada más seguro: hace que la marca deje de significar algo.

El brief: lo que se aprueba antes de escribir

Escribir veinte pruebas es lo caro de la fase, y lo que sale mal sale mal en bloque. Por eso primero va el brief, que siembra pruebas/a-construir-<TICKET>.md:

kb pruebas brief

Abre con lo que invalida todo lo demás si está mal: la plataforma de cada componente, dónde se van a crear los archivos (la carpeta absoluta de cada suite; si la ficha no la declara, el brief dice «PARÁ ACÁ») y cómo se levanta cada componente. Sigue con las unitarias por componente, los roles con su usuario de prueba y una sección transversal de E2E con una fila por condición, cada una con su oráculo del 02. El desarrollador quita, agrega y corrige, y lo aprueba poniendo estado: aprobado y su nombre en aprobado_por:. Después se escribe una prueba por fila, ni una más ni una menos.

Cómo salen las condiciones y qué trae el kit de Playwright está en Las pruebas de fábrica.

`kb pruebas` y las evidencias

kb pruebas corre los comandos que declara la ficha de cada componente y guarda cada salida con el nombre que busca el PR. Corre solo lo que se exige: --todo corre todo lo declarado y --faltantes saltea lo que ya tiene evidencia en verde posterior al último cambio del repositorio. Cada archivo lleva en su primera línea qué comando corrió y con qué código salió, y su huella queda en el rastro: una corrida en rojo no cuenta, y un archivo escrito a mano tampoco.

Código	Evidencia	Quién la produce
`E01` · `E02` · `E03`	Compilación · lint o analizador · unitarias con cobertura	`kb pruebas`
`E04`	E2E: la salida, una captura por caso y el reporte	`kb pruebas`
`E05`	La pantalla funcionando, o la API respondiendo	una persona (captura) · `kb pruebas --solo api`
`E06`	Scripts de base de datos, ida y vuelta	`kb pruebas --solo bd`
`E07`	Validador de código corporativo	quien lo corrió: la salida tal cual
`E08` · `E09`	La revisión automática del PR · la revisión especializada	`/kb-pr` · `/kb-revisar`
`E10`	Dependencias vulnerables	`kb revisar`, si la ficha la exige

Qué exige cada componente lo dice su ficha, en la fila evidencias (kb apps editar OPS-WEB --evidencias "E01, E03, E04"), y, mientras la ficha no lo diga, la tabla por tipo de aplicaciones/PULL-REQUEST.md: a un frontend se le piden de E01 a E05; a un proyecto de base de datos, E06. kb hoja dice qué falta, por repositorio, antes de abrir el PR.

El 07: tres partes, dos momentos

07-resultados-pruebas.md separa lo que prueba el desarrollador antes del PR de lo que valida el usuario después.

§1 · Cada sistema y cada paso

La escribe kb pruebas resultados, que kb pruebas corre solo al terminar: el veredicto de cada paso con su archivo y la cola del log de lo que quedó en rojo. No se edita a mano; lo único manual, «Correcciones durante la corrida», se conserva al regenerarla.

§2 · Cada caso, antes del Pull Request

Una fila por cada caso del 06, con la columna «Cómo»:

Cómo	Qué significa
`E2E`	Lo cubre una prueba automática: su resultado y su captura, ligada como imagen. El caso sale del título de la prueba (`CP04_…`), de una anotación `CP`, o de su condición cuando la valida un solo caso del 06 — el brief dice cuál le toca a cada una
`manual`	Lo verificaste vos antes del PR, con una captura `E05-pantalla-<caso>.png` (por ejemplo `E05-pantalla-cp02.png`), que en el PR va junto a su caso. Se conserva al regenerar
`UAT`	Se deja para el usuario, con el motivo en Observaciones. Un P0 no: la UAT llega después del PR aprobado y un P0 sin resultado frena el PR — `kb pruebas resultados` lo avisa
`—`	Todavía no: no cuenta como probado y no se lee como duda

Una §2 de las de antes («Pruebas funcionales del desarrollador») se convierte sola; una que el equipo personalizó no se toca. No marques lo pendiente con ❓: ❓ es duda, tapa el verde de la E2E del mismo caso y, en un P0, frena el PR igual que un rojo.

§3 · La validación del usuario

Llega después de kb pr aprobado, con el cambio en staging: kb plan-uat arma la app que ejecuta el usuario y kb uat importar vuelca lo que devuelve. Un visto bueno sin quién lo dio no cuenta; un ❌ sin nombre, sí: sigue siendo un defecto que alguien vio. El recorrido, con las rondas de corrección, está en La UAT y las rondas.

El peor resultado manda

kb pruebas revisar     # PASA · CON RESERVAS · FALLA, sin gastar un token

Cruza el 06, el 07, las evidencias, el linter de las E2E y el brief. Lee la §2 y la §3 juntas, y el peor resultado manda: si la automática pasó y el usuario lo reprobó, el caso está en rojo. Al revés sería entregar un defecto porque una de las pruebas lo dejó pasar. Un — no está resuelto, un ❓ tampoco, y un caso que el runner salteó (⏭) es un caso sin resultado. Cuenta además la cobertura por criterio —un requisito de cuatro criterios con un solo caso no está cubierto— y avisa de las pruebas en fixme o skip sin motivo y de un brief sin aprobar. Sale con 0, 1 o 2 para un pipeline, y lo que dice «Frena» es exactamente lo que kb pr va a rechazar después: enterarse acá cuesta una corrección; allá, una vuelta entera.