AI-LAB Astro Visual System

Este documento fija el estándar visual para futuras páginas y actualizaciones Astro. La meta es mantener una presentación premium, técnica y coherente entre /infra, /ai-infrastructure, observabilidad, status, runbooks y páginas futuras.

• Oscuro premium.
• Acentos cyan/teal.
• Jerarquía ejecutiva primero.
• Contenido técnico después.
• Evitar tablas crudas cuando una matriz o card sea más legible.
• Separar resultado técnico PASS de resultado visual PASS.
• Mantener coherencia entre páginas internas y documentación operativa.

• Hero / encabezado.
• Estado operativo.
• Executive summary cards.
• Secciones principales.
• Matrices operativas.
• Roadmap.
• Riesgos residuales.
• Próxima fase.

Estos nombres describen patrones visuales/documentales. No implican que exista todavía un componente Astro con ese nombre.

• HeroBlock.
• StatusCard.
• MetricCard.
• OperationalMatrix.
• RoadmapPanel.
• ToolMatrix.
• CalloutSuccess.
• CalloutWarning.
• CalloutCritical.
• OperatorAction.
• SecurityNote.

• confirmed.
• active.
• standby.
• pending.
• reserved.
• low risk.
• medium risk.
• critical.
• operator action.
• read-only.
• mutable.
• destructive.

• Completado recientemente.
• Próximo bloque.
• Pendiente.
• En reserva.
• Operator action.
• No convertir Roadmap en changelog largo.

• Tools confirmadas.
• Uso activo.
• En preparación.
• En reserva.
• Condiciones de activación.
• AILAB_MCP_TOKEN como nombre de variable, sin valor real.
• LAN controlled mode.
• Read-only por defecto.
• Acciones mutables o destructivas en reserva salvo aprobación.

• Tabla solo si mejora lectura.
• Máximo 5 columnas cuando sea posible.
• Para tools y roadmap, preferir cards o matriz visual.
• Evitar contenido plano sin jerarquía.

• No tokens.
• No credenciales.
• No endpoints sensibles.
• No seriales.
• No identificadores GPON completos.
• IPs internas solo si la página es interna o protegida y hay justificación.
• En caso de duda, usar versión sanitizada.

Antes de commit:

• npm run build PASS.
• Ruta validada en dist.
• Sin secretos.
• Sin tokens reales.
• Sin seriales.
• Sin IPs sensibles salvo justificación.
• Diseño revisado.
• No tablas crudas innecesarias.
• Roadmap actualizado si aplica.
• MCP Tools actualizadas si aplica.
• Informe de auditoría creado.
• No runtime ni servicios tocados.
• Visual review antes de push.

Futuras fases Astro deben:

• Reutilizar estos patrones.
• Evitar HTML/CSS ad hoc sin justificación.
• Incluir revisión visual antes de push.
• Separar contenido técnico de aceptación visual.

• Próxima fase recomendada: AI-LAB-ASTRO-ROADMAP-MCP-TOOLS-VISUAL-APPLY-01
• Objetivo: aplicar este estándar a /ai-infrastructure.

npm run build no equivale a aceptaci?n visual.

Una publicaci?n Astro solo puede pasar si:

1. npm run build PASS.
2. npm run validate:visual PASS.
3. Ruta objetivo validada en dist.
4. Revisi?n visual o screenshot sin overflow.
5. Resumen final al operador en espa?ol.
6. Sin m?tricas largas como t?tulos principales.
7. Sin cards ad hoc fuera del sistema visual.
8. Sin push si hay regresi?n visual.

Usar t?tulos cortos:

• Runtime Health
• Infra Cross-check
• Health Drift
• Watchdog
• Router Auto
• LM Studio Benchmark

Mover nombres largos a badges/code:

• ailab_cognitive_health_score
• ai_lab:runtime_health_score
• no_nodes_online
• google/gemma-4-e4b

El resumen operativo debe estar en espa?ol. El ingl?s solo se permite para literales t?cnicos.

Antes de push:

• build,
• validate:visual,
• screenshot/revisi?n,
• commit,
• no push sin aprobaci?n si hay cambios visuales.