David
e94d5e6c71
- Created project overview document for UECKO application. - Added README file for project documentation structure. - Introduced template for architectural decision records (ADR). - Defined backend architecture guidelines. - Established conventions for project-wide consistency. - Documented data persistence architecture. - Outlined frontend architecture principles. - Developed testing strategy documentation. - Provided a general architecture overview. - Created guides for task closure and ChatGPT-Codex workflow. - Organized chat management guidelines for development projects. - Added template for current work status reporting.
227 lines
4.0 KiB
Markdown
227 lines
4.0 KiB
Markdown
# 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.
|