Pular para o conteúdo
Pathrule

documentação

O que uma sessão de IA registra

O que o Pathrule armazena quando uma sessão de IA conclui um trabalho, o que ele nunca armazena e quais recursos esse registro alimenta.

Nesta página

A maior parte do que o Pathrule aprende sobre o seu projeto vem do trabalho feito, não do que alguém escreveu. Quando uma sessão de IA conclui um trabalho, ela registra uma entrada curta e estruturada, e é sobre essa única entrada que vários outros recursos são construídos.

Esta página explica o que vai nessa entrada, o que fica de fora de propósito e o que ela passa a alimentar.

O que é registrado

Cada entrada tem poucos campos, todos pequenos:

  • Área, ação e escopo. Que tipo de coisa foi alterada (ui, backend, database, infra, config, test, docs), o que foi feito com ela (create, update, fix, refactor, delete, style) e em que nível (um componente, uma página, uma API, uma migration, um serviço).
  • Assuntos. Até cinco palavras-chave em minúsculas, do jeito que você marcaria o trabalho numa conversa.
  • Um resumo de uma frase. O que mudou e por quê, em uma linha.
  • Os caminhos alterados, agrupados por área.
  • Em qual cliente de IA a sessão rodou, e quando.
  • Como foi o turno: quantas chamadas de ferramentas foram feitas, quantas falharam e um código curto para cada tipo de falha (timeout, exit_nonzero, not_found e similares). Apenas contagens e códigos, nunca o comando ou o texto do erro.

Esse é o registro inteiro. Ele foi pensado para ser entendido de relance meses depois, e é também por isso que continua curto. A visão Recent Activity no Pathrule para VS Code lista as entradas mais recentes do espaço de trabalho.

O assistente escreve a frase. O Pathrule anexa a medição. O resumo, a área e os caminhos vêm da sessão que fez o trabalho, enquanto a contagem de chamadas de ferramentas, as falhas e quais das entradas entregues foram de fato consultadas são observadas pela camada que as entregou. Essa divisão importa: um assistente pode esquecer de mencionar que quatro comandos falharam, e a contagem está lá mesmo assim.

O que nunca é registrado

Seu código não está ali. Nada de conteúdo de arquivos, diffs, patches, mensagens de commit ou texto de prompt. Os caminhos estão lá para que recursos posteriores saibam onde o trabalho aconteceu; a substância da mudança não é armazenada.

Os caminhos também são normalizados antes de serem armazenados. Um caminho chega do jeito que o agente o viu naquela máquina e é convertido para a forma relativa ao espaço de trabalho, então /Users/you/projects/app/src/api.ts vira src/api.ts. Nada específico de uma máquina chega ao conhecimento compartilhado da equipe, e o mesmo arquivo é o mesmo arquivo, não importa quem mexeu nele.

O que uma entrada alimenta

O que faz o registro valer a pena é quem o lê:

  • Episódios de trabalho. Entradas relacionadas de uma mesma sessão de trabalho se juntam em um registro com título de algo que a sua equipe resolveu, que uma sessão futura pode recuperar.
  • Arquivos que mudam juntos. São os caminhos de cada entrada que ensinam ao Pathrule quais arquivos andam em pares.
  • Aprendizado de recuperação. Quando um conhecimento foi apresentado a um agente e o agente depois trabalhou nessa mesma área, isso é evidência de que o conhecimento era relevante. Com o tempo, isso ajusta a prioridade, conforme descrito em como a recuperação funciona.

Nenhum deles exige um passo extra da sua parte. Todos vêm da mesma entrada curta.

O registro nunca bloqueia o trabalho

Vale destacar uma escolha de design deliberada, porque ela aparece no comportamento da ferramenta. O registro nunca falha por causa do tamanho. Se um resumo fica longo ou uma tarefa alterou dezenas de arquivos, a entrada é cortada no servidor e armazenada, em vez de rejeitada.

Rejeitar seria pior do que cortar. Um agente que recebe um erro de validação entende isso como "corrija os argumentos e tente de novo" e passa os próximos turnos reescrevendo um resumo em vez de terminar a sua tarefa. Por isso os limites são aplicados de forma silenciosa, na entrada, e a resposta informa ao agente o que foi armazenado.

Para que servem as contagens de falhas

As contagens de chamadas de ferramentas e de falhas são a forma como o Pathrule responde "em quais arquivos desta base de código um assistente tem mais dificuldade" a partir de trabalho real, e não de opinião. Duas coisas as leem.

A primeira é um agrupamento semanal. Cada falha é registrada como uma tripla: o tipo de ferramenta, o arquivo em que ela estava trabalhando e um código curto para o modo como falhou. Agrupado por semana, isso vira uma lista simples dos arquivos em que um assistente mais falha e do tipo de falha que ele encontra ali. Um arquivo que aparece repetidamente com file_not_found costuma ser um caminho desatualizado na sua própria documentação ou um módulo movido que ninguém atualizou. Um que aparece com syntax_error costuma ser um arquivo difícil de editar com segurança.

A segunda é o aprendizado de recuperação. Se um turno recebeu conhecimento do Pathrule e ainda assim encontrou falhas de ferramentas, isso conta contra o conhecimento entregue. Esse sinal entra no mesmo ciclo de aprendizado descrito em o que faz um conhecimento ganhar prioridade, de modo que um conhecimento que aparece repetidamente em turnos que dão errado vai deixando de ser escolhido.

O que uma contagem de falhas consegue e não consegue ver

Isso depende do assistente que você usa, e a resposta honesta não é a mesma para todos.

As ferramentas de arquivo reportam direito. Uma leitura, edição ou escrita que falha chega com a sua mensagem, então é classificada e atribuída ao arquivo certo. Esse é o caso que vale a pena ter, porque é o caminho do arquivo que torna o número útil na prática.

O status de saída do shell muitas vezes não chega. Alguns assistentes simplesmente não reportam um código de saída diferente de zero: um comando que falha e um que dá certo chegam com a mesma cara. O Pathrule não tenta adivinhar. Ele registra o que o assistente de fato reportou e classifica o resto como desconhecido em vez de inventar uma falha, porque uma falha errada atribuída a um arquivo é pior do que uma falha ausente.

Acesso e escopo

As entradas ficam no espaço de trabalho em que foram registradas, protegidas pelo mesmo controle de acesso por usuário que vale para memórias, regras e skills. Um colega vê a atividade dos espaços de trabalho que ele já pode ver, e nada além disso. As entradas mais antigas expiram de acordo com um cronograma, em vez de se acumularem para sempre.