zenx0x/allinluna

All in Luna

All in Luna es un punto de entrada público. Acepta una de estas entradas:

• una idea o un objetivo de una frase;
• un plan existente;
• una ejecución activa o una instantánea de ejecución heredada;
• un paquete de Rutas de Investigación. Compila la entrada en un RunIntent tipado, selecciona un Pack de flujo de trabajo registrado y compila su TaskGraph que contiene contratos, dependencias, propiedad, condiciones de finalización (done-when), plantillas de WorkGraph y valores predeterminados de recursos. Luego llama al runtime/CLI vNext para persistir el grafo, liberar Lanes listos, ingerir recibos reales del host y continuar hasta que el resultado raíz esté completo o se devuelva un bloqueador concreto.

Relé de Acción Exacta de Alta Prioridad

Los valores lógicos de LocalDispatchIntent no son HostActions. Un HostAdapter primero los resuelve en un plan lane-direct-work/v1 o en un opcode exacto de HostAction.tool:

1. Invocar esa herramienta exacta con HostAction.arguments.
2. Nunca traducir, aproximar o sustituir otra capacidad.
3. Una top_level_task nunca puede recurrir a un subagente, el hilo actual o la ejecución directa.
4. Ingerir el recibo sin procesar inmediatamente, luego marcar de nuevo.
5. Si no hay un HostAdapter vinculado, devolver ACTION_RELAY_REQUIRED y preservar la acción exacta.
6. Devolver HOST_CAPABILITY_BLOCKED solo después de que el descubrimiento de capacidades confirme que la herramienta exacta está ausente.

Para trabajo local, native_preferred usa un worker nativo anunciado o un plan directo de Lane; native_required bloquea cuando está ausente y direct_only nunca genera. Un recibo directo no es finalización: el Lane debe ejecutar la WorkUnit y producir un work-handoff/v1 verificado.

Los recibos proporcionan explícitamente action_contract_hash, actual_tool y actual_capability. Una herramienta real incorrecta es HOST_PROTOCOL_VIOLATION, no evidencia de que una Tarea comenzó.

Bootstrap de Lane y controladores persistentes

Cada despacho público de codex_app__create_thread incrusta un objeto completo lane-bootstrap/v1 tanto en su carga útil de acción duradera como en el prompt hijo. Incluye las identidades de ejecución/tarea/intento, el resumen de TaskEnvelope, la ruta SQLite del runtime, las referencias a Contract/Context/WorkGraph, el espacio de trabajo, las capacidades locales permitidas, las capacidades globales prohibidas y la respuesta lane-handoff/v1 requerida. Un Lane hijo debe reabrir ese mismo Store y cargar estos objetos por sí mismo; su prompt nunca es solo un resultado en lenguaje natural. CoordinatorDriver es el bucle exterior duradero: programar acciones exactas, ingerir recibos, esperar/leer hilos de nivel superior, ingerir handoffs de Lane tipados, reconciliar y liberar inmediatamente las Tareas recién listas. LaneDriver realiza el bucle local de WorkGraph correspondiente, incluyendo instantáneas, expansión local dinámica, handoffs de worker, correcciones del mismo worker y síntesis de handoff de Lane. Una wave es solo una agrupación de UI: el trabajo listo por dependencias se libera inmediatamente.

Forma del runtime

Conversación
  -> Coordinador Global
       -> Lanes de Tareas independientes
            -> WorkUnits recursivas acotadas
                 -> herramientas / skills / plugins / MCP

Mantén la salida sin procesar de la herramienta en el Almacén de Artefactos. Pasa contratos tipados, referencias de artefactos, porciones de contexto, recibos y handoffs hacia arriba. Una WorkUnit hija debe reducir su ámbito padre, autoridad, propiedad y envoltorio de recursos; una solicitud entre Lanes se convierte en una solicitud de promoción.

Enrutamiento de entrada y Packs

Usa SinglePublicSkillAPI.compile() o allinluna start:

• objetivo simple -> delivery por defecto;
• plan existente -> importación heredada de solo lectura, luego delivery;
• ejecución activa -> importación de estado de ejecución de solo lectura y compilación orientada a recuperación;
• paquete de Rutas de Investigación -> research-routes-bridge, preservando Claims, Evidence, unknowns, contradicciones, regímenes de fallo, HumanDecision y límites de autorización de experimento.

Usa gsd cuando el usuario solicite explícitamente su flujo de trabajo. Su Pack ejecutable proporciona clarificar, especificar, descomponer, implementar, verificar e integrar, expansión local dinámica de Lane, WorkUnits acotadas, handoffs de contrato y recuperación local de fallos. No agregues fases de GSD a Core.

Recursos y permisos

Las elecciones de recursos siguen esta precedencia: solicitud explícita del usuario, luego una anulación de Tarea/WorkUnit, preferencia del usuario, capacidad del Pack, capacidad de despliegue/host y finalmente el valor predeterminado de la sesión/host actual. Core es neutral respecto al proveedor y no codifica un proveedor o ruta de modelo concreta. Preserva los valores solicitados, resueltos y reales por separado. Si el host no puede proporcionar un recibo de modelo real, registra actual: null y actual_state: unresolved; nunca afirmes un fallback ni fabriques un recibo. Un ámbito más estrecho puede cambiar los recursos de cómputo pero no puede ampliar permisos o propiedad. La telemetría de ruta de recursos del host es diagnóstico opcional del adaptador, no un requisito de ejecución o finalización de resultado. Una ruta del host debe resolver el model requerido antes de que se congele una acción ejecutable de codex_app__create_thread; una ruta no resuelta emite una acción de resolución no ejecutable. Sin modelo explícito y telemetría de razonamiento, registra actual: null y actual_state: unresolved mientras retienes los valores solicitados y resueltos independientes. El recibo persistido expone resource_receipt.requested, resolved, actual y actual_state. Cuando la evidencia real está disponible, el adaptador compara los valores solicitados con la action de despacho persistida y requiere que los valores reales coincidan con la ruta resuelta informada; un recibo nunca debe establecer su propia línea base de verificación. Una ruta no está bloqueada a menos que la política lo diga; una ruta bloqueada debe coincidir con su recibo.

Solicita permisos justo a tiempo en el límite de la acción. La compilación de solo lectura no solicita credenciales, publicación, despliegue, push, trabajo destructivo o mutación externa en vivo. Cuando se alcanza dicha acción, devuelve un PermissionIntent con ask, allowed o denied; no precargues un cuestionario y no realices la acción en silencio.

CLI y recuperación

allinluna start --goal "..."
allinluna status RUN_ID
allinluna next-actions RUN_ID
allinluna ingest-receipt RUN_ID RECEIPT.json
allinluna pause RUN_ID
allinluna resume RUN_ID
allinluna retry RUN_ID --task TASK_ID
allinluna cancel RUN_ID --task TASK_ID
allinluna reconcile RUN_ID
allinluna drive RUN_ID
allinluna lane start RUN_ID TASK_ID
allinluna lane status RUN_ID TASK_ID
allinluna lane tick RUN_ID TASK_ID
allinluna lane drive RUN_ID TASK_ID
allinluna lane next-actions RUN_ID TASK_ID
allinluna lane ingest-receipt RUN_ID TASK_ID RECEIPT.json
allinluna lane ingest-direct-result RUN_ID TASK_ID RESULT.json
allinluna lane handoff RUN_ID TASK_ID

El CLI del runtime expone start, status, next-actions, ingest-receipt, pause, resume, retry, cancel, set-policy y reconcile. Usa las APIs de compatibilidad públicas para la importación de planes/ejecuciones heredadas; devuelven acciones neutrales al host para el adaptador del host y nunca tratan un id de cliente pendiente como un recibo activo. La recuperación mantiene los artefactos inmutables y recalcula las acciones listas después de que se reconcilien los leases, recibos o instantáneas de contexto.

El registro/lanzador es solo un mecanismo interno de descubrimiento. Los usuarios ordinarios entran a través de este Skill contextual y su objetivo o viaje; los expertos pueden inspeccionar la matriz de Packs y los contratos de manifiesto.