---
title: Escopo
description: >-
  O que é a v1, o que foi removido do plano anterior da camada de execução e por
  quê.
sidebar:
  order: 8
---
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.