# ESTADO — project.linkedcorp.net

Ultima actualizacion: 2026-09-06
Fase actual: **En produccion** (`https://project.linkedcorp.net`, v1.1.0). MVP fase 1 operativo +
autorregistro/aprobacion/SMTP.

## Como retomar

1. Leer primero el orquestador: `/home/mgonzalez/desarrollo/project-md-templates/leeme_primero.txt`.
2. Leer `AGENTS.md`, `SPEC.md`, `PRODUCCION.md` y este archivo.
3. Backend dev: `cd backend && npm install && npm run dev` (puerto 4019). Requiere `backend/.env`
   (no versionado — completar con las credenciales de la BD dev `project_linkedcorp` en
   `192.168.222.20`; la clave la tiene el usuario).
4. Frontend dev: `cd frontend && npm install && npm run dev` (puerto 5196, proxy `/api` al backend).
5. Login dev: `mgonzalez@linkedcorp.net` / clave `mgonzalez` (rol Administrador). Login de
   **producción**: mismo email, clave fuerte generada por `create-admin.js` (no está en este repo,
   se entregó al usuario al desplegar).
6. Produccion: ver `PRODUCCION.md` y `DEPLOY_WEB.md` para topología, comandos y el flujo de deploy
   de actualizaciones (arquetipo B, dos servicios systemd en `192.168.222.3`).

## Hecho y verificado

### Fase 1 — MVP en desarrollo (2026-09-03)

- Backend completo: auth (JWT + rate limit), users, departments, catalogs, projects (+members),
  activities (+dependencies), subtasks, comments, attachments, notifications, dashboard, audit.
  Recalculo automatico de `progress_pct` verificado.
- Frontend completo: identidad Fluent/Windows adaptada a web — NavigationView, ContentDialog,
  InfoBar, Toast, Flyout, ListView, ComboBox, Treeview, Tabs, Expander. Paginas: Login, Dashboard,
  Proyectos (listado + detalle), Organizacion, Configuracion. i18n es-EC/en-US, tema claro/oscuro.
- Verificacion end-to-end con Playwright sin errores de consola.

### Iteraciones de UI/UX (2026-09-03 al 2026-09-05)

- `DetailPopup`: reemplaza el antipatron "formulario apilado debajo/al costado del listado" en
  TODOS los listados de gestion (Proyectos, Actividades, Departamentos, Usuarios, Miembros,
  Catalogos) — popup de tamaño fijo por instancia, listado inactivo detras, nunca se cierra con
  clic afuera. Regla documentada en `project-md-templates/UI-UX-WINDOWS.md`.
- Bug de stacking corregido: `ContentDialog` ahora usa portal a `document.body` (antes quedaba
  tapado detras de un `DetailPopup` abierto). Jerarquia de z-index: Flyout(100) < DetailPopup(200)
  < ContentDialog(250) < Toast(300).
- Bug de remount corregido: las guardas `if (loading || !data) return <Cargando/>` desmontaban
  TODA la pantalla (y el popup abierto dentro) en cada recarga en segundo plano. Cambiadas a
  `if (!data)` — solo bloquean la carga inicial.
- Bug de clipping corregido: `ComboBox` (y `Flyout`) se posicionan con portal + `position:fixed`
  calculado desde el trigger — antes un ancestro con `overflow:hidden` (Expander, DetailPopup) los
  recortaba. Regla documentada en `UI-UX-WINDOWS.md`.
- "Miembros" del proyecto es su propia pestaña (antes vivia dentro de "Info").
- Logo real de LinkedCorp (`/desarrollo/imgLinkedCorp/logoLinkedCorpTxt(Black).png`) en sidebar y
  login, theme-aware, tamaño duplicado respecto a la primera version.

### Deploy a produccion (2026-09-06)

- BD `project_linkedcorp` creada en `192.168.222.32` (prod) con `crear-db-prod.sh`.
- Servidor `192.168.222.3`: `/opt/apps/project.linkedcorp.net/{source,backend,frontend,storage,logs}`.
- Migraciones aplicadas; catalogos sembrados (`seed-db.js`, sin datos de ejemplo en produccion —
  ver decision abajo); usuario Administrador inicial creado con `create-admin.js`.
- Servicios systemd `project-linkedcorp-backend` (4019) y `project-linkedcorp-frontend` (5196,
  `serve -s dist`), ambos `enabled` + `active`.
- NPM: Proxy Host id 77 → frontend, Custom Location `/api` → backend, SSL Let's Encrypt forzado.
- Verificado end-to-end via curl contra `https://project.linkedcorp.net`: health check, login,
  token valido. Detalle completo en `PRODUCCION.md`.
- **Pendiente no bloqueante**: limpiar `.md` de `/opt/apps/project.linkedcorp.net/source` (paso de
  higiene de `DEPLOY_WEB.md`) — bloqueado por el clasificador de auto-mode del agente durante el
  deploy; requiere ejecutarlo a mano o con autorizacion explicita la proxima vez.

### Autorregistro, aprobación, superadmin y SMTP (2026-09-06)

