project.linkedcorp.net/ESTADO.md

# ESTADO — project.linkedcorp.net

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

## 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.

## 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).

## 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.
- Ruteo backend: `app.use('/api', subtasksRoutes)` actua como catch-all de cualquier `/api/*` no
  matcheado por un mount mas especifico registrado antes; una request SIN token a una ruta
  inexistente bajo `/api` devuelve 401 "No autenticado" en vez de 404. No afecta ninguna ruta real
  de la app (todas requieren auth de todos modos) — deteccion: `curl .../api/health` (esa ruta no
  existe bajo `/api`, solo en la raiz `/health`). Prolijidad pendiente para fase 2: montar
  `subtasksRoutes` bajo un prefijo mas especifico.