Lo stack di memoria per agenti AI che tutti devono usare nel 2026 (Guida per sviluppatori)

Il tuo modello e il tuo harness non contano più.

ciò che conta di più è...

il tuo contesto personale / la memoria condivisa che lo fa

Introduzione

ti mostrerò come costruire una memoria condivisa per i tuoi agenti di coding... così il prossimo strumento potrà trovare le decisioni che hai già preso.

la conversazione sull'architettura in Claude, la sessione di debugging in Codex, la spiegazione sepolta in Cursor... lavoro utile che dovrebbe essere ancora disponibile quando cambi strumento, inizi un'altra sessione o torni al progetto dopo un mese di assenza.

TLDR; se non vuoi leggere tutte le 3.845 parole, dai questo repository GitHub al tuo agente ➡️ https://github.com/codejunkie99/agentic-stack-desktop

ho costruito tutto questo usando Kimi K3 in Codex Harness. Il video è stato realizzato e montato usando Kimi K3 con Cua per Computer Use

questa è una guida per builder su agentic stack desktop, dalla tua prima importazione a un flusso di lavoro in cui un agente può recuperare una decisione precedente, verificarla rispetto al codice corrente, apportare una modifica delimitata e lasciare qualcosa di utile.

ecco cosa ottieni:

1. le fondamenta: cosa sopravvive quando cambi strumento
2. il percorso più veloce: costruisci un workspace che puoi giudicare
3. la configurazione operativa: separa l'indagine dall'implementazione
4. l'esercizio pratico: prendi un bug ricorrente attraverso l'intero ciclo
5. il livello condiviso: porta il recupero nei tuoi altri strumenti
6. il livello durevole: cosa merita di diventare una lezione
7. le regole operative: brevi, delimitate, ispezionabili
8. la build personalizzata: modifica il workspace attorno a un punto di attrito reale
9. scalare: aggiungi copertura dove il ciclo precedente ha esposto una lacuna
10. il foglio di costruzione

1. le fondamenta: cosa sopravvive quando cambi strumento

immagina di aver passato un pomeriggio a decidere come dovrebbe funzionare una funzionalità. hai esplorato alternative, trovato un vincolo, rifiutato la soluzione ovvia e infine hai scelto qualcosa che si adatta.

l'implementazione viene commitata. la spiegazione rimane in una conversazione.

una settimana dopo, un altro agente guarda il codice e propone lo stesso approccio che avevi già rifiutato. Potrebbe anche essere un suggerimento ragionevole date le informazioni a sua disposizione. Il pezzo mancante è la discussione che ti ha fatto scegliere diversamente.

rendi recuperabile il ragionamento

inizia qui: rendi quella discussione recuperabile, poi fai in modo che il prossimo agente la controlli prima di agire.

agentic stack fornisce un workspace macOS nativo con cronologia ricercabile e selezionata da Claude Code, Codex, OpenCode e Cursor. Claude Code e Codex eseguono anche attraverso le loro CLI ufficiali; Cursor e OpenCode attualmente forniscono solo contesto. panoramica del repository

il flusso di lavoro qui sotto è come userei queste capacità. I brief, la divisione delle responsabilità e l'esercizio pratico sono pratiche operative suggerite che puoi adattare.

2. il percorso più veloce: costruisci un workspace che puoi giudicare

inizia con un repository che conosci. Scegli qualcosa di cui ricordi i file importanti, una decisione recente e in cui puoi riconoscere una raccomandazione sbagliata.

Un progetto familiare ti dà un punto di riferimento. Se inizi con codice e cronologia sconosciuti, proverai a convalidare lo strumento e imparare il sistema allo stesso tempo.

Per una build dal sorgente, i requisiti documentati includono macOS 14+, Python 3.10+, Xcode Command Line Tools e una toolchain Swift 6. Installa e accedi alla CLI di coding che vuoi eseguire. requisiti

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

Apri il tuo repository nell'app e completa la configurazione guidata. Questa è un'anteprima con firma ad hoc, quindi macOS potrebbe richiedere una conferma al primo avvio. configurazione

Imposta il primo controllo di accettazione