- Migración `002_registration_and_smtp.sql`: rol `superadmin`, columnas de ciclo de vida en `users`
  (`status`, tokens de verificación/recuperación), tabla `system_settings`. El usuario más antiguo
  (id=1, creado por `create-admin.js` antes de este feature) se promovió solo a `superadmin`.
- `POST /api/auth/register`: primer usuario del sistema → `superadmin` con sesión directa
  (bootstrap); los siguientes → `pending_verification`, correo con enlace de un solo uso (24h).
- `GET /api/auth/verify-email` → `pending_approval` + notificación in-app a `admin`/`superadmin`.
- `admin`/`superadmin` aprueban (`POST /api/users/:id/approve`, eligen rol/departamento) o rechazan
  (`POST /api/users/:id/reject`, borra y audita el email) desde Organización → Usuarios (nuevo badge
  de estado + acciones de fila).
- `login()` da mensaje específico según `status` (pendiente de verificar / pendiente de aprobar)
  en vez del genérico "credenciales inválidas".
- Recuperación de clave (`/olvide-clave` → `/restablecer-clave`): respuesta siempre genérica, token
  de 1 hora de un solo uso.
- SMTP configurable desde Configuración → Correo (SMTP), **solo superadmin** (oculto para el resto);
  clave cifrada AES-256-GCM (`ENCRYPTION_KEY`) en `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 envío tumbe al que lo llama (crítico para `forgot-password`, que debe responder
  genérico siempre).
- Bug real corregido: `React.StrictMode` disparaba el efecto de `VerifyEmailPage` dos veces; la
  segunda llamada (token ya consumido) mostraba "enlace inválido" pese a que la verificación había
  funcionado. Se agregó una guarda por token ya solicitado.
- Deuda técnica de la v1.0.0 resuelta de paso: se reordenó el montaje de rutas en `app.js` —
  `subtasksRoutes` (mount genérico en `/api`) ahora va al final, así ya no intercepta con su
  `requireAuth` interno una request sin token dirigida a un router más específico (`/api/settings`,
  etc.) registrado después.
- Verificado end-to-end en dev con Playwright: registro → correo logueado (modo dev) → login
  rechazado (pendiente de verificar) → verificar correo → login rechazado (pendiente de aprobar) →
  aprobar desde Usuarios → login exitoso → recuperar clave → login con clave nueva → panel SMTP
  visible solo para superadmin. Sin errores de consola.
- **Pendiente**: desplegar esta versión a producción (migración `002` sobre `.32` + redeploy de
  ambos servicios) — ver `DEPLOY_WEB.md`. El superadmin de producción deberá cargar el SMTP real
  desde la UI cuando lo tenga; hasta entonces el sistema sigue en modo dev (logueando enlaces).

## Pendiente (fase 2, sin comprometer lo ya construido)

- Riesgos e Incidencias como modulos propios (hoy: `risk_level` simple en el proyecto).
- Solicitudes/requerimientos formales de otras areas.
- Recursos (servidores/licencias/software), Proveedores, Presupuesto y costos.
- Registro de horas trabajadas detallado (bitacora diaria).
- Reportes exportables (PDF/Excel/CSV) y vista ejecutiva separada.
- Permisos configurables por modulo × accion desde la UI (hoy: roles fijos codificados).
- Notificaciones por email/WhatsApp (hoy: solo in-app).
- Job programado para detectar actividades vencidas/por vencer (hoy: solo se notifica al asignar).
- DatePicker: sigue usando `<input type="date">` nativo (simplificacion deliberada del MVP).
- En producción, crear los departamentos/usuarios reales de la empresa desde la UI (arranca limpia
  a proposito, ver decision abajo).

## Decisiones clave

- MVP simplificado respecto al listado original de 30 areas — detalle en `SPEC.md`.
- Identidad UI/UX: `UI-UX-WINDOWS.md` (Fluent/Windows 11), no la identidad web estandar del grupo.
- Empresa unica (single-company): no existe tabla `companies`.
- Arquetipo de despliegue B (dos servicios separados).
- Produccion arranca sin datos de ejemplo: `seed-db.js` solo carga catalogos universales
  (roles/prioridades/estados/tipos) cuando `NODE_ENV=production`; los departamentos y usuarios de
  ejemplo (TI/Finanzas/RRHH/Comercial, admin con clave=usuario) son SOLO de dev. El admin real de
  produccion se crea con `create-admin.js` (clave fuerte generada, nunca clave=usuario).
- Autorregistro con doble candado (correo + aprobacion admin) — decision explicita del usuario,
  revierte la regla inicial "sin autosuscripcion". El primer usuario del sistema es `superadmin`
  automatico; el resto pasa por verificacion + aprobacion. SMTP vive en BD (cifrado), configurable
  solo por el superadmin desde la UI, no en `.env`.

## Deuda tecnica

- `npm audit`: 3 vulnerabilidades moderadas en `qs`/`body-parser`, transitivas de Express 4.x (sin
  fix no-breaking disponible al 2026-09-06). No critico; revisar cuando Express publique el fix.