Release v2026.10.4 — Mission Control madura

Operar una flota de empleados digitales exige dos cosas opuestas: potencia total (cross-tenant, runs, puentes, credenciales) y calma (que la pantalla no sea una ensalada de IDs internos). Este release ataca ambas.

---

La interfaz respira

Mission Control se consolidó: navegación por secciones con tabs, canvas de contenido pensado para 1920×1080, y humanización de identificadores — el operador lee _"la recepcionista del Sauce no pudo cobrar"_ donde antes leía rt-F50 / emp-80 / run-20. El código técnico sigue ahí, pero como metadata secundaria, nunca de titular.

El nacimiento del Orbi, guiado

Crear un empleado para un cliente dejó de ser un formulario denso. Ahora es un wizard de 7 pasos — Cliente → Identidad → Relevamiento → Propuesta → Pruebas → Firmas → Lanzamiento — con un rail lateral tipo ficha de personaje: el avatar del Orbi cambia de estado según el paso (escuchando, pensando, hablando). Cada paso se desbloquea con evidencia real del anterior; la navegación es server-driven (?paso=), y los detalles técnicos (el DiscoverySpec JSON, por ejemplo) quedan tras disclosure progresivo.

El Centinela

Mission Sentinel es el primer guardián autónomo de la flota: un daemon liviano que cada 15 minutos recorre la telemetría cross-tenant — workers caídos, clústeres de fallas por causa raíz, puentes que dejaron de latir — y persiste _findings_ deduplicados con severidad y una acción sugerida.

La regla de oro: propone, nunca muta. El finding dice _"la rutina de reservas debería pausarse"_ con el payload listo; la ejecución solo ocurre cuando un operador — humano o agente — la corre por el seam auditado.

Herramientas para agentes de ingeniería

basiliskctl mcp:operator abre un servidor MCP por stdio (JSON-RPC) para que Claude Code, Cursor o Antigravity operen la flota con herramientas tipadas:

roster_fleet_overview     salud cross-tenant
roster_tenant_360         detalle completo del cliente
roster_list_incidents     incidentes por causa raíz
roster_trace_run          veredicto + eventos (secretos redactados, DLP)
roster_sentinel_findings  hallazgos del centinela
roster_pause_routine      MUTACIÓN auditada
roster_trigger_lan_scan   MUTACIÓN auditada

Sin ORBIS_MISSION_TOKEN el servidor ni arranca. Las mutaciones escriben en mission_actions con actor: "mcp:operator" — el éxito y el rechazo quedan registrados por igual. Y el plano de clientes jamás ve esta capa: un token de tenant no habilita nada acá.

---

Honestidad operativa

El Sentinel v1 es determinístico deliberadamente: detecta lo que la telemetría ya sabe y lo redacta en lenguaje claro. No hay un LLM decidiendo solo. Cuando madure la evaluación asistida, las propuestas se enriquecerán — la mutación seguirá siendo humana.

Release v2026.10.3 — La firma ya no pide tokens

El último paso antes de que un Orbi empiece a trabajar es contractual: el cliente revisa la propuesta — qué va a hacer, con qué límites — y la firma. Hasta ayer ese gesto pedía un ownerToken: un secreto tipo rb_live_… que un dueño de hotel jamás debería manejar.

Este release elimina la fricción sin renunciar a la gobernanza.

---

Puntos Destacados del Release

• Firma con un tap: cuando Basilisk firma su lado de la propuesta, el sistema mintea un magic link (token aleatorio de 128 bits, hash SHA-256 persistido, un solo uso, 24 horas) y lo entrega al WhatsApp registrado del dueño: _"✍️ Camila — tu nueva recepcionista digital — está lista para tu firma."_ El link aterriza directo en la tarjeta de la propuesta.
• La sesión ES la segunda firma: la cookie firmada con rol dueño reemplaza al token — el control de dos personas (Basilisk propone, dueño autoriza, jamás el mismo userId) queda intacto. El token sigue existiendo para rotaciones de vault, donde pertenece.
• /desbloquear self-serve: el cliente entra su email o WhatsApp registrado y recibe el link por el mismo canal. Sin operador, sin espera. El campo @ decide la vía.
• White-glove cuando hace falta: si el cliente todavía no tiene canal vinculado, el operador recibe el link copiable para entregarlo a mano — el piloto sigue siendo concierge.
• El cliente firma a su empleado, no a un plan: la tarjeta de propuesta muestra el avatar y nombre del Orbi definido en el paso de identidad.

