Secciones públicas /tools y /notes con artículos técnicos y mocks de herramientas internas.

Listado público de certificaciones vigentes/expiradas y línea de tiempo de hitos educativos.

JSON-LD, sitemap, RSS, notificación IndexNow y manifest de PWA en cada publicación.

El visitante descarga el CV desde /contact mediante un token de un solo uso (ventana de 5 min) emitido tras capturar una huella de dispositivo.

Página /paginas-web dirigida a negocios locales y emprendedores no técnicos: tres planes con precio visible, preguntas frecuentes y contacto por WhatsApp o formulario.

Las páginas públicas de marca, las notas técnicas, el LAB y el contenido de proyectos existen bajo el prefijo /en con contenido traducido, selector de idioma que conserva la página actual y hreflang recíproco. El español sigue siendo el idioma canónico, sin prefijo.

Página /capacitacion-ia con los programas de formación publicados desde el panel (formato, nivel, duración, objetivos de aprendizaje, temario desplegable y nota de precio), el proceso de trabajo en cuatro pasos, preguntas frecuentes y contacto por WhatsApp o formulario.

Repositorio general de guías, prompts, plantillas, checklists y presentaciones en /capacitacion, con detalle por recurso en /capacitacion/[slug], contenido en markdown renderizado en el servidor y contador de lecturas.

Los recursos marcados "con código" solo aparecen a quien canjeó en /capacitacion/acceso el código que se dicta al cerrar una capacitación; el canje entrega un pase firmado por 30 días, sin correo ni cuenta.

El mismo cuestionario antes y después de la formación, entregado por enlace firmado por cohorte, con informe de delta por grupo y por tema.

La página /automatizaciones publica lo que corre solo: los workflows de GitHub Actions con el resultado de su última corrida en main, las tareas programadas con horario, origen y qué se pierde si dejan de correr, y los automatismos que dispara el propio tráfico.

Cualquier visitante escribe un dominio y recibe doce diagnósticos en vivo contra ese sitio: alcanzabilidad, certificado TLS, redirección a HTTPS, cabeceras de seguridad, DNS, vencimiento del dominio por RDAP, robots.txt, sitemap.xml, meta SEO, peso y recursos de la página, Lighthouse vía PageSpeed Insights y una heurística de accesibilidad. Cada prueba llega por streaming en cuanto termina, con estado (pass/warn/fail/info), resumen y detalle.

Demostración pública en /lab/fingerprint: se crea una sala con un enlace corto y su QR, cada dispositivo que entra aporta su huella (señales del recolector propio más el hash de FingerprintJS para contrastar precisión) y el tablero /lab/fingerprint/[room]/board las va mostrando en vivo, con los bits de entropía de cada una y el contador de revisitas que enseña lo que hace de esto una demostración y no una lámina: volver en incógnito o borrando cookies no estrena dispositivo, incrementa el contador del mismo.

La portada se comporta como un instrumento vivo: un terreno de isolíneas en WebGL que levanta un pico bajo el cursor, emite un pulso con cada clic y se aplana al hacer scroll hasta continuar en la cinta de señales; un índice cinético de proyectos con ventana flotante y portadas generativas para los que no tienen captura; el proceso de trabajo como un pipeline de CI que se recorre con el scroll; tarjetas de expertise con pantallas animadas (grafo de servicios que escala, cascada de red con el LCP, suite de tests corriendo); la huella dactilar del visitante dibujada en la sección del laboratorio; y un bento con luz que sigue al cursor, odómetros y la hora de Bogotá en vivo.

