FlexGodX/Ciclo-de-Desarrollo-Autónomo-Agentic

Ciclo de Desarrollo Autónomo Agentic (Pipeline con Quality Gates)

Este skill formaliza el flujo de trabajo de ingeniería de 5 fases y el pipeline de arbitraje multi-agente desarrollado y verificado durante la creación autónoma de Quest Nova (Flutter + Go + PostgreSQL 16 + Drift/SQLite).

Garantiza alta fidelidad arquitectónica, cero pérdida de datos, seguridad estricta (Zero-Trust/IDOR) y sincronización distribuida verificada matemáticamente sin intervención humana entre fases.

[!NOTE] Ingeniería Inversa Excluida: La fase de ingeniería inversa está omitida/deshabilitada. El pipeline comienza directamente con la Definición de Objetivos y la redacción de Especificaciones Funcionales (o toma un brief de producto existente como entrada).

---

1. Principios de Arquitectura Central

1. Autonomía Sin Interrupción: El orquestador avanza a través de todas las fases de forma autónoma. La confirmación se deriva estrictamente de auditorías rigurosas de Quality Gates, en lugar de preguntar al usuario.
2. Verificación Independiente con Contexto Limpio: Los revisores y jueces se crean como subagentes dedicados con contexto limpio (reciben solo el artefacto objetivo verificable, las especificaciones de referencia y los criterios de evaluación explícitos, libres de razonamiento previo del chat).
3. Barrera de Aprobación Unánime: La transición a la siguiente fase está bloqueada hasta que todos los auditores/jueces otorguen un veredicto explícito de APPROVED. Las listas de defectos (CHANGES_REQUESTED) activan un bucle inmediato de corrección-re-auditoría.
4. Enrutamiento de Modelo de Respaldo: Cuando los modelos de razonamiento primarios experimentan límites de tasa (por ejemplo, cuota agotada HTTP 429), el pipeline enruta sin problemas las tareas a modelos de alto rendimiento disponibles (por ejemplo, Gemini 3.8 Flash) preservando estrictamente los roles de los agentes y los límites de contexto limpio.

---

2. El Pipeline de 5 Fases

flowchart TD
    P1["Fase 1: Formulación de Objetivos y Especificación Funcional"] --> QG1{"Quality Gate 1: Auditoría de Especificación"}
    QG1 -->|"CHANGES_REQUESTED"| P1Fix["Resolución de Defectos de Especificación"]
    P1Fix --> QG1
    QG1 -->|"APPROVED (Unánime)"| P2["Fase 2: Diseño del Sistema y Arquitectura"]
    P2 --> QG2{"Quality Gate 2: Tribunal de 3 Agentes"}
    QG2 -->|"CHANGES_REQUESTED"| P2Fix["Refinamiento de Arquitectura"]
    P2Fix --> QG2
    QG2 -->|"APPROVED (Unánime)"| P3["Fase 3: Artefacto de QA y Plan de Implementación"]
    P3 --> QG3{"Quality Gate 3: Revisión Cruzada de Trazabilidad"}
    QG3 -->|"CHANGES_REQUESTED"| P3Fix["Alineación Plan y QA"]
    P3Fix --> QG3
    QG3 -->|"APPROVED (Unánime)"| P4["Fase 4: Implementación (Backend + Cliente)"]
    P4 --> P5["Fase 5: Verificación Completa, Pruebas de Estrés y Lanzamiento"]

---

3. Convención de Nomenclatura de Artefactos

Cada artefacto producido por el pipeline es un archivo versionado. Nunca sobrescribas un artefacto en el mismo lugar; crea la siguiente versión en su lugar.

<NOMBRE-ARTEFACTO>-<fecha>-<NN>.md

• <NOMBRE-ARTEFACTO> — Nombre en UPPER_SNAKE del artefacto: GOAL, SPECIFICATION, DESIGN, QA_ARTIFACT, IMPLEMENTATION_PLAN, RELEASE_NOTES.
• <fecha> — fecha de creación en formato ISO YYYY-MM-DD.
• <NN> — número de secuencia de dos dígitos (01, 02, …) que desambigua artefactos del mismo nombre creados dentro del mismo día. Comienza en 01 en el primer artefacto del día e incrementa para cada revisión subsiguiente de ese mismo artefacto en ese día. El contador es por nombre de artefacto, por lo que diferentes artefactos creados el mismo día pueden compartir el mismo número (por ejemplo, GOAL-2026-11-10-01.md y DESIGN-2026-11-10-01.md). En un nuevo día, el contador comienza de nuevo en 01.

Ejemplo:

Artefacto	Primer artefacto del día	Segundo artefacto del mismo día
Goal	docs/GOAL-2026-11-10-01.md	docs/GOAL-2026-11-10-02.md
Specification	docs/SPECIFICATION-2026-11-10-01.md	docs/SPECIFICATION-2026-11-10-02.md
Design	docs/DESIGN-2026-11-10-01.md	docs/DESIGN-2026-11-10-02.md

Reglas:

1. Los entregables de las fases y todas las referencias cruzadas (prompts de Quality Gates, planes, notas de lanzamiento) deben citar el nombre de archivo versionado exacto, nunca un nombre no versionado como docs/GOAL.md.
2. El <NN> más alto para un nombre de artefacto es la versión autorizada actual; las versiones anteriores permanecen intactas como un rastro de auditoría.
3. Los Quality Gates auditan la versión específica que se les entrega y registran ese nombre de archivo en su veredicto.

