Arquivos que mudam juntos

Alguns arquivos andam em pares. Uma rota e seu validador. Uma migration e o tipo que a espelha. Um componente e o arquivo de tokens que ele lê. Ninguém documenta isso, e raramente dá para ver na estrutura de pastas, mas depois de alguns meses todo mundo na equipe sabe.

O Pathrule aprende isso a partir do próprio trabalho. Quando seus agentes registram o que fizeram, cada registro traz os caminhos em que mexeram. Se dois caminhos aparecem repetidamente na mesma unidade de trabalho, o Pathrule registra que eles mudam juntos. Em um espaço de trabalho no Cloud, ele também ganha um adiantamento a partir do seu histórico do git, de modo que o sinal já é útil na primeira semana, e não só depois de alguns meses.

O que isso faz pela recuperação

O escopo de caminho e a correspondência por significado partem de onde você está. O co-change acrescenta os arquivos vizinhos.

Quando o assistente está trabalhando em /apps/api/payments/refund.ts, a recuperação já considera o que está fixado nesse caminho e o que corresponde à intenção. O co-change permite que o conhecimento associado aos caminhos que costumam mudar junto com ele também ganhe prioridade. Assim, uma regra sobre o gravador do ledger pode chegar a uma sessão que nunca mencionou o ledger, porque nessa base de código reembolsos e ledger sempre foram editados juntos.

Isso faz mais diferença justamente para o conhecimento que ninguém pensou em associar em dois lugares. Uma decisão registrada uma única vez, no arquivo onde foi tomada, ainda consegue chegar às sessões que precisam dela.

O que o assistente vê

Em um espaço de trabalho no Cloud, o co-change aparece no contexto que um agente pede ao Pathrule (via pathrule_get_context) em três lugares:

• Um aviso. Quando um arquivo vizinho muda junto com o arquivo diante do assistente com frequência especialmente alta, o assistente recebe uma única linha dizendo isso: aquele arquivo costuma mudar junto com este. No máximo uma linha, e só para uma relação forte, para que funcione como alerta e não como ruído.
• Caminhos relacionados. Junto com o contexto de uma requisição focada ou profunda, o assistente recebe uma lista curta dos caminhos que costumam mudar junto com aquele em que está trabalhando.
• Áreas acopladas em uma resposta profunda. Quando um agente pede contexto profundo, a resposta indica as partes do espaço de trabalho acopladas à área em questão, com os títulos das memórias, regras e skills associadas a elas.

A busca dessas informações é feita separadamente, então uma falha ao buscá-las não faz o turno perder as memórias e regras que elas deveriam acompanhar.

Como a relação é medida

Um par registrado conta quando os dois caminhos aparecem na mesma unidade de trabalho registrada. Compartilhar uma pasta não basta, nem ser alterado no mesmo dia por tarefas diferentes. A unidade é uma unidade de trabalho, porque é isso que indica uma dependência real, e não uma coincidência de organização.

As relações são reconstruídas a partir da atividade recente, então uma relação que deixa de acontecer vai perdendo força sem que ninguém precise removê-la. Um refactor que separa dois arquivos aparece como um enfraquecimento da relação entre eles nas semanas seguintes.

O adiantamento a partir do histórico do git

Um espaço de trabalho novo ainda não tem trabalho registrado, e é exatamente aí que conhecer os vizinhos mais ajudaria. Por isso, em um espaço de trabalho no Cloud, na primeira vez que um agente pede contexto profundo ao Pathrule, o runtime local lê os caminhos de arquivo do histórico recente do git. Arquivos alterados no mesmo commit formam um par, e commits muito grandes, que geralmente são refactors ou renomeações, são ignorados porque pareiam tudo com tudo. Os pares de caminhos de arquivo resultantes, com a frequência de cada par, são salvos no espaço de trabalho no Pathrule Cloud.

Isso acontece uma única vez, sem pedir confirmação, e não lê nada além de caminhos de arquivo. À medida que sua equipe registra trabalho, as relações registradas passam a pesar mais e a carga inicial do git passa a pesar menos, então o retrato deixa de refletir como o código mudou no passado e passa a refletir como sua equipe trabalha nele hoje.

Do que ele é construído, e do que não é

O sinal é construído apenas a partir de caminhos de arquivo: os caminhos do trabalho que seus agentes registram e, em um espaço de trabalho no Cloud, os caminhos de arquivo do histórico recente do git. O Pathrule não lê seu código-fonte, seus diffs nem suas mensagens de commit para calculá-lo, e nada sobre um arquivo além do seu caminho faz parte dele.

Um espaço de trabalho local, usado sem conta, não tem carga inicial do git. Seus pares vêm apenas do trabalho registrado, o que tem uma consequência prática que vale conhecer: ele precisa de um histórico de edição real. Um espaço de trabalho em que toda tarefa registrada mexe em exatamente um arquivo não gera nenhum par, porque não há o que parear. Nesse caso, a recuperação continua funcionando com base no escopo de caminho e no significado, e o co-change não contribui com nada em vez de chutar.

Ele também é por espaço de trabalho. Relações aprendidas em um espaço de trabalho não passam para outro, e o sinal fica atrás do mesmo controle de acesso que o restante do seu conhecimento.

Onde olhar

O co-change funciona em segundo plano, então não há nada para configurar nem para ativar. Ele fica mais útil à medida que sua equipe registra mais trabalho, que é a mesma coisa que torna os episódios de trabalho e as sugestões mais úteis. Se seus agentes estão registrando o trabalho, isso já está se acumulando. O que o Pathrule calcula lista o que o Pathrule lê de um checkout.