Documentación

Arquitectura, manuales y decisiones técnicas del AI-LAB.

Phase 8 Architecture — Realtime Cognitive Mesh

Arquitectura completa del AI-LAB tras la Fase 8: runtime cognitivo con eventos SSE, topologia viva y observabilidad en tiempo real.

AI-LAB Runtime Domains

Mapa real de dominios (bounded contexts) del runtime AI-LAB: núcleo cognitivo, orquestación, inteligencia operacional, cognición estructural, memoria y governance.

Arquitectura AI-LAB

Arquitectura real actual: nodos, servicios runtime, truth layers (authority/operational/structural) y dominios cognitivos.

Audits

Curated audit index for AI-LAB architecture, operations, observability and governance reports.

Hermes Enterprise — Overview

Hermes Enterprise es la capa de governance, registros y observabilidad declarativa del runtime AI-LAB. Define SOUL, capabilities, operators, hooks, MCP y governance dinámico.

Fases Historicas

Archivo de documentacion de fases completadas del proyecto AI-LAB (Fase 11 a Fase 36+). Contenido historico, no necesariamente reflectivo del runtime actual.

AI-LAB Docs — Estado Actual

Documentación oficial de AI-LAB: plataforma de ingeniería con runtime evidence-bound, Hermes Enterprise Governance, AnythingLLM Knowledge Base, Marketplace Digital Twin y GitNexus Structural Cognition.

Event Bus — Sistema de Eventos Cognitivos

Arquitectura del bus de eventos SSE del AI-LAB para streaming de metricas y eventos del runtime.

Governance AI-LAB

Documentación de gobernanza del runtime: herramientas, policies, evidence enforcement, governance visibility y reglas operacionales.

Architecture

Arquitectura de Hermes Enterprise: gimnasia relacional entre SOUL, capabilities, operators, hooks, MCP y governance.

Runtime

Baseline oficial del runtime observacional de AI-LAB antes de Multi-GPU: estado actual, madurez, sensor fusion, semántica y contrato observado.

Topología AI-LAB

Diagrama real de alto nivel: clientes, gateway, truth layers, backend de inferencia, observabilidad y cognición estructural.

Agentic Runtime

Documentación del runtime agentic gobernado de AI-LAB: simulation, planner, readonly executor, sandbox write y rollback.

Arquitectura del Ecosistema AI-LAB

Arquitectura actual del ecosistema AI-LAB: runtime evidence-bound, Hermes Enterprise Governance, AnythingLLM Knowledge Base, GitNexus Structural Cognition, Marketplace Digital Twin y observabilidad.

SOUL

Identidad, truth model, protocolos, boundaries y dominios del agente Hermes.

SSE Runtime — Streaming de Eventos

Implementacion del servidor SSE en la Live API, con ThreadingHTTPServer y conexiones persistentes.

Capability Registry

6 capabilities críticas con dependencias, governance levels y validación cruzada.

Observabilidad

Documentación de observabilidad de AI-LAB: métricas Prometheus, dashboards Grafana, alertas, audit trail, SLO enforcement y error taxonomy.

Rutas internas AI-LAB

URLs principales del laboratorio y servicios internos.

Topology Layer — Mapa Vivo del Cluster

Capa de topologia interactiva del AI-LAB: nodos, conexiones, estados en tiempo real.

Architecture Stabilization Map (ARCH-STABILIZATION-PASS-01)

Mapa de estabilización arquitectónica: desacoplos mínimos, consistencia de métricas gateway y extracción de handlers para reducir fragilidad sin cambiar comportamiento.

Arquitectura Astro de AI-LAB

Estructura completa del frontend documental de AI-LAB con Astro: páginas, componentes, separación público/privado, integración con Live API, build y deploy.

30I Burn-in Results

Resultados del burn-in de FASE 30I: validación de sensor fusion con datos reales de Prometheus, GPU metrics, topology derivation y OBSERVED_RUNTIME injection.

AI-LAB Phase Closure Protocol (01)

Protocolo oficial de cierre de fase para AI-LAB. Toda fase debe evaluar impacto documental, actualizar documentación, reindexar AnythingLLM y validar recuperación documental antes de declararse PASS.

Operator Registry

5 operadores con execution modes, truth model y validación de contratos.

Runtime AI-LAB

Arquitectura runtime real: gateway entrypoint, routing determinista, profiles, fastpath, authority, precision y truth layers.

