Como visitante, quiero ver el portfolio público con proyectos reales para evaluar el trabajo de Mike

• ✓BaseLayout, Navbar, Footer y la página principal con hero, proyectos y proceso quedan operativos.
• ✓ProjectCard consume datos reales de GitHub vía API de repos.
• ✓Tailwind CSS v4 configurado con paleta y tipografía del sitio.

Como visitante, quiero ver el estado en vivo de los servicios (uptime, incidentes, latencia)

• ✓/status muestra uptime global de 30 días e incidentes activos.
• ✓Animación EKG con latencia p95 en tiempo real por monitor (13 commits de status).
• ✓API de latencia expone último estado y hora de chequeo por monitor.

Como visitante, quiero que el sitio sea indexable y compartible (SEO técnico completo)

• ✓JSON-LD y breadcrumbs estructurados en páginas de proyecto.
• ✓Feed RSS y notificación IndexNow a buscadores en cada publicación (8 commits de IndexNow).
• ✓Web app manifest y apple-touch-icon para instalación como PWA.

Como visitante, quiero escanear un QR y ver cómo un tablero reconoce mi dispositivo en vivo sin cookies

• ✓Landing con consentimiento crea sala + QR; el tablero (/board) refleja los dispositivos por polling corto (Vercel no soporta WebSocket).
• ✓Al reentrar en incógnito o borrar cookies, el contador de "revisitas" sube: mismo dispositivo re-identificado (validado por smoke test de API).
• ·Prueba end-to-end en navegador real del ciclo crear → escanear → revisita (canvas/WebGL/audio solo producen valores en un browser).

Como visitante, quiero entender qué me delata: recolector propio contrastado con una librería y una capa de comportamiento

• ✓Recolector propio: canvas, WebGL, AudioContext, fuentes, pantalla, zona horaria, CPU/memoria, idiomas, touch y UA.
• ✓Segunda opinión con FingerprintJS (open source): su visitorId se muestra junto al hash propio en el tablero.
• ✓Entropía dinámica: cada señal bloqueada/vacía suma 0 bits; se declara como estimación educativa (EFF Panopticlick / AmIUnique), no medición poblacional.
• ✓Capa de comportamiento: cadencia de tecleo, velocidad de mouse y giroscopio (con permiso iOS 13+).

Como visitante, quiero explorar el portal de clientes de la demo con datos frescos, no con lo que dejó otro visitante

• ✓seedPortalDemo siembra clientes, facturas y client_users ficticios en la base demo, reusando scripts/seed-demo.mjs.
• ✓Cron de Vercel resiembra el portal demo a las 4am todos los días (vercel.json).
• ✓Endpoint público de demo añadido a las rutas accesibles sin sesión; pagos bloqueados también en el portal demo (middleware).

Como visitante, quiero analizar cualquier dominio público (SEO, performance, accesibilidad, TLS) desde el sitio

• ✓Endpoint público de análisis de dominio con rate limiting propio.
• ✓SSRF protegido: resolución de hostname y rechazo de IPs privadas/reservadas antes de solicitar el sitio.
• ✓Fetch del HTML memoizado y reutilizado entre las pruebas de SEO, performance y accesibilidad para no golpear el sitio objetivo varias veces.
• ✓Integración con Google PageSpeed Insights (Lighthouse) para las métricas de performance.

Como visitante, quiero que ningún enlace en inglés me lleve a una página que no existe

• ✓TRANSLATED_ROUTES como única fuente de verdad de qué existe en inglés; localizedHref cae al español si no hay traducción.
• ✓El hreflang y el sitemap solo anuncian idiomas en los que la página existe de verdad.
• ✓El middleware redirige GET/HEAD de /en sin traducir a la versión en español con 302, no 308.
• ✓tests/i18n-routing.test.ts cruza la lista contra los archivos reales de src/pages/en/ en las dos direcciones.

Como visitante, quiero que el sitio siga en pie cuando la base no responde

• ✓safeQuery: una consulta que falla en una página pública devuelve su valor de reemplazo y el dato se pinta como ausente, nunca como error y mucho menos como 404.
• ✓Aplicado a las 23 consultas de las cinco páginas públicas con datos (portada, /status, /security, /certifications, /engineering); no queda ninguna consulta desnuda.
• ✓Cada fallo se registra con etiqueta en el log del servidor: degradar para el visitante no puede significar degradar en silencio para quien opera.
• ✓Excluido a propósito del panel, el portal y todo lo que cobra o autentica, donde un dato ausente en silencio es peor que un error visible.

Como administrador, quiero autenticarme y que solo yo pueda entrar a /admin

• ✓Middleware de Astro protege todas las rutas /admin y /api/admin.
• ✓Auth.js con proveedor GitHub y allowlist de logins permitidos.
• ✓Base de datos Drizzle + libSQL con el esquema inicial de clients/projects/messages/finances.

Como administrador, quiero un dashboard con KPIs y gestión de proyectos, clientes y finanzas

• ✓Dashboard admin con KPIs de proyectos, mensajes, clientes y finanzas.
• ✓Sidebar de navegación agrupada y FinanceTable/MessagesList funcionales.
• ✓Formulario de contacto público con validación y persistencia de mensajes.

Como administrador, quiero backups automáticos de la base de datos para no perder información

• ✓API de backups sube snapshots a Vercel Blob mediante cron programado.
• ✓Página /admin/backup lista y permite crear backups manualmente.

Como administrador, quiero monitorear la salud de mis servicios en producción

• ✓Esquema monitors/monitor_checks/monitor_incidents con checks HTTP periódicos.
• ✓Página /admin/monitors con estado, latencia e incidentes por monitor.
• ✓13 commits dedicados a monitoreo durante la iteración.

Como administrador, quiero que las variables de entorno de mis proyectos estén cifradas

• ✓Utilidades de cifrado/descifrado (crypto.ts) para project_env_vars.
• ✓Revelado de secretos on-demand vía fetch, sin exponerlos en el HTML inicial.

Como administrador, quiero un sensor que observe y clasifique requests hostiles sin bloquear tráfico legítimo

• ✓classify.ts clasifica requests por firmas conocidas de ataque.
• ✓sensor.ts observa cada request de forma síncrona y no bloqueante (fire-and-forget).
• ✓security_events y security_rollups agregan eventos para el panel.

Como administrador, quiero bloquear IPs maliciosas y aplicar rate limiting que sobreviva a un redeploy

• ✓blocklist.ts responde 403 seco a IPs bloqueadas, con lectura cacheada 30s.
• ✓rate_limit_buckets: ratelimit-durable.ts reemplaza el rate limiting en memoria (9 commits).
• ✓Todo el bloque de enforcement es fail-open: un fallo nunca tumba el sitio.
• ✓Tests de blocklist y clasificación de seguridad en tests/.

Como administrador, quiero registrar y gestionar mis llaves de seguridad desde el panel

• ✓Tabla webauthnCredentials (credentialID, publicKey, counter, transports, nickname) con índice por login.
• ✓/admin/passkeys lista, añade (con nickname) y revoca llaves; excludeCredentials evita re-registrar la misma llave física.
• ✓API /api/admin/webauthn/{registration,credentials} protegida por el gate de sesión+allowlist existente.

Como administrador, quiero entrar a /admin tocando mi llave, sin pasar por GitHub

• ✓Flujo usernameless (sin allowCredentials): el navegador ofrece las llaves discoverable del rpID y el login se descubre por el credentialID devuelto.
• ✓Proof HMAC de 30s (signPasskeyProof/verifyPasskeyProof) conecta la ceremonia FIDO2 con el provider "passkey" de Auth.js, sin repetir la criptografía ahí.
• ✓rpID/origin derivados del Host de cada request (prod, previews de Vercel y dev en cualquier puerto), no hardcodeados.

Como administrador, quiero una demo read-only del panel admin para mostrar a reclutadores sin exponer datos reales

• ✓/demo firma un token de sesión de solo lectura y lo valida en middleware sin tocar Auth.js.
• ✓Middleware bloquea cualquier método no-GET en modo demo y marca el flag demo en locals.
• ✓scripts/seed-demo.mjs siembra clientes, proyectos, finanzas, monitores y CI runs ficticios en una base aislada.
• ✓Tests de verificación de token demo y restricción de métodos.

Como administrador, quiero cobrarle a un cliente por WhatsApp con un enlace de pago corto, sin que necesite cuenta

• ✓Página /cobrar genera un cobro con código corto (alfabeto/crypto propios) y arma el mensaje de WhatsApp.
• ✓/pagar simula el pago del cobro validando titularidad de la factura, reutilizando la máquina de estados de payments.
• ✓Webhook de conciliación liquida o reversa el pago y actualiza la factura asociada.
• ✓Cron diario (sweep) marca facturas vencidas y notifica al cliente automáticamente.
• ✓Tests de cálculo de facturas, formato de dinero en COP y expiración de cobros.

Como administrador, quiero activar clientes en el portal, invitar usuarios y gestionar sus facturas e hitos desde /admin

• ✓/admin/portal activa clientes, invita usuarios y lista su estado (invited/active/disabled).
• ✓/admin/portal/facturas y /admin/portal/hitos con CRUD completo de invoices y milestones.
• ✓/admin/portal/mensajes lista y responde hilos de conversación por cliente, con notificación al responder.
• ✓Enlaces añadidos al sidebar de administración.

Como administrador, quiero que cada push escanee vulnerabilidades de dependencias y del propio código

• ✓.github/workflows/security.yml corre npm audit y CodeQL en cada push/PR.
• ✓scripts/npm-audit-scan.mjs normaliza el reporte de npm audit para ingesta.
• ✓security_findings agrega hallazgos por herramienta con severidad, estado y auto-resolución cuando el hallazgo desaparece.

Como administrador, quiero saber si mis tests realmente detectan bugs (mutation testing), no solo si pasan

• ✓stryker.config.json configura mutation testing sobre los módulos críticos, con reporte HTML y concurrencia ajustada.
• ✓.github/workflows corre Stryker y scripts/mutation-scan reporta el score al panel LAB (mutationScore en ci_runs).
• ✓Pipeline y /lab muestran el mutation score cuando hay un resultado reciente disponible.

Como administrador, quiero ver el portal exactamente como lo ve un cliente, para dar soporte sin pedirle su clave

• ✓Botón "Ver como cliente" en la lista de clientes con usuarios de portal activos.
• ✓API de impersonación crea una portal_session marcada con impersonatedBy, visible en PortalLayout con aviso y logout que restaura la sesión admin.
• ✓Modo impersonado restringido a solo lectura: bloquea pagos y cualquier acción de escritura; queda registrado en auditoría (impersonate.start/end).

Como administrador, quiero que una IP reincidente reciba un bloqueo cada vez más largo, no siempre el mismo TTL

• ✓blockIpEscalated calcula TTL creciente (1h → 24h → 7d) según el historial de bloqueos previos de la IP.
• ✓Honeypots tocados se bloquean inline desde el middleware, sin esperar al cron de auto-block.
• ✓Tests unitarios de blockIpEscalated y de la lógica de TTL en isBlocked.

Como stakeholder académico, quiero navegar la documentación del proyecto sin necesitar sesión de administrador

• ✓Páginas de casos de uso, diagramas, historias de usuario, requisitos y kanban migradas de /admin/docs a /docs.
• ✓DocsNav como componente de navegación propio, reemplazando AdminLayout en todas las vistas de documentación.
• ✓Redirect catch-all de /admin/docs a /docs para no romper enlaces existentes.

Como visitante técnico, quiero un panel público con métricas de ingeniería reales (Web Vitals, CI, disponibilidad)

• ✓/engineering muestra Core Web Vitals p75 de usuarios reales (RUM) con p50/p95, distribución de rating, tendencia 7d y peor ruta por métrica.
• ✓Cards de pipeline CI (tests, cobertura, duración) y disponibilidad agregada, alimentadas de ci_runs y monitor_checks.
• ✓CardPopover en cada métrica explica el origen del dato y el umbral contra el que se evalúa; página server-rendered con datos de producción.

Como responsable del sitio, quiero que la demo sea ética y segura: efímera, consentida y con defensas anti-abuso

• ✓Salas efímeras: TTL de 2h purgadas por el cron (sweepFpRooms), sin PII persistente; consentimiento explícito antes de recolectar.
• ✓Rate limiting durable por endpoint (beat reescopado por dispositivo para eventos con muchos móviles tras una NAT).
• ✓entropyBits acotado a 0–64 en servidor y valores escapados en el DOM (el UA es controlable).
• ✓Cierre pedagógico: por qué el incógnito no protege y cómo defenderse (Tor, resistFingerprinting).

Como cliente, quiero iniciar sesión en mi propio portal con invitación previa y recuperar mi contraseña si la olvido

• ✓client_users, client_invitations y portal_sessions con hashing scrypt y sesiones opacas revocables (cookie portal_session, distinta de admin).
• ✓APIs de login, logout, aceptar invitación y reset de contraseña, con rate limiting y logging al micro-SIEM.
• ✓PortalAuthLayout para las pantallas de login, invitación y reset; requirePortalSession() como única puerta de entrada al tenant.
• ✓Tests de hashing de contraseña, clasificación de rutas del portal y aislamiento entre tenants.

Como cliente, quiero ver el estado de mis proyectos, salud del servicio y mis facturas en un panel propio

• ✓Página de overview del proyecto con HealthCard (salud de monitores) y MilestoneTimeline (hitos con estado).
• ✓Selector de proyecto (tabs) cuando el cliente tiene más de uno, resuelto por ?p= solo contra la lista de proyectos de su propia sesión - un id ajeno cae al primero propio.
• ✓Módulo invoices/invoice_items con CRUD completo, numeración correlativa y estados (draft/sent/paid/overdue/void).
• ✓Centro de notificaciones in-app e hilos de mensajería (portal_threads/portal_messages) con conteo de no leídos.

Como cliente, quiero gestionar mi cuenta, mi equipo, mis documentos y ver mi historial de pagos

• ✓/portal/cuenta con perfil, cambio de contraseña y gestión de sesiones activas.
• ✓Gestión de equipo (invitar/roles) reutilizando client_invitations desde el propio cliente.
• ✓/portal/documentos sube y descarga archivos vía stream autenticado (se descartó URL firmada por seguridad) con auditoría.
• ✓/mis-pagos resuelve el historial por teléfono con enlace firmado y rate limiting.

Como cliente, quiero pagar un cobro real por WhatsApp y recibir una notificación cuando se apruebe

• ✓Checkout API en /api/c/[code]/checkout.ts integra Wompi para el cobro real, además del mock de pruebas.
• ✓notifyCobroPaid envía alerta push al admin cuando un cobro se marca pagado.
• ✓Rate limiting propio para las rutas de enlace de cobro (isCobroLinkPath).

Como cliente, quiero ver la respuesta a mi mensaje sin recargar la página

• ✓portalLiveDigest() sobre los helpers existentes: cero SQL nuevo.
• ✓GET /api/portal/live con rate limit por sesión (10/min) y no-store.
• ✓Ciclo de 20 s con pausa por visibilidad y backoff 20→300 s; fail-open silencioso.
• ✓Un CustomEvent y tres suscriptores: campana, dashboard e hilo abierto.
• ✓tests/portal-live.test.ts con libSQL real: aislamiento entre clientes, rol billing sin mensajes, projectId ajeno cae al propio.

Como equipo de QA, quiero que las pruebas E2E corran automáticamente en cada push, no solo en mi máquina

• ✓Job de Playwright añadido a .github/workflows/ci.yml, corriendo contra base de datos desechable sembrada.
• ✓Roadmap actualizado marcando el E2E de Playwright como completado, con siguientes pasos definidos.

Como asistente, quiero entrar al material de mi grupo sin crear otra cuenta

• ✓Código de grupo que se dicta al cerrar la sesión, con alfabeto sin caracteres ambiguos (sin O/0, I/1/l, S/5) y normalizado al comparar; se canjea por un pase firmado de 30 días, sin correo ni cuenta.
• ✓El id del código viaja dentro de lo firmado y se revalida contra la base en cada request: revocar corta el acceso de esa cohorte al instante, sin tocar el de las demás.
• ✓Único punto del repo que falla CERRADO: sin poder confirmar que el código sigue vivo se cae al banco público, porque abrir publicaría material restringido en una respuesta cacheable.
• ✓El canje devuelve el mismo mensaje para código inexistente, vencido, revocado o mal escrito, y lleva rate limit propio (10/min por IP) sobre el mismo enforcement durable de los links de cobro.
• ✓tests/capacitacion.test.ts: 35 casos. Firma con otro secreto, sin secreto, vencimiento reescrito, id de cohorte reescrito y tokens malformados, todos rechazados sin lanzar.

Como compañero de clase, quiero un único punto de entrada que me explique cómo se prueba este sistema

• ✓/docs/testing cubre los niveles de prueba, la pirámide con volúmenes reales, el pipeline etapa por etapa y un glosario.
• ✓Las métricas salen de src/data/testing.ts y de la ingesta del pipeline, no se escriben a mano en la página.
• ✓Restricción OPSEC respetada: los tests de seguridad se describen por lo que garantizan, sin citar patrones, rutas señuelo ni umbrales.

Como evaluador, quiero ver la vista de red y las interacciones en notación UML de verdad

• ✓Diagrama de despliegue con nodos «device»/«executionEnvironment», artefactos y caminos de comunicación con su protocolo.
• ✓Cuatro diagramas de comunicación con numeración decimal, enlazados en ambos sentidos con los de secuencia.
• ✓Tres diagramas de actividades con particiones, bifurcación concurrente y bucle de reintento.
• ✓SVG generado en el servidor desde modelos tipados; el navegador no ejecuta JavaScript para dibujarlos.

Como dueño de un negocio local, quiero entender qué me ofrecen y cuánto cuesta sin lenguaje técnico

• ✓/paginas-web con tres planes de precio visible, perfiles de cliente, pasos del proceso y FAQ.
• ✓Contacto por WhatsApp o formulario, reutilizando /api/contact con su rate limiting ya probado.
• ✓Enlace «Diseño Web» en el navbar; la landing vive aparte de la marca técnica del resto del sitio.

Como cliente que navega con teclado o lector de pantalla, quiero saber qué pasó al enviar un formulario del portal

• ✓Skip link como primer elemento tabulable del portal, con el <main> identificado como destino.
• ✓Región aria-live que anuncia el resultado del envío, incluidos los mensajes de error explícitos.
• ✓El foco aterriza en la confirmación tras enviar, en vez de quedarse donde estaba.

Como jurado, quiero ver los procesos de negocio modelados en BPMN, no descritos en prosa

• ✓/docs/diagrama-bpmn renderiza cuatro procesos (monitoreo, cobro de campo, acceso al portal, seguridad) desde datos tipados en src/data/bpmn.ts.
• ✓src/lib/bpmn-layout.ts calcula carriles, canales de transición y cajas de etiqueta como lógica pura; 83 tests en tests/bpmn.test.ts.
• ✓Detección de colisiones de etiquetas y de texto fuera de los límites dentro del propio motor de layout.
• ✓Eventos temporizadores de frontera con su tabla de tiempos por proceso.

Como jurado, quiero que las cifras de /docs/testing sean la corrida real, no un número escrito a mano

• ✓scripts/report-tests.mjs lee el XML JUnit de "npx vitest run --reporter=junit" y genera src/data/ejecucion-pruebas.json (versionado, porque coverage/ e informes/ están en .gitignore y Vercel no puede leer lo que no está en el repo) más un informe HTML autocontenido.
• ✓/docs/ejecucion-pruebas publica el total real de la última regeneración (1181 tests y 0 fallos en la entrega del 21 ago; 1200 en 70 archivos tras regenerarla el 26 ago), duración por nivel, distribución logarítmica de tiempos y las 12 pruebas más lentas.
• ✓METRICAS_REFERENCIA, NIVELES y PIRAMIDE en src/data/testing.ts pasan a derivarse de la instantánea (EJECUCION) en vez de tener sus propios números, que era justo la fuente de la contradicción (724 vs 777 tests en dos tablas distintas del mismo documento).

Como jurado, quiero ver qué zona puede alcanzar a cuál y con qué protocolo, no solo dónde corre cada nodo

• ✓src/data/red.ts modela zonas (con nivel de confianza), hosts y flujos dirigidos; src/lib/red-layout.ts calcula la geometría reutilizando el motor genérico del BPMN (corte de texto, polilíneas redondeadas).
• ✓NetworkDiagram.astro renderiza el SVG en el servidor; /docs/diagrama-red lo publica con la tabla de controles por cruce de frontera.
• ✓OPSEC respetado: solo entra lo ya público (puertos estándar, protocolos, proveedores y controles por categoría), nunca umbrales de rate limit ni nombres de reglas de detección.

Como visitante internacional, quiero leer el sitio en inglés sin perder la página en la que estoy

• ✓Prefijo /en con el español como idioma canónico sin prefijo; el selector de idioma conserva la página actual.
• ✓Siete páginas de marca traducidas vía diccionario: home, engineering, tools, security, contact, certifications y architecture.
• ✓Una sola implementación por página: la variante /en es un cascarón que reexporta la misma página y el locale sale de la URL del request.
• ✓hreflang recíproco con x-default, canónico localizado, og:locale y feed propio /en/rss.xml.
• ✓Sugerencia de idioma por Accept-Language como invitación descartable, nunca como mecanismo de ruteo (rompería el cache público).

Como responsable del sistema, quiero que ningún guarda de seguridad cambie de veredicto por un prefijo de idioma

• ✓El middleware normaliza el pathname una sola vez, antes de cualquier clasificación de amenazas o de auth.
• ✓Las rutas privadas (admin, API, portal, cobros y los tres gates de login) devuelven 404 bajo cualquier prefijo de idioma.
• ✓141 tests en tests/i18n-routing-guards.test.ts: cada guarda da el mismo veredicto para /x y /en/x, con casos adversariales (//en/admin, /EN/admin, /e%6E/admin, /english/algo).

Como visitante anglófono, quiero que las páginas de producto y estado estén en mi idioma, no solo la portada

• ✓/status, /demo, /log y /paginas-web traducidas y dadas de alta en TRANSLATED_ROUTES.
• ✓Tiempos relativos y fechas por locale, sin cadenas en español coladas en la versión inglesa.
• ✓El formulario de contacto envía el locale y la notificación lo refleja.
• ✓tests/i18n-dictionary.test.ts y tests/i18n-routing.test.ts cubren las claves y rutas nuevas.

Como responsable de la documentación, quiero que un diagrama mal formado falle en CI y no en la sustentación

• ✓54 tests de geometría y notación en tests/uml-{activity,communication,deployment,component}.test.ts.
• ✓Geometría: nada encimado, ninguna transición atravesando una figura ajena, todo elemento dentro de su nodo o partición.
• ✓Notación: decisiones con al menos dos salidas y todas con guarda, uniones con una sola salida, ningún final con transiciones salientes, ningún nodo inalcanzable.
• ✓/docs/diagrama-componentes rehecho como diagrama de componentes real; un test falla si vuelve a nombrar infraestructura.

Como presentador, quiero proyectar desde cualquier pantalla y controlarla desde mi celular

• ✓Tres vistas sobre una sesión: /present/[sessionId] proyecta, /remote/[sessionId] controla y /[pin] sigue en sincronía.
• ✓El control remoto no carga el iframe del deck: las notas salen de deck_slides, extraídas al subir el archivo.
• ✓Layout de dos mitades sin scroll, botones de 72 px, Wake Lock y vibración corta, todo con degradación silenciosa.
• ✓El deck se sirve desde /decks/[id].html (mismo origen) porque el control por DOM del iframe no funciona contra una URL de blob.

Como público, quiero seguir la presentación en mi dispositivo escaneando un QR

• ✓PIN de cuatro caracteres, dos letras y dos dígitos, sin i/l/o ni 0/1: 203.136 combinaciones y forma inconfundible con una ruta del sitio.
• ✓/[pin] es la última ruta en resolver; lo que no tiene forma de PIN devuelve el 404 normal sin llegar a consultar Redis.
• ✓Generación con reintento contra rutas reservadas y PIN vivos; un test cruza la lista de reservadas contra los archivos de src/pages.
• ✓Vista de solo lectura: sin controles, sin notas y con el teclado del deck neutralizado dentro del iframe.

Como responsable del coste, quiero tiempo real sin una invocación abierta por espectador

• ✓El público se suscribe DIRECTAMENTE al bus de Upstash con un token de solo lectura; Vercel solo trabaja al crear la sesión, al dar el snapshot y en cada comando.
• ✓Dos bases separadas: estado (privada, con el secreto del presentador) y bus (token público, solo números de slide).
• ✓Tres capas de sincronía: bus, resincronización cada 10 s y polling de rescate - pub/sub no garantiza entrega.
• ✓El servidor es la fuente de verdad: valida rango, persiste y reemite; el cliente descarta mensajes con versión anterior.
• ✓tests/present-sync.test.ts levanta dos clientes y comprueba que el salto llega a ambos, en orden, y que sin secreto no se mueve nada.

Como responsable del coste, quiero que una página pública lea lo mismo el primer día que el año siguiente

• ✓Tabla monitor_daily con un resumen precalculado por monitor y día, alimentada por un cron nuevo (/api/cron/monitor-rollup); /status lee ~720 filas de resumen más el día en curso en vez de agregar los 90 días crudos de monitor_checks.
• ✓Medido contra la sqld local: 5.912 filas recorridas por render antes, 552 después.
• ✓Los contadores del resumen son exactos y aditivos; la latencia no, porque un percentil no se suma, así que cada día guarda un histograma de 32 cubos del que sale el p95 de la ventana, dentro del 7,4% del exacto que devolvía la window function.
• ✓La escalera de cubos es geométrica y no lineal: en un percentil importa el error relativo, y la primera versión lineal pintaba 2450 ms un p95 real de 2030.
• ✓tests/monitor-rollup.test.ts cubre histograma, percentil y agregación por día UTC.

Como responsable del coste, quiero que una prueba de carga no pueda alcanzar la base real

• ✓El health check declara contra qué base está sirviendo el objetivo, y los perfiles de k6 (carga y estrés) se niegan a arrancar un solo usuario virtual si esa base no es local.
• ✓La guarda vive en el arranque de la prueba, no en la documentación: apuntar a localhost no basta cuando el dev server detrás puede estar conectado a Turso.
• ✓tests/db-target.test.ts cubre la detección de base local.

Como aprendiz, quiero registrar cada sesión de práctica y ver si el hábito se sostiene

• ✓Registro de sesión con día, minutos, tema, bitácora y hito relacionado; tres tablas nuevas (skill_tracks, skill_sessions, skill_milestones) en migración aditiva.
• ✓Racha con día de gracia: si la última sesión fue ayer sigue viva y se marca "en juego", en vez de romperse a las 00:00 de un día que apenas empieza.
• ✓Meta semanal configurable con lo que falta y el ritmo por día necesario para llegar antes del domingo.
• ✓Mapa de calor de 26 semanas con intensidad relativa al mejor día de la ventana, no a umbrales fijos.

Como aprendiz, quiero un temario concreto en vez de una intención vaga de "aprender .NET"

• ✓Temario semilla de 28 hitos en 8 áreas, de fundamentos de C# a desplegar una API real, con dos hitos de proyecto insignia.
• ✓La siembra es idempotente por título: volver a dispararla añade los hitos nuevos de la plantilla sin duplicar ni pisar el estado de los cerrados.
• ✓Los hitos se editan desde el panel una vez sembrados; la plantilla en src/data/track-dotnet.ts no vuelve a tocar un track existente.

Como responsable de que el dato sea correcto, quiero que la racha no dependa de la zona horaria del servidor

• ✓Los días se guardan como clave de calendario "YYYY-MM-DD" en zona de Bogotá, no como timestamp: el servidor corre en UTC y una sesión de las 8 de la noche caería en el día siguiente, partiendo la racha.
• ✓Los logros se derivan de las sesiones en cada render en vez de persistirse: una tabla de badges se desincroniza al borrar una sesión mal registrada.
• ✓Cada logro queda fechado en el día en que se cumplió (cruce del umbral acumulado, cierre de la racha), no en el día en que se consulta el panel.
• ✓tests/skills.test.ts: 31 casos sobre el módulo puro, incluidos cambio de mes, año bisiesto, fin de año, corte de racha a los dos días y niveles relativos del mapa de calor.

Como capacitador, quiero que el material siga sirviendo cuando termina la sesión

• ✓Tres tablas nuevas en migración aditiva: training_programs (catálogo), training_resources (banco) y training_access_codes (grupos).
• ✓Banco público en /capacitacion con detalle por recurso; el contenido es markdown en base de datos, renderizado en el servidor con un subconjunto propio que escapa el HTML antes de formatear.
• ✓Las presentaciones no se duplican: un recurso de tipo deck referencia la tabla decks, que sigue siendo la única fuente de verdad del material proyectable.
• ✓La previsualización del panel usa el mismo renderizador que la página pública, para que no sea una previsualización que miente.

Como dueño de los datos, quiero saber si el backup diario realmente se está haciendo

• ✓Descubierto con el store de Blob vacío: un mes sin un solo archivo. Dos fallos que se tapaban entre sí: el endpoint vivía bajo /api/admin/, donde el middleware exige sesión y el cron se llevaba un 302; y el handler del backup era POST mientras que los crons de Vercel disparan GET, con lo que la petición diaria caía en el GET de "listar backups" y devolvía 200.
• ✓El backup se mueve a /api/cron/backup con Bearer CRON_SECRET, y es el único cron del repo que NO es fail-open: devuelve 500 cuando falla, porque un cron que solo puede responder 200 no está verificado, está silenciado.
• ✓tests/crons.test.ts recorre cada entrada de vercel.json y afirma las cuatro condiciones que fallaban: la ruta existe, exporta GET, comprueba CRON_SECRET y no cuelga del gate de /api/admin. Ninguna necesita desplegar para comprobarse.
• ✓La ruta del cron queda vetada en la demo, cubierto por tests/demo.test.ts.

Como responsable del incidente, quiero un procedimiento escrito para la próxima vez que la cuota se agote

• ✓docs/runbook-cuota-turso.md documenta qué pasó (86.000 filas leídas por llamada a /api/now.ts pese a devolver un único número), la regla que lo evita (ningún agregado público sobre ventanas >24h sin rollup) y que es la tercera vez que el mismo patrón agota la cuota.
• ✓Dos caminos de recuperación documentados: aguantar hasta el corte del ciclo (la capa de respaldo de RNF-27 se apaga sola) o mudar a una base nueva, con el requisito de que ENCRYPTION_KEY debe coincidir para no perder la bóveda.
• ✓/api/now.ts (error budget) y /api/engineering/live.ts pasan a leer de monitor_daily en vez de agregar monitor_checks/web_vitals crudos; este último además cambia no-store por s-maxage=30.

Como autor del modelo, quiero que un flujo no pueda saltarse un perímetro sin que el test lo note

• ✓tests/red.test.ts verifica geometría (zonas sin solaparse, host dentro de su zona, ninguna traza atravesando una zona ajena a sus extremos, rótulos sin encimarse) y notación (todo flujo con protocolo, todo cruce con puerto y al menos un control, ningún host aislado).
• ✓Regla dura verificada con tres pruebas hostiles a propósito: un flujo que se salta el perímetro, un cruce sin control y un host huérfano, exigiendo que el verificador los detecte.
• ✓findLayoutIssues corregido para usar bboxZona (la caja real, incluida la cabecera de la zona) tras encontrar cabeceras encimadas que la primera versión no detectaba.