Sistema Gubernamental Confidencial

01Contexto

Sistema administrativo y documental diseñado para una unidad con red local aislada. La interfaz y la API pueden operar con recursos locales. La plantilla conserva una fuente externa opcional que no carga sin internet; las funciones centrales no dependen de ella. Identidad institucional, expedientes y topología quedan reservados.

02Problema

El trabajo previo dependía de archivadores físicos y planillas separadas. Eso dificultaba ubicar un expediente, conocer el estado de documentos y reconstruir movimientos. La centralización busca reducir consultas manuales y discrepancias de versión. No hay medición conservada del tiempo previo ni estudio formal de incidentes.

03Mi rol

Diseño y desarrollo full-stack del sistema integral 100% individual y autónomo: arquitectura de API REST en Express 5, modelos de persistencia local en Prisma/SQLite, interfaz SPA local-first con iconos vectoriales auto-alojados, motor de auditoría criptográfica HMAC-SHA256, canal de respaldos cifrados con AES-256-GCM y automatización de despliegue en Windows Server y PCs cliente mediante Windows Service y scripts BAT. No existió delegación en terceros en la arquitectura ni en la programación. La identidad de la institución, la información del personal y el código fuente permanecen reservados.

04Restricciones

La operación prevista usa una red institucional aislada y equipos Windows. No se publican datos de personal, capturas con información real, código reservado, credenciales, direcciones ni detalles de infraestructura. La confidencialidad también limita la comprobación pública del despliegue. El uso sin internet exige activos locales; una fuente tipográfica opcional puede faltar.

05Solución

El panel reúne secciones, personas, estados de checklist, documentos y movimientos. La búsqueda normaliza texto y filtra datos ya cargados en el navegador. El perfil administrador puede modificar y exportar; el perfil de lectura consulta recursos permitidos. Los archivos se almacenan aparte y se entregan tras autenticación. El sistema registra eventos para inspección posterior.

06Arquitectura

Express 5 sirve HTML/CSS/JS y la API. Prisma escribe los registros en SQLite; los documentos se guardan en disco con referencias en la base. Las rutas aplican controles HTTP, identidad y rol antes de la operación. La auditoría HMAC-SHA256 se intenta después de cambios relevantes. Un proceso programado crea copias de base y archivos; el cifrado AES-256-GCM depende de una clave válida. HTTPS depende de certificados configurados. El diagrama representa rutas alternativas de datos y una tarea de respaldo separada.

07Flujo crítico y procesamiento

1. Una persona inicia sesión; el servidor valida la credencial y emite una sesión JWT revocable.

2. En rutas protegidas, Express comprueba la sesión y el rol. Las mutaciones con cuerpo definido pasan por validación Zod.

3. El operador consulta o actualiza personas, checklist y movimientos. Prisma persiste registros en SQLite; la carga de archivos añade comprobación del tipo binario y almacenamiento en disco. La interfaz presenta y filtra lo recibido.

4. Tras una operación relevante, se intenta registrar un evento encadenado. Esa escritura tiene transacción propia: una falla de auditoría no revierte automáticamente el cambio principal.

5. En otro momento, la tarea de respaldo recoge base y archivos. La restauración se ejecuta y comprueba mediante un comando separado.

08Concurrencia e integridad de datos

La cola de auditoría serializa escrituras dentro de un proceso. En la copia aislada, 25 promesas concurrentes produjeron 25 eventos encadenados y una verificación íntegra. No se probaron varios procesos ni carga sostenida. La operación administrativa y la auditoría no son atómicas entre sí. El control de acceso es por rol compartido, no por propiedad individual del expediente; no se afirma aislamiento entre usuarios del mismo rol. Recuperar requiere base y archivos correspondientes.

09Decisiones de ingeniería

SQLite con Prisma mantiene la persistencia en el servidor local sin operar otro motor; el coste es que no hay evidencia de escalado o WAL configurado explícitamente. Separar archivos del registro permite controlar descargas y respaldar ambos, pero exige restaurarlos juntos. El encadenamiento HMAC detecta cambios en eventos conservados, sin hacerlos inmutables. Los scripts Windows automatizan tareas repetibles, con decisiones manuales del operador. Estas razones se reconstruyen del código y las restricciones documentadas: no existen ADR formales que fechen cada elección.

10Seguridad y defensa en profundidad

Se implementan JWT revocables, roles admin/viewer, validación Zod en cuerpos definidos, límites de solicitudes y cabeceras Helmet. Los archivos requieren sesión. La cabecera X-Requested-With es una barrera de solicitud, no un token CSRF. La cadena HMAC-SHA256 detecta alteraciones de eventos conservados con claves conocidas; no prueba que cada operación quedó registrada ni evita su borrado. Los respaldos solo se cifran con una clave válida. Una red aislada reduce exposición externa, sin sustituir controles del puesto o auditoría operativa.

