Hooks e automatização
Nesta lição, vais aplicar verificações locais em momentos definidos do ciclo de vida da Nova, sem enfraquecer aprovações nem expor dados sensíveis.O que são hooks
Hooks são comandos locais que a Nova executa em limites definidos do ciclo de vida. São úteis quando uma regra tem de ser aplicada mecanicamente, em vez de ser apenas lembrada num prompt. Usos típicos incluem:- rejeitar entradas de ferramentas inseguras antes da execução;
- executar verificações locais depois de chamadas de ferramentas selecionadas;
- acrescentar contexto limitado quando uma sessão ou prompt começa;
- registar sinais de auditoria locais sem expor segredos;
- notificar outro processo local quando ocorre um evento do ciclo de vida.
Eventos suportados
A Nova reconhece atualmente estes nomes de eventos exatos:
Os nomes dos eventos distinguem maiúsculas de minúsculas nos caminhos dos hooks.
Localizações dos hooks
A Nova descobre hooks a partir de:.compass/hooks/no projeto;~/.compass/hooks/para hooks pessoais.
.yaml, .yml e .md. Também suporta scripts sem extensão, com shebang, em caminhos de eventos reconhecidos. Para duplicados da mesma origem, .yaml tem precedência sobre .yml, depois .md e, por fim, um ficheiro sem extensão.
Frontmatter
Um hook configurado pode usar frontmatter em estilo YAML seguido do corpo do comando:description— objetivo legível para pessoas;enabled— definefalsepara ignorar o hook;tools— padrões glob de nomes de ferramentas paraPreToolUseePostToolUse;timeout— tempo limite do processo, em milissegundos.
match para correspondência glob de campos de entrada, mas o leitor de frontmatter atual é intencionalmente simples e não interpreta de forma fiável mapeamentos aninhados. Não dependas de match num hook publicado; faz a correspondência das entradas no próprio script.
Exemplo portátil de PreToolUse
Um hook Node.js sem extensão evita sintaxe de shell específica da plataforma. Guarda o seguinte em .compass/hooks/PreToolUse/protect-env:
bash ou sh do Git for Windows quando esses interpretadores são pedidos.
Entrada do hook
A Nova envia um objeto JSON específico do evento para a entrada padrão. Todos os eventos incluem:session_id;transcript_path;cwd;hook_event_name.
tool_name, tool_input e tool_use_id. PostToolUse acrescenta tool_response. Outros eventos acrescentam os respetivos campos, como prompt, message, agent_id ou source.
A Nova também fornece variáveis de ambiente como HOOK_EVENT, HOOK_NAME, HOOK_CWD e valores específicos de ferramentas. Prefere a entrada JSON porque preserva a estrutura e é mais fácil de validar.
Trata toda a entrada de hooks como não fiável. Analisa JSON defensivamente, valida campos, coloca caminhos entre aspas e nunca avalies entradas como código. Para entradas malformadas, escolhe e documenta o comportamento de falha aberta ou fechada; o exemplo de aplicação de política anterior falha deliberadamente de forma fechada.
Estado de saída e resultado
ParaPreToolUse:
- o código de saída
0permite que o processamento continue; - um código de saída diferente de zero bloqueia a chamada da ferramenta;
- o erro padrão e, em seguida, a saída padrão são usados como explicação do bloqueio quando disponíveis.
SessionStart e UserPromptSubmit também aceitam saída de texto simples bem-sucedida como contexto adicional. Outros eventos exigem a forma estruturada para injetar contexto.
A Nova limita a execução e a saída dos hooks: o tempo limite predefinido por hook é 30 segundos, os tempos configurados estão limitados a 120 segundos e a saída do processo é limitada. Por isso, os hooks devem ser rápidos, locais e determinísticos.
Ativar ou desativar hooks
Os hooks estão ativos por predefinição no runtime. A configuração pode alterar explicitamente essa definição:nova doctor quando a execução de hooks parece estar desativada ou a instalação pode ter um problema mais amplo.
Recomendações de desenho
- Usa
NOVA.mdpara orientação e hooks para aplicação. Um hook só é adequado quando é necessária uma verificação determinística do ciclo de vida. - Falha de forma fechada apenas para verificações de elevada confiança. Um hook
PreToolUsecom falsos positivos pode bloquear trabalho legítimo. - Mantém os hooks rápidos. Operações de rede longas tornam cada chamada de ferramenta mais lenta e menos fiável.
- Não imprimas segredos. A saída do hook pode ficar visível em diagnósticos ou contexto injetado.
- Não dupliques aprovações da Nova. Os hooks podem adicionar restrições específicas da organização, mas não devem enfraquecer nem contornar o gestor de aprovações.
- Testa scripts fora da Nova primeiro. Fornece JSON representativo através da entrada padrão e confirma os códigos de saída no sistema operativo de destino.
- Revê hooks do projeto após atualizar alterações. São políticas executáveis, não documentação passiva.
Resolução de problemas
- Confirma o diretório e a grafia exata do evento.
- Confirma que a extensão é suportada ou que um ficheiro sem extensão começa com um shebang.
- Verifica que o interpretador configurado existe na máquina atual.
- Mantém caminhos válidos para a shell de destino; corpos
.yaml,.ymle.mdusam a shell da plataforma. - Confirma que o padrão
toolsdo hook corresponde ao nome da ferramenta em runtime. - Reproduz o script com JSON de teste capturado e inspeciona o código de saída.
- Reduz trabalho lento ou aumenta
timeoutapenas dentro do limite da Nova. - Executa
nova doctorpara verificar se os hooks foram desativados pela configuração.
Recapitulação
Usa hooks para aplicar verificações locais rápidas e determinísticas que não podem depender apenas de instruções. Revê hooks de projeto como código executável e valida sempre entradas, efeitos e códigos de saída.Prática segura
Num projeto descartável, cria um hookPreToolUse que bloqueie tentativas de escrever ficheiros .env. Testa-o com entradas JSON válidas e malformadas antes de o ativares num projeto partilhado.
Anterior: Model Context Protocol | Voltar ao percurso do curso