Experimentos

Resultados de experimentos, benchmarks y validaciones del runtime AI-LAB.

Document Publishing Automation

Pipeline automatizado de publicación documental: Astro público (Cloudflare Pages), Astro privado (ailab-docs local), reindex AnythingLLM y smoke queries. Orquestador invoke-phase-closure con flags DryRun/Skip/SudoPassword.

Hook Registry

9 lifecycle hooks para eventos del pipeline Hermes. Todos disabled.

Memory Layer

Memoria del runtime: Qdrant (persistente), episodic memory local, incident recall y cognitive history. Implemented vs experimental vs planned.

Routing Cognitivo

Routing determinista del runtime AI-LAB: route families, perfiles, fastpath, autoridad/precisión y reglas de escalación.

AnythingLLM — Memoria Documental de AI-LAB

Rol de AnythingLLM en AI-LAB: memoria documental, auditor RAG, consumidor de documentación canónica y gobierno del conocimiento.

Grounding y RAG

Arquitectura de grounding contextual y recuperación semántica.

MCP Registry

5 servidores MCP declarativos para acceso a herramientas del runtime.

Qdrant Memory Layer

Colecciones reales en Qdrant y su rol en AI-LAB: operational recall, incident recall, knowledge, snapshots y governance.

Schemas

Contratos y esquemas oficiales del baseline observacional: OBSERVED_RUNTIME, sensor_snapshot, gpu_operational_summary y archive manifests.

AnythingLLM Enterprise

Knowledge Base Enterprise de AI-LAB sobre AnythingLLM Desktop: 1304 vectores, 7 workspaces activos, RAG 100%.

Dynamic Governance

4 modos de governance (NORMAL, ELEVATED, DEGRADED, LOCKDOWN) con resolver de señales, anti-flapping y matrix de capabilities.

Inferencia Distribuida

Estado real: single GPU activa + inventory offline. Multi-GPU se pospone hasta maturity/governance/precision estables.

Roadmap

Roadmap realista stabilization-first con Hermes Enterprise Core completado, AnythingLLM Enterprise baseline, y próxima gobernanza activa.

Federation Governance Bootstrap (01)

Transición de runtime monolítico a federación cognitiva operacional basada en bounded contexts: registry + contracts + aislamiento de agentes.

Marketplace Digital Twin

Rioja Marketplace como Digital Twin: repositorio indexado en GitNexus, MCP read-only, estado actual de servicios y riesgos conocidos.

AnythingLLM Reindex Automation

Automatización del reindexado incremental de AnythingLLM tras cambios documentales. Procesamiento por lotes, exclusiones automáticas, modo incremental y smoke queries para cerrar el ciclo documental del protocolo PC-01.

Runtime Status Endpoint

GET /hermes/status — fuente oficial de observabilidad de Hermes Enterprise.

Observabilidad y Estado Vivo

Sistema de monitorización y snapshots vivos del AI-LAB.

FASE 28 — Governed Autonomy Runtime

Implementación completa del runtime agentic gobernado: simulation, planner, readonly executor, sandbox write, rollback, burn-ins, seguridad y límites.

Almacenamiento AI-LAB

Arquitectura de almacenamiento persistente del laboratorio.

Roadmap

Estado actual y planificación de Hermes Enterprise: implementado, skeleton y planificado.

FASE 29 — Runtime Observability

Gateway hardening, real streaming, three-model runtime, SLO enforcement, error taxonomy, SLO health endpoint always-on, parallel tool call hardening.

Capas de Verdad del Runtime

Arquitectura de las tres capas de verdad del runtime AI-LAB: Prometheus, OperationalTruth y GitNexus. Separación de responsabilidades y correlación entre fuentes.

Estado Actual del Runtime

Descripción del estado actual del runtime AI-LAB: control-plane, backend, modelos activos, servicios principales, endpoints y checkpoints.

Runtime Current State

Estado actual real del runtime AI-LAB: control plane, observability, backends de inferencia, enterprise layer, knowledge base y checkpoints.

Snapshots Históricos

Persistencia temporal y observabilidad histórica del AI-LAB.

Runtime Maturity Layer

Cómo AI-LAB pasó de routing reactivo a un runtime observacional cognitivo con evidencia, semántica de sensores y contratos operacionales explícitos.

Cognitive Health Layer (37A)

