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

2.6 KiB

Raw Permalink Blame History

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:

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

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.

2.6 KiB Raw Permalink Blame History