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.
247 lines
3.8 KiB
Markdown
247 lines
3.8 KiB
Markdown
# Organización de chats en proyectos de desarrollo
|
|
|
|
## Objetivo
|
|
|
|
Organizar los chats de un Proyecto de ChatGPT de forma que cada conversación mantenga un contexto claro, estable y reutilizable.
|
|
|
|
---
|
|
|
|
## Chats básicos
|
|
|
|
### `[ARCH] Arquitectura y decisiones`
|
|
|
|
Para:
|
|
|
|
- arquitectura;
|
|
- patrones;
|
|
- convenciones;
|
|
- decisiones transversales;
|
|
- ADR;
|
|
- límites entre módulos.
|
|
|
|
### `[BACKEND] Backend transversal`
|
|
|
|
Para aspectos de backend que afecten a varios módulos:
|
|
|
|
- APIs;
|
|
- middleware;
|
|
- DI;
|
|
- errores;
|
|
- transacciones;
|
|
- autenticación/autorización;
|
|
- infraestructura común.
|
|
|
|
### `[FRONTEND] Frontend / UI / UX`
|
|
|
|
Para:
|
|
|
|
- layouts;
|
|
- componentes compartidos;
|
|
- sistema de diseño;
|
|
- navegación;
|
|
- UX;
|
|
- accesibilidad;
|
|
- responsive;
|
|
- patrones frontend.
|
|
|
|
### `[TESTS] Testing / E2E`
|
|
|
|
Para:
|
|
|
|
- estrategia de tests;
|
|
- infraestructura de testing;
|
|
- E2E;
|
|
- fixtures;
|
|
- mocks;
|
|
- problemas generales de testing.
|
|
|
|
### `[INFRA] Infraestructura / DevOps`
|
|
|
|
Para:
|
|
|
|
- Docker;
|
|
- CI/CD;
|
|
- despliegues;
|
|
- servidores;
|
|
- observabilidad;
|
|
- logging;
|
|
- monitorización;
|
|
- backups;
|
|
- entornos.
|
|
|
|
### `[DATA] Base de datos / persistencia`
|
|
|
|
Opcional.
|
|
|
|
Para:
|
|
|
|
- migraciones;
|
|
- índices;
|
|
- rendimiento;
|
|
- integridad;
|
|
- concurrencia;
|
|
- persistencia transversal.
|
|
|
|
### `[DOCS] Documentación`
|
|
|
|
Opcional.
|
|
|
|
Para:
|
|
|
|
- estructura documental;
|
|
- ADR;
|
|
- revisión de documentación;
|
|
- documentación técnica transversal.
|
|
|
|
---
|
|
|
|
## Chats por módulo o área funcional
|
|
|
|
Crear un chat por cada módulo o área con suficiente entidad propia.
|
|
|
|
Formato:
|
|
|
|
```text
|
|
[MODULO] Nombre
|
|
```
|
|
|
|
Ejemplos:
|
|
|
|
```text
|
|
[CUSTOMERS] Customers
|
|
[COMPANIES] Companies
|
|
[CATALOGS] Catalogs
|
|
[PROFORMAS] Proformas
|
|
[INVOICES] Issued Invoices
|
|
[IDENTITY] Identity
|
|
```
|
|
|
|
Usar estos chats para todo el trabajo específico del módulo:
|
|
|
|
- dominio;
|
|
- backend;
|
|
- frontend;
|
|
- persistencia;
|
|
- tests;
|
|
- bugs;
|
|
- pequeñas refactorizaciones.
|
|
|
|
---
|
|
|
|
## Chats temporales
|
|
|
|
Crear solo cuando el trabajo tenga suficiente entidad propia:
|
|
|
|
```text
|
|
[AUDIT] ...
|
|
[BUG] ...
|
|
[REFACTOR] ...
|
|
[MIGRATION] ...
|
|
[FEATURE] ...
|
|
```
|
|
|
|
No crear un chat nuevo para tareas pequeñas que encajen correctamente en un chat existente.
|
|
|
|
---
|
|
|
|
## Regla para elegir chat
|
|
|
|
```text
|
|
¿Pertenece claramente a un módulo?
|
|
→ Chat del módulo
|
|
|
|
¿Afecta a varios módulos dentro de una disciplina?
|
|
→ BACKEND / FRONTEND / TESTS / DATA / INFRA
|
|
|
|
¿Es una decisión transversal?
|
|
→ ARCH
|
|
|
|
¿Es un trabajo grande e independiente?
|
|
→ AUDIT / BUG / REFACTOR / MIGRATION / FEATURE
|
|
```
|
|
|
|
---
|
|
|
|
## Cuándo abrir un chat nuevo
|
|
|
|
Abrir uno cuando:
|
|
|
|
- cambie sustancialmente el contexto;
|
|
- el trabajo tenga entidad propia;
|
|
- existan muchas fases;
|
|
- sea una investigación independiente;
|
|
- el chat anterior sea demasiado largo;
|
|
- mezclar el nuevo trabajo dificulte entender decisiones anteriores.
|
|
|
|
No abrir un chat nuevo simplemente porque empieza una nueva tarea.
|
|
|
|
---
|
|
|
|
## Chats demasiado largos
|
|
|
|
Cuando un chat acumule demasiado histórico, cerrarlo conceptualmente y continuar en otro.
|
|
|
|
Ejemplo:
|
|
|
|
```text
|
|
[PROFORMAS] Fiscalidad I
|
|
[PROFORMAS] Fiscalidad II
|
|
```
|
|
|
|
Al iniciar el nuevo chat, trasladar únicamente:
|
|
|
|
```text
|
|
Objetivo actual:
|
|
Estado:
|
|
Decisiones vigentes:
|
|
Completado:
|
|
Pendientes:
|
|
Restricciones:
|
|
Fuentes de verdad:
|
|
Siguiente tarea:
|
|
```
|
|
|
|
No copiar toda la conversación anterior.
|
|
|
|
---
|
|
|
|
## Convención de nombres
|
|
|
|
Usar:
|
|
|
|
```text
|
|
[CATEGORIA] Descripción
|
|
```
|
|
|
|
Ejemplos:
|
|
|
|
```text
|
|
[ARCH] Arquitectura general
|
|
[FRONTEND] Layouts
|
|
[PROFORMAS] Fiscalidad
|
|
[BUG] Error al emitir factura
|
|
[REFACTOR] Inyección de dependencias
|
|
```
|
|
|
|
Evitar nombres ambiguos:
|
|
|
|
```text
|
|
Dudas
|
|
Cambios varios
|
|
Problema de hoy
|
|
Nuevo chat
|
|
```
|
|
|
|
---
|
|
|
|
## Principio general
|
|
|
|
Un chat debe representar un **contexto de trabajo estable**.
|
|
|
|
No debe representar necesariamente:
|
|
|
|
- todo el proyecto;
|
|
- ni una única tarea.
|
|
|
|
Debe agrupar conversaciones que realmente se beneficien de compartir contexto entre sí.
|