Prima di importare qualsiasi cosa, scrivi la domanda a cui vuoi che il primo agente risponda. Qualcosa come: perché il nostro job di esportazione elabora i record in lotti, e l'implementazione attuale ha ancora bisogno di quel limite?

Quella domanda diventa il tuo primo controllo di accettazione. Stai cercando la decisione giusta, il codice di supporto giusto e una spiegazione onesta di tutto ciò che l'agente non può stabilire.

2.1 la prima importazione: dagli una decisione che valga la pena trovare

Apri Knowledge Graph → Graph → Import memory, visualizza l'anteprima delle fonti e seleziona il materiale che vuoi includere.

Il grafico utilizza la ricerca full-text di SQLite, con connessioni basate su argomenti, collegamenti al repository e provenienza; gli archivi delle chat originali rimangono invariati. comportamento di importazione

Inizierei con una conversazione completata contenente una decisione che ricordi. Soprattutto una in cui hai rifiutato qualcosa di attraente a causa di un vincolo che non sarebbe ovvio dal codice finale.

Cerca quella decisione dopo l'importazione. Apri il risultato e ispeziona la fonte. Assicurati di guardare la conversazione che intendevi importare, con abbastanza spiegazioni circostanti per capire cosa è successo.

Verifica se riesci a trovarla di nuovo

Poi prova una seconda ricerca usando il vocabolario che useresti naturalmente il mese prossimo. Potresti ricordare il nome della funzionalità mentre la conversazione usava un nome di modulo interno. Trovare questa discrepanza ora ti aiuta a capire come recuperare il materiale in seguito.

Mantenerei la prima raccolta abbastanza piccola da poterla ispezionare manualmente. Una risposta corretta da una fonte nota è una prova utile che il flusso di lavoro funziona.

Un numero elevato di importazioni ti dice quanto materiale è entrato nel sistema, lasciando che la sua utilità venga testata.

Espandi la raccolta quando un'altra attività ti dà una ragione per farlo.

2.2 la prima sessione di lavoro: rendi l'esperimento abbastanza piccolo da finirlo

Darei alla configurazione iniziale un traguardo prima di aprire un'altra schermata di configurazione. Entro la fine della sessione, dovresti aver recuperato una decisione nota, averla verificata rispetto al repository e prodotto una revisione che puoi spiegare a qualcun altro.

Scegli un esempio con un confine ristretto. Un singolo comportamento di esportazione è più facile da ispezionare dell'intera piattaforma dati. Una scelta precedente su un componente è più facile da verificare di una domanda ampia su se l'architettura sia buona.

Tieni una breve nota accanto all'esercizio: la domanda, la fonte prevista, l'implementazione corrente e la parte che richiede giudizio. Questo è il tuo riferimento per valutare la risposta.

Diagnostica il guasto giusto

• Se il revisore recupera la conversazione sbagliata, lavora sul recupero.
• Se trova la conversazione giusta ma interpreta male il codice, lavora sull'indagine.
• Se i risultati sono validi ma l'implementazione non soddisfa il requisito, migliora il passaggio di consegne.

Questa separazione è importante perché ogni fallimento richiede una correzione diversa. Aggiungere più memoria non risolverà necessariamente un brief poco chiaro, e riscrivere il brief non recupererà una fonte che non è mai stata importata.

Completa il ciclo più piccolo, registra cosa è fallito e usa quella prova per scegliere il miglioramento successivo.

3. la configurazione operativa: separa l'indagine dall'implementazione

La mia prima configurazione suggerita ha un revisore in sola lettura e un implementatore con accesso di modifica al progetto. Dai a ciascuno un risultato chiaro e rendi il passaggio di consegne qualcosa che puoi leggere prima che inizi qualsiasi modifica.

I profili agente supportano un runner, modello, sforzo, istruzioni e accesso ai file. Le conversazioni appartengono ai progetti e i follow-up riprendono le loro sessioni CLI sottostanti. modello di conversazione

1. agente 1: il revisore riceve la prima domanda: cosa abbiamo deciso, cosa fa il codice ora e c'è una lacuna che vale la pena affrontare?
2. agente 2: l'implementatore riceve la risposta revisionata più una richiesta delimitata: apporta questa modifica di comportamento, in questo ambito, e verificala in questo modo.

Mantieni i ruoli distinti

