File che rallentano un assistente

Alcuni file sono più difficili di altri per un assistente, e di solito il motivo non è il codice in sé. Un percorso citato nella tua documentazione che è stato spostato. Un file generato che non si può modificare in sicurezza. Una directory che richiede un permesso che l'agente non ha. Sai già, più o meno, quali sono quei file, perché ti hanno fatto perdere la pazienza. Pathrule li registra con precisione.

Cosa viene registrato

Quando uno strumento chiamato da un assistente fallisce, vengono salvate tre cose: il tipo di strumento, il file su cui stava lavorando e un codice breve che indica come è fallito. file_not_found, permission_denied, timeout, rate_limit, token_limit, syntax_error, oppure unknown quando il fallimento è reale ma nessuna regola lo riconosce.

Il registro è tutto qui. Non il comando. Non il messaggio di errore. Non il file. Un conteggio e un codice, associati a un percorso. In un workspace Cloud questi conteggi e codici vengono salvati insieme al workspace in Pathrule Cloud.

Il fallimento viene osservato, non segnalato. L'hook degli strumenti di Pathrule controlla direttamente la chiamata, quindi il conteggio non dipende dal fatto che l'assistente si accorga del proprio errore, ricordi una sessione o chiami qualcosa in seguito. Un assistente che fallisce in silenzio e va avanti viene registrato esattamente come uno che lo dichiara. Anche la durata della chiamata fa parte della stessa osservazione, ed è ciò che permette di distinguere un comando rimasto bloccato da uno che è stato rifiutato. Questo vale per i client in cui Pathrule ha hook sugli strumenti: Claude Code, Codex, Cursor e GitHub Copilot. Windsurf non ha hook di Pathrule, quindi le sue chiamate agli strumenti non vengono osservate in questo modo.

Prima di tutto il percorso viene normalizzato in forma relativa al workspace, e la cosa conta più di quanto sembri. Un percorso assoluto su un portatile è /Users/<name>/…, e quel nome non ha alcun motivo di finire nella conoscenza condivisa. I percorsi relativi fanno anche sì che lo stesso file venga raggruppato correttamente in tutto il team, invece di comparire una volta per ogni macchina.

A cosa serve

Un quadro dei punti in cui il lavoro si blocca. Col tempo i fallimenti vengono raggruppati per file, strumento e codice. Il risultato è un breve elenco più che un grafico: i file in cui un assistente fallisce più spesso, e in che modo. Un file che compare spesso sotto file_not_found di solito è un percorso obsoleto da qualche parte nelle tue istruzioni. Uno sotto syntax_error di solito è un file davvero scomodo da modificare. Uno sotto permission_denied di solito è un problema di configurazione che puoi risolvere una volta per tutte.

Apprendimento del recupero. Se un turno ha ricevuto conoscenza da Pathrule e ha comunque incontrato dei fallimenti, quella conoscenza riceve un segnale negativo, e alcuni tipi di fallimento pesano più di un normale insuccesso perché tendono a indicare che le indicazioni hanno mandato l'assistente in un punto in cui non poteva andare. Il segnale entra nel ciclo descritto in come il recupero trova la conoscenza giusta. La conoscenza che continua a comparire in turni andati male diventa gradualmente meno probabile da scegliere, senza che nessuno debba revisionarla.

Cosa il segnale non riesce a vedere

Questa parte dipende dall'assistente che usi, e non è uniforme.

Gli strumenti sui file segnalano correttamente i fallimenti. Una lettura, una modifica o una scrittura che fallisce arriva con il suo messaggio, viene classificata e finisce sul file giusto. È il caso che conta, perché è il percorso del file a rendere un conteggio utilizzabile.

I comandi della shell spesso no. Alcuni assistenti non riportano alcun codice di uscita, quindi un comando che fallisce e uno che riesce arrivano identici. Pathrule non deduce un fallimento dal testo dell'output: un risultato di ricerca può legittimamente contenere le parole "no such file or directory", e un fallimento sbagliato associato a un file è peggio di uno mancante. Quando l'assistente non segnala un fallimento non viene registrato nulla, e quando ne segnala uno che nessuna regola riconosce, il codice è unknown invece di un'ipotesi.

Cosa non fa

Registrare un fallimento non blocca una chiamata a uno strumento e non compare nel contesto dell'assistente. Un fallimento è un fatto relativo alla tua codebase, registrato a posteriori. Non cambia ciò che l'assistente può fare, e un file con un brutto registro non viene considerato off limits. Niente di tutto questo è un punteggio associato a una persona: il registro riguarda i file, non chi ci stava lavorando.