Contrato 37A-COGNITIVE-HEALTH-LAYER-01: capa liviana, determinista y metadata-only para salud del runtime. Always-on, fail-safe, bounded.

Router LM Studio Failover

Tarea pendiente para mejorar el failover inteligente entre nodos LM Studio.

Runtime Flow — Flujo del AI-LAB (CP-22B+)

Diagrama actualizado del flujo completo del AI-LAB desde OpenCode/OpenWebUI hasta LM Studio, pasando por perfiles cognitivos, politicas de herramientas y memoria.

Runtime Sensor Fusion

Documentación completa de FASE 30I y 30I-B: sensor fusion, dominios, topología, Prometheus integration, hardening y baseline observacional antes de Multi-GPU.

Servicios Persistentes (systemd)

Servicios systemd del AI-LAB y gestión de arranque (core runtime + docs + métricas).

Cloudflare Zero Trust

Publicación segura del AI-LAB mediante Cloudflare Access y Tunnel.

Runtime Sensor Semantics

FASE 30I-D: normalización semántica de sensores para alinear /runtime/sensors, OBSERVED_RUNTIME y respuestas LLM sobre un único contrato operacional.

Open WebUI — Conexion al AI-LAB Router

Configuracion de Open WebUI para usar el Router API del AI-LAB con enrutamiento declarativo por perfiles cognitivos y politicas de herramientas.

GPU Operational Summaries

Diseño y uso de los summaries compactos de GPU introducidos en 30I-C y normalizados en 30I-D para respuestas operacionales cortas.

Runtime Observability Fabric

Arquitectura del tejido de observabilidad del runtime: Prometheus como sistema nervioso, sensor fusion, evidence pipeline y topología dinámica.

Observed Runtime Contract

Contrato cognitivo de OBSERVED_RUNTIME: qué incluye, cómo se construye y por qué es la interfaz entre sensores, governance y respuesta LLM.

Runtime Sensor Topology

Topología dinámica del runtime derivada de sensores Prometheus: clasificación de nodos GPU, modos de topología y transiciones.

Sensor Fusion Pipeline

Pipeline de adquisición, fusión y exposición semántica de sensores en AI-LAB: desde Prometheus y LM Studio hasta OBSERVED_RUNTIME y respuestas del LLM.

Runtime Sensor Fusion — Observabilidad

Observabilidad del sensor fusion runtime: métricas, dashboards, endpoints y troubleshooting para FASE 30I.

Evidence-Bound Runtime

Cómo 30H y 30I convierten AI-LAB en un runtime evidence-bound: prevención, observación, contratos y sanitización post-respuesta.

Runtime Evidence Pipeline

Pipeline completo de evidencia: desde Prometheus hasta el LLM, con observed/derived separation, confidence scoring y sanitización.

Storage Archive Policy

Política operativa de archive histórico: separación entre runtime vivo, runtime data, modelos y NAS; manifests, exclusiones y detección anti-recursiva.

Research: FASE 10 — JSON HARD FACTS + Qdrant Cognitive Layer

Diseño y plan de implementación para HARD FACTS estructurado en JSON y memoria operacional cognitiva con Qdrant.

Pre-Multi-GPU Baseline

Baseline oficial del runtime antes de reactivar Multi-GPU: un solo backend activo, un backend inventariado y contrato semántico de sensores estabilizado.

FASE 94 — HARD FACTS (arquitectura actual CP-22B+)

Sistema de grounding con datos reales del runtime. Ahora activo solo en rutas reasoning/analysis. Las rutas ligeras usan prompts declarativos sin HARD_FACTS.

Prometheus Runtime Integration

Cómo AI-LAB integra Prometheus en el runtime: query client, cache TTL, timeout, dominios y métricas que alimentan sensor fusion.

Authority-Backed Cognition (35C)

Cómo el runtime separa autoridad (Prometheus) de cognición: freshness, gaps, confidence per-domain y disciplina NO DISPONIBLE.

Cloudflare Pages — Redirects y Submodules

Solucion a los problemas de build en Cloudflare Pages: submodules git y redirects externos no soportados.

FASE 95 — Plan Mode (HISTORICO)

Documento historico de FASE 9.5 (marzo 2026). El Plan Mode fue eliminado en FASE 20B y reemplazado por tool governance y perfiles cognitivos declarativos.

