Files
project.linkedcorp.net/SPEC.md
T
Milton Gonzalez 7557dffc52 feat: autorregistro con verificacion de correo + aprobacion, superadmin y SMTP
- POST /api/auth/register: primer usuario del sistema -> superadmin con sesion
  directa (bootstrap, sin correo ni aprobacion); los siguientes quedan
  pending_verification y reciben un correo con enlace de un solo uso (24h).
- GET /api/auth/verify-email: pasa a pending_approval y notifica in-app a los
  admin/superadmin activos.
- admin/superadmin aprueban (POST /api/users/:id/approve, eligen rol y
  departamento) o rechazan (POST /api/users/:id/reject, borra y audita el
  email) desde Organizacion -> Usuarios (nuevo badge de estado + acciones).
- login() da mensaje especifico segun el status de la cuenta en vez del
  generico "credenciales invalidas".
- Recuperacion de clave (forgot/reset-password): respuesta siempre generica,
  token de 1 hora de un solo uso.
- Nuevo modulo settings: SMTP configurable SOLO por superadmin desde
  Configuracion -> Correo (SMTP); clave cifrada AES-256-GCM (ENCRYPTION_KEY)
  en la tabla system_settings, nunca expuesta por la API. sendMail() degrada
  a modo dev (loguea en vez de enviar) si no hay SMTP configurado, y nunca
  deja que un fallo de envio tumbe al que lo llama.
- Migracion 002_registration_and_smtp.sql: rol superadmin, columnas de ciclo
  de vida en users (status, tokens), tabla system_settings, y promueve al
  usuario mas antiguo del sistema a superadmin.
- Fix: React.StrictMode disparaba el efecto de VerifyEmailPage dos veces; la
  segunda llamada (token ya consumido) mostraba "enlace invalido" pese a que
  la verificacion ya habia funcionado. Se agrega una guarda por token.
- Fix (deuda tecnica v1.0.0): se reordena el montaje de rutas en app.js —
  subtasksRoutes (mount generico en /api) va al final, para no interceptar
  con su requireAuth interno una request sin token dirigida a un router mas
  especifico registrado despues.
- Documentacion actualizada: AGENTS.md, SPEC.md, API.md, BASE_DE_DATOS.md,
  CONFIGURACION.md, ESTADO.md, CHANGELOG.md. Version 1.1.0.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-05 23:28:46 -05:00

6.5 KiB
Raw Blame History

SPEC - project.linkedcorp.net

Objetivo

Sistema interno para que una empresa de tamaño medio controle los proyectos y actividades de TI que debe cumplir: qué proyectos hay, quién es responsable de qué, qué está atrasado y qué avance real tiene cada cosa — sin que cargar la información sea tedioso para quien lo usa día a día.

Problema que resuelve

  • Hoy no hay un lugar único donde ver proyectos activos, actividades pendientes/vencidas y de quién es cada una. El Jefe de TI necesita esa foto al entrar, sin perseguir a cada persona.

Usuarios o roles

Rol Alcance
Super Administrador Todo lo de Administrador + configura el SMTP del sistema. Es el usuario más antiguo (bootstrap automático al registrarse el primero)
Administrador Todo, incluida gestión de usuarios/roles/catálogos y aprobar/rechazar registros
Jefe de TI Ve y gestiona todos los proyectos/actividades, aprueba; no administra usuarios
Coordinador / Líder de proyecto Crea/edita los proyectos donde es responsable o miembro, gestiona sus actividades
Colaborador Ve y actualiza lo asignado a él (actividades/subtareas propias), comenta
Consultor Solo lectura en todo

Modulos (MVP)

1. Seguridad

  • Login/logout con JWT, sesión persistida en el navegador.
  • Usuarios: alta/edición directa por el Administrador (nombre, email, rol, departamento, cargo, activo/inactivo) o autorregistro público (/registro) con doble candado: el propio usuario confirma su correo (enlace de un solo uso, vence en 24h) y luego un Administrador/Super Administrador aprueba la cuenta (elige rol y departamento) o la rechaza. El primer usuario que exista en el sistema se vuelve Super Administrador automáticamente, sin correo ni aprobación.
  • Recuperación de clave (/olvide-clave → /restablecer-clave): respuesta siempre genérica (no revela si el correo existe), enlace de un solo uso que vence en 1 hora.
  • Correo saliente (verificación/recuperación): SMTP configurable desde Configuración por el Super Administrador; sin configurar, el sistema sigue funcionando en modo dev (el enlace se loguea en vez de enviarse por correo real).
  • Auditoría central (audit_log): quién hizo qué, sobre qué entidad, cuándo.

