User Intelligence

Workspace Intelligence conserva il progetto. User Intelligence conserva la persona dietro il lavoro.

Due ingegneri nello stesso repository non vogliono la stessa cosa da un agente, e la differenza non è di facciata. Riguarda quanto l'agente debba decidere da solo, quando debba fermarsi e proporre delle opzioni invece di implementare, quante verifiche bastino e quale strada prendere quando due soluzioni sono entrambe difendibili.

È un vero patrimonio di conoscenza e, se non ha un posto dove stare, finisce nelle correzioni che riscrivi a ogni nuova sessione.

Cosa modella

Preferenze di esecuzione

Se vuoi un refactoring incrementale o sei disposto a una riscrittura. Se ti aspetti di vedere delle opzioni prima di un'implementazione, o se per una certa categoria di modifiche preferisci che l'agente proceda e basta. Quanta astrazione ritieni giustificata. Su quali tipi di modifica ti aspetti di essere interpellato prima che avvengano.

Schemi decisionali

Quali compromessi tendi a scegliere. Prestazioni contro manutenibilità. Costruire contro adottare. Quanto rigidamente mantieni la retrocompatibilità. Cosa pesi per primo quando una decisione di prodotto si scontra con una tecnica.

Aspettative di qualità

Quanti test ti aspetti. Quando vuoi un benchmark invece di un ragionamento. Quando la ricerca è sufficiente e quando è diventata un modo per non rilasciare. Cosa intendi per "finito" e quale livello di validazione ci associ.

Stile di collaborazione

Quanto autonomo debba essere l'agente. Quando ti aspetti una domanda. Quando ti aspetti una scelta. Come vuoi che ti venga riferito il lavoro svolto, e con quale livello di dettaglio nelle spiegazioni.

Cosa non modella

Non chi sei. Niente dati demografici, niente personalità, niente deduzioni su di te come persona. L'unità è una preferenza di lavoro su come va fatto lo sviluppo software, e ognuna è qualcosa che avresti potuto dire ad alta voce.

Tre tipi di affermazione vengono rifiutati del tutto invece di essere memorizzati:

• Qualsiasi dato personale. Salute, religione, politica, sessualità, etnia, finanze e relazioni private sono fuori da ciò che Pathrule conserva, qualunque fosse l'argomento della frase.
• Una regola travestita da preferenza. Una preferenza è un consiglio per un agente. Un'affermazione formulata come divieto ("mai", "non deve", "vietato") verrebbe letta come un requisito di progetto che non ha l'autorità di essere, quindi non viene memorizzata. Se qualcosa davvero non deve mai succedere in un progetto, il suo posto è lì, come regola.
• Un fatto relativo a un progetto. "In questo repository usiamo l'helper di configurazione condiviso" vale per una codebase, non per te. Se fosse memorizzato come tuo, ti seguirebbe nel repository di un cliente dove è sbagliato. È conoscenza del workspace, e resta nel workspace.

Come impara

Glielo insegni tu. Esegui pathrule me teach con la frase che altrimenti continueresti a scrivere nelle nuove sessioni:

pathrule me teach "Show me options before implementing anything that changes a public API"

Il modello locale opzionale legge la frase sulla tua macchina e la trasforma in una preferenza di lavoro strutturata. Qualsiasi conclusione tragga deve trovare riscontro nelle tue parole: non può riformularti in una preferenza che non hai mai espresso, e se non riesce a indicare cosa hai scritto, non viene memorizzato nulla e la CLI ti spiega il perché.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

In concreto, se continui a ripetere qualcosa come "non trasformare ogni implementazione in un progetto di ricerca", la rappresentazione utile non è una citazione salvata. È una preferenza di lavoro:

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

Per insegnare serve un Mac con Apple Silicon e il modello locale installato. Tutto il resto di questa pagina, compresa la consegna, funziona anche senza.

Cambiare idea

Quando insegni una nuova preferenza che contraddice una precedente sullo stesso tipo di lavoro, la nuova sostituisce la vecchia. Quella vecchia viene ritirata, non cancellata, e conserva un riferimento a ciò che l'ha sostituita, così alla domanda "perché è cambiato" c'è sempre una risposta. Due preferenze su tipi di lavoro diversi restano semplicemente valide entrambe.

Chi è "l'utente"

Le preferenze parlano di te, quindi quando parli delle persone che usano ciò che costruisci, la formulazione potrebbe trasformarle silenziosamente in te. "Risolvi i problemi senza mostrare errori agli utenti" verrebbe letto da un agente come "non mostrarmi errori", cioè l'opposto di ciò che intendevi. Quando le tue parole riguardavano i tuoi utenti, la preferenza continua a dire "utenti finali".

Dove si applica una preferenza

User Intelligence appartiene a te, non a un repository. Dove si applichi ciascuna preferenza è una questione a parte.

• Ciò che insegni si applica ovunque. Non è stato appreso da un progetto, quindi non viene conservato in uno.
• Puoi limitarne una a un workspace. pathrule me scope <id>, eseguito dentro un repository, limita quella preferenza al workspace in cui lo esegui. pathrule me scope <id> --everywhere la rende di nuovo valida in tutti i workspace.

Come una preferenza arriva a un agente

Prima di ogni turno, Pathrule sceglie le preferenze che si applicano al lavoro che sta per iniziare.

