Grupo N° completar · Integrantes

Cómo se construiría el sistema desde cero y cómo repartirlo en un equipo de 3 o 4 personas. Sirve también como mapa para que cada integrante sepa qué partes del código debe poder explicar en la sustentación.

Cada paso deja algo funcionando y probado, y solo depende de los anteriores.

Paso	Qué se construye	Archivos principales	Resultado verificable
0	Repositorio, módulo Go, .gitignore, .env.example, estructura de carpetas	backend/go.mod, backend/cmd/, backend/internal/	go build ./... compila
1	Configuración y conexión a la base de datos con migraciones	config/, basedatos/, migraciones/0001_esquema_inicial.sql	La API arranca y crea las tablas
2	Contenedores: Dockerfile, docker-compose.yml con PostgreSQL, Redis y Nginx	backend/Dockerfile, docker-compose.yml, nginx/nginx.conf	docker compose up y GET /salud responde
3	Pipeline de CI mínimo (formato, lint y pruebas)	.github/workflows/ci.yml, .golangci.yml	Cada push queda validado desde el inicio
4	Esqueleto de capas: errores tipados, respuestas HTTP, enrutador por módulos	apperr/, handler/respuestas.go, handler/router.go	Formato de error único
5	Usuarios y autenticación: bcrypt, JWT, middleware de roles, administrador inicial	auth/, dominio/usuario.go, servicio/autenticacion.go, servicio/usuarios.go, handler/middleware.go	Login y CRUD de usuarios (RF-01, RF-02)
6	Períodos y espacios (cursos y proyectos), cierre y visibilidad	dominio/espacio.go, servicio/periodos.go, servicio/espacios.go, servicio/acceso.go	RF-03
7	Vinculaciones con las reglas de horas, transacción con bloqueo y rectificación	dominio/vinculacion.go, servicio/vinculaciones.go, repositorio/vinculaciones.go	RF-04, RF-05 (la parte más delicada)
8	Semanas y tareas: semana activa, tardanza, inmutabilidad y adjuntos	dominio/semana.go, dominio/tarea.go, servicio/tareas.go, almacenamiento/	RF-06 a RF-08
9	Seguimiento: personas a cargo, semanas, "sin reporte", consolidado, historial	dominio/seguimiento.go, servicio/seguimiento.go	RF-09 a RF-12
10	Reportes asíncronos: cola, worker, IA, PDF	cola/, cmd/worker/, ia/, pdf/, servicio/reportes.go, servicio/generacion_reportes.go	RF-14
11	Pruebas de integración y colección de Postman en CI	repositorio/integracion_test.go, postman/	Regresiones detectadas automáticamente
12	SonarQube en el pipeline y corrección de hallazgos	sonar-project.properties, etapa del pipeline	Quality Gate aprobado
13	Pruebas de carga y análisis	pruebas-carga/	Capacidad medida
14	Documentación en la Wiki, video, tag y envío	Wiki del repositorio	Entrega cerrada

Por qué este orden:

• La infraestructura va primero (pasos 1 a 3): si el docker compose y el pipeline existen desde el día uno, todo lo demás se integra y se prueba de forma continua, no al final.
• Los módulos siguen las dependencias del modelo de datos: usuario → período → espacio → vinculación → tarea → seguimiento → reporte. Ninguno se puede probar sin el anterior.
• Dentro de cada módulo se avanza de adentro hacia afuera: primero la regla pura en dominio con sus pruebas unitarias, después el servicio con dobles de prueba, luego el repositorio SQL y por último el handler. Así las reglas de negocio se validan antes de existir la base de datos o el HTTP.
• Lo asíncrono va al final porque consume todo lo anterior (tareas y vinculaciones de una semana), pero su infraestructura (Redis) ya estaba en el paso 2.

Completa = después de este paso el requisito queda terminado. Avanza = deja una parte lista, que se termina en un paso posterior. Los códigos RF, RN y RNF son los del enunciado; "Lineamientos" se refiere al documento de lineamientos generales de entrega.