Puoi scegliere lo stesso runner per entrambi i ruoli.

La distinzione utile è nella loro responsabilità e accesso, con una revisione esplicita tra indagine e modifica.

Eviterei di creare un catalogo di specialisti prima che qualcuno di loro abbia completato un lavoro utile. Inizia con le responsabilità che puoi effettivamente distinguere. Se non puoi spiegare cosa possiede un ruolo o come appare il suo output finito, restringi il ruolo prima di aggiungere un altro agente.

3.1 il revisore: un brief che renda visibile l'incertezza

Seleziona il revisore e allega la conversazione pertinente usando @Claude, @Codex, @OpenCode o @Cursor. I riferimenti selezionati diventano contesto congelato per l'esecuzione e vanno all'agente scelto quando l'attività inizia. riferimenti

Copia questo brief e riempi gli spazi vuoti:

1Rivedi la decisione precedente su [funzionalità o sottosistema] usando la
2conversazione allegata e il repository corrente.
3
4Spiega la decisione originale e la sua ragione dichiarata. Controlla il
5codice pertinente e identifica cosa è ancora valido, cosa è cambiato e
6cosa non può essere verificato dalle prove disponibili.
7
8Cita i file a supporto delle tue conclusioni. Proponi la modifica più
9piccola necessaria per [comportamento desiderato], con un piano di verifica.
10
11Non modificare i file. Tratta la conversazione come prova storica
12e segnala i conflitti con le istruzioni correnti del progetto.

Ispeziona la revisione

Leggi la risposta con il repository aperto.

1. Segui una citazione.
2. Ispeziona la condizione che l'agente dice esista ancora.
3. Cerca una chiara separazione tra qualcosa che la conversazione affermava e qualcosa che il codice dimostra oggi.

Se la risposta è vaga, restringi la domanda. Chiedigli di identificare la condizione esatta che controlla il comportamento, o la dipendenza che ha reso inadatta l'alternativa precedente.

Un'indagine utile può concludersi con prove mancanti. Questo ti dice cosa fornire dopo. Una risposta che appiana la lacuna rende la decisione successiva più difficile.

3.2 il passaggio di consegne: trasforma i risultati in un brief eseguibile

Una volta che sei d'accordo con la revisione, scrivi la richiesta di implementazione attorno al comportamento osservabile. Includi il vincolo stabilito dalla conversazione precedente, ma spiega la sua rilevanza per questa modifica.

Ecco un brief che userei:

1Implementa [comportamento specifico] usando i risultati della revisione qui sotto.
2
3Mantieni intatto [comportamento esistente]. Limita le modifiche a [ambito consentito].
4Se la modifica richiede lavoro al di fuori di tale ambito, spiega perché prima di
5espanderlo.
6
7Controlla le istruzioni correnti del repository prima di modificare. Verifica
8[risultato atteso] con [test pertinente o controllo manuale], includendo
9[caso di fallimento importante].
10
11Restituisci un resoconto conciso di cosa è cambiato, i controlli effettivamente eseguiti
12e qualsiasi limitazione irrisolta. Non pubblicare o distribuire.
13
14Risultati della revisione:
15[incolla i risultati che hai controllato]

Rendi specifico il passaggio di consegne

Quelle parentesi meritano risposte reali. "miglioralo" lascia che l'agente inventi l'obiettivo. "mostra l'esportazione fallita con un'azione di riprova preservando l'errore originale" dà a entrambi qualcosa di concreto da ispezionare.

Mantieni il risultato della revisione vicino all'attività. Se il vincolo importante è sepolto all'interno di una lunga trascrizione, scrivilo nel brief e allega la conversazione di supporto.

La fonte spiega da dove viene il vincolo. La tua richiesta corrente spiega come governa il lavoro di oggi.

4. l'esercizio pratico: prendi un bug ricorrente attraverso l'intero ciclo

Ecco un esercizio ipotetico per rendere concreto il flusso di lavoro. Immagina che il tuo progetto occasionalmente crei esportazioni duplicate dopo un'interruzione di rete, e una conversazione più vecchia contenga un'indagine sul comportamento di riprova.

