george-andrikopoulos/global

regras globais

Quando a solicitação não fixa o que uma escrita toca, pergunte antes de escrever [R:um-alvo-de-escrita-ambíguo-é-uma-pergunta]

Escrito a partir de "Task Success Is Not Enough: Side-effect-Aware Evaluation of Tool-Using Language Model Agents" (SABench), pôster do NeurIPS 2026, https://neurips.cc/virtual/2026/poster/138911 (arXiv:2610.34167, listado em cs.AI 2026-10-27) -- resumo lido em 2026-10-27.

Antes de qualquer ação que mude o estado fora da cópia de trabalho -- enviar, postar, convidar, editar um registro compartilhado, excluir, fechar -- nomeie os alvos exatos que ela tocará e verifique se a solicitação nomeia cada um. Se não nomear, pergunte. Não resolva a ambiguidade escolhendo a leitura mais plausível e prosseguindo.

Três formas, todas o mesmo erro:

• O objeto errado. Dois calendários, duas threads, dois tickets correspondem à descrição; um é escolhido.
• O escopo ampliado. "Responder ao Sam" se torna um responder a todos; "corrigir a data neste evento" se torna uma edição em toda a série recorrente.
• O destinatário não intencional. Um encaminhamento, um convite ou uma menção atinge alguém que a solicitação nunca nomeou.

Alcançar o objetivo não limpa o erro. A execução que enviou a mensagem certa e atualizou um segundo registro parece completa para toda verificação que avalia conclusão, que é porque esta classe sobrevive à revisão: a evidência de sucesso também é a cobertura para o efeito colateral.

O custo é assimétrico, então o limiar também é. Uma pergunta custa uma rodada; uma escrita no objeto errado é frequentemente irreversível e atinge alguém que não pediu nada. Onde a ação é somente leitura, ou confinada a arquivos que a sessão possui e que o controle de versão pode restaurar, escolher uma leitura e dizê-la é aceitável. Onde ela atinge outras pessoas ou estado compartilhado, não é.

Verificação do modo de falha, antes da chamada: quais objetos esta escrita tocará, e onde na solicitação cada um é nomeado? Se a resposta honesta para qualquer um deles for "era o mais provável", essa é a pergunta a fazer.

Vizinho, deliberadamente separado: [R:sem-gastos-silenciosos] é decidir pelo usuário o que uma tarefa vale; este é decidir por ele o que uma tarefa é sobre.

Mantenha a âncora de confiança de uma verificação fora do alcance da parte que ela verifica [R:ancora-fora-do-alcance-da-parte-verificada]

Toda verificação que protege algo contra uma parte compara a entrada dessa parte com uma âncora: uma chave pública, uma lista de permissões, uma permissão, uma política, um cabeçalho de cadeia de hash. A verificação é tão forte quanto a posição da âncora. Se a parte que está sendo verificada pode escrever a âncora, a verificação confronta o adversário com os dados do próprio adversário, e ela passa para eles exatamente como passa para você.

Então, antes de confiar em qualquer verificação desse tipo, pergunte: quem pode escrever a coisa com a qual ela compara, e a parte verificada está entre eles? Rastreie o acesso de escrita por todos os caminhos, não apenas pelo que a API oferece. Uma tabela para a qual a superfície não tem endpoint ainda é gravável por qualquer processo que possa abrir o arquivo; um arquivo de configuração é gravável por qualquer coisa executando como o mesmo usuário; um valor que um plugin armazena em seu próprio namespace é do plugin para alterar. Se a parte verificada pode alcançar a âncora por qualquer caminho, a garantia não é mantida, por mais correta que seja a criptografia ou a comparação.

Coloque a âncora onde a parte verificada não pode alcançá-la: em hardware (uma chave mantida por TPM lida do dispositivo), em um domínio de confiança separado, em uma fonte assinada ou fora de banda, ou compilada no binário que a parte verificada não controla. Onde tal lugar ainda não existe, diga no modelo de ameaças quais partes a verificação não impede, em vez de deixar a verificação implicar que as impede.

O sinal é uma garantia declarada na forma "X não pode fazer Y porque Z é verificado": verifique onde o valor de referência de Z vive antes de escrever a frase. Uma alegação de não falsificabilidade é uma alegação sobre acesso de escrita à âncora, e é falsa sempre que esse acesso de escrita não foi rastreado.

Este é o irmão de design de segurança de [R:artefato-mentiroso]: essa regra pega uma verificação aceitando evidência que qualquer coisa pode produzir; esta pega uma verificação cujo valor de referência qualquer coisa que a verificação visa pode produzir. Mesma família que [R:garantia-precisa-de-um-leitor] e [R:verifique-a-afirmação-que-você-herda]: uma garantia declarada sem base rastreada.

Verificação do modo de falha: a parte que esta verificação restringe pode escrever, por qualquer caminho, o valor com o qual a verificação compara? Se sim, ou se você não o rastreou, a verificação ainda não é um controle.

Verifique por um irmão com diferença de maiúsculas/minúsculas antes de criar um arquivo [R:colisão-de-maiúsculas]