Paso	Completa	Avanza
0 · Estructura	Lineamientos 1.2 (repositorio único y organizado)	RNF-05 mantenibilidad (estructura por paquetes); stack Go; lineamientos 10 (.env fuera del repositorio, solo .env.example)
1 · Configuración y base de datos	Stack PostgreSQL; lineamientos 10 (configuración por variables de entorno); modelo de datos completo (sección 5 de la arquitectura)	RNF-04 persistencia; RNF-06 consistencia con restricciones en la base de datos: estados válidos (RF-07.2), semana que empieza en lunes (RF-08.1), horas positivas, vinculaciones únicas por persona, espacio y rol (RF-04.6)
2 · Contenedores	Entregables Dockerfile y docker-compose.yml; stack Docker, Docker Compose, Nginx y Linux Debian; despliegue local reproducible (07-alcance)	Stack Asynq + Redis (el broker queda listo); arquitectura §4 despliegue
3 · CI mínimo	Entregable "pipeline de GitHub Actions"; 06-pruebas "ejecución automática de pruebas unitarias"	Pruebas unitarias (empiezan con config); RNF-05 (lint obligatorio)
4 · Esqueleto de capas	Formato único de errores y códigos HTTP (400, 401, 403, 404, 409, 413, 422, 500)	RNF-01 backend sólido y RNF-05 (arquitectura en tres capas); RF-06.5 (rechazo de horas decimales en el JSON); RF-01.2 (base para 401 y 403)
5 · Usuarios y autenticación	RF-01.1 a RF-01.3; RF-02.1 a RF-02.3; RF-15.2; RNF-03	RF-12 visibilidad (actor y roles en cada petición)
6 · Períodos y espacios	RF-03.1 a RF-03.7; RN-06 a RN-09	RF-12 y RF-15.1 (visibilidad por profesor y global)
7 · Vinculaciones	RF-04.1 a RF-04.6; RF-05.1 a RF-05.6; RF-15.3; RN-10 a RN-19	RNF-06 (reglas bajo concurrencia)
8 · Semanas y tareas	RF-06.1 a RF-06.9; RF-07.1 y RF-07.2; RF-08.1 a RF-08.5; RN-20 a RN-34	RF-11.2 (solo sus tareas)
9 · Seguimiento	RF-09 (adelantado); RF-10.1 a RF-10.6; RF-11.1 a RF-11.3; RF-12.1 a RF-12.3; RF-15.1; RN-35 a RN-37	—
10 · Reportes asíncronos	RF-14.1 a RF-14.7; RN-41 a RN-46; stack Asynq y LLM; arquitectura §6 flujo asíncrono	Arquitectura §7 (falta elegir el proveedor de IA)
11 · Integración y Postman	Pruebas de integración (DT-01); colección de Postman y Newman (tutoriales de la semana 2)	Pipeline de CI (agrega PostgreSQL y la prueba de punta a punta)
12 · SonarQube	06-pruebas "validación de calidad con SonarQube"	Deuda técnica (DT-10, hallazgos de SonarQube)
13 · Pruebas de carga	Lineamientos 7 (pruebas de carga y análisis de capacidad); deuda técnica DT-08 (medida antes y después de la optimización)	—
14 · Documentación y entrega	Documento de arquitectura; documento de deuda técnica; lineamientos 1.1, 3, 5, 13 y 15 (grupo visible, video, Wiki, Coursera, verificación)	—

La rama paso-a-paso construye el proyecto desde cero hasta la versión final de main en 66 commits pequeños (pasos 0 a 65), sin el historial de main. Cada commit agrega una sola cosa nueva (una configuración, una capa de un módulo o una herramienta), compila, pasa sus pruebas y el lint, y desde el paso 8 lo valida GitHub Actions. El último commit es idéntico a main.