1. passo 1: per prima cosa, recupera quella conversazione. Chiedi al revisore di identificare cosa ha stabilito l'indagine precedente, poi controlla il percorso di riprova corrente rispetto ad essa.
2. passo 2: supponi che la vecchia discussione dica che le richieste possono essere ripetute dopo una risposta incerta. Il revisore dovrebbe stabilire se l'implementazione corrente lo permette ancora, quale codice lo controlla e se esiste già un meccanismo inteso a prevenire i duplicati.
3. passo 3: se le prove supportano una modifica, dai istruzioni all'implementatore attorno al caso di fallimento. Specifica cosa dovrebbe fare una richiesta ripetuta, quale comportamento di esportazione esistente deve rimanere e come verificherai una risposta interrotta.
4. passo 4: poi ispeziona la modifica e verifica il percorso pertinente. Controlla sia l'esportazione riuscita che la riprova dopo l'incertezza. Se l'ambiente non può riprodurre l'interruzione, registra quella limitazione e decidi quale ulteriore verifica è necessaria.
5. passo 5: infine, rivedi la lezione che potresti conservare: le condizioni che hanno causato il duplicato, il meccanismo che lo affronta e le prove a supporto della correzione.

Questo esempio è un esercizio proposto, non un'affermazione su un bug in agentic stack. Sostituisci un fallimento reale dal tuo progetto e mantieni la stessa sequenza.

5. il livello condiviso: porta il recupero nei tuoi altri strumenti

Il desktop può installare l'integrazione tramite Tools → Connections → Use @ in tools → Enable in all four tools. Il comando equivalente è:

1agentic-stack context install

Riavvia gli strumenti dopo. L'entry MCP espone la ricerca di conversazioni, la lettura di chat selezionate e la ricerca di memoria condivisa. integrazione

Il comportamento del selettore dipende dal client; dove il completamento delle risorse non è disponibile, l'agente può cercare e presentare conversazioni corrispondenti. comportamento del client

Verifica la continuità tra gli strumenti

Il mio primo controllo sarebbe chiedere a un altro strumento di trovare la stessa decisione che hai appena revisionato. Dagli l'argomento, chiedigli di presentare la fonte corrispondente e conferma la selezione prima di chiedere un'analisi.

Poi confronta il risultato con la fonte che hai ispezionato nel desktop. Stai testando la continuità del contesto tra gli strumenti, quindi mantieni stabile la domanda mentre cambi il posto in cui la fai.

Includerei anche la fonte nel brief dell'attività finale ogni volta che una decisione influisce materialmente sul lavoro. "ne abbiamo discusso prima" dà all'agente un problema di ricerca. "usa questa conversazione revisionata e verifica questa condizione" gli dà una responsabilità specifica.

6. il livello durevole: cosa merita di diventare una lezione

Il recupero riporta in vista il materiale vecchio. Devi ancora decidere quale autorità dovrebbe avere quel materiale.

Una conversazione può contenere un piano abbandonato, una diagnosi errata o una risposta che era ragionevole prima che il progetto cambiasse. Preservarla ti permette di ispezionare il ragionamento in seguito; accettare una lezione è una decisione separata.

Tasks contiene i record di esecuzione. Knowledge → Lessons supporta la messa in scena, l'accettazione, il rifiuto e la revisione delle lezioni con motivazioni, mentre la cronologia importata rimane separata dalle lezioni accettate. ciclo di vita della revisione

Scrivi una lezione che puoi contestare

Scriverei una lezione proposta con abbastanza dettagli per essere contestata: la condizione a cui si applica, il comportamento che raccomanda, la ragione e le prove.

Per l'ipotetico bug di esportazione, "riprova sempre in sicurezza" è troppo vago per essere utile. Una nota utile identifica cosa rende incerta una riprova e come l'implementazione di questo progetto dovrebbe riconoscere il lavoro ripetuto.

Poi chiedi cosa renderebbe obsoleta la lezione. Un backend diverso, un contratto modificato o un sottosistema sostituito potrebbero rimuovere il vincolo originale. Includi quel confine in modo che una revisione futura abbia un punto di partenza.

Questo è come manterrei una correzione utile dal diventare una regola che sopravvive alla sua ragione.

6.1 la struttura della memoria: metti ogni tipo di conoscenza al suo posto

