# ── Argui · delta del schema OpenSpec: stage `qa` ─────────────────────────
#
# Cómo usar:
#   1. Forkea primero:  openspec schema fork spec-driven argui
#   2. Confirma que `verify` sigue en openspec/schemas/argui/schema.yaml.
#   3. Mira cómo están definidos `verify` y `archive` en TU fork y replica su
#      forma estructural para insertar `qa` ENTRE ellos. Las claves exactas
#      (nombres de stage, requires/tracks) dependen de tu versión de OpenSpec.
#   4. El valor DURABLE de este snippet es el `instruction` (la contribución de
#      Argui). La estructura YAML es andamiaje — ajústala a tu versión.
#   5. Copia templates/qa-artifact.md.template como la plantilla `qa.md` del schema.
#
# `qa` es un stage PROPIO de Argui (OpenSpec no lo trae): pruebas manuales del
# cambio con aprobación humana, entre verify y archive.

# 1) Artifact que produce el documento de QA.
artifacts:
  - id: qa-checklist
    generates: qa.md
    description: Artefacto de QA — pruebas manuales del cambio y seguimiento de la fase
    template: qa.md
    instruction: |
      Construye el artefacto de QA del cambio sobre los tres pasos del protocolo:
      (1) qué datos tiene que haber en la base para estas pruebas —usuarios con su
      rol, un registro en cada estado del flujo, el caso vacío, los casos borde del
      cambio—; (2) qué suites cubren lo objetivo (API, estado de BD, lógica) con su
      comando; (3) los bloques manuales, uno por rol × flujo, cada uno con su
      usuario, su estado de partida y sus pruebas con criterio de paso, marcadas
      como pendientes. Las pruebas salen de los specs y del PRD técnico; lo que ya
      cubre la suite NO se repite como prueba manual (triaje de QA, efficiency.md).
      Las credenciales van POR REFERENCIA al script de seed —nunca el valor en el
      artefacto, nunca credenciales de un entorno real—. Generación y seguimiento son
      trabajo mecánico (tier económico).

# 2) Stage qa — entre verify y archive. Ajusta las claves a tu versión (mira `verify`).
qa:
  requires: [qa-checklist]
  tracks: qa.md
  instruction: |
    Corre el protocolo en orden. Es SECUENCIAL y BLOQUEANTE:
    1. Verifica los datos en la base: no "corrí el seed", sino confirmar que existe
       lo que estas pruebas necesitan (usuarios y roles, un registro por estado, el
       caso vacío, los casos borde), sobre un seed reproducible y versionado. Si
       falla, no se pasa al 2.
    2. Corre lo automatizable y regístralo: comando y resultado, con fecha, y
       declara qué queda cubierto para que no se vuelva a probar a mano. Si queda en
       rojo, al humano no se le entrega nada.
    3. Entrega los bloques manuales —un bloque = un rol × un flujo, autocontenido y
       con su propio cierre, porque QA ocurre en varias sentadas—. Es el residuo del
       triaje, no un volcado mecánico.
    Cada bug se corrige (re-entra a apply con el agente implementador
    correspondiente) y se confirma, o se marca `won't resolve` / `skipped` con
    motivo documentado; al aplazarse genera un candidato de backlog. Automatizar con
    Playwright solo cuando el gate de costo lo justifique (ver efficiency.md). La
    fase NO cierra sin aprobación humana explícita (✋).