Cómo usarla: cada commit reescribe por completo el README.md para explicar solo ese paso, con la misma estructura:

1. Qué se hizo (tabla de archivos nuevos y modificados).
2. Por qué.
3. Explicación detallada del código, línea a línea donde hace falta.
4. Conceptos de Go que aparecen por primera vez (pensado para quien no conoce el lenguaje).
5. Cómo comprobarlo (comandos y resultado esperado).
6. Pasos para lograr esa versión desde la anterior: comandos y archivos a modificar, en orden.
7. Preparación para las próximas entregas.
8. Requisitos que atiende.

Para recorrerla, abra el enlace de cada paso en la tabla (muestra el repositorio y su README tal como quedaron en ese commit) o los commits de la rama empezando por el más antiguo. Localmente: git checkout <commit> y abrir README.md.

La columna Paso de la guía relaciona cada commit con los 15 pasos de la tabla anterior.

Paso	Qué se agrega	Paso de la guía	Requisitos que atiende
0	Estructura inicial del proyecto	0	Lineamientos 1.2: repositorio único y organizado · Lineamientos 10: sin secretos en el repositorio · Stack: Go
1	Configuración por variables de entorno	1	Lineamientos 10: configuración sin secretos en el código · RF-08.1 (semana de lunes a domingo) · RNF-05 Mantenibilidad
2	Servidor HTTP con Gin y endpoint de salud	1	Stack: Go + Gin · RNF-01: backend sólido · Despliegue reproducible (pasos 5 a 7)
3	Conexión a PostgreSQL	1	Stack: PostgreSQL · RNF-04 Persistencia · Lineamientos 10
4	Migraciones y esquema de la base de datos	1	RNF-04 Persistencia · RNF-06 Consistencia · RF-04.6 Vinculaciones independientes · RF-07.2 Estados de tarea · RF-08.1 Semana de lunes a domingo · Arquitectura §5 Modelo de datos
5	Dockerfile de la API	2	Entregable: Dockerfile · Stack: Linux Debian · RNF-01 / seguridad básica
6	Docker Compose con PostgreSQL y la API	2	Entregable: docker-compose.yml · Stack: Docker Compose, PostgreSQL · Lineamientos 10: reproducibilidad
7	Nginx como proxy inverso	2	Stack: Nginx · Arquitectura §4 Despliegue · RNF-03 / seguridad básica
8	Integración continua con GitHub Actions	3	Entregable: pipeline de GitHub Actions · 06-pruebas: ejecución automática de pruebas unitarias · RNF-05 Mantenibilidad
9	Errores de aplicación	4	RNF-05 Mantenibilidad · RNF-06 Consistencia · RNF-03 Seguridad básica
10	Router por módulos y middleware de registro	4	RNF-05 Mantenibilidad · RNF-01 Backend sólido · Arquitectura §4 (Nginx delante de la API) · Entregas 2 y 4: frontend conectado al backend
11	Dominio de usuarios, roles y validaciones	5	RF-01.3 / RN-01 Múltiples roles · RF-02.1 Crear usuarios (validaciones) · RN-02 Roles por vinculación · RNF-05 Mantenibilidad
12	Contraseñas con bcrypt y tokens JWT	5	RF-01.1 Inicio de sesión local · RF-01.2 Control de acceso por rol · RNF-03 Autenticación local y seguridad básica
13	Repositorio de usuarios	5	RF-02.1 Crear usuarios · RF-02.2 Asignar roles · RF-02.3 Consulta global de usuarios · RNF-06 Consistencia
14	Servicio de autenticación	5	RF-01.1 Inicio de sesión local · RF-02 / RF-15.2 Gestión por el administrador · RNF-03 Seguridad básica
15	Administrador inicial al arrancar	5	RF-15.2 / RF-02 Administración de usuarios · RNF-03 Seguridad básica · Lineamientos 10
16	Middleware de autenticación y roles	5	RF-01.2 Control de acceso por rol · RNF-03 Autenticación local · RN-03 a RN-05 Visibilidad
17	Endpoints de inicio de sesión	5	RF-01.1 Inicio de sesión local · RF-01.2 Control de acceso · RNF-03 Seguridad básica
18	Servicio de gestión de usuarios	5	RF-02.1 Crear usuarios · RF-02.2 Asignar roles · RF-02.3 Consulta global · RF-15.2 Gestión de usuarios por el administrador · RN-04 Cada usuario ve solo lo suyo
19	Endpoints de usuarios	5	RF-02.1 Crear usuarios · RF-02.2 Asignar roles · RF-02.3 Consulta global · RF-01.2 Control de acceso por rol · RF-15.2 Administración
20	Dominio de fechas y semanas	8 (adelantado)	RF-08.1 / RN-29 Semana de lunes a domingo · RF-08.2 Semana activa · RN-32 Tardanza
21	Dominio de períodos académicos	6	RF-03.2 Períodos explícitos · RN-07 Creación solo en la ventana autorizada
22	Repositorio de períodos	6	RF-03.2 Períodos explícitos · RNF-04 Persistencia
23	Servicio de períodos	6	RF-03.2 Períodos académicos · RN-07 Ventana de creación · RF-15 Administración
24	Endpoints de períodos	6	RF-03.2 Períodos académicos · RN-07 Ventana de creación · RF-01.2 Control de acceso
25	Dominio de cursos y proyectos	6	RF-03.1 / RN-06 Cursos y proyectos · RF-03.3 Información mínima · RF-03.5 / RN-08 Cerrar · RF-03.7 / RN-09 Sin registros en espacios cerrados · RF-12 Visibilidad
26	Repositorio de espacios	6	RF-03.1 Crear cursos y proyectos · RF-03.4 / RF-11.1 Consultar sus espacios · RF-03.5 Cerrar · RF-12 Visibilidad
27	Reloj inyectable	6	RF-08.1 / RF-08.2 Semana activa · RNF-05 Mantenibilidad
28	Servicio de espacios	6	RF-03.1 Crear cursos y proyectos · RF-03.2 / RN-07 Período habilitado · RF-03.4 / RF-11.1 Consultar sus espacios · RF-03.5 Cerrar · RF-03.6 Consultar cerrados · RF-12 / RN-03 a RN-05 Visibilidad
29	Endpoints de espacios	6	RF-03.1 a RF-03.3 Crear con información mínima · RF-03.4 / RF-11.1 Consultar sus espacios · RF-03.5 Cerrar · RF-03.6 Consultar cerrados en solo lectura
30	Dominio de vinculaciones y reglas de horas	7	RF-04.1 a RF-04.3 Vinculación con rol y horas · RF-04.5 Rectificación · RF-05.1 a RF-05.5 / RN-14 a RN-18 · RF-05.6 / RN-19 Reglas bloqueantes
31	Repositorio de vinculaciones	7	RF-04.1 a RF-04.3 Vincular · RF-04.5 Rectificación con registro · RF-04.6 Vinculaciones independientes · RF-05.6 / RN-19 Reglas bloqueantes y atómicas
32	Servicio de vinculaciones	7	RF-04.1 a RF-04.3 / RN-10 Vinculación manual por el profesor · RF-04.4 / RN-12 Horas no modificables · RF-04.5 Rectificación · RF-05 / RN-14 a RN-19 Reglas de horas · RN-02 Rol por vinculación · RN-09 Espacio cerrado · RN-04 Visibilidad propia
33	Endpoints de vinculaciones	7	RF-04.1 a RF-04.3 Vincular con rol y horas · RF-04.4 Horas no modificables por el profesor · RF-04.5 Rectificación · RF-05.1 a RF-05.6 Reglas de horas · RF-10.2 / RF-11.1 Listados
34	Dominio de tareas semanales	8	RF-06.3 / RN-22 Información mínima · RF-06.5 / RN-24 Horas enteras · RF-07 / RN-27 y RN-28 Estados · RF-08.2 / RN-30 Semana activa · RF-08.3 Semanas anteriores · RF-08.5 / RN-33 Tardía inmutable · RN-34 Semanas cerradas
35	Repositorio de tareas	8	RF-06.1 a RF-06.3 Registrar tareas · RF-06.4 Adjuntos (metadatos) · RF-06.7 / RF-06.8 Editar y eliminar · RF-08.5 / RN-33 Tardía inmutable · RF-11.2 / RF-12 Visibilidad
36	Servicio de tareas	8	RF-06.1, RF-06.2, RF-06.6 · RF-06.7, RF-06.8 · RF-08.1 a RF-08.5 · RN-09, RN-21, RN-26, RN-30, RN-32 a RN-34 · RF-10.5, RF-11.2, RF-12
37	Endpoints de tareas	8	RF-06.1 a RF-06.3, RF-06.5, RF-06.6 · RF-06.7 / RF-06.8 · RF-08.1 a RF-08.5 · RF-10.5 / RF-11.2 / RF-12
38	Almacenamiento local de archivos	8	RF-06.4 / RN-23 Evidencias · RF-14.5 Almacenar los PDF · Stack: volúmenes de archivos · RNF-03 Seguridad básica
39	Adjuntos en el servicio de tareas	8	RF-06.4 / RN-23 Evidencias · RF-08.5 / RN-33 · RNF-03 Seguridad básica · RNF-06 Consistencia
40	Endpoints de adjuntos	8	RF-06.4 / RN-23 Evidencias · RF-08.5 / RN-33 · RNF-03 Seguridad básica
41	Dominio del seguimiento semanal	9	RF-09 / RN-35 a RN-37 Sin reporte (adelantado) · RF-10.1 / RF-10.2 Personas a cargo · RF-10.3 Detalle semanal · RF-10.4 Consolidado · RF-10.6 Horas reportadas frente a contratadas
42	Consulta de tareas por vinculaciones	9	RF-10.3 / RF-10.4 Detalle y consolidado · RF-10.1 Personas a cargo · RNF-01 Backend sólido
43	Servicio de seguimiento	9	RF-10.1 / RF-10.2 Personas a cargo · RF-10.3 / RF-10.6 Detalle semanal · RF-10.4 Consolidado · RF-11.3 Historial propio · RF-09 Sin reporte · RF-12 / RN-03 a RN-05 Visibilidad
44	Endpoints de seguimiento	9	RF-10.1 / RF-10.2 Personas a cargo y sus vinculaciones · RF-10.3 / RF-10.6 Detalle semanal con horas · RF-10.4 Consolidado · RF-11.3 Historial propio · RF-09 Sin reporte · RF-12 Visibilidad
45	Dominio de lotes y reportes	10	RF-14.1 Ejecución por lotes · RF-14.2 Un reporte por persona · RF-14.3 / RN-43 Solo insumos permitidos · RF-14.5 / RF-14.6 Almacenar y descargar · RF-14.7 Una semana concreta
46	Repositorio de reportes	10	RF-14.1 Ejecución por lotes · RF-14.2 Un reporte por persona · RF-14.3 / RN-43 Insumos permitidos · RF-14.5 Almacenar · RF-14.7 Semana concreta
47	Cola de tareas con Asynq y Redis	10	Stack: Asynq + Redis · RF-14.1 / RN-41 Generación por lotes, asíncrona · RNF-01 Backend sólido
48	Servicio de reportes	10	RF-14.1 / RN-41 Ejecución manual por lotes · RF-14.6 Descarga posterior · RF-14.7 Semana concreta · RN-03 / RN-05 Visibilidad
49	Endpoints de reportes	10	RF-14.1 Ejecución manual por lotes · RF-14.6 Descarga posterior · RF-14.7 Semana concreta · Stack: Asynq + Redis · RN-03 / RN-05 Visibilidad
50	Generador de PDF	10	RF-14.4 / RN-42 PDF individual · RN-46 Sintetizar, no evaluar · RF-10.6 Horas contratadas frente a reportadas
51	Interfaz de IA, modo simulado y prompt	10	RF-14 Resumen con IA · RF-14.3 / RN-43 Solo insumos permitidos · RN-46 Sintetizar, no evaluar · Stack: LLM
52	Proveedor de IA compatible con OpenAI	10	RF-14 Resumen con IA · Stack: LLM en la nube o local · RNF-01 Backend sólido
53	Proveedor de IA Anthropic	10	RF-14 Resumen con IA · RN-43 / RN-46 · RNF-01 Backend sólido
54	Generación asíncrona de reportes	10	RF-14.2 Un reporte por persona · RF-14.3 Insumos permitidos · RF-14.4 / RF-14.5 PDF almacenado · RN-46 No inventar ni evaluar · RNF-01 Backend sólido
55	Worker	10	RF-14.1 a RF-14.7 · Stack: Asynq + Redis, Docker Compose · Arquitectura §6 Flujo asíncrono
56	Panel de la cola	10	Stack: Asynq · Sustentación (lineamientos §3)
57	Modelo local con Ollama	10	Stack: LLM pequeño (local o en la nube) · RF-14.3 / privacidad
58	Pruebas de integración de la capa de datos	11	06-pruebas: pruebas automáticas en el pipeline · RF-05.6 / RN-19 Reglas atómicas · RNF-06 Consistencia · Deuda técnica DT-01
59	Datos de demostración	14 (para el video)	Sustentación en video (lineamientos §3) · RF-09 / RF-10 · RF-05
60	Colección de Postman	11	Colección de Postman (entregables de la Entrega 1) · RF-01 a RF-12 · Reglas de negocio (RN-04, RN-07, RN-12, RN-14, RN-17, RN-24, RN-27, RN-32 a RN-34)
61	Newman en la integración continua	11	Despliegue con Docker Compose verificable · Colección de Postman · Integración continua
62	SonarQube	12	Reporte de SonarQube del backend (entregables de la Entrega 1) · Calidad del código
63	Scripts de pruebas de carga	13	Análisis de capacidad (Entrega 1) · Métricas: throughput, tiempos de respuesta, errores, CPU y memoria
64	Resultados de las pruebas de carga	13	Análisis de capacidad: resultados y evidencias (Entrega 1) · Comparación entre entregas
65	README final	14	Documentación del proyecto (README de main)