11Pruebas y alcance

Se copió el código fuente a una carpeta temporal separada y se instaló su lockfile. Las pruebas usaron SQLite temporal, usuarios ficticios y loopback. Aprobaron 17/17 pruebas originales en dos archivos: sesión, roles, CRUD, persistencia, exportación de auditoría, carga y descarga, validadores y utilidades. Aprobaron 10/10 comprobaciones adicionales en el código real: 25 escrituras concurrentes de auditoría en un proceso, alteración y borrado de eslabones, rotación de claves y sanitización. Pasaron seis simulaciones BAT y los chequeos de mensajes/filtros. El esquema Prisma fue válido al aportar una URL de prueba; sin ella, la validación inicial falló por configuración. npm audit --omit=dev informó cuatro avisos y salida no limpia. No se ejecutó el despliegue ni el servicio institucional.

12Despliegue y operación

El repositorio prepara el servidor mediante un asistente PowerShell y los clientes mediante BAT. El operador debe decidir parámetros de instalación y certificados; HTTPS depende de su configuración. Hay tarea programada de respaldo, cifrada solo con clave válida; verificar la restauración es un paso aparte. Desarrollé, probé y operé el software localmente en red institucional aislada. Esta comprobación técnica validó una copia de laboratorio separada y no accedió a la instalación institucional.

13Resultado

El sistema implementa expedientes digitales consultables, estados documentales, movimientos y eventos conservados cuya integridad puede verificarse. Estimo cerca de un 60 % menos tiempo de procesamiento y consulta frente al trabajo manual anterior. Es una estimación personal: no conservo línea base, periodo, muestra ni método que permitan auditar ese porcentaje. Tampoco se midió aquí el uso o desempeño de la instalación institucional.

14Evidencia y límites

Implementado: rutas, esquema, interfaz, auditoría, respaldos y scripts en la copia revisada. Comprobado localmente: suite original, arnés adicional, sintaxis, filtros y esquema, siempre con datos ficticios. Simulado: configuración BAT de los puestos. Desarrollo y despliegue: desarrollo 100% individual, despliegue institucional en red aislada y estimación empírica del 60 % de optimización. Pendiente: estado actual del servicio, restauración contemporánea, carga sostenida y resolución de avisos de dependencias. La interfaz web pública del repositorio privado no fue accesible. No se publican expedientes ni código reservado.

15Calidad de software y UX

La interfaz agrupa registros por sección y permite buscar por nombre o grado con normalización de acentos y varios términos. Los filtros de estado y los mensajes de error se comprobaron con herramientas locales; no hubo una sesión de usabilidad con operadores. La muestra siguiente explica la búsqueda sobre filas cargadas y su prueba con datos ficticios. No representa permisos ni expone lógica de seguridad.

16Muestra de código y prueba de ingeniería

Muestra pública aislada de calidad de software y experiencia de usuario (UX): búsqueda por varios términos, sin distinguir acentos ni mayúsculas, sobre filas ya cargadas. Resume un comportamiento visible del cliente; no es el módulo institucional literal ni implementa permisos.

1
// Ejemplo aislado de UX: filtrar filas ya cargadas en el navegador.
2
export function findPeople(rows, query) {
3
  const normalize = (value) => String(value ?? '')
4
    .normalize('NFD')
5
    .replace(/[\u0300-\u036f]/g, '')
6
    .replace(/[^\p{L}\p{N}\s]/gu, '')
7
    .toLowerCase()
8
    .trim();
9
  const terms = normalize(query).split(/\s+/).filter(Boolean);
10
  if (terms.length === 0) return rows;
11
  return rows.filter(({ grade, name }) => {
12
    const visibleText = normalize(`${grade} ${name}`);
13
    return terms.every((term) => visibleText.includes(term));
14
  });
15
}

1
import assert from 'node:assert/strict';
2
3
const rows = [
4
  { grade: 'Inspector', name: 'Ana Pérez' },
5
  { grade: 'Analista', name: 'Mario Soto' },
6
];
7
assert.deepEqual(findPeople(rows, 'PEREZ inspector'), [rows[0]]);
8
assert.deepEqual(findPeople(rows, 'ana inexistente'), []);
9
assert.deepEqual(findPeople(rows, '  '), rows);
10
console.log('3/3 casos de búsqueda sintéticos aprobados');

Se ejecutó exactamente el código mostrado junto con su prueba: 3/3 casos sintéticos aprobados (acentos y orden de términos, ausencia de coincidencias, consulta vacía). No utiliza datos institucionales.