Seguridad de un endpoint público

/desbloquear es la puerta — pública por definición. La matriz de amenazas quedó cerrada:

Vector	Postura
Enumeración de usuarios	Respuesta byte-idéntica exista o no el contacto; el link jamás viaja en el body
Spam al cliente	Cooldown de 120 segundos por usuario — el re-pedido responde ok pero no re-envía
Flood	Rate-limit dedicado (10 pedidos/10min por IP)
PII en logs	El trail de auditoría enmascara (j…n@dom.com, ***6789)
Open-redirect	El destino post-login lo define el servidor; validación por charset hace imposible expresar un host externo

WhatsApp queda en su lugar correcto: timbre, no firma. El contrato de diseño se lee en la tarjeta antes de aprobarse.

Release v2026.10.2 — El Orbi vive en la máquina del cliente

Hasta este release, un Orbi provisionado ejecutaba su trabajo desde nuestra infraestructura. Eso funciona para APIs públicas, pero el software que importa en una pyme o un hotel — el PMS de escritorio, el ERP en un servidor del fondo, la carpeta compartida de facturas — no tiene URL pública.

Fase O (O1–O6) convierte al Edge Bridge en un host de ejecución completo: el mismo puente que ya sondeaba la LAN ahora corre los runs del empleado dentro de la red del cliente. El panel jamás abre una conexión entrante; el edge sale por HTTPS, trae el trabajo, lo ejecuta y devuelve evidencia firmada.

---

Puntos Destacados del Release

• Lane de ejecución embebido: el proceso orbis-edge (un binario único, sin dependencias) levanta un harness completo en la máquina del cliente. El run remoto es indistinguible del local: mismos checkpoints, mismas métricas, mismo trail.
• Artefactos digest-bound: conocimiento, manifests de conectores y el plan de deployment viajan como artifact.push verificado por SHA-256 antes de persistir en el CAS local del edge. El run solo resuelve desde el CAS — nunca del cuerpo del comando.
• Cero secretos en reposo: cuando una tool remota necesita credenciales, las resuelve por llamada contra el panel (POST /api/edge/credentials/resolve). El valor vive en memoria del proceso durante ese call — jamás en sqlite, jamás en un envelope, jamás en el trail.
• Aprobaciones remotas reales: una tool que exige needsApproval ya no cierra el run en FAILED. El run se suspende con checkpoint durable, la tarjeta aparece en /decisiones del dueño como cualquier otra, y la decisión vuelve al edge como comando firmado run.resume. El humano sigue en el loop — aunque el empleado esté a 300 km de la nube.
• Telemetría sin fricción: cada RunEvent sube como envelope run.event y el panel lo appenda al runs.db del tenant. /trabajo lee runs remotos idénticos a los locales.
• Supervisión gobernada: run.cancel, kill-switch por feature flag y pinning multi-bridge — todo por el canal firmado, todo auditado.

Por qué importa

La promesa de Orbis siempre fue "un empleado que trabaja donde trabaja tu equipo". Hasta acá eso significaba WhatsApp + conectores cloud. Con este release, el Orbi también opera el software que solo existe dentro de la red del cliente — sin VPN, sin exponer puertos, sin que las credenciales del PMS salgan de la memoria del proceso que las usa.

La arquitectura sigue siendo la misma promesa de siempre, empujada una capa más adentro: el panel propone, el edge ejecuta, la evidencia vuelve firmada.

Release v2026.10.1 — Unidades de Trabajo (UT)

Hoy oficializamos en toda la documentación técnica, contratos comerciales, paneles de control y APIs la transición definitiva hacia Unidades de Trabajo (UT) como la métrica oficial en español para medir la capacidad de ejecución de los empleados digitales.

Esta actualización responde directamente a los aprendizajes de nuestros primeros despliegues en clientes de hospitalidad y servicios corporativos: el mercado hispanohablante rechaza los anglicismos innecesarios y desconfía profundamente de los esquemas opacos de "créditos de IA" o facturaciones imprevistas por tokens de inferencia.

---

Puntos Destacados del Release

