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 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 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).
• ✓ 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 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.