zenx0x/allinluna

All in Luna

All in Luna é um ponto de entrada público único. Aceita uma destas entradas:

• uma ideia ou objetivo de uma frase;
• um plano existente;
• uma execução ativa ou snapshot de execução legada;
• um pacote de Rotas de Pesquisa. Compila a entrada em um RunIntent tipado, seleciona um Pacote de Workflow registrado e compila seu TaskGraph contendo contratos, dependências, ownership, condições de conclusão, modelos de WorkGraph e padrões de recursos. Em seguida, chama o runtime/CLI vNext para persistir o grafo, liberar Lanes prontas, ingerir recibos reais do host e continuar até que o resultado raiz esteja completo ou um bloqueador concreto seja retornado.

Retransmissão de Ação Exata de Mais Alta Prioridade

LocalDispatchIntent lógico não são HostActions. Um HostAdapter primeiro os resolve para um plano lane-direct-work/v1 ou um opcode HostAction.tool exato:

1. Invocar essa ferramenta exata com HostAction.arguments.
2. Nunca traduzir, aproximar ou substituir por outra capacidade.
3. Uma top_level_task nunca pode recorrer a um subagente, ao thread atual ou à execução direta.
4. Ingerir o recibo bruto imediatamente e então processar novamente.
5. Se nenhum HostAdapter estiver vinculado, retornar ACTION_RELAY_REQUIRED e preservar a ação exata.
6. Retornar HOST_CAPABILITY_BLOCKED somente após a descoberta de capacidade confirmar que a ferramenta exata está ausente.

Para trabalho local, native_preferred usa um worker nativo anunciado ou um plano Lane-direct; native_required bloqueia quando ausente e direct_only nunca cria subprocessos. Um recibo direto não é conclusão: o Lane deve executar a WorkUnit e produzir um work-handoff/v1 verificado.

Recibos fornecem explicitamente action_contract_hash, actual_tool e actual_capability. Uma ferramenta real errada é HOST_PROTOCOL_VIOLATION, não evidência de que uma Task foi iniciada.

Bootstrap de Lane e drivers persistentes

Cada dispatch codex_app__create_thread público incorpora um objeto lane-bootstrap/v1 completo tanto na carga útil da ação durável quanto no prompt filho. Inclui as identidades de run/task/attempt, o digest do TaskEnvelope, o caminho do SQLite do runtime, referências de Contract/Context/WorkGraph, o workspace, capacidades locais permitidas, capacidades globais proibidas e a resposta lane-handoff/v1 necessária. Um Lane filho deve reabrir esse mesmo Store e carregar esses objetos ele mesmo; seu prompt nunca é apenas um resultado em linguagem natural. CoordinatorDriver é o loop externo durável: agendar ações exatas, ingerir recibos, aguardar/ler threads de nível superior, ingerir handoffs de Lane tipados, reconciliar e liberar imediatamente Tasks recém-prontas. LaneDriver executa o loop local correspondente do WorkGraph, incluindo snapshots, expansão local dinâmica, handoffs de worker, correções do mesmo worker e síntese de handoff de Lane. Uma wave é apenas um agrupamento de UI: trabalho pronto por dependência é liberado imediatamente.

Forma do Runtime

Conversation
  -> Coordinator Global
       -> Lane(s) de Tarefa independentes
            -> WorkUnits recursivas limitadas
                 -> ferramentas / skills / plugins / MCP

Manter a saída bruta da ferramenta no Artifact Store. Passar contratos tipados, referências de artefatos, fatias de contexto, recibos e handoffs para cima. Uma WorkUnit filha deve restringir seu escopo pai, autoridade, ownership e envelope de recursos; uma solicitação entre Lanes se torna uma solicitação de promoção.

Roteamento de Entrada e Pacote

Usar SinglePublicSkillAPI.compile() ou allinluna start:

• objetivo simples -> delivery por padrão;
• plano existente -> importação legada somente leitura, depois delivery;
• execução ativa -> importação de estado de execução somente leitura e compilação orientada a recuperação;
• pacote de Rotas de Pesquisa -> research-routes-bridge, preservando Claims, Evidence, unknowns, contradições, regimes de falha, HumanDecision e limites de autorização de experimento.

Usar gsd quando o usuário solicitar explicitamente seu workflow. Seu Pacote executável fornece clarify, specify, decompose, implement, verify e integrate, expansão local dinâmica de Lane, WorkUnits limitadas, handoffs de contrato e recuperação local de falhas. Não adicionar fases GSD ao Core.

Recursos e permissões

As escolhas de recursos seguem esta precedência: solicitação explícita do usuário, depois uma sobrescrição de Task/WorkUnit, preferência do usuário, capacidade do Pacote, capacidade de deploy/host e, finalmente, o padrão da sessão/host atual. Core é vendor-neutral e não codifica um provedor ou rota de modelo concreta. Preservar valores solicitados, resolvidos e reais separadamente. Se o host não puder fornecer um recibo de modelo real, registrar actual: null e actual_state: unresolved; nunca alegar um fallback ou fabricar um recibo. Um escopo mais restrito pode alterar recursos de computação, mas não pode expandir permissões ou ownership. A telemetria de rota de recurso do host é diagnóstico opcional de adaptador, não um requisito de execução ou conclusão de resultado. Uma rota de host deve resolver o model necessário antes que uma ação executável codex_app__create_thread seja congelada; uma rota não resolvida emite uma ação de resolução não executável. Sem modelo explícito e telemetria de raciocínio, registrar actual: null e actual_state: unresolved enquanto retém os valores solicitados e resolvidos independentes. O recibo persistido expõe resource_receipt.requested, resolved, actual e actual_state. Quando evidência real estiver disponível, o adaptador compara valores solicitados com a ação de dispatch persistida e exige que actual corresponda à rota resolvida informada; um recibo nunca deve estabelecer sua própria linha de base de verificação. Uma rota não é bloqueada a menos que a política assim o determine; uma rota bloqueada deve corresponder ao seu recibo.

Solicitar permissões just-in-time no limite da ação. A compilação somente leitura não solicita credenciais, publicação, deploy, push, trabalho destrutivo ou mutação externa ao vivo. Quando tal ação for alcançada, retornar um PermissionIntent com ask, allowed ou denied; não pré-carregar um questionário e não executar a ação silenciosamente.

CLI e recuperação

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

O runtime CLI expõe start, status, next-actions, ingest-receipt, pause, resume, retry, cancel, set-policy e reconcile. Usar as APIs de compatibilidade pública para importação de planos/execuções legadas; elas retornam ações host-neutral para o adaptador de host e nunca tratam um client id pendente como um recibo ativo. A recuperação mantém artefatos imutáveis e recompõe ações prontas após leases, recibos ou snapshots de contexto serem reconciliados.

O registry/launcher é apenas um mecanismo interno de descoberta. Usuários comuns entram através deste Skill contextual e seu objetivo ou jornada; especialistas podem inspecionar a matriz de Pacotes e os contratos do manifesto.