• Erradicación del anglicismo "Work Units": Tanto en las propuestas comerciales como en las interfaces de usuario del panel web se adopta formalmente la denominación Unidades de Trabajo (UT).
• Claridad en escala: Descartamos términos discretos ambiguos como "gestiones" que generaban confusión matemática al fraccionar tareas en decimales (ej: 1.5 unidades para una reserva compleja).
• Presupuesto de Seguridad (maxWuPerDay): Se refuerza el circuit breaker diario en el motor de ejecución (jobs.db) para garantizar que ningún agente pueda superar el límite presupuestario acordado sin aviso previo.
• Alertas proactivas por WhatsApp: El dueño recibe notificación inmediata al alcanzar el 80% del límite mensual con números reales y sin tecnicismos.

---

Arquitectura de Metrología en el Motor

Detrás de cada Unidad de Trabajo no hay una estimación arbitraria, sino un libro mayor inmutable (_wu-ledger_) que opera con aritmética de enteros:

[Invocación de Tarea]
        │
        ▼
[Pre-Check de Presupuesto] ─── SqliteUsageBudget en jobs.db
        │
        ├── ¿Excede maxWuPerDay? ──► Pausa preventiva + Alerta WhatsApp
        │
        └── ¿Presupuesto OK? ──────► Ejecución autorizada
                                          │
                                          ▼
[Registro en Ledger] ───────────── Cálculo en milliWU (1 UT = 1.000 milliWU)
                                   Sin errores de punto flotante

1. Eliminación del Error de Redondeo

Para evitar inconsistencias en facturaciones acumuladas, el libro mayor almacena el uso en milliWU enteros. Una tarea que consume 0.25 UT se almacena exactamente como 250 milliWU, eliminando los desvíos característicos de operaciones float en bases de datos.

2. Estimación Pre-Ejecución

Antes de disparar tareas complejas de back-office (como una conciliación contable o un bloqueo masivo en PMS), el motor proyecta el gasto basándose en la mediana histórica del tenant. El operador o cliente puede consultar en todo momento el costo estimado previo y contrastarlo con el consumo real en el rastro inmutable (_The Trail_).

---

Impacto y Compatibilidad

• Contratos vigentes: Todos los retainers activos mantienen su capacidad garantizada intacta bajo la nueva denominación 1:1 (1 WU = 1 UT).
• Endpoints de API: Las rutas internas de telemetría y webhooks mantienen compatibilidad binaria transparente.

Release v2026.10.0 — Edge Bridge LAN

Presentamos la versión 1.0 del Edge Bridge, el daemon de conectividad perimetral de Orbis diseñado específicamente para instalaciones hoteleras, clínicas y sedes corporativas con infraestructura local (_on-premise_).

En sectores con sistemas heredados (_legacy_), la mayoría de los motores de reservas y sistemas de gestión (PMS como MiniHotel, Fidelio o bases de datos SQL locales) se ejecutan en computadoras de escritorio bajo el mostrador de recepción. Exponer estas máquinas abriendo puertos en el router o montando VPNs complejas es frágil ante caídas de IP pública y peligroso a nivel de ciberseguridad.

El Edge Bridge resuelve este problema de raíz: cero puertos abiertos de entrada y conexión saliente cifrada.

---

Puntos Destacados del Release

• Canal Criptográfico Outbound-only: Conexión HTTPS inversa hacia el control plane autenticada mediante HMAC-SHA256 y tokens rotativos (bridges.token_hash). El panel central jamás intenta conectarse a la IP del hotel.
• Sondeo LAN Seguro (lan.scan): Detección pasiva de servicios HTTP en la subred privada local para facilitar el mapeo de sistemas de reservas sin configuración manual de IPs.
• Confirmación Humana de Sistemas: Los hallazgos del escáner no se activan automáticamente; requieren confirmación explícita del supervisor en el panel web antes de emitir cualquier petición.
• Vigilancia de Disponibilidad (system.health): Notificación automática e instantánea al dueño en caso de caída del servidor local del cliente antes de afectar la atención a huéspedes.

---

Arquitectura de Conexión y Protocolo de Envelopes

RED PRIVADA DEL HOTEL                             NUBE DE ORBIS
┌─────────────────────────────────┐               ┌───────────────────────────────┐
│ Servidor PMS Local              │               │ Orbis Control Plane           │
│ [192.168.1.50:8080]             │               │ (API Cifrada)                 │
└────────────────▲────────────────┘               └───────────────▲───────────────┘
                 │ Sondeo interno                                 │