Notas:

• Los archivos que en main crecen con los pasos (main.go, config.go, router.go, Dockerfile, docker-compose.yml, .env.example, ci.yml, Makefile) aparecen en versión parcial: cada paso solo agrega lo que ese paso usa.
• Dentro de cada módulo el orden es siempre el mismo: dominio (reglas puras y sus pruebas) → repositorio (SQL) → servicio (casos de uso, con dobles de prueba) → endpoints (handler y router).
• En el paso 60 se corrigió la colección de Postman: calcula las fechas en hora de Bogotá. Antes fallaba los domingos desde las 19:00 (hora de Colombia), porque en UTC ya era lunes. La corrección también se aplicó en main.
• Revisión de limpieza y preparación (12 de octubre). Se revisó todo el código y se integraron estos cambios en el paso donde corresponde cada uno (también están en main):
  • Paso 10: CORS configurable con CORS_ORIGENES, listo para el frontend de la Entrega 2.
  • Paso 32: constante LongitudMaxMotivo en lugar de un número suelto.
  • Pasos 38, 39 y 55: almacenamiento.Nuevo elige el almacenamiento según ALMACENAMIENTO_TIPO; agregar Cloud Storage será un archivo y un caso más.
  • Paso 40: quitarTildes sin duplicación y leerPeticionTarea, que simplifica la creación de tareas.
  • Pasos 42 y 43: optimización de la vista del profesor (DT-08): unas 3 veces más peticiones por segundo, medido.
  • Paso 57: Ollama probado en vivo; se recomienda qwen2.5:3b.
  • Paso 58: prueba de integración de la consulta del seguimiento.
  • Paso 64: pruebas de carga repetidas con el código final y comparación antes/después.

