Uecko/uecko-control-tiempos
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
uecko-control-tiempos/docs/guias/organizacion-de-chats.md
David e94d5e6c71 Add project documentation and architectural guidelines 
- 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.
2026-09-17 22:11:39 +02:00

3.8 KiB
Raw Permalink Blame History

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:

[MODULO] Nombre

Ejemplos:

[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:

[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

¿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:

[PROFORMAS] Fiscalidad I
[PROFORMAS] Fiscalidad II

Al iniciar el nuevo chat, trasladar únicamente:

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:

[CATEGORIA] Descripción

Ejemplos:

[ARCH] Arquitectura general
[FRONTEND] Layouts
[PROFORMAS] Fiscalidad
[BUG] Error al emitir factura
[REFACTOR] Inyección de dependencias

Evitar nombres ambiguos:

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