Instrucciones de orquestación

# ── Argui · delta del schema OpenSpec: `instruction` de orquestación ──────
#
# Qué es: la prosa que dirige a la IA en cada stage del ciclo iterativo. Es el
# lugar concreto donde vive "la lógica de invocación de agentes" — el `model` de
# cada agente vive en el agente; el *cuándo* invocarlo vive acá.
#
# Cómo usar:
#   1. Forkea primero:  openspec schema fork spec-driven argui
#   2. Abre openspec/schemas/argui/schema.yaml y pega cada `instruction` en SU
#      stage. Las claves exactas dependen de tu versión de OpenSpec: mira cómo
#      está definido cada stage en TU fork y respeta esa forma.
#   3. Reemplaza los [corchetes] por los agentes reales del proyecto (F4.7).
#   4. openspec update  → regenera los bindings (nunca se editan a mano).
#
# `apply`, `verify` y `archive` son stages BASE de OpenSpec: acá va solo el
# `instruction`, nunca la estructura del stage (esa sale de tu fork, y congelarla
# la deja obsoleta en el próximo upgrade).
#
# El stage `qa` es invención de Argui y se distribuye aparte, con su estructura
# y su instruction: ver qa-stage.snippet.yaml. No lo dupliques acá.
#
# Fundamento: methodology/openspec.md · methodology/efficiency.md · workflow.md F5.1

apply:
  instruction: |
    Antes de implementar, clasifica el change como `architectural: true | false`
    (paso económico, criterios en efficiency.md: dependencia mayor, contratos
    entre módulos, modelo de datos, seguridad/autenticación, patrón transversal
    nuevo). Solo si marca `true` participa el arquitecto [agente-arquitecto], que
    toma o valida las decisiones de diseño. Si el change venía definido desde
    F3.5, el gate además lo revalida contra el PRD y el prototipo vigentes.
    Implementan los agentes [agentes-implementadores], agrupando los archivos
    relacionados en una sola invocación en vez de uno por archivo.

verify:
  instruction: |
    Hasta tres pases, en orden y con corte temprano:
    1. Cumplimiento (económico): pasan los tests, se siguen los estándares, se
       cumplen los criterios literales del spec, no hay archivos fuera de lugar.
    2. Juicio (capaz): calidad, bugs sutiles, idoneidad del enfoque. ES la
       revisión de código del ciclo y la hace un agente que NO implementó
       ([agentes-revisores]). Corre si el pase 1 aprobó o dejó flags de juicio.
    3. Seguridad (capaz), CONDICIONAL: un paso económico clasifica el change como
       `security: true | false` (autenticación o autorización, datos personales o
       de pago, entradas no confiables, secretos, dependencias nuevas, superficie
       pública). Solo si marca `true` corre este pase, que busca vulnerabilidades
       en el diff, no calidad general. Un hallazgo BLOQUEA el archive salvo
       disposición explícita del humano con su motivo; al aplazarse, genera un
       candidato de backlog.
    Los pases son responsabilidades, no comandos: si el asistente ofrece una
    revisión de código o de seguridad empaquetada, úsala como atajo; si no, corre
    igual como instrucción al agente revisor.

# qa: → ver qa-stage.snippet.yaml (stage propio de Argui, entre verify y archive)

archive:
  instruction: |
    1. Sincroniza las delta specs con las principales (`/opsx:sync`) — es una
       acción separada, antes de archivar.
    2. Revisión final: los revisores [agentes-revisores] repasan el código del
       change y corrigen los issues que encuentren. Si el gate marcó impacto
       arquitectónico, el arquitecto verifica la consistencia con la arquitectura
       definida.
    3. Actualiza el progreso en todos los archivos (agente de progreso, tier
       económico): backlog —incluido regenerar su diagrama de dependencias desde
       los campos Estado y Dependencias—, CLAUDE.md y documentos de estado.
    4. Agrega la fila de este change al índice de changes archivados
       (README.md de la carpeta de archivo; créalo desde
       templates/archive-index.md.template si no existe): ID, fecha, título,
       capabilities/specs tocadas, RF que satisface y la regla aprendida.
       Append-only: no reescribas filas anteriores.
    5. Pregunta si el change dejó una REGLA APRENDIDA. El default es "ninguna";
       se anota solo si verify o qa corrigieron algo que se repetiría en el
       próximo change, si hubo que decidir una convención sobre la marcha, o si
       un supuesto del PRD o del spec resultó falso. Si la dejó, escríbela en
       donde se aplica —estándares del proyecto, decisiones.md, CLAUDE.md o la
       spec de su capability— y deja en el índice solo el puntero.
    6. Cuenta los ítems archivados desde la última auditoría; al llegar al umbral
       (5 ítems, o fin de sprint) sugiere correr la auditoría periódica.