FASE 9.5.1 — Disciplina Semántica en HARD FACTS

Reglas estrictas de categorización para evitar que el modelo confunda servicios systemd, contenedores Docker, colecciones Qdrant y nodos GPU. Etiquetado obligatorio [HARD_FACTS], [INFERIDO], [NO DISPONIBLE].

GPU Metrics Integration

Integración de métricas GPU en vivo: exporter, Prometheus, sensor fusion y summaries operacionales de RX9070/RX7900XT.

Runbook — Cloudflare Pages y Sincronizacion

Problemas comunes con Cloudflare Pages y sus soluciones: submodules git, redirects, builds fallidos, sincronizacion.

FASE 30I — Runtime Sensor Fusion

Sensor fusion runtime: Prometheus-backed evidence viva, 13 dominios observados, topología degradada single-GPU, confidence per-domain, evidence pipeline hacia OBSERVED_RUNTIME.

Precision Semantics (36B)

Semántica de precisión operacional: partial evidence, conflicts, stale evidence, degradación segura y señales de precisión expuestas por el runtime.

Implementacion — Astro + Cloudflare Pages + GitHub

Arquitectura de despliegue del portal AI-LAB con dos blogs (publico y privado), sincronizacion automatica via GitHub y Cloudflare Pages.

Grafana Dashboard Map

Mapa de dashboards y su relación con el runtime observacional: qué paneles sustentan sensor fusion, SLO y GPU evidence.

Operator Intent Reasoning (36C)

Clasificación determinista de intención operativa como metadata: evita sobreclasificación, no ejecuta acciones y no eleva verdad operacional sin autoridad.

Automatización CI/CD — Publicación Automática de Documentación

Sistema de publicacion automatica para ambos blogs: Cloudflare Pages para el publico y self-hosted runner para el privado.

Sensor Domains

Catálogo de dominios observados por sensor fusion: prioridad, confianza, evidence level y efecto operacional de cada dominio.

Evidence Enforcement

Resumen de 30H, 30H.1 y 30H.2 como capa de enforcement epistémico sobre el runtime observacional.

Runtime Analytics Engine — Documentacion Tecnica

Motor de analiticas en tiempo real del AI-LAB: health score, metricas agregadas, sesiones, routing y event bus.

Runtime Trust Boundaries

Límites de confianza entre observación, inventario, derivación y generación LLM dentro del runtime AI-LAB.

FASE 11 — Cognitive Recall & Supervised Execution

Controlled semantic recall with policy engine, persistent mode state, command proposal pipeline, and EXECUTE v1 security sandbox.

Runtime Analytics - Diagnostico y Correccion de Metricas

Diagnostico y solucion de los 3 bugs que impedian la correcta visualizacion de metricas en el AI-LAB Command Center: health score, nodos online y gateway health check.

Arquitectura Publico-Privado de Metricas

Split de metricas: sitio privado con datos reales via Service Token, sitio publico con JSON estatico.

Archive Governance

Gobernanza de archives históricos: manifests, exclusiones, semántica de integridad y prevención de recursividad en el runtime.

FASE 12 — Adaptive Learning & Self-Optimization

Pattern learning engine, recommendation pipeline, context efficiency scoring, recall threshold optimizer, and supervised profile tuning.

Phase 30I Burn-in

Burn-in de 30I/30I-B: validación de sensor fusion con datos reales, dominio GPU, expected_offline y comportamiento del endpoint /runtime/sensors.

Operación Privada AI-LAB

Runbook operativo interno (realineado): endpoints core, autoridad/precisión, fastpath, y verificación sin tocar runtime/state.

Restauración de telemetría GPU y verificación de dashboards

Diagnóstico y reparación de telemetry GPU tras reboot: restauración de RX9070/RX7900XT, corrección de labels y verificación de dashboards AI-LAB y metricas.labrazahome.com.

Qwen Grounding Validation

Validación de grounding operacional de qwen sobre OBSERVED_RUNTIME y contratos 30I/30I-D, incluyendo rechazo de infraestructura no observada.

FASE 12.1 — Disciplina de prompting

Refuerzo de disciplina semántica en INFERIDO/HARD_FACTS, reglas 11-15, profile en HARD FACTS JSON y DEBUG template dinámico.

Plan de pruebas - AI-LAB v1 RC (HISTORICO)

