Come Pathrule dimostra le affermazioni impegnative

Lo standard tecnico di Pathrule è semplice: un'affermazione sul prodotto richiede un input delimitato, un comportamento definito quando mancano le evidenze e un risultato verificabile in modo indipendente.

Questa pagina raccoglie questi contratti per il modo in cui la conoscenza entra in Pathrule, viene selezionata e viene consegnata. Una connessione Remote MCP ha un confine di consegna diverso: non installa alcun hook, quindi la conoscenza arriva quando l'agente chiama gli strumenti di Pathrule.

La qualità della conoscenza passa da più controlli

Pathrule non mette ogni file Markdown in ogni prompt. La conoscenza attraversa controlli indipendenti:

1. Scoperta selettiva. Quando il tuo agente esegue la scansione del progetto, i file di istruzioni attivi, la loro catena di import, le regole degli strumenti e i registri delle decisioni vengono distinti dalla documentazione generica. La documentazione più ampia viene proposta per la revisione invece di essere importata come istruzione attiva per impostazione predefinita.

2. Revisione prima della persistenza, con le eccezioni dichiarate. La conoscenza dedotta attende una persona: i candidati della scansione del progetto vengono aggiunti solo quando sono approvati, i suggerimenti di Team Intelligence raggiungono gli agenti solo dopo che una persona li ha verificati, le correzioni alla conoscenza obsoleta non cambiano nulla finché un'attività di aggiornamento non viene risolta, e un vincolo eseguibile che un agente propone per una regola viene salvato come proposta e non viene applicato finché una persona non lo approva. Le scritture fatte da un assistente passano dagli strumenti di scrittura di Pathrule e vengono contrassegnate come opera di un assistente, versionate e reversibili. Le conclusioni dell'apprendimento sul progetto vengono condivise senza un passaggio di revisione, come consigli da verificare e mai come regole. Due cose vengono scritte senza chiedere, solo su un workspace Cloud e solo la prima volta che un agente chiede un contesto approfondito: le coppie di percorsi di file lette dalla cronologia git recente, che alimentano quali file cambiano insieme, e brevi memorie sulle tecnologie alla radice del workspace, riconosciute dai nomi dei file. In nessuno dei due casi vengono letti contenuti dei file, diff o messaggi di commit. Vedi Come cresce la conoscenza nel tempo.

3. Appartenenza al percorso. Una voce appartiene al percorso più ristretto del workspace che la possiede. Il lavoro fuori da quel percorso non la riceve solo perché esiste nello stesso repository.

4. Pertinenza alla richiesta. Una voce deve comunque qualificarsi per la richiesta corrente, ogni volta. Idoneità e ordine vengono decisi separatamente e non si scambiano mai di ruolo: la prima stabilisce se una voce è idonea, il secondo stabilisce l'ordine tra quelle già idonee. L'apprendimento incide solo sull'ordine. Può spostare una memoria che si è dimostrata utile dal quarto al primo posto; non può mai far consegnare una voce non idonea. Anche il volume è limitato: la consegna rientra in un budget per prompt, quindi la quantità consegnata non cresce con le dimensioni della base di conoscenza.

   Per questo una scrittura disciplinata non è un prerequisito per avere un prompt pulito. Una voce vaga o scritta male non diventa rumore; semplicemente non si qualifica mai per una richiesta con cui non ha nulla a che fare. Il costo visibile di una memoria debole è che non compare.

5. Consegna e uso misurati. Pathrule registra cosa ha consegnato e cosa l'assistente ha consultato. I livelli derivati indicano quando hanno ricevuto dati l'ultima volta, così un sistema tranquillo si distingue da uno disconnesso.

   La stessa disciplina si applica al motivo per cui una voce non è stata consegnata. "Nulla si è qualificato", "la chiamata per l'assegnazione delle priorità è andata in timeout", "la risposta era malformata" e "non c'era nulla a cui dare priorità" vengono registrati come esiti distinti invece che con un'unica parola, perché sono situazioni diverse con soluzioni diverse. Un momento di lentezza viene segnalato come tale, così non viene mai scambiato per una base di conoscenza vuota.

   Quando la conoscenza pertinente non rientra nel budget, o il suo corpo non è già presente sulla macchina, viene offerta per titolo invece di essere scartata, così l'assistente può recuperarla di proposito. Scartare una risposta corretta solo perché si trova in una posizione scomoda è proprio l'esito che questo meccanismo vuole evitare.

6. Manutenzione revisionabile. La conoscenza che un agente trova obsoleta, smentita dal codice, duplicata o poco chiara viene sottoposta a revisione come attività di aggiornamento, e nulla viene modificato finché quell'attività non viene risolta. Le scritture sono versionate, i conflitti sono espliciti e l'eliminazione è reversibile.

Questi controlli trasformano la conoscenza condivisa in un piccolo sistema operativo ispezionabile per un repository. È grazie a loro che un progetto può accumulare decisioni senza trasformare l'intero archivio della documentazione in contesto predefinito. Vedi Come cresce la conoscenza nel tempo e Suggerimenti e autoverifica.

Verifica datata

Il 23 agosto 2026 i controlli automatici mirati su questi contratti sono stati superati nel repository principale del prodotto Pathrule, tra cui la scoperta della conoscenza, l'ordinamento degli import e l'esclusione delle fonti rumorose.

Il benchmark pubblico sulla consegna del contesto è riproducibile separatamente su github.com/pathrule/benchmarks. Come misuriamo ne pubblica il metodo, gli artefatti grezzi e i risultati contrastanti. I risultati misurati descrivono le configurazioni su cui sono stati ottenuti; non sono garanzie per il tuo repository.

Una regola utile per valutare

Per qualsiasi affermazione di Pathrule, poniti tre domande:

1. Quali evidenze entrano nella decisione?
2. Cosa succede quando quelle evidenze mancano o sono ambigue?
3. Quale risultato può modificare o bloccare il lavoro?

I contratti descritti sopra rispondono a tutte e tre. È questa la differenza tra la descrizione di una funzionalità e un'affermazione ingegneristica.