Workspace Intelligence

Workspace Intelligence è la risposta a una sola domanda: come funziona questo progetto?

Non che cosa contengono i file. Quelli un agente li sa leggere, e li legge bene. Quello che non riesce a leggere è la conoscenza operativa che un repository accumula attorno al proprio codice, cioè proprio la conoscenza che decide se una modifica è corretta o soltanto plausibile.

Che cosa modella

• Decisioni architetturali, e il ragionamento che le ha prodotte.
• Vincoli nascosti che non sono visibili da nessuna parte nel codice.
• Requisiti di verifica: che cosa va controllato prima che qualcosa possa dirsi finito.
• Correzioni precedenti: che cosa ha funzionato davvero l'ultima volta che si è presentato proprio questo problema.
• Convenzioni che un team segue senza averle mai messe per iscritto.
• Procedure: la sequenza con cui un lavoro ricorrente viene svolto in questo progetto.
• Fatti di contesto che cambiano l'approccio giusto, come un database che è una replica in sola lettura.
• Motivazioni tecniche, che sono ciò che impedisce a un agente di annullare con le migliori intenzioni una scelta fatta di proposito.
• Implementazioni preferite tra diverse che funzionerebbero tutte.
• Decisioni superate, così che una decisione vecchia smetta di essere trattata come attuale.

Tutto questo vive in tre tipi di contenuto che il tuo team può leggere e modificare: memorie, regole e skill.

Ambito

Workspace Intelligence è legata a un repository e, al suo interno, ai percorsi.

È questo il meccanismo che impedisce a un livello di conoscenza di diventare il problema che doveva risolvere. Non tutto ciò che vale per un monorepo è rilevante per una modifica a un singolo pacchetto, e consegnarlo per intero mette le tre frasi che contano in competizione con le duecento che non contano. La conoscenza si aggancia al percorso che governa, e un'attività in quel percorso riceve ciò che lo governa.

Il legame con i percorsi è anche il motivo per cui un workspace può continuare a crescere senza che ogni turno diventi più pesante. Vedi come funziona il recupero.

Autorità

Workspace Intelligence è il livello che può contenere requisiti vincolanti.

I requisiti vivono nelle regole. Una regola stabilisce che cosa deve o non deve accadere in un ambito, ha una priorità e arriva in una sezione a sé, separata dai consigli. Una regola può anche avere un vincolo eseguibile, cioè un pattern che una modifica non deve contenere. Un vincolo proposto da un agente viene salvato come proposta e non viene applicato; una volta che una persona lo ha approvato, l'hook pre-tool può bloccare una modifica corrispondente nei client i cui hook lo supportano. Vedi le regole come guardrail.

Sono proprietà del progetto. Non vengono messe da parte perché una preferenza personale sarebbe più comoda, e User Intelligence non può prevalere su di esse. Tutto il resto che Workspace Intelligence contiene ha valore consultivo e viene consegnato come consiglio, quindi una correzione passata non viene mai presentata come se contasse più di una regola.

Fonti

Sono di quattro tipi, ed è importante distinguerle.

Scritte di proposito. Memorie, regole e skill che una persona ha scritto intenzionalmente, oppure che un agente ha scritto tramite gli strumenti di Pathrule, di solito dopo avertele proposte. Sono quelle che un team può indicare e su cui può discutere, e ne costituiscono l'ossatura.

Conclusioni ricavate dal codice. Ciò che un agente ha concluso leggendo il tuo codice, salvato insieme ai file su cui si basa e consegnato come consiglio solo finché quei file restano invariati. Vedi apprendimento del progetto.

Evidenze dal lavoro reale. Ciò che le sessioni degli agenti hanno riportato su sé stesse: quale conoscenza è stata consegnata, quale è stata effettivamente consultata, quali file sono stati modificati insieme, dove un agente continuava a bloccarsi. Vedi cosa calcola Pathrule.