RESULTADOS DE PRUEBAS — AI-LAB v1 RC (marzo 2026). No reflejan el estado actual CP-22B+. Varios bugs aqui documentados ya fueron resueltos en FASEs 20-22. Conservado como referencia historica.

GPU Summary Validation

Validación específica de summaries GPU compactos: métricas vivas, source_of_truth, freshness, confidence y compatibilidad del alias gpu_summary.

FASE 13 - Dynamic Model Discovery for AI-LAB Auto Router

Hito de descubrimiento dinámico de modelos en LM Studio para eliminar dependencias fijas en el auto router.

Cognitive Runtime Overview

AI-LAB como plataforma cognitiva operacional: separación backend de inferencia, gateway de gobernanza, GitNexus topológico y autoridad observacional.

Operational Truth vs Discoverable

Separación activa entre active/loaded/discoverable/disabled y cómo el runtime evita elevar discovery a verdad operacional.

FASE 14 - Tool-Use Native Routing and OpenAI Tool Call Bridging

Hito del router AI-LAB para detectar requests con tools, priorizar modelos tool_use descubiertos y emitir tool_calls estructurado.

Cognitive Health Layer (37A)

Capa bounded, read-only y metadata-only que puntúa nodos, estima confianza de routing y emite triggers watchdog sin remediación.

Baseline Pre-Multi-GPU

Documento de baseline previo a FASE 31A: por qué se pospuso Multi-GPU, qué se cerró antes, riesgos mitigados y estado listo.

Observed Runtime Schema

Esquema normalizado de OBSERVED_RUNTIME como contrato cognitivo del runtime AI-LAB.

Graph-Aware Governance

Gobernanza informada por topología: hotspots, blast radius, gravity centers y riesgo de acoplamiento. Framework bounded y determinista.

Worktree Governance

Disciplina de worktree para AI-LAB: qué se commitea, qué nunca se commitea, staging selectivo, y criterio de tags/checkpoints.

FASE 15 - Tool-Aware Context Fastpath and Latency Validation

Optimizacion de tool_use y saludos triviales; test y produccion local convergen en ~3s y el gateway devuelve tool_calls estructurado.

Graph-Runtime Correlation (37B)

Primera capa de correlación explicable entre hotspots topológicos (GitNexus) y degradación runtime real (health/SLO/triage/federation).

Sensor Snapshot Schema

Esquema de sensor_snapshot con contrato 30I-D: topología, confidence, source_quality y summaries GPU compactos.

Nexus Runtime Operator

Visión: operador cognitivo basado en señales (authority + topology + governance). Sin AGI, sin loops, sin remediation autónoma peligrosa.

AI-LAB v1 RC - Native Tool Calls + Tool Fastpath Stable

Punto de control del runtime: native tool calls y fastpath tool-aware estabilizados en router y gateway.

GPU Operational Summary Schema

Contrato semántico de un summary GPU en 30I-D: inventory, observed, operational, metrics, freshness, confidence y evidence level.

Runtime Topology Intelligence

Topología operational: dependencias, authority chains, blast radius y drift. Separación active/inventory/discoverable.

FASE 16 - Observe Mode and Readonly Shell

Modo de observacion para analisis tecnico/operativo sin HARD_FACTS obligatorio y con comandos informativos seguros.

Archive Manifest Schema

Contrato del manifest de archive histórico introducido por STORAGE-HARDENING: trazabilidad, tamaños, exclusiones e integridad.

Federation Intelligence

Federation-aware runtime: guards, evidence lineage, trust boundaries y explainability.

FASE 17 - Observabilidad y Gobernanza Prometheus

Integracion de observabilidad nativa en el runtime: contadores prometheus_client para HARD_FACTS, peticiones al router y bloqueos de politica con desglose por razon. Endpoint /metrics en router, target en Prometheus y dashboard en Grafana.

Pre-Multi-GPU Readiness

Qué condiciones quedaron cerradas antes de reactivar trabajo Multi-GPU: evidencia, sensor semantics, summaries GPU y archive governance.

Cognitive Control Plane

Plano de control cognitivo: APIs runtime always-on 200, contratos, métricas y disciplina evidence-bound.

Cognición Estructural de la Codebase

Documentación técnica de la integración GitNexus como memoria estructural del código fuente: dependency graphs, blast radius, ownership mapping, structural risks y cognitive pipeline.

FASE 18 — Professional Operations Runtime & Control Plane