• Solo quelle attive. Una preferenza non ancora in uso compare in pathrule me list ma non arriva mai a un agente. Neanche quelle ritirate o rifiutate vengono usate.
• Solo quelle nell'ambito del workspace, come descritto sopra.
• Solo quelle che riguardano questa attività. Una preferenza su come lavorare con te si applica a qualsiasi attività. Una preferenza su un tipo di lavoro, come l'architettura o le migrazioni, arriva a un agente solo quando l'attività riguarda proprio quello.
• Poche per turno, a partire dalla più forte. Se se ne applicano di più, restano fuori le più deboli.
• Ognuna indica da dove viene, così un agente può dare a "l'hai detto tu" il peso che merita.

Arrivano tramite l'hook del prompt, ciascuna una volta per sessione, sotto un'intestazione che dice all'agente che le regole e i controlli obbligatori del workspace hanno la precedenza. Oggi questo significa sessioni di Claude Code e Codex. Cursor e GitHub Copilot hanno hook di sessione e degli strumenti ma nessun hook del prompt, e Windsurf non ha hook, quindi le preferenze non li raggiungono. Vedi come funzionano gli hook.

Autorità: cosa succede quando tu e il progetto non siete d'accordo

Una preferenza dell'utente non prevale sulla verità del progetto.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

Si applica la regola. È un requisito del workspace, e una preferenza per meno verifiche non è un motivo per scavalcarla.

Il principio generale, che vale la pena dire chiaramente:

• Workspace Intelligence rappresenta la verità e i requisiti del progetto. Le sue regole e i suoi controlli obbligatori sono requisiti inderogabili.
• User Intelligence dà forma alla collaborazione: come si affronta il lavoro, quanto se ne fa in autonomia, come viene riferito. Non ridefinisce cosa significhi corretto.

Quando entrambe riguardano solo lo stile, vale la tua preferenza. Quando il workspace stabilisce un requisito di sicurezza o di correttezza, quel requisito resta.

Lo stesso vale anche in assenza di una regola del workspace. Una preferenza che potrebbe tradursi in meno verifiche viene trattenuta ogni volta che il lavoro tocca autenticazione, pagamenti, migrazioni di dati, crittografia o sicurezza. Lì gli errori sono silenziosi e costosi, e una preferenza nata sul codice di tutti i giorni non dice nulla sul fatto che lì sia sicura.

Cosa controlli tu

Tutto. User Intelligence è ispezionabile, non implicita. Per ogni preferenza puoi vedere:

• Il suo stato: candidata, attiva, ritirata o rifiutata.
• Da dove viene e quanto è affidabile.
• Dove si applica: in tutti i workspace o solo in uno.
• Perché: le parole su cui si basa, con le date.

E puoi:

• Insegnare direttamente una preferenza.
• Dimenticarne una. Smette di essere usata e viene conservata come rifiutata, così la stessa affermazione non la riporta subito indietro. Aggiungi --delete per rimuoverla del tutto.
• Limitarne una a questo workspace, o renderne una valida ovunque.
• Verificare cosa riceverebbe un agente per un'attività prima di cominciarla.

Una deduzione che non vedi mai è una deduzione che non puoi contestare, ed è per questo che ogni preferenza è a un comando di distanza.

Dalla riga di comando

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context stampa esattamente ciò che un agente riceverebbe per quell'attività, insieme alle preferenze trattenute e al motivo. È il modo più rapido per verificare che una preferenza arrivi al lavoro per cui l'avevi pensata, e solo a quello. Ogni sottocomando accetta --json.

Passare da un progetto all'altro

Apri un altro repository e la conoscenza di progetto intorno a te cambia completamente. Le preferenze che hai insegnato, a meno che tu non ne abbia limitata una a un singolo workspace, vengono con te.

È lì che le due si incontrano in un turno: il workspace porta ciò che è vero e obbligatorio in quel contesto, tu porti il modo in cui il lavoro va fatto, e la consegna mantiene i requisiti del progetto al di sopra delle tue preferenze. Vedi Agent IR.

Limiti da conoscere

• La corrispondenza si basa sulle parole, non sul significato. Una preferenza raggiunge un'attività con cui condivide dei termini. Una formulata in modo molto diverso dall'attività può mancarla.
• Per insegnare serve il modello locale, che funziona solo sui Mac con Apple Silicon.
• Le preferenze raggiungono solo i client con un hook del prompt: Claude Code e Codex.
• Si astiene invece di tirare a indovinare. Una frase che non riesce ad ancorare alle tue parole non viene memorizzata. Perdere una preferenza ti costa una frase in più; inventarne una ti rappresenterebbe in modo sbagliato davanti a ogni agente con cui lavori.

Privacy

L'inferenza che trasforma ciò che insegni in una preferenza strutturata gira sul tuo dispositivo, e le tue preferenze sono conservate in un archivio privato sulla tua macchina.

Se condividi un workspace con un team, ciò che viene sincronizzato è la conoscenza del workspace, non le tue preferenze di lavoro personali. E quando usi Claude Code, Codex o un altro agente, a tutto ciò che gli arriva si applicano i confini del provider di quell'agente. La pagina sulla sicurezza tiene distinti questi confini, perché condensarli in un'unica frase è proprio il modo in cui un'affermazione smette di essere vera.

Cosa leggere dopo

• Workspace Intelligence: cosa porta il progetto e perché i suoi requisiti prevalgono.
• Il modello locale: cosa gira sul tuo dispositivo e come installarlo.
• Riferimento dei comandi CLI: tutti i sottocomandi pathrule me insieme al resto della CLI.