Arquitectura Static-First para un Portfolio con Astro 7
Cómo este portfolio bilingüe usa Content Collections de Astro 7, evidencia versionada e islas Svelte acotadas sin base de datos en runtime.
El portfolio actual es un sitio estático en Astro 7. Los proyectos y credenciales viven en Content Collections JSON, los artículos en MDX y todas las rutas públicas se generan durante el build. La aplicación desplegada no tiene base de datos en runtime, autenticación ni rutas admin.
Por Qué Static-First Encaja con el Contenido
El contenido del portfolio cambia mediante actualizaciones revisadas del repositorio, no en cada request. Integrarlo al HTML y los assets elimina una dependencia de red del render público y vuelve inspeccionable cada cambio en control de versiones.
Los gates de contenido y build validan:
- categorías de evidencia y campos obligatorios de flagships;
- tipos de credencial y estado de verificación;
- fechas, URLs, metadata de collections y salud de imágenes.
La suite amplia de calidad valida por separado rutas localizadas, alternates recíprocos, enlaces internos, comportamiento unitario, regresión de navegador, flujos de teclado y responsive, seguridad y accesibilidad.
Collections como Fuente de Verdad
El schema de proyectos separa presentación de evidencia. Un flagship debe incluir problema, rol, decisiones, resultado y limitaciones en ambos idiomas. También necesita al menos una fuente tipada de evidencia o una ruta localizada de caso técnico; un sitio desplegado por sí solo no prueba el rol ni el impacto.
const projectSchema = z.object({
project_type: projectTypeSchema,
evidence_status: projectEvidenceStatusSchema,
capabilities: z.array(projectCapabilitySchema).min(1),
domain: projectDomainSchema,
translations: z.object({
en: projectTranslationSchema,
es: projectTranslationSchema,
}),
});Las credenciales usan otro contrato. verified, source-linked y unverified son estados distintos; una fuente pública no se presenta como verificación independiente.
Rutas y SEO
Un registro tipado controla pares EN/ES, labels, canonicals, alternates, indexabilidad, tipo de página y rutas OS. Navegación, taskbar, cambio de idioma, redirects, SEO y sitemap consumen el mismo registro en vez de mantener mapas paralelos.
Interacción sin Backend de Runtime
Astro renderiza el documento y los datos de collections. Las islas Svelte reciben esos datos mediante props y administran interacciones locales como filtros, diálogos accesibles, ventanas persistentes, controles multimedia y replays deterministas.
El filtrado es síncrono y local. El archivo de proyectos también refleja los filtros activos en el query string para poder revisitar una vista sin introducir un backend.
Los Scripts de Migración No Son Arquitectura de la Aplicación
El repositorio conserva scripts explícitos de exportación para contenido histórico de Supabase. Requieren variables de entorno locales y nunca se importan desde la aplicación pública. Su presencia no significa que el sitio desplegado use Supabase en runtime.
Límites Conocidos
El escritorio retro es mejora progresiva, pero algunas interacciones avanzadas requieren JavaScript. Safari/iOS físico, VoiceOver, zoom real del navegador y headers alojados siguen siendo gates manuales o de Preview separados.
La Arquitectura en una Frase
Versionar contenido y evidencia en el repositorio, validarlos durante el build, renderizar HTML estático útil con Astro e hidratar únicamente las interacciones Svelte que necesitan estado del navegador.
