uecko-control-tiempos/docs/guias/flujo-chatgpt-codex.md

Flujo ChatGPT → Codex

Objetivo

Definir un flujo de trabajo consistente para analizar, implementar y validar cambios de desarrollo utilizando ChatGPT y Codex.

---

Flujo general

Necesidad
→ Análisis
→ Auditoría
→ Diseño
→ Prompt para Codex
→ Implementación
→ Validación
→ Revisión
→ Cierre

---

1. Plantear la necesidad

Definir:

• qué problema se quiere resolver;
• qué comportamiento se espera;
• qué módulo o área está afectada;
• qué restricciones conocidas existen.

Evitar empezar por una solución técnica concreta si todavía no se ha auditado el código.

---

2. Analizar el contexto

Antes de pedir cambios:

• revisar decisiones previas;
• identificar documentación relevante;
• comprobar si existe contexto suficiente;
• determinar el nivel de complejidad de la tarea.

---

3. Auditar el estado actual

Para cambios no triviales:

• localizar el flujo actual;
• identificar archivos, clases, hooks, casos de uso o servicios implicados;
• buscar patrones equivalentes;
• identificar contratos y consumidores;
• localizar causa raíz si existe un bug.

No modificar código cuando la fase tenga como objetivo exclusivo comprender el sistema.

---

4. Diseñar la solución

Definir:

• resultado esperado;
• alcance;
• invariantes;
• restricciones;
• componentes afectados;
• compatibilidad necesaria;
• validaciones requeridas.

Preferir la solución mínima compatible con la arquitectura existente.

---

5. Preparar el prompt para Codex

El prompt debe incluir, cuando corresponda:

CONTEXTO

OBJETIVO

ALCANCE

RESTRICCIONES

PROCEDIMIENTO

CRITERIOS DE VALIDACIÓN

FORMATO DE RESPUESTA

No repetir reglas ya definidas claramente en AGENTS.md salvo que sean especialmente relevantes para la tarea.

---

6. Implementación con Codex

Codex debe:

• inspeccionar el repositorio antes de modificar;
• respetar AGENTS.md;
• trabajar dentro del alcance;
• reutilizar patrones existentes;
• evitar cambios colaterales;
• mantener el código validable durante el proceso.

Para trabajos grandes, dividir la implementación en fases verificables.

---

7. Validación

Después de implementar:

tests específicos
→ tests del módulo
→ typecheck
→ lint
→ integración
→ E2E
→ validación global si corresponde

No ejecutar toda la cadena automáticamente si el alcance no lo requiere.

Exigir siempre evidencia de qué validaciones se han ejecutado realmente.

---

8. Revisar el resultado

Comprobar:

• que se ha resuelto el objetivo original;
• que el alcance no se ha ampliado innecesariamente;
• que las decisiones coinciden con el diseño;
• que no existen regresiones evidentes;
• que los tests cubren el comportamiento relevante;
• que los fallos preexistentes están diferenciados.

Si algo no está claro, auditar antes de pedir nuevas modificaciones.

---

9. Iterar si es necesario

Si aparecen defectos:

Diagnosticar
→ corregir causa
→ validar
→ volver a revisar

Evitar encadenar instrucciones correctivas sin reconstruir primero el problema cuando Codex empiece a desviarse.

---

10. Cerrar la tarea

Antes de considerar terminada una tarea:

• objetivo cumplido;
• alcance revisado;
• tests relevantes ejecutados;
• typecheck y lint revisados cuando corresponda;
• pendientes reales identificados;
• documentación actualizada si el cambio lo requiere.

Estados:

COMPLETA
PARCIAL
BLOQUEADA

---

Nivel de proceso según la tarea

Cambio pequeño

Analizar
→ Implementar
→ Validar

Cambio normal

Auditar
→ Diseñar
→ Implementar
→ Validar
→ Revisar

Cambio complejo o delicado

Auditoría independiente
→ Diseño
→ Implementación por fases
→ Validación entre fases
→ Verificación final
→ Documentación

---

Regla principal

No convertir el proceso en burocracia.

Aplicar únicamente el nivel de análisis, documentación y validación proporcional al riesgo, complejidad y alcance de la tarea.