La arquitectura por módulos permite repartir por funcionalidad completa (vertical): cada persona es dueña de sus módulos en las tres capas, con sus pruebas. Repartir por capas (uno hace handlers, otro SQL) genera bloqueos constantes y nadie puede explicar un caso de uso completo.

Integrante	Responsabilidad	Código	Documentación
A – Plataforma y calidad	Configuración, migraciones, Docker, Nginx, pipeline, SonarQube, Postman	config/, basedatos/, Dockerfile, docker-compose.yml, nginx/, .github/, postman/	Arquitectura §4 Despliegue, deuda DT-10
B – Acceso y estructura académica	Autenticación, usuarios, roles, períodos, espacios, visibilidad	auth/, servicio/autenticacion.go, usuarios.go, periodos.go, espacios.go, acceso.go, handler/middleware.go	Arquitectura §10 Seguridad, DT-04, DT-05
C – Reglas de carga y tareas	Vinculaciones (reglas de horas y concurrencia), semanas, tareas, adjuntos, seguimiento	dominio/vinculacion.go, semana.go, tarea.go, seguimiento.go y sus servicios y repositorios	Arquitectura §5 Datos y §9 Reglas temporales, DT-07, DT-08
D – Reportes asíncronos y capacidad	Cola, worker, IA, PDF, pruebas de carga	cola/, cmd/worker/, ia/, pdf/, servicio/reportes.go, generacion_reportes.go, pruebas-carga/	Arquitectura §6 y §7, página de pruebas de carga, DT-02, DT-03, DT-06