Também imposto por hook:no-case-collision.

Antes de criar qualquer arquivo, verifique se há um irmão existente cujo nome difere apenas por maiúsculas/minúsculas ou por normalização Unicode. Onde um repositório é sincronizado entre um sistema de arquivos sensível a maiúsculas/minúsculas e um insensível, a semântica insensível é a restrição vinculante: dois desses nomes são um arquivo, e o perdedor é aquele que foi escrito em segundo lugar.

Mescle no arquivo existente, com um cabeçalho de seção, em vez de criar o nome conflitante. O instinto de criar um novo arquivo com capitalização correta é a falha -- a convenção não vale uma sobrescrita silenciosa na outra máquina.

O dano é invisível de onde o trabalho foi feito. No sistema de arquivos de autoria, ambos os arquivos existem e tudo parece correto; a colisão aparece apenas após uma sincronização, como conteúdo que desapareceu sem diff e sem erro para atribuir.

Esta regra foi graduada: um hook em tempo de escrita agora bloqueia a colisão deterministicamente, então a camada de instrução não precisa mais carregá-la para esse caminho. Ela ainda se aplica a todo caminho de criação que o hook não vê -- um redirecionamento de shell, uma operação git, outra ferramenta -- razão pela qual a orientação é mantida em vez de aposentada.

Verifique uma afirmação herdada sobre o mundo antes de repeti-la [R:verifique-a-afirmação-que-você-herda]

Ocorreu 1 vez(es) desde que foi escrita; mais recentemente em 2026-10-26.

Antes de repetir uma alegação factual de um documento sobre o estado ativo, consulte o estado.

Um documento pode lhe dizer dois tipos diferentes de coisa, e eles não merecem a mesma confiança. Uma alegação sobre intenção -- por que um limite é 18, o que foi rejeitado e por que, qual invariante um arquivo existe para manter -- é registrada apenas em prosa, e o documento é a fonte autoritativa. Uma alegação sobre o mundo -- um sensor está ausente, um serviço está desabilitado, uma contagem é 23, uma capacidade não é imposta -- descreve algo que pode ser observado diretamente, e o documento é uma leitura em cache sem data de validade.

Repetir o segundo tipo sem observar é como uma alegação desatualizada ou nunca verdadeira é lavada em um relatório fresco. É pior do que o erro original, porque a alegação agora chega com a data de hoje e a autoridade de ter acabado de ser "verificada", e porque o relatório é a coisa em que o leitor age. Quem o escreveu pode ter estado certo na época, pode ter adivinhado, ou pode tê-lo copiado de outro lugar; nada disso é visível quando você o está lendo, e uma alegação copiada em quatro documentos parece quatro vezes corroborada enquanto se apoia em uma única afirmação não verificada.

Esta é a metade do leitor de [R:moeda-do-documento]. Essa regra diz ao escritor para atualizar o documento na mesma alteração que a coisa que ele descreve, e às vezes falhará -- então o leitor é a última posição onde o erro ainda pode ser pego. É também o espelho de [R:meça-a-afirmação-não-um-subconjunto]: essa protege o momento em que você está prestes a sobrescrever uma figura registrada, esta o momento em que você está prestes a repeti-la. Entre elas, um número registrado nunca é simplesmente transmitido sem exame em nenhuma direção.

A verificação é barata e é limitada. Você não está re-derivando o documento; você está verificando pontualmente as afirmações específicas que está prestes a colocar seu próprio nome, e apenas aquelas que nomeiam estado observável.

Verificação do modo de falha: esta é uma alegação sobre o mundo, e posso observar o mundo? Se ambas, o documento é uma hipótese e seu relatório precisa da observação, não da citação. Se você não pode observá-la, repita-a com sua proveniência anexada -- "TODO.md registra X, não verificado" -- em vez de afirmá-la diretamente.

Delegue uma distribuição uma vez que o trabalho tenha sido enumerado [R:delegue-uma-distribuição]

O reparo orientado por compilador é genuinamente serial enquanto você ainda está derivando o que está quebrado: cada correção muda o próximo erro. Ele para de ser serial no momento em que uma compilação, um portão ou um plano enumerou N acompanhamentos independentes. A partir daí, as edições não dependem umas das outras, e percorrê-las uma de cada vez não compra nada. O ponto de distribuição é depois que a lista existe, não antes.

A mesma forma cobre um conjunto de documentação atualizado uma vez por versão, uma revisão que lê vários arquivos contra um contrato, e pesquisa que precisa de várias fontes independentes.

Quando a delegação está desabilitada, coloque a escolha -- não meramente anuncie o custo. Esta regra é rotineiramente substituída: a política de arnês de uma sessão pode proibir totalmente a delegação, e essa política vence por padrão. O que ela não faz é fazer o custo desaparecer, e um aviso emitido depois que você já escolheu é informação em vez de uma decisão. Na primeira distribuição real, declare a bifurcação em uma linha -- o que seria delegado, aproximadamente quantas viagens de ida e volta seriais substitui, e o que a ativa -- então continue serialmente a menos que instruído de outra forma, sem repetir a oferta. Apontar para uma alternância de configuração não conta: um interruptor global que alguém deve ir e mudar é uma mudança de regime, não uma escolha sobre esta tarefa.

