Skip to main content
O comando /lsp <arquivo> pega os diagnósticos reais de um arquivo de código — os mesmos erros e avisos que seu editor mostraria — iniciando o language server apropriado e falando o Language Server Protocol com ele.
/lsp <arquivo> é o comando manual e por arquivo: você passa um arquivo, o ChatCLI inicia o language server da linguagem dele, abre o documento, aguarda os diagnósticos e os imprime. À parte disso, o motor @coder agora checa automaticamente os arquivos que acabou de editar — veja Diagnósticos automáticos pós-edição abaixo.

​
Como funciona

  1. Detecção de linguagem — pela extensão do arquivo.
  2. Spawn — inicia o language server da linguagem (comando default ou seu override). Se o binário não estiver instalado/no PATH, o /lsp avisa.
  3. Handshake — initialize + textDocument/didOpen.
  4. Diagnósticos — espera até 12s por textDocument/publishDiagnostics e renderiza o resultado.

​
Linguagens e comandos default

Cada linguagem usa um comando convencional de stdio, sobrescrevível por variável de ambiente. O binário precisa estar instalado e no PATH.

​
Uso

Combine com o /coder: rode /lsp num arquivo que você acabou de editar para confirmar que não introduziu erros de compilação antes de seguir.

​
Diagnósticos automáticos pós-edição

Você não precisa mais rodar /lsp na mão para pegar uma edição quebrada. No /agent e no /coder, depois de um @coder write, patch ou multipatch bem-sucedido, o motor roda o language server sobre os arquivos que acabou de tocar e anexa os achados ao resultado da tool como um bloco compacto [DIAGNOSTICS]:
O modelo vê o problema imediatamente — no mesmo turno da edição — em vez de turnos depois quando um teste falha. É a forma mais barata de manter as edições de um agente compilando. Comportamento e proteções:
  • Ligado por padrão, alternado por CHATCLI_CODER_AUTODIAG (off/false/no para desligar).
  • Silencioso em arquivos limpos — um arquivo sem diagnósticos não anexa nada, então o caminho feliz custa zero tokens.
  • Limitado — no máximo 5 arquivos por edição, um orçamento de 3000 caracteres para o bloco, e um orçamento de tempo (wall-clock) para o passe inteiro; excedente e arquivos pulados são elididos com uma nota explícita.
  • Nunca bloqueia em servidor frio — se o pool da sessão ainda não iniciou um servidor para aquela linguagem, a checagem não reporta nada agora, aquece o servidor em background, e a próxima edição recebe findings reais. O resultado do seu write renderiza imediatamente de qualquer forma.
  • Degrada para no-op quando não há language server disponível para a linguagem do arquivo (ou numa superfície sem o pool de LSP da sessão). Reaproveita o mesmo pool de servidores por sessão da tool @lsp abaixo, então não há custo extra de inicialização.
Deixe ligado: transforma “o build quebrou três passos atrás” em “corrija esta linha agora”, sem exigir disciplina de prompt do modelo.

​
A tool @lsp — navegação semântica para o agente

O mesmo motor LSP também está disponível para o modelo nos modos agent e coder, como a tool builtin @lsp — com um pool de servidores por sessão (o server inicializa uma vez por projeto e é reaproveitado entre chamadas; servidores ociosos são encerrados após 15 minutos): Posições são 1-based nos dois sentidos. Onde o @search encontra texto, o @lsp entende código: depois de editar um arquivo, diagnostics confirma que ele ainda compila; antes de mudar um símbolo, references mostra o raio de impacto.

​
Veja também