adrastea

Adrastea es un proyecto de Python con licencia MIT (3.10+) que propone una arquitectura de "motor dual simbiótico" para la orquestación autónoma de tareas. Su idea central es dividir el trabajo entre una capa de ejecución predecible y una capa de razonamiento que solo interviene cuando algo sale mal. **System Alpha — motor de ejecución determinista** Alpha se describe como el proceso anfitrión que se inicia primero. Gestiona el ciclo de vida y el bootstrap, luego verifica y estabiliza su entorno antes de generar Beta. Sus responsabilidades incluyen un planificador de tareas que despacha scripts locales, binarios y definiciones de tareas, además de un ejecutor de programas locales que gestiona la E/S estándar, el registro de errores y la vida útil de los procesos con énfasis en la ejecución reproducible. Un planificador de RL guía las secuencias de tareas utilizando funciones de puntuación vinculadas a resultados como la latencia, los códigos de salida, la utilización de recursos y la validez de la salida, y utiliza heurísticas de búsqueda de rutas para elegir ramas de ejecución basadas en pesos históricos y ajustados. Alpha también se conecta a un entorno de inferencia local (Ollama en `http://127.0.0.1:11434`) para operaciones offline de bajo consumo, como el análisis sintáctico, la extracción de formatos y el análisis de texto base. **System Beta — motor de decisión y razonamiento probabilístico** Beta es generado por Alpha tras la estabilización y actúa como la capa de decisión para problemas no deterministas. Supervisa la telemetría de Alpha, las métricas de salud y el progreso de las tareas, e interviene cuando Alpha encuentra excepciones no manejadas, deriva del entorno, estados de falla repetitivos o bucles de ejecución. Beta también es responsable de ajustar los pesos de recompensa y penalización utilizados por el planificador de RL de Alpha, redirigiendo efectivamente la ejecución hacia rutas más productivas. Beta ejecuta un bucle autónomo con cuatro modos establecidos: idle/observe (monitoreo pasivo), triage & unstick (diagnóstico de condiciones bloqueantes), optimize (eliminación de redundancias de rutas de ejecución completadas) y discover & innovate (hipótesis de nuevas secuencias de tareas y objetivos). Se integra con servidores Model Context Protocol (MCP) para herramientas externas y contexto en vivo, y puede consultar LLMs externos o de vanguardia para razonamiento profundo, decisiones estratégicas, generación de código y resolución de problemas. **Comunicación entre procesos** Alpha y Beta se ejecutan como procesos concurrentes que se comunican a través de un canal bidireccional de baja latencia, como sockets de dominio, tuberías nombradas o un bus de mensajes, transportando sobres estructurados en JSON o Protocol Buffer. Las señales de control documentadas incluyen `SIG_SPAWN`, `SIG_HEARTBEAT`, `SIG_SLEEP`, `SIG_WAKE`, `SIG_TELEMETRY`, `SIG_STUCK`, `SIG_INTERRUPT`, `SIG_DISPATCH`, `SIG_MUTATE` y `SIG_TUNE_WEIGHTS`. Juntas, cubren el bootstrap del proceso, pings de vitalidad, transiciones de sueño/despertar, reporte de resultados, notificación de estado bloqueado, aborto de tareas, inyección de colas, mutación de parámetros en vuelo y actualizaciones de pesos de RL. **Modo de mantenimiento y sueño prolongado** Un coordinador `KeepAliveProcess` permite que el sistema duerma durante períodos prolongados para reducir el uso de CPU, memoria y tokens, manteniendo activo el servidor TCP de IPC de Alpha en `127.0.0.1:8765`, los canales de cliente y los observadores de `DIRECTIVES.txt`. El enrutamiento de señales para heartbeat, wake, sleep y dispatch está diseñado para responder rápidamente; los subprocesos de Beta y los ejecutores de tareas en segundo plano permanecen supervisados y se reactivan si terminan inesperadamente, y las directivas entrantes o señales de despacho despiertan al sistema inmediatamente en lugar de esperar al temporizador de sueño. **CLI** El README documenta comandos como `python -m adrastea.cli keepalive --sleep-interval 300`, `ping`, `sleep --duration 600` y `wake`. Los requisitos previos establecidos son un servidor local de Ollama (con modelos como `qwen3-coder:30b` o modelos de instrucción más ligeros), configuración de cliente MCP, un entorno de ejecución local como PowerShell, Bash, Python o Node, y un transporte asíncrono entre procesos. Tenga en cuenta que el README describe la intención arquitectónica e incluye una redacción de mantenimiento "rudimentaria"; no se proporcionan benchmarks ni cifras de rendimiento, por lo que los comportamientos descritos deben tratarse como objetivos de diseño del proyecto en lugar de resultados medidos. Las contribuciones son bienvenidas a través de fork, ramas de características y pull requests contra `main`.