O que o Pathrule calcula

Você escreve três tipos de coisa: memórias, regras e skills. Essa parte é intencional, curada e sua.

Ela também é a parte menor. A maior parte do que a camada guarda em qualquer momento não foi digitada por ninguém. Ela é derivada de como o trabalho realmente acontece, mantida por espaço de trabalho e recalculada à medida que o trabalho continua. Esta página nomeia cada parte derivada, porque saber o que existe ali explica por que a recuperação se comporta como se comporta.

Uma representação de significado para cada entrada

Cada memória, regra e skill também existe como uma representação calculada do que ela significa. Quando chega uma solicitação, ela é convertida no mesmo tipo de representação e comparada diretamente com essas representações.

É essa parte que faz a correspondência entre idiomas funcionar. Um prompt em turco traz à tona uma memória escrita em inglês quando as duas compartilham uma ideia, e nenhuma palavra sequer. Uma busca por palavras-chave não consegue fazer isso, porque não existe nenhum texto em comum para comparar. A comparação acontece em um espaço em que "the payment webhook retries twice" e "ödeme webhook'u iki kez deniyor" ficam próximos um do outro.

As entradas recebem uma nova representação quando o conteúdo muda, então a correspondência reflete o que a entrada diz agora, e não o que dizia quando foi criada.

Uma janela medida em torno de cada entrega

Quando o Pathrule entrega conhecimento para um turno, ele abre um registro dessa entrega. Esse registro guarda quais entradas foram enviadas, em qual caminho e para qual tipo de intenção.

O turno então reporta de volta para a mesma janela:

• quais das entradas entregues o assistente realmente consultou, e não apenas recebeu
• quantas chamadas de ferramenta o turno fez e quantas delas falharam
• quais arquivos foram editados, em formato relativo ao espaço de trabalho
• como as falhas se distribuíram, na forma de códigos curtos, e não de texto de erro

Essa janela é a matéria-prima de tudo o que vem abaixo. É também o motivo pelo qual o Pathrule consegue distinguir um turno que foi bem de um que foi mal sem que ninguém precise avaliar nada.

Pesos aprendidos, por tipo de trabalho

As janelas se acumulam. Com o tempo, cada entrada passa a ter uma posição para cada tipo de trabalho em que foi entregue, e essa posição muda conforme as evidências: sobe quando a entrada foi consultada em um trabalho que correu bem e desce quando foi entregue em um turno que teve dificuldades.

A consequência é que a priorização não é um único número por entrada. A mesma memória pode ter prioridade alta em uma migração e baixa em um ajuste de interface, porque são tipos de trabalho diferentes e as evidências são diferentes. Um único campo de "importância" em um arquivo não consegue expressar isso, e uma pessoa mantendo esse campo manualmente teria que chutar.

O aprendizado é conservador de propósito. Um resultado ambíguo não ensina nada, em vez de ensinar a coisa errada; um único erro claro reduz a posição, em vez de apagar o histórico; e a influência diminui à medida que o código se afasta. Como a recuperação encontra o conhecimento certo explica esse comportamento em detalhes.

Um grafo de arquivos que mudam juntos

A partir dos caminhos que os turnos reportam, o Pathrule monta um retrato de quais arquivos sua equipe costuma alterar no mesmo trabalho. O conhecimento associado a um desses arquivos pode então chegar a uma sessão que está trabalhando no vizinho dele.

Ninguém declara essas relações e nenhum arquivo é aberto para encontrá-las. Elas surgem do trabalho registrado, têm um piso de ruído para que uma única coincidência não conte e perdem peso quando o par deixa de acontecer. Em um espaço de trabalho no Cloud, o grafo também sai na frente: na primeira vez que um agente pede contexto aprofundado, ele é inicializado com os caminhos de arquivo do histórico recente do git, então já é útil antes de sua equipe ter registrado muito trabalho. Veja arquivos que mudam juntos.

Um mapa de atrito

As falhas são agrupadas em uma tripla: o tipo de ferramenta, o arquivo e um código curto de como falhou. Agrupadas por semana, elas formam um retrato de onde e como um assistente continua travando no seu código, e alimentam a priorização como sinal negativo quando um turno que recebeu conhecimento ainda assim teve problemas. Veja arquivos que atrasam um assistente.

Uma medida de se o roteamento acertou

Cada prompt também recebe uma rota: os caminhos onde o trabalho provavelmente está, indicados antes de o assistente abrir qualquer coisa. O Pathrule então registra se o assistente foi para lá. Em uma janela móvel, isso vira um único número de acurácia, ao lado de quanto trabalho com ferramentas de arquivo uma sessão roteada exige em comparação com uma que nunca foi roteada.

É o único número que diz se apontar para um caminho de fato ajuda, em vez de apenas parecer útil, e é o motivo pelo qual o roteamento pode ser ajustado com base em evidências, e não em gosto.

Cada camada informa se ainda está sendo alimentada

Cada uma das camadas derivadas acima depende de trabalho chegando até ela, e uma camada que para de receber qualquer coisa não retorna nada. Isso parece exatamente uma camada que não tem nada a relatar. Esses dois casos pedem respostas opostas, então o Pathrule não deixa que pareçam iguais.

Cada camada é consultada regularmente sobre quando recebeu dados pela última vez, e a resposta é registrada como um de três estados: em dia, sem receber nada recentemente ou nunca alimentada. A mesma verificação percebe turnos vindos de um cliente antigo o suficiente para ser anterior a parte do registro, de modo que uma atualização que vale a pena instalar aparece como uma contagem identificada, e não como resultados que pioraram sem ninguém perceber.