┌────────────────┴────────────────┐               HTTPS Saliente  │ Envelopes v2
│ Edge Bridge Daemon              ├────────────── (Outbound Only) ┘ (HMAC-SHA256)
│ • Token Hash en SQLite          │
│ • Enrolamiento RFC 8628         │
│ • Cola Outbox At-Least-Once     │
└─────────────────────────────────┘

1. Envelopes Criptográficos Versión 2

Toda la telemetría y ejecución de comandos viaja empaquetada en envelopes firmados:

• Carga normalizada en JSON canónico: { v: 2, tenant, key, kind, at, body }.
• Firma HMAC-SHA256 derivada de la clave única del puente (sha256(token)).
• Verificación fail-closed: peticiones sin firma o manipuladas se descartan en milisegundos con error 401.

2. Emparejamiento por Dispositivo (Device Flow RFC 8628)

El instalador ejecuta un único comando en la sede local. El sistema emite un código de vinculación de 6 caracteres que el supervisor valida desde el panel web. El servidor entrega un token de uso único y destruye la versión en texto claro, persistiendo solo su hash irreversible.

---

Detección Proactiva de Caídas de PMS

La mayor pesadilla de un hotelero es enterarse de que el PMS se cayó porque un huésped intentó reservar y recibió un mensaje de error.

El Edge Bridge monitorea la salud del sistema local cada 30 segundos. Si el servidor deja de responder durante dos sondeos consecutivos, Orbis deriva un incidente crítico (system_down) y despacha una alerta al WhatsApp del dueño:

_"🚨 Alerta en Sede Centro: El servidor PMS local dejó de responder (puerto 8080 inaccesible). Verificá la máquina de recepción."_

Release v2026.9.3 — Egress DLP & Aprobaciones 4-Eyes

Desplegamos la suite integral de seguridad y gobernanza humana para toda la flota de empleados digitales, incorporando prevención de fuga de datos en el egreso (_Egress DLP_) y el protocolo de autorización humana en bordes de riesgo (_4-Eyes Principle_).

En entornos de atención al cliente y gestión de pagos, permitir que un modelo de lenguaje emita respuestas al exterior sin filtros previos es un riesgo inaceptable de filtración de datos sensibles (_PII_) o claves de sistema.

---

Puntos Destacados del Release

• Escáner Egress DLP Pre-WhatsApp: Todo mensaje saliente hacia canales externos pasa por un escáner de egreso que redacta datos de tarjetas de crédito y bloquea la filtración de variables de entorno o tokens.
• Protocolo de Aprobación 4-Eyes: Las acciones que involucran dinero, reembolsos o modificaciones contractuales se suspenden automáticamente en estado pending.
• Tarjetas de Decisión en WhatsApp: El supervisor recibe una notificación instantánea con el identificador unívoco APR-<runId> y puede autorizar o denegar respondiendo con una sola palabra ("sí" o "no").
• Blindaje Anti-Prompt Injection: Las salidas de herramientas y los textos de usuarios externos se entregan al modelo encapsulados en etiquetas trust="untrusted", previniendo que instrucciones maliciosas ocultas tomen el control del agente.

---

Arquitectura del Escáner de Egreso

[Empleado Digital genera respuesta]
                 │
                 ▼
     [Escáner Egress DLP]
           ├── Detección de Tarjetas de Crédito ──► REDACCIÓN (ej: **** **** **** 4819)
           ├── Detección de Documentos / PII    ──► TOKENIZACIÓN PROTEGIDA
           ├── Detección de Claves de API / Env ──► BLOQUEO TERMINAL + INCIDENTE
           │
           ▼
  [Mensaje Seguro Saliente] ──► WhatsApp / Email

El escáner corre en el límite de la red (_boundary check_) y es fail-closed: si el proceso de escaneo encuentra cualquier anomalía crítica, la llamada al exterior se aborta y se genera un registro en el libro de auditoría.

---

Resolución de Aprobaciones Inequívoca

El sistema de aprobaciones por WhatsApp utiliza un parser estricto con normalización Unicode:

• Si el supervisor responde sí o aprobar APR-812, el estado en jobs.db cambia a granted y la tarea se reanuda de inmediato.
• Si el mensaje es ambiguo o el supervisor tiene múltiples aprobaciones pendientes y responde simplemente "sí", el sistema responde pidiendo el ID exacto: _"Tenés 2 aprobaciones pendientes. Por favor respondé 'APR-812' o 'APR-813' para confirmar cuál autorizás."_

Release v2026.9.2 — Learning Hub & Memoria Estratificada

