# Flujo ChatGPT → Codex

## Objetivo

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

---

## Flujo general

```text
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:

```text
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:

```text
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:

```text
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:

```text
COMPLETA
PARCIAL
BLOQUEADA
```

---

## Nivel de proceso según la tarea

### Cambio pequeño

```text
Analizar
→ Implementar
→ Validar
```

### Cambio normal

```text
Auditar
→ Diseñar
→ Implementar
→ Validar
→ Revisar
```

### Cambio complejo o delicado

```text
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.