Sotto il desktop, l'architettura portatile .agent/ separa lo stato di lavoro, gli episodi precedenti, i modelli durevoli e le preferenze personali. Le skills forniscono procedure riutilizzabili, mentre i protocolli descrivono permessi e delega. architettura

• L'indagine corrente appartiene al lavoro in corso.
• Il suo resoconto completato diventa prova di ciò che è successo.
• Un modello verificato può diventare una lezione durevole.
• Una preferenza su come vuoi che i risultati siano presentati appartiene alle tue preferenze.

Mantenere chiari questi significati rende più facile la revisione successiva. Una soluzione temporanea dovrebbe spiegare quando può essere rimossa. Una preferenza di scrittura personale non dovrebbe diventare accidentalmente una regola architetturale.

Trasforma una procedura verificata in una skill

Lo stesso vale per le skills. Creerei una skill quando una procedura è abbastanza utile da essere ripetuta e abbastanza specifica da essere seguita. Includi gli input di cui ha bisogno, i passaggi che contano, l'output atteso e le condizioni che richiedono un'altra decisione.

Per l'esempio di esportazione, l'indagine potrebbe produrre una procedura utile per il controllo delle regressioni. Salvala solo dopo aver confermato che i passaggi funzionano sul tuo progetto. Una trascrizione copiata dà al prossimo agente una storia; una procedura revisionata gli dà un metodo che puoi valutare.

7. le regole operative: brevi, delimitate, ispezionabili

Ecco le regole che metterei attorno al flusso di lavoro dal primo progetto.

1. regola 1: ogni brief nomina il risultato. Una revisione restituisce risultati con prove. Un'implementazione restituisce una modifica di comportamento con controlli. Una proposta di lezione restituisce un'affermazione che puoi accettare o rifiutare.
2. regola 2: l'accesso segue il lavoro. L'indagine inizia con accesso in sola lettura; l'implementazione ottiene l'ambito necessario per la modifica concordata. Mantieni espliciti nella richiesta la pubblicazione, la distribuzione e altre azioni consequenziali.
3. regola 3: chiedi una verifica effettiva. Il rapporto dovrebbe dire cosa è stato eseguito e cosa è successo. Se un controllo non era disponibile, rendilo visibile invece di trattare silenziosamente il risultato mancante come un successo.
4. regola 4: mantieni il contesto storico subordinato alle prove attuali e alle istruzioni applicabili del progetto. Una conversazione recuperata può spiegare una decisione precedente pur essendo ancora superata.
5. regola 5: rivedi il risultato prima di conservare la conclusione. La spiegazione di un agente del proprio lavoro è qualcosa da ispezionare insieme al diff e al comportamento osservato.

Queste sono pratiche operative per la configurazione che sto descrivendo. Adattale al tuo progetto, ma mantieni le responsabilità abbastanza chiare che un'altra persona possa dire se un'attività ha soddisfatto il suo brief.

7.1 la coda di revisione: rendi il lavoro facile da accettare o rispedire indietro

Chiederei a ogni implementazione di finire nella stessa forma:

• cosa è cambiato,
• cosa è stato verificato,
• cosa rimane incerto,
• e se propone una lezione riutilizzabile.

Questo ti dà un modo coerente per leggere il lavoro completato senza ricostruire l'intera conversazione ogni volta. Il dettaglio di supporto può rimanere disponibile per la parte che devi ispezionare.

Quando rispedisci qualcosa indietro, allega la correzione al requisito che ha mancato. "questo è sbagliato" inizia un altro giro di ipotesi. "la riprova crea una seconda esportazione in questa condizione; preserva l'identità della richiesta originale e riesegui questo controllo" identifica la lacuna.

Decidi cosa merita di sopravvivere

Dopo che la correzione è stata superata, decidi se rappresenta un vincolo ricorrente o un dettaglio di quell'attività. Salva il primo quando ha prove dietro di sé. Il secondo può rimanere nella cronologia dell'attività.

Resisterei alla tentazione di trasformare ogni commento di revisione in memoria permanente. Alcune correzioni sono utili una volta sola. Altre rivelano una regola che dovrebbe plasmare il lavoro successivo. Fare questa distinzione fa parte della manutenzione del sistema.

