Il bibliotecario.

Gira una volta al giorno, presto. Rilegge la memoria di lavoro del workspace — le iniziative con il loro stato, la conoscenza, i prompt degli agenti — e cerca le cose che non tornano. Quello che trova non finisce tutto nello stesso posto, e la biforcazione al centro del disegno è la parte che conta.

Il giro completo. Sopra la generazione, sotto il consumo.

Fino a poco fa esisteva solo la metà di sopra. Il Librarian trovava, scriveva, e la coda cresceva: centoventisei rilievi in tre mesi, zero decisioni. Un sistema che segnala e basta non è un sistema di qualità, è un accumulatore.

Il difetto non era la quantità di rilievi: era che venivano trattati tutti allo stesso modo. Un conflitto fra due fonti e la misura dello stile di un prompt finivano nella stessa lista, e la seconda categoria — che si genera da sola a ogni run — sommergeva la prima.

La regola che li separa è una domanda sola.

Una domanda sola, e decide tutto il resto.

«Questo prompt ha sedici trattini lunghi» non chiede un verdetto: chiede una riscrittura, e domani il numero è un altro. Accodarlo produce esattamente quello che si era osservato — due terzi della coda occupati da misure, per decine di soggetti, senza che una sola decisione fosse possibile. Quel genere di rilievo ora vive in uno stato che si sovrascrive e si legge quando serve, mentre si lavora su quel prompt.

La regola vale in avanti, non solo per il caso che l'ha generata: un controllo nuovo deve dichiarare da che parte sta prima di poter scrivere. Se non lo fa, non entra.

Un rilievo non risolto viene ritrovato al run successivo, e al successivo ancora. Se ogni ritrovamento fosse una riga nuova, la lista crescerebbe anche a problemi fermi. Ogni rilievo porta quindi un'impronta costruita su tre cose: la famiglia del problema, l'iniziativa e il soggetto. Stessa impronta già aperta, nessuna riga nuova: sale un contatore di ricorrenza.

Il soggetto deve essere il soggetto, non la misura. Una chiave come «stile_di_lora_16_trattini» cambia appena Lora arriva a diciassette, l'impronta cambia con lei e il doppione nasce comunque. È il difetto che ha tenuto la coda gonfia per settimane prima che qualcuno lo guardasse.

Perché lo stesso soggetto può occupare più righe, e perché non è un doppione.

La famiglia resta dentro l'impronta di proposito, ed è la scelta meno ovvia di tutte. Toglierla farebbe collassare i tre casi qui sopra in una riga — ma quelle tre righe pongono tre domande diverse, e ognuna vuole la sua risposta. Il costo che restava, cioè ritrovarsi lo stesso soggetto in giorni diversi senza saperlo, si paga mostrando i fratelli accanto all'item corrente: rispondi sapendo cosa c'è intorno.

Arrivano cinque rilievi al giorno, mai di più, uno per messaggio. Nessuna lista: la lista è precisamente ciò che non veniva letto. Tu rispondi come parleresti a una persona, e quello che dici viene mappato su un vocabolario chiuso.

Tre garanzie, e sono la ragione per cui questo meccanismo può toccare i tuoi dati. La prima: nessuna istruzione dedotta dal parlato arriva mai al database — se la frase non mappa, il sistema chiede. La seconda: prima di ogni scrittura vedi il cambiamento proposto, e la conferma è tua. La terza: chi scrive è un solo punto del codice, che valida, esegue e lascia una traccia di chi ha deciso cosa.

La sessione si può interrompere. Se la lasci a metà mentre scendi dal treno, riprende da dove eri: il segnaposto è sul server, non nella chat.

Il briefing di ogni run e i rilievi ancora aperti stanno in /dashboard/librarian, e si abilita dalle impostazioni del workspace. Il giro delle decisioni si fa in chat con /librarian-triage, dal telefono come dal desktop: tre minuti, ed è l'unica dimensione compatibile con il farlo davvero tutti i giorni.

Un'avvertenza onesta: il Librarian non corregge niente da solo, e non è previsto che lo faccia. Trova, propone, e aspetta che qualcuno dichiari come stanno le cose. La memoria resta tua anche quando è sbagliata.