> ## Documentation Index > Fetch the complete documentation index at: https://docs.orkestral.pro/llms.txt > Use this file to discover all available pages before exploring further. # Fast Apply > O motor determinístico que funde as edições nos seus arquivos. O Fast Apply é o motor local que transforma uma edição da IA em uma mudança real no disco. Os modelos premium planejam e o modelo local embutido (o Forge) descreve a mudança, mas é o Fast Apply que de fato funde essa mudança no seu arquivo. Ele roda inteiramente na sua máquina, não custa nada em tokens de API e segue regras rígidas para nunca escrever algo do qual não tenha certeza. Esta página explica como o Fast Apply analisa as edições, como localiza o ponto certo no seu arquivo, por que recusa edições ambíguas e como ele se combina com o Forge para manter as mudanças de código baratas e seguras. O app aplica a edição, nunca o modelo. A mesma entrada sempre produz a mesma saída. A fusão roda no processo principal do Electron, sem chamada externa por padrão. Apenas os trechos correspondentes mudam. Todo o resto do seu arquivo é preservado byte a byte. Se uma correspondência for ambígua ou inexistente, a edição é rejeitada com um motivo claro. ## Por que um motor determinístico Modelos locais pequenos são ótimos em descrever uma mudança, mas pouco confiáveis em reproduzir longos trechos de código literalmente. Se você deixar o modelo reescrever um arquivo inteiro, ele tende a remover comentários, reordenar imports ou alterar silenciosamente código distante da edição. O Fast Apply elimina esse risco ao tornar o modelo responsável apenas pelo **texto da mudança**, enquanto o app é responsável por **onde e como** esse texto é inserido. O modelo só produz o texto da edição. O aplicador (`parseEditBlocks`, `applyEditBlocks` e `mergeLazyEdit` em `src/main/services/smart-exec/morph.ts`) é o que altera o seu arquivo. Essa separação é o que torna cada aplicação reproduzível e revisável. ## Os dois formatos de edição O Fast Apply entende dois formatos de edição. Ambos mantêm o modelo honesto ao forçá-lo a se ancorar em linhas que realmente existem no seu arquivo. Um bloco nomeia as linhas exatas a encontrar e as linhas a colocar no lugar delas: ```text theme={null} <<<<<<< SEARCH ======= >>>>>>> REPLACE ``` Regras: * São permitidos vários blocos por arquivo, aplicados em ordem. * Um **SEARCH** vazio significa inserir ou criar: o **REPLACE** é prependido ao arquivo (ou se torna o arquivo inteiro se ele estava vazio). * Um **REPLACE** vazio significa excluir: as linhas correspondentes ao **SEARCH** são removidas. * Cada bloco deve corresponder exatamente uma vez. Mais de uma correspondência é rejeitada como ambígua. Em vez de repetir código longo literalmente, o modelo emite apenas o trecho alterado e marca o código intocado com um comentário de reticências: ```text theme={null} function totals(items) { // ... existing code ... const tax = subtotal * 0.1; return subtotal + tax; } ``` Cada trecho deve começar e terminar com uma **linha de âncora** real e inalterada que exista no seu arquivo. O modelo só precisa acertar duas linhas por trecho; o app preenche tudo entre as âncoras a partir do seu arquivo original. O formato preguiçoso é o que o Forge mais usa. Ele mantém a saída do modelo curta, que é exatamente onde os modelos pequenos são mais precisos, e permite que o app preserve cada linha que o modelo não mencionou. ## Como funciona uma fusão de busca e substituição Quando o Fast Apply processa um bloco de busca e substituição, ele percorre os níveis do mais rígido ao mais tolerante e para no primeiro nível que produz uma correspondência única e não ambígua. `parseEditBlocks` varre a saída do modelo em busca das marcações `SEARCH`, `=======` e `REPLACE`. O texto em prosa ao redor dos blocos é ignorado, marcações soltas de código markdown são removidas e blocos truncados (sem um divisor ou marcador final) são descartados em vez de aplicados pela metade. O motor conta as ocorrências do texto SEARCH no arquivo. Exatamente uma ocorrência é substituída no local. Zero ou mais de uma passa para a próxima decisão. Se o texto SEARCH aparece mais de uma vez, a edição é rejeitada com um motivo como `SEARCH matches 3x (ambiguous), needs more context`. O Fast Apply não escolherá um entre vários pontos por você. Se não houve acerto exato, o motor compara o SEARCH com janelas de linhas do mesmo tamanho, com os espaços finais e internos normalizados. Ele aplica a mudança apenas quando exatamente uma janela é equivalente. Como último recurso, ele pontua cada janela de mesmo tamanho por similaridade. Ele aplica apenas quando exatamente uma janela atinge ou supera o limiar de similaridade. Isso captura quase-acertos por espaços ou aspas sem nunca adivinhar. Se nenhum nível produz uma correspondência única, o bloco falha com um motivo preciso. O orquestrador pode então reparar a edição ou escalar para um modelo premium, em vez de corromper o seu arquivo. O nível aproximado usa um limiar de similaridade fixo de `0.92` e só dispara para uma única janela qualificada. Zero ou múltiplas janelas acima do limiar significam rejeição. Essa barra é deliberadamente alta para que o motor possa absorver variações de espaços e aspas, mas nunca possa escrever silenciosamente o conteúdo errado. ## Como funciona uma fusão preguiçosa As edições preguiçosas são fundidas por `mergeLazyEdit`. A atualização é dividida em trechos a cada marcador de reticências, e cada trecho é costurado de volta ao seu arquivo usando suas linhas de âncora. A atualização é dividida em trechos contíguos sempre que aparece um marcador `... existing code ...`. O marcador é reconhecido em vários estilos de comentário, então `//`, `#`, `--`, `/* */`, `` e `;` todos funcionam. Para cada trecho, a primeira e a última linha não vazias se tornam as âncoras inicial e final. As linhas de borda vazias são ignoradas porque corresponderiam a qualquer linha vazia. `anchorPositions` busca cada âncora do mais rígido ao mais tolerante: linha exata, linha sem espaços nas pontas, depois linha com espaços normalizados. Se essas falharem, ele tenta uma chave estrutural para declarações comuns de JS e TS (de modo que `export default function foo` ainda possa se ancorar em `export function foo` quando esse nome é único), depois uma única linha aproximada de alta similaridade. Linhas curtas como `}` ou `)` nunca são correspondidas de forma aproximada. Quando vários pares de âncoras são possíveis, o motor escolhe o trecho cujo comprimento é mais próximo do comprimento do snippet. Isso evita o bug clássico de fechar na primeira `}` aninhada em vez da verdadeira chave de fechamento da função. As linhas originais antes de cada trecho (o cabeçalho e os espaços entre trechos) e depois do último trecho (o final) são copiadas inalteradas. Apenas os trechos correspondentes são substituídos. Após a fusão, se um arquivo não trivial (mais de 30 linhas) perdeu mais de 60 por cento das suas linhas, a fusão é rejeitada como âncora suspeita, em vez de gravar um arquivo mutilado. Em uma fusão preguiçosa, as linhas de âncora reais do seu arquivo são mantidas, não as versões reformatadas pelo modelo. Assim, mesmo quando o modelo ajusta o espaçamento de uma âncora, a linha exata do seu arquivo sobrevive à fusão. ## Por que a ambiguidade é rejeitada Todo o motor é construído sobre uma promessa: se não tiver certeza, não escreve. Essa promessa aparece em vários lugares. Quando um SEARCH ou âncora corresponde mais de uma vez, o motor recusa em vez de escolher. Uma escolha errada editaria a região errada e passaria pela revisão sem ser notada. A rejeição força uma edição mais específica ou uma escalada. Cada correspondedor tenta primeiro o exato, depois o sem espaços nas pontas, depois o normalizado. O primeiro nível que encontra qualquer correspondência vence, então uma correspondência exata nunca é diluída por correspondências mais frouxas abaixo. A correspondência por similaridade só se aplica com uma única janela acima de um limiar alto. Ela existe para absorver ruído de espaços e aspas, não para inventar conteúdo. Toda rejeição carrega um motivo legível: correspondência ambígua, âncora não encontrada ou encolhimento suspeito. Esse motivo é o que permite ao orquestrador decidir reparar ou escalar. ## Como o Fast Apply se combina com o Forge O Forge é o modelo local embutido (Qwen2.5-Coder) que executa as mudanças de código. O Fast Apply são as mãos dele. O Forge escreve uma edição preguiçosa; o Fast Apply a funde de forma determinística; só se a fusão não conseguir encontrar suas âncoras é que o trabalho sobe um nível. Um orquestrador premium lê o seu repositório e decide o que deve mudar, depois delega a edição concreta ao Forge. O Forge produz uma edição preguiçosa curta (ou blocos de busca e substituição), mantendo apenas algumas linhas de âncora ao redor de cada mudança. O aplicador determinístico funde a edição no seu arquivo com custo zero de API. A maioria das edições se resolve aqui. Se a fusão local não conseguir ancorar a edição, o trabalho é escalado para que um modelo premium produza uma edição mais limpa, em vez de o motor adivinhar. Existe um fallback hospedado opcional (`morphFastApply`, a API do morphllm.com) que pode fundir uma edição preguiçosa antes da escalada para premium. Ele vem desligado por padrão e só ativa quando uma `MORPH_API_KEY` está presente no ambiente. Ele não é exposto na UI, porque o Orkestral é local-first. ## O que fazer a seguir Aprenda como o modelo local embutido executa mudanças de código com custo zero de API. Veja como as edições fundidas aparecem como diffs que você pode aprovar antes de chegarem ao seu repositório. Gerencie o comportamento do Fast Apply e provedores opcionais na área de Ferramentas. Entenda como planejamento, delegação e execução se encaixam.