La domanda utile alla fine di una revisione è: cosa dovrebbe sapere un futuro agente prima di tentare un'attività simile, e dove può verificare quella conoscenza?

7.2 la disciplina dei costi: dai a ogni esecuzione una condizione di arresto

Includerei una condizione di arresto in qualsiasi attività che potrebbe continuare ad espandersi. Per una revisione, potrebbe essere un resoconto scritto del comportamento pertinente e delle domande irrisolte. Per l'implementazione, potrebbe essere la modifica concordata che supera i suoi controlli nominati.

Se l'agente scopre un problema più grande, chiedigli di spiegare il risultato e la sua relazione con l'attività originale prima di assorbire quel lavoro nella modifica corrente.

Decidi se questo appartiene all'attività corrente.

Confronta i risultati e applica i limiti

Scegli il runner e il modello usando le opzioni effettivamente disponibili nel tuo account, poi giudicali sui tuoi esempi delimitati. Confronterei la qualità dei risultati, le correzioni richieste e la verifica fornita prima di rendere una configurazione predefinita.

Mantieni l'esperimento equo mantenendo stabili l'attività e il materiale di partenza. Se ogni prova cambia la domanda, il contesto e i criteri di accettazione, il confronto sarà difficile da interpretare.

E metti tutti i controlli di spesa dove sono effettivamente applicati dai tuoi strumenti o provider. Una frase che chiede a un agente di essere economico è una preferenza; ispeziona i controlli disponibili prima di fare affidamento su un limite.

8. la build personalizzata: modifica il workspace attorno a un punto di attrito reale

Una volta completato il ciclo di base, avrai un'idea migliore di cosa vuoi dal desktop stesso. Forse un passaggio di navigazione ripetuto ti dà fastidio, o una vista attività rende un campo più difficile da ispezionare di quanto dovrebbe essere.

Scrivi l'attrito prima di proporre una funzionalità. Descrivi l'azione che stai cercando di compiere, dove perdi tempo e cosa ti permetterebbe di fare il comportamento migliorato.

Poi apri il repository sorgente e dai al tuo agente una richiesta di modifica delimitata. Includi come intendi ispezionare il risultato nell'app.

Costruisci e ispeziona la modifica

Il repository documenta questi comandi di sviluppo e packaging:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

comandi di sviluppo

Le modifiche SwiftUI richiedono una ricostruzione e un riavvio per essere ispezionate. flusso di lavoro desktop

Testerei l'interazione che ha motivato la modifica e un caso vicino che potrebbe rompersi. Se migliori il filtraggio delle attività, ispeziona i risultati filtrati, un set di risultati vuoto e il percorso di ritorno all'elenco completo.

Usa lo stesso standard che hai applicato all'esercizio di esportazione: un prima concreto, una modifica delimitata e un dopo osservato.

8.1 l'opzione remota: decidi dove dovrebbe vivere il lavoro

Dopo che il flusso di lavoro locale funziona, potresti volere l'esecuzione su un server persistente. Il percorso di self-hosting collega l'app nativa a un servizio a proprietario singolo che possiede i suoi progetti, memoria, cronologia delle attività e accessi CLI; cambiare host non trasferisce automaticamente i dati o le credenziali del tuo Mac. guida all'hosting

Ecco la traduzione in italiano del testo fornito, seguendo tutte le linee guida specificate.

farei quella mossa per una ragione concreta, come mantenere un progetto e il suo ambiente di esecuzione su una macchina che già gestisci. scrivi quella ragione prima di intraprendere il lavoro di deployment.

segui la guida di hosting per i passaggi di configurazione, autenticazione e verifica supportati. tratta il server come un altro ambiente di lavoro con il suo stato da ispezionare.

verifica l'ambiente selezionato

poi ripeti un'attività familiare lì. controlla il progetto selezionato, conferma che l'agente possa accedere alla fonte prevista e verifica che il risultato appartenga all'ambiente server che hai scelto.

usare un'attività nota rende più facile valutare la transizione. se cambi host, progetto e flusso di lavoro contemporaneamente, diventa più difficile identificare quale modifica ha causato un risultato sorprendente.

Il locale è sufficiente per imparare lo schema di base. espandi l'infrastruttura quando il lavoro ti dà una ragione.