É por isso que uma camada derivada que fica em silêncio é um estado reportado com data, e não algo que alguém nota meses depois ao se perguntar por que um resultado piorou.

Episódios e avaliações de atualidade

Mais duas camadas derivadas se apoiam na mesma atividade.

Episódios de trabalho costuram turnos relacionados na história de como algo foi resolvido, para que "como fizemos isso da última vez" tenha uma resposta que não dependa da memória de uma pessoa. Veja como resolvemos isso antes.

Avaliações de defasagem comparam o que uma entrada afirma com o rumo que o código tomou desde então, e apresentam as que parecem superadas como propostas de edição, em vez de simplesmente reduzir a prioridade delas em silêncio. Veja sugestões e autoauditoria.

Preferências pessoais, guardadas na sua máquina

Uma camada começa com você, e não com o trabalho registrado. Quando você diz ao Pathrule como gosta de trabalhar, por exemplo pathrule me teach "I prefer incremental refactors", o modelo no dispositivo opcional transforma a frase em uma preferência curta e com escopo definido. Ela fica armazenada na sua máquina, não é enviada, e é entregue aos seus agentes onde se aplica.

Você continua no controle: pathrule me list mostra o que está em uso, pathrule me explain mostra de onde veio uma preferência, pathrule me scope limita a preferência a um espaço de trabalho ou permite que ela valha para vários, pathrule me forget faz com que ela deixe de ser usada e pathrule me context mostra uma prévia do que um agente receberia para uma tarefa. Veja User Intelligence.

Do que nada disso é construído

Não é do conteúdo do seu código-fonte. O código-fonte do repositório não é enviado automaticamente. Cada camada derivada acima vem do que sua equipe escolheu escrever e do que o próprio trabalho relatou, e nenhum diff ou mensagem de commit é armazenado.

Duas coisas são lidas do seu checkout, ambas somente em um espaço de trabalho no Cloud e ambas na primeira vez que um agente pede contexto aprofundado:

• Caminhos de arquivo do histórico recente do git, para descobrir quais arquivos mudaram no mesmo commit. Commits muito grandes, geralmente refatorações ou renomeações, são ignorados. Os pares de caminhos de arquivo resultantes são salvos no espaço de trabalho como ponto de partida do grafo de mudanças conjuntas. Mensagens de commit, autores e diffs não são lidos.
• Nomes de arquivo perto do topo da árvore de pastas, para reconhecer as tecnologias em uso a partir de arquivos de configuração, como uma configuração de TypeScript, Vite, Docker ou GitHub Actions. Cada tecnologia reconhecida vira uma memória curta na raiz do espaço de trabalho, escrita sem perguntar. É uma memória comum, que você pode editar ou excluir.

Enquanto o histórico do próprio espaço de trabalho ainda é escasso, a mesma resposta aprofundada também indica as pastas de nível superior do projeto e os arquivos alterados com mais frequência no histórico recente do git. Esses dados são lidos do seu checkout e passados ao agente para essa resposta, sem serem armazenados pelo Pathrule.

Um espaço de trabalho local, mantido na sua máquina sem conta, não faz nada disso: o grafo de mudanças conjuntas dele vem apenas do trabalho registrado.

Mais duas coisas saem da sua máquina no modo Cloud, e as duas estão descritas aqui:

• O início de cada prompt. A primeira parte do prompt, aproximadamente os primeiros 1.000 caracteres, é enviada ao Pathrule Cloud para priorizar o conhecimento para ele.
• Um snapshot do projeto, quando você ou seu agente executam pathrule snapshot. Ele envia a árvore de arquivos, os manifestos, pequenos trechos da documentação e metadados recentes do git. Só é executado quando acionado.

A varredura do projeto é uma etapa separada que você mesmo inicia, pedindo ao seu agente que configure o Pathrule para o projeto. Seu agente lê o projeto para propor memórias, regras e skills, e só o que você aprovar é salvo.

Além disso, um CLI gerenciado e conectado pode enviar telemetria de uso anônima somente depois que você der consentimento com pathrule telemetry enable. Ela não contém código, caminhos, prompts, conhecimento, nomes de arquivo, e-mails nem IDs de conta. pathrule telemetry disable, NO_TELEMETRY=1 e DO_NOT_TRACK=1 a mantêm desativada.

Os caminhos de arquivo são normalizados para o formato relativo ao espaço de trabalho antes de qualquer coisa ser guardada, então nada específico da sua máquina sai dela também.

Por que os mesmos arquivos em uma pasta não são a mesma coisa

Você poderia colocar as mesmas memórias, regras e skills em um diretório e apontar um assistente para ele. Há equipes que fazem isso. O que esse diretório não consegue fazer é nada do que está nesta página.

Ele não sabe o que foi entregue no último turno, então não consegue dizer o que ajudou. Ele não tem nenhuma representação de significado, então uma pergunta formulada de outro jeito não encontra nada. Ele não sabe quais arquivos mudam juntos, então o conhecimento registrado em um arquivo nunca chega ao vizinho. Ele não distingue um tipo de tarefa de outro, então tudo tem a mesma prioridade para tudo. E ele cresce: cada entrada adicionada deixa cada turno futuro mais pesado, porque um diretório não tem como enviar apenas as poucas que importam.

As entradas escritas são a parte que você controla. A camada derivada é o que as transforma nas poucas certas para este turno, e é o motivo pelo qual a resposta melhora à medida que o trabalho continua, em vez de ficar exatamente tão boa quanto no dia em que foi escrita.