Ideia principal

Um ponto de engate chamado Stop sugere um fim: você imagina que ele dispara quando fecha a ferramenta, uma vez por sessão. Na prática ele dispara ao final de cada turno — depois de cada resposta completa do assistente, caiba ela em uma frase ou tenha encadeado quinze chamadas de ferramenta. Entre a ideia que você faz dele e o que ele faz, o fator é de várias dezenas.

A diferença não é um detalhe de documentação, ela muda o que você pode plugar ali. Um processamento pensado para rodar uma vez por dia — uma síntese cara, um envio de e-mail, uma escrita massiva — fica inutilizável nessa cadência. Na direção oposta, um mecanismo que precisa ver cada troca ficaria vazio se só disparasse no fechamento.

A frequência real é, portanto, a primeira coisa a estabelecer diante de um ponto de engate, antes mesmo de saber quais dados ele recebe. O nome é uma indicação de intenção, não uma especificação.

Por que isso importa

O erro não aparece na hora de escrever: o código plugado funciona, ele simplesmente funciona muito mais vezes do que o previsto. A conta chega depois, em custo, em lentidão ou em volume de dados produzidos, e quase nunca alguém faz a ligação com o mal-entendido inicial.

De forma mais geral, em qualquer integração, a granularidade de um evento é um dado a verificar tanto quanto o seu formato.

Nuances e limites

A frequência real também depende do uso: o mesmo ponto de engate dispara vinte vezes em uma sessão de trabalho intensa e duas vezes em uma sessão curta. Não é uma constante que você estabelece de uma vez por todas.

E o nome nem sempre engana: o problema é tomá-lo por uma especificação, não o fato de ele evocar alguma coisa.

Questões em aberto

• Como verificar a frequência real de um evento antes de plugar um processamento nele, sem ser observando em produção?