File che cambiano insieme

Alcuni file viaggiano in coppia. Una route e il suo validatore. Una migrazione e il tipo che la rispecchia. Un componente e il file dei token che legge. Nessuno lo mette per iscritto, e raramente lo si vede dalla struttura delle cartelle, ma dopo qualche mese tutti nel team lo sanno.

Pathrule lo impara dal lavoro stesso. Quando i tuoi agenti registrano quello che hanno fatto, ogni voce riporta i percorsi che ha toccato. Se due percorsi continuano a comparire nello stesso lavoro, Pathrule registra che cambiano insieme. In un workspace Cloud parte anche avvantaggiato grazie alla cronologia git, così il segnale è utile già dalla prima settimana invece che dopo qualche mese.

A cosa serve nel recupero

L'ambito del percorso e la corrispondenza basata sul significato partono entrambi dal punto in cui ti trovi. Il co-change aggiunge i file che gli stanno accanto.

Quando l'assistente lavora su /apps/api/payments/refund.ts, il recupero tiene già conto di ciò che è fissato su quel percorso e di ciò che corrisponde all'intento. Il co-change permette di far emergere anche la conoscenza associata ai percorsi che abitualmente cambiano insieme a quello. Così una regola sul writer del ledger può raggiungere una sessione che non ha mai nominato il ledger, perché in questo codebase i rimborsi e il ledger sono sempre stati modificati insieme.

Questo conta soprattutto per la conoscenza che nessuno ha pensato di associare in due posti. Una decisione registrata una sola volta, sul file in cui è stata presa, può comunque arrivare alle sessioni che ne hanno bisogno.

Cosa vede l'assistente

In un workspace Cloud, il co-change compare nel contesto che un agente chiede a Pathrule (tramite pathrule_get_context) in tre punti:

• Un avviso. Quando un file vicino cambia insieme a quello che l'assistente ha davanti con particolare frequenza, l'assistente riceve una sola riga che lo segnala: quel file di solito cambia insieme a questo. Al massimo una riga, e solo per una relazione forte, in modo che venga letta come un avvertimento e non come rumore.
• Percorsi correlati. Insieme al contesto per una richiesta mirata o approfondita, l'assistente riceve un breve elenco dei percorsi che cambiano abitualmente insieme a quello su cui sta lavorando.
• Aree accoppiate in una risposta approfondita. Quando un agente chiede contesto approfondito, la risposta indica le parti del workspace accoppiate all'area in questione, con i titoli delle memorie, delle regole e delle skill a esse associate.

Il recupero di queste informazioni è gestito separatamente, quindi se non riesce il turno non perde le memorie e le regole che dovevano accompagnare.

Come viene misurata la relazione

Una coppia registrata conta quando entrambi i percorsi compaiono nello stesso lavoro registrato. Stare nella stessa cartella non basta, e nemmeno essere modificati lo stesso giorno da attività diverse. L'unità è un singolo lavoro, perché è questo che indica una dipendenza reale e non una coincidenza dovuta alla struttura.

Le relazioni vengono ricostruite a partire dall'attività recente, quindi una relazione che smette di verificarsi si attenua senza che nessuno debba rimuoverla. Un refactoring che separa due file si manifesta con l'indebolimento della loro relazione nelle settimane successive.

Il vantaggio iniziale dalla cronologia git

Un workspace nuovo non ha ancora lavoro registrato, ed è proprio il momento in cui conoscere i file vicini sarebbe più utile. Per questo, in un workspace Cloud, la prima volta che un agente chiede a Pathrule contesto approfondito, il runtime locale legge i percorsi dei file della cronologia git recente. I file modificati nello stesso commit formano una coppia, mentre i commit molto grandi, che di solito sono refactoring o rinomine, vengono saltati perché accoppiano tutto con tutto. Le coppie di percorsi che ne risultano, con il numero di volte in cui ciascuna coppia si è presentata, vengono salvate nel workspace in Pathrule Cloud.

Succede una sola volta, senza alcuna richiesta di conferma, e non legge altro che i percorsi dei file. Man mano che il tuo team registra lavoro, le relazioni registrate contano di più e il seed da git conta di meno, così il quadro passa da come il codice è cambiato in passato a come il tuo team ci lavora oggi.

Da cosa è costruito, e da cosa no

Il segnale è costruito solo dai percorsi dei file: i percorsi presenti nel lavoro registrato dai tuoi agenti e, in un workspace Cloud, i percorsi dei file della cronologia git recente. Per calcolarlo Pathrule non legge il tuo codice sorgente, i tuoi diff o i tuoi messaggi di commit, e di un file non entra a farne parte nient'altro che il suo percorso.

Un workspace locale, usato senza account, non ha il seed da git. Le sue coppie derivano solo dal lavoro registrato, e questo ha una conseguenza pratica che è bene conoscere: serve una vera cronologia di modifiche. Un workspace in cui ogni attività registrata tocca esattamente un file non produce nessuna coppia, perché non c'è niente da accoppiare. In quel caso il recupero continua a funzionare in base all'ambito del percorso e al significato, e il co-change non contribuisce, invece di tirare a indovinare.

Inoltre è legato al singolo workspace. Le relazioni apprese in un workspace non vengono trasferite a un altro, e il segnale è protetto dallo stesso controllo degli accessi del resto della tua conoscenza.

Dove guardare

Il co-change lavora in background, quindi non c'è niente da configurare né da attivare. Diventa più utile man mano che il tuo team registra altro lavoro, la stessa cosa che rende più utili gli episodi di lavoro e i suggerimenti. Se i tuoi agenti registrano il loro lavoro, questo segnale si sta già accumulando. Cosa calcola Pathrule elenca cosa legge Pathrule da un checkout.