| # OpenSkyNet: Integración de OpenClaw + SKYNET_OMEGA |
| |
| ## 1. Propósito |
| |
| `OpenSkyNet` nace como una unificación pragmática: |
| |
| - **OpenClaw** ya era un host sólido de ejecución: |
| - sesiones |
| - tools |
| - gateway |
| - TUI |
| - subagentes |
| - delivery multicanal |
| - **SKYNET_OMEGA** ya había producido mecanismos útiles, pero como sistema separado: |
| - validación estricta |
| - continuidad de sesión |
| - memoria local / edición local |
| - estudios sobre temporalidad, interferencia y corrección |
| |
| El problema del diseño anterior era claro: dos sistemas separados intentando coordinarse por bridge externo, con duplicación de policy, cierre frágil y riesgo de falsos positivos. |
| |
| La idea central de `OpenSkyNet` es: |
| |
| **mantener a OpenClaw como host/runtime principal e incrustar dentro de ese host la capa útil de OMEGA.** |
| |
| No es una “fusión caótica”. Es una integración por capas. |
| |
| --- |
| |
| ## 2. Arquitectura de Marco |
| |
| ### 2.1 OpenClaw como sustrato host |
| |
| OpenClaw sigue aportando: |
| |
| - CLI/TUI |
| - gateway de sesiones |
| - tool calling |
| - spawn y coordinación de subagentes |
| - transporte y delivery |
| - infraestructura de plugins |
| - runtime operativo general |
| |
| En otras palabras: |
| |
| **OpenClaw es el sistema nervioso periférico y el plano de ejecución.** |
| |
| ### 2.2 OMEGA como capa cognitiva embebida |
| |
| Dentro de `OpenSkyNet`, OMEGA aporta tres familias de capacidades: |
| |
| 1. **Control y validación** |
| 2. **Memoria operativa persistente** |
| 3. **Mecanismos cognitivos embebidos reutilizables** |
| |
| Esto quedó dividido en dos capas: |
| |
| - **capa TS operativa**, conectada al host real |
| - **capa Python embebida**, donde vive el core matemático de OMEGA |
| |
| --- |
| |
| ## 3. Qué se integró realmente |
| |
| ## 3.1 Capa operativa OMEGA en TypeScript |
| |
| La integración operativa vive en: |
| |
| - `src/omega/` |
| - `src/agents/tools/omega-*.ts` |
| |
| Estas piezas ya están conectadas al runtime real del host. |
| |
| ### A. Validación estructurada |
| |
| Archivo: |
| |
| - `src/omega/validator.ts` |
| |
| Qué hace: |
| |
| - valida si una respuesta cumple contrato JSON |
| - valida si están las `expectedKeys` |
| - valida si hubo cambios reales en disco |
| - valida si se tocaron **todos** los archivos requeridos, no solo uno |
| |
| Esto corrige uno de los defectos clásicos del padre: |
| |
| **OpenClaw base podía aceptar un run “accepted” aunque el trabajo no estuviera realmente bien cerrado.** |
| |
| OMEGA añade: |
| |
| - rechazo de JSON inválido |
| - rechazo de falso éxito sin delta real |
| - rechazo de edición parcial multiarchivo |
| |
| ### B. Verificación de delta real en disco |
| |
| Archivos: |
| |
| - `src/omega/observed-write.ts` |
| - `src/omega/session-task.ts` |
| |
| Qué hace: |
| |
| - toma línea base de archivos esperados |
| - observa cambios reales tras el run |
| - compara contra `expectedPaths` |
| - rechaza el resultado si el target no fue realmente modificado |
| |
| Esto transforma el cierre del agente desde: |
| |
| `"el modelo dijo que editó"` |
| |
| a: |
| |
| `"el sistema verificó que sí editó y dónde editó"` |
| |
| ### C. Ejecución validada de runs |
| |
| Archivo: |
| |
| - `src/omega/session-task.ts` |
| |
| Qué hace: |
| |
| - dispara `agent` |
| - espera con `agent.wait` |
| - recupera la última reply |
| - aplica validación estructural |
| - aplica validación de escritura observada |
| - registra resultado en la memoria persistente de sesión |
| |
| Esta pieza es el corazón del cierre honesto de `OpenSkyNet`. |
| |
| ### D. Modelo del tipo de interacción |
| |
| Archivo: |
| |
| - `src/omega/interaction-model.ts` |
| |
| Clasifica el turno en: |
| |
| - `direct_instruction` |
| - `corrective_feedback` |
| - `verification_request` |
| - `analysis_request` |
| - `mixed_turn` |
|
|
| Esto importa porque no todo input significa lo mismo. |
|
|
| El sistema ya distingue, por ejemplo: |
|
|
| - “arregla esto” |
| - “verifica lo anterior” |
| - “explica por qué falló” |
| - “revisa y luego corrige” |
|
|
| Eso reduce confusiones entre análisis, verificación y edición. |
|
|
| ### E. Línea temporal causal verificable |
|
|
| Archivo: |
|
|
| - `src/omega/session-context.ts` |
|
|
| Qué guarda por sesión: |
|
|
| - historial de tareas |
| - validación pedida |
| - estado verificado del outcome |
| - archivos realmente tocados |
| - errores estructurados |
|
|
| Además persiste en: |
|
|
| - `.openskynet/omega-session-state/` |
|
|
| Esto evita el problema de “Alzheimer de sesión”. |
|
|
| No es un historial libre de chat. Es una **línea temporal de acciones verificadas**. |
|
|
| ### F. Estado mínimo del “yo” operativo |
|
|
| Archivo: |
|
|
| - `src/omega/event-model.ts` |
|
|
| El self-state persistente incluye: |
|
|
| - `activeGoal` |
| - `activeTargets` |
| - `requiredKeys` |
| - `lastInteractionKind` |
| - `lastTask` |
| - `lastOutcomeStatus` |
| - `lastErrorKind` |
| - `lastSuccessfulTask` |
| - `lastFailedTask` |
| - `learnedConstraints` |
|
|
| Esto no es conciencia fuerte. Pero sí es una forma operativa de identidad de sesión: |
|
|
| - qué estaba intentando hacer |
| - sobre qué archivos |
| - qué falló |
| - qué restricción aprendió |
|
|
| ### G. Routing OMEGA nativo |
|
|
| Archivo: |
|
|
| - `src/agents/tools/omega-work-tool.ts` |
|
|
| Qué hace: |
|
|
| - decide entre `sessions_send` |
| - `sessions_spawn` |
| - `omega_delegate` |
|
|
| La decisión ya no depende solo de un timeout o un path. Usa también: |
|
|
| - validación requerida |
| - cantidad de targets |
| - tipo de interacción |
|
|
| Con eso `OpenSkyNet` decide mejor cuándo: |
|
|
| - mandar algo directo |
| - aislar en subagente |
| - exigir cierre validado |
|
|
| ### H. Surface tools nuevos |
|
|
| Archivos: |
|
|
| - `src/agents/tools/omega-delegate-tool.ts` |
| - `src/agents/tools/omega-work-tool.ts` |
| - extensiones de: |
| - `sessions-send-tool.ts` |
| - `sessions-spawn-tool.ts` |
|
|
| Capacidad nueva: |
|
|
| - delegación con validación |
| - spawn con validación |
| - rechazo nativo de falsos positivos |
|
|
| En el padre, eso no existía como capa unificada. |
|
|
| --- |
|
|
| ## 3.2 Capa matemática/cognitiva embebida en Python |
|
|
| Ruta: |
|
|
| - `python/omega_py/` |
|
|
| Aquí vive el core portado desde `SKYNET_OMEGA`. |
|
|
| ### A. Core principal |
|
|
| Archivo: |
|
|
| - `python/omega_py/core.py` |
|
|
| Este core conserva la línea de investigación de OMEGA: |
|
|
| - `HolographicRetina` |
| - `HoloODEFuncWithForcing` |
| - `JEPAPredictor` |
| - `EpisodicFossilMemory` |
| - `NeuralLogicEngine` |
| - `LocalMemoryEditor` |
|
|
| Y expone perfiles: |
|
|
| - `canonical` |
| - `reasoning_clean` |
| - `local_editing` |
|
|
| ### B. Qué significa matemáticamente |
|
|
| El core no es un transformer clásico puro. |
|
|
| La idea de fondo es una arquitectura híbrida con: |
|
|
| 1. **dinámica continua** |
| - evolución del estado por ODE |
| - integración por `odeint_adjoint` |
|
|
| 2. **predicción autosupervisada** |
| - JEPA |
| - frustración como señal de plasticidad |
|
|
| 3. **memoria episódica/fósil** |
| - consolidación de trazas importantes |
|
|
| 4. **edición local explícita** |
| - reescritura localizada |
| - preservación del resto de la estructura |
|
|
| 5. **sesgo lógico** |
| - `NeuralLogicEngine` |
|
|
| En términos conceptuales: |
|
|
| **OMEGA busca que el estado no solo represente, sino que pueda corregirse localmente sin destruir el resto.** |
|
|
| ### C. LocalMemoryEditor |
|
|
| Archivo: |
|
|
| - `python/omega_py/components/local_memory_editor.py` |
|
|
| Esta es una de las piezas más importantes heredadas de los experimentos. |
|
|
| Separa tres responsabilidades: |
|
|
| 1. **focus_address** |
| - enfocar pocos slots de memoria |
| |
| 2. **write** |
| - escribir localmente con protección del resto |
| |
| 3. **fuse_context** |
| - reinyectar contexto local al estado final antes del actor |
|
|
| Matemáticamente, introduce: |
|
|
| - sharpening de direccionamiento |
| - compuertas de confianza |
| - protección de slots no objetivo |
| - supresión de escritura colateral |
| - fusión controlada del contexto local |
|
|
| Esta pieza no surgió de teoría vacía. Viene de la línea experimental que mostró que la propiedad más defendible de OMEGA era: |
|
|
| **edición local con preservación estructural bajo interferencia** |
|
|
| ### D. Qué sí se migró y qué no |
|
|
| Se migró: |
|
|
| - el core Python |
| - el runtime |
| - el `LocalMemoryEditor` |
| - los perfiles de core |
|
|
| No se migró todavía como ruta viva principal del razonamiento: |
|
|
| - la ejecución online del host no llama todavía al core Python como “motor pensante” principal en cada turno |
|
|
| Hoy esa capa está: |
|
|
| - **embebida** |
| - **instalable** |
| - **invocable** |
| - pero **no gobierna aún toda la cadena principal del razonamiento live** |
|
|
| Eso es importante para no sobre-vender el sistema. |
|
|
| --- |
|
|
| ## 4. Qué cosas hace OpenSkyNet que OpenClaw base no tiene |
|
|
| ## 4.1 Cierre honesto de tareas |
|
|
| OpenClaw base: |
|
|
| - puede ejecutar |
| - puede esperar resultados |
| - puede entregar respuestas |
|
|
| OpenSkyNet: |
|
|
| - además comprueba si el resultado cumple contrato |
| - además comprueba si realmente hubo cambios |
| - además persiste el outcome y lo usa en turnos futuros |
|
|
| ### Diferencia real |
|
|
| OpenClaw responde: |
|
|
| - “el run terminó” |
|
|
| OpenSkyNet responde: |
|
|
| - “el run terminó y además quedó verificado” |
|
|
| ## 4.2 Memoria persistente de sesión con semántica operativa |
|
|
| OpenClaw base tiene sesiones. |
|
|
| OpenSkyNet añade: |
|
|
| - self-state persistente |
| - timeline causal |
| - restricciones aprendidas desde errores reales |
|
|
| Eso significa que cerrar una sesión no equivale a vaciar toda la continuidad útil. |
|
|
| ## 4.3 Interpretación del input como interacción |
|
|
| OpenClaw base trata el turno sobre todo como mensaje/acción. |
|
|
| OpenSkyNet además intenta responder: |
|
|
| - ¿esto es una orden? |
| - ¿esto es feedback correctivo? |
| - ¿esto es verificación? |
| - ¿esto es diagnóstico? |
| - ¿esto mezcla análisis y acción? |
|
|
| Eso mejora el routing y reduce errores de modo. |
|
|
| ## 4.4 Routing cognitivo mínimo |
|
|
| OpenClaw base enruta principalmente por tool/command. |
|
|
| OpenSkyNet añade una capa que toma decisiones con: |
|
|
| - estructura requerida |
| - paths requeridos |
| - tipo de interacción |
| - aislamiento o no |
|
|
| ## 4.5 Puerta de entrada para razonamiento con memoria local |
|
|
| OpenClaw base no tiene un core cognitivo propio de edición local. |
|
|
| OpenSkyNet sí tiene embebido: |
|
|
| - el runtime Python de OMEGA |
| - el perfil `local_editing` |
| - el `LocalMemoryEditor` |
|
|
| Esto no significa que ya piense mejor en general. |
| Sí significa que el sistema tiene una dirección interna diferenciada para evolucionar más allá del host base. |
|
|
| --- |
|
|
| ## 5. Qué NO hay que afirmar todavía |
|
|
| Para mantener rigor, hay cosas que **no** se deben afirmar aún: |
|
|
| ### No está demostrado todavía: |
|
|
| - que `OpenSkyNet` razone mejor que OpenClaw base en inteligencia bruta del modelo |
| - que OMEGA ya sea una conciencia digital |
| - que el core matemático ya gobierne la ruta principal de deliberación multi-turno |
| - que la capa Python embebida haya reemplazado al runtime del modelo principal |
|
|
| ### Sí está demostrado: |
|
|
| - que `OpenSkyNet` es más confiable operativamente |
| - que detecta mejor falsos positivos |
| - que conserva continuidad de sesión útil |
| - que interpreta mejor el tipo de turno |
| - que integra una ruta de memoria/edición local heredada de OMEGA |
|
|
| --- |
|
|
| ## 6. Relación con los experimentos de SKYNET_OMEGA |
| |
| El trabajo experimental previo no dejó una “mente completa” lista para producción. |
| |
| Sí dejó algo más concreto y reutilizable: |
| |
| ### Hallazgo fuerte |
| |
| La propiedad más sólida encontrada fue: |
| |
| **edición local con preservación estructural bajo interferencia** |
| |
| Eso quedó reflejado en: |
| |
| - la línea `exp65-68` |
| - el perfil `local_editing` |
| - el `LocalMemoryEditor` |
|
|
| ### Traducción a OpenSkyNet |
|
|
| Esa línea se traduce aquí en dos planos: |
|
|
| 1. **Plano operativo** |
| - no aceptar resultados falsos |
| - mantener continuidad causal de sesión |
| - aprender restricciones desde errores reales |
|
|
| 2. **Plano cognitivo embebido** |
| - conservar dentro del repo el core OMEGA |
| - conservar la ruta de memoria local |
| - dejar preparada una futura integración más profunda al razonamiento principal |
|
|
| --- |
|
|
| ## 7. Flujo lógico completo: de Macro a Micro |
|
|
| ## 7.1 Macro |
|
|
| 1. El usuario emite un turno. |
| 2. `OpenSkyNet` interpreta qué tipo de interacción es. |
| 3. Decide la ruta de ejecución adecuada. |
| 4. Ejecuta el run. |
| 5. Verifica estructura y/o escritura real. |
| 6. Registra outcome en timeline persistente. |
| 7. Actualiza self-state de sesión. |
| 8. Usa esa memoria en el siguiente turno. |
|
|
| ## 7.2 Meso |
|
|
| Componentes: |
|
|
| - `interaction-model.ts` |
| - `omega-work-tool.ts` |
| - `session-task.ts` |
| - `validator.ts` |
| - `session-context.ts` |
| - `event-model.ts` |
|
|
| Cadena: |
|
|
| `input -> interpretación -> routing -> ejecución -> validación -> persistencia -> reutilización` |
|
|
| ## 7.3 Micro |
|
|
| Ejemplo concreto: |
|
|
| 1. El usuario dice: |
| - “revisa el fix anterior y corrige el JSON” |
|
|
| 2. OMEGA detecta: |
| - feedback + verificación + posible acción |
|
|
| 3. El router decide: |
| - `omega_delegate` o `sessions_spawn` |
|
|
| 4. Tras el run: |
| - valida JSON |
| - revisa si hubo escritura real |
|
|
| 5. Si falla: |
| - registra `invalid_structured_result` |
| - añade restricción `return_exact_json_object` |
|
|
| 6. En el siguiente turno: |
| - esa restricción aparece en el prompt de contexto de sesión |
|
|
| Eso ya es un ciclo causal operativo real. |
|
|
| --- |
|
|
| ## 8. Parte lógica y parte matemática |
|
|
| ## 8.1 Parte lógica |
|
|
| La lógica integrada hoy es principalmente: |
|
|
| - clasificación del tipo de interacción |
| - routing contextual |
| - validación de contrato |
| - verificación de evidencia |
| - actualización del self-state |
|
|
| Es una lógica orientada a: |
|
|
| - no confundir tareas |
| - no aceptar mentiras del runtime |
| - no olvidar el contexto operativo |
|
|
| ## 8.2 Parte matemática |
|
|
| La parte matemática vive sobre todo en `python/omega_py`. |
|
|
| Sus pilares son: |
|
|
| - dinámica continua por ODE |
| - plasticidad guiada por señal de predicción/frustración |
| - memoria episódica |
| - edición local explícita |
| - compuertas de protección y direccionamiento espacial |
|
|
| No toda esta matemática está activada como cerebro online principal. |
|
|
| Hoy su papel en `OpenSkyNet` es: |
|
|
| - mantener vivo el núcleo experimental útil |
| - servir de base para futuras capas de planificación/memoria activa |
| - conservar la parte más defendible de la investigación de OMEGA |
|
|
| --- |
|
|
| ## 9. Estado actual honesto |
|
|
| `OpenSkyNet` ya es superior a `OpenClaw` base en: |
|
|
| - confiabilidad operativa |
| - honestidad de cierre |
| - continuidad de sesión |
| - interpretación del input |
| - control de falsos positivos |
|
|
| `OpenSkyNet` todavía no es superior de forma demostrada en: |
|
|
| - razonamiento bruto del modelo base |
| - conciencia fuerte |
| - autonomía cognitiva general |
|
|
| La mejor forma de describirlo hoy es: |
|
|
| **OpenSkyNet no es todavía una mente nueva completa, pero sí es un runtime cognitivamente endurecido que integra la parte útil y verificable de OMEGA.** |
|
|
| --- |
|
|
| ## 10. Próximo paso correcto |
|
|
| El siguiente salto no debería ser “más features”. |
|
|
| Debería ser una de estas dos integraciones profundas: |
|
|
| 1. **omega_reason** |
| - usar el estado persistente + timeline + restricciones antes de la generación |
| - convertir OMEGA en una capa previa de planificación e hipótesis |
| |
| 2. **goal ledger + tension engine** |
| - dar continuidad de metas internas |
| - convertir al sistema de reactivo a persistentemente activo, pero con budget y control |
| |
| Si eso se hace bien, OMEGA dejaría de ser solo: |
| |
| - validador |
| - router |
| - memoria operativa |
| |
| y pasaría a influir directamente sobre el razonamiento. |
| |
| --- |
| |
| ## 11. Resumen corto |
| |
| OpenClaw aportó el host. |
| |
| SKYNET_OMEGA aportó: |
| |
| - validación dura |
| - continuidad causal |
| - self-state mínimo |
| - memoria local / edición local |
| - un core matemático reutilizable |
| |
| OpenSkyNet es la síntesis: |
| |
| - **OpenClaw como runtime** |
| - **OMEGA como capa cognitiva embebida** |
|
|
| Lo nuevo no es “más marketing”. |
| Lo nuevo es que ahora esas capacidades viven dentro del mismo sistema y ya afectan el comportamiento real del host. |
|
|