Evolucion de AI-LAB hacia una plataforma operacional profesional con control plane centralizado, health scoring, tool reliability, memory usefulness, governance v2, explainability y recovery.

Phase 31 Readiness

Lectura de readiness para FASE 31 basada en el baseline 30I/30I-D y sin adelantar trabajo Multi-GPU no implementado.

Graph Runtime Correlation

Roadmap 37A: correlación entre topología (GitNexus) y señales runtime (SLO, triage, alerting) para priorización operacional.

FASE 18 — Test de Estabilidad y Rendimiento

Resultados de la bateria de tests de rendimiento post-FASE 18 contra baseline FASE 15. Sin degradacion de rendimiento atribuible al nuevo codigo.

FASE 19.4 — Route Family Observability

Documentacion de la observabilidad por route family: metricas Prometheus, lectura en Grafana, interpretacion de anomalias y validacion operativa del runtime.

Fix — Resiliencia ante Model Unloaded de LM Studio

Diagnostico y solucion del error 'Model unloaded.' que afectaba a OpenCode y OpenWebUI tras FASE 18. El modelo se descargaba por TTL de LM Studio y el router/gateway necesitaban compatibilidad SSE estable con retry y fallback.

Runbook — FASE 19.4 Route Family Observability

Runbook para revisar metricas por route family, detectar regresiones de contexto y validar el baseline del runtime AI-LAB.

FASE 19.5 — Operational Alerts Baseline

Reglas de alerta para detectar degradaciones del runtime por route family antes de abrir Grafana.

Retrospectiva — FASE 18 y el Incidente Model Unloaded

Documento completo del despliegue de FASE 18, el incidente de streaming con OpenCode, la restauracion del router y el estado final del proyecto tras la sesion del 17/18 de mayo 2026.

Parche — OpenCode, Router y Gateway Streaming

Documenta la correccion aplicada al flujo de OpenCode y al runtime AI-LAB: respuestas directas para informes, compatibilidad SSE, retry ante Model unloaded y limpieza de la integracion question tool.

Runbook — FASE 19.5 Operational Alerts Baseline

Runbook para validar las alertas basicas por route family y comprobar degradaciones automaticas.

Architectural Decision Records (ADRs)

Decisiones arquitectónicas del runtime AI-LAB: governance, operational truth, fastpath, precision, structural cognition y política anti-multi-GPU prematuro.

FASE 20A — Migracion del AI-LAB Router a qwen/qwen2.5-coder-14b-instruct

Migracion controlada del modelo principal del runtime AI-LAB hacia qwen/qwen2.5-coder-14b-instruct como modelo por defecto para fast, general y coding, manteniendo llama-3.1-8b para rutas minimal/casual/greeting/observe.

Autonomous Runtime Triage

FASE 36D: triage observacional bounded, determinista y always-on. Incidents, recommendations y métricas.

ADR-001 — Runtime Governance

Decidir que la gobernanza es parte del runtime: evidencia, límites de confianza, trazabilidad git y disciplina de publicación.

FASE 20B — Limpieza de Wrappers Legacy en Rutas No Cognitivas

Eliminacion de HARD_FACTS automaticos, Plan Mode, reasoning wrappers, structured JSON y tool forcing de las rutas fast, general y coding. Las rutas reasoning y tool_use mantienen su comportamiento.

Cognitive SLO Governance

SLO framework del runtime: salud, degradación, enforcement (dry-run) y endpoint always-on.

ADR-002 — Operational Truth

Separar discovery/inventory de operational: active/loaded/discoverable/disabled y anti-promoción de ctx:0.

Runbook — FASE 20 Router Qwen 2.5

Runbook unificado para operar y verificar las FASEs 20A y 20B del AI-LAB Router tras la migracion a qwen2.5-coder-14b-instruct.

ADR-003 — Fastpath + Authority

Fastpath operacional debe basarse en autoridad/evidencia y mantener respuestas compactas.

FASE 20C — Normalizacion de Prompts Runtime

Extraccion de prompts hardcoded a archivos versionados y declarativos en runtime/prompts/. Loader con validacion de wrappers prohibidos y fallback legacy.

ADR-004 — Precision Semantics

Definir precisión como integridad de evidencia (partial/conflicts/stale) y degradación visible.

FASE 21A — Cognitive Profiles (Profile Loader + Routing)

