Como o Pathrule comprova afirmações fortes

O padrão técnico do Pathrule é simples: uma afirmação sobre o produto precisa de uma entrada delimitada, de um comportamento definido quando faltam evidências e de um resultado que possa ser testado de forma independente.

Esta página reúne esses contratos para a forma como o conhecimento entra no Pathrule, como é selecionado e como é entregue. Uma conexão Remote MCP tem um limite de entrega diferente: ela não instala hooks, então o conhecimento chega quando o agente chama as ferramentas do Pathrule.

A qualidade do conhecimento passa por vários filtros

O Pathrule não coloca todos os arquivos Markdown em todos os prompts. O conhecimento passa por controles independentes:

1. Descoberta seletiva. Quando o seu agente executa a varredura do projeto, os arquivos de instrução ativos, a cadeia de imports deles, as regras das ferramentas e os registros de decisão são diferenciados da documentação geral. Por padrão, a documentação mais ampla é oferecida para revisão, em vez de ser importada como instrução ativa.

2. Revisão antes da persistência, com as exceções explícitas. O conhecimento inferido espera por uma pessoa: candidatos da varredura do projeto só são adicionados quando aprovados, sugestões da Team Intelligence só chegam aos agentes depois que uma pessoa as verifica, correções para conhecimento desatualizado não mudam nada até que uma tarefa de atualização seja resolvida, e uma restrição executável que um agente propõe para uma regra é armazenada como proposta e só passa a ser aplicada quando uma pessoa a aprova. As gravações feitas pelo próprio assistente passam pelas ferramentas de escrita do Pathrule e ficam marcadas como sendo do assistente, versionadas e reversíveis. As descobertas do aprendizado do projeto são compartilhadas sem etapa de revisão, como orientações a verificar e nunca como regras. Duas coisas são gravadas sem perguntar, apenas em um espaço de trabalho no Cloud e apenas na primeira vez que um agente pede contexto aprofundado: os pares de caminhos de arquivos lidos do histórico recente do git, que alimentam a detecção de quais arquivos mudam juntos, e memórias curtas de tecnologia na raiz do espaço de trabalho, reconhecidas a partir dos nomes de arquivos. Em nenhum dos dois casos são lidos conteúdos de arquivos, diffs ou mensagens de commit. Veja Como o conhecimento se acumula.

3. Pertencimento ao caminho. Uma entrada pertence ao caminho mais específico do espaço de trabalho que a possui. Trabalhos fora desse caminho não a recebem só porque ela existe no mesmo repositório.

4. Relevância para a solicitação. Uma entrada ainda precisa se qualificar para a solicitação atual, toda vez. Elegibilidade e ordem são decididas separadamente e nunca trocam de papel: uma decide se uma entrada é elegível, a outra decide a ordem entre as que já são elegíveis. O aprendizado afeta apenas a ordem. Ele pode levar uma memória comprovada do quarto lugar para o primeiro; não pode fazer com que algo inelegível seja entregue. O volume também é limitado: a entrega cabe em um orçamento por prompt, então a quantidade entregue não cresce com o tamanho da base de conhecimento.

   É por isso que uma escrita disciplinada não é pré-requisito para um prompt enxuto. Uma entrada vaga ou mal escrita não vira ruído; ela simplesmente nunca se qualifica para uma solicitação com a qual não tem nada a ver. O custo visível de uma memória fraca é que ela não aparece.

5. Entrega e uso medidos. O Pathrule registra o que entregou e o que o assistente consultou. As camadas derivadas informam quando receberam dados pela última vez, então dá para distinguir um sistema silencioso de um sistema desconectado.

   A mesma disciplina vale para o motivo de uma entrada não ter sido entregue. "Nada se qualificou", "a chamada de priorização esgotou o tempo", "a resposta veio malformada" e "não havia nada para priorizar" são registrados como resultados distintos, e não com uma única palavra, porque são situações diferentes com correções diferentes. Um momento de lentidão é reportado como tal, então nunca é confundido com uma base de conhecimento vazia.

   Quando um conhecimento relevante não cabe no orçamento, ou o conteúdo dele ainda não está na máquina, ele é oferecido pelo título em vez de ser descartado, para que o assistente possa buscá-lo de forma deliberada. Descartar uma resposta correta só porque ela estava em um lugar inconveniente é justamente o resultado que este mecanismo foi projetado para evitar.

6. Manutenção revisável. Conhecimento que um agente considera desatualizado, contradito pelo código, duplicado ou pouco claro é levado para revisão como uma tarefa de atualização, e nada muda até que essa tarefa seja resolvida. As gravações são versionadas, os conflitos são explícitos e a exclusão é reversível.

Esses filtros transformam o conhecimento compartilhado em um sistema operacional pequeno e inspecionável para um repositório. É graças a eles que um projeto consegue acumular decisões sem transformar todo o seu acervo de documentação em contexto padrão. Veja Como o conhecimento se acumula e Sugestões e autoauditoria.

Verificação datada

Em 23 de agosto de 2026, verificações automatizadas focadas nesses contratos passaram no repositório principal do produto Pathrule, entre elas a descoberta de conhecimento, a ordem dos imports e a exclusão de fontes ruidosas.

O benchmark público de entrega de contexto pode ser reproduzido separadamente em github.com/pathrule/benchmarks. Como medimos publica o método, os artefatos brutos e os resultados, que são mistos. Os resultados medidos descrevem as configurações em que foram obtidos; não são garantias para o seu repositório.

Uma regra útil de avaliação

Para qualquer afirmação do Pathrule, faça três perguntas:

1. Quais evidências entram na decisão?
2. O que acontece quando essas evidências estão ausentes ou são ambíguas?
3. Qual resultado tem permissão para alterar ou bloquear o trabalho?

Os contratos acima respondem às três. Essa é a diferença entre a descrição de um recurso e uma afirmação de engenharia.