El panel público de ingeniería deja de ser una rejilla de tarjetas con el detalle escondido tras el cursor. El hero es un osciloscopio que mide LA VISITA ACTUAL con las mismas APIs de la telemetría del sitio (web-vitals, Navigation y Resource Timing): repite la carga como una traza de bytes recibidos con sus fases (red, servidor, descarga, pintado) y las marcas de TTFB, FCP y LCP, la ubica frente a la distribución de los visitantes reales ("más rápida que el X % de las visitas") y mide el INP con la primera interacción. Debajo, cinco medidores con el histograma real de cada métrica, la aguja del p75 y el punto de la visita; el último run del CI recorrido etapa por etapa (push, tests y build, despliegue, verificación en producción, con el rollback automático a la vista) junto a la tira de los últimos 20 runs; la disponibilidad como una tira de 90 días, un día por barra, con los huecos sin datos visibles y lectura por día bajo el cursor; y enlaces a las fuentes con vistas previas vivas.

La vitrina pública de seguridad deja de ser texto y tarjetas iguales. El hero es un "filtro de capas": las peticiones cruzan de izquierda a derecha las capas de defensa del sitio y cada una termina donde el sistema la dejaría de verdad. Todas son grises hasta el clasificador (una petición hostil no se distingue hasta que alguien la inspecciona); ahí la hostil se marca y, según su categoría, se frena (lista de bloqueo y límite de tasa), cae a la bitácora o queda atrapada en un señuelo, mientras el cron horario barre la bitácora y devuelve bloqueos al clasificador. Un punto "tú" cruza limpio hasta el sitio, el cursor lee cada punto (categoría y destino) con el tiempo casi detenido, y un clic lanza un sondeo simulado que se ve detectado y registrado. Debajo, el panel en vivo con cifras que ruedan, barras con el mismo código de color del filtro y la tendencia levantándose detrás de un barrido; los hallazgos corregidos como una línea de commits que, al bajar, cierra cada hallazgo (el problema se tacha, la corrección se destapa y el commit real se enciende); los controles vigentes con una demostración cada uno (firma que rechaza un evento alterado, secreto cifrado en el formato real de la bóveda, sesión revalidada en cada petición, inyección que viaja como parámetro); y la metodología como tres pasos unidos.

La página de herramientas deja de ser siete tarjetas iguales con maquetas quietas. El hero es un "circuito de operación": el sitio con sus tres franjas (middleware, rutas, /admin), lo que llega desde fuera (tráfico, despliegues) y lo que lo vigila y avisa (monitor, celular, portal del cliente), unidos solo por los cables que existen en el código. Sobre ese mapa corren en bucle cuatro escenarios con su bitácora: un experimento de caos (el flag rompe /tienda, el monitor lo detecta, la alerta llega al celular, /status publica el incidente y el pánico lo apaga), un deploy roto (el health check contra el sitio real falla y el pipeline revierte solo), un sondeo hostil (gris hasta que el clasificador lo inspecciona, límite de tasa, frenado antes de las rutas, bloqueo escalonado y alerta por anomalía) y un proyecto nuevo (un servicio mueve el P&L y deja su credencial cifrada, y el hito llega al portal). Cada estación de herramienta lleva a su caso. Debajo, en escritorio, el texto de cada caso corre a la izquierda y una ventana fija a la derecha muestra la herramienta del caso que se está leyendo, haciendo lo que su texto afirma: el monitor ve una página que responde 200 con el contenido equivocado y el presupuesto de error baja, el P&L normaliza ciclos y monedas y recalcula el margen al pagarse una factura, el seguimiento cierra lo interno en la vista del cliente, la bóveda cifra y rechaza un byte alterado, el pipeline revierte al último deploy sano, el caos rompe /tienda sin tocar /admin y el SIEM escala el bloqueo de un origen reincidente mientras el detector marca una anomalía. En móvil cada escena va dentro de su caso, bajo el título.