Introduccion de perfiles cognitivos como policy bundles declarativos. Cada perfil define modelo, inferencia, tools, memoria, razonamiento y streaming. Jerarquia: cliente > perfil > sistema.

ADR-005 — Structural Cognition (GitNexus)

Adoptar GitNexus como verdad estructural grounded para blast radius, coupling y drift, sin reemplazar autoridad operacional.

FASE 21A.1 — Observabilidad de Perfiles Cognitivos

Trazabilidad completa del perfil cognitivo aplicado a cada peticion: stdout, audit y Prometheus con labels profile, route_family y model.

ADR-006 — No Multi-GPU Before Stabilization

Decidir explícitamente retrasar Multi-GPU hasta que maturity/governance/precision/memory estén estables.

FASE 22A — Tool Runtime Policies

Politicas de herramientas declarativas en runtime/policies/tools/. Tres modos (disabled/readonly/agentic), lista maestra global de bloqueo, filtrado por allowed/blocked names.

FASE 22B — Tool Execution Safety

Sanitizador de comandos bash con token scanning, confirmation gate 428, auditoria por tool_call, presupuesto de tool_calls y metricas Prometheus por tool_name.

Observabilidad — AI-LAB (CP-26.1)

Documentacion definitiva del stack de observabilidad AI-LAB. Dashboards TIER 1 y TIER 2, metricas Prometheus, alertas, replay API, drift analytics y diagrama de flujo completo.

Observabilidad — Plataforma AI-LAB

Infraestructura completa de observabilidad del AI-LAB: Prometheus, Grafana, 15 dashboards, 19 alertas y metricas.

Mapa de Observabilidad — AI-LAB

Mapa completo del flujo de observabilidad del AI-LAB: generacion de metricas, scrape Prometheus, dashboards Grafana, alertas y auditoria.

FASE 25 — OpenCode Production Profile

Perfil de produccion para OpenCode: developer-first, sin Plan Mode, sin HARD_FACTS automatico, single ingress al router, guard duro contra tool_use y wrappers.

FASE 26.2 — UX & Cognitive Quality Refinement

Mejora de calidad de respuesta: capability answers, observe enrichment, reasoning template, creative profile, NO DISPONIBLE UX y metricas de calidad.

GitNexus UI Local Access (Backend URL Fix)

Por qué GitNexus UI puede quedarse en 'Waiting for server to start' cuando se accede remotamente y cómo fijar el backend URL (localStorage) o usar SSH tunnel.

Critical Path Analysis (37C)

Análisis híbrido del critical-path: file-level import graph + agregación por dominio (runtime/<folder>/). Metadata-only, bounded y determinista.

Graph Hotspot History (37D)

Histórico bounded de hotspots/chokepoints y drift_score determinista para detectar evolución topológica del runtime.

Governance Drift Detection (37E)

Detección de drift entre expectativas de governance y comportamiento real del runtime mediante señales de 37B/37C/37D, SLO y triage.

FASE 28 — Governed Agentic Runtime

Plan técnico completo para introducir workflows agentic seguros, gobernados y reversibles en AI-LAB. Action Intent Layer, approval con tickets firmados, risk determinista, rollback transaccional, sandbox con confinamiento, simulation-only mode y observabilidad completa.

FASE 29.0 — ROCm vs Vulkan Benchmark

Comparativa de rendimiento entre los backends Vulkan y ROCm de llama.cpp v2.14.0 en RX9070 con qwen2.5-coder-14b-instruct. 20 requests por backend, midiendo latencia, tokens/sec y consistencia.

FASE 29.2 — Real Streaming & TTFB Architecture

Eliminación del pseudo-streaming y activación de streaming real end-to-end con relay de chunks nativos desde llama.cpp. Feature flag AI_LAB_REAL_STREAMING, backpressure, timeouts en 4 capas y primeras métricas de TTFB real.

FASE 29.3 — Three-Model Runtime Simplification

Simplificación del runtime a 3 modelos estables: llama-3.1-8b para tareas ligeras, qwen2.5-coder-14b para coding/report/reasoning, y nomic-embed para embeddings. qwen3.6-27b desactivado.

FASE 29.3.1 — Routing Tightening & Latency Optimization

Optimización determinista del routing para que greetings, short prompts y observe vayan siempre a llama-3.1-8b. qwen2.5-14b se reserva para coding, architecture y reasoning profundo. 48 greeting markers, is_lightweight_prompt(), QWEN_ESCALATION_REASONS.