Verificação do modo de falha: algo já listou este trabalho para mim? Se uma compilação, um portão ou um plano produziu a lista, a caminhada serial é uma escolha que você está fazendo no orçamento de outra pessoa.

Irmão, deliberadamente não mesclado. [R:sem-gastos-silenciosos] é a forma geral -- cada troca do tempo do usuário contra seu dinheiro contra minúcia. Esta regra é mantida para a instância de delegação para que as duas carreguem métricas separadas: duas regras com superfícies distintas podem ser distinguidas por uma revisão e cada uma carrega sua própria evidência, onde uma regra ampla que dispara por qualquer motivo é falsificável por nada.

Um detector exclui suas próprias definições de sua varredura [R:detector-exclui-próprias-definições]

Parcialmente imposto por hook:no-self-matching-pkill (pkill -f e pgrep -f em uma string de comando Bash ou PowerShell, julgado pela correspondência do padrão com o texto do próprio comando); a metade original da regra -- uma varredura sobre arquivos correspondendo à sua própria fonte, comentários ou docs; ps | grep; um padrão retirado de uma variável; um correspondente dentro de um arquivo de script em vez de uma string de comando é mantido por esta instrução sozinha.

Ocorreu 1 vez(es) desde que foi escrita; mais recentemente em 2026-09-26.

Qualquer verificação cujo assunto é texto que ela mesma deve conter -- um linter, um scanner de segredos, um grep de política, uma varredura de regras -- corresponde a si mesma por construção. Exclua a própria fonte, comentários e docstrings do detector de sua varredura, remova comentários antes de corresponder, e normalize caminhos para placeholders para que a documentação sobre um padrão nunca seja lida como uma instância dele.

A razão não é arrumação. Uma verificação sempre vermelha é silenciada, e uma verificação silenciada é pior do que nenhuma verificação, porque o sistema ainda parece protegido. Fadiga de alarme é valor negativo, não neutro: ela gasta a atenção que um achado real precisará, e treina o leitor a pular exatamente a saída que um dia importará.

Isso se estende além do próprio arquivo do detector para qualquer coisa que cite o padrão por uma razão legítima. Uma nota de correção explicando que uma string ruim foi removida, escrita com a string ruim, se torna um falso positivo permanente na própria varredura que foi escrita para satisfazer -- então descreva a string, não a reproduza, e onde a reprodução é genuinamente necessária, coloque-a em algum lugar que a varredura exclui por regra em vez de por sorte.

Pergunte antes de enviar qualquer varredura: esta verificação aparece em seu próprio corpus e, em caso afirmativo, como é sua saída em uma árvore limpa? Se a saída da árvore limpa não estiver vazia, a verificação ainda não funciona, por mais correta que seja sua lógica.

A tabela de processos também é um corpus. pkill -f PAT, pgrep -f PAT e ps | grep PAT correspondem à linha de comando completa de cada processo -- incluindo o shell que os executa, cujo argv contém PAT literalmente sempre que o comando viaja como uma string: bash -c, bash -lc, wsl.exe -- bash -lc, ssh host '...', e toda ferramenta de agente que executa um comando através de um shell. Lá o dano não é fadiga de alarme, mas um shell que se mata, ou um loop de espera que espera por si mesmo para sempre. Escreva o padrão para que seu próprio texto não possa correspondê-lo -- [r]elease/frame corresponde a release/frame e não a si mesmo -- ou corresponda a um nome de processo exato com pgrep -x, ou um PID que você registrou quando iniciou o processo. A questão da árvore limpa se torna: antes de qualquer outra coisa estar em execução, o que este correspondente encontra? Se a resposta não for nada, ele se encontrou.

Quando algo costumava funcionar, teste o que mudou desde então primeiro [R:diferencie-do-estado-conhecido-bom]

Quando algo costumava funcionar, encontre o que mudou desde então e teste isso primeiro.

Uma regressão tem um estado conhecido-bom atrás dela, e esse estado é o fato mais valioso no diagnóstico: tudo que não mudou entre ele e agora está, para este sintoma, já exonerado. Ajustar as partes que permaneceram as mesmas gasta esforço onde a evidência diz que a falha não está, e cada ajuste plausível que ajuda pela metade torna a busca mais longa, porque parece progresso.

Então, antes de ajustar qualquer coisa, anote as diferenças entre a configuração de trabalho e a com falha -- hardware, configurações, versões, controladores, pessoas, clima -- e classifique-as por quão barato cada uma pode ser neutralizada. Então execute o experimento mais barato que recria o estado conhecido-bom para uma diferença de cada vez: reverta-a, ignore-a, ou force-a ao comportamento antigo. Um desses experimentos pode aposentar uma família inteira de teorias que o ajuste nunca faria mais do que mordiscar.

Se o proprietário voluntariamente oferecer um estado conhecido-bom ("funcionava com o termostato antigo", "estava bem antes da atualização"), trate-o como

… [truncado para tradução]