9. scalare: aggiungi copertura dove il ciclo precedente ha mostrato una lacuna

Espanderei questa configurazione in base al contesto mancante che incontri durante le attività reali.

• se una revisione necessitava di una discussione precedente sull'architettura, importa quella discussione.
• se l'implementazione richiedeva ripetutamente la stessa procedura, sviluppa e verifica una skill.
• se una decisione viene continuamente riaperta, scrivi una lezione mirata con le prove che la supportano.

mantieni una piccola raccolta di domande di cui conosci già le risposte. usale dopo aver modificato le tue importazioni o il flusso di lavoro: trova questa decisione, spiega questo vincolo, identifica il codice che lo implementa e segnala la parte che non è più attuale.

espandi quando il lavoro lo giustifica

aggiungerei un altro ruolo agente solo quando la sua responsabilità è chiara dal lavoro. una revisione ricorrente della documentazione può giustificare un brief dedicato. una richiesta una tantum può adattarsi perfettamente a un ruolo esistente.

espandi le parti che si sono guadagnate il loro posto. mantieni il resto abbastanza semplice da capire quando qualcosa va storto.

9.1 l'abitudine alla manutenzione: rivedi la conoscenza quando il sistema cambia

Rivedrei le lezioni pertinenti ogni volta che un sottosistema cambia abbastanza da alterare le loro ipotesi. usa il cambiamento stesso come innesco: una nuova dipendenza, un livello di archiviazione sostituito, un ambiente di deployment diverso o un requisito di prodotto rivisto.

chiedi quali lezioni esistenti dipendono dal vecchio comportamento, poi ispeziona quelle fonti insieme al cambiamento. mantieni ciò che è ancora valido, rivedi ciò che necessita di un ambito più ristretto e ritira ciò che non si applica più attraverso il flusso di lavoro di revisione disponibile.

La parte importante è preservare la spiegazione. un futuro costruttore dovrebbe essere in grado di capire perché esisteva la regola precedente e cosa è cambiato abbastanza da sostituirla.

aggiorna le procedure e risolvi i conflitti

per le skill, esegui di nuovo la procedura dopo un cambiamento che influisce sui suoi input o comandi. se un passaggio non funziona più, aggiorna la procedura in base al fallimento osservato e ripeti il controllo pertinente.

questo mantiene la manutenzione collegata agli eventi reali del progetto. stai rivedendo la conoscenza che molto probabilmente è diventata obsoleta, con le prove attuali già davanti a te.

quando un'attività fa emergere note in conflitto, rendi la risoluzione di quel conflitto parte della revisione. identifica quale affermazione si applica alla versione corrente e lascia il risultato abbastanza chiaro che il prossimo agente possa seguire il ragionamento senza ripetere l'intera indagine.

lascia un passaggio di consegne utile

prima della sessione successiva, lascia un breve passaggio di consegne che descriva il risultato verificato, la domanda aperta e la fonte che un altro agente dovrebbe leggere per primo. mantienilo specifico per lo stato del progetto che hai effettivamente ispezionato.

questo dà al lavoro di domani un punto di partenza che puoi tracciare, specialmente quando torni attraverso un altro strumento o dopo un periodo di assenza, con il ragionamento originale ancora disponibile.

10. il foglio di costruzione

1. scegli un repository familiare e una decisione che puoi riconoscere.
2. costruisci il desktop, completa la configurazione e importa una conversazione completata contenente quella decisione.
3. cercala, ispeziona la fonte e allegala a una revisione in sola lettura del codice corrente.
4. verifica tu stesso i risultati, poi prepara un'implementazione delimitata con una condizione di accettazione visibile.
5. ispeziona il diff ed esegui la verifica pertinente, incluso il caso di fallimento che ha motivato il lavoro.
6. crea una lezione solo quando il risultato la supporta, con l'ambito e la ragione registrati.
7. trasforma una procedura in una skill quando hai verificato che vale la pena ripeterla.
8. prova la stessa estrazione da un altro strumento, poi espandi il tuo contesto o la tua infrastruttura quando un'attività reale lo richiede.

inizia con una decisione questa settimana e portala avanti per tutto il ciclo prima di importare tutta la tua cronologia.

il prossimo agente dovrebbe ereditare il tuo giudizio.