21 de julio de 2026 · CreaRack Pro v1.61.5 en producción · para Txell y Dani. Esta es la versión
.mddel informe — la versión completa con gráficos es el HTML del mismo nombre.
En sencillo
CreaRack dibuja el plano de los racks; el Agente ve qué equipos hay funcionando de verdad. La Barra de Integridad es una nota de 0 a 100 por rack que dice cuánto se parece el plano a la realidad, y que baja sola cuando algo cambia en la red y nadie actualiza el dibujo. Cuando el sistema confirma que un cambio es real, abre una incidencia con una explicación escrita en claro, y al resolverla el plano y la nota se ponen al día solos. Todo está apagado para clientes: solo lo vemos nosotros mientras medimos si el detector acierta. Si en una red ajena acierta el 80% o más, se enciende y se vende; si no, se rediseña o se descarta.
1. Estado del plan
| Fase | Qué es | Versión | Estado |
|---|---|---|---|
| F1 · Motor | Cruce plano↔realidad: clasifica equipos y calcula las dos notas. Foto diaria 04:15 | v1.59.0 | ✔ En producción |
| F2 · Radar interno | Página Integrity: notas, histórico y cola de revisión con 3 veredictos | v1.60.0 | ✔ En producción |
| F3 · CNS/ITSM | Cambio confirmado → incidencia con explicación de la IA; resolver = re-verificar | v1.61.0 | ✔ En producción |
| Pulido | Textos EN + 4 arreglos de monitorización cazados al verificar el sensor | v1.60.1 · v1.61.1→.5 | ✔ En producción |
| F4 · Cara externa | Racha por sitio + bloque en el Project Report | — | ◌ Aparcada a propósito |
| Calibración | Foto diaria en la oficina + veredictos nuestros | — | ▶ En marcha |
| Validación | El examen en red ajena contra el umbral pre-declarado | — | ◷ Septiembre-octubre |
El plan está concluido en todo lo que dependía de construir. F4 y la activación comercial esperan al examen — por diseño, no por retraso.
2. La Barra de Integridad
La documentación de racks se pudre en silencio: alguien sustituye un servidor, no actualiza el plano, y seis meses después el plano miente. Como el Agente ve la red de verdad, la Barra compara continuamente "lo que el plano dice" con "lo que la red demuestra".
Las dos notas (un solo número mentiría):
- Coverage — ¿qué porcentaje de los equipos del plano puede observar el sensor?
- Fidelity — de lo observable, ¿cuánto cuadra con el plano? Esta es la que decae sola.
Regla de oro: lo que el sensor no puede ver va a cuarentena y jamás baja la fidelity — un MSP no puede sacar mala nota por física de red.
Las cinco clases que asigna el motor cada madrugada:
| Clase | Significado |
|---|---|
| matched_alive | En el plano y vivo en la red. El caso feliz |
| matched_stale | En el plano pero días sin señales de vida. ¿Retirado? ¿Apagado? |
| ip_conflict | Dos equipos comparten IP de gestión. Huele a sustitución o clonado |
| unobservable | El sensor no puede verlo. Cuarentena: ni puntúa ni castiga |
| undocumented | Vivo en la red pero en ningún plano. Se reporta a nivel de organización |
El radar interno (página /integrity/, módulo activado solo en nuestra org): cada aviso llega con su evidencia y el técnico dicta uno de tres veredictos — Plan updated (corregí el plano), Real change (abre incidencia), False alarm (a cuarentena silenciada). Cada veredicto alimenta automáticamente el contador señal/ruido del examen: usar el producto ES calibrarlo.
Límite honesto: el Agente ve el qué (existencia, vida, identidad), no el dónde físico. Una mudanza dentro de la misma red no es detectable sola — por eso la confirmación humana está siempre en el circuito.
3. El examen antes de vender (gate)
Umbral declarado por escrito antes de mirar datos (17-07-2026):
| % de avisos que resultan reales | Decisión |
|---|---|
| ≥ 80% | GO — activar y vender |
| 60-80% | Rediseñar el emparejado |
| < 60% | KILL del empaquetado (el score mentiría) |
La oficina solo calibra; la validación de verdad será en la red de un design partner (sept-oct). Seguimiento: task #202.
4. El puente con las incidencias (F3)
En vez de inventar un sistema nuevo, la cola de la Barra desemboca en el CNS/ITSM que ya existe:
- El probe diario detecta un posible cambio y lo pone en la cola con su evidencia.
- El técnico dicta "Real change" → se abre una incidencia CNS con la explicación de la IA en claro ("parece que sustituyeron el servidor del rack 3, ¿actualizo el plano?"). Documental, sin comandos, caduca a los 14 días.
- Resolver = reconciliar: al cerrar la incidencia, el próximo probe re-verifica. Si el plano quedó bien, la nota sube; si no, vuelve a avisar.
- Regalo: el historial de incidencias resueltas alimenta gratis el informe trimestral del MSP.
5. CNS en dos palabras
CreaRack Network Sentinel vigila la red (Observatory, Wireless, UPS) y ante una anomalía genera un Insight: diagnóstico con causa raíz, confianza (0-100%), riesgo (HIGH/MEDIUM/LOW), telemetría y comandos con su rollback. Estados: Pending → Applied / Acknowledged / Expired (4 h) / Failed. Con Explain le preguntas a la IA con el contexto del caso cargado; las conversaciones quedan guardadas en el insight. Los patrones recurrentes y los grupos de incidentes filtran el ruido: un fallo de uplink que tumba 5 APs es un grupo, no cinco alarmas.
6. ITSM en dos palabras
La disciplina de gestión encima del CNS: SLA por riesgo (HIGH: ack 15 min / resolver 60 min · MEDIUM: 30 min / 4 h · LOW: 60 min / 8 h, personalizables), canales de notificación (email, Slack, Teams, webhook) filtrables por riesgo, escalado en 3 niveles si nadie responde, ventanas de mantenimiento que suprimen alertas, y known issues + runbooks que aparecen como badge cuando un insight nuevo coincide con un problema documentado.
7. La foto real de la oficina
Al encender el sensor para calibrar salieron cuatro bugs encadenados de la monitorización, arreglados y desplegados el mismo día (v1.61.1→.5): el ingest bulk no contaba como prueba de vida, los replays del Agente machacaban el estado vivo (130/131 caídos falsos), la lista de incidencias salía invertida, y faltaba el control de orden. Resultado verificado en producción: 88 equipos vivos / 43 caídos reales de 131 monitorizados. El motor se ganó el sueldo antes de estrenarse: su primera medición detectó que el propio sensor estaba dormido.
8. Qué queda y quién lo tiene
- Gate señal/ruido (task #202) — Edu, sept-oct, validación en red ajena.
- F4 cara externa — tras el feedback MSP.
- Task #203 — throttle del re-envío histórico del Agente + flapping del WS (próximo
.exe). - Hueco anotado sin fecha:
resolved_atde las incidencias no lo rellena ningún flujo.
Fuentes: plan vivo barra-integridad/PLAN_BARRA_INTEGRIDAD.md · STATE.md s227-s229 · guía crearack-tech--guides--cns-itsm-user-guide · tasks #202/#203.