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.

docs/Ficha del proyecto UECKO.md

@@ -0,0 +1,194 @@
+# Ficha del proyecto
+
+## 1. Identificación
+
+**Nombre del proyecto:**  
+Aplicación de Control de Tiempos y Gestión UECKO
+
+**Objetivo principal:**  
+Desarrollar una aplicación para la gestión de tiempos, tareas, actividad, incidencias y procesos de Oficina Técnica y Oficina Comercial para Uecko. La aplicación debe centralizar la operativa de ambos módulos, conservar la trazabilidad y el histórico de la información y permitir la evolución funcional mediante nuevas versiones sin pérdida ni reconstrucción manual de datos.
+
+**Estado actual:**  
+En pruebas con datos demo
+
+## 2. Repositorio
+
+**Repositorio principal:**  
+N/A
+
+**Estructura general:**  
+N/A
+
+## 3. Stack tecnológico
+
+**Backend:**  
+N/A
+
+**Frontend:**  
+N/A
+
+**Base de datos:**  
+N/A
+
+**Testing:**  
+N/A
+
+**Infraestructura / despliegue:**  
+N/A
+
+## 4. Arquitectura
+
+**Estilo arquitectónico:**  
+N/A
+
+**Organización principal:**  
+La aplicación se divide inicialmente en dos módulos funcionales:
+
+* Oficina Comercial.
+* Oficina Técnica.
+
+Existe además una base común transversal que contiene las reglas compartidas de arquitectura, personas, perfiles, permisos, tareas, contextos, imputación de tiempos, trazabilidad, actualización y continuidad de datos.
+
+Cada módulo mantiene su responsabilidad funcional y es propietario de los datos que genera. Los flujos, campos y permisos específicos deben definirse en el documento funcional correspondiente a cada módulo.
+
+La aplicación y la base de datos deben mantenerse separadas conceptualmente:
+
+* la aplicación contiene interfaz, lógica de negocio, pantallas, navegación y funcionalidades;
+* la base de datos contiene usuarios, perfiles, permisos, presupuestos, expedientes, OF, estados, tareas, tiempos, errores, comentarios, trazabilidad e históricos.
+
+**Reglas arquitectónicas importantes:**
+
+* El programa y los datos deben permanecer separados.
+* Una actualización de la aplicación no puede sobrescribir ni eliminar información operativa o histórica.
+* Los datos deben sobrevivir a cualquier cambio de versión.
+* Los cambios de estructura de datos deben realizarse mediante actualizaciones controladas.
+* Antes de modificar la estructura de datos debe existir una copia de seguridad recuperable.
+* Las nuevas versiones no pueden exigir reintroducir manualmente datos históricos.
+* Las ampliaciones futuras deben integrarse sobre la base existente sin reconstruir usuarios, históricos ni datos comunes.
+* Las migraciones de datos y actualizaciones deben quedar registradas.
+* Los módulos pueden consultar información del otro módulo cuando sea necesario, pero no modificar datos ajenos salvo permiso expreso.
+* Los cambios relevantes deben poder probarse en un entorno Beta antes de aplicarse a Producción.
+* El desarrollador no debe operar directamente sobre datos de Producción fuera de los mecanismos previstos por la aplicación.
+
+## 5. Convenciones relevantes
+
+* Los perfiles se definen por puesto o función y se reutilizan entre las personas que desempeñen ese puesto.
+* Una misma persona puede disponer de varios perfiles.
+* El Máster asigna perfiles y permisos; el usuario no puede modificarlos por sí mismo.
+* Tarea y contexto son conceptos diferentes:
+  * la tarea indica qué trabajo se realiza;
+  * el contexto indica para qué se realiza.
+* Los contextos principales de la primera fase son:
+  * Presupuesto;
+  * OF;
+  * Actividad general.
+* Los grupos funcionales de tareas contemplados inicialmente son, como mínimo:
+  * OT;
+  * OC · Presupuestos;
+  * OC · Back Office;
+  * OC · Pedidos;
+  * Comunes.
+* Una tarea puede pertenecer a uno o varios grupos.
+* Las tareas o grupos con histórico no se eliminan físicamente; se desactivan para nuevos usos.
+* Solo puede existir una actividad activa a la vez.
+* Debe permitirse tanto la imputación de tiempo en tiempo real como la imputación diferida.
+* La imputación debe disponer de controles de solape y mantener trazabilidad.
+* Back Office puede iniciar tareas sin número de presupuesto ni OF mediante un identificador interno y vincularlas posteriormente sin reescribir el tiempo registrado.
+* Presupuestos imputa normalmente contra número de presupuesto, con posibilidad excepcional de hacerlo contra OF.
+* Pedidos imputa contra OF.
+* Oficina Técnica trabaja fundamentalmente contra OF.
+* Cuando un expediente cambia de fase, los datos consolidados de la fase anterior quedan bloqueados para la edición ordinaria.
+* Las correcciones posteriores a un cambio de fase deben realizarse mediante un procedimiento formal y quedar registradas.
+* Un expediente puede existir incompleto, pero no puede avanzar de fase mientras falten datos obligatorios para dicha transición.
+* Las fechas y horas de cambios de estado, el usuario que ejecuta las acciones y los registros automáticos del sistema no son editables por usuarios ordinarios.
+* Las correcciones excepcionales realizadas por el Máster deben conservar:
+  * valor anterior;
+  * valor nuevo;
+  * fecha;
+  * hora;
+  * usuario.
+* Los números de presupuesto y OF son identificadores maestros externos procedentes de Factuges.
+* La aplicación no debe generar, sustituir ni reutilizar números de presupuesto u OF.
+* El presupuesto debe conservar su identidad de origen y las OF deben mantener su vínculo con el presupuesto del que proceden.
+
+## 6. Comandos habituales
+
+**Instalación:**
+
+```bash
+N/A
+```
+
+**Desarrollo:**
+
+```bash
+N/A
+```
+
+**Tests:**
+
+```bash
+N/A
+```
+
+**Typecheck:**
+
+```bash
+N/A
+```
+
+**Lint:**
+
+```bash
+N/A
+```
+
+## 7. Documentación de referencia
+
+Principales documentos que deben consultarse antes de tomar decisiones:
+
+* `Respaldo_Arquitectura_Tecnica_Aplicacion_v1.1.md` — Arquitectura técnica y reglas comunes de la aplicación.
+* Documento funcional de Oficina Comercial.
+* Documento funcional de Oficina Técnica.
+
+## 8. Restricciones importantes
+
+* No debe perderse información existente como consecuencia de una actualización.
+* No deben sobrescribirse ni eliminarse usuarios, expedientes, OF, tareas, imputaciones de tiempo, errores, históricos, registros de actividad ni configuraciones funcionales durante una actualización.
+* Debe mantenerse compatibilidad con los datos existentes entre versiones.
+* Ninguna evolución futura debe requerir la reintroducción manual de datos históricos.
+* Antes de cualquier cambio estructural de base de datos debe existir una copia de seguridad recuperable.
+* Toda actualización debe realizar una copia automática de seguridad cuando corresponda.
+* Debe existir un mecanismo de restauración o rollback que no dependa de conocimientos técnicos del usuario Máster.
+* La aplicación debe impedir la instalación de paquetes de actualización no válidos o incompatibles.
+* En la primera etapa, las actualizaciones se distribuyen como paquetes completos de versión, no como conjuntos de archivos sueltos.
+* Las modificaciones relevantes deben poder validarse en Beta antes de pasar a Producción.
+* El perfil Informática / Soporte no debe modificar por defecto reglas funcionales del negocio.
+* El perfil Desarrollador no debe modificar directamente datos de Producción fuera de los mecanismos previstos.
+* Los módulos no deben modificar datos propiedad de otros módulos salvo permiso expreso.
+* No deben eliminarse físicamente tareas o grupos que tengan histórico.
+* Los datos consolidados de una fase no deben modificarse mediante edición ordinaria después del avance de fase.
+* Los registros automáticos, fechas de cambio de estado y usuarios asociados a acciones no deben ser editables por usuarios ordinarios.
+* Los identificadores de presupuesto y OF procedentes de Factuges no pueden ser inventados, sustituidos ni reutilizados por la aplicación.
+* Las nuevas decisiones funcionales deben incorporarse previamente al documento marco correspondiente antes de pasar a Producción.
+* La aplicación debe limitarse a registrar, conservar, relacionar, mostrar, filtrar y exportar información. No debe emitir automáticamente juicios de rendimiento ni conclusiones de gestión.
+
+## 9. Observaciones
+
+La responsabilidad transversal de la primera fase corresponde a Dirección Técnica. Cada módulo conserva además su propia responsabilidad funcional mediante el Responsable de Oficina Comercial y el Responsable de Oficina Técnica.
+
+Existe un perfil Máster con responsabilidad sobre permisos y decisiones funcionales, diferenciado de los perfiles Informática / Soporte y Desarrollador.
+
+La aplicación contempla un nivel de experiencia UECKO calculado automáticamente a partir de la fecha de incorporación:
+
+* Nivel 1: hasta 3 meses.
+* Nivel 2: más de 3 y hasta 6 meses.
+* Nivel 3: más de 6 y hasta 9 meses.
+* Nivel 4: más de 9 y hasta 12 meses.
+* Nivel 5: más de 12 meses.
+
+Este nivel representa antigüedad y adaptación al entorno UECKO, no una calificación profesional. Cuando sea relevante para análisis posteriores, debe conservarse el nivel existente en el momento de asignación del trabajo.
+
+Las actualizaciones deben generar un registro técnico independiente del histórico funcional, incluyendo fecha y hora, usuario, versión anterior, versión nueva, resultado y, cuando proceda, restauración posterior.
+
+Mientras no exista integración automática con Factuges, los números de presupuesto y OF pueden incorporarse manualmente o mediante importación, manteniendo siempre Factuges como sistema de origen de dichos identificadores.

