# 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í.