Files
project.linkedcorp.net/SPEC.md
T
Milton Gonzalez 1d22adc42e chore: estructura inicial del MVP
Backend (Express + MariaDB) y frontend (React + Vite, identidad Fluent/Windows) con el
nucleo funcional: seguridad, organizacion, proyectos, actividades, subtareas, dependencias,
dashboard, calendario, gantt, comentarios, adjuntos, notificaciones in-app y catalogos.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-03 08:37:58 -05:00

111 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 |
|---|---|
| Administrador | Todo, incluida gestión de usuarios/roles/catálogos |
| 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 por el Administrador (nombre, email, rol, departamento, cargo, activo/inactivo).
- 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.
## 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.