Presentamos el Learning Hub, el motor de mejora continua supervisada de Orbis, acompañado por la reestructuración completa del sistema de memoria operativa en tres capas independientes.

Muchos sistemas de agentes autónomos caen en la trampa de la auto-modificación descontrolada (_prompt drift_), donde el modelo altera sus propias reglas en caliente y degrada la calidad de servicio con el paso de las semanas. El Learning Hub resuelve este problema separando la captura de evidencia de la decisión humana.

---

Puntos Destacados del Release

• Daemon de Barridos Periódicos: Proceso en segundo plano que analiza cada 6 horas la evidencia durable acumulada (errores de herramientas, solicitudes de aprobación resueltas, patrones de conversación).
• Propuestas de Reglas de Auto-Aprobación (rule_suggestion): Detección de patrones repetitivos donde un supervisor aprueba sistemáticamente la misma acción para sugerir reglas seguras acotadas.
• Cero Auto-Mutación: Toda propuesta generada por el sistema queda en estado pending en la pantalla /propuestas y requiere confirmación explícita de un supervisor para integrarse en la próxima revisión del plan.
• Memoria Estratificada con TTL: La memoria operativa de baja confianza expira automáticamente a $\le 7$ días (LOW_CONFIDENCE_MAX_DAYS), eliminando alucinaciones acumuladas.
• Knowledge Packs Compilados (name@pin): Paquetes normativos sellados criptográficamente que se inyectan en el prefijo del prompt para aprovechar el _prefix caching_ de los proveedores de IA.

---

El Ciclo de Aprendizaje en la Práctica

[Operación Diaria] ─── Registros de runs, fallos y approvals en runs.db
        │
        ▼
[Barrido Periódico (Daemon)] ─── Análisis no intrusivo sin consumo de UT cliente
        │
        ▼
[Bandeja de Entrada en /propuestas]
        ├── "¿Querés auto-aprobar cotizaciones de estadías ≤ 3 noches?"
        ├── "¿Querés sumar este caso límite a los tests de calidad?"
        │
        ▼
[Decisión Humana] ─── El supervisor hace clic en APROBAR
        │
        ▼
[Compilación de Revisión] ─── Se sella el nuevo plan firmado criptográficamente

Este ciclo garantiza que la flota aprenda y mejore con la experiencia real del negocio, pero siempre manteniendo el control estratégico en manos del equipo humano.

Release v2026.9.1 — Canal del Dueño & Watchdog

Inauguramos el canal bidireccional de control para el dueño del negocio a través de su propio WhatsApp personal, junto con el supervisor de salud de canal (_Channel Watchdog_) para la API de WhatsApp Business.

Los gerentes de hoteles y dueños de empresas no tienen tiempo de monitorear paneles web todo el día. Necesitaban una forma de enterarse al instante si algo requiere su atención, autorizar decisiones sobre la marcha y hacer consultas rápidas de estado sin fricción.

---

Puntos Destacados del Release

• Vinculación Directa por Número E.164: Enlace seguro del número personal del dueño con verificación en dos pasos desde la pantalla de configuraciones.
• Comandos Interactivos del Dueño: Capacidad de enviar mensajes directos como estado, incidentes, pendientes o pausar [rol] para recibir reportes instantáneos.
• Watchdog de Facturación Meta (waba_billing): Detección temprana de problemas de cobro en tarjetas registradas en Meta antes de que suspendan la línea de atención al cliente.
• Protocolo Anti-Flapping: Garantía de notificación única por incidente, evitando cadenas molestas de mensajes si un servicio titila.
• Digest Ejecutivo Semanal: Envío programado todos los lunes a las 09:00 AM con métricas claras de reservas cerradas, horas ahorradas y consumo de UT.

---

Comandos Disponibles para el Dueño

DUEÑO ──► "estado"
ORBIS ──► "📊 Estado de hoy (Sede Centro):
           • 32 conversaciones atendidas
           • 8 cotizaciones emitidas
           • 3 reservas confirmadas
           • Consumo: 4.8 UT (Dentro de los parámetros previstos)
           • Todo el personal digital operando con normalidad."

DUEÑO ──► "incidentes"
ORBIS ──► "✅ No hay incidentes activos en este momento."

Si el dueño envía un mensaje que no coincide con un comando conocido o una orden de aprobación, el sistema responde con un menú conciso de opciones sin inventar respuestas.