workspace/projects/gamilit/orchestration/agentes/tech-leader/PLAN-ANALISIS-FLUJO-USUARIOS-2025-12-15.md

PLAN DE ANÁLISIS - FLUJO DE CREACIÓN DE USUARIOS

Tech-Leader: Claude Opus 4.5 Proyecto: GAMILIT Fecha: 2025-12-15 Tarea: Análisis detallado y adaptación del flujo de creación de usuarios

---

1. RESUMEN EJECUTIVO

Objetivo Principal

Analizar y adaptar el flujo de creación de usuarios para implementar:

1. Clase genérica "por asignar" para nuevos estudiantes
2. Institución default para organización inicial
3. Corrección del registro de último ingreso en admin/users

Hallazgos Iniciales

Componente	Estado	Observación
Classroom Default	✅ EXISTE	UUID: 00000000-0000-0000-0000-000000000001, code: DEFAULT
School Default	❌ NO EXISTE	Solo hay escuelas demo, ninguna marcada como default
Función assign_default_classroom	✅ EXISTE	Funciona correctamente
Trigger asignación	✅ EXISTE	trg_assign_default_classroom AFTER INSERT en profiles
AuthService.register	❌ NO IMPLEMENTADO	Método lanza excepción
last_login actualización	⚠️ PARCIAL	Campos existen pero no se actualizan
Institución Default	❌ NO EXISTE	No hay concepto de institución default

---

2. ARQUITECTURA ACTUAL

2.1 Flujo de Registro de Usuario (Actual)

┌─────────────────────────────────────────────────────────────────┐
│                    FLUJO ACTUAL (INCOMPLETO)                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Frontend envía datos de registro                            │
│     ↓                                                           │
│  2. AuthService.register() → ❌ throws Error                    │
│     (NO IMPLEMENTADO)                                           │
│     ↓                                                           │
│  3. Si se creara el profile:                                    │
│     • trg_set_default_tenant (BEFORE INSERT)                    │
│     • INSERT profile                                            │
│     • trg_initialize_user_stats (AFTER INSERT)                  │
│     • trg_assign_default_classroom (AFTER INSERT) ← ✅ EXISTE   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

2.2 Tablas Involucradas

Tabla	Schema	Propósito
auth.users	auth	Credenciales, last_sign_in_at
auth_management.profiles	auth_management	Perfil de usuario, role, school_id
auth_management.tenants	auth_management	Multi-tenancy
social_features.schools	social_features	Instituciones/Escuelas
social_features.classrooms	social_features	Aulas
social_features.classroom_members	social_features	Membresía estudiante-aula

2.3 Usuarios Default Existentes (Seeds)

Email	UUID	Rol	Propósito
admin@gamilit.com	aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa	super_admin	Admin principal
teacher@gamilit.com	bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb	admin_teacher	Maestro default
teacher2@gamilit.com	-	admin_teacher	Maestro secundario
student@gamilit.com	cccccccc-cccc-cccc-cccc-cccccccccccc	student	Estudiante demo 1

2.4 Classroom Default (Existente)

id: '00000000-0000-0000-0000-000000000001'
name: 'Sin Asignar - Aula Default'
code: 'DEFAULT'
school_id: '50000000-0000-0000-0000-000000000001'  # Marie Curie
teacher_id: 'bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb'  # teacher@gamilit.com
metadata:
  is_default: true
  system_classroom: true
  auto_assignment: true

---

3. PLAN DE ANÁLISIS (FASE 2)

3.1 Componentes a Analizar

A. Database Layer

• DDL de social_features.schools - verificar campo is_default
• DDL de social_features.classrooms - validar metadata schema
• Seeds de escuelas - verificar si hay escuela default
• Función gamilit.assign_default_classroom() - revisar lógica
• Triggers de inicialización - orden de ejecución

B. Backend Layer

• AuthService.register() - estado de implementación
• ProfilesService - métodos de creación
• UsersService - si existe
• Endpoints de /auth/register
• Actualización de last_sign_in_at

C. Frontend Layer

• AdminUsersPage.tsx - mostrar último ingreso
• useUserManagement.ts - hook de gestión
• API types para SystemUser
• Formato de fechas para lastLogin

D. API Contracts

• Response de GET /admin/users
• Mapeo de campos last_sign_in_at → lastLogin

---

4. ISSUES IDENTIFICADOS

4.1 P0 - Críticos

ID	Issue	Ubicación	Impacto
P0-001	AuthService.register() no implementado	auth.service.ts:48	Bloquea registro de nuevos usuarios
P0-002	last_sign_in_at no se actualiza	Backend auth	Admin ve "Nunca" en último acceso
P0-003	No existe School Default	Seeds	Nuevos usuarios no tienen school_id

4.2 P1 - Importantes

ID	Issue	Ubicación	Impacto
P1-001	Campo school_id en profiles es opcional	profiles.sql:34	Usuarios sin escuela asignada
P1-002	No hay institución default para admin	Arquitectura	Admin sin escuela asociada
P1-003	Mapping lastLogin incorrecto	Frontend types	UI muestra "Nunca" siempre

4.3 P2 - Mejoras

ID	Issue	Ubicación	Impacto
P2-001	Reasignación de estudiantes entre aulas	Admin UI	UX mejorable
P2-002	Reasignación de escuelas	Admin UI	UX mejorable

---

5. DELEGACIONES PLANIFICADAS

5.1 ARCHITECTURE-ANALYST

Objetivo: Análisis profundo de dependencias y diseño de solución

Tareas:

1. Validar arquitectura actual de flujo de usuarios
2. Diseñar solución para School Default
3. Mapear dependencias entre tablas
4. Proponer estructura de seed para institución default

5.2 DATABASE (después de análisis)

Objetivo: Implementación de cambios DDL/Seeds

Tareas:

1. Crear seed de School Default si no existe
2. Verificar/corregir función assign_default_classroom
3. Validar triggers de inicialización

5.3 BACKEND (después de DB)

Objetivo: Implementación de servicios

Tareas:

1. Implementar/corregir AuthService.register()
2. Actualizar last_sign_in_at en login
3. Mapear respuesta de API users

5.4 FRONTEND (después de Backend)

Objetivo: Correcciones de UI

Tareas:

1. Corregir mapping de lastLogin en AdminUsersPage
2. Verificar tipos de SystemUser

---

6. PREGUNTAS DE CLARIFICACIÓN

Antes de proceder a FASE 2, necesito clarificar:

1. School Default: ¿Crear una nueva escuela "Sistema - Por Asignar" o usar Marie Curie como default?

2. Admin School: ¿El admin debe tener una escuela asignada o es correcta que sea NULL?

3. Flujo OAuth: ¿Los usuarios que se registran vía OAuth también deben asignarse al classroom default?

4. Reasignación masiva: ¿Se requiere funcionalidad para mover todos los estudiantes de una aula a otra?

---

7. SIGUIENTE PASO

FASE 2: Ejecución de Análisis

• Delegar a ARCHITECTURE-ANALYST para análisis profundo
• Ejecutar análisis con subagentes especializados
• Consolidar hallazgos en reporte

---

Fin del Plan de Análisis - FASE 1 Documento generado por Tech-Leader - 2025-12-15