2. Organización

  • Departamentos (con sub-área opcional vía parent_id, ej. TI → Desarrollo).
  • Usuarios pertenecen a un departamento y tienen un cargo (texto libre).

3. Proyectos

  • Código autogenerado, nombre, descripción, objetivo, tipo, prioridad, estado, responsable, miembros del equipo, fechas (inicio, fin estimado, fin real), % avance (calculado desde las actividades), departamento solicitante y responsable, nivel de riesgo (bajo/medio/alto), notas.
  • Estados: Planificado, En preparación, En ejecución, En pausa, Bloqueado, Completado, Cancelado.

4. Actividades

  • Código, nombre, descripción, responsable, prioridad, estado, fecha inicio, fecha límite, fecha real de fin, % avance, marca de hito (is_milestone), horas estimadas, dependencias simples ("depende de" otra actividad del mismo proyecto).
  • Estados: Pendiente, En progreso, En revisión, Bloqueada, En espera, Completada, Cancelada.

5. Subtareas

  • Checklist liviano dentro de una actividad: nombre, responsable opcional, hecho/no hecho, fecha límite opcional. Si una actividad tiene subtareas, su avance se calcula solo desde ellas.

6. Dashboard

  • KPIs: proyectos activos, proyectos atrasados, actividades pendientes/vencidas/para hoy, avance promedio. Lista de actividades vencidas y de hoy del usuario.

7. Calendario

  • Vista mensual de actividades por fecha límite (incluye hitos marcados).

8. Gantt

  • Vista de solo lectura por proyecto: barras por actividad (inicio/fin/avance), sin edición directa desde el gráfico en el MVP.

9. Comentarios y adjuntos

  • Hilo de comentarios por proyecto y por actividad.
  • Adjuntar archivos (evidencias) a proyecto o actividad.

10. Notificaciones

  • In-app (campana con contador): asignación de actividad, actividad vencida/por vencer (job diario), cambio de estado relevante.

11. Configuración

  • Catálogos editables por el Administrador: estados de proyecto, estados de actividad, prioridades, tipos de proyecto, departamentos. Vienen con datos semilla — no requieren configuración inicial.
  • Preferencias de interfaz: idioma es-EC/en-US, tema claro/oscuro, apariencia de botones.
  • Correo (SMTP) — visible y editable solo por el Super Administrador: host, puerto, usuario, remitente y clave (la clave se guarda cifrada y nunca se vuelve a mostrar, solo se sabe si está "configurada" o no).

Flujos clave

  1. Administrador crea departamentos y usuarios (con rol y departamento).
  2. Jefe de TI o Coordinador crea un proyecto, asigna miembros, define fechas y prioridad.
  3. Se crean actividades dentro del proyecto (con responsable, fechas, dependencias si aplica).
  4. Cada responsable actualiza el avance de sus actividades/subtareas; el avance del proyecto se recalcula solo.
  5. El Jefe de TI entra al Dashboard y ve de un vistazo activos/atrasados/pendientes/avance.
  6. Vencimientos se marcan automáticamente (🟢 en tiempo / 🟡 próximo a vencer / 🔴 vencido) y generan notificación in-app al responsable.

Reglas funcionales importantes

  • El listado se ve primero; la creación se abre solo con el botón "Nuevo" (regla de UX del grupo).
  • El % de avance de una actividad con subtareas es automático (no editable a mano); sin subtareas, es manual (0-100).
  • El % de avance de un proyecto es el promedio del avance de sus actividades (no editable a mano).
  • Una actividad no puede marcarse "Completada" si depende de otra que no lo está (aviso, no bloqueo duro en el MVP).
  • Todo texto de interfaz sale de i18n (es-EC/en-US), nunca hardcodeado.

Fuera de alcance por ahora (fase 2+)

  • Riesgos e Incidencias como módulos propios (hoy: risk_level/notas en el proyecto).
  • Solicitudes/requerimientos formales de otras áreas.
  • Recursos (servidores/licencias/software), Proveedores, Presupuesto y costos.
  • Registro de horas trabajadas detallado (bitácora diaria).
  • Reportes exportables (PDF/Excel/CSV) y vista ejecutiva separada.
  • Permisos configurables por módulo × acción desde la UI.
  • Notificaciones por email/WhatsApp.
  • Equipos de trabajo como entidad propia multi-proyecto (hoy: miembros por proyecto).

Estado para produccion

  • Completado: en desarrollo (MVP en construcción).
  • Bloqueantes: ninguno conocido; deploy a producción pendiente de validación del MVP en local.