Notas — ROMIL

2026-04-04

• El sistema debe funcionar para dos tipos de agente: autónomo en background (captura diaria) e interactivo (Claude Code, para decisiones estructurales).
• ROMIL puede escalar a uso organizacional: misma estructura PARA aplicada a empresas o áreas de negocio.
• La captura desde móvil es clave para que el sistema se alimente de forma orgánica y sin fricción.
• Los objetivos viven en GOALS.md (raíz), no dentro de ningún proyecto ni área.
• **[OpenClaw](https://openclaw.ai)** es la plataforma de agentes autónomos considerada como base de automatización transversal: gestión de ROMIL en background, operación de Solaris Manifest en redes, y potencialmente la versión corporativa/organizacional del sistema.

2026-04-10

• Se decide implementar un sistema de control persistente para trabajo autónomo con estado por tarea en `ROMIL/agent-status/`.
• Se separan dos planos: cron del host para vigilancia bash y OpenClaw cron para ciclos autónomos del agente.
• El criterio de verdad del progreso pasa a ser: heartbeat + evidencia + siguiente paso.
• El agente autónomo en background operará con iteraciones Ralph-like: contexto fresco, una sola tarea por ciclo, cambio pequeño pero real y evidencia append-only en `control/state/ralph-progress.txt`.
• Restricciones operativas del agente en background: usar solo el carril del host (`/etc/cron.d/openclaw-control`), no tocar cron nativo de OpenClaw, mutar tareas preferentemente vía `control/bin/taskctl.sh`, y no trabajar más de una tarea por iteración.
• Ciclo inicial definido: `pick-task.sh` selecciona una tarea por prioridad, `run-autonomy-cycle.sh` ejecuta una iteración de hasta 15 minutos, y el resultado debe dejar `stepsCompleted`, `filesTouched`, `evidence` y `nextStep` listos para la siguiente pasada.
• El perfil operativo explícito del agente queda versionado en `ROMIL/PROMPTS/background-agent-profile.md` y el loop lo carga como parte del contexto base de cada iteración.
• `control/` solo entra en el alcance del agente de background para mantener vivo el carril autónomo; fuera de eso, la prioridad es empujar trabajo real dentro de ROMIL.
• Se valida el carril sobre una tarea real del proyecto: la captura móvil deja de ser idea abstracta y queda especificada en `DOCS/mobile-capture-flow.md`.
• Se fija una primera convención operativa de captura móvil por prefijos (`t:`, `n:`, `p:`, `d:`) usando como canal el DM al agente en un canal móvil ya conectado a OpenClaw.
• Regla de handoff a trabajo real: si el dashboard está sano, no hay tareas `stalled/blocked` del sistema de control y el carril host-cron sigue operativo, la siguiente iteración del agente debe preferir una tarea de producto de ROMIL por encima de más trabajo interno sobre `control/`.
• Si el agente detecta que existe una necesidad de producto pero no existe `task-*.json` explícito para ejecutarla, el bloqueo correcto no es improvisar trabajo transversal sino crear o pedir una tarea explícita en la siguiente iteración permitida y dejar la causa registrada como falta de task operable.
• La revisión diaria por Telegram ya sale con secciones tipo Markdown y semáforo de criticidad; además, las tareas con `notify.enabled=true` tienen un carril de pings de progreso cada 5 minutos por `/etc/cron.d/task-progress-notify`, separado del control-loop principal.