FASE 29.3.2 — SLO Baseline & Post-Routing Burn-In

Burn-in de 45 minutos validando el impacto del routing tightening. TTFB p50 reducido a 804ms (-29%), 100% success rate, 0 crashes, 0 qwen3.6 usage. SLO baseline establecida.

Gateway Graceful Shutdown

Manejo de apagado limpio del gateway para evitar SIGKILL por timeout de systemd y rechazar peticiones nuevas de forma controlada durante shutdown.

FASE 29.4 — SLO Enforcement & Adaptive Runtime Protection

De SLO pasivo a runtime auto-protegido. SLO enforcement engine con estados GREEN/YELLOW/RED, adaptive degradation (LEVEL 0-3), priority lanes, adaptive concurrency y circuit breakers observables. DRY RUN primero — toda accion es reversible y feature-flagged.

FASE 29.4.1 — Report Runtime Grounding Fix

Los reportes pesados (informe técnico, estructura general, detallado) ahora reciben OBSERVED_RUNTIME real en lugar de una referencia vacía. Nuevo módulo runtime/context/report_runtime_context.py, prompt externo en runtime/prompts/report_prompt.md, y 4 métricas Prometheus nuevas.

Runbook — FASE 29.4 SLO Enforcement & Adaptive Runtime Protection

Runbook operativo para verificar, diagnosticar y actuar sobre el SLO enforcement runtime. Incluye queries rapidas, interpretacion de estados, procedimientos de dry-run a enforcement activo, y troubleshooting de metricas.

FASE 28.1 — Planner Runtime Skeleton

Esqueleto del planner agentico con DAG readonly, dependencias deterministas, permission scopes, governance pre-hooks y estados preparados para ejecución futura. Sin ejecución real todavia.

FASE 29.4.2 — Report Grounding Presentation Fix

Convierte los reportes AI-LAB de chatbot genérico a informes operacionales NOC con clasificación precisa de modelos (active/disabled/discovered), nodos (active/inventory), servicios (core/support/observability), calidad de datos (observed/inferred/missing), estructura fija de 12 secciones, tono técnico y metadatos de reporte.

FASE 28.2 — Executor Readonly Runtime

Ejecutor readonly con subprocess seguro (shell=False), catálogo de comandos validados, governance pre-ejecución, audit trail JSONL con hashes SHA-256 y 6 métricas Prometheus.

FASE 29.4.3 — Runtime Identity Grounding Fix

Corrige el problema de identidad runtime: hostname ubuntu-ialab y IP 192.168.1.30 son la misma entidad. El runtime ahora conoce explícitamente primary_runtime_ip, runtime_identity y target_runtime_match, eliminando falsas negaciones 'AI-LAB no está levantado en 192.168.1.30'.

Informe Operacional Exhaustivo — AI-LAB

Reporte NOC completo del estado actual de AI-LAB en 192.168.1.30, incluyendo routing, modelos, GPU, SLO, planner, servicios y estado de fases.

FASE 28.3 — Sandbox Write Runtime

Executor de mutaciones sandbox con Python I/O (nunca subprocess), snapshot SHA-256 pre-mutación, rollback con validación checksum post-restore, governance con chmod prohibition, rate limiting, budget por workflow, artifact registry con lineage DAG, auditoría JSONL con mutation_class y 7 métricas Prometheus.

FASE 29.4.4 — Error Taxonomy & Failure Attribution

Elimina la caja negra de ailab_errors_total. Convierte todos los errores runtime en eventos clasificados, atribuibles y observables con taxonomy de 31 categorías, severity, recoverability, origin stage, attribution engine y structured logs.

Integración de Memoria Estructural GitNexus

Experimento: integrar GitNexus como memoria estructural del codebase AI-LAB. Indexación local, dependency graph, blast radius, ownership y structural risk scoring.

ROADMAP Legacy — AI-LAB Arquitectura Final

Hoja de ruta histórica previa al baseline 30I-D. Se conserva como referencia legacy y no sustituye la estructura roadmap normalizada actual.

Informe Completo AI-LAB

Inventario detallado de la VM, Astro, runtime, stacks y estado operativo actual del laboratorio.

AI-LAB Astro Visual System

Estándar visual y checklist de publicación para páginas Astro de AI-LAB.