Inizializzate dalla tua copia locale, su un workspace Cloud. La prima volta che un agente chiede a Pathrule un contesto approfondito su un workspace Cloud, il runtime locale legge i percorsi dei file dalla cronologia git recente per capire quali file sono cambiati insieme, ed elenca i nomi dei file nei primi livelli dell'albero delle cartelle per riconoscere le tecnologie in uso, come una configurazione TypeScript, Docker o GitHub Actions. Le coppie di percorsi vengono salvate nel workspace come punto di partenza per i file che cambiano insieme, così il segnale è utile ancora prima che il tuo team abbia registrato molto lavoro. Ogni tecnologia riconosciuta diventa una breve memoria alla radice del workspace, come "TypeScript project", scritta senza chiedere conferma; è una memoria qualsiasi, che puoi modificare o eliminare. Un workspace locale salta questo passaggio e impara quali file cambiano insieme solo dal lavoro registrato.

Che cosa non è una fonte: il tuo codice sorgente. Pathrule non carica automaticamente il tuo codice, e l'inizializzazione descritta sopra legge nomi e percorsi dei file, non il loro contenuto, i diff o i messaggi di commit. Su un workspace Cloud, pathrule snapshot, quando lo esegui tu o il tuo agente, carica l'albero dei file, i manifest, brevi estratti della documentazione e i metadati git recenti, così che Pathrule possa descrivere il progetto. Cosa calcola Pathrule elenca che cosa viene letto e che cosa viene conservato.

Team Intelligence

Su Pathrule Cloud, Team Intelligence esamina l'insieme delle evidenze prodotte dal lavoro di un team e propone pattern: convenzioni, correzioni e decisioni che continuano a ripresentarsi. È disponibile sui piani Team ed Enterprise, e i proprietari e gli amministratori dell'organizzazione la gestiscono nella console web, nelle impostazioni Team guidance dell'organizzazione.

Un pattern passa da bozza a suggerimento, e una persona lo verifica oppure lo rifiuta; un suggerimento su cui nessuno interviene scade. Solo i pattern verificati raggiungono gli agenti. Nulla di ciò che Team Intelligence deduce viene considerato affidabile di per sé.

Ciclo di vita

1. Scritta o proposta. Una persona la scrive con la CLI, l'estensione per VS Code o il proprio agente. Un agente che ha scoperto qualcosa che vale la pena conservare lo salva tramite gli strumenti di scrittura di Pathrule, di solito dopo avertelo proposto, e la scrittura è attribuita, versionata e reversibile. Chiedere al tuo agente "Set up Pathrule for this project" avvia una scansione guidata in cui l'agente propone memorie, regole e skill e scrive quelle che approvi. Su un workspace Cloud, Pathrule aggiunge anche le brevi memorie sulle tecnologie descritte sopra.
2. Approvata, quando qualcosa è stato dedotto. La conoscenza dedotta aspetta una persona: il vincolo eseguibile di una regola viene applicato solo dopo l'approvazione, e un pattern di Team Intelligence raggiunge gli agenti solo dopo essere stato verificato. Le conclusioni degli agenti sono l'unica eccezione, e restano consultive. Vedi Proposed Knowledge.
3. Consegnata. La parte rilevante per un'attività raggiunge l'agente tramite il meccanismo supportato dal suo client. Vedi Agent IR.
4. Misurata. La consegna e ciò che l'agente ne ha fatto vengono registrati, così il peso di una voce riflette ciò che è successo e non chi l'ha scritta.
5. Aggiornata, superata o ritirata. La conoscenza che sembra obsoleta può essere segnalata come attività di aggiornamento, che una persona o un agente porta a termine. Una decisione sostituita da una successiva smette di essere trattata come attuale. Vedi suggerimenti e autoverifica.

Che cosa cambia quando passi a un altro progetto

Tutto. Workspace Intelligence appartiene al repository, e aprirne uno diverso significa avere un diverso insieme di conoscenza di progetto, condiviso con chiunque altro ci lavori.

Quello che ti porti dietro è User Intelligence, che appartiene a te: le preferenze che hai insegnato a Pathrule e che hai scelto di applicare ovunque.