El laboratorio deja de ser una lista de tarjetas con cifras. El hero es un "banco de ensayo": tres emisores (navegador, pasarela, motor de caos), las cinco defensas de la pasarela (llave única, evento ya visto, transición legal, versión, transacción) y la máquina de estados de un pago. Sobre ese banco se reproducen los cinco experimentos que registra lab_experiments (doble clic, webhook duplicado, webhook tardío, carrera aprobado/rechazado y caída de BD a mitad de transacción): cada evento viaja hasta la defensa que lo decide, las transiciones aplicadas se dibujan en verde, las negadas en rojo con ✕ y las que nunca hicieron COMMIT en ámbar, y el registro (pagos, estado, versión, eventos) cambia al ritmo del experimento. El sello final lo ponen las corridas reales, no la reproducción. Debajo, los KPIs forman una sola franja con odómetros; el pipeline es una pista por corrida que una luz recorre etapa por etapa (calidad, deploy, health check) y los rollbacks vuelven por su desvío; los hallazgos de seguridad arrancan todos en "abiertos" y viajan a donde terminaron; las pruebas de carga dibujan la escalera real de la última corrida de estrés (ofrecido, servido sin error y p95 por escalón, dónde se rompe, qué sostiene y cuánto tardó en volver); cada contador de la pasarela nombra la defensa que lo neutralizó con el mismo número del banco; y el analizador de sitios enseña sus 12 pruebas corriendo en paralelo y llegando en desorden.

El índice de notas deja de ser una columna de tarjetas iguales. El hero pone al lado del titular "Decisiones, no tutoriales" una ficha que recorre las decisiones de las notas reales: aparece el problema, la opción descartada se tacha y la elegida se escribe letra a letra, sobre el mapa generativo de la nota (isolíneas sembradas con su slug, el lenguaje de la portada) que se transforma de una nota a la siguiente; avanza sola, se pausa al apuntarla o enfocarla y tiene botón de pausa y controles. Debajo, una bitácora por meses con un riel que se enciende al bajar, el mismo mapa de cada nota como miniatura, tiempo de lectura y filtros por cuatro familias temáticas (seguridad, operación, calidad, arquitectura) que reacomodan la lista y quedan en la URL (?tema=). Cada artículo gana su mapa en la cabecera, "la decisión, en corto" antes del texto, un índice lateral que marca la sección que se lee con los minutos que quedan (barra superior en móvil) y tres notas relacionadas por enlaces reales y etiquetas.

El registro de actividad deja de ser cuatro cifras, un gráfico de barras y una lista. El hero es un "reloj de sesiones": una fila por día de los últimos 30 (hora de Colombia) y 24 horas de ancho, con cada commit como un punto en su hora (cian los públicos, gris y sin nombre los privados). Un cabezal recorre el mes de arriba abajo: los commits de cada día caen en su hora y enseguida los que quedan a menos de 90 min se funden en una sesión, dibujada desde 30 min antes del primero, mientras las cifras de arriba (trabajo profundo de 7 y 30 días, commits) se van sumando con lo que se dibuja; al terminar, la racha se enciende día a día y sube el histograma de commits por hora del día. Cada cifra es un interruptor que ilumina en el reloj lo que cuenta (la semana desde su hora exacta, las sesiones del mes, los commits o los días de la racha), y bajo el cursor (o el dedo) se lee el commit con su mensaje, la sesión con su duración o el día. Debajo, la bitácora: una barra de commits del mes por proyecto que es también su filtro (lo privado, un solo segmento sin nombre), filtros por tipo de cambio leídos del prefijo del commit, días con su franja de sesiones y enlace a cada commit en GitHub, y los commits nuevos entran arriba solos mientras la página sigue abierta.

La página deja de ser tres listados de tarjetas. El hero es una "partitura" de las tareas programadas: un renglón por job y una marca por cada ejecución real de las últimas 24 h, con el pulso de cada 5 min como textura, los diarios como notas sobre su hora declarada y cada silencio mayor a lo tolerado como un tramo teñido con su duración. Apuntar un renglón lee la corrida, el hueco o el resumen del job. Un simulacro reproduce el corte del 7 sep 2026 sobre los datos de hoy: las tareas del programador externo se callan, los silencios crecen y el aviso llega cuando el vigilante de verdad llegaría (con la corrida diaria de uptime-check que lo hospeda), con el texto real del push. Los workflows se leen con un selector de eventos (push, pull request, domingo, a mano) que despierta solo los que declara cada YAML, con las etapas de CI y la verificación de tres chequeos que solo corre en push a main; la insignia de cada fila es la última corrida real en GitHub. La tabla de crons suma un medidor de silencio consumido y sigue contando con el reloj de quien mira. Los seis automatismos del producto tienen cada uno su escena ilustrativa. De paso corrige que siete de once tareas salieran "sin registro": la página lee ahora un rango de 48 h de la bitácora en vez de las últimas 150 filas (~9 h).

