Saltar para o conteúdo
Runic
Português
Esc
navegarabrir⌘Jpré-visualizar
Nesta página

Escopo

O que é a v1, o que foi removido do plano anterior da camada de execução e por quê.

Runic nem sempre foi um cache. Planos anteriores (arquivados em _deprecated/ no repositório e em ALPHA.md/ROADMAP.md para contexto histórico) descreviam um runtime de execução: interceptar chamadas de ferramentas, impor permissões, aplicar sandbox ao acesso ao sistema de arquivos/rede e medir um orçamento rígido. Esta página explica por que esse plano foi removido, não ampliado.

No escopo da v1

  • Armazenar em cache o resultado de uma decisão, indexado por uma assinatura normalizada de correspondência exata — { intent, params }, nunca o texto bruto da tarefa, nunca um rastreamento de raciocínio.
  • Registrar os tokens gastos (relatados pelo agente) em comparação com os tokens economizados em um acerto de cache.
  • Escopo por sessão. O compartilhamento entre sessões/agentes é uma fase posterior, depois que a reutilização por sessão se provar relevante na prática.

Explicitamente fora do escopo

  • Execução de qualquer tipo. Runic nunca chama uma capacidade, implanta nada nem executa código. O antigo packages/runtime está descontinuado.
  • Permissões ou sandboxing. Não há nada para verificar se nada é executado. Os antigos packages/permissions e packages/sandbox estão descontinuados.
  • Correspondência semântica ou aproximada de tarefas. Isto é deliberadamente restrito — apenas correspondência exata. É uma restrição de design destinada a continuar sendo uma restrição, não um atalho da v1 a ser ampliado mais tarde sem reabrir a questão de saber se um acerto de cache é de fato a mesma decisão.

Por que isto é uma mudança de direção, não uma adição

Grande parte do antigo plano da camada de execução — imposição de permissões, sandboxing, execução de capacidades — acabou duplicando o que o MCP já padroniza para chamadas de ferramentas. Construir um sistema paralelo de permissões/execução sobre isso não é uma proposta defensável por si só; é infraestrutura redundante competindo com um padrão que já existe.

A ideia de cache e livro-razão sobreviveu ao corte porque responde a uma pergunta que o MCP não responde: esta decisão exata já foi resolvida e quanto ela custou? Essa é uma afirmação mais restrita e honesta do que “Runic gerencia a execução do seu agente” — e é a que este repositório realmente entrega, com números reais de benchmark para sustentá-la, em vez de um diagrama de arquitetura.

Se você está procurando o plano da camada de execução

Ele foi preservado para fins históricos em ALPHA.md e ROADMAP.md na raiz do repositório, e o próprio código está arquivado em _deprecated/. Nenhum dos dois é mantido, e nenhum reflete o que o Runic disponibiliza hoje — leia Introdução para isso.

Esta página foi útil?