# Artifact de QA — [ID y nombre del cambio]

> Generado en la fase **qa** del ciclo OpenSpec, después de verify y antes de archive.
> Este documento hace tracking de toda la fase. La fase termina solo cuando el usuario confirma explícitamente que todas las pruebas pasaron o que los bugs pendientes tienen disposición documentada.

## Contexto del cambio

- **Ítem del backlog**: [PRJ-XXX]
- **Qué se implementó**: [resumen en 2-3 líneas]
- **Fecha de inicio de QA (Quality Assurance)**:

## Estado de la fase

| | |
|---|---|
| Bloques manuales | |
| Bloques cerrados | |
| Con bugs abiertos | |
| Bugs resueltos | |
| Bugs won't resolve / skipped | |
| **Fase completada** | ☐ No / ☑ Sí — confirmado por el usuario el [fecha] |

> **El protocolo es secuencial y bloqueante:** si el paso 1 falla no se pasa al 2; si el 2 queda en
> rojo, al humano no se le entrega nada. Lo que llega a la persona es el residuo del triaje de QA
> (ver [efficiency.md](../methodology/efficiency.md)), no un volcado mecánico.

---

## Paso 1 — Verificar los datos en la base

> No es "corrí el seed": es confirmar que existe lo que **estas** pruebas necesitan. Es trabajo del
> agente, antes de involucrar a nadie.

- [ ] Base de datos local levantada y app apuntada a ella
- [ ] **Seed cargado** — reproducible y versionado (script de seed), no datos ad-hoc: QA siempre
  parte de un estado conocido
- [ ] **Usuarios de cada bloque** existen, con su rol asignado
- [ ] **Estados a probar representados**: un registro en cada estado del flujo, y el caso vacío
  para las pruebas de estado vacío
- [ ] Casos borde del cambio presentes en los datos

| Qué se verificó | Cómo se consultó | Resultado |
|---|---|---|
| [usuarios y roles del bloque 1] | [query o comando] | ☐ OK |
| [pedidos en estado `pendiente` y `cancelado`] | | ☐ OK |

---

## Paso 2 — Correr lo automatizable y registrar

> API (Application Programming Interface) (status/contrato/payload), estado de BD (base de datos) e
> invariantes, lógica de negocio: cubiertas por la suite de tests, corren en verify y en el CI
> (Continuous Integration). No se listan prueba por prueba — se registra **el comando y su
> resultado**, con fecha. Lo que queda verde acá **no se vuelve a probar a mano**.

| Suite / chequeo | Cubre | Comando | Resultado |
|---|---|---|---|
| [tests de integración de la API X] | [contrato, status, payload] | `[comando]` | ☐ Verde — [fecha] |
| [verificación de BD / invariantes] | [estado tras la operación] | `[comando]` | ☐ Verde — [fecha] |

**Declarado como cubierto** (no entra a los bloques manuales): [lista corta de lo que el humano no
tiene que verificar porque ya está verde arriba].

---

## Paso 3 — Bloques manuales (juicio humano)

> **Un bloque = un rol × un flujo**: lo que una persona prueba de una sentada sin cambiar de
> sesión. Cada bloque es **autocontenido** —se corre sin leer los otros y en cualquier orden, salvo
> dependencia declarada— y registra su propio resultado: QA real ocurre en varias sentadas.
>
> **Credenciales:** el bloque nombra **qué usuario** y **de dónde sale la contraseña** (el script de
> seed, con contraseña de desarrollo válida solo en local). **Nunca se escribe una credencial en
> este archivo**, y nunca credenciales de un entorno real. Si el entorno de QA no es local, se
> referencia el gestor de secretos, no el valor.
>
> Si una prueba de acá es automatizable y vale la pena, pasa a la suite (gate de costo — bucket 3
> del triaje). Lo que no se automatizó por costo queda anotado como deuda de automatización.

### Bloque 1 — [Rol] · [Flujo]

- **Usuario**: [correo del seed] (rol: [rol])
- **Credencial**: la del script de seed ([ruta del script]) — solo válida en local
- **Estado de partida**: [qué datos tiene que ver al entrar]
- **Depende de**: — [o "del bloque N", si hay orden obligatorio]

| # | Prueba | Resultado esperado | Resultado |
|---|---|---|---|
| 1.1 | [Pasos, en una línea] | [Qué debe pasar] | ☐ Pendiente / ✅ / 🐛 [BUG-XX] |
| 1.2 | | | |

**Cierre del bloque**: ☐ Pendiente / ✅ Cerrado el [fecha]

---

### Bloque 2 — [Rol] · [Flujo]

[...]

---

## Bugs

### BUG-01 — [Descripción corta]

- **Encontrado en**: Bloque [N], prueba [N.N]
- **Descripción**: [Qué pasó vs. qué debía pasar]
- **Disposición**: ☐ Abierto / ✅ Resuelto y confirmado por el usuario el [fecha] / ⏭️ `skipped` / 🚫 `won't resolve`
- **Motivo** (obligatorio si skipped o won't resolve): [Por qué se decidió no resolverlo]

---

## Cierre de la fase

- [ ] Los pasos 1 y 2 quedaron en verde antes de entregar los bloques
- [ ] Todos los bloques tienen cierre registrado
- [ ] Todos los bugs tienen disposición explícita
- [ ] Los bugs `won't resolve` y `skipped` tienen motivo documentado — y su candidato de backlog
- [ ] **El usuario confirmó explícitamente el cierre de la fase**: ____________ (fecha)

→ Con este checklist completo, el cambio puede pasar a **archive**.