docs/README.md

@@ -0,0 +1,37 @@
+# Documentación del proyecto
+
+Este directorio contiene la documentación técnica y operativa del proyecto.
+
+## Estructura
+
+```text
+docs/
+├── architecture/
+├── adr/
+├── work/
+├── guides/
+└── README.md
+```
+
+### `architecture/`
+
+Documentación estable sobre la arquitectura y las reglas generales del sistema.
+
+### `adr/`
+
+Decisiones arquitectónicas o técnicas relevantes y duraderas.
+
+### `work/`
+
+Estado de trabajos largos, migraciones, refactors o iniciativas en curso.
+
+### `guides/`
+
+Procedimientos operativos y guías para desarrolladores.
+
+## Principios
+
+- Evitar duplicar información.
+- Mantener una única fuente de verdad por tema.
+- Actualizar la documentación cuando cambien decisiones o contratos relevantes.
+- No documentar detalles triviales que ya se expresen claramente en el código.

docs/adr/0000-plantilla.md

@@ -0,0 +1,45 @@
+# ADR-0000 — Título
+
+## Estado
+
+Propuesta / Aceptada / Sustituida / Rechazada
+
+## Contexto
+
+[Qué problema existe y por qué requiere una decisión.]
+
+## Decisión
+
+[Qué se ha decidido.]
+
+## Motivos
+
+[Por qué se elige esta opción.]
+
+## Consecuencias
+
+### Positivas
+
+- ...
+
+### Negativas
+
+- ...
+
+### Restricciones
+
+- ...
+
+## Alternativas consideradas
+
+### Alternativa A
+
+[Descripción y motivo de descarte.]
+
+### Alternativa B
+
+[Descripción y motivo de descarte.]
+
+## Referencias
+
+- [Issue / documento / código]