A lo largo de este skill, <fecha> y <NN> representan la fecha y el número de secuencia descritos anteriormente.

---

4. Guía de Ejecución Fase por Fase

Fase 1: Formulación de Objetivos y Especificación Funcional (Quality Gate 1)

• Objetivo: Formular límites explícitos del sistema, bucles de usuario, modelos de dominio y especificaciones técnicas basadas directamente en los requisitos/brief.
• Entregables:
  • docs/GOAL-<fecha>-<NN>.md: Alcance global del sistema, invariantes centrales, Definición de Hecho (DoD).
  • docs/SPECIFICATION-<fecha>-<NN>.md: Esquemas de entidades, mecánica temporal, protocolo de sincronización, versionado OCC, reglas de fusión de 3 vías, protección IDOR, esquemas DDL.
• Quality Gate 1 (Auditor de Contexto Limpio):
  • Crear subagente (typeName: "research").
  • Proporcionar solo docs/SPECIFICATION-<fecha>-<NN>.md y los criterios (integridad, seguridad, integridad de datos, consistencia).
  • Bucle hasta APPROVED.

Fase 2: Diseño del Sistema y "Tribunal de Tres Agentes" (Quality Gate 2)

• Objetivo: Arquitecturar un backend escalable y tolerante a fallos y un cliente reactivo.
• Entregable: docs/DESIGN-<fecha>-<NN>.md (documento de diseño del sistema: backend, cliente, seguridad).
• Quality Gate 2 (El Tribunal de Tres Agentes): Crear 3 subagentes independientes con contexto limpio:
  1. Juez 1 (Backend y Arquitecto de Sistemas): Evalúa esquema de BD, límites de transacciones, bloqueos a nivel de fila, ordenamiento DAG topológico, esquemas de partición y OCC.
  2. Juez 2 (Cliente y Arquitecto de UI): Evalúa BD Offline-First (Drift/SQLite), isolates en segundo plano, presupuesto de frame (< 16.6 ms), coalescencia de cola de mutación y máquinas de estado BLoC.
  3. Juez 3 (Crítico de Seguridad y Casos Extremos): Identifica condiciones de carrera, deadlocks de arranque en frío, bucles de eco, reutilización de tokens (RTR), robo de sesión y vulnerabilidades IDOR.
  • Los 3 jueces deben devolver APPROVED antes de continuar.

Fase 3: Artefacto de QA, Plan de Trazabilidad y Quality Gate 3

• Objetivo: Asegurar 100% de trazabilidad bidireccional entre especificación, arquitectura y pruebas antes de escribir código.
• Entregables:
  • docs/QA_ARTIFACT-<fecha>-<NN>.md: Criterios de Aceptación Completos (AC-XX), escenarios de prueba Unitaria, Integración, Sincronización Distribuida (TC-SYNC-XX) y pruebas de Estrés (STRESS-XX).
  • docs/IMPLEMENTATION_PLAN-<fecha>-<NN>.md: Desglose de tareas por etapas mapeado directamente a los casos de QA.
• Quality Gate 3 (Revisor Cruzado):
  • Verificar que cada criterio de aceptación y caso extremo en docs/QA_ARTIFACT-<fecha>-<NN>.md se mapea directamente a un paso de implementación en docs/IMPLEMENTATION_PLAN-<fecha>-<NN>.md.
  • Bucle hasta APPROVED.

Fase 4: Implementación y Verificación de Pruebas

1. Migraciones de Base de Datos: Aplicar todas las migraciones DDL con índices compuestos y particionamiento.
2. Motor Backend:
   • Arquitectura Limpia: domain/, repository/, usecase/, delivery/http/.
   • Ejecución de pruebas unitarias y de integración: cd backend && go test -v ./....
3. Motor Cliente:
   • Utilidades temporales centrales (PlainDate, FloatingTime, SparseSortOrder).
   • Motor de Fusión Diferencial de 3 Vías (5 escenarios de lista de verificación, notas de cero pérdida de datos).
   • Coalescencia de mutaciones in situ y manejo de condiciones de carrera en vuelo (MutationQueueManager).
   • Arquitectura BLoC y UI Adaptativa (3 paneles en Escritorio + Navegación Móvil).
   • Ejecución de pruebas del cliente: cd client && flutter test.
   • Verificación del linter: cd client && flutter analyze (0 problemas).

Fase 5: Pruebas de Estrés, Lanzamiento y Entrega

1. Verificación de Sincronización Distribuida: Ejecutar concurrencia multi-dispositivo, conflictos OCC, supresión de Eco y reconciliación de Bootstrap HTTP 410.
2. Pruebas de Estrés:
   • Saturación del Pool de Conexiones de la BD (STRESS-01): Trabajadores concurrentes con 0 fugas de pool.
   • Benchmark del Presupuesto de Frame de UI (STRESS-02): 1000 tareas procesadas en < 16.6 ms (60/120 FPS estable).
3. Compilación de Artefactos:
   • Construir binario nativo del backend: go build -o bin/<servicio> cmd/<servicio>/main.go.
   • Construir paquete del cliente: flutter build bundle / flutter build macos / flutter build web.
4. Notas de Lanzamiento: Generar docs/RELEASE_NOTES-<fecha>-<NN>.md documentando métricas verificadas, lista de verificación DoD e instrucciones de ejecución.

---

5. Plantillas de Prompts para Auditores y Jueces

Para las plantillas de prompts utilizadas al invocar subagentes de contexto limpio para los Quality Gates 1, 2 y 3, consulta references/auditor_prompts.md.