Con 3 integrantes: A asume también los reportes asíncronos (la cola es infraestructura) y D reparte las pruebas de carga entre todos: cada uno ejecuta y analiza el escenario de su módulo.

• Arquitectura §1 a §3 (problema, estilo y componentes): en conjunto, al inicio. Fija los contratos entre módulos.
• Revisión cruzada: todo cambio entra por pull request con aprobación de otro integrante y el pipeline en verde.
• Video: cada integrante presenta su parte (asegura que todos sustenten).
• Deuda técnica: cada uno registra la de sus módulos; A consolida la tabla final.

Momento	Todos	A	B	C	D
Semana 1, inicio	Leer el enunciado, modelo de datos, arquitectura inicial, convenciones	Esqueleto, compose, CI	Autenticación y usuarios	Dominio de semanas y reglas de horas (sin base de datos)	Cola, worker y prompt con datos simulados
Semana 1, cierre	Revisión de PR	Migraciones completas, Postman base	Períodos y espacios	Vinculaciones en SQL con bloqueo	IA configurable y PDF
Semana 2, inicio	Integración de módulos	SonarQube, e2e en CI	Visibilidad en todos los endpoints	Tareas, adjuntos y seguimiento	Lotes de reportes de punta a punta
Semana 2, cierre	Wiki, video, tag entrega-1, Coursera	Despliegue y calidad en la Wiki	Seguridad	Reglas en la Wiki	Pruebas de carga y su análisis

1. El esquema SQL inicial completo (evita conflictos entre migraciones).
2. El formato de error (apperr → {"error", "mensaje"}) y los códigos HTTP.
3. El usuario autenticado (dominio.Usuario en el contexto de Gin) y la función de visibilidad por rol.
4. Las interfaces que cada servicio declara para sus repositorios: permiten trabajar en paralelo con dobles de prueba antes de que exista el SQL.