La entrada del laboratorio deja de ser una lista con una casilla. El hero pone junto al titular la huella dactilar del visitante, dibujada con el shader de la portada, y la lee en dos tiempos: al cargar solo lo que cualquier sitio lee sin pedir nada (pantalla, zona horaria, idioma, núcleos, plataforma, vendor de la GPU) y, al marcar el consentimiento, se suman canvas, audio y fuentes y la misma huella se transforma en la completa; si se retira el sí, vuelve a la parcial. Cada línea de "qué vamos a recolectar" muestra sus señales como puntos (llenos cuando ya se leyeron) y su estado (leída, n de m, espera tu sí, solo dentro de la sala), y un medidor de 38 marcas enciende los bits leídos con el "1 en N" que se deduce. En el tablero cada dispositivo que entra a la sala trae su huella en SVG, dibujada cresta a cresta desde su identificador; cuando el mismo dispositivo vuelve, una línea de lectura barre su huella, las crestas pasan a ember y la tarjeta dice "reconocido de nuevo" mientras sube el contador de revisitas. Con la sala vacía, una huella fantasma con la línea de lectura esperando. El cierre "cómo defenderte" es una comprobación con cuatro dispositivos de ejemplo: sin defensa (cuatro huellas distintas), incógnito (la cookie se borra y las huellas no cambian), Tor Browser (las cuatro convergen en la misma) y Firefox con resistFingerprinting (la rejilla de precisión junta algunas, no todas); el conteo "N de 4 huellas distintas" se calcula sobre lo que se dibuja.

La página de la etapa productiva SENA deja de ser un tablero de tarjetas iguales. La banda de estado y la barra del cronograma se funden en una cinta de días: una raya por día de la etapa, más cortas los fines de semana, en ember los festivos colombianos, en cyan la entrega de cada bitácora (con el último hábil marcado cuando el cierre cae en domingo o festivo), en violeta las ventanas de visita, y en lima hoy. Al entrar, las rayas se levantan, un cabezal recorre lo transcurrido hasta hoy mientras el contador del día rueda, y los corchetes de las bitácoras y las etiquetas de las visitas se dibujan. Apuntar un día (o recorrerlo con las flechas) lo lee: fecha, día de la etapa, bitácora en curso, entrega adelantada, visita y motivo si es inhábil. En celular la cinta se parte en seis filas, una por mes de bitácora, con un blanco de unos 10 px por día. La calculadora rearma esa misma cinta con la fecha de otro aprendiz, y cada fila de la tabla de bitácoras lleva su miniatura. El pago se imprime renglón a renglón con las cifras rodando, el asunto generado cae en una bandeja de ejemplo del instructor que lo encuentra con la búsqueda por el comienzo del asunto (y apaga los que no tienen el formato), y los documentos de cierre marcados entran como páginas a un PDF que se sella al estar completo. De paso corrige que la página midiera 635 px de ancho en un celular de 390 px.

El administrador ve las sesiones activas por dispositivo (IP, user-agent, última actividad) y puede revocarlas.

El administrador puede cerrar su sesión desde cualquier página del panel.

Documento de alcance por proyecto con objetivo, presupuesto estimado/acordado, horas e ítems (requerimiento/entregable/exclusión).

Registro de decisiones técnicas por proyecto con contexto, decisión, justificación y alternativas consideradas; opcionalmente públicas.

Biblioteca de decks HTML autónomos y sesiones de proyección: pantalla principal, control remoto desde el celular y vista del público en sincronía por PIN corto servido en la raíz del dominio.

Panel único en /admin/capacitacion para el banco de recursos (alta, edición con previsualización del markdown y borrado), el catálogo de programas y los códigos de grupo (generación, revocación y reactivación), con cifras de material publicado, borradores, lecturas y canjes.

Un asistente de IA que conoce proyectos, clientes, cuentas de cobro, pagos recibidos, vencimientos de dominios y servicios, mensajes, páginas vigiladas, finanzas, seguimiento y la documentación del sitio. Responde preguntas en lenguaje natural desde la terminal y desde la caja del dashboard (RF-219), y prepara trabajo (cuentas de cobro en borrador, cambios de proyectos e hitos, pendientes de seguimiento, cotizaciones), pero toda escritura la aprueba el administrador viendo el cambio. En la terminal delega la seguridad en el analista del micro-SIEM (RF-613); para cotizar deja la propuesta en Plano (RF-211).

Capacidad del asistente (RF-210): el administrador pega el mensaje de un cliente que pide precio y el asistente deja una propuesta en borrador en Plano (RF-214), leída por la IA de Plano (RF-216), con el rango de precio del motor y las preguntas que faltan. Nunca escribe al cliente ni ofrece descuentos; crear la propuesta lo aprueba el administrador viendo el texto que se va a leer, y revisarla y enviarla sigue siendo suyo. Las capacitaciones no van a Plano: se remiten a su precio publicado.

En todo el sitio, la burbuja de WhatsApp ofrece además resolver dudas con un agente de IA que responde sobre los servicios (planes, tiempos, pagos, capacitación), calcula un precio estimado con el tarifario y termina abriendo WhatsApp con el resumen ya escrito. WhatsApp sigue siendo la opción principal y la IA nunca es paso obligatorio.

Cuando el asesor público (RF-212) da un precio, prepara el WhatsApp u ofrece el formulario de contacto, avisa a Mike por ntfy con enlace a la conversación y le pide a la persona su WhatsApp por si Mike no alcanza a entrar. Mike la lee en vivo desde el panel y, si escribe, el asesor se calla y sus mensajes le llegan al visitante en el mismo chat de la burbuja.

Claude (Opus 5.5, salida estructurada) lee la conversación con el cliente y arma el borrador: solo componentes de la tabla, con la frase literal del cliente que justifica cada uno y las preguntas que faltan. Una segunda función revisa la propuesta como el cliente más exigente: ambigüedades, alcance que puede crecer sin pagarse y pre-mortem.

Al aprobarse el anticipo, la propuesta se convierte sola en cliente, proyecto, hitos con fechas, cuentas de cobro en borrador de los pagos restantes e invitación al portal. En las propuestas aceptadas se anotan las horas reales por componente y Plano sugiere si la tabla se queda corta o larga respecto del colchón (con tres mediciones o más).

El dashboard del panel abre con un saludo y una caja "Pregunta o busca algo", al estilo de la portada de Notion. Mientras se escribe, busca sin IA y sin costo páginas del panel, clientes, proyectos, cuentas de cobro, facturas, briefings y propuestas. Con Enter le pregunta al asistente (RF-210), que responde en la misma página con los pasos que dio y enlaces a donde verlo, y puede proponer una cuenta de cobro que se aprueba desde una tarjeta con los totales calculados por el servidor. Ctrl+K abre la misma búsqueda desde cualquier página del panel.

Cada encargo registra las solicitudes del cliente (fecha, canal, dentro del alcance, cupo o adicional, fuera de horario) y las reuniones con sus minutos y su resumen escrito, y descuenta los cupos.

Convierte un pedido vago en alcance (entregables, exclusiones, supuestos y preguntas previas), clasifica las solicitudes nuevas contra el alcance firmado con respuesta y orden de cambio en borrador, y redacta el resumen de cada reunión.

El cliente ve en un enlace privado la propuesta, los cupos que le quedan, la bitácora y los adicionales pendientes, y los aprueba o rechaza con constancia antes de que se hagan.

Apartado /admin/marketing para escribir campañas de correo con vista previa en vivo, enviarse una prueba y dispararlas a la lista de suscriptores. La lista solo tiene gente que pidió entrar: formulario público /novedades y casilla opcional de /contact (las dos con doble confirmación por correo) y casilla de la cuenta del portal. Cada correo lleva su enlace de baja, y la cola respeta el horario de la Ley 2300, una promoción por persona por semana y un cupo diario que deja sitio a los correos del portal.

Registro cifrado de variables de entorno por ambiente (producción/staging/dev) para cada proyecto gestionado.

Descubrimiento automático de fecha de expiración vía RDAP y alerta por email/push antes del vencimiento.

El cliente consulta sus pagos en /mis-pagos mediante un link firmado incluido en el mensaje de WhatsApp; la consulta manual por número muestra datos enmascarados.

El formulario de una cuenta de cobro nueva permite crear el deudor ahí mismo, y avisa de forma accionable cuando la ficha elegida no tiene NIT: deja crear el borrador, no deja emitirlo, y enlaza al sitio donde se completa.

El panel suma lo emitido en el año en cuentas de cobro y lo compara contra las 3.500 UVT del art. 437 par. 3 ET, con aviso al 70 %, alerta al 90 % y advertencia explícita al superarlo.

Desde /admin/infra se ve qué costaría el stack propio (Vercel, Turso, Claude y Google Workspace) con el uso de hoy y con el de tres escenarios de crecimiento: cuota incluida por dimensión, porcentaje consumido, excedente facturable y, sobre todo, en qué dimensión se rompe primero cada plan gratuito.

Desde /admin/resumen se ve, mes a mes, lo que sale del bolsillo en tres secciones: infraestructura, suscripciones de trabajo y costos de vida, con total en USD y COP, promedio mensual, variación contra el mes anterior y una proyección de 12 meses (cinco atrás, seis adelante) para ver venir los meses pesados. Los costos de vida se llevan en /admin/vida: una plantilla de gastos fijos (arriendo, servicios, suscripciones personales) y un registro de lo gastado de verdad cada mes, fijos y variables, que se compara con lo presupuestado por categoría.

Un archivo único y sin dependencias (instrumentacion/medidor.ts) que se copia al proyecto del cliente, se engancha como middleware de Astro o de Express o envuelve un handler web, y mide lo que la función ve: CPU activa del proceso, memoria por tiempo con peticiones en curso, invocaciones y bytes de respuesta. Lo acumula por hora y lo envía cada 10 minutos, firmado con HMAC por proyecto, a /api/computo/ingest, que lo aplica de forma atómica e idempotente.

Desde /admin/computo se ve cuánto de la cuota Hobby de la cuenta llevan consumido los proyectos medidos en el mes, por dimensión y por proyecto, con proyección al cierre y la fecha en que se agotaría. Un aviso por ntfy sale al cruzar el 70, el 90 y el 100 %, o cuando la proyección pasa del 100 %, una vez por umbral y por mes. El mismo panel da de alta los proyectos medidos: genera o rota el secreto del medidor (se muestra una sola vez) y pausa o reanuda la medición.

En /admin/computo, a partir de una estimación en términos de visitas (páginas vistas, qué parte pasa por una función, peso por visita, CPU y duración por render) y con plantillas de landing estática, sitio SSR y tienda, el cotizador calcula el consumo mensual del cliente, qué parte de la cuota gratis se comería, si cabe junto a lo que la cuenta ya proyecta, cuánto costaría en Pro y una cuota mensual sugerida en USD y COP.

Hilos de conversación por proyecto entre el cliente y el administrador, con estado de leído. Cada hilo nuevo y cada respuesta del cliente avisan al administrador por push y por correo, con enlace directo a la conversación en el panel.

El cliente ve los documentos compartidos y el avance por hitos de su proyecto.

El administrador puede ver el portal como un cliente concreto para dar soporte, sin poder escribir nada en su nombre.

La información del portal (notificaciones, mensajes, facturas, salud del proyecto) se refresca sola mientras la pestaña está visible, sin recargar.

El cliente ve una línea de tiempo de lo que ha pasado en sus proyectos (hitos, facturas, mensajes), con filtro por tipo y paginación.

La pantalla /login, a la que lleva el botón de entrar del sitio, sirve a los dos públicos con un selector de dos pestañas: Cliente (correo y contraseña del portal) y Admin (GitHub o llave de seguridad). Abre en Cliente por defecto, en Admin cuando el middleware rebota a alguien desde una ruta del panel, y recuerda en el navegador la pestaña elegida a mano.

Endpoint público de salud que ejerce la cadena real de dependencias del portal, sondeado por el motor de uptime propio para que el portal aparezca en /status como cualquier otro servicio.

Cálculo de SLI/SLO configurable (objetivo % y ventana en días) por monitor, con presupuesto de error restante.

Alertas push (ntfy.sh) ante caídas de monitores, vencimientos de dominio y anomalías de seguridad.

Cada cron que pasa la autenticación deja una fila con el job, si salió bien, cuánto tardó y un resumen corto del resultado; /automatizaciones muestra la última corrida de cada uno.

Cada lunes a las 7:00 de Bogotá un cron junta la semana anterior (disponibilidad por sitio, incidentes, ataques por tipo, bloqueos, tareas programadas, integración continua y gasto del analista), Claude la redacta en un resumen corto y el titular llega al celular. Se guarda el historial de 12 semanas y se ve en /admin/semana, con un botón para generarlo a mano.

Inyección de fallos reales (500, 503, latencia) por ruta con TTL obligatorio y kill-switch de pánico; /admin y /api/auth excluidos por código.

Escenarios de carga y estrés contra endpoints críticos: escalera de niveles de concurrencia, punto de quiebre, recuperación tras la saturación y consumo de CPU/heap del proceso.

Análisis estático de seguridad (npm audit + CodeQL) y auditoría de accesibilidad (axe-core sobre Playwright) que ingieren sus hallazgos al panel del LAB.

Escaneo dinámico baseline contra el deployment de preview, con el reporte JSON ingerido como hallazgos del LAB junto a los de SAST.

La página /pay separa "Pagar un servicio" de "Apoyar mi trabajo", pide nombre, correo y concepto, y muestra quién recibe el pago, los medios disponibles, qué llega después y a quién escribir si algo falla. El checkout de Wompi se abre con nombre y correo ya prellenados, y al volver, /pay/gracias muestra si el pago quedó aprobado, pendiente o rechazado (con reintento cuando aplica), en vez de dar las gracias a ciegas.

Un agente que corre en un contenedor de Anthropic clona el repositorio, ejecuta npm audit, los tests y astro check, mide los headers del sitio publicado y entrega un informe priorizado que cruza los avisos del CI con el código real. Llega por webhook a /admin/lab/security y al celular; abrir un issue o un PR exige aprobación humana desde el panel.

Agregados horarios/diarios de eventos de seguridad por categoría para tendencias y detección de anomalías.

Detector estadístico (z-score sobre baseline de 30 días) de picos, patrones nuevos, anomalías geográficas y ráfagas de error.

Vista en /admin con eventos, anomalías y acciones de respuesta (bloquear IP, marcar revisado).

Archivo único sin dependencias que se copia al proyecto de un cliente, clasifica sus requests con las mismas firmas del micro-SIEM, agrega en memoria y envía lotes firmados a la ingesta de seguridad.

Endpoint que recibe lotes de eventos ya clasificados desde los proyectos vigilados, autenticados con HMAC por proyecto, y los guarda con su project_id.

Una IP delatada en cualquier proyecto vigilado queda bloqueada en todos, limitando la propagación a las categorías donde el falso positivo es imposible por diseño.

Un agente de IA (Claude Opus 5.5) lee el micro-SIEM con seis herramientas propias, decide qué investigar, explica lo que encontró en lenguaje claro y puede PROPONER bloqueos, que siempre aprueba o rechaza el administrador. Vive en /admin/analista en producción, con historial (que marca si el análisis fue automático, desde la terminal o desde el panel), retoma de un bloqueo pendiente aunque se cierre la pestaña, y transmisión en vivo de cada paso.

Requerimientos, casos de uso, historias, diagramas UML y BPMN, kanban, guía de testing, verificación y validación, y estado del pipeline en vivo, navegables desde /docs.

Los cuatro procesos de negocio (cobro de campo, acceso al portal de clientes, respuesta de seguridad y ciclo de monitoreo) modelados en notación BPMN con carriles por participante, compuertas, eventos y temporizadores, más la explicación de los cinco tipos de compuerta y la tabla de tiempos de cada proceso, navegables desde /docs.

La vista de red del sistema como diagrama de despliegue (nodos «device»/«executionEnvironment», artefactos y caminos de comunicación con protocolo), las cuatro interacciones principales como diagramas de comunicación con numeración decimal, y tres flujos de control internos como diagramas de actividades con particiones, bifurcación concurrente y bucle de reintento. Incluye la corrección de /docs/diagrama-componentes, que era un flowchart de despliegue sin ninguna interfaz declarada, a un diagrama de componentes UML real con conectores de ensamblaje.

La evidencia medida de la última corrida completa de la suite, publicada en /docs/ejecucion-pruebas: total de pruebas y fallos, duración por nivel (unitario contra integración), distribución logarítmica de tiempos, las 12 pruebas más lentas y la tabla de los archivos con su tiempo individual. Un generador convierte el reporte JUnit de Vitest en una instantánea versionada y, en paralelo, en un informe HTML autocontenido para entregar o proyectar.

Página /docs/diagrama-red con la topología de producción expresada como zonas de confianza (Internet, perímetro, cómputo, datos gestionados, terceros salientes), los hosts de cada una y los flujos dirigidos entre ellas, cada cruce de frontera con su protocolo, su puerto y la tabla de controles que atraviesa.

Pantalla de mando en /sustentacion/control: avanza y retrocede la presentación desde el teléfono, muestra las notas de narración del beat en curso, el cronómetro contra la duración estimada y un selector para saltar a cualquiera de los doce beats.

La pantalla que ve el jurado en /sustentacion: grafo de la arquitectura dibujado en canvas 2D que se revela por capas, HUD de la corrida de estrés con la curva real, matriz de trazabilidad a la que vuelan los nodos, demo del portal en vivo dentro de un iframe, pipeline de CI/CD y checklist de entregables. Vestíbulo con el PIN y el QR del público antes de empezar.

La pantalla /presentacion monta el bundle exportado en un iframe y /remote lo gobierna desde el teléfono: siguiente, anterior, salto directo y la posición real del mazo, con el estado compartido por /api/presentacion.

Página /docs/planteamiento con el planteamiento del problema (síntomas observados con su evidencia y su consecuencia, causas que los explican y delimitación en las tres dimensiones), la justificación por ejes y los objetivos general y específicos, cada objetivo con su indicador, su meta, su forma de verificación y los requisitos que lo realizan.

Consola retráctil en la ventana que conduce la presentación, con tres estados que se ciclan con la tecla P y se recuerdan entre recargas: oculto (el mazo a pantalla completa), barra (una franja con reloj, desvío, posición, título de la diapositiva y estado del enlace) y consola (guion completo con la nota de la diapositiva siguiente, ritmo contra las duraciones estimadas del guion, rejilla de saltos sobre la forma real del mazo, URL de la página viva con atajos para volver a la demo del portal, /status o /engineering, botones de desplazamiento y tres acciones de rescate). Sustituye la necesidad de mirar el celular mientras se conduce desde el portátil: hasta aquí el guion y la rejilla solo existían en /remote.