docs/arquitectura/backend.md

@@ -0,0 +1,64 @@
+# Arquitectura backend
+
+## Objetivo
+
+Definir la estructura, responsabilidades y reglas principales del backend.
+
+## Organización
+
+[Capas, módulos, bounded contexts o estructura principal.]
+
+## Flujo de entrada
+
+[Request → aplicación → dominio → persistencia → respuesta.]
+
+## Responsabilidades
+
+### Entrada / API
+
+[Responsabilidades.]
+
+### Aplicación
+
+[Responsabilidades.]
+
+### Dominio
+
+[Responsabilidades.]
+
+### Infraestructura
+
+[Responsabilidades.]
+
+## Casos de uso
+
+[Convenciones y responsabilidades.]
+
+## Servicios
+
+[Convenciones y responsabilidades.]
+
+## Repositorios
+
+[Reglas y límites.]
+
+## Persistencia
+
+[ORM, mappers, modelos, transacciones.]
+
+## Errores
+
+[Estrategia de errores y mapeo.]
+
+## Transacciones
+
+[Reglas de atomicidad y rollback.]
+
+## Seguridad
+
+[Autenticación, autorización, tenancy, validación.]
+
+## Referencias
+
+- [ADR relacionado]
+- [Documento relacionado]

docs/arquitectura/convenciones.md

@@ -0,0 +1,55 @@
+# Convenciones del proyecto
+
+## Objetivo
+
+Centralizar convenciones generales que afecten a todo el repositorio.
+
+## Idioma
+
+- Código e identificadores: [definir]
+- Comentarios: [definir]
+- Documentación: [definir]
+
+## Naming
+
+- Ficheros: [convención]
+- Directorios: [convención]
+- Clases / tipos: [convención]
+- Variables / funciones: [convención]
+- Constantes: [convención]
+
+## Estructura de carpetas
+
+[Convenciones principales.]
+
+## Tipado
+
+[Reglas principales.]
+
+## Validación
+
+[Reglas principales.]
+
+## Errores
+
+[Reglas principales.]
+
+## Async
+
+[Reglas principales.]
+
+## Imports
+
+[Reglas principales.]
+
+## Dependencias
+
+[Reglas para añadir o actualizar dependencias.]
+
+## Git
+
+[Convenciones relevantes.]
+
+## Documentación
+
+[Convenciones de actualización y SSOT.]

docs/arquitectura/datos-persistencia.md

@@ -0,0 +1,46 @@
+# Arquitectura de datos y persistencia
+
+## Objetivo
+
+Definir las reglas de persistencia, integridad y evolución de datos.
+
+## Base de datos
+
+[Motor, versión y configuración relevante.]
+
+## Modelado
+
+[Convenciones para tablas, columnas, claves y relaciones.]
+
+## Persistencia
+
+[ORM, repositorios y mappers.]
+
+## Transacciones
+
+[Reglas de atomicidad.]
+
+## Integridad
+
+[Constraints, foreign keys, invariantes críticas.]
+
+## Concurrencia
+
+[Locks, versionado, idempotencia, etc.]
+
+## Migraciones
+
+[Estrategia de migraciones.]
+
+## Índices y rendimiento
+
+[Convenciones y criterios.]
+
+## Datos legacy
+
+[Reglas para compatibilidad y eliminación.]
+
+## Referencias
+
+- [ADR relacionado]
+- [Documento relacionado]

docs/arquitectura/frontend.md

@@ -0,0 +1,52 @@
+# Arquitectura frontend
+
+## Objetivo
+
+Definir la estructura y las reglas generales del frontend.
+
+## Organización
+
+[Aplicaciones, módulos, features, pages, components, hooks, etc.]
+
+## Estado
+
+### Estado remoto
+
+[Herramienta y reglas.]
+
+### Estado local
+
+[Reglas.]
+
+## Formularios
+
+[Convenciones de formularios y validación.]
+
+## Componentes
+
+[Reutilización, sistema de diseño y composición.]
+
+## Navegación
+
+[Routing y layouts.]
+
+## UI / UX
+
+[Patrones visuales, loading, empty, error, disabled, responsive.]
+
+## Internacionalización
+
+[Convenciones i18n.]
+
+## Accesibilidad
+
+[Reglas mínimas.]
+
+## Errores
+
+[Manejo de errores de UI y API.]
+
+## Referencias
+
+- [ADR relacionado]
+- [Documento relacionado]

docs/arquitectura/testing.md

@@ -0,0 +1,55 @@
+# Estrategia de testing
+
+## Objetivo
+
+Definir qué se prueba, dónde y con qué nivel de profundidad.
+
+## Niveles
+
+### Unitarios
+
+[Qué deben cubrir.]
+
+### Integración
+
+[Qué deben cubrir.]
+
+### E2E
+
+[Qué deben cubrir.]
+
+## Criterios
+
+- Validar comportamiento observable.
+- Evitar depender de detalles internos irrelevantes.
+- Añadir regresión para bugs cuando sea viable.
+- Mantener tests deterministas.
+
+## Fixtures y datos de prueba
+
+[Convenciones.]
+
+## Mocks
+
+[Cuándo y cómo usarlos.]
+
+## Validación por cambio
+
+```text
+tests específicos
+→ tests del módulo
+→ typecheck
+→ lint
+→ integración
+→ E2E
+→ validación global
+```
+
+## Fallos preexistentes
+
+[Cómo distinguirlos y documentarlos.]
+
+## Referencias
+
+- [ADR relacionado]
+- [Documento relacionado]

docs/arquitectura/vision-general.md

@@ -0,0 +1,39 @@
+# Visión general de arquitectura
+
+## Objetivo
+
+Describir la arquitectura general del sistema y sus principales límites.
+
+## Sistema
+
+[Descripción breve del producto y su propósito.]
+
+## Principales módulos o áreas
+
+- [Módulo 1]
+- [Módulo 2]
+- [Módulo 3]
+
+## Relaciones principales
+
+[Describir dependencias y comunicación entre módulos.]
+
+## Límites arquitectónicos
+
+- [Regla 1]
+- [Regla 2]
+- [Regla 3]
+
+## Flujos principales
+
+[Describir los flujos más importantes a alto nivel.]
+
+## Dependencias externas
+
+- [Servicio / API / infraestructura]
+- [Servicio / API / infraestructura]
+
+## Referencias
+
+- [ADR relacionado]
+- [Documento relacionado]

docs/guias/cierre-de-tareas.md

@@ -0,0 +1,124 @@
+# Cierre de tareas
+
+## Objetivo
+
+Definir cuándo una tarea puede considerarse realmente terminada y qué evidencias deben existir antes de cerrarla.
+
+---
+
+## Checklist de cierre
+
+- [ ] El objetivo solicitado está implementado.
+- [ ] El alcance real coincide con el solicitado.
+- [ ] No se han introducido cambios innecesarios.
+- [ ] La solución respeta la arquitectura y los patrones existentes.
+- [ ] Los contratos afectados siguen siendo coherentes.
+- [ ] Se han añadido o actualizado tests cuando corresponde.
+- [ ] Se han ejecutado las validaciones relevantes.
+- [ ] Los errores introducidos por el cambio están resueltos.
+- [ ] Los fallos preexistentes están diferenciados de los nuevos.
+- [ ] Se ha revisado el diff final.
+- [ ] No quedan logs, código temporal, archivos accidentales o secretos.
+- [ ] La documentación se ha actualizado si el cambio lo requiere.
+- [ ] Los riesgos, limitaciones o pendientes están identificados.
+
+---
+
+## Validación
+
+Según el alcance y riesgo del cambio, utilizar:
+
+```text
+tests específicos
+→ tests del módulo
+→ typecheck
+→ lint
+→ integración
+→ E2E
+→ validación global
+```
+
+No es obligatorio ejecutar siempre toda la cadena.
+
+La validación debe ser proporcional al impacto del cambio.
+
+No declarar una validación como superada si no se ha ejecutado correctamente.
+
+---
+
+## Estados finales
+
+### COMPLETA
+
+Usar cuando:
+
+- el objetivo está cumplido;
+- las validaciones necesarias se han ejecutado;
+- no quedan defectos conocidos dentro del alcance.
+
+### PARCIAL
+
+Usar cuando:
+
+- parte de la tarea está completada;
+- faltan puntos del alcance;
+- faltan validaciones relevantes;
+- existe algún bloqueo que impide cerrar completamente.
+
+Debe indicarse exactamente qué queda pendiente.
+
+### BLOQUEADA
+
+Usar cuando no puede avanzarse correctamente por:
+
+- falta de información;
+- dependencia externa;
+- error de entorno;
+- problema del repositorio;
+- decisión pendiente;
+- requisito incompatible.
+
+Debe indicarse qué impide continuar.
+
+---
+
+## No considerar completa una tarea solo porque
+
+- compila;
+- un test concreto pasa;
+- desaparece el error visible;
+- Codex afirma que funciona;
+- el diff parece correcto;
+- no aparecen errores de TypeScript.
+
+El criterio es el cumplimiento verificable del objetivo.
+
+---
+
+## Informe final recomendado
+
+```text
+Estado:
+
+Objetivo:
+
+Cambios realizados:
+
+Archivos principales:
+
+Validaciones ejecutadas:
+
+Resultados:
+
+Problemas preexistentes:
+
+Riesgos o pendientes:
+```
+
+---
+
+## Regla principal
+
+No cerrar una tarea por sensación de finalización.
+
+Cerrar únicamente cuando exista evidencia suficiente de que el resultado esperado funciona y el alcance está controlado.

docs/guias/flujo-chatgpt-codex.md

@@ -0,0 +1,226 @@
+# 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.

docs/guias/organizacion-de-chats.md

@@ -0,0 +1,246 @@
+# 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í.

docs/trabajo/plantilla-estado-actual.md

@@ -0,0 +1,39 @@
+# Estado de trabajo — Título
+
+## Objetivo
+
+[Qué se quiere conseguir.]
+
+## Estado actual
+
+EN CURSO / BLOQUEADA / COMPLETA
+
+## Completado
+
+- [P1]
+- [P2]
+
+## Decisiones vigentes
+
+- [Decisión 1]
+- [Decisión 2]
+
+## Pendiente
+
+- [Pendiente 1]
+- [Pendiente 2]
+
+## Riesgos / bloqueos
+
+- [Riesgo o bloqueo]
+
+## Fuentes de verdad
+
+- `AGENTS.md`
+- [ADR]
+- [Documento]
+- [Código relevante]
+
+## Siguiente paso
+
+[Próxima tarea concreta]