Un sitio estático que se construye solo en cada push, lee el contenido de otros repos sin copiarlo a mano y delega las pruebas pesadas a una segunda máquina. Cuatro vistas: contenedores, flujos, despliegue y decisiones. Haz clic en cualquier caja; reproduce un flujo para ver el recorrido.
Cada caja es una pieza que corre por separado: una sesión de trabajo, un script, un servicio o el navegador de quien visita. Las líneas son llamadas reales: protocolo y qué viaja.
No hay servidor de aplicación: el visitante recibe HTML ya hecho. Lo único que corre en su navegador son islas pequeñas (el buscador carga su índice de 3,5 KB recién al primer foco). Menos piezas que mantener, nada que pueda caerse a las tres de la mañana y una factura de hosting fija.
La Academy y estas páginas de arquitectura viven en los repos de cada proyecto. Dos scripts de Python las leen, auditan la privacidad con fallo duro y escriben la colección de contenido. Añadir un proyecto a la serie es escribir tres archivos en su repo y nada aquí.
El PC edita, revisa y fusiona. Las capturas, Lighthouse y las pruebas con Playwright corren en la Mac mini a través de enjambre, en un worktree limpio, y vuelven como una rama de git. El PC nunca queda saturado por un navegador sin cabeza.
El sitio es un directorio de archivos. Eso es lo que permite moverlo a cualquier hosting estático cambiando solo el destino del build. Las demos no viven aquí: cada una tiene su subdominio y su propio docroot, y se despliega desde su repo.
mainnpm run buildLighthouse móvil (mediana de 5, sitio en vivo): rendimiento 100, accesibilidad 96, SEO 100.
Qué gana: caché en el borde y despliegues atómicos. Qué no gana: velocidad de página, que ya depende del peso, no del servidor.
| Decisión | Por qué | Descartado |
|---|---|---|
| Astro 4 estático, sin SSR | HTML hecho en el build; el visitante no espera a un servidor y no hay nada que mantener corriendo | SSR o una SPA: más JS en el cliente y un proceso vivo en el hosting |
| Un subdominio por demo | Cada demo tiene su docroot y su deploy; la Landing solo enlaza. Un demo roto no rompe el hub | Copiar cada demo en una subcarpeta del sitio: un repo Astro de cientos de MB con toolchains mezclados |
| Deploy automático por git | Cada push a main reconstruye; no hay zip ni subida manual que olvidar | Subir dist/ a mano por API: un paso humano en cada publicación |
| Importadores que leen otros repos | La lista vive en los datos: un manifiesto nuevo aparece en el índice sin tocar la Landing | Editar el índice a mano: alguien tiene que acordarse cada vez |
| Privacidad por auditoría con fallo duro | Un nombre o una ruta personal detiene la importación y el build con archivo y línea | Revisión a ojo antes de publicar |
| Recibo del build medido, no escrito | Peso, peticiones y rastreadores se miden sobre el archivo final; si no cuadran, el build falla | Cifras escritas a mano en el pie, que envejecen sin avisar |
| Pruebas pesadas en la Mac mini | Playwright, Lighthouse y grabaciones saturaban el PC; en la Mac corren en un worktree limpio y vuelven como rama | Correr todo en Windows, de a uno |
| Páginas de arquitectura copiadas, sin iframe | HTML estático en pestaña nueva: no hereda la CSP del sitio ni mide dos veces en Lighthouse | Incrustarlas con iframe en la página del proyecto |