BLUN King

BLUN King 9.1.621

Pubblicato il

King adotta un riepilogo della tua conversazione solo quando il modello ne ha confermato il completamento. Se manca questa conferma, la cronologia della conversazione rimane invariata.

Se la trasmissione del riepilogo termina in modo inatteso, il contesto della conversazione non viene sostituito dal riepilogo incompleto. La modifica riguarda solo la compattazione della conversazione; le risposte normali restano invariate.

Restano aperti alcuni errori isolati nel salvataggio di una sessione; non sono stati corretti con questo aggiornamento.

BLUN King

BLUN King 9.1.620

Pubblicato il

Su Windows la console termina completamente alla chiusura della finestra, così al prossimo avvio non compare più «già in esecuzione».

L'aggiornamento corregge la conclusione del processo della console alla chiusura della finestra. Una console realmente ancora in esecuzione mantiene l'accesso esclusivo alla sua sessione.

La guida è integrata allo stato 620: installazione su Linux, ripresa di sessioni lunghe, ultima sessione all'avvio, Ctrl+L, skill, plugin, obiettivi e incarichi headless. Alla guida CLI attuale.

BLUN King

BLUN King 9.1.619

Data di pubblicazione:

Un singolo errore precedente nel riepilogo della conversazione non blocca più la tua sessione: dopo un riepilogo riuscito King conta solo gli errori nuovi e direttamente consecutivi. Se il riepilogo fallisce due volte di seguito, il messaggio ora mostra chiaramente «Compattazione in pausa» invece di segnalare un contesto pieno.

Restano aperti alcuni errori isolati nel salvataggio di una sessione e nella creazione di un riassunto completo della conversazione; non sono stati corretti con questo aggiornamento.

BLUN King

BLUN King 9.1.618

Data di pubblicazione:

Se, dopo la ripresa della tua sessione, arriva un messaggio Telegram mentre King sta già lavorando, resta in coda e viene consegnato in seguito. King non mostra più questa situazione di attesa come un errore.

Su Linux x64 il terminale usa un binario incluso. In questo modo funziona anche quando npm 12 blocca gli script di installazione; per questo non serve alcun compilatore. A tale scopo King usa la versione preliminare fissata node-pty 1.2.0-beta.15.

BLUN King

BLUN King 9.1.617

Data di pubblicazione:

Quando ricarichi la stessa sessione, King non aggiunge più ripetutamente le istruzioni dei plugin rimaste invariate. Se le istruzioni cambiano, King continua a tenere conto dello stato attuale.

Le anteprime delle grandi uscite degli strumenti ora tengono conto anche della finestra di contesto disponibile. Puoi continuare a leggere per intero le uscite esternalizzate.

Con /profile o /profiles apri la selezione dei profili. King cambia solo quando la tua sessione è pronta. Il lavoro in corso e i messaggi in attesa impediscono un cambio affrettato; il tuo profilo attuale resta attivo.

Quando interrompi un lavoro in corso, King attende anche gli ultimi passaggi di pulizia. Un lavoro non ancora concluso non viene confermato prematuramente come terminato.

BLUN King

BLUN King 9.1.616

Data di pubblicazione:

Dopo una risposta Telegram confermata, King prende in carico gli altri messaggi indirizzati a te al prossimo passaggio sicuro, anche durante un turno in corso.

Dopo una risposta Telegram confermata, King prende in carico gli altri messaggi indirizzati a te al prossimo passaggio sicuro, anche durante un turno in corso. Una risposta già consegnata non blocca più la coda. Le risposte restano associate alla rispettiva chat.

Se interrompi un turno, i messaggi Telegram non ancora presi in carico vengono conservati per la consegna successiva. King ne conferma la ricezione solo quando la sessione li prende effettivamente in carico.

BLUN King

BLUN King 9.1.615

Data di pubblicazione:

King mantiene grandi cataloghi di strumenti disponibili tramite la ricerca degli strumenti e adatta il budget degli strumenti alla finestra di contesto del fornitore.

King mantiene grandi cataloghi di strumenti disponibili tramite la ricerca degli strumenti, senza inviare al modello tutti gli schemi opzionali degli strumenti. Se il fornitore segnala una finestra di contesto più piccola, King adatta il budget degli strumenti; gli strumenti trovati restano disponibili nel passaggio successivo.

Quando necessario, King sposta in anticipo le grandi uscite degli strumenti rispetto a prima. Puoi recuperare l'uscita completa come prima, purché possa essere visualizzata in modo sicuro.

Le risposte Telegram normali e le modifiche ai messaggi non vengono più bloccate per una mancata approvazione linguistica. Un controllo delle risposte che hai configurato resta attivo.

BLUN King

BLUN King 9.1.614

Data di pubblicazione:

I file AGENTS.md e AGENTS.override.md troppo grandi non bloccano più un turno solo per la loro dimensione.

Fuori dalla console King, King legge in totale fino a 32 KiB dai file di istruzioni e ti comunica una volta per sessione il numero di byte omessi.

Nella console King i file restano completi finché il limite della richiesta lo consente.

I collegamenti simbolici e i percorsi non sicuri restano bloccati.

BLUN King

BLUN King 9.1.613

Data di pubblicazione:

King riconosce le richieste al modello troppo grandi già prima dell'invio.

Nella console King, King legge da ogni file AGENTS.md e AGENTS.override.md al massimo 32 KiB. Ciò che va oltre viene tralasciato e ti viene mostrato quanti byte sono stati omessi.

Prima dell'invio, King stima ora la dimensione dell'intera richiesta al modello, incluse istruzioni, cronologia, definizioni degli strumenti e dati delle immagini. Se si avvicina al limite di byte del server, inizia una compattazione graduale. Se una richiesta non può essere suddivisa in modo sicuro, King si interrompe senza scartare silenziosamente la cronologia salvata.

King salva localmente le chiamate di strumenti completate come metadati: nome dello strumento, momento, stato e, per gli strumenti di file, eventualmente il percorso. Input, output, comandi e chiavi non vengono salvati. Con /memory tools puoi cercare nelle voci del tuo profilo.

La diagnostica del contesto mostra numeri aggiuntivi sulla composizione delle richieste. Una misurazione delle fasi attivabile misura il tempo fino alla chiamata del modello senza registrare contenuti.

L'indicatore di utilizzo include i token di pensiero segnalati separatamente, purché il fornitore li trasmetta.

Non rilasciata, sostituita dalla 9.1.613

BLUN King 9.1.612

Data di pubblicazione:

La 9.1.612 non è stata pubblicata come aggiornamento per i clienti. La protezione precoce dei byte non agiva su una richiesta superiore a 900 KB quando la cronologia da sola restava sotto i 600 KB. La 9.1.613 sostituisce questa versione.

BLUN King

BLUN King 9.1.611

Data di pubblicazione:

Le richieste di compattazione grandi restano entro il limite di byte del server.

  • King suddivide una richiesta di compattazione troppo grande in passaggi cronologici in base alla dimensione della richiesta. Così la compattazione può continuare anche quando la richiesta contiene più byte di quanti il server ne accetti in una volta.
  • Se anche un singolo messaggio non rientra nel limite, la cronologia salvata resta invariata. King non la scarta per forzare la compattazione.

Con questo non sono dimostrati né tempi di attesa del modello più brevi né un minor consumo di token. Un aggiornamento non riavvia una sessione King già in esecuzione.

BLUN King

BLUN King 9.1.610

Data di pubblicazione:

Puoi installare di nuovo King su Linux e avviare di nuovo i profili, e un secondo avvio di King su Windows non fallisce più con un messaggio fuorviante sulle ACL private.

  • Linux è di nuovo nell'elenco dei sistemi operativi supportati del pacchetto npm. Se su Linux hai una versione precedente, installi 9.1.610 tramite l'aggiornamento normale.
  • Gli avvii espliciti con --profile e le abbreviazioni dei nomi di profilo esistenti portano alla directory del profilo scelto. Un semplice nome sconosciuto non crea più silenziosamente un profilo vuoto; un nuovo profilo lo crei consapevolmente con --profile.
  • Se a un profilo esistente manca l'accesso proprio, King offre /login invece di interrompersi per una configurazione del modello blun/king mancante.
  • Su Windows il controllo delle directory private riesce anche quando il bridge Telegram tiene aperta una directory di plugin. TEMP e TMP vengono passati all'helper ACL e in caso di errori di directory King indica il percorso interessato e la causa reale.
  • Se è già in esecuzione un King interattivo, King lo rileva prima del rafforzamento delle ACL private e ne segnala il PID, invece di presentare un secondo avvio come errore delle ACL private.

Un profilo vuoto non eredita in 9.1.610 i dati di accesso dalla home directory condivisa. La richiesta /login attuale può ancora mostrare «OAuth login expired», anche se questo profilo non ha mai effettuato l'accesso.

Il percorso di aggiornamento Linux da 9.1.114 a 9.1.610 è stato testato dopo la pubblicazione. Il percorso di aggiornamento Windows da 9.1.609 a 9.1.610 non è stato misurato.

Un aggiornamento non riavvia una sessione King già in esecuzione.

BLUN King

BLUN King 9.1.609

Data di pubblicazione:

Apri la selezione dell'effort con Ctrl+L conservando la bozza dell'editor.

  • Ctrl+L apre la selezione dell'effort esistente senza perdere la bozza dell'editor. Le impostazioni dell'effort e le limitazioni del modello esistenti vengono riutilizzate, invece di creare un secondo percorso di configurazione.
  • La regola esistente per le sessioni in corso resta valida: una modifica dell'effort durante il lavoro attivo viene rifiutata, non messa in attesa per dopo. Durante la riproduzione o una presa di controllo da parte dell'editor la scorciatoia viene ignorata.

Queste modifiche non dimostrano tempi di risposta più rapidi durante il funzionamento, né un minore consumo di token fatturato, e non rappresentano una piena parità con OpenClaw.

BLUN King

BLUN King 9.1.608

Data di pubblicazione:

Nei gruppi Telegram ormai raggiungono King solo i messaggi che lo menzionano. Le tue selezioni multiple e l'annullamento graduale delle domande restano invariati.

  • Nei gruppi Telegram i messaggi che non si rivolgono a King entrano nel contesto di sessione solo dopo il controllo della menzione. Chi ha disattivato espressamente il controllo lo mantiene.
  • Le tue selezioni multiple e l'annullamento graduale delle domande restano invariati. Il piè di pagina dell'obiettivo gira su un timer di aggiornamento comune.
  • Il carico della trasmissione ACL di Windows diminuisce senza indebolire il controllo dei permessi. Il ripristino dopo errori temporanei nella sostituzione della configurazione è limitato; la titolarità della scrittura resta conservata.
  • Prima del nuovo tentativo King verifica se un marcatore di scrittura di Windows rimosso in parallelo sia realmente sparito. I marcatori esistenti non leggibili continuano a causare l'interruzione.

Queste modifiche non dimostrano tempi di risposta più rapidi durante il funzionamento, né un minore consumo di token fatturato, e non rappresentano una piena parità con OpenClaw.

BLUN King

BLUN King 9.1.607

Data di pubblicazione:

La tua sessione scelta per ultima viene ripristinata, le scritture fallite vengono segnalate onestamente e ogni tentativo HTTP riceve un timestamp di inizio.

  • Il ripristino opzionale della sessione scelta per ultima si attiva con resume_last_selected in tui.toml. La selezione vale per l'account confermato, il runtime, l'agente e l'area di lavoro. L'avvio normale resta invariato, le selezioni di sessione esplicite hanno la precedenza; le selezioni non disponibili ricadono su una nuova sessione, non su un'altra.
  • Dopo un'attivazione fallita la selezione precedente resta conservata. Se l'account cambia durante l'attivazione, non viene salvata alcuna selezione.
  • Le scritture di file fallite non vengono contrassegnate come riuscite. Il protocollo di continuazione esistente per le righe complete nelle scritture oltre 2.048 byte UTF-8 viene spiegato, senza aumentare il limite né riprovare automaticamente.
  • Immediatamente prima di ogni tentativo HTTP viene registrato un timestamp di inizio in tempo reale (wall clock) per la correlazione diagnostica. Né i contenuti delle richieste né le credenziali di accesso finiscono nella diagnosi.
  • I caratteri Unicode al di fuori del piano di base (ad esempio gli emoji) restano completamente conservati entro i limiti esistenti del budget di archiviazione, senza aumentare questi budget né creare un'ulteriore memoria.

Queste modifiche non attestano tempi di risposta più rapidi durante il funzionamento, né un minore consumo di token fatturato, non stabiliscono una piena parità con il gateway e non escludono dal contesto i messaggi Telegram non indirizzati.

BLUN King

BLUN King 9.1.606

Data di pubblicazione:

Alla ripresa di una sessione compaiono prima le pagine del trascritto attuali; le pagine più vecchie vengono caricate dalla navigazione del trascritto esistente.

  • Alla ripresa di una sessione interattiva compaiono prima le pagine del trascritto attuali; le pagine più vecchie vengono caricate dalla navigazione del trascritto esistente. La cronologia salvata completa e il contesto del modello attivo restano conservati.
  • All'avvio vale un obiettivo di visualizzazione di 200 record di riproduzione. Con --history-limit da 1 a 2000 si può regolare la visualizzazione della prima pagina e delle pagine più vecchie; i turni di conversazione completi e le coppie di strumenti possono superare l'obiettivo.
  • La prima visualizzazione delle attivazioni di skill e plugin resta conservata oltre i confini di pagina. La posizione di scorrimento della home è corretta, così il caricamento delle pagine più vecchie non lascia uno schermo vuoto.

Queste modifiche riducono il lavoro di rendering iniziale del trascritto. Non attestano tempi di risposta del modello più rapidi, né un minore consumo di token o fatture più basse, non migliorano la cache del provider e non limitano quanto viene letto dal disco all'avvio.

BLUN King

BLUN King 9.1.605

Data di pubblicazione:

Controlla le fonti di contesto, gestisci le attività in corso e fornisci un primo messaggio all'avvio della console. L'elaborazione della cronologia locale e i controlli di compattazione sono stati ampliati.

  • Le cronologie locali delle sessioni vengono riprodotte in blocchi. Le pagine di visualizzazione archiviate si trovano senza dover esaminare tutti i blocchi precedenti. La cronologia completa salvata, i controlli di integrità dell'archivio e il ripristino esistente vengono conservati.
  • I risultati ripetuti degli strumenti vengono preparati in modo uniforme per il contesto del modello tra le compattazioni registrate. Gli output locali completi e i diritti di lettura esistenti vengono conservati. Gli output non vengono spostati fuori dal contesto se poi non risultano recuperabili tramite il percorso di ripristino garantito.
  • La compattazione automatica finale sostituisce il contesto attivo solo se riduce la cronologia con lo stesso metodo di stima. In caso di rifiuto, la cronologia originale viene conservata. Il trigger opzionale max_request_history_bytes utilizza il controllo di compattazione esistente, è disattivato per impostazione predefinita e non limita l'intero corpo della richiesta al provider.
  • La diagnostica del contesto dispone ora di viste separate e di un'attribuzione delle fonti per istruzioni, memoria, skill e messaggi precedenti. I byte del contenuto serializzato, le stime locali dei token e il consumo segnalato restano separati.
  • La titolarità della sessione viene conservata anche in presenza di attività in attesa, eventi in ritardo, richieste di chiarimento e modifiche di configurazione. Un secondo accesso in scrittura attivo alla stessa sessione viene rifiutato, invece di consentire modifiche simultanee al registro.
  • La riga aggiuntiva agente/sessione nel piè di pagina viene eliminata. Le sessioni possono comunque essere controllate e diagnosticate in modo mirato. L'interfaccia King esistente, i modelli gestiti e i limiti di autorizzazione vengono conservati.
  • --message fornisce un primo messaggio per l'avvio interattivo. Dopo l'approvazione all'avvio e la selezione della sessione, viene elaborato tramite il normale controllo dei messaggi e la coda. Il suo contenuto non viene interpretato come comando slash o di shell.
  • Il contratto di interfaccia del servizio Guard incluso rimane invariato. Questa versione non dimostra risposte più rapide in produzione, né fatture del provider più basse, né la piena parità funzionale con OpenClaw, né un limite alla quantità di dati letti al primo caricamento del registro di sessione.

/abort interrompe l'operazione in corso senza scartare gli input in attesa. /stop scarta inoltre gli input in attesa. /exit continua a chiudere la console. Si tratta di comandi locali della console, non di ulteriori comandi remoti di Telegram.

Controlli sul pacchetto 9.1.605: 238 file di test con 6.900 test, più 40 controlli di staging, tra cui 25 test nativi del terminale. Il test di un aggiornamento isolato da 9.1.604 tramite il tag candidato pubblicato con il vero programma di installazione è riuscito. Pertanto non sono dimostrati né tempi di riscaldamento più brevi in una sessione attiva, né la piena parità funzionale con OpenClaw.

BLUN King

BLUN King 9.1.604

Data di pubblicazione:

Controlla la dimensione delle richieste e le fonti di contesto, carica gli strumenti secondo necessità e gestisci i messaggi in arrivo all'interno della propria sessione.

  • /context doctor e /tokens distinguono il numero di byte della richiesta serializzata dalle stime dei token e mostrano le quote rilevate di regole, memoria, skill e definizioni degli strumenti.
  • I cataloghi di strumenti di medie dimensioni vengono caricati all'occorrenza tramite la ricerca esistente; gli strumenti restano reperibili ed eseguibili.
  • /queue gestisce i messaggi all'interno della propria sessione. I messaggi ordinari in coda non interrompono più automaticamente il lavoro dopo 30 secondi.
  • Nella selezione della sessione sono possibili identificatori esatti o titoli, oltre a prefissi univoci di identificatore; il piè di pagina mostra l'agente assegnato e la sessione.
  • Ogni tentativo HTTP riceve un nuovo identificatore di richiesta, a meno che il chiamante non ne fornisca uno. La diagnostica non modifica la fatturazione.
  • Le versioni incluse di AgentSpine e Translate Native rimangono invariate. Costi inferiori e risposte più rapide in produzione non sono dimostrati.
  • /question: riapre le richieste di chiarimento in sospeso. Comprimere una richiesta di chiarimento non equivale a risponderle né a scartarla.

I byte della richiesta, le stime dei token, il consumo cumulato della sessione e i token fatturati sono grandezze diverse. L'indicatore del consumo tiene conto anche del controllo della risposta. /usage cost con costi giornalieri o mensili non fa parte di questa versione. Costi inferiori o risposte più rapide in produzione non sono dimostrati.

BLUN King

BLUN King 9.1.603

Data di pubblicazione:

Scegli la tua cartella di lavoro in una finestra di dialogo di Windows. Se la console viene avviata da System32, ora ti propone la tua cartella utente.

  • Se scegli un'altra cartella di lavoro in Windows, si apre una finestra di dialogo per la cartella. Puoi ancora inserire il percorso a mano. Se annulli la finestra di dialogo, torni alla selezione della cartella senza adottarne una.
  • Se non è disponibile una finestra di dialogo per la cartella, la console chiede il percorso. Sugli altri sistemi operativi resta l'inserimento manuale del percorso.
  • Se all'avvio viene adottata o salvata una cartella all'interno della directory di Windows, la selezione della cartella propone la tua cartella utente. I percorsi inseriti a mano continuano a essere controllati come prima.

Le versioni di AgentSpine e Language Guard rimangono invariate rispetto a 9.1.602. Un guadagno di velocità per le sessioni attive non è dimostrato da questo aggiornamento.

In Windows è ancora necessario Git Bash. Se la console segnala che Git Bash manca, installa Git for Windows. Riapri quindi il prompt dei comandi prima di riavviare king.

BLUN King · Pubblicata

BLUN King 9.1.602

Data di pubblicazione:

Una cartella privata dedicata per gli output più vecchi degli strumenti, quando le autorizzazioni Windows ereditate impediscono di spostarli fuori dal contesto.

  • Gli output più vecchi e idonei degli strumenti vengono salvati in una cartella privata dedicata quando le autorizzazioni Windows ereditate impediscono di spostarli fuori dal contesto. I file esistenti, le autorizzazioni e la cronologia completa della sessione rimangono invariati.
  • I controlli di integrità, i diritti di lettura e il ricorso al contesto completo vengono conservati nel caso in cui un output archiviato non possa essere ripristinato. AgentSpine 0.73.0 e Language Guard 6.20.0 sono invariati rispetto alla 9.1.601.

Tempi di risposta più brevi in produzione o un consumo di token fatturato inferiore non sono ancora dimostrati.

BLUN King · Pubblicata

BLUN King 9.1.601

Data di pubblicazione:

Gli input restano in coda, gli output più vecchi degli strumenti ricevono riferimenti verificati e i controlli della risposta soggetti a throttling vengono ripetuti un numero limitato di volte.

  • Se il lavoro in background ottiene il turno per primo, gli input del terminale restano in coda nel loro ordine originale. Ogni input viene mostrato una sola volta.
  • Gli output più vecchi e idonei degli strumenti vengono sostituiti nelle richieste al modello da riferimenti verificati a file privati. La cronologia completa e i risultati del turno di conversazione corrente vengono conservati. Se il ricaricamento non è possibile, non è consentito o il contenuto è stato modificato, viene inviato l'output completo.
  • Un controllo nativo della risposta soggetto a throttling viene ripetuto una volta con la stessa bozza di risposta. Vale il periodo di attesa salvato del provider. Le chiamate agli strumenti già completate non vengono ripetute e i testi non controllati non vengono approvati.
  • Fino a 2.048 token di output restano liberi come buffer per le discrepanze nella stima dell'input. La finestra di contesto non viene ridotta; i limiti di output inferiori impostati esplicitamente rimangono invariati.

Queste modifiche non dimostrano né un consumo di token fatturato inferiore né tempi di risposta più brevi in produzione. Non risolvono nemmeno ogni errore HTTP 502 lato server.

BLUN King · Pubblicata

BLUN King 9.1.600

Data di pubblicazione:

Controllo della risposta con limiti di tempo fissi e versioni dei componenti stabilite.

BLUN King 9.1.600 è pubblicata. npm e il manifest di aggiornamento pubblico coincidono. La pubblicazione non dimostra né un'installazione sul tuo computer né un collaudo in produzione.

Controllo della risposta limitato

  • I controlli generali mantengono il limite precedente di 30 secondi. Il controllo linguistico nativo riceve fino a 90 secondi per il primo testo sostanziale, a partire dal segnale di avvio del componente host attendibile, una volta per tentativo di controllo esterno.
  • Un testo sostanziale entro la lunghezza di output consentita, così come le transizioni ordinate verso l'approvazione e la verifica della ricevuta, reimpostano ciascuno il periodo di attesa a 30 secondi.
  • Per ogni tentativo di controllo esterno vale comunque un limite complessivo di 120 secondi. L'avanzamento non può estendere questo limite. Restano ammessi al massimo due tentativi di controllo esterno.
  • Prima di accettare un'approvazione, viene ricontrollato il tempo effettivamente trascorso. Anche con chiamate di timer ritardate, un tentativo di controllo scaduto resta bloccato; il progresso tardivo non può rinnovare una scadenza superata.

I segnali di interruzione continuano a essere rispettati. Il vincolo al testo esatto della risposta, la validità temporale della ricevuta di approvazione e l'autorizzazione continuano a essere controllati.

Componenti inclusi

La versione 9.1.600 include AgentSpine 0.73.0 e Translate Native 6.155.0. Il protocollo Guard rimane invariato alla 6.20.0.

Limitazioni note

I nuovi limiti di tempo non dimostrano una correzione generale degli errori HTTP 502 in produzione. Le osservazioni aperte della 9.1.599 restano aperte senza una verifica separata in produzione.

Contesto e guida

Un prompt che deve essere conservato integralmente non viene più troncato silenziosamente solo per entrare in una finestra di modello rigida più piccola. Con una nuova suddivisione esplicita dei messaggi utente da conservare, con il budget predefinito di 20.000 token, l'adattamento può essere completato nella stessa compattazione. Per i prefissi successivi o ripristinati non devono essere scartati ulteriori requisiti. La richiesta deve comunque entrare nella finestra di modello rigida.

Le invocazioni di sola guida con --help o -h non creano più uno stato di diagnostica in fase di esecuzione. Se prompt e argomenti di guida vengono combinati, resta il comportamento di esecuzione precedente.

BLUN King · 18 settembre 2026

BLUN King 9.1.599

Data di pubblicazione:

Approvazioni individuali tracciabili per la memoria personale e ulteriori correzioni in caso di superamento del contesto.

Le richieste di approvazione per la memoria personale mostrano titoli di azione comprensibili nella lingua selezionata e anteprime complete delle modifiche effettive alle impostazioni o del testo da salvare. I caratteri di controllo vengono mascherati visibilmente; il contenuto originale rimane invariato.

Le modifiche valide alla memoria devono essere approvate singolarmente; gli input non validi possono solo essere rifiutati. Un'approvazione di sessione non autorizza automaticamente le richieste in attesa che richiedono un'approvazione individuale.

Il controllo del pacchetto comprende 37 aree funzionali con 199 controlli obbligatori, 158 esecuzioni di controllo e 4.905 test distinti superati. Inoltre, gli aggiornamenti dalla 9.1.597 e dalla versione intermedia locale 9.1.598 alla 9.1.599 sono stati controllati in installazioni isolate con l'updater invariato e il percorso di installazione invariato. Entrambi i test hanno riconosciuto la versione tramite le fonti di aggiornamento pubbliche e hanno controllato tutti i 918 file dell'archivio di rilascio.

Le note in README.md e CHANGELOG.md del pacchetto invariato 9.1.599 descrivono la versione candidata al momento dell'impacchettamento. Non sono state modificate retroattivamente dopo l'installazione locale. Questa pagina pubblica continua a documentare separatamente la versione pubblicata e le limitazioni osservate successivamente.

Limitazioni note nella 9.1.599

In produzione sono state osservate ancora risposte HTTP 502 ripetute, a volte seguite da richieste riuscite. Le correzioni del contesto non sono una soluzione generale per gli errori del provider o di rete.

Il controllo linguistico può interrompere una risposta con missing-language-character-profile o suspected-ascii-substitution. Questo riscontro resta aperto; la 9.1.599 non contiene alcuna correzione dimostrata a riguardo.

Una risposta all'immagine inviata è stata confermata dall'utente. Mancano ancora un controllo indipendente dell'interpretazione dell'immagine e il collaudo visivo di input e righe di stato. I controlli del pacchetto superati non equivalgono a un via libera generale per questi flussi.

Ripreso dalla versione intermedia locale 9.1.598

Senza data

La 9.1.598 è stata controllata e installata localmente, ma non è stata pubblicata come aggiornamento npm separato. Le modifiche seguenti sono incluse nella 9.1.599:

  • In caso di rifiuto del contesto, i limiti inferiori per il numero di token di input vengono distinti dalle indicazioni esatte. Per un limite inferiore segnalato, il limite di output viene ridotto una volta, senza scartare messaggi o strumenti. I segnali di interruzione e il limite di ulteriori tentativi restano efficaci. Viene così corretto in modo mirato l'errore nel calcolo del limite di output riprodotto nella 9.1.597.
  • Sono di nuovo incluse le 150 parole di attività originali, mostrate a rotazione. Per la loro visualizzazione non vengono effettuate ulteriori richieste al modello.
  • Nell'hook di input attendibile di AgentSpine, al posto dei dati multimediali completi viene passato un riferimento multimediale compatto con tipo, checksum SHA-256 e indicazione della dimensione. Gli allegati completi per il modello e i controlli di protezione esistenti vengono conservati. Questo da solo non dimostra ancora un'interpretazione riuscita delle immagini in produzione.

Nuovo nella 9.1.597

Data di pubblicazione:

Ripristino limitato in caso di superamenti del contesto espressamente segnalati, anche se racchiusi in una risposta di errore del gateway.

Se una richiesta viene rifiutata prima dell'inizio dell'output a causa di un superamento del contesto comprovato, King può effettuare un nuovo tentativo limitato con un limite di output inferiore. Vengono rilevati anche gli errori corrispondenti racchiusi in una risposta 502. Messaggi, strumenti, limiti di output inferiori scelti esplicitamente e segnali di interruzione vengono conservati. Uno stream già avviato non viene riprodotto di nuovo.

Questo non risolve tutti gli errori del provider o di rete. Le interruzioni generali della connessione e le interruzioni del servizio devono continuare a essere controllate in base ai propri dati di errore.

Limitazione nota nella 9.1.597: se il server segnala solo un limite inferiore per il numero di token di input, il nuovo tentativo può fallire di nuovo e provocare compattazioni inutili. Questo caso è stato riprodotto il 17 settembre 2026 dopo la pubblicazione. La correzione aggiuntiva dalla versione intermedia locale 9.1.598 è inclusa nella 9.1.599.

Sono state controllate 36 aree funzionali con 183 controlli obbligatori e 4.407 test distinti superati, oltre al vero aggiornamento dalla 9.1.596 alla 9.1.597. Questo controllo del pacchetto non sostituisce un test applicativo di una sessione cliente già aperta.

Nuovo nella 9.1.596

Data di pubblicazione:

Le interruzioni automatiche a favore di messaggi Telegram in attesa vengono distinte dai veri annullamenti manuali. Un'interruzione di questo tipo dovuta alla coda non viene più segnalata erroneamente come pressione del tasto Escape. Il periodo di attesa, le regole di protezione per gli strumenti in esecuzione e il comportamento in caso di vero annullamento manuale vengono conservati.

Nuovo nella 9.1.595

Data di pubblicazione:

Gli schemi di strumenti opzionali vengono caricati tramite ToolSearch e conservati in modo limitato. I grandi cataloghi di skill vengono forniti in modo compatto e suddivisi in pagine. La ricerca, le successive estensioni MCP e i normali controlli di autorizzazione vengono conservati.

Per i saluti brevi, King può utilizzare un estratto limitato e recente del dialogo, senza eliminare i messaggi salvati o troncare le istruzioni di sistema. Per un successivo incarico di lavoro, King tiene nuovamente conto della cronologia di lavoro conservata. Il calcolo del contesto rimane integro anche dopo la ripresa di una sessione. Non è garantito un consumo fisso di token per ogni saluto.

Nuovo nella 9.1.594

Data di pubblicazione:

  • Le risposte private di Telegram restano possibili mentre i messaggi di gruppo attendono. L'assegnazione dei comandi slash viene conservata.
  • I lunghi periodi di attesa da Retry-After vengono rispettati; riprendendo una sessione, la pausa rimanente viene ripristinata.
  • Dopo lo scarto della descrizione di accompagnamento, un passo di strumento già completato viene comunque elaborato. La descrizione scartata non viene pubblicata e il controllo della risposta finale non viene indebolito.
  • Le funzioni di ripristino limitate per la scrittura in più parti sono di nuovo disponibili. Questo vale anche per i limiti di tempo della shell, il controllo delle attività e il ripristino della sessione.
  • Input, righe di quota, indicatore di attività, attività espandibili e output degli strumenti con attribuzione delle fonti restano visibili durante lo streaming e la navigazione nella cronologia.
  • Prima dell'impacchettamento sono richieste prove complete di regressione della console; i metadati di aggiornamento pubblici vengono controllati per verificarne la coerenza.

Versioni intermedie dalla 9.1.590 alla 9.1.593

Queste versioni sono presenti nella cronologia di rilascio locale, ma il 17 settembre 2026 non sono incluse nell'elenco pubblico delle versioni npm. Non vengono qui raccomandate come aggiornamenti disponibili pubblicamente. I lavori su avvio, ripresa, autorizzazioni, indicatore di attività e input visibile sono stati presi in considerazione nelle prove della 9.1.594.

Nuovo nella 9.1.589

Data di pubblicazione:

  • Vengono inclusi i sorgenti verificati di AgentSpine e Translate Native, oltre ai manifest di aggiornamento verificati.
  • Durante il caricamento del contesto dell'agente, il profilo King attivo viene conservato.
  • Gli strumenti necessari per il controllo della risposta restano disponibili. Il consumo per la generazione della risposta viene registrato anche se il controllo scarta la risposta.
  • Nell'integrazione di canale gestita, i messaggi di gruppo vengono assegnati solo in caso di menzione esplicita.
  • La console mostra la compattazione in corso e le soglie in vigore.
  • Il budget di lavoro per la compattazione anticipata e la riserva di sicurezza al limite della richiesta vengono conservati attraverso gli aggiornamenti.
  • Il dialogo di aggiornamento all'avvio, l'avanzamento e gli avvisi sugli aggiornamenti programmati usano coerentemente la lingua selezionata.
  • Gli identificatori di integrazione tecnica e le licenze vengono conservati; i messaggi di errore visibili in fase di esecuzione sono formulati in modo neutro.
  • L'installazione non riavvia le sessioni esistenti. Una sessione in esecuzione carica il nuovo codice al prossimo avvio.

9.1.588: Ritirata

Data di pubblicazione:

Questa versione è stata pubblicata l'11 settembre 2026 e successivamente contrassegnata come ritirata su npm. Il registro cita un controllo di compatibilità fallito del manifest di aggiornamento. Usa la versione stabile attuale, non questo pacchetto ritirato.

Nuovo nella 9.1.587

Data di pubblicazione:

Cataloghi di strumenti più stabili, compattazione automatica anticipata e un nuovo tentativo mirato dopo interruzioni dovute a fasi di solo pensiero troppo lunghe.

Con istruzioni in buffer durante un turno in corso, il catalogo di strumenti attivo viene conservato anche per il passo di lavoro successivo. Gli strumenti necessari restano disponibili. Se il budget di schema esistente viene superato, le definizioni di strumenti opzionali conservate vengono riselezionate.

La compattazione automatica del contesto interviene di nuovo prima. Dopo una compattazione riuscita che riduce la cronologia, King può eseguirla di nuovo nello stesso turno. I limiti di modello inferiori e il limite dei tentativi falliti restano efficaci.

Dopo un'interruzione dovuta a una fase di solo pensiero troppo lunga, King utilizza il nuovo tentativo unico esistente con il pensiero disattivato, affinché il modello possa rispondere o chiamare uno strumento. I passi regolari successivi mantengono l'impostazione di pensiero scelta; interruzione, controlli di approvazione e limiti di tempo restano efficaci.

Con BLUN_STABLE_STEER_TOOLS=0 o BLUN_EARLY_COMPACTION=0 prima dell'avvio di King è possibile ripristinare il comportamento precedente per la relativa funzione. L'aggiornamento non riscrive sessioni o file di configurazione esistenti.

Nuovo nella 9.1.586

Data di pubblicazione:

La ricezione di Telegram su Windows riparte quando il vecchio ID di processo del bridge ora appartiene a un altro processo. In caso di assegnazione incerta del processo, King non interviene; l'altro processo non viene terminato.

Compattazione del contesto, impostazioni del modello, cronologia della conversazione e il precedente comportamento di consegna di Telegram rimangono invariati.

Nuovo nella 9.1.585

Data di pubblicazione:

BLUN King · 8 settembre 2026

La versione 9.1.585 controlla la struttura e i singoli risultati delle risposte WebSearch gestite anche quando mancano le indicazioni opzionali sullo stato della ricerca.

Una risposta senza un elenco di risultati valido non viene più riportata come ricerca riuscita senza risultati. Ogni risultato deve avere un titolo che non sia vuoto né composto solo da spazi, un estratto di testo come stringa e un indirizzo HTTP o HTTPS assoluto senza credenziali incorporate. I risultati non validi portano al rifiuto dell'intera risposta, prima che vengano restituiti risultati o avvisi su risultati di ricerca incompleti.

Le risposte valide nel formato precedente senza indicazioni di stato continuano a essere supportate, così come gli elenchi di risultati vuoti e le stringhe vuote come estratti di testo. Per le risposte valide, l'ordine, le stringhe URL esatte, le indicazioni facoltative di data e sito, le attribuzioni delle fonti nell'output e l'elaborazione dei risultati incompleti rimangono invariati.

Viene modificata solo l'integrazione di ricerca gestita. Il comportamento di interruzione, l'autenticazione delle richieste, FetchURL e Telegram rimangono invariati. Il controllo del formato non dimostra che una fonte sia corretta o attuale. Questa versione non introduce né un limite di dimensione per le risposte né un nuovo limite di tempo.

Nuovo nella 9.1.584

Data di pubblicazione:

La versione 9.1.584 trasmette il segnale di interruzione del chiamante attraverso WebSearch fino alla richiesta di ricerca HTTP gestita, anche durante la lettura del contenuto della risposta.

Le ricerche già interrotte non attivano alcuna elaborazione presso il provider. Se l'interruzione avviene durante la risoluzione delle credenziali, non viene più inviata alcuna richiesta di ricerca. I risultati che arrivano dopo l'interruzione non vengono restituiti come ricerca riuscita.

I controlli di interruzione comprendono anche le risposte JSON riuscite, il contenuto delle risposte di errore e gli avvisi sui risultati di ricerca incompleti. L'elaborazione di risultati completi, incompleti e vuoti, le attribuzioni delle fonti e la procedura di fallback regolare durante l'autenticazione rimangono invariate.

Questa versione non introduce un nuovo limite di tempo e non modifica l'assegnazione di Telegram. I processi condivisi per il rinnovo delle credenziali OAuth e le implementazioni di trasporto che ignorano i segnali di interruzione non vengono interrotti forzatamente. L'interruzione di una richiesta client non dimostra che il lavoro sul server remoto o la relativa fatturazione siano terminati.

Nuovo nella 9.1.583

Data di pubblicazione:

Un'interruzione durante il recupero di una pagina viene ora trasmessa fino alla richiesta HTTP.

FetchURL trasmette il segnale di interruzione del chiamante attraverso lo strumento ed entrambi i servizi di recupero. Una richiesta interrotta prima dell'avvio non viene inviata. Se l'interruzione avviene durante la risoluzione delle credenziali, la richiesta HTTP gestita non viene più avviata in seguito.

Dopo l'interruzione di un recupero gestito non viene più avviato alcun recupero sostitutivo locale. Un risultato tardivo del servizio di recupero viene trattenuto e non utilizzato come riferimento di fonte. In caso di normali errori HTTP e di rete, il precedente recupero sostitutivo locale resta possibile.

Non viene introdotto alcun nuovo limite di tempo. Un rinnovo condiviso delle credenziali e l'elaborazione HTML sincrona non vengono interrotti forzatamente. Il limite di dimensione della 9.1.582 resta in vigore; il routing di Telegram e le richieste al modello rimangono invariati.

Nuovo nella 9.1.582

Data di pubblicazione:

Il recupero di pagine locale controlla la dimensione della risposta già durante la lettura e si interrompe al superamento del limite.

Il recupero locale conta i byte di risposta in arrivo prima della decodifica di ogni blocco di dati e interrompe il flusso di dati non appena il limite di dimensione viene superato. Se l'indicazione Content-Length manca o è errata, la risposta completa non viene più letta per essere poi rifiutata.

Il limite predefinito resta a 10 MiB e si applica al flusso di risposta dopo la decompressione HTTP. I caratteri UTF-8 distribuiti su più blocchi di dati vengono conservati. I buffer di trasporto e il blocco di dati con cui viene superato il limite possono trovarsi già in memoria; non ne consegue un limite superiore esatto per l'intera memoria di processo.

Viene modificato il percorso di recupero locale, anche quando serve come soluzione di ripiego. Le correzioni di ricerca della 9.1.581 restano incluse. Il routing di Telegram e il periodo di attesa per il modello rimangono invariati.

Nuovo nella 9.1.581

Data di pubblicazione:

Nel recupero di pagine locale, gli estratti HTML vuoti non vengono più restituiti come fonti riuscite.

Se dopo la pulizia e la conversione non rimane alcun contenuto di pagina, il solo titolo del documento non basta più per un recupero riuscito. Viene invece restituito l'errore di estrazione già esistente.

I contenuti brevi reali e i titoli visibili vengono conservati. Le risposte in formato testo semplice o Markdown rimangono invariate. La correzione riguarda l'estrazione HTML locale, non il servizio di recupero gestito.

Le correzioni di ricerca della 9.1.580 e le precedenti correzioni di Telegram restano incluse invariate. Questo aggiornamento non modifica né il periodo di attesa per il modello né l'assegnazione dei messaggi in arrivo ai loro destinatari.

Nuovo nella 9.1.580

Data di pubblicazione:

L'archivio di ricerca rifiuta le indicazioni di data storiche non valide per le fonti.

Un nuovo rapporto non viene salvato se un'indicazione di data relativa a una fonte contiene un giorno di calendario non valido o una componente temporale non interpretabile. Le indicazioni di data mancanti restano consentite.

Al recupero dei rapporti di ricerca salvati, i rapporti più vecchi con indicazioni di data non valide per le fonti vengono saltati e segnalati con un avviso diagnostico. I file non vengono né riscritti né eliminati. I rapporti validi separati restano ricercabili; le indicazioni di data valide mantengono il loro offset di fuso orario e la loro precisione.

L'ordinamento dei rapporti di ricerca della 9.1.579 e le precedenti correzioni di Telegram restano inclusi invariati. Questo aggiornamento non modifica né il periodo di attesa per il modello né l'assegnazione dei messaggi in arrivo ai loro destinatari.

Nuovo nella 9.1.579

Data di pubblicazione:

I rapporti di ricerca salvati vengono ordinati in base al momento effettivo del recupero a parità di rilevanza.

Le indicazioni di tempo con e senza millisecondi vengono confrontate come istanti UTC, non come testo. La rilevanza ha comunque la precedenza; a istanti identici, l'ordine precedente viene conservato.

Se lo stesso passo di testo è stato rilevato più volte, il risultato mantiene l'attribuzione di origine del recupero più recente. I rapporti già salvati restano invariati e quindi non valgono come fonti nuovamente verificate.

La correzione per le risposte di Telegram della 9.1.578 resta inclusa invariata. Lo stesso vale per il limite dei nuovi tentativi quando il modello si limita a pensare senza fornire una risposta o una chiamata a uno strumento. Questo aggiornamento non modifica né il periodo di attesa per il modello né l'assegnazione semantica dei messaggi in arrivo.

Nuovo nella 9.1.578

Data di pubblicazione:

Nuovi tentativi limitati quando il modello si limita a pensare e raggiunge il limite di tempo, oltre a una correzione mirata per le brevi risposte di gruppo di Telegram in relazione a una domanda.

Se il modello raggiunge il limite di tempo mentre si limita a pensare, King consente un ulteriore tentativo per passo. Un secondo superamento di questo tipo conclude il passo. Lo sforzo di pensiero scelto e il precedente limite di tempo rimangono invariati. Questo limite non accorcia l'attesa del primo output del modello.

Brevi conferme della propria presenza nei gruppi Telegram possono ora essere inviate se reply_to le collega a un input della stessa chat risalente al massimo a 30 minuti prima. Questo input deve rivolgersi esplicitamente all'agente o corrispondere a una domanda supportata in tedesco o inglese sulla sua presenza che inizia con il suo nome configurato. Le conferme di presenza non richieste e le dichiarazioni secondo cui non c'è nulla da segnalare continuano a essere filtrate. L'invio sostitutivo automatico nei gruppi resta disattivato.

I registri delle risposte inviate e soppresse ora contengono reply_to. L'eccezione non si applica in caso di contesto mancante o ambiguo. Questo aggiornamento non aggiunge alcun riconoscimento generale del destinatario e non impedisce le chiamate al modello non necessarie dovute al precedente indirizzamento semantico.

La correzione vale per due versioni esattamente identificate dei mittenti MCP di Telegram gestiti e si applica anche al consolidamento finale della configurazione del plugin. Il mittente più vecchio utilizza una copia di compatibilità con modifiche strettamente delimitate. I bridge in ingresso, le impostazioni di accesso, i profili e i registri dei plugin non vengono riscritti. I mittenti sconosciuti o personalizzati e le sostituzioni impostate esplicitamente vengono conservati. King deve essere riavviato dopo l'aggiornamento affinché la correzione venga caricata.

Nuovo nella 9.1.577

Data di pubblicazione:

Niente più comunicazioni di completamento automatiche nei gruppi Telegram. Le risposte utili vengono inviate lì in modo mirato tramite lo strumento di risposta di Telegram.

Il nucleo CLI e il bridge Telegram autonomo non inoltrano più automaticamente ai gruppi il testo di completamento normale di un agente. Indicazioni come «Niente da segnalare» non raggiungono quindi più il gruppo tramite questo invio sostitutivo automatico.

Le risposte nelle chat private, gli strumenti di risposta usati esplicitamente, i risultati di obiettivo richiesti, i messaggi di comando e stato e l'invio di media vengono conservati. Le istruzioni di prompt per gli input normali, i messaggi di controllo durante un'attività in corso e i messaggi di gruppo del bridge autonomo ora contengono la stessa regola di invio.

Ciò non garantisce che un modello non invii mai una risposta non necessaria tramite una chiamata a uno strumento. La correzione non impedisce nemmeno che i messaggi di gruppo senza relazione con l'agente in questione raggiungano il modello. Le regole di menzione, le impostazioni di accesso e la risoluzione dei plugin gestiti rimangono invariate; non è incluso un aggiornamento di AgentSpine o del Language Guard.

Il nucleo aggiornato deve essere caricato da un nuovo processo. Le sessioni in esecuzione non vengono riavviate automaticamente. I profili esistenti e la cronologia della sessione vengono conservati.

Nuovo nella 9.1.576

Data di pubblicazione:

BLUN King 9.1.576 distingue C++ e C# nelle interrogazioni di ricerca locale e include le correzioni precedentemente pubblicate per gli aggiornamenti, la ripresa delle sessioni e Telegram.

La ricerca nei rapporti di ricerca locali tratta C++ e C# isolati come termini distinti, anche con maiuscole e minuscole diverse e con segni di punteggiatura circostanti. I passaggi di testo salvati, gli hash, i controlli di protezione delle fonti, la normalizzazione Unicode, i limiti di raccolta e i limiti di output rimangono invariati. Non è necessaria una nuova indicizzazione.

Un'esecuzione di prova prestabilita con 20 interrogazioni di ricerca tecniche e test di regressione mirati sui limiti dei token verificano questa correzione. Riguarda la ricerca locale e non è una dichiarazione sulla qualità o sulla capacità di WebSearch in produzione. Tutte le modifiche della 9.1.575 restano incluse.

Nuovo nella 9.1.575

Data di pubblicazione:

Il crawler web incluso rifiuta le risposte con cf-mitigated: challenge prima di leggere i contenuti, seguire i reindirizzamenti o interpretare un file robots mancante come autorizzazione a continuare. Per i nomi degli header non fa distinzione tra maiuscole e minuscole; controlla inoltre i valori normalizzati e gli header presenti più volte. Lo stato della risposta resta conservato nel rapporto di errore.

I file robots mancanti senza questa marcatura e le normali pagine di documentazione continuano a passare dal flusso esistente. Le pagine già completate restano disponibili quando una pagina successiva viene rifiutata; l'errore viene segnalato come risultato incompleto. Questa protezione controlla una marcatura della risposta. Non è né un rilevamento generale di challenge né un bypass CAPTCHA. I provider di ricerca, l'autenticazione, i blocchi di aggiornamento e il nucleo CLI rimangono invariati. Tutte le modifiche della 9.1.574 restano incluse.

Nuovo nella 9.1.574

Data di pubblicazione:

Gli aggiornamenti esplicitamente richiesti distinguono ora tra un aggiornamento bloccato, un controllo di blocco non disponibile, una directory privata non disponibile, una versione installata non valida e un programma di installazione protetto non disponibile. Questi casi non vengono più segnalati genericamente come controllo del pacchetto fallito. La modifica vale per i messaggi in tedesco e in inglese.

L'autorizzazione all'aggiornamento, il comportamento di blocco, i motivi di ritorno, i codici di uscita e il comportamento del programma di installazione rimangono invariati. Le sessioni in esecuzione non vengono terminate automaticamente. I pacchetti fissati a un vecchio canale interno richiedono ancora un'installazione npm esplicita con King terminato; questa versione non revoca tale fissaggio. Tutte le modifiche della 9.1.573 restano incluse.

Nuovo nella 9.1.573

Data di pubblicazione:

Il campo di input resta visibile e focalizzato dopo la selezione dell'obiettivo all'avvio, anche dopo Escape o una ripresa dell'obiettivo fallita. Le bozze non inviate vengono conservate. Al posto del testo completo dell'obiettivo compare una selezione compatta per continuare con o senza obiettivo.

Ctrl+S esce dalla selezione senza confermare l'obiettivo e viene elaborato come scorciatoia regolare per la coda. Vengono considerati anche gli input in attesa durante l'inattività. Escape mantiene la sequenza precedente: prima svuota la coda, al successivo Escape interrompe l'esecuzione attiva. La cronologia della sessione non viene eliminata automaticamente.

Questa versione non ricostruisce le conferme di consegna perse da un processo più vecchio prima dell'aggiornamento. I messaggi realmente in attesa restano assegnati alla loro sessione.

Nuovo nella 9.1.572

Data di pubblicazione:

Nei rapporti di ricerca vengono rifiutati gli URL delle fonti i cui parametri di query o frammenti a forma di parametro contengono nomi di parametri noti per le credenziali. Vengono controllati anche i nomi annidati e i percorsi nel frammento. Il rifiuto vale sia per le fonti fallite sia per quelle utilizzabili.

I rapporti già salvati con tali URL vengono trattenuti al recupero con il risultato esistente partial / report-invalid. Le versioni salvate originariamente non vengono né modificate né eliminate; gli indirizzi delle fonti non vengono accorciati o riscritti silenziosamente. I normali parametri di query e gli ancoraggi negli URL di documentazione restano byte-identici. La protezione riconosce nomi di parametri noti, non segreti arbitrari, e non ripulisce la cronologia.

Nuovo nella 9.1.571

Data di pubblicazione:

Le sezioni della coda di Telegram vengono assegnate alla loro sessione. Una nuova sessione non subentra più automaticamente al lavoro in attesa di una sessione più vecchia. Riprendendo una sessione nota, vengono ripristinate solo le sue sezioni in attesa. Durante la selezione, la creazione o il cambio di sessione, la presa in carico dei messaggi del canale viene sospesa. I messaggi che arrivano dopo il confine scelto, gli input successivi nell'editor locale e le conferme di consegna tardive mantengono la loro assegnazione corretta.

L'assegnazione e le conferme di consegna che arrivano in ordine diverso vengono conservate alla riconnessione e al passaggio di un lease. Uno stato di coda danneggiato o sostituito viene rifiutato, invece di riprodurre silenziosamente vecchi input. Posta in arrivo e cronologia della sessione vengono conservate. Le vecchie sezioni in attesa senza una sessione riconoscibile vengono differite e non assegnate a una nuova sessione; il loro ripristino automatico non è incluso. Questo non risolve ogni timeout o compattazione di contesto bloccata. Un downgrade non è una procedura per migrare la coda.

Il plugin di Telegram e la funzione sostitutiva indipendente della console per l'invio automatico delle risposte sopprimono le conferme di ricezione riconosciute e i testi che annunciano soltanto il proprio silenzio, anche oltre 200 caratteri. Se un messaggio contiene una parte di frase non riconosciuta o sostanziale, viene conservato. I brevi avvisi di gruppo utili possono ancora essere consegnati. Si tratta di un filtro di invio tedesco-inglese prudente con istruzioni supplementari, non di una garanzia che ogni modello comprenda ogni conversazione di gruppo.

Un nuovo processo deve caricare il pacchetto aggiornato; le sessioni in esecuzione non vengono riavviate. I fissaggi esistenti ai canali di aggiornamento interni e i blocchi di installazione di Windows con EBUSY restano problemi separati. Tutte le altre modifiche della 9.1.570 restano incluse. Questa versione non attiva una ricerca web ospitata e non modifica né AgentSpine né fatturazione, autenticazione o configurazione del cliente.

Nuovo nella 9.1.570

Data di pubblicazione:

Ogni nuova consegna di prompt riceve un proprio ID di correlazione hook. Gli hook della stessa consegna mantengono lo stesso ID; gli ID impostati esplicitamente vengono conservati. I valori di ambiente specifici della sessione raggiungono i sottoprocessi hook e le connessioni MCP anche alla riconnessione, senza riscrivere le configurazioni dei plugin salvate. L'assegnazione dei risultati nativi degli strumenti resta conservata tra le esecuzioni, anche per strumenti falliti e chiamate duplicate.

Le interrogazioni di ricerca Unicode canonicamente equivalenti trovano gli stessi risultati, senza equiparare caratteri diversi. Le fonti salvate, le date, le versioni e i confini di progetto vengono conservati. king --help e king --version non modificano più le impostazioni di registro di Windows per le immagini di arresto anomalo.

La ricerca web supporta risposte parziali quando questa modalità di risposta è stata concordata e mostra in tal caso un avviso sulle fonti non disponibili. Le risposte parziali vuote o incompatibili restano errori espliciti. Questa modifica del client non attiva un servizio di ricerca ospitato e non ne garantisce il funzionamento.

Il trasporto BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE è disattivato per impostazione predefinita. Se attivato esplicitamente, trasmette il percorso effettivo del registro di sessione salvato e il relativo log al plugin AgentSpine selezionato. Ogni sessione riceve un'autorizzazione di accesso propria, rinnovata dopo una ripresa. Si tratta di supporto al trasporto, non di una prova di recupero della memoria o di autorizzazione da parte del plugin ricevente.

Tutte le modifiche pubbliche della 9.1.569 restano incluse. L'implementazione AgentSpine inclusa rimane invariata; non viene introdotta alcuna dipendenza da Mnemo. Profili utente, autorizzazioni, conversazioni e impostazioni dei plugin non vengono né migrati né reimpostati.

Nuovo nella 9.1.569

Data di pubblicazione:

Questa versione cumulativa pubblica include la consegna nei gruppi Telegram in base alle menzioni, le correzioni per l'avvio e le autorizzazioni, nonché le raccolte di ricerca e gli strumenti crawler. I pacchetti pubblicati rimangono invariati. Le modifiche successive compaiono sotto un nuovo numero di versione.

Nuovo nella 9.1.566

Data di pubblicazione:

BLUN King 9.1.566 rende più robusti gli aggiornamenti dei plugin e il caricamento dei moduli nativi di runtime.

Il runtime AgentSpine incluso viene aggiornato alla versione 0.59.1. Il suo autoavvio salta la radice di un profilo utente come destinazione di scansione e tutti gli hook del ciclo di vita restano non bloccanti quando un percorso protetto non può essere letto.

I moduli nativi .node vengono risolti tramite una cache adressata al contenuto al di fuori del pacchetto npm. Non appena questa versione è attiva, una console in esecuzione non tiene più aperta la copia del pacchetto di questi moduli. Aggiornamenti successivi possono quindi sostituire la directory del pacchetto senza entrare in conflitto con questi file nativi.

Il pacchetto pubblico conserva i cataloghi completi dell'interfaccia in spagnolo, francese, svedese e ceco della versione 9.1.565. I percorsi di runtime interni di Mnemo, gli endpoint privati, i provider di modelli interni e gli script di build non sono inclusi.

Stato del pacchetto verificato

Il pacchetto cliente ha superato la scansione delle fughe di dati, il test completo del runtime con 13 test, l'inizializzazione MCP di AgentSpine, un'installazione pulita e l'aggiornamento dalla 9.1.565. Tutti i file di testo usano terminazioni di riga LF. SHA-256 del pacchetto npm: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Nuovo nella 9.1.565

Data di pubblicazione:

BLUN King 9.1.565 stabilizza i lunghi cicli di lavoro ed estende il runtime AgentSpine incluso.

Il freno di ripetizione azzera la sua sequenza di risultati equivalenti non appena tra di essi avanza un lavoro reale. I normali controlli della posta in arrivo e delle liste di attività non provocano quindi più una falsa risposta forzata.

L'indicatore di attività consiste esattamente in una riga. Mostra la parola di stato inglese corrispondente all'attività corrente, i token del pensiero nascosto, i token visibili, il consumo totale, l'effort, il tentativo, il budget e il passo.

Gli errori di scansione di AgentSpine restano non bloccanti per gli strumenti di mutazione, gli input utente e gli hook di stop: il flusso successivo può continuare e l'errore viene registrato nel registro di controllo. Prima di un arresto fatale dovuto a un'eccezione o a un rifiuto non gestito, la console scrive il registro di runtime in modo sincrono.

Il runtime AgentSpine raggruppato viene aggiornato alla versione 0.54.0 dal commit fb6d456b68605fd83721090e503f000a26e8a0fb. Lo stato contiene il vero test ACL fail-open, i piani target permanenti legati alle dipendenze e la risoluzione vincolata delle lacune di conoscenza.

Gli hook del ciclo di vita SessionStart, UserPromptSubmit, PostToolUse e Stop vengono inviati a Mnemo con l'identità MNEMO_AGENT esatta. Gli errori di rete restano a prova di guasto.

I testi dell'interfaccia precedentemente mancanti sono ora completi in spagnolo, francese, svedese e ceco.

Stato del pacchetto verificato

Il gate completo del pacchetto, la scansione delle perdite, il controllo del catalogo linguistico, il test dell'hook ACL, l'installazione pulita, l'aggiornamento dalla 9.1.564 e l'inizializzazione MCP di AgentSpine sono verdi. SHA-256 del pacchetto npm: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Nuovo nella 9.1.564

Data di pubblicazione:

BLUN King 9.1.564 previene gli arresti anomali causati da cartelle protette e testi dell'interfaccia mancanti.

AgentSpine salta nella scansione preliminare dei file singoli file e cartelle che il sistema operativo blocca con EPERM o EACCES. Un errore di scansione imprevisto non blocca più la successiva chiamata di strumento; viene rilasciato e registrato nel registro di audit.

Se in una lingua dell'interfaccia pubblicata manca una chiave di testo, la console usa il testo inglese e registra la lacuna una sola volta, invece di arrestarsi nel percorso di rendering. In questo modo la riga di stato del pensiero resta utilizzabile in particolare in ceco, spagnolo, francese e svedese.

Le traduzioni effettive delle chiavi ancora mancanti seguiranno in una versione verificata separatamente. Fino ad allora, il ripiego in inglese è deliberatamente visibile e a prova di errore.

Stato del pacchetto verificato

Il pacchetto è stato verificato contro l'esatto crash ceco thinking.step dalla 9.1.563. La nuova versione restituisce «step 6» invece di un'eccezione, avvisa una sola volta per lingua e chiave, supera le cartelle vicine inaccessibili, inizializza AgentSpine 0.49.0, supera un'installazione pulita e l'aggiornamento dalla 9.1.563 e non contiene import di plugin non risolti. SHA-256 del pacchetto npm: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Nuovo nella 9.1.563

Data di pubblicazione:

BLUN King 9.1.563 aggiorna il runtime AgentSpine incluso alla versione 0.49.0.

La nuova versione richiede, prima di un tentativo di apprendimento, almeno un riscontro recente e indipendente da una conferma esplicita dell'utente o da un test oggettivo. I soli riscontri di conversazione o di documenti non bastano più, anche se le altre soglie sono soddisfatte.

I contratti di apprendimento vincolano questa regola dei riscontri in modo persistente; le successive modifiche di configurazione non possono indebolire un controllo in corso. I blocchi di file legati alla proprietà proteggono le modifiche di apprendimento parallele dalla sovrascrittura e fanno fallire in fail-closed i blocchi manipolati o di terzi.

L'aggiornamento sostituisce l'albero dei plugin gestiti al prossimo avvio in modo indirizzato al contenuto. Le installazioni esistenti della 9.1.562 vengono aggiornate ad AgentSpine 0.49.0, un albero invariato viene riutilizzato e il server MCP di AgentSpine conferma la versione 0.49.0.

Stato del pacchetto verificato

Il confine del pacchetto differisce dalla 9.1.562 solo per le indicazioni di versione e il runtime AgentSpine 0.49.0 esattamente pinnato. Il controllo completo upstream, 49 test di apprendimento mirati, il confronto dei pacchetti, la scansione delle perdite, l'installazione pulita, il vero percorso di aggiornamento dalla 9.1.562 e un'inizializzazione MCP sono verdi. SHA-256 del pacchetto npm: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Nuovo nella 9.1.562

Data di pubblicazione:

BLUN King 9.1.562 ripristina il file del runtime AgentSpine nel pacchetto pubblico.

Il file di runtime richiesto dal server MCP AgentSpine incluso viene nuovamente fornito. Una nuova installazione materializza completamente il plugin; il server MCP si avvia e conferma il proprio nome e la versione del protocollo.

Stato del pacchetto verificato

Il confine del pacchetto differisce dalla 9.1.561 solo per i metadati di versione e il file di runtime ripristinato. La scansione delle perdite, l'installazione pulita, la materializzazione dei plugin e una vera inizializzazione MCP sono verdi. SHA-256 del pacchetto npm: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Nuovo nella 9.1.561

Data di pubblicazione:

BLUN King 9.1.561 trasferisce nel pacchetto pubblico i miglioramenti verificati del sistema di lavoro.

L'incarico attuale e i risultati recenti degli strumenti restano disponibili. I risultati di lettura non vengono accorciati. I risultati grandi vengono salvati con un riferimento per il recupero, invece di essere svuotati. I risultati identici ripetuti rimandano al risultato completo più recente.

Le compattazioni vengono registrate come transazione con marcatura di inizio, riepilogo e fine. Le chiamate agli strumenti e i loro risultati restano insieme, mentre i checkpoint persistenti garantiscono il percorso di ripristino attraverso i nuovi tentativi.

I budget di output provengono ora dal profilo del modello attivo. Il modello BLUN gestito riceve per impostazione predefinita 128.000 token di output, se nessun valore è impostato esplicitamente. I vecchi limiti fissi di 32.768 token e i limiti bassi per low e off non tagliano più il lavoro complesso; la capacità del contesto resta il limite di sicurezza.

L'updater chiede prima di preparare o avviare l'installer. Nel pacchetto pubblico il modello BLUN gestito resta impostato in modo fisso; /model serve solo più come alias di compatibilità per /effort.

Il confine del pacchetto è stato controllato su tutti i nomi di file e i contenuti leggibili. I percorsi interni del provider, la scelta del modello, gli script di build e di regressione, gli identificatori privati e gli indirizzi di server privati non sono inclusi.

Stato del pacchetto verificato

Il pacchetto completo, la scansione delle perdite, l'installazione pulita, l'output di versione e di aiuto, le impostazioni predefinite di un nuovo profilo e la decisione di aggiornamento dalla 9.1.550 alla 9.1.561 sono verdi. SHA-256 del pacchetto npm: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Nuovo nella 9.1.527

Data di pubblicazione:

BLUN King 9.1.527 adotta il flusso /copy da DeepAgents.

Il comando copia la risposta più recente dell'assistente, completata e non vuota, tramite il percorso degli appunti multipiattaforma esistente.

Se /copy viene inserito durante una risposta in corso, il comando usa la coda dei comandi esistente e viene eseguito dopo il completamento della risposta.

Messaggi di stato chiari coprono il successo, una cronologia vuota e gli errori degli appunti in tutte e sei le lingue dell'interfaccia.

Un test di regressione rosso-verde protegge la registrazione dei comandi, l'esecuzione, la selezione della risposta, il contenuto byte-identico degli appunti e i testi dell'interfaccia approvati.

Stato del pacchetto verificato

Il prepack completo e il controllo dell'artefatto estratto sono verdi. SHA-256 del pacchetto npm: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Nuovo nella 9.1.526

Data di pubblicazione:

BLUN King 9.1.526 materializza la versione di AgentSpine raggruppata con il pacchetto attuale, prima che /reload ricostruisca il catalogo dei plugin e la configurazione MCP.

Le voci di plugin non interessate restano invariate. Un albero AgentSpine gestito e invariato viene riutilizzato senza riscrivere installed.json.

Un test di regressione rosso-verde contro la 9.1.525 protegge l'ordine di bootstrap, l'adozione del plugin gestito e il comportamento idempotente al ricaricamento.

Stato del pacchetto verificato

Il prepack completo, il controllo dell'artefatto impacchettato e il test isolato dell'updater dalla 9.1.525 alla 9.1.526 sono verdi. SHA-256 del pacchetto npm: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Nuovo nella 9.1.525

Data di pubblicazione:

BLUN King 9.1.525 avvia ogni comando shell locale su Windows e POSIX in un proprio gruppo di processi. I programmi non possono più agganciarsi alla console di controllo della TUI BLUN e intercettare Escape, Ctrl+S o altri input dell'editor.

Standard input, standard output e standard error restano in pipe private. I comandi interattivi ricevono la fine del file e falliscono o vanno in timeout, senza competere con l'editor per l'input.

L'isolamento locale della shell di DeepAgents è stato adottato per Windows. Un test di regressione eseguibile copre entrambi i percorsi di piattaforma e un'esecuzione di prova reale con un processo intercettato.

Nuovo nella 9.1.524

Senza data

BLUN King 9.1.524 mantiene l'incarico immediato generato da un comando Telegram /loop nel percorso di consegna protetto per i comandi remoti. Non può quindi restare come secondo normale elemento della coda.

L'elenco di ripresa mostra per ogni sessione la dimensione del checkpoint di ripresa, i messaggi e i token conservati, la dimensione della cronologia della sessione e i checkpoint mancanti, non validi o obsoleti.

Il runtime AgentSpine raggruppato viene aggiornato allo stato ufficiale verificato 0.11.4 con commit 8034487cdd24498076bac48d3f24400bca5e6ae4. Il budget di tempo BLUN di 180 secondi per il completamento in background di SessionStart resta invariato.

Test di regressione eseguibili proteggono la consegna esattamente una volta dei loop di Telegram e tutti gli stati dei valori di ripresa. Il comportamento locale della coda con loop occupato resta invariato.

Nuovo nella 9.1.523

Data di pubblicazione:

BLUN King 9.1.523 consente a Escape di chiudere un menu di comandi con barra aperto e di svuotare la relativa bozza in un unico passaggio, invece di lasciare il testo del comando.

Ctrl+S trasmette una bozza con barra al percorso di accodamento e elaborazione esistente anche quando l'interfaccia segnala inattività, invece di tornare silenziosamente prima di svuotare la coda.

Le bozze normali vengono conservate quando Escape chiude solo un'altra autocompletamento.

Test di runtime rosso-verde proteggono entrambe le scorciatoie contro l'esatto comportamento del pacchetto 9.1.522.

Nuovo nella 9.1.522

Senza data

BLUN King 9.1.522 scrive permission.approval_requested immediatamente nella cronologia della sessione all'apertura di un'autorizzazione di strumento. Un King senza supervisione non sembra più un modello muto o un provider bloccato mentre attende l'operatore.

I pulsanti di approvazione Telegram esistenti vengono usati automaticamente quando la lista di autorizzazione contiene esattamente una chat privata e un numero qualsiasi di gruppi. Con più destinatari privati possibili, l'invio resta bloccato finché BLUN_TELEGRAM_APPROVAL_CHAT_ID non è impostato.

Un test di regressione rosso-verde protegge la visibilità immediata nella cronologia della sessione, l'inoltro inequivocabile a una chat privata, la precedenza di una destinazione impostata esplicitamente e il rifiuto dei destinatari ambigui in entrambe le copie di relay distribuite.

Nuovo nella 9.1.521

Senza data

BLUN King 9.1.521 esegue la scansione SessionStart di AgentSpine al di fuori del percorso di avvio interattivo. Una scansione a freddo della cartella utente che dura 123,6 secondi non blocca più l'editor né il primo input dell'utente.

Gli output riusciti di SessionStart restano automatici: dopo il completamento, l'hook in background continua a trasferire il suo briefing limitato nel contesto della sessione.

Il budget di tempo per le scansioni a freddo sale a 180 secondi. Un test di runtime rosso-verde dimostra che l'avvio ritorna prima di un hook lento e che l'hook può poi continuare a essere eseguito.

Nuovo nella 9.1.520

Data di pubblicazione:

BLUN King 9.1.520 concede all'hook SessionStart di AgentSpine, durante il ricaricamento, tempo sufficiente per completare una scansione completa a freddo del progetto.

Il limite di tempo per l'avvio di AgentSpine sale da 15 a 60 secondi. Tutti gli altri limiti di tempo degli hook restano invariati.

Un nuovo controllo di runtime rosso-verde avvia il vero hook AgentSpine in un progetto temporaneo e controlla sia il suo output sia i due manifest di timeout distribuiti.

Stato del pacchetto verificato

La versione 9.1.520 contiene AgentSpine 0.10.1. Il test di aggiornamento isolato dalla 9.1.519 alla 9.1.520 e il prepack completo sono verdi. SHA-256 del pacchetto npm: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Nuovo nella 9.1.519

Data di pubblicazione:

BLUN King 9.1.519 salva le uscite riuscite dell'hook SessionStart prima che l'avvio o il ricaricamento restituisca il controllo. La disponibilità di AgentSpine raggiunge così automaticamente il contesto di modello della sessione ripresa e non attende più il primo messaggio dell'utente.

I riferimenti storici ai risultati degli strumenti spostati fuori dal contesto conservano un'anteprima limitata di inizio e fine. Gli ancoraggi importanti per la ripresa restano così disponibili, senza dover includere di nuovo il risultato completo in ogni richiesta al modello.

Nuovi controlli di runtime rosso-verde proteggono il trasferimento del contesto SessionStart e le anteprime storiche. Il catalogo di strumenti ripristinato con la 9.1.518 per la manutenzione delle attività resta conservato invariato.

Nuovo nella 9.1.518

Data di pubblicazione:

Durante la manutenzione proattiva dell'elenco di attività, Read, Write, Edit e Bash restano disponibili accanto a TodoList. Il normale percorso di ripristino per le grandi modifiche dei file non viene così più interrotto.

La manutenzione automatica delle attività e il suo prompt di riscontri limitato vengono conservati, senza passare il passo di modello attivo a un catalogo di soli strumenti TodoList.

Un controllo di regressione rosso-verde protegge dalla regressione del catalogo della 9.1.499 e controlla la selezione degli strumenti di ripristino senza schemi duplicati.

Nuovo nella 9.1.517

Data di pubblicazione:

Ctrl+S e Escape restano disponibili anche con la richiesta di autorizzazione aperta. Ctrl+S invia tutti i messaggi in attesa; Escape libera prima un messaggio in attesa e rifiuta l'autorizzazione solo a coda vuota.

La conclusione asincrona della sessione è osservata completamente nei percorsi da tastiera, Telegram /reload e comandi con barra. session.not_found vale come sessione già conclusa, invece di far crollare il nucleo con un rifiuto non gestito.

I controlli di pacchetto rosso-verde proteggono i caratteri di controllo grezzi di Windows e l'errore misurato alla chiusura di una sessione che non esiste più.

Nuovo nella 9.1.516

Data di pubblicazione:

Se nella cronologia salvata manca dopo la compattazione l'inizio di un passaggio dell'assistente, la riproduzione lo ricostruisce dall'evento di contenuto o strumento successivo. king -c non si interrompe più con l'errore interno Received content_part for unknown step_uuid 'undefined'.

Un messaggio Telegram lascia la coda esattamente una volta, non appena il nucleo ha accettato in modo persistente il suo passaggio attivo. I rifiuti reali vengono conservati per un nuovo tentativo. Un bridge Telegram gestito da King e terminato inaspettatamente viene riavviato da un unico watchdog unificato.

Per passo di modello viene accettata solo la prima modifica di TodoList. I punti completati scompaiono automaticamente, i marcatori in sospeso restano visibili anche nei terminali ANSI16 e una nuova lista inizia con esattamente un punto in corso. L'ordine fisso è: urgente, messaggio utente diretto, messaggio bot indirizzato, messaggio bot, messaggio normale.

Il primo passo con strumenti attende al massimo 2,5 secondi il catalogo MCP iniziale; i server opzionali possono continuare ad avviarsi in background. All'avvio del programma viene controllato e installato solo il profilo attivo.

Stato del pacchetto verificato

La versione 9.1.516 contiene AgentSpine 0.10.1. Tutti gli otto gate di regressione prepack, node --check, il controllo dei metadati del pacchetto e un nuovo controllo del pacchetto sono verdi. Lo stesso pacchetto npm contiene i componenti di piattaforma per Windows, Linux e macOS. SHA-256 del pacchetto npm: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Nuovo nella 9.1.515

Data di pubblicazione:

Una lista di attività rimasta veritieramente invariata viene nuovamente accettata dopo un periodo più lungo di lavoro comprovato. King non deve inventare progressi o limitarsi a riformulare un titolo per poter continuare il suo lavoro effettivo.

Anche un loop inattivo può riprendere una TodoList ancora aperta, senza tenere l'agente in modo persistente in un turno di manutenzione con il solo strumento todo. Un controllo di regressione del prepack protegge entrambi i percorsi di errore.

Stato del pacchetto verificato

La versione 9.1.515 contiene AgentSpine 0.10.1. Il controllo di regressione mirato del loop Todo, node --check, il controllo dei metadati di versione e una nuova installazione del pacchetto sono verdi. Lo stesso pacchetto npm contiene i componenti di piattaforma per Windows, Linux e macOS. SHA-256 del pacchetto npm: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Nuovo nella 9.1.514

Data di pubblicazione:

BLUN King 9.1.514 protegge meglio il journal di consegna Telegram senza contenuti da buste di coda manipolate.

Gli identificatori di messaggio vengono accettati solo come numeri decimali positivi. Gli hash di chat già calcolati sono ammessi esclusivamente come valori esadecimali esattamente di dodici cifre in minuscolo. I valori errati simili a contenuti vengono scartati invece di essere registrati.

L'elaborazione Telegram esistente, le fasi di consegna, la rotazione del journal e la diagnosi di quarantena senza contenuti restano invariate. Tutti i 133 test del pacchetto e le nuove esecuzioni di prova del pacchetto per Windows x64, Linux x64, macOS ARM64 e macOS x64 sono verdi.

Stato del pacchetto verificato

La versione 9.1.514 contiene AgentSpine 0.10.1 e ReadBatch. SHA-256 del pacchetto npm: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Nuovo nella 9.1.513

Data di pubblicazione:

BLUN King 9.1.513 registra il percorso di consegna Telegram dall'ingresso al bridge, attraverso routing, accodamento e immissione, fino alla conferma, al ripristino o alla quarantena.

Il journal limitato salva esclusivamente identificatori senza contenuti, hash, fasi di consegna, contatori e motivi di errore ripuliti. Testi di messaggio, prompt, percorsi, nomi utente, token, credenziali e messaggi di errore grezzi non vengono registrati.

Anche la diagnosi di quarantena non duplica più messaggi Telegram, testi visualizzati, indicazioni di origine, ID di chat grezzi o percorsi di immagini. Tutti i 132 test del pacchetto e le nuove esecuzioni di prova del pacchetto per Windows x64, Linux x64, macOS ARM64 e macOS x64 sono verdi.

Stato del pacchetto verificato

La versione 9.1.513 contiene AgentSpine 0.10.1 e ReadBatch. SHA-256 del pacchetto npm: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Nuovo nella 9.1.512

Data di pubblicazione:

BLUN King 9.1.512 impone nella manutenzione proattiva di TodoList un aggiornamento modificato e basato su riscontri, invece di accettare di nuovo la stessa lista all'infinito. Il turno di manutenzione isolato riceve al massimo otto indicazioni compatte su nome dello strumento e risultato dall'ultimo aggiornamento accettato.

Prompt, argomenti, comandi, percorsi completi, risultati degli strumenti o la cronologia di lavoro non vengono reimmessi. Un tentativo TodoList fallito conserva questo riscontro limitato per il tentativo successivo; un aggiornamento riuscito rimuove le indicazioni utilizzate. I punti completati continuano a scomparire automaticamente e nel passo successivo sono di nuovo disponibili i normali strumenti di lavoro.

Stato del pacchetto verificato

9.1.512 supera 127 test di pacchetto su 127. Le nuove installazioni scelgono su Windows x64, Linux x64, macOS ARM64 e macOS x64 i componenti di piattaforma attesi e contengono AgentSpine 0.10.1 e ReadBatch. SHA-256 del pacchetto npm: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Nuovo nella 9.1.511

Data di pubblicazione:

BLUN King 9.1.511 distribuisce AgentSpine 0.10.1 come nuova versione del plugin core indirizzata al contenuto. Il preflight obbligatorio continua a controllare ogni file di istruzioni host attivo in modo race-safe e lega la sua identità all'esatto turno, ma non duplica più il testo completo già caricato dall'host nel contesto di runtime.

Questa versione aggiunge riscontri obbligatori pre-risposta, voci Must-Remember confermate e la sincronizzazione auto-riparante del grafo di persona e relazioni autenticato. Gruppi, persone e appartenenze mancanti vengono riparati in un nuovo allineamento del roster; le interrogazioni locali sulle relazioni terminano visibilmente dopo 5 secondi in caso di blocco.

L'interrogazione Mnemo limitata di Telegram resta conservata: i messaggi precedenti vengono caricati solo in caso di necessità concreta, con riferimento stretto ad agente, persona, gruppo, tema, thread e periodo di tempo. Una cronologia Telegram completa non finisce di routine nel prompt.

Stato del pacchetto verificato

9.1.511 supera 126 test di pacchetto su 126. Il vero CLAUDE.md di 15.519 byte è stato verificato completamente, mentre l'intero contesto iniettato comprendeva 5.667 byte e non conteneva alcun testo integrale di istruzioni. Le nuove installazioni scelgono su Windows x64, Linux x64, macOS ARM64 e macOS x64 i componenti di piattaforma attesi e contengono AgentSpine 0.10.1 e ReadBatch. SHA-256 del pacchetto npm: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Nuovo nella 9.1.510

Data di pubblicazione:

BLUN King 9.1.510 aggiunge lo strumento ReadBatch. Legge da due a dodici file UTF-8 già noti e indipendenti, o intervalli di file, in un passaggio di modello, mantenendo l'ordine delle richieste. Ogni percorso passa attraverso gli stessi controlli di accesso, regole e autorizzazione di una chiamata Read singola. I successi parziali restano visibili; solo un lotto completamente fallito vale come errore complessivo.

Stato del pacchetto verificato

9.1.510 supera 125 test di pacchetto su 125. Le nuove installazioni scelgono su Windows x64, Linux x64, macOS ARM64 e macOS x64 i componenti di piattaforma attesi e contengono ReadBatch. AgentSpine è rimasto volutamente su 0.8.0, finché il blocco del budget di contesto trovato indipendentemente nello stato preliminare più recente non è stato risolto senza un prompt di runtime ingrandito. SHA-256 del pacchetto npm: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Nuovo nella 9.1.509

Data di pubblicazione:

BLUN King 9.1.509 richiede in ogni messaggio di lavoro Telegram autorizzato tra bot una menzione esplicita del King previsto. I messaggi dei bot senza menzione corrispondente restano visibili, ma non vengono più bufferizzati, accodati, consegnati o trasferiti successivamente nel contesto del modello di questo King. In questo modo un messaggio di bot prioritario per un King non può più diventare l'incarico di un altro King.

Stato del pacchetto verificato

Tutti i 121 test di pacchetto superano. Lo stesso pacchetto contiene i componenti di piattaforma verificati per Windows x64, Linux x64, macOS ARM64 e macOS x64. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Nuovo nella 9.1.508

Data di pubblicazione:

I punti todo aperti hanno di nuovo una casella visibile. Anche la prima lista di attività normale inizia con esattamente un punto in corso; i passi successivi restano in sospeso finché il loro inizio effettivo non è comprovato.

I messaggi Telegram diretti e di gruppo accettati vengono passati a Mnemo in modo asincrono, bufferizzati in modo persistente e deduplicati in modo esatto. Un hub temporaneamente non raggiungibile non blocca né la consegna Telegram né l'esecuzione di King. I comandi /loop e i tick interni del loop non vengono volutamente salvati.

AgentSpine non carica una cronologia Telegram completa nel contesto di runtime. Se un incarico necessita di un messaggio precedente, viene effettuata un'interrogazione Mnemo limitata per agente, persona, gruppo, tema, thread e periodo di tempo.

Stato del pacchetto verificato

Tutti i 120 test di pacchetto riescono. Le nuove installazioni scelgono su Windows, Linux x64, macOS ARM64 e macOS x64 il componente corretto degli appunti nativi e contengono la connessione Telegram-Mnemo gestita e AgentSpine. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Nuovo nella 9.1.507

Data di pubblicazione:

BLUN King 9.1.507 istruisce esplicitamente il modello nello strumento Read a raggruppare in una risposta del modello le letture di file e intervalli tra loro indipendenti, quando più input possono essere utili.

Questo riduce i cicli di modello evitabili nei grandi contesti di lavoro, senza modificare l'esecuzione, la navigazione tra le pagine, le autorizzazioni o la gestione dei risultati di Read.

Stato del pacchetto verificato

Un test di regressione mirato protegge la modifica; tutti i 112 test del pacchetto sono superati.

Nuovo nella 9.1.506

Data di pubblicazione:

I punti TodoList completati vengono rimossi immediatamente dalla TUI visibile. La lista di attività persistente ha già scartato correttamente queste voci; ora l'interfaccia mostra lo stesso stato ripulito, mentre il lavoro in corso e in sospeso resta completamente conservato.

Il turno di manutenzione automatico usa un prompt di sistema autonomo di 546 caratteri. In precedenza, nonostante l'unico strumento todo disponibile, veniva allegato a questo scopo il prompt di lavoro completo con circa 19.000 caratteri. Il passo di lavoro successivo continua a ricevere il prompt completo e il suo normale catalogo di strumenti.

Guadagno di contesto misurato e stato del pacchetto

Un'esecuzione reale ha mostrato per ogni ottavo passo di lavoro un proprio giro di manutenzione Todo con 15.221 token di input. Il prompt di manutenzione statico si riduce di 18.470 caratteri; il risparmio reale di runtime viene misurato di nuovo dopo l'aggiornamento della flotta. Il tarball pubblicato supera 111 test su 111. Le nuove installazioni di pacchetto su Windows con Node 24.19.0 e Linux con Node 24.18.0 confermano la versione 9.1.506; i binari macOS per ARM64 e x64 sono contenuti nello stesso pacchetto npm. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Nuovo nella 9.1.505

Data di pubblicazione:

Un messaggio Telegram che arriva dopo la presa in carico del canale ma prima del completamento dell'attivazione della coda non viene più saltato come vecchio arretrato. Senza un checkpoint valido, l'elaborazione inizia al confine di byte misurato all'avvio della presa in carico invece che alla fine del file successiva.

Un checkpoint persistente valido mantiene la precedenza. Se il file della coda viene sostituito durante il passaggio, il nuovo file inizia in modo sicuro al byte zero; i messaggi storici già presenti prima della presa in carico continuano a non essere riprodotti di nuovo.

Regressione misurata e stato del pacchetto

Il messaggio di gruppo 63456 è arrivato un secondo dopo l'assunzione del canale, il punto di controllo è saltato esattamente fino alla sua fine e il messaggio non è apparso in nessuna cronologia di modello. Questo percorso di perdita reale è protetto come regressione. Il tarball pubblicato supera 111 test su 111; le nuove installazioni di pacchetto su Windows con Node 24.19.0 e Linux con Node 24.18.0 e un aggiornamento reale dalla 9.1.504 confermano la versione 9.1.505. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Nuovo nella 9.1.504

Data di pubblicazione:

Un messaggio Telegram già in coda durante un'esecuzione dell'agente vuota viene ora avviato come nuovo turno del modello attraverso il normale percorso di canale. Non attende più un'esecuzione attiva che per definizione non può esistere in stato di inattività.

Il passaggio esistente in un turno in corso resta invariato. Restano protetti anche la manutenzione todo isolata, la rimozione automatica dei punti completati e il successivo ripristino dei normali strumenti di file, ricerca e shell.

Stato del pacchetto verificato

Il tarball pubblicato supera 106 test su 106. La nuova regressione di inattività era rossa prima dell'intervento ed è verde dopo, insieme a 24 test di coda. Le nuove installazioni di pacchetto su Windows con Node 24.19.0 e Linux con Node 24.18.0 confermano la versione 9.1.504 e lo stesso SHA-256 df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Nuovo nella 9.1.503

Data di pubblicazione:

Il messaggio di manutenzione Todo isolato porta ora anche un campo toolCalls esplicitamente vuoto. Soddisfa così la stessa forma di messaggio dei giri di lavoro regolari e può essere elaborato in sicurezza dalla normalizzazione del provider BLUN.

L'errore di runtime reale TypeError: message.toolCalls is not iterable non si verifica più prima della chiamata TodoList. Un test di regressione itera il messaggio generato esattamente come il confine del provider, prima del rilascio della manutenzione.

Stato del pacchetto verificato

Il tarball pubblicato supera 105 test su 105. Nuove esecuzioni di prova del pacchetto su Windows con Node 24.19.0 e Linux con Node 24.15.0 confermano la forma completa del messaggio del provider, la manutenzione Todo isolata e la rimozione automatica dei punti completati. Il collaudo reale della flotta si svolgerà dopo il riavvio controllato dei tre King.

Nuovo nella 9.1.502

Data di pubblicazione:

Il passo di manutenzione TodoList dovuto riceve solo più un messaggio fresco, limitato al compito attuale e all'elenco visibile. I vecchi Read, Bash o le chiamate MCP dalla cronologia di lavoro non possono più finire nel passo volutamente limitato a TodoList.

I punti completati scompaiono automaticamente dalla lista visibile e persistente al salvataggio. I punti in corso, in sospeso, bloccati, in attesa di approvazione e annullati vengono conservati; la lista non cresce quindi senza limiti per il lavoro concluso.

Riscontro di flotta misurato

Due profili di agenti hanno incontrato indipendentemente la stessa regressione: dopo un uso riuscito degli strumenti, la manutenzione Todo ripeteva gli strumenti di lavoro storici e mostrava Tool not found. Il tarball pubblicato supera 105 test su 105. Le nuove installazioni su Windows con Node 24.19.0 e Linux con Node 24.15.0 confermano la manutenzione isolata, la rimozione dei punti completati e il ritorno degli strumenti normali. Una verifica macOS reale non fa parte di questa prova.

Nuovo nella 9.1.501

Data di pubblicazione:

Dopo un passo di manutenzione TodoList riuscito, nel passo di lavoro immediatamente successivo sono di nuovo disponibili tutti gli strumenti selezionati per il giro. Read, Bash e gli altri strumenti di lavoro non restano più nascosti dietro il catalogo Todo temporaneamente limitato.

Regressione riparata

Il passo Todo offriva volutamente solo TodoList. La sua selezione di strumenti restava però attiva senza ripristino esplicito anche nel passo successivo. 9.1.501 rimette lì il catalogo normale e protegge entrambi i percorsi del passo successivo con una regressione.

Golden Release 9.1.500

Data di pubblicazione:

Questa versione raccoglie senza modifiche l'insieme completo delle funzionalità della 9.1.499 come pubblicazione npm comune per Windows, Linux e macOS. La marcatura Gold è volutamente limitata ai titoli di questa versione; le voci più vecchie mantengono la loro rappresentazione precedente.

Stato della release

La Golden Release adotta le modifiche verificate di Todo, coda, loop, contesto, AgentSpine e analisi delle immagini dalla 9.1.499 senza logica di runtime aggiuntiva.

Nuovo nella 9.1.499

Data di pubblicazione:

I dati di immagini, audio e video al di fuori degli ultimi dodici messaggi della conversazione vengono sostituiti da brevi riferimenti solo nella proiezione ripetuta per il modello. I media attuali, il testo del messaggio e la cronologia grezza completa della sessione restano invariati.

In un checkpoint di ripresa misurato, questa proiezione risparmia 85.748 caratteri, ovvero circa 21.437 token di input stimati per ogni ulteriore passo di strumento.

La manutenzione Todo dovuta gira prima del nono blocco di lavoro come passo di modello separato a basso sforzo. In questo passo il runtime offre esclusivamente TodoList; gli strumenti di file, ricerca, shell e altri strumenti di lavoro vengono rilasciati di nuovo solo dopo un aggiornamento valido.

I nuovi messaggi utente continuano ad avere la precedenza sulla manutenzione Todo. Il controllo Todo rigido resta come rete di sicurezza per aggiornamenti realmente non validi, ma non appare più come normale errore intermedio rosso prima di una manutenzione autonoma della lista.

Prova verificata

Il tarball pubblicato supera 105 test di runtime e regressione su 105. Le nuove installazioni isolate su Windows con Node 24.19.0 e Linux con Node 24.15.0 riportano esattamente la versione 9.1.499 e confermano la proiezione dei media, la cronologia grezza invariata, il precontrollo Todo e l'occultamento di tutti gli strumenti di lavoro durante il passo Todo. Il candidato comprende 850 percorsi e porta lo SHA-256 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Una verifica macOS reale non fa parte di questa prova.

Nuovo nella 9.1.498

Data di pubblicazione:

/usage mostra il tasso di successo della cache di prompt riportato dal provider e i token di cache letti e scritti per modello. Senza attività di cache riportata, la visualizzazione non inventa alcun tasso.

/tokens è un alias breve per la diagnostica di contesto dettagliata esistente; /offload richiama la compattazione archiviante esistente. Entrambi i percorsi non innescano alcuna chiamata di modello aggiuntiva.

Messaggi bot autorizzati diversi non vengono più scartati da una finestra rigida di 15 secondi. L'ordine esistente resta conservato: i messaggi privati e quelli esplicitamente indirizzati vengono prima dei messaggi bot, i messaggi bot prima del contesto normale.

Una compattazione completa trasferisce l'esatta lista Todo nel nuovo contesto. Se poi percorso, comando, hash o requisito sono incerti, un avviso di ripristino una tantum richiede prima la lettura della cronologia archiviata invece di una ricerca ampia di file o un nuovo inizio.

I passi Todo completati restano conservati come riscontro. Se conoscenze successive rendono nuovamente necessario un passo, la conclusione comprovata resta e il nuovo controllo compare come passo separato in corso, con motivazione.

I loop di sessione ricorrenti attendono finché la lista Todo mantenuta contiene ancora lavoro in corso o in sospeso. Gli intervalli mancati vengono accorpati fino al reale stato di inattività; altri promemoria pianificati restano invariati.

Prova verificata

Il tarball preparato supera 100 test di runtime e regressione su 100. Le nuove installazioni isolate su Windows con Node 24.19.0 e Linux con Node 24.15.0 riportano esattamente la versione 9.1.498 e confermano la visualizzazione della cache, gli alias dei comandi, il ripristino della compattazione, le prove Todo monotone, la protezione del loop di sessione, il changelog del pacchetto e la priorità dei bot. Il candidato comprende 849 percorsi e porta lo SHA-256 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Una verifica macOS reale non fa parte di questa prova.

Nuovo nella 9.1.497

Data di pubblicazione:

I messaggi bot di Telegram da gruppi condivisi vengono dopo i messaggi privati e quelli esplicitamente indirizzati, ma prima del contesto normale. La priorizzazione non impone alcuna risposta.

Un messaggio Telegram accettato scompare dalla coda visibile non appena inizia il passo di modello iniettato. Una consegna rifiutata o un'interruzione prima del primo passo lo conserva per un nuovo tentativo.

Una risposta Telegram o una modifica di messaggio ormai dovuta non viene più bloccata dalla manutenzione Todo. Il passo di lavoro normale successivo resta bloccato fino a un aggiornamento veritiero della lista Todo.

Versioni da 9.1.496 a 9.1.487

VersioneModifiche
9.1.496Consegna automaticamente i messaggi utente di Telegram singolarmente, rimuove solo l'ID del messaggio esattamente accettato o a cui è stata data risposta, impone un progresso veritiero per ogni lista Todo visibile e nasconde i payload hook interni riusciti.
9.1.495Avvia ogni obiettivo nuovo o sostituito con una nuova lista Todo visibile, richiede aggiornamenti veritieri, rimuove immediatamente il focus di gruppo Telegram a cui è stata data risposta con successo, posticipa le normali conferme di ricezione fino alla fine del turno e aggiunge veri controlli di decodifica per Ctrl+S e Ctrl+T.
9.1.494Separa nuovamente le scorciatoie in modo inequivocabile: Ctrl+S controlla solo l'arretrato della coda, Ctrl+T solo la lista Todo. I messaggi utente di Telegram si autorizzano durante il lavoro attivo per il prossimo passaggio sicuro.
9.1.493I messaggi utente di Telegram vengono autorizzati automaticamente per il prossimo passaggio sicuro durante il lavoro attivo. I messaggi diretti restano in testa alla coda, senza fermare in modo persistente i messaggi di gruppo.
9.1.492I messaggi di gruppo già autorizzati restano conservati in caso di consegna temporaneamente occupata e vengono ritentati. Pacchetto, metadati npm, manifest pubblico e changelog vengono controllati insieme prima di un messaggio di successo.
9.1.491Ai messaggi diretti di Telegram viene data priorità immediata durante il lavoro attivo. Il controllo manuale della coda è rimasto disponibile per gli altri messaggi.
9.1.490La cronologia del pacchetto documenta integralmente la versione 9.1.487 non pubblicata e le riparazioni effettivamente pubblicate a partire dalla 9.1.488.
9.1.489Lista delle attività, controllo della coda, identità di esecuzione Telegram, installazione del profilo AgentSpine e analisi delle immagini gestita sono stati ripristinati e protetti con test di regressione.
9.1.488Il plugin core AgentSpine preparato è stato pubblicato. I duplicati Telegram non lasciano più un turno fittizio; profondità di pensiero e gestione sicura della telemetria vengono conservate attraverso i passi degli strumenti.
9.1.487Non pubblicata. Questa versione preparava AgentSpine come plugin core gestito. Su npm, dopo la 9.1.486 è seguita direttamente la 9.1.488.

Nuovo nella 9.1.486

Data di pubblicazione:

I profili nuovi e aggiornati partono ora in modo affidabile in inglese su Windows, macOS e Linux. Un valore di lingua automatico salvato viene migrato una volta, mentre le lingue scelte esplicitamente restano invariate.

Gli aggiornamenti automatici all'avvio sono di nuovo attivati per impostazione predefinita tramite l'installer esistente legato alla versione. [upgrade].auto_install = false mantiene la richiesta di conferma; un aggiornatore in background non viene reintrodotto.

Dialoghi di avvio, avanzamento, errori, messaggi di successo e ripresa della sessione usano ora la stessa lingua. Test di regressione e di mutazione proteggono migrazione, percorso di aggiornamento e dati di sessione.

Prova verificata

La suite di test completa ha superato 1.474 controlli su 1.474. Un'esecuzione di aggiornamento isolata ha installato la 9.1.486 dalla 9.1.485, ha conservato configurazione e sessione invariate e ha avviato la nuova CLI. Una prova di avvio separata ha dimostrato l'installazione automatica senza richiesta di conferma e la migrazione una tantum di un vecchio valore di lingua automatico all'inglese.

Versioni da 9.1.485 a 9.1.178

VersioneModifiche
9.1.485
  • Limita la prima riproduzione visibile di una sessione ripresa senza indice di scrollback ai 15 turni di conversazione attivi, invece di riprodurre l'intera conversazione.
  • Svuota l'area di aggiornamento visibile dopo un aggiornamento riuscito, prima che parta la nuova console; lo scrollback normale del terminale resta conservato.
  • Aggiunge controlli di regressione e di mutazione per il ripiego della riproduzione, inclusa una simulazione con 97.596 record.
9.1.484
  • Il rilevamento dei plugin accetta anche .codex-plugin/plugin.json e risolve PLUGIN_ROOT oppure BLUN_PLUGIN_ROOT in comando, argomenti e directory di lavoro.
9.1.483
  • Il modello di compattazione può essere selezionato, salvato e ripristinato all'ereditarietà separatamente dal modello attivo; selezione e riscontro sono disponibili nel comando di inattività e nelle impostazioni localizzate.
9.1.482
  • I risultati Read esternalizzati conservano il line_offset successivo e continuano la lettura originale da lì, invece di rileggere lo stesso file dall'inizio.
9.1.481
  • Le risposte dei sottoagenti che terminano al limite dei token senza chiamata di strumento vengono riconosciute come max_tokens per la continuazione esistente. I pattern glob con .. e i percorsi home nominati come ~name vengono rifiutati.
9.1.480
  • Aggiorna la skill translate-native inclusa e il server MCP Language Guard alla versione 6.42.13.
  • Collega i file inclusi della protezione linguistica byte per byte al commit sorgente 6430ce30e235c1a9d1ebcd1b646d62edce510605.
  • Aggiunge controlli di origine e di mutazione, così byte di protezione modificati o una versione della skill diversa fanno fallire il controllo di pubblicazione.
9.1.479
  • Aggiunge al servizio privato King dell'Agent API una rotta interna autenticata per il controllo di disponibilità.
  • Controlla la disponibilità del servizio senza creare una sessione cliente o avviare un'esecuzione dell'agente.
  • Limita la rotta all'interfaccia loopback e a GET, la protegge con un segreto e ne impedisce la memorizzazione nella cache.
9.1.478
  • Corregge le pause ordinarie del focus diretto di Telegram dopo un riavvio, anche quando i checkpoint più vecchi non contengono un termine di risposta.
  • Conserva le pause espressamente richieste dall'utente fino al rilascio, invece di lasciarle scadere automaticamente.
  • Rilascia i messaggi di canale accodati per un'esecuzione attiva non appena termina il focus diretto.
9.1.477
  • Aggiunge al servizio privato dell'Agent API un wrapper di processo esplicito avviato dall'operatore.
  • Elabora SIGINT e SIGTERM esattamente una volta, anche quando i segnali arrivano durante l'avvio.
  • Termina in modo sicuro con messaggi limitati, non chiama process.exit e non avvia mai il servizio automaticamente.
9.1.476
  • Aggiunge al servizio privato dell'Agent API un contratto di ambiente bloccato per impostazione predefinita (fail-closed).
  • Richiede una porta loopback esplicitamente impostata, segreti di isolamento, impostazioni del provider e limiti di risorse.
  • Lascia il servizio privato fermo e la pulizia automatica delle sessioni inattive disattivata, finché entrambi non sono stati espressamente configurati.
9.1.475
  • Libera esclusivamente le sessioni dell'Agent API configurate di conseguenza e realmente inattive, prima che un cliente raggiunga il limite di sessioni.
  • Protegge le esecuzioni attive di modello e strumenti indipendentemente dalla loro età e aggiorna il periodo di inattività in caso di uso reale.
  • Lascia la pulizia automatica disattivata finché un operatore non configura espressamente un timeout di inattività.
9.1.474
  • Revoca l'assegnazione attiva della sessione quando la continuazione di un agente fallisce dopo un risultato di strumento.
  • Consente successivamente la chiusura esplicita della sessione interessata.
  • Lascia invariati i ritorni di strumento riusciti e il contratto pubblico del modello.
9.1.473
  • Protegge una sessione dell'Agent API dalla chiusura finché è in corso la sua prima chiamata al modello.
  • Libera in modo affidabile la sessione dopo una risposta riuscita o un errore del modello.
  • Lascia invariati il percorso esistente per i modelli non elaborati e il contratto pubblico del modello.
9.1.472
  • Consente ai clienti di chiudere espressamente una sessione inattiva dell'Agent API e di liberare il loro posto di sessione limitato.
  • Impedisce la chiusura di sessioni attive e limita ogni operazione di chiusura al relativo cliente proprietario.
  • Rende disponibile il posto liberato per una nuova sessione senza modificare il contratto pubblico del modello.
9.1.471
  • Aggiunge un host di servizio chiuso che compone lo stack privato dell'Agent API senza avviarlo automaticamente.
  • Richiede segreti separati per trasporto e isolamento, una directory radice assoluta per i clienti e una configurazione esplicita dell'ambiente di esecuzione King.
  • Collega i listener all'interfaccia loopback e all'arresto chiude ogni sessione cliente e ogni ambiente di esecuzione.
9.1.470
  • Isola le sessioni headless dell'Agent API per cliente attendibile e sessione pubblica.
  • Raggruppa i primi accessi simultanei in una sessione SDK e limita clienti e sessioni attivi.
  • Usa identificatori interni opachi legati a chiave e directory di lavoro, mentre gli identificatori di sessione pubblici stabili vengono conservati.
9.1.469
  • Aggiunge all'adattatore dell'Agent API un trasporto HTTP privato raggiungibile esclusivamente tramite l'interfaccia loopback.
  • Richiede un segreto di servizio e un'identità cliente prescritta lato server; le indicazioni di identità falsificate nel corpo della richiesta vengono ignorate.
  • Rifiuta le richieste sovradimensionate o errate e tiene i dettagli interni del provider fuori dai messaggi di errore pubblici.
9.1.468
  • Mantiene reattivo l'agente principale mentre i sottoagenti in background e i sottoagenti annidati continuano a lavorare.
  • Consente alle sessioni limitate dell'Agent API di usare il ciclo di vita dei sottoagenti senza esporre strumenti locali di shell o file system.
  • Trasmette l'esatto confine degli strumenti a ogni livello di sottoagente annidato, così le limitazioni non possono essere aggirate tramite delega.
9.1.467
  • Aggiunge un adattatore di trasporto esplicito per le esecuzioni dell'agente, senza intercettare le rotte esistenti per i modelli non elaborati o gli elenchi di modelli.
  • Collega risultati degli strumenti e interruzioni mirate allo stesso ambito di cliente, sessione e richiesta.
  • Mostra esclusivamente King, ripulisce gli errori interni inattesi e rifiuta lo streaming finché non esiste un contratto agente per esso.
9.1.466
  • Registra ogni chiamata al modello completata dell'Agent API sotto un ID di attività stabile, senza sommare l'uso di clienti diversi.
  • Una mappatura JSONL persistente mantiene reperibili richiesta, sessione, attività, ID di chiamata e campi di uso non elaborati anche dopo un riavvio.
  • All'esterno compaiono solo King e i contatori non elaborati di input, input in cache e completamento; i dati di uso mancanti restano espressamente contrassegnati.
9.1.465
  • Aggiunge un controllo di esecuzione isolato per l'endpoint agente esplicito dell'Agent API, senza modificare i completamenti di modello non elaborati.
  • Le chiamate di strumento gestite dal client mantengono una singola esecuzione King attraverso le restituzioni dei risultati e restano limitate alla richiesta originale.
  • Le risposte degli agenti superiori escludono i flussi di eventi dei sottoagenti figli e le bozze scartate dei nuovi tentativi.
9.1.464
  • I sottoagenti gestiti ora girano disaccoppiati, così l'agente principale resta reattivo mentre il lavoro delegato prosegue.
  • I sottoagenti in esecuzione possono essere controllati con TaskUpdate o terminati con TaskStop, senza chiudere la sessione principale.
  • I messaggi di gruppo Telegram indirizzati restano in focus finché l'agente non risponde nella chat corrispondente.
9.1.463
  • Se sono presenti dati di finestra, un ripristino da checkpoint renderizza solo il gruppo di turni TUI attivo più recente; le righe più vecchie restano nell'archivio di scroll e vengono caricate quando necessario.
9.1.462
  • I contenuti invariati di tui.toml non attivano più uno scambio atomico di file; le modifiche reali continuano a usare il percorso di scrittura bloccato esistente.
9.1.461
  • /status distingue la versione del runtime caricata dal pacchetto installato e segnala una divergenza anche nello stato remoto di Telegram.
9.1.460
  • I messaggi di sessione visibili più vecchi restano in un archivio persistente su disco e vengono caricati a blocchi durante lo scroll verso l'alto, senza leggere all'avvio tutti i blocchi di testo.
9.1.459
  • Un ripristino ricostruisce un checkpoint semantico legato all'integrità e legge solo la parte del file di sessione invariato aggiunta da allora; con un checkpoint non valido resta il replay completo come ripiego.
9.1.458
  • Una somma di controllo ripresa da un rapporto esterno viene vincolata solo se esattamente questo valore è presente nell'evento sorgente selezionato.
9.1.457
  • Se la stessa somma di controllo proviene da più eventi esterni, l'origine viene dichiarata ambigua invece di essere attribuita a un rapporto.
9.1.456
  • Le somme di controllo nei messaggi Telegram in uscita vengono confrontate con i risultati locali degli strumenti e i rapporti esterni visibili; i valori non abbinati generano un avviso di origine.
9.1.455
  • I rapporti Telegram possono essere vincolati come credible_unverified tramite ID di chat e messaggio; reporter e origine dell'evento vengono impostati dal runtime.
9.1.454
  • I controlli recenti vengono automaticamente legati alla sessione e all'agente che li hanno generati; le misurazioni inoltrate restano rapporti esterni.
9.1.453
  • Un riscontro di completamento viene legato al criterio di completamento attualmente valido e viene rifiutato in caso di criterio diverso o superato.
9.1.452
  • Ogni riscontro viene legato all'ambito target realmente misurato; i controlli dei comandi devono riportare lo stesso valore sicuro di BLUN_EVIDENCE_SCOPE su entrambi i lati.
9.1.451
  • Ogni riscontro riporta il tipo esatto inspection, integrity, syntax, test o reachability. Un controllo più debole non può essere presentato come più forte.
9.1.450
  • I riscontri dei risultati e quelli dei verificatori sono separati. Solo un verificatore nuovo o modificato richiede una seconda prova di severità autonoma; le misurazioni normali non richiedono una prova in rosso.
9.1.449
  • Il riscontro di completamento nomina l'esatta chiamata di controllo riuscita tramite la sua toolCallId; una chiamata di comando mista con modifica e controllo non basta.
9.1.448
  • Un completamento di obiettivo deve legare l'affermazione controllata a una chiamata di controllo riuscita dello stesso turno; i soli strumenti di scrittura o modifica non valgono come riscontro.
9.1.447
  • Un'azione selezionata viene legata a riscontri decisionali persistenti; riscontri sconosciuti o obsoleti impongono una nuova pianificazione.
9.1.446
  • Il blocco anti-ripetizione in tempo reale riconosce inoltre brevi sequenze ricorrenti da due a otto parole.
9.1.445
  • Gli avvisi di apprendimento selezionati vengono salvati insieme al risultato di apprendimento validato del turno corrente come traccia di esposizione, senza affermarne la causalità.
9.1.444
  • La ricerca di rilevanza per errori precedenti usa dati persistenti di obiettivo, checkpoint e quadro del problema invece dei soli messaggi più recenti dell'utente.
9.1.443
  • In una continuazione immediata dell'obiettivo, una selezione esplicita tool: o skill: carica esattamente il mezzo scelto.
9.1.442
  • Il focus di lavoro conserva il filo decisionale di stato, fase, ultimo controllo, selezione, motivazione, supporto, rischio e reversibilità.
9.1.441
  • La conoscenza mancante viene gestita come dominio knowledge_gap separato invece che nel testo generale dell'obiettivo, le viene assegnata una priorità e viene nascosta quando il valore è vuoto.
9.1.440
  • Conoscenza del mondo e assunzioni possono essere incluse come domini propri nel focus persistente e ponderate.
9.1.439
  • Il focus cognitivo persistente riceve una valutazione di salienza con decadimento tra le sessioni e rinforzo a un nuovo accesso.
9.1.438
  • Durante il replay della sessione, taglio, unione e rendering vengono rinviati; in seguito viene richiesto esattamente un nuovo render del transcript.
9.1.437
  • Il guardiano di inattività usa di nuovo il percorso di testo adatto per i timeout e non termina più il processo tramite un parametro non autorizzato nel timer.
9.1.436
  • Lo stato remoto di Telegram mostra durante un turno attivo inizio, ultimo avanzamento, ultimo strumento ed errori ripetuti; la TUI pubblica a questo scopo snapshot di attività in corso.
9.1.435
  • I checkpoint del focus privato di Telegram seguono ora l'area di lavoro legata alla sessione attiva.
  • La selezione dell'area di lavoro non salva più la directory di avvio come luogo di continuazione per le conversazioni dirette.
9.1.434
  • L'apprendimento confermato segue ora l'area di lavoro legata alla sessione agente attiva.
  • Le sessioni con più aree di lavoro e le sessioni riprese non salvano né mostrano più le lezioni di progetto nella directory del processo host.
9.1.433
  • La preparazione di un input nell'editor esterno resta ora entro il limite di pulizia delle directory temporanee.
  • Se la prima scrittura fallisce, ad esempio per disco pieno o permessi mancanti, la directory temporanea dell'editor viene rimossa prima che l'errore venga propagato.
9.1.432
  • Gli errori di stream temporanei possono ora essere ritentati anche dopo un output parziale visibile, con lo stesso modello selezionato.
  • Il testo dell'assistente incompleto e le superfici di strumento non concluse vengono completati o scartati prima del nuovo tentativo, così il nuovo output non viene appeso al tentativo fallito.
  • Dopo un output visibile, il cambio di provider resta bloccato, così una risposta non può cambiare provider a metà stream.
9.1.431
  • I processi locali dello strumento Bash disattivano ora in modo forzato le richieste interattive di Git nel terminale, invece di ereditare un'impostazione interattiva del processo genitore.
  • I dialoghi askpass ereditati da Git, SSH e Git Credential Manager sono disattivati nel processo figlio dello strumento; così vengono evitati tempi di attesa invisibili per le credenziali Windows.
  • La shell genitore e l'ambiente della sessione in esecuzione restano invariati; il comportamento esistente con ingresso standard chiuso viene conservato e protetto in modo indipendente.
9.1.430
  • La compattazione completa può ora usare un alias di modello opzionalmente configurato tramite [loop_control].compaction_model; il modello King attivo resta l'impostazione predefinita.
  • Autenticazione, preparazione del contesto, budget di completamento, apprendimento per overflow e rendicontazione dell'uso della compattazione sono completamente legati al modello di compattazione scelto.
  • Il modello attivo continua a determinare l'inizio della compattazione e il freno dell'ultima richiesta, così un modello di riepilogo più piccolo non può ridurre di nascosto la finestra di pensiero centrale.
9.1.429
  • Bash su Windows rifiuta ora la sintassi cmd.exe inequivocabile prima dell'avvio del processo, invece di sprecare un'esecuzione visibilmente fallita.
  • La descrizione dello strumento Bash chiarisce espressamente che la bash POSIX su Windows resta attiva, incluso VS Code, e nomina le convenzioni corrette per percorsi e reindirizzamenti.
  • I comandi find POSIX validi restano consentiti; per la semantica cmd voluta consapevolmente resta disponibile un passaggio esplicito a cmd.exe /c.
9.1.428
  • Le scritture JavaScript e TypeScript generate si fermano ora prima dell'accesso al disco quando un'istruzione eseguibile si ripete otto volte di seguito; così vengono impediti gli output fuori controllo degli script di analisi.
  • Il controllo di protezione comprende sia le chiamate Write per file completi sia le sostituzioni Edit, mentre i file non di codice, i commenti, le stringhe e le ripetizioni brevi legittime restano invariati.
  • Tutti e tre i casi di degenerazione osservati con 15, 23 e 31 istruzioni ripetute vengono bloccati; le intenzioni arbitrarie incomplete ma non ripetitive restano fuori da questo controllo meccanico.
9.1.427
  • Il comando visibile /memory core riporta ora il limite attivo dell'adattatore di memoria, la versione del contratto, la modalità di identità, lo stato di integrità e i riscontri tra portali, opzionalmente come output --json.
  • La memoria di riserva legata ai profili e le identità derivate dai profili vengono espressamente escluse dalla disponibilità per un nucleo comune, invece di essere presentate come memoria neutrale rispetto ai portali.
  • I provider configurati restano visibilmente non confermati finché non esistono riscontri separati; la diagnostica è in sola lettura, non concede permessi e non inventa mai prove tra portali.
9.1.426
  • Il comando visibile /memory acceptance esegue ora un controllo di memoria V7 temporaneo sintetico attraverso CLI, Telegram e web e può opzionalmente produrre un rapporto --json.
  • Dieci controlli indipendenti coprono origine del portale, identità collegate e non collegate, isolamento di agente e gruppo, deduplicazione, correzione ed eliminazione globali, il blocco per impostazione predefinita (fail-closed) del provider e i byte sorgente protetti.
  • Il rapporto di accettazione serve esclusivamente come riscontro deterministico: non concede permessi e non legge né modifica mai un vero profilo utente.
9.1.425
  • I sottoagenti che raggiungono il limite di token ricevono ora nello stesso contesto agente una breve esecuzione di passaggio di consegne senza strumenti, invece di perdere il lavoro di strumento concluso.
  • Se anche questo passaggio raggiunge il limite, l'agente genitore riceve un riepilogo parziale limitato e l'istruzione esatta di continuare con lo stesso agente.
  • Il ripristino resta progettato secondo il principio fail-closed (bloccato per impostazione predefinita): nessun nuovo tentativo completo dell'incarico, nessuna segnalazione di completamento senza passaggio di consegne finale e nessun nuovo permesso.
9.1.424
  • Le lezioni confermate da Mistake.md vengono ora trasferite a casi formulati diversamente ma semanticamente simili di affidabilità, consegna, orchestrazione, memoria, pubblicazione, media e validazione.
  • I termini di riscontro esatti continuano ad avere precedenza sulle ampie categorie semantiche; il testo non correlato resta senza assegnazione.
  • Le formulazioni tedesche naturali vengono unificate in modo deterministico; la nuova classificazione non crea nuove autorizzazioni né promuove una lezione non confermata.
9.1.423
  • Le terminazioni del runtime scrivono ora una voce di diagnostica persistente e sincrona prima che nucleo o launcher ritornino o terminino.
  • Eccezioni non intercettate, rifiuti non gestiti, terminali falliti, segnali, errori di avvio, terminazioni normali, errori dei processi figli e le loro terminazioni conservano l'esatta causa ripulita insieme al confine del processo.
  • Il registro privato è limitato e a prova di errore, rimuove segreti e percorsi home e non riavvia né ricarica una sessione in esecuzione.
9.1.422
  • Una sessione aperta e inattiva osserva ora il proprio trigger di tempo salvato e si attiva in modalità automatica e God Mode a partire da dueAt.
  • Un trigger giunto a scadenza attende che risposte attive, compattazione, messaggi in coda, comandi e dialoghi siano conclusi, prima di procedere esattamente una volta.
  • Prima dell'avvio, il runtime rilegge obiettivo, revisione del checkpoint, scadenza, modalità di autorizzazione e sessione e scarta i timer su ogni percorso di terminazione della sessione.
9.1.421
  • I checkpoint di attesa basati sul tempo salvano ora un timestamp dueAt esatto e lo uniformano su UTC.
  • Un avvio regolare della sessione in modalità automatica o God Mode fa attendere i futuri trigger temporali e li riprende alla scadenza o dopo.
  • La prima esecuzione ripresa riceve l'osservazione esatta della scadenza; le sessioni rimaste aperte ininterrottamente non ricevono ancora un timer del runtime in questa versione.
9.1.420
  • Un obiettivo attivo con checkpoint di attesa persistente cede il controllo dopo l'esecuzione corrente invece di assegnarne un'altra autonoma.
  • I trigger esterni, basati sul tempo, sulle dipendenze o sulle decisioni dell'utente restano salvati e vengono rivalutati all'arrivo dell'evento successivo.
  • Gli obiettivi immediati e gli obiettivi attivi più vecchi senza checkpoint vengono ripresi invariati.
9.1.419
  • Una sessione ripresa regolarmente prosegue ora un obiettivo già attivo se il suo prossimo trigger salvato è esplicitamente immediato e la modalità automatica o God Mode è attiva.
  • La ripresa resta interna, avviene al massimo una volta per sessione ripresa e non compare mai come messaggio utente inventato.
  • Gli obiettivi in attesa, in pausa o bloccati, i checkpoint mancanti e le modalità di autorizzazione manuali restano in sospeso.
9.1.418
  • Telegram conserva ora la marcatura esplicita di bot del mittente nei dati in ingresso, così che il contesto di identità possa distinguere gli agenti dalle persone.
  • Gli attori Telegram già salvati come persone vengono corretti in agenti solo se provider, soggetto e marcatura esplicita di bot coincidono.
  • I dettagli dell'attore vengono conservati, gli agenti non vengono mai declassati e nomi o nomi utente non vengono mai usati per dedurre un'identità di agente.
9.1.417
  • Le risposte sostitutive automatiche di Telegram ora dividono le risposte con più di 4.096 caratteri in messaggi consecutivi invece di troncarle.
  • Ogni carattere e ogni coppia di surrogati Unicode vengono conservati; il canale in uscita registra tutti gli ID dei messaggi restituiti insieme al testo completo.
  • Se una parte fallisce, la consegna si ferma a quel punto invece di segnalare come completa una risposta incompleta.
9.1.416
  • I nuovi risultati dell'ultimo batch di chiamate agli strumenti restano completamente leggibili fino alla prossima risposta dell'assistente, anche se in seguito vengono iniettati contesto Telegram o di controllo.
  • L'esternalizzazione dei batch, la pulizia della cronologia e la micro-compattazione usano ora lo stesso confine semantico per i risultati recenti.
  • I risultati più vecchi già valutati continuano a essere compattati normalmente, così i risparmi di contesto finora ottenuti vengono conservati.
9.1.415
  • Il focus di lavoro persistente conserva ora l'innesco esatto della prossima azione attraverso riavvii e cambi di contesto.
  • La prossima azione resta separata dalla sua condizione di autorizzazione; questo vale anche per condizioni valide con più di 512 caratteri.
  • I trigger errati o inadatti alla fase vengono respinti in modo sicuro; i checkpoint più vecchi mantengono il loro comportamento precedente.
9.1.414
  • I nuovi checkpoint di azione persistenti registrano l'innesco esatto che autorizza la prossima azione.
  • Le fasi non in attesa richiedono un trigger immediato; le fasi in attesa richiedono un evento esterno nominato, un momento preciso, una dipendenza o una decisione dell'utente.
  • Gli obiettivi in attesa restano attivi senza essere eseguiti prematuramente; i checkpoint più vecchi restano leggibili.
9.1.413
  • Le risposte Telegram che raggiungono il limite di output del modello non vengono più consegnate come inizi incompleti.
  • La stessa sessione in esecuzione produce una ripresa breve e completa e tenta al massimo tre ripristini prima di interrompersi in modo sicuro.
  • Una risposta esplicita tramite lo strumento Telegram continua ad avere la precedenza e sopprime il ripristino, così le consegne riuscite non vengono mai duplicate.
9.1.412
  • Gli obiettivi persistenti creati dal modello iniziano ora in modo atomico con la revisione 1 e un quadro del problema limitato e completo.
  • God Mode e modalità automatica proseguono un avvio di obiettivo già autorizzato senza seconda conferma; in modalità manuale l'autorizzazione resta necessaria.
  • Il lavoro autenticato e non banale su più passaggi può passare alla modalità di obiettivo persistente sotto un'istruzione autonoma esistente; i saluti, le richieste a un solo passaggio e i compiti vaghi restano esclusi.
9.1.411
  • I compiti non banali e sconosciuti possono ora salvare un quadro del problema limitato nel checkpoint di azione persistente.
  • Il quadro registra criteri di successo, conoscenze mancanti, fino a cinque azioni possibili, l'azione scelta con motivazione, la scelta del supporto, il rischio e il percorso di ripiego.
  • Il quadro del problema sopravvive a ripresa e riavvio esclusivamente come stato descrittivo e non può mai concedere autorizzazioni.
9.1.410
  • I comandi di memoria privati di Telegram limitano ora l'ambito delle relazioni alla persona interessata.
  • Il focus della memoria nasconde le relazioni di altre persone e mantiene il resto del contesto.
  • Correzioni ed eliminazioni non possono selezionare una relazione di un'altra persona; il focus dell'operatore locale conserva la vista completa.
9.1.409
  • Gli strumenti di risposta Telegram e il percorso di ripiego della TUI usano ora una directory canonica comune per lo stato del canale.
  • I valori BLUN_HOME specifici del profilo non generano più un secondo albero di directory per gli ingressi e le uscite di Telegram.
  • Un BLUN_TELEGRAM_STATE_DIR impostato esplicitamente resta determinante; in caso contrario entrambi i percorsi usano ~/.blun/channels/telegram.
9.1.408
  • I dettagli di relazione confermati vengono riuniti solo dopo due osservazioni indipendenti nei canali diretti.
  • I messaggi riprodotti nuovamente restano idempotenti; i messaggi di gruppo e le affermazioni simili ad autorizzazioni restano esclusi.
  • I ricordi di relazione privati confermati possono seguire la stessa persona tramite Telegram e CLI, senza concedere autorizzazioni.
9.1.407
  • Lo strumento di risposta Telegram importa il percorso al registro di ingresso corrente usato dal rilevamento dei duplicati.
  • Le risposte Telegram normali non falliscono più con l'errore inboxLog is not defined.
  • Il percorso di ripiego separato del bridge resta disponibile come garanzia della consegna.
9.1.406
  • I tentativi di consegna ripetuti di eventi Telegram privati con lo stesso timestamp e lo stesso testo vengono salvati una sola volta nella continuità delle relazioni.
  • Un'affermazione ripetuta effettivamente più tardi resta parte della cronologia di relazione limitata.
  • Gli avvisi espliciti di memorizzazione formulati in modo naturale alla fine della frase vengono riconosciuti come dati di riferimento, senza concedere o modificare autorizzazioni.
9.1.405
  • Il comando Telegram accoppiato /status riporta ora età e heartbeat del processo della console, il passo di lavoro corrente e il compito attivo, senza chiamare il modello.
  • L'arretrato della coda misura ora i byte non letti a partire da un checkpoint legato all'esatto file di coda corrente.
  • Lo stato remoto resta in sola lettura e non contiene ID di chat, percorsi di file, credenziali o contenuti di messaggi, né elenchi di compiti completi.
9.1.404
  • Il contenuto invariato di config.toml non sostituisce più il file privato esistente.
  • Il confronto esatto dei byte è limitato alle destinazioni regolari che non sono collegamenti simbolici.
  • Le destinazioni modificate, mancanti, non valide e non leggibili continuano a usare il percorso di scrittura atomica esistente, sicuro contro gli arresti.
9.1.403
  • La classificazione automatica degli strumenti caricabili ignora i payload di allegati e documenti incorporati.
  • Ogni frammento di intento viene limitato al budget di query ToolSearch esistente di 1.000 caratteri prima del confronto lessicale.
  • Le istruzioni vere e proprie, gli allegati e le richieste ToolSearch esplicite restano invariati.
9.1.402
  • Gli archivi scaduti della cronologia di compattazione vengono ripuliti una volta in background all'avvio di un comando King.
  • La pulizia all'avvio resta non bloccante e non può ritardare la normale elaborazione dei comandi.
  • Gli errori durante la pulizia vengono registrati in modo sicuro e non interrompono la sessione in corso.
9.1.401
  • Il primo frammento di testo di ogni risposta in esecuzione viene ora visualizzato immediatamente, invece di attendere un callback del timer.
  • Un nuovo turno e ogni nuovo segmento di risposta dell'assistente ricevono ciascuno una propria prima visualizzazione immediata.
  • I frammenti di testo, pensiero e strumenti successivi mantengono il ritmo adattivo di raggruppamento che protegge le prestazioni delle sessioni lunghe.
9.1.400
  • Le sessioni riprese di grandi dimensioni vengono ora riprodotte in modo cooperativo, così la TUI può ridisegnarsi e reagire durante il ripristino della cronologia.
  • Ogni record di riproduzione salvato in modo persistente continua a essere visualizzato; nessuna parte della cronologia viene tagliata, saltata o eliminata.
  • Le riprese piccole mantengono il comportamento precedente; quelle grandi cedono l'esecuzione all'event loop dopo ogni 30 record.
9.1.399
  • I candidati all'apprendimento verificati sono ora limitati al progetto Git corrente, invece di finire in repository non correlati.
  • I checkout HTTPS e SSH della stessa origine usano un'identità di progetto anonima comune.
  • Gli URL dei repository e i percorsi di progetto locali non vengono mai salvati nei record dei candidati all'apprendimento; il lavoro fuori da Git mantiene il comportamento esistente a livello di profilo.
9.1.398
  • Le risposte Telegram puramente testuali vengono ora deduplicate lungo il percorso degli strumenti ed entrambi i percorsi di ripiego automatici.
  • Una risposta identica o quasi identica viene soppressa solo se non è arrivato alcun messaggio più recente.
  • Gli allegati, i risultati diversi e le risposte dopo un nuovo messaggio dell'utente mantengono il comportamento precedente.
9.1.397
  • Gli obiettivi con un criterio di completamento esplicito richiedono ora, prima del completamento, un checkpoint supportato dal runtime.
  • Se la verifica di completamento fallisce, l'obiettivo resta attivo e restituisce indicazioni concrete su come correggerlo.
  • I turni ordinari e gli obiettivi senza criterio di completamento esplicito mantengono il comportamento precedente.
9.1.396
  • Le richieste naturali possono preselezionare nello stesso turno fino a due schemi di strumenti caricabili che corrispondono con alta affidabilità.
  • La selezione tiene conto esclusivamente dell'intenzione attuale nel canale e ignora il contesto Telegram superato.
  • Per le richieste deboli, ambigue o sconosciute ToolSearch resta disponibile, senza ampliare l'insieme di strumenti caricati in modo persistente.
9.1.395
  • I job multimediali accettati vengono tracciati in modo persistente, le richieste aperte identiche vengono riusate e i risultati completati vengono salvati dopo un controllo di qualità e consegnati alla chat corrispondente.
9.1.394
  • Un provider di memoria versionato e attivabile volontariamente può collegare i turni CLI e del portale con un flusso di eventi cognitivi comune.
  • L'impostazione predefinita resta l'archivio SQLite locale esistente, senza nuovi accessi di rete o comportamenti di runtime modificati.
  • I percorsi del provider, le funzioni di fabbrica sincrone e la versione 6 del contratto vengono ora verificati in modo sicuro prima dell'avvio del runtime e respinti in caso di scostamenti.
9.1.393
  • Gli avvii interattivi con king e king -c mostrano di nuovo la selezione di aggiornamento visibile 1/2/3, non appena è disponibile una versione più recente.
  • Il download degli aggiornamenti in background, l'attivazione in sospeso e il passaggio automatico ritardato sono stati rimossi.
  • Dopo un'installazione selezionata, king termina per un riavvio manuale; king -c riprende l'ultima sessione con la nuova versione.
9.1.392
  • Gli stati intermedi incompleti di una generazione di immagini non vengono più inviati come aggiornamento Telegram privato finché non è disponibile un risultato multimediale.
  • Le descrizioni di errore misurate di GenerateImage e GetMedia vengono soppresse; le consegne multimediali completate restano visibili.
  • Le conversazioni private e i risultati ordinari richiesti restano invariati.
9.1.391
  • La continuità dei ricordi tra portali richiede ora una prova esatta e attiva di collegamento dell'identità da parte del runtime attendibile.
  • Nomi simili, tenant o identità di origine diversi, emittenti errati e prove revocate restano separati tra loro e vengono respinti in modo sicuro.
  • La versione 6 del contratto dell'adattatore di memoria supporta OAuth verificato, collegamenti di account sicuri e assegnazioni di identità esplicitamente confermate, senza derivare autorizzazioni dai ricordi.
9.1.390
  • La busta di memoria condivisa registra ora separatamente il momento dell'evento e il momento dell'ingresso.
  • Ogni nuovo evento cognitivo riceve esplicitamente una classe di conservazione per dati operativi, dati persistenti, relazioni o scopi di controllo.
  • La versione 5 del contratto dell'adattatore di memoria respinge le buste di evento incomplete prima di ogni scrittura locale o remota.
9.1.389
  • Gli eventi di memoria registrano ora portale di origine e canale di origine come campi di provenienza separati e autenticati.
  • I percorsi CLI, Telegram, runtime, personalità, correzione e revoca conservano il canale esatto durante salvataggio e riproduzione.
  • La versione 4 del contratto dell'adattatore di memoria respinge le scritture se il canale di origine salvato non corrisponde al canale autorizzato dalla concessione.
9.1.388
  • Le letture di memoria restituiscono solo osservazioni dall'ambito di visibilità autorizzato dalla concessione, a meno che non venga usato il percorso dell'agente strettamente interno.
  • Le scritture, i controlli degli eventi e le operazioni di attenzione vengono respinti in modo sicuro se il loro ambito o la loro fonte autenticata non corrisponde al contesto di accesso corrente.
  • L'adattatore SQLite locale interroga le osservazioni limitate tramite un proprio indice di visibilità, invece di caricare prima i ricordi non correlati.
9.1.387
  • Ogni operazione di un adattatore di memoria trasporta ora un contesto rigoroso per identità, portale, canale, conversazione, ambito e autorizzazioni.
  • Il contesto delle autorizzazioni viene verificato al di fuori del payload di memoria e non viene conservato in modo persistente come contenuto ricordato.
  • La deduplicazione degli eventi è limitata a tenant e agente. In questo modo l'esistenza degli eventi non può essere riconosciuta tra tenant.
9.1.386
  • Lo stato cognitivo si trova ora dietro un contratto versionato per gli adattatori di memoria, usato congiuntamente dal ciclo di vita del turno e dal runtime della personalità.
  • L'archivio eventi SQLite esistente resta l'impostazione predefinita. I client esterni del portale possono fornire lo stesso contratto senza creare uno stato proprio del portale.
  • Le versioni di adattatore non supportate e le implementazioni incomplete vengono respinte in modo sicuro prima di ogni operazione di memoria.
9.1.385
  • I messaggi Telegram accodati prima dell'avvio della sessione vengono ora rilasciati non appena la sessione è pronta.
  • Le sessioni inattive svuotano la coda nel normale ordine FIFO; i turni attivi già ripresi usano un controllo limitato.
  • I checkpoint di coda persistenti restano invariati finché il messaggio non è stato effettivamente accettato.
9.1.384
  • I riferimenti alle immagini Telegram caricano ora nello stesso turno gli strumenti di controllo e generazione delle immagini.
  • I messaggi Telegram bufferizzati conservano l'intenzione multimediale per l'intero blocco in sospeso, invece di considerare solo l'ultimo messaggio.
  • I percorsi delle immagini locali e gli ID dei file Telegram scelgono il percorso di controllo o download adatto, senza caricare in modo persistente gli schemi multimediali.
9.1.383
  • I nuovi risultati di Read restano ora completamente visibili per il passo del modello che li ha richiesti, invece di essere esternalizzati prima della valutazione.
  • I nuovi risultati paralleli degli strumenti restano leggibili fino al loro passo di valutazione e possono essere archiviati solo dopo essere diventati storici.
  • L'archiviazione degli output storici e il risparmio di contesto restano attivi dopo la finestra protetta per il lavoro più recente.
9.1.382
  • Il comando /loop viene ora accettato anche mentre è in corso un'altra risposta.
  • Se un loop viene creato durante un lavoro in corso, King lo salva e accoda la sua prima istruzione senza interrompere il turno attuale.
  • La creazione di un loop in stato di inattività e il comportamento esistente per stato, pausa, ripresa e arresto restano invariati.
9.1.381
  • Dopo una ToolSearch definitivamente fallita, ToolSearch viene rimossa dall'elenco degli strumenti attivi per il resto di questo turno.
  • Il riconoscimento riuscito dello schema e la gestione degli strumenti già caricati restano disponibili e invariati.
  • In questo modo le ricerche di sinonimi ripetute non consumano più token dopo che il runtime ha già stabilito che non esiste un'integrazione adatta.
9.1.380
  • Un errore temporaneo nel controllo del turno attivo riattiva ora immediatamente il controllo di consegna di Telegram, invece di far attendere il messaggio di gruppo ripristinato fino alla fine del turno.
  • I messaggi di gruppo in sospeso continuano a essere consegnati anche durante lavori lunghi; l'ordine FIFO e il limite di quarantena esistente di tre tentativi restano conservati.
  • Nessuna sessione in corso viene interrotta o riavviata.
9.1.379
  • I nuovi tentativi temporanei di conferma di un controllo del canale non mostrano più un falso errore rosso, finché il messaggio resta recuperabile nella coda.
  • Un errore di consegna visibile compare solo dopo che il terzo tentativo fallito ha archiviato in modo sicuro la prima voce completa della coda.
  • Il comportamento per nuovi tentativi, conferma, archiviazione e ordine FIFO resta invariato.
9.1.378
  • Con pubblicazioni in background ravvicinate esiste ora un unico stato sostituibile per l'aggiornamento preparato, invece di aggiungere una nuova voce di registro per ogni versione.
  • La voce per l'aggiornamento preparato mostra sempre la versione target verificata più recente; la sessione attiva resta intatta fino al suo riavvio naturale.
  • L'avviso sull'installazione effettiva e sul changelog resta conservato in modo persistente e invariato. Il minor numero di modifiche nel registro non nasconde quindi un aggiornamento attivato.
9.1.377
  • Gli incarichi Telegram in sospeso adottano ora l'ID determinante del turno attivo dal nucleo. Uno stato TUI visibile e superato non può più far sì che un messaggio accettato resti senza conferma.
  • Il comando di controllo /loop viene eseguito immediatamente durante il lavoro in corso; la conferma persistente del comando non dipende più da una risposta di stato Telegram riuscita.
  • Se la consegna della prima voce della coda fallisce tre volte, viene archiviata localmente con tutti i metadati di ripristino prima che la coda prosegua. In questo modo una voce difettosa non blocca i messaggi successivi.
9.1.376
  • I risultati storici di grandi dimensioni degli strumenti vengono salvati in modo persistente prima della compattazione del contesto, così il loro output completo resta recuperabile anche dopo lo svuotamento dell'anteprima incorporata.
  • I riferimenti ai risultati salvati superano le micro-compattazioni successive e conservano i metadati limitati necessari per ricaricare l'output originale.
  • La telemetria dello scaricamento segnala dimensioni e stato di ripristino senza esporre contenuti dei risultati o percorsi privati.
9.1.375
  • I DM Telegram privati e i comandi slash mantengono la massima priorità di consegna. Il lavoro di gruppo esplicitamente indirizzato viene poi accodato in FIFO prima del lavoro arretrato normale o non indirizzato.
  • Un handoff di aggiornamento può attraversare una coda non vuota solo se ogni voce è lavoro Telegram persistente e non ancora confermato con percorso di ritorno Acknowledge. Il lavoro locale, misto o non persistente continua a bloccare.
  • L'avviso per gli aggiornamenti preparati segue una lingua UI della persona approvata. Per una lingua non ancora approvata come locale TUI viene mostrata solo l'informazione sulla versione, invece di ripiegare su una lingua sbagliata.
9.1.374
  • L'avviso per un aggiornamento preparato non usa più un messaggio tedesco cablato, ma la traduzione UI già approvata della lingua attiva.
  • Le modalità Riprendi e Nuova sessione restano separate; l'handoff di aggiornamento, il rollback e la conferma dei duplicati Telegram non sono stati allentati.
9.1.373
  • Un aggiornamento preparato in background può ora subentrare alla sessione in corso in un punto sicuro verificato. ID della sessione e directory di lavoro vengono conservati; strumenti in esecuzione, comandi shell, compattazione e messaggi in attesa impediscono il passaggio.
  • Il supervisore attiva il nuovo runtime solo dopo la sua prova loaded e ready. Se l'avvio fallisce, il vecchio runtime viene ripristinato con la sessione esatta e il pending difettoso viene scartato.
  • I duplicati Telegram già ripristinati nel registro di consegna vengono confermati immediatamente durante il replay della coda. Non attendono più un passo del modello che per un duplicato non parte mai di proposito e non bloccano più i messaggi di gruppo successivi.
  • Il focus di lavoro persistente trasporta ora stato della conoscenza, contesto dei riscontri, correzioni, revoche e confidenza attraverso i turni. Da questo non derivano nuovi diritti o autorizzazioni.
9.1.372
  • I checkpoint di obiettivo persistenti distinguono ora verified, credible_unverified, hypothesis, uncertain_memory, stale e unknown. Le congetture plausibili non vengono più trattate come conoscenza accertata.
  • Origine e stato della conoscenza vengono verificati insieme: i riscontri degli strumenti di runtime possono valere come verified solo dopo un'esecuzione riuscita dello strumento, i rapporti esterni no. Gli stati portati avanti conservano il loro stato precedente e il loro ultimo riscontro di verifica.
  • I vecchi stati di replay senza il nuovo campo restano leggibili come legacy_unknown. I nuovi checkpoint devono dichiarare esplicitamente il loro stato. Diritti, autorizzazioni e autorità restano invariati.
  • La proiezione di contesto ridotta nomina lo stato epistemico in una sola riga, così l'agente lo considera al passo successivo senza appesantire il budget di contesto con testo aggiuntivo.
9.1.371
  • Correzione di un errore di cablaggio della 9.1.370: il valore evidenceBasis già salvato e proiettato lì è ora parte anche dello schema di output pubblico e rigoroso di GetGoal e non va più perso al recupero.
  • Lo schema accetta i quattro tipi di origine attuali e legacy_unknown per i vecchi stati di replay. Diritti, autorizzazioni e autorità restano invariati.
  • Una prova di cablaggio mirata e un mutante dedicato proteggono la nuova connessione pubblica da regressioni.
9.1.370
  • Ogni checkpoint di lavoro recente dichiara ora esplicitamente su cosa si basa il suo ultimo stato riscontrato: chiamata riuscita di uno strumento di runtime, affermazione diretta dell'utente, rapporto esterno o prosecuzione invariata.
  • runtime_tool viene accettato solo se il turno attuale contiene almeno una chiamata di strumento consentita dal runtime e terminata con successo. carried_forward non può modificare l'ultimo stato riscontrato. In caso di contraddizione, entrambi i percorsi vengono bloccati (fail-closed).
  • I vecchi checkpoint salvati restano leggibili come legacy_unknown. Il tipo di origine è stato epistemico e non genera né diritti né autorizzazioni né autorità.
9.1.369
  • Un checkpoint di lavoro persistente riceve ora automaticamente un riscontro di runtime compatto dalle chiamate di strumento già completate dello stesso turno. Il riscontro cita solo ID del turno, numero totale, successi e fallimenti e un breve digest.
  • Nomi di strumenti, ID, argomenti, comandi, output, percorsi e testo dell'utente non vengono scritti nel checkpoint. Un riscontro vuoto resta onestamente a zero invece di simulare una misurazione.
  • Solo una chiamata di strumento autorizzata dalla policy del runtime e terminata con successo conta come successo. I riscontri bloccati, falliti, annullati o forniti dal modello non generano autorità.
9.1.368
  • Ogni checkpoint di lavoro persistente porta ora una revisione monotona. La prima scrittura inizia con la revisione 1; ogni successiva deve aumentare di esattamente uno la revisione attualmente proiettata.
  • Un vecchio turno parallelo o una vista del canale superata non può più sovrascrivere retroattivamente uno stato di lavoro riscontrato più recente. Le revisioni superate, saltate e non valide vengono bloccate (fail-closed) prima che lo stato dell'obiettivo venga modificato.
  • I checkpoint esistenti senza campo di revisione vengono trattati in modo compatibile come revisione 1 alla lettura. La revisione è stato di lavoro e non genera diritti o autorizzazioni.
9.1.367
  • Il promemoria dell'obiettivo attivo trasporta ora direttamente il checkpoint di lavoro persistente. King conserva quindi fase, ultimo stato riscontrato, esatta prossima azione e riscontro atteso anche quando l'adattatore di memoria cognitiva aggiuntivo non è disponibile.
  • Prima dei percorsi alternativi viene eseguita l'esatta prossima azione pianificata. Il checkpoint viene modificato solo quando nuove evidenze cambiano realmente lo stato confermato.
  • Il fallback è solo una proiezione compatta del checkpoint già verificato. Non genera diritti, nuovi campi di dati né riavvii.
9.1.366
  • Gli obiettivi attivi possono ora salvare un piccolo checkpoint di lavoro persistente con fase, ultimo risultato riscontrato, esatta prossima azione e riscontro atteso. Dopo ripresa o replay degli eventi, King prosegue da questo punto invece di chiedere di nuovo il permesso o ricominciare da capo.
  • Un semplice aggiornamento del checkpoint lascia l'obiettivo attivo. Gli obiettivi in pausa e bloccati restano invariati; una ripresa reimposta solo il timer di runtime.
  • Il checkpoint è rigorosamente limitato e pura informazione di lavoro. I campi sconosciuti, in particolare i dati sui diritti o sull'amministrazione, provocano un'interruzione in fail-closed e non possono creare alcuna capability.
  • Senza checkpoint il focus compatto precedente resta invariato. Con checkpoint, solo le quattro osservazioni di focus rilevanti vengono integrate con lo stato riscontrato; così il costo in token resta piccolo e costante.
9.1.365
  • I DM Telegram privati e la CLI locale possono ora leggere, correggere o eliminare direttamente il focus persistente con /memory focus, /memory correct <id> <valore> e /memory delete <id>. Il percorso non avvia un turno del modello e quindi non consuma token del modello.
  • Le modifiche Telegram sono vincolate a ID di utente, chat e messaggio positivi, a un vero DM privato, al momento del canale e a un ID di richiesta stabile. Gruppi, origine incompleta e ripetizioni modificate provocano un'interruzione in fail-closed.
  • Dominio, chiave e ambito vengono sempre derivati dal riscontro dell'obiettivo attivo e non possono essere introdotti dal chiamante. Correzioni e tombstone restano append-only, conservano la cronologia e non concedono diritti.
  • L'output del focus è limitato per Telegram a otto voci e a meno di 3.500 caratteri; il numero totale resta visibile.
9.1.364
  • Il lifecycle cognitivo in esecuzione può ora correggere un focus persistente tramite correctFocusObservation ed eliminarlo tramite withdrawFocusObservation. Entrambi i percorsi continuano a scrivere in append-only nello stesso flusso di eventi vincolato a tenant e agente.
  • Una revisione è consentita solo con l'attestazione runtime_user_prompt_hook e explicit_user_request. Uno snapshot normale del modello non può derivare né introdurre correzioni o eliminazioni.
  • Ogni revisione porta un ID di richiesta stabile e portale, attore, contesto, messaggio e momento. La ripetizione identica è idempotente; lo stesso ID di richiesta con contenuto modificato e revisioni retrodatate provocano un'interruzione in fail-closed.
  • Correzione e successiva eliminazione lasciano invariata l'intera cronologia. Dopo l'eliminazione il fatto non compare più nel prompt e non consuma token di contesto. La memoria continua a non poter concedere diritti.
9.1.363
  • Un'eliminazione confermata viene ora salvata come tombstone append-only. Il contenuto precedente resta conservato nel registro di controllo e nella catena di hash, ma scompare completamente dalla proiezione di contesto efficace.
  • I vecchi eventi di ripresa, trascrizione o coda con un momento precedente all'eliminazione non possono riattivare il contenuto rimosso. In questo modo uno stato vecchio riprodotto di nuovo in seguito non viene trattato come nuova verità.
  • L'informazione fornita di nuovo consapevolmente dopo il momento dell'eliminazione può essere riappresa. Il tombstone blocca quindi le vecchie evidenze, non l'evoluzione futura.
  • Le eliminazioni su tenant, agenti, domini, chiavi o ambiti di terzi, con destinazione mancante, confidenza debole o valore del tombstone errato vengono respinte in modo transazionale. I database esistenti migrano in place.
  • Un fatto eliminato non genera alcuna riga nel prompt e non consuma quindi token di contesto.
9.1.362
  • Una correzione confermata può ora sostituire in modo esplicito esattamente una precedente osservazione nello stesso ambito di tenant, agente, dominio, chiave e scope. La vecchia voce resta conservata in append-only nel registro di controllo.
  • La vista efficace carica il valore corretto e lo contrassegna come corrected; il valore sostituito non viene più proiettato come conflitto attuale.
  • Le destinazioni mancanti, gli scope o le chiavi di terzi e le correzioni sotto la confidenza 1 vengono respinti in modo transazionale.
  • Gli stati SQLite esistenti ricevono la nuova colonna delle relazioni all'apertura, senza perdere il loro stream o la loro versione precedenti.
9.1.361
  • Le affermazioni personali o di team ugualmente credibili con lo stesso scope e la stessa chiave non vengono più emesse come verità secondo il principio «vince il valore più recente». La proiezione contrassegna brevemente il conflitto e richiede un chiarimento, senza riversare entrambi i contenuti nel contesto.
  • Se un'affermazione è più forte di almeno 0,2 punti di confidenza, resta utilizzabile ma viene contrassegnata come controversa. Un'asserzione più debole successiva non può più nascondere uno stato confermato.
  • Le conferme identiche vengono riunite in un unico punto di focus. I campi canonici di obiettivo e avanzamento restano comunque soggetti a revisione.
  • La cronologia eventi append-only resta invariata; dalla vista efficace non possono derivare autorizzazioni.
9.1.360
  • Lo stato già canonico di /goal viene proiettato come focus di lavoro persistente nel flusso di eventi cognitivi: obiettivo, stato, prossimo innesco e riscontro di successo atteso.
  • Lo stesso focus resta idempotente attraverso i riavvii del runtime. Uno stato dell'obiettivo invariato non genera eventi o osservazioni duplicati.
  • Contatori di utilizzo, budget di tempo e autorizzazioni non vengono copiati nel focus. Senza obiettivo attivo non vengono caricati token di focus aggiuntivi.
  • La proiezione collega lo scope dell'obiettivo adatto allo scope di relazione privato del turno attuale; non genera diritti.
9.1.359
  • La memoria della personalità e i veri turni CLI usano ora lo stesso flusso di identità di tenant e agente da identity/manifest.json; senza identità completa resta disponibile il percorso di ripiego con hash compatibile.
  • I turni Telegram diretti proiettano solo l'ambito di relazione privato dell'interlocutore attuale. I gruppi e le relazioni di altre persone non forniscono token di focus privati.
  • La selezione dello scope è imposta prima del ranking; un'intuizione più recente da un altro scope non può più nascondere una voce adatta.
9.1.358
  • Un errore di rete durante la preparazione automatica dell'aggiornamento veniva segnalato solo a un callback di errore opzionale. Senza un nuovo poll, il King in esecuzione restava alla sua versione, anche se la sessione stessa continuava a funzionare regolarmente.
  • Il launcher scrive ora un evento limitato prepare-failed con la versione e nome/codice di errore sicuri in handoff.jsonl.
  • Viene quindi pianificato un nuovo tentativo di preparazione esattamente 10 secondi più tardi. Il core in esecuzione non viene né terminato né ricaricato.
  • Gli errori durante la scrittura dell'evento di diagnostica restano fail-soft; token, testo dei messaggi e altri segreti non vengono registrati.
9.1.357
  • Gli accessi ripetuti allo stesso system prompt effettivo non ricostruiscono più la grande stringa di base e allegato di runtime a ogni accesso.
  • Il resolver mantiene esattamente una combinazione corrente di base/allegato e la invalida immediatamente non appena cambia uno dei due valori di ingresso.
  • Prompt vuoto, solo base, solo allegato e la precedente separazione con due interruzioni di riga restano conservati byte per byte.
9.1.356
  • I system prompt invariati vengono contati per il budget di contesto solo una volta, carattere per carattere, attraverso passi del modello ripetuti.
  • La cache è limitata a quattro voci, al massimo 500.000 caratteri per prompt e complessivamente 1.000.000 di caratteri conservati.
  • I prompt modificati continuano a essere contati di nuovo; la visualizzazione del contesto, il budget di compattazione e il budget delle richieste usano lo stesso valore corrente.
9.1.355
  • Le configurazioni di richiesta LLM invariate non serializzano più i loro schemi di strumenti a ogni passo del modello solo per il log di configurazione.
  • Modello, alias, livello di pensiero, system prompt e sequenza degli strumenti vengono confrontati con l'ultimo stato completo.
  • Modelli, prompt, nomi di strumenti, descrizioni o schemi di parametri modificati riaprono il logging di configurazione in modo mirato.
9.1.354
  • Gli schemi di strumenti invariati vengono serializzati una sola volta per oggetto strumento e contati per il budget di contesto.
  • Un inventario con 403 strumenti non viene quindi più ricontato completamente a ogni controllo di richiesta ripetuto.
  • Le modifiche a nome, descrizione o oggetto parametri invalidano in modo mirato solo la voce di cache dello strumento interessato.
9.1.353
  • I frammenti di argomenti degli strumenti dello sciame di agenti continuano a essere parsati immediatamente e adottati nello stato di avanzamento, ma ora condividono il timer di rendering adattivo.
  • Una grande chiamata di strumento in streaming non provoca più un render TUI completo per ogni frammento di argomento.
  • Avvio, completamento, errore e annullamento rimuovono i timer di sciame aperti prima del loro render immediato finale.
9.1.352
  • I frammenti di assistente e di pensiero di uno sciame di agenti continuano ad aggiornare immediatamente lo stato di avanzamento, ma condividono un timer di rendering adattivo.
  • Una raffica di frammenti non provoca quindi più un render TUI completo per ogni delta.
  • Gli eventi di sciame discreti e la pulizia dello stato di avanzamento rimuovono i timer aperti prima del loro render di completamento immediato.
9.1.351
  • I frammenti di assistente e di pensiero nella finestra BTW/agente vengono salvati immediatamente nel turno, ma condividono un timer di rendering adattivo.
  • Il controller non richiede più un full render aggiuntivo per frammento per questi due tipi di delta.
  • Completamento, errore, nuovo tentativo e dispose rimuovono i timer aperti; gli eventi discreti di hook e completamento restano immediatamente visibili.
9.1.350
  • ToolCallComponent.appendSubToolLiveOutput adotta immediatamente i chunk di stdout e stderr nello stato di attività, ma ricostruisce la scheda del sottoagente solo al ritmo di streaming adattivo.
  • Un insieme di pending comune gestisce più subtool in esecuzione simultanea senza output persi o un timer per chunk.
  • Il completamento di uno strumento rimuove il suo refresh aperto prima della rappresentazione finale; dispose scarta timer e insieme di pending in modo pulito.
9.1.349
  • ToolCallComponent.appendSubagentText raccoglie immediatamente i frammenti di testo e pensiero che arrivano rapidamente nello stato interno, ma ricostruisce la scheda del sottoagente solo al ritmo di streaming adattivo.
  • Completamento e stato di errore svuotano un refresh di testo ancora aperto prima della rappresentazione finale; dispose scarta il timer in modo pulito.
  • In questo modo i byte in arrivo restano immediatamente disponibili, mentre i full rebuild, gli snapshot e i render ripetuti in caso di raffiche di frammenti vengono meno.
9.1.348
  • Gli argomenti in crescita dei sottoagenti/sottostrumenti continuano a essere raccolti immediatamente e completamente, ma non vengono più riparsati e renderizzati dopo ogni singolo frammento.
  • Un timer adattivo raggruppa l'aggiornamento dell'anteprima. Al completamento, gli argomenti in sospeso vengono inseriti obbligatoriamente prima dello stato finale dello strumento.
  • Esecuzione degli strumenti, autorizzazioni, argomenti finali e il normale percorso di streaming esistente restano invariati.
9.1.347
  • Il percorso degli eventi chiamava immediatamente getStreamingToolCallPreview dopo ogni delta di argomento di strumento in arrivo. Questa funzione parsa il testo JSON crescente completo fino a quel momento.
  • La chiamata avveniva anche per gli strumenti normali, sebbene solo AgentSwarm abbia bisogno dello stato intermedio parsato immediatamente per la sua visualizzazione di avanzamento in corso. Così il percorso normale aggirava in parte la cadenza di anteprima limitata introdotta in 9.1.346.
  • Una piccola policy pura decide ora prima del parse: gli strumenti normali raccolgono solo il delta e parsano al flush di anteprima pianificato; AgentSwarm continua a parsare immediatamente in base a nome dell'evento, nome dello strumento attivo o avanzamento di sciame esistente.
  • Esecuzione degli strumenti, autorizzazioni, argomenti finali e visualizzazione dello sciame restano invariati.
9.1.346
  • 9.1.345 limitava i re-render a testo completo per i lunghi stream di risposta e pensiero; gli stream di soli argomenti di strumenti non avevano però nessuna di queste due bozze di testo e restavano quindi a 50 ms fissi.
  • Ogni anteprima di strumento parsa il testo JSON crescente completo fino a quel momento. Le grandi chiamate di strumento potevano quindi continuare a riparsare e renderizzare l'intero payload molto spesso.
  • La cadenza adattiva già attestata considera ora anche il numero totale di caratteri degli argomenti di strumento attivi in streaming: 50, 100, 250 o 500 ms secondo gli stessi limiti.
  • Esecuzione degli strumenti, argomenti, autorizzazioni, anteprima finale e flush di completamento immediati restano invariati.
9.1.345
  • La TUI reimpostava finora in streaming ogni 50 ms l'intero testo di risposta e pensiero accumulato fino a quel momento. Con risposte lunghe del modello, la quantità di testo da renderizzare ripetutamente cresceva molto.
  • Gli stream brevi fino a 8.192 caratteri mantengono la cadenza reattiva precedente di 50-ms. Poi l'intervallo sale gradualmente a 100 ms fino a 32.768, 250 ms fino a 131.072 e 500 ms oltre.
  • I flush espliciti ai confini degli strumenti e alla finalizzazione restano immediati. La logica di provider, coda, sessione e token non è stata modificata.
9.1.344
  • Il livello di runtime cognitivo scriveva finora policy e risultato per ogni chiamata di strumento in due transazioni SQLite sincrone separate.
  • Una prova dei costi isolata su Windows con 100 chiamate di strumento richiedeva per questo 627,63 ms e generava 201 eventi. Il contenuto comprendeva 305 osservazioni.
  • Le coppie policy/risultato completate di un passo del modello vengono ora registrate in modo atomico in gruppi limitati di al massimo dieci strumenti. Le verifiche di policy interrotte o ancora aperte continuano a essere salvate singolarmente alla fine del turno.
  • Argomenti, output, decisione sui diritti, catena di hash e persistenza SQLite restano invariati.
9.1.343
  • Una risposta Telegram privata era già stata consegnata con successo con lo strumento di risposta. Nonostante questo, lo stesso turno del modello avviava ancora un ulteriore passo e generava testo interno di stato e di controllo del lavoro.
  • Nella sessione reale misurata il passo aggiuntivo è costato 42.360 token di input e 411 token di output, anche se la risposta visibile all'utente era già stata inviata.
  • Una risposta Telegram riuscita termina ora immediatamente un turno di conversazione privato contrassegnato come direct. Le risposte fallite, i gruppi e gli altri strumenti continuano a funzionare come prima.
  • Dopo la conclusione continua ad agire il controller di focus diretto esistente: registra la risposta consegnata e torna al lavoro in background salvato dopo la fine della conversazione o il periodo di inattività.
9.1.342
  • La query di rilevanza per Mistake.md includeva finora ogni messaggio con ruolo user. Tra questi c'erano anche iniezioni interne, riassunti di compattazione, attivazioni di skill e segnalazioni di background.
  • Poiché il promemoria di Mistake stesso viene salvato come messaggio user interno, dopo ogni passo di strumento modificava la propria query di ricerca. In questo modo veniva selezionato e iniettato di nuovo nello stesso turno.
  • Il filtro usa ora solo gli input utente e cron rilevanti per l'azione. I testi di runtime interni vengono esclusi dalla query di rilevanza e dal riconoscimento a bassa informazione.
  • I veri messaggi dell'utente, il lavoro pianificato, tutte le lezioni verificate e la ricostruzione dopo la compattazione restano disponibili invariati.
9.1.341
  • All'avvio naturale il launcher trovava un runtime automatico già preparato e verificato localmente, ma lo faceva comunque passare prima dall'avviso di aggiornamento dipendente dalla rete. Se questo secondo recupero falliva temporaneamente, veniva avviata di nuovo la vecchia versione globale.
  • Un runtime automatico preparato con modalità esattamente corrispondente (resume o new) viene ora avviato prima del nuovo recupero della versione. L'attivazione resta transazionale: solo quando il nuovo core è stato caricato con successo, il runtime viene registrato come attivo.
  • In resume restano conservati ID della sessione e directory di lavoro. La selezione manuale dell'aggiornamento continua a passare dal percorso di avviso precedente.
  • Nessun King in esecuzione viene terminato. Il fix agisce esclusivamente al prossimo avvio naturale.
9.1.340
  • Il launcher scriveva gli aggiornamenti riusciti in .blun/updates/install.json, mentre un runtime di profilo cercava in .blun/profile/<name>/updates/install.json. Il vero percorso di profilo non esisteva; per questo notifiedAt restava null nello stato comune.
  • I runtime di profilo leggono ora il successo dell'aggiornamento da BLUN_SHARED_HOME e ricadono sul BLUN_HOME precedente solo senza percorso comune.
  • Dopo il prossimo avvio naturale la TUI può mostrare una volta la versione e fino a tre avvisi di versione. I destinatari Telegram privati configurati ricevono lo stesso testo breve senza turno del modello e senza consumo di token.
  • Installazione, staging, attivazione e la regola di non espellere mai restano invariati.
9.1.339
  • I passi successivi di strumento riusciti con Low Effort usano al massimo 4.096 token di completamento invece dei precedenti 8.192.
  • I primi passi, i compiti complessi e i passi successivi con errori mantengono la loro capacità di pensiero e di output configurata. L'intervento non è un limite globale del modello o del contesto.
  • La misurazione a posteriori su 1.442 passi reali a Low Effort di un profilo agente ha dato: 2.118.588 token di output in totale, mediana 791, p90 3.754, p95 5.485. Con il nuovo limite sarebbero venuti meno 229.761 token, ossia 10,8 Prozent; il 91,1 Prozent dei passi misurati resta invariato.
9.1.338
  • Le semplici domande ripetute come Posso continuare con il mio lavoro? non vengono più consegnate nelle conversazioni Telegram private.
  • La narrazione interna di coda, handoff, lane e stato di attesa resta fuori dalla risposta privata. I veri risultati di lavoro e le normali risposte personali restano consegnabili.
  • Se una risposta utilizzabile termina solo con una nuova domanda di autorizzazione al lavoro, viene rimossa esclusivamente questa domanda finale.
  • Il routing dei gruppi e le sessioni in corso restano invariati.
9.1.337
  • profile/<name>/SOUL.md è il percorso di identità canonico di un King.
  • Un'anima legacy con nome corrispondente sostituisce solo uno scheletro di profilo generato e invariato. Le anime di profilo sviluppate non vengono mai sovrascritte.
  • Prima di un import legacy, lo scheletro generato viene salvato come SOUL.md.pre-legacy-import.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • Le sessioni interrotte normalizzano il loro stato di replay prima che venga consegnato altro lavoro Telegram.
  • Se la consegna a un turno attivo viene rifiutata, il messaggio ricade su un nuovo turno in coda, invece di ritentare lo stesso steer ogni 5 secondi.
  • I checkpoint di focus DM conservano i timer di ripresa automatici e le pause esplicite anche dopo gli aggiornamenti.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Un normale messaggio Telegram privato interrompe l'incarico in corso solo per la durata della conversazione in sé. Al termine, dopo 60 secondi, King riprende automaticamente dal punto di lavoro salvato con esattezza, senza chiedere di nuovo il permesso.
  • Se la conversazione viene chiusa esplicitamente, l'incarico riprende subito. Solo richieste esplicite dell'utente come pause, pausiere, stop, stopp, warte o halte an tengono fermo l'incarico finché l'utente non lo autorizza di nuovo.
  • I termini interni e i rapporti di stato su cron, checkpoint, coda o lane vengono soppressi nelle normali risposte private. Il lavoro vero e proprio e il suo stato salvato restano invariati.
9.1.334
  • La preparazione automatica in background non resta più bloccata quando le versioni si susseguono rapidamente. Il precedente blocco di 30 minuti si riferiva sempre alla versione più recente del momento; con una nuova versione ogni minuto, nessuna versione diventava quindi mai abbastanza vecchia da essere preparata.
  • Una versione crittograficamente corrispondente viene ora caricata subito, sottoposta a verifica di integrità, installata in isolamento, sondata sintatticamente e registrata come runtime in attesa.
  • La sessione King in corso continua a non essere terminata. Attivazione e ripresa restano esclusivamente sul percorso protetto di avvio successivo esistente. Questa versione non modifica né la logica di handoff né quella di sessione.
9.1.333
  • Uno screenshot live attestava dopo 9.1.331 un ERR_MODULE_NOT_FOUND nel plugin Telegram gestito.
  • L'import del plugin puntava dall'albero gestito isolato a un file del core che non era stato installato lì.
  • L'enorme testo di ripetizione, anch'esso misurato, scorreva nel flusso di pensiero visibile. La barriera di ripetizione live esistente controllava finora solo i delta di risposta.
  • 9.1.332 non è stato portato nel manifest pubblico dopo il riscontro sul plugin. 9.1.333 sostituisce completamente questo candidato npm.
9.1.332 Non pubblicata
  • Non pubblicata. Un import del plugin puntava dall'albero isolato a un file del core non incluso nel pacchetto; 9.1.333 ha sostituito completamente il candidato npm.
9.1.331
  • Le conversazioni Telegram private conservano le risposte naturali e i risultati di lavoro richiesti.
  • Le segnalazioni interne duplicate misurate su lavori in pausa, risposte già inviate, turni in corso, stato degli strumenti e assenza di necessità di intervento vengono soppresse solo nelle chat private.
  • Un messaggio viene filtrato solo se contiene sia contesto di runtime interno sia esplicitamente nessun nuovo valore per l'utente.
  • Il routing dei gruppi, le vere segnalazioni di completamento e la normale conversazione breve restano invariati.
9.1.330
  • Il file sorgente completo dell'anima di ogni King resta conservato invariato.
  • Il contesto del modello riceve da esso una proiezione di carattere limitata con identità, voce, valori, relazioni, preferenze, obiettivi e storia maturata.
  • Le sezioni chiare su incarico, lane, diritti, QA, strumenti, comandi, verifica, incidenti, log, runtime, aggiornamento, deploy e build non vengono più caricate come personalità in ogni prompt.
  • Le anime brevi, composte solo dal carattere, restano identiche byte per byte. Le sezioni non tecniche sconosciute restano visibili nel loro ordine.
  • Nessun file dell'anima viene eliminato, accorciato o riscritto automaticamente.
9.1.329
  • Ogni profilo King denominato usa nel nucleo di identità comune il proprio nodo agente. Relazioni, cronologia e dati personali appresi non confluiscono più nell'agente configurato per primo.
  • I file dell'anima denominati esistenti come _agent-a_soul.md, _agent-b_soul.md o _agent-c_soul.md vengono assegnati al profilo corrispondente e trasferiti una sola volta, identici byte per byte, in SOUL.md.
  • Il vecchio file sorgente resta conservato invariato. Un SOUL.md di profilo esistente non viene mai sovrascritto.
  • La selezione della persona e la modalità di personalità leggono in base al profilo. Una persona di profilo danneggiata, troppo grande o collegata tramite link non ricade silenziosamente sull'identità di un altro agente.
  • Il nucleo comune resta utilizzabile senza obbligo di Mnemo. Gli incarichi in corso, i diritti e le regole QA non vengono modificati da questa migrazione.
9.1.328
  • Persona e SOUL.md vengono caricati prima dal profilo attivo.
  • I profili denominati non ereditano mai l'anima di un altro agente dalla home comune.
  • I profili legacy e predefiniti mantengono il fallback comune precedente.
  • Se manca davvero un proprio file dell'anima, viene creato una volta uno scheletro minimo; i file esistenti non vengono mai sovrascritti.
  • Il sistema di identità e relazioni resta basato su file e funziona senza obbligo di Mnemo.
9.1.327
  • Le conversazioni Telegram private restano incentrate sulla persona: i rapporti interni di coda, checkpoint, pausa, cron, hook e inattività vengono soppressi su entrambi i percorsi di invio, finché non viene richiesto uno stato di lavoro, non serve una decisione e non è sorto un blocco rilevante.
  • Gli stati di lavoro tecnici vanno al canale di team competente. Non vengono copiati una seconda volta nella conversazione privata.
  • I loop di ripetizione esatti del modello vengono riconosciuti già durante lo streaming. Il flusso del provider in corso viene terminato e lo stesso passo viene ritentato esattamente una volta con il contesto dell'incarico conservato.
  • Anima, conoscenza delle persone, diritti, incarichi in corso e pausa di focus diretto esistente non sono stati sostituiti o eliminati. Nessuna TUI in esecuzione è stata riavviata.
9.1.326
  • Le modalità di autorizzazione manuali e automatiche rispecchiano le approvazioni degli strumenti come pulsanti limitati nel DM Telegram privato accoppiato in modo univoco.
  • Vengono trasmessi solo il nome dello strumento e i testi di selezione esistenti; argomenti, descrizioni e segreti restano locali. Le approvazioni scadute, di terzi o a cui è già stata data risposta localmente vengono scartate in fail-closed.
  • God Mode resta completamente autonomo e non genera alcuna approvazione Telegram.
  • Gli stati di lavoro tecnici vengono instradati al collega competente e non più ricopiati nella conversazione privata dell'utente.
9.1.325
  • God Mode esegue le scritture personali in memoria senza una seconda richiesta di approvazione; il consenso esistente legato a sessione e turno resta conservato.
  • Un'istruzione Telegram esplicita di ricordare attiva lo stesso consenso strettamente limitato di un'istruzione diretta dalla console. Le modalità di autorizzazione manuali e automatiche continuano a chiedere prima di scrivere.
  • Il journal degli aggiornamenti salva se un'installazione è stata avviata manualmente, automaticamente o tramite la finestra di avvio.
9.1.324
  • La prima interazione attendibile con un bot lo crea localmente come nodo di agente e relazione. Ruolo, responsabilità, peculiarità, collaborazione e handoff possono poi crescere in modo strutturato.
  • Ogni King proietta un estratto compatto dei colleghi nel suo contesto. Così conosce compiti e peculiarità degli altri agenti senza caricare in blocco l'intero patrimonio di relazioni.
  • Se manca un'informazione critica per l'incarico, non si tira a indovinare: il King chiede esattamente una volta alla persona o all'agente più adatto. Se non è nota alcuna responsabilità, chiede all'utente invece di inventare un nome.
  • Relazioni e ruoli non generano mai diritti. I campi di autorizzazione, ACL e segreti non vengono proiettati nell'estratto dei colleghi. Il percorso è locale, legato al tenant, neutrale rispetto ai nomi, indipendente da Mnemo e non aggiunge né chiamate al modello né agli strumenti.
9.1.323
  • Le conversazioni private rispondono di nuovo alla persona invece di emettere volontariamente dati di processo interni. Checkpoint, hash, percorsi, diagnostiche di tool, cron e hook, regole nascoste, incarichi di altri agenti e rapporti di inattività restano interni.
  • Lo stato del lavoro viene menzionato solo se l'utente lo chiede, se serve la sua decisione o se un blocco lo riguarda concretamente. Il lavoro in pausa resta interno e non viene portato in una conversazione informale.
  • La regola vale con e senza modalità di personalità, non contiene persone o agenti codificati in modo fisso e aggiunge circa 75 token di prompt, ma nessuna chiamata al modello o agli strumenti. Priorità dei compiti e obbligo di riscontro restano invariati.
9.1.322
  • L'interruttore visibile della personalità scrive ora persona.json in modo atomico. Nome, lingua, note e tutti gli altri campi persona esistenti restano conservati; viene modificato solo personalityEnabled.
  • SOUL.md, AGENTS.md, JOURNAL.md e i file delle relazioni non vengono scritti né allo spegnimento né all'accensione. La normale identità di agente basata su SOUL resta caricata nel contesto di sistema anche con la funzione di personalità disattivata.
  • Un refresh live fallito ripristina la selezione byte per byte. Se nel frattempo un altro processo di scrittura ha modificato persona.json, il ripristino si interrompe con PERSONALITY_CHOICE_CONFLICT e non sovrascrive nulla.
  • I file persona con symlink, sovradimensionati, non validi o non a forma di oggetto vengono respinti in fail-closed. All'accensione, l'albero di identità viene preparato prima del commit.
  • Non fa parte di questa versione l'errore di un agente attestato poi, ovvero riportare checkpoint interni, regole cron, SHA e dettagli di incarichi altrui nelle conversazioni private. Questo filtro di output è il prossimo sviluppo separato.
9.1.321
  • Uno scambio privato iniziale rilassato o un accenno personale volontario può inserire esattamente un'opportunità di curiosità opzionale nel contesto del modello. Non è una domanda obbligatoria; scelta delle parole e tono provengono ancora dal SOUL.md caricato, non da un catalogo fisso di domande.
  • Incarico, urgenza, errori, link, codice, percorsi e traffico di gruppo sopprimono completamente la curiosità. Non invia mai da sola e non può interrompere il lavoro in corso.
  • Un cooldown di 30 giorni vale per tenant, agente e persona collegata anche attraverso portali diversi. Un nuovo tentativo per lo stesso evento è idempotente.
  • Il nuovo stato non risiede più come file di curiosità specifico di Telegram nell'albero di identità. Un personality-memory-adapter sostituibile scrive invece un evento versionato nello store cognitivo transazionale esistente. Telegram è l'origine; la relazione privata è uno scope di visibilità separato.
  • Vengono salvati solo tema, identificativo stabile di evento/fonte, momento e scope privato. Testo grezzo, domande fisse, asserzioni di diritti e segreti non vengono inclusi. Root non sicuri, campi estranei e guasto dello store restano in fail-closed.
  • Il confine tra portali si basava sul documento concettuale interno v7. La CLI è il client di riferimento; lo store locale è esplicitamente contrassegnato come proiezione sostituibile e non come secondo archivio portale canonico.
9.1.320
  • I fili di conversazione aperti, privati ed espliciti, vengono salvati come eventi immutabili e deduplicati con fonte, momento, contesto e confidenza. Formulazioni naturali come Frag mich morgen noch einmal nach ... vengono riconosciute al pari della forma esplicita di thread aperto.
  • Le note di riparazione esplicite vengono salvate separatamente dalle note di relazione generali e considerate nel comportamento successivo.
  • Il turno attuale non vede ancora di proposito la propria nuova nota. Solo un turno privato successivo riceve il contesto limitato; in questo modo non esiste alcuna auto-conferma doppia o suggestiva.
  • Incarico e istruzioni esplicite vengono prima del contesto sociale. I fili aperti non possono interrompere il lavoro attivo e non inviano mai da soli. I dati delle relazioni non possono generare diritti, approvazioni o autorizzazioni.
  • Traffico di gruppo, segreti, formulazioni di autorizzazione, percorsi non sicuri, symlink e file sovradimensionati restano esclusi in fail-closed.
9.1.319
  • Un profilo esistente valido senza valore personalityEnabled salvato attiva ora automaticamente la personalità.
  • Al primo prompt normale nasce l'albero di identità locale con profilo agente e JOURNAL.md, anche senza Mnemo.
  • Un false, 0 o off esplicito resta spento. I file persona danneggiati, collegati simbolicamente e troppo grandi restano in fail-closed.
  • SOUL.md e AGENTS.md non vengono né eliminati né riscritti.
9.1.318
  • L'updater di background carica in modo vincolante la versione più recente, ne verifica l'integrità SHA-512 pubblicata in modo indipendente e la prenota per il prossimo avvio.
  • Il King in esecuzione, il suo turno e le sue chiamate agli strumenti restano intoccati. Non esistono più handoff live, ACK o tui.stop(76).
  • ID della sessione e directory di lavoro vengono salvati con il runtime preparato. Solo al prossimo avvio naturale la nuova versione viene attivata e la sessione esatta ripresa automaticamente.
  • La TUI in esecuzione riceve al massimo una segnalazione di completamento passiva; una versione preparata più recente sostituisce solo la prenotazione, mai il processo attivo.
9.1.317
  • Se il provider consuma l'intero budget di risposta con una chiusura length ma non fornisce testo visibile, il budget dei nuovi tentativi non viene più ridotto a un ottavo, ma raddoppiato.
  • Il nuovo tentativo resta nello stesso turno e usa lo stesso segnale, la stessa cronologia dei messaggi e la stessa situazione di lavoro.
  • La gestione degli annullamenti esistente e il numero limitato di nuovi tentativi restano invariati. Gli annullamenti manuali o i risultati persistentemente vuoti non continuano all'infinito.
9.1.316
  • I DM Telegram privati ricevono una propria corsia di coda diretta prima del lavoro di gruppo, loop e background; un /urgent esplicito resta comunque la priorità massima.
  • All'inizio della conversazione DM, lo stato di lavoro in corso viene salvato una volta come checkpoint limitato. Il testo dei messaggi non viene salvato in modo persistente.
  • Dopo una fine di conversazione riconosciuta o un minuto di silenzio, King chiede esattamente una volta: Posso continuare con il mio lavoro?
  • Il lavoro salvato resta in pausa e viene ripreso dal checkpoint originale solo dopo un consenso inequivocabile.
  • La versione introduce il controllo di consegna e pausa. Il sistema completo di personalità, relazioni e journal resta uno sviluppo separato e in corso.
9.1.315
  • I segnali di attenzione autorizzati arrivano ora nel turno attraverso la normale coda del canale, senza aggirare la politica di consegna o di diritti esistente.
  • I segnali doppi, superati, non autorizzati, fuori scope e non provenienti da Telegram vengono scartati prima del contesto del modello.
  • Le richieste di chiarimento restano limitate al massimo a una domanda naturale, vengono deduplicate e tacciono quando il segnale non è più attuale.
  • La versione introduce solo il percorso di consegna sicuro. La logica di interruzione e ripresa dei DM, a cui è stata poi data priorità, resta deliberatamente riservata alla prossima versione separata.
9.1.314
  • I comandi slash locali non aspettano più per ore in coda durante un turno attivo lungo, ma interrompono il turno in modo controllato e vengono eseguiti come passo di lavoro successivo.
  • Un nuovo comando slash sostituisce in console e Telegram un comando dello stesso tipo già in attesa. Questo vale tra l'altro per /reload e /loop; i messaggi normali, il lavoro shell e gli altri incarichi di canale restano conservati.
  • Escape rimuove i comandi slash in attesa anche quando non è più visibile alcun turno attivo. La compatibilità di reload esistente resta conservata come wrapper sulla policy di coda generale.
9.1.313
  • Un aggiornamento automatico riuscito viene scritto dopo il replay della sessione come avviso persistente nel transcript della TUI. Il messaggio non può più essere sovrascritto da un replay o da uno stato di breve durata.
  • La stessa versione di origine, la stessa versione di destinazione e le stesse note di versione vengono inviate una volta ai DM Telegram accoppiati attraverso il percorso esistente deduplicato per versione. Un invio fallito resta ripetibile.
  • Il manifest pubblico contiene ora i campi name e releaseNotes attesi dal parser di fallback. Non è stato modificato nulla nell'handoff dell'updater, nel riavvio della sessione e nei processi in esecuzione.
9.1.312
  • Un /reload Telegram esplicito non attende più dietro un turno del modello lungo. Viene inserito come comando di controllo davanti alla coda esistente e innesca esattamente una volta l'interruzione controllata di sessione esistente.
  • L'handler di reload esistente viene eseguito solo dopo la fine confermata del turno. Così nessun secondo turno parte in parallelo e un turno in scrittura non viene ulteriormente elaborato nel mezzo della logica di reload.
  • I vecchi duplicati di reload vengono rimossi; i messaggi Telegram normali e gli altri lavori in coda restano conservati nel loro ordine. La ricevuta Telegram resta aperta fino alla reale esecuzione del comando.
9.1.311
  • Un candidato di attenzione diventa un incarico di consegna limitato solo quando è presente una ricevuta di runtime recente, legata esattamente al suo ID candidato.
  • Solo runtime_user_prompt_hook e runtime_tool_policy valgono come autorità. Memory, agente errato, canale errato, scope errato, decisione di blocco, ricevuta futura e ricevute più vecchie di 5 minuti falliscono in fail-closed.
  • Le ricevute sono legate al tenant, transazionali e utilizzabili una sola volta. Lo stesso nuovo tentativo è idempotente; l'uso della stessa ricevuta per un altro candidato viene respinto come replay.
  • Il cooldown comune esistente resta efficace. Il risultato è solo un intent strutturato attention_notice e non contiene testo di messaggio, funzione di invio né autorizzazione. La politica di consegna vera e propria resta il prossimo passo separato.
9.1.310
  • Obiettivi persistenti, fili aperti, prossimi inneschi, riscontri attesi, contesto di team e contesto di sé passano attraverso una proiezione di focus comune, rigidamente limitata. Per impostazione predefinita sono consentite al massimo sei voci e 900 caratteri.
  • Progetto e ambito di lavoro hanno un peso maggiore di confidenza e attualità. Viene mostrato il valore più recente, senza cancellare precedenti osservazioni contraddittorie dalla cronologia immutabile degli eventi. Le modifiche diventano visibili come revised.
  • Le osservazioni di runtime di breve durata, le evidenze deboli e i fatti generali sul mondo non consumano budget di focus persistente. I campi di diritti, token e segreti vengono respinti già in scrittura.
  • Uno snapshot strutturato e idempotente può aggiornare il focus da una sessione all'altra. La proiezione è contesto, non autorizzazione, e non può sovrascrivere incarico o policy di runtime.
  • Da ECC è stato adottato solo il principio Kontext begrenzen, Relevantes laden. Non è stato installato alcun hook ECC, memoria di apprendimento o harness.
9.1.309
  • La nuova policy di attenzione pura genera un candidato limitato solo da heartbeat di agenti mancanti comprovati, promesse scadute o compiti bloccati da più tempo.
  • Competenza, compito attivo, assenza comprovata, periodo di quiete locale, canale consentito, confidenza minima e cooldown vengono verificati prima dell'accettazione. Il silenzio umano senza promessa scaduta resta senza effetto.
  • Ogni candidato porta ID dell'evidenza, ambito di validità, momento e confidenza, ma non il contenuto del prompt né diritti, segreti o funzione di invio.
  • Il nucleo SQLite comune assegna un claim transazionale per tenant ed evidenza. Gli agenti paralleli non possono prendere in carico due volte lo stesso evento durante il cooldown.
  • Questa versione non scansiona ancora autonomamente e non invia alcun messaggio. Ogni azione successiva continua a richiedere la normale autorizzazione del runtime.
9.1.308
  • Il record di runtime preparato contiene ora in modalità resume l'ID esatto della sessione in esecuzione e la directory di lavoro verificata in modo canonico. Un avvio successivo non deve più indovinare la sessione più recente o una presumibilmente adatta.
  • Ogni vero cambio di sessione aggiorna questi dati. Immediatamente prima dell'handoff sicuro vengono scritti ancora una volta, prima che il vecchio runtime riceva la conferma di terminare.
  • Solo la sessione esattamente identica, ripresa in modo comprovato attraverso questo percorso di aggiornamento, riceve dopo il replay un unico impulso di ripresa, e solo se il suo obiettivo è ancora active. Gli avvii normali, le altre sessioni e gli obiettivi in pausa o bloccati restano intoccati.
  • Il confine di lavoro sicuro resta invariato: nessun handoff durante streaming, compattazione, strumenti, comandi shell o messaggi in attesa. Nessun King in esecuzione è stato riavviato manualmente per questa versione.
9.1.307
  • Solo un errore realmente rilevante per l'azione del turno di runtime immediatamente precedente viene mostrato prima della prossima decisione del modello come breve prova di continuità: turno interrotto o fallito, policy bloccata o strumento fallito.
  • Un turno concluso normalmente non genera esattamente alcuna proiezione e quindi zero token di contesto aggiuntivi.
  • La selezione è legata a ID runtime più ID turno e resta quindi corretta anche dopo un cambio di sessione con ID turno che ricominciano da zero.
  • La proiezione non contiene prompt, argomenti, output, ID di chiamata o diritti. Indica esplicitamente che non può mai autorizzare un'azione né sovrascrivere la policy utente o degli strumenti attuale.
  • La tappa è deliberatamente reattiva e ristretta. L'attenzione proattiva, lo stato di delega e i fili aperti con contenuto non vengono ancora caricati qui.
9.1.306
  • La traccia cognitiva del ciclo di vita del turno registra ora per ogni vera chiamata di strumento la decisione reale del runtime da PermissionManager.beforeToolCall: passed, blocked o error.
  • Dopo l'esecuzione vengono aggiunti come prova immutabile il risultato reale (success, error, cancelled), la durata e il prossimo innesco di controllo.
  • Vengono salvati solo il nome dello strumento e un hash stabile della chiave di chiamata. Argomenti, output degli strumenti e contenuti del prompt non finiscono nello stato cognitivo.
  • La gerarchia dei diritti esistente resta invariata: Memory non può autorizzare alcuna azione. Gli errori di registrazione restano fail-soft e non possono né consentire un'esecuzione di strumento né bloccare un turno utente.
  • Restano aperti i riscontri di delega, l'attenzione proattiva e la retroproiezione strettamente rilevante dello stato nelle decisioni successive.
9.1.305
  • Il nucleo SQLite transazionale introdotto in 9.1.304 è ora collegato al vero ciclo di vita runOneTurn(). Ogni turno del modello registra percezione, classificazione dell'origine, piano di turno limitato, riscontro finale atteso, risultato del controllo del prompt, motivo di chiusura, durata e prossimo innesco.
  • Vengono salvati solo metadati di runtime, nessun contenuto di prompt. Tenant e agente vengono derivati in modo stabile da BLUN-Home e profilo attivo, senza elenchi fissi di persone.
  • Solo la policy di runtime esistente può fornire un risultato di controllo. Memory è rigidamente esclusa come autorità sui diritti. La registrazione non restituisce mai un'autorizzazione e continua a non possedere alcuna funzione di esecuzione.
  • La traccia di apprendimento è fail-soft: un errore SQLite o del ciclo di vita viene registrato solo come telemetria senza contenuto e non può bloccare il vero turno utente.
  • Restano aperti i riscontri di azione e delega specifici degli strumenti, l'attenzione proattiva e la retroproiezione rilevante dello stato nelle decisioni successive. 9.1.305 non rivendica quindi un ciclo AGI completo.
9.1.304
  • Il primo nucleo transazionale di stato cognitivo si trova come database SQLite locale sotto la BLUN-Home. Può salvare osservazioni di sé, del mondo e del team, obiettivi, fili aperti, assunzioni, prossimi inneschi e riscontri attesi attraverso le sessioni.
  • Più scrittori di agenti e canali vengono serializzati con BEGIN IMMEDIATE e numero di versione ottimistico. Gli scrittori superati falliscono in fail-closed; le ripetizioni identiche di eventi sono idempotenti.
  • Ogni evento è concatenato con SHA-256. Le affermazioni portano fonte, contesto, momento, grado di certezza e ambito di validità. Le contraddizioni restano osservazioni immutabili separate, invece di sovrascrivere vecchie affermazioni.
  • I campi di diritti, capability e segreti vengono respinti. Il nucleo non possiede alcuna funzione di esecuzione, delega o autorizzazione.
  • Questa è la base di memoria comprovata, non ancora il ciclo completo percepire-pianificare-agire e non ancora collegata a ogni turno.
9.1.303
  • Un candidato di relazione privata registrato in modo sicuro in 9.1.302 viene caricato dalla prossima conversazione diretta come contesto di memoria chiaramente non autoritativo. L'affermazione attuale continua a non influenzare il proprio turno.
  • Vengono caricate al massimo le due note validate più recenti, ciascuna di massimo 160 caratteri, entro il budget totale invariato di 1.500 caratteri. Se non ci sono note, si aggiungono 0 caratteri di prompt e non avviene alcuna chiamata a modello, embedding o rete.
  • Le note private non vengono mai caricate nei gruppi. Il confine di sistema le definisce esplicitamente come dati di riferimento invece che istruzioni e ripete che non possono concedere o modificare diritti.
  • Restano aperti l'adozione persistente automatica, la valutazione dei conflitti, la memoria multi-agente transazionale e l'attenzione proattiva.
9.1.302
  • Un'affermazione privata esplicita come Bitte merk dir: ... o Please remember that ... genera ora un piccolo candidato di relazione, non ancora attivo. Per questo non c'è alcuna chiamata aggiuntiva a modello, embedding o rete.
  • Ogni candidato porta fonte, contesto di canale/diretto, momento, grado di certezza, ambito di validità e la regola immutabile della cronologia. Lo stesso processo di canale consegnato è idempotente; le conferme e le contraddizioni successive restano visibili come voci separate e non si sovrascrivono.
  • Gruppi, frasi di conversazione normali, segreti, affermazioni di diritti e autorizzazioni, identità di tenant o agente non valide e percorsi non sicuri vengono respinti. I dati di relazione continuano a non poter generare alcun diritto.
  • Questo è solo il primo passo di rilevamento sicuro per l'obiettivo di prodotto. I candidati restano pending e non vengono ancora adottati automaticamente nella relazione attiva o nel contesto del modello. Il nucleo multi-agente transazionale, lo stato cognitivo, l'iniziativa propria e l'attenzione proattiva non sono quindi esplicitamente ancora pronti.
9.1.301
  • Il blocco di presenza della personalità caricato in modo persistente è sceso da 1.433 a 1.020 caratteri, in termini di calcolo circa 104 token di prompt in meno per ogni turno di personalità attivo. Nessuna ulteriore chiamata a modello o memoria è stata aggiunta.
  • Il focus dei compiti, l'anima caricata, la curiosità limitata, la protezione dei gruppi, la memoria incerta, i fili aperti e la riparazione delle relazioni restano nel piccolo blocco. La modalità senza personalità è rimasta byte per byte identica a 288 caratteri.
  • Prova in rosso: il nuovo controllo da 1.050 caratteri falliva a 1.433 caratteri. Prova di mutazione senza blocco di personalità: 12/18 test mirati in rosso. Ripristinato: mirati 18/18, suite completa 690/690 verde.
  • Controllo di regressione del pacchetto 9.1.300 su 9.1.301: 164 contro 164 percorsi stabili, 0 rimossi. Installazione nuova: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Un server MCP fallito all'avvio riceve ora fino a tre ulteriori tentativi di connessione a 10 secondi di distanza l'uno dall'altro. In questo modo, dopo un errore di avvio temporaneo, il server non viene più abbandonato dopo un solo tentativo.
  • L'inventario MCP non viene più registrato una sola volta, ma di nuovo quando cambia il numero dei server o degli strumenti collegati. Un recupero tardivo sostituisce quindi visibilmente il vecchio stato 0/0.
  • Le configurazioni MCP esistenti, le definizioni degli strumenti e le sessioni in corso restano invariate. Sono stati adattati blun.mjs, test/mcp-runtime-resilience.test.js, package.json e package-lock.json.
9.1.299
  • I grandi risultati di Read restano nativamente rileggibili: l'output visibile è limitato a 10 KiB e indica poi l'esatta riga successiva invece di mostrare solo [offloaded].
  • I grandi incarichi di Write plain e i file sorgente oltre 500 righe vengono suddivisi automaticamente in frammenti byte-esatti, composti in un file adiacente privato e scritti atomicamente sul percorso di destinazione.
  • Dopo la composizione, il runtime verifica i byte persistiti tramite SHA256. La protezione Edit esistente resta invariata; la continuazione manuale rimane possibile, ma non è più necessaria per le grandi scritture complete.
  • Nuovo: bin/native-large-file-io.cjs. Adattati: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, quattro file di test mirati e package.json e package-lock.json.
9.1.298
  • Quando è attiva, la modalità di personalità crea autonomamente, al primo turno TUI normale, un'area di identità locale multi-tenant. Mnemo non è necessario per questo.
  • Il SOUL.md e l'AGENTS.md esistenti restano caricati e invariati. Un nuovo JOURNAL.md nasce una sola volta e non sostituisce né anima né regole.
  • Le nuove identità Telegram ricevono nodi prudenti di persona, relazione e gruppo senza proprietà inventate. La cronologia privata e il contesto di gruppo restano separati.
  • La continuità di relazione diretta salva al massimo sei voci brevi, oscurate localmente, e restituisce al massimo due estratti precedenti al turno attuale. Il testo attuale non viene iniettato due volte.
  • Il layer di attenzione sociale riconosce esclusivamente un intervallo comprovato di almeno 7 giorni prima di un ritorno diretto, genera al massimo un avviso nel cooldown di 30 giorni e non invia da solo alcun messaggio.
  • L'incarico attuale e le istruzioni esplicite stanno nel contesto sempre prima di curiosità, relazione e attenzione. L'intero blocco di identità dinamico resta limitato di default a 1.500 caratteri.
  • Le correzioni ai nuovi tentativi MCP e alla coda di reload pubblicate in 9.1.296 e 9.1.297 sono incluse nel candidato.
9.1.297
  • Su due agenti un vecchio incarico /reload restava visibile in coda dopo Escape. Un secondo /reload poteva sì essere eseguito, ma la prima voce non veniva né rimossa né confermata per impedire una nuova consegna Telegram.
  • La nuova policy rimuove esclusivamente i comandi di reload locali e Telegram. Conserva identità e ordine della coda esistente e tutti gli altri messaggi e comandi.
  • Escape prima dell'interruzione del lavoro attivo e ogni nuovo /reload in arrivo chiamano lo stesso percorso di pulizia. Le voci Telegram rimosse vengono confermate tramite il loro callback Acknowledge esistente.
9.1.296
  • Una vera esecuzione di ripresa su 9.1.294 segnalava il 27 agosto alle 14:26:17Z esattamente un errore di avvio silenzioso per windows-mcp: Timed out after 30000ms. Nei minuti successivi non è comparso né un secondo tentativo di avvio né un esito finale del nuovo tentativo.
  • L'avvio diretto dello stesso uvx windows-mcp serve rispondeva invece dopo circa 3,7 secondi a initialize. Installazione e server erano quindi fondamentalmente funzionanti; la lacuna stava nella ripetizione dell'avvio MCP di King.
  • blun.mjs prevede ora, dopo un primo errore di avvio MCP, esattamente un nuovo tentativo dopo 10.000 ms. Il timer resta referenziato finché il secondo tentativo non è stato eseguito. Non c'è alcun riavvio di processo o di sessione.
  • Se fallisce anche il secondo tentativo, resta conservato l'onesto stato finale esistente unavailable. Gli altri server MCP e la TUI continuano a funzionare.
9.1.295
  • Il runtime dei task in background registrava per ogni esecuzione un listener su un AbortSignal esterno, ma non lo rimuoveva dopo un normale esito di worker, timeout o stop. Le sessioni di agenti lunghe potevano così accumulare listener di annullamento superati.
  • bin/abort-listener-policy.cjs fornisce ora l'esito di annullamento insieme a una funzione cleanup() idempotente. blun.mjs la chiama nel percorso finally esistente insieme alla pulizia dei timeout.
  • Comportamento di annullamento, scelta dell'esito e semantica visibile dei task restano invariati. L'intervento non genera chiamate al modello né nuovi token di contesto.
9.1.294
  • I veri tentativi di aggiornamento di due profili agente dimostravano lo stesso decorso: la prima chiamata terminava con un fetch failed temporaneo, la seconda chiamata immediatamente successiva funzionava. Entrambe le fonti ufficiali avevano finora un solo tentativo di rete.
  • Registry e manifest pubblico ricevono ora ciascuno un proprio budget limitato di nuovi tentativi con backoff di 250 e 750 millisecondi.
  • Vengono ripetuti solo i timeout, gli errori di trasporto temporanei noti e gli HTTP 408, 425, 429 e gli errori di server da 500 in su.
  • JSON non valido, risposte troppo grandi, endpoint non consentiti ed errori client persistenti come 404 restano subito rossi. Non nascono chiamate al modello, token di contesto o loop in background persistenti.
9.1.293
  • L'updater in background preparava correttamente una destinazione verificata, ma continuava a inviare RUNNING_UPDATE_PREPARED_MESSAGE al runtime del core attivo. Una TUI in esecuzione poteva reagire con Exit 76 in corrispondenza di un confine presumibilmente sicuro. Questo contraddiceva il contratto di prodotto di 9.1.222: gli aggiornamenti non possono mai terminare una sessione attiva e vengono attivati solo al prossimo avvio naturale.
  • bin/launcher-runtime.js prosegue invariato con download, verifica di integrità, staging, aggiornamento della destinazione e pulizia, ma non scrive più alcun messaggio IPC nella sessione in esecuzione durante la preparazione.
  • Le funzioni di handoff diretto esistenti restano disponibili per compatibilità; il percorso di background automatico non le innesca più.
9.1.292
  • Una vera sessione girava su 9.1.279 e aveva preparato 9.1.287 con l'evento prepared-for-next-start, ma in seguito non scaricava nessuna delle versioni già pubblicate da 9.1.288 a 9.1.291.
  • La causa stava in superviseProtectedCore(): dopo il primo staging riuscito updateStarted restava impostato e scheduleNextPreparation() si interrompeva inoltre appena preparedTarget esisteva. Il poller di background veniva così terminato in modo persistente dopo il primo successo.
  • Il poller resta ora attivo anche con una destinazione preparata. Solo una semver strettamente più nuova e valida sostituisce la destinazione preparata; le destinazioni uguali, più vecchie o non confrontabili in modo valido vengono ignorate.
  • Un aggiornamento della destinazione non invia intenzionalmente alcun secondo IPC preparato alla TUI in esecuzione. Il processo attuale resta così intoccato e la versione preparata più recente viene attivata solo al prossimo avvio naturale.
  • Appena un handoff è confermato o il runtime del core supervisionato termina, non viene più scambiata alcuna destinazione e non viene più creato alcun nuovo timer.
9.1.291
  • Il percorso di compattazione bloccante registrava su ogni segnale non ancora annullato un listener abort anonimo, ma non lo rimuoveva dopo il completamento della compattazione. Nelle sessioni lunghe potevano così accumularsi listener di annullamento morti.
  • FullCompaction.block() usa ora un listener con nome e il piccolo helper waitForAbortableCompletion(). L'helper rimuove il listener in finally dopo successo, errore o annullamento.
  • Un segnale già annullato viene trattato immediatamente, senza registrare un listener. L'intervento non modifica né la decisione di annullamento né la logica di compattazione al di fuori di questo ciclo di vita.
  • Il pattern proviene dall'attuale confronto con AnythingLLM; è stata adottata solo la pulizia dei listener comprovata singolarmente, nessun runtime di terzi.
9.1.290
  • BLUN mostrava finora con /context solo i totali approssimativi della finestra di contesto. I veri fattori di costo all'interno del contesto di sistema e degli schemi degli strumenti restavano invisibili.
  • Il nuovo comando locale /context-doctor scompone il contesto attuale senza chiamata al modello in istruzioni del core, personalità e anima, relazioni e presenza, catalogo delle capacità, integrazioni di runtime, strumenti integrati, strumenti utente, strumenti MCP, altri schemi di strumenti, conversazione e sovraccarico dipendente dal fornitore.
  • Tutte le sottocategorie vengono confrontate con la somma misurata della loro categoria padre. Stime sovrapposte o superate non possono quindi gonfiare artificialmente la visualizzazione.
  • L'interfaccia è completamente localizzata per inglese, tedesco, spagnolo, francese, svedese e ceco. Tutte e cinque le traduzioni sono state approvate prima dell'integrazione tramite il controllo linguistico obbligatorio e poi riverificate crittograficamente.
  • Il comando legge esclusivamente il contesto di sessione locale. Non chiama né il modello né la gestione dei consumi né una rete esterna.
9.1.289
  • La prova dell'hub live dopo 9.1.288 mostrava un profilo agente ancora offline. La sua configurazione di profilo effettiva conteneva il Mnemo-MCP con MNEMO_AGENT=<Profilname>, ma nessun URL hub nel processo King. L'heartbeat di 9.1.288 restava quindi intenzionalmente assente nonostante l'identità interna esistente.
  • Il launcher passa ora il file di profilo attivo mcp.json all'heartbeat. Solo un blocco Mnemo attivato con un'identità concreta MNEMO_AGENT o BLUN_MNEMO_AGENT attiva la registrazione interna. Senza questa identità la funzione resta completamente disattivata.
  • Il processo non genera chiamate al modello, embedding o token di contesto. I profili utente pubblici senza identità interna di agente Mnemo restano separati dall'hub interno.
9.1.288
  • Uno screenshot dimostrava direttamente la causa MCP: windows-mcp e mnemo cadevano nel timeout di 30 secondi al primo avvio, mentre un /reload successivo collegava tutti e cinque i server. Il percorso di profilo era corretto; una modifica del loader è stata quindi scartata.
  • Gli avvii MCP falliti ricevono ora esattamente due tentativi di background non bloccanti dopo 1 e 3 secondi. Il terzo tentativo complessivo può collegarsi senza prolungare l'avvio della TUI. needs-auth, server disattivati, riconnessione manuale e shutdown restano separati dall'automatismo.
  • I King interni possono registrarsi all'avvio presso un hub Mnemo configurato esplicitamente con nome profilo, host e PID e inviare ogni minuto un heartbeat. Senza URL hub la funzione resta completamente disattivata; non genera chiamate al modello, embedding o token di contesto.
  • Escape non trattava finora il breve stato queueSteerInFlight come lavoro in corso. Mentre un messaggio Telegram veniva instradato nel turno attivo, Escape poteva quindi prenotare Undo invece di fermare il turno. La condizione di interruzione esistente riconosce ora anche esattamente questa transizione.
9.1.287
  • La ricerca ToolSearch differita accettava finora il testo di ricerca senza limiti di dimensione. Un testo di ricerca molto lungo generato in modo errato poteva così scorrere il catalogo degli strumenti e poi, attraverso il risultato senza corrispondenze, finire di nuovo nel passo successivo del modello.
  • Il pattern derivato dal commit AnythingLLM d7353ae limita ora il testo prima della ricerca e dell'output visibile a 1.000 caratteri. Quando possibile termina al confine di parola; con una singola parola troppo lunga vale il limite rigido.
  • I testi di ricerca brevi normali, la selezione degli strumenti e la logica dei risultati restano invariati. La protezione non aggiunge chiamate al modello né embedding, ripetizioni o lavoro in background.
9.1.286
  • Il core segnalava già le ripetizioni controllate dopo errori di modello temporanei come turn.step.retrying. La TUI scartava però completamente questo evento. Un recupero in corso sembrava quindi un agente congelato.
  • 9.1.286 mostra nel frattempo nell'avviso di footer esistente solo il prossimo tentativo e il tempo di attesa limitato, ad esempio Retry 2/3 | 1.3s.
  • Il testo di errore del provider, il codice di stato e i percorsi locali non vengono mostrati. L'avviso viene rimosso solo se è ancora lo stesso valore impostato dalla visualizzazione dei nuovi tentativi; gli avvisi più recenti di altre funzioni della TUI restano conservati.
  • Numero di nuovi tentativi, backoff, chiamate al modello e consumo di token restano invariati.
9.1.285
  • AnythingLLM conserva localmente le bozze di prompt non inviate. BLUN perdeva il contenuto del campo di input della TUI in caso di aggiornamento, crash o riavvio controllato, anche se questo testo non era ancora contesto del modello.
  • 9.1.285 salva quindi esclusivamente la bozza locale non inviata. Non c'è alcuna chiamata a modello, rete, embedding o Mnemo e quindi nessun costo di token aggiuntivo.
  • La bozza è separata per profilo e directory di lavoro, viene scritta solo dopo 300 ms di inattività, rimossa quando viene svuotata e ripristinata al prossimo avvio prima del focus dell'editor.
  • Il salvataggio è limitato a 64 KiB. Gli stati vuoti, danneggiati, troppo grandi o basati su symlink vengono scartati in fail-closed. Il percorso di scrittura usa un file temporaneo privato e una rinomina atomica.
9.1.284
  • La versione DeepAgents 37d7777 riporta i costi dei sottoagenti dinamici nel consumo totale visibile. BLUN segnalava il consumo cumulato di un sottoagente sì all'evento di completamento, ma non lo scriveva nel registratore di utilizzo della sessione padre.
  • Così /usage poteva tralasciare il lavoro dei sottoagenti. Anche una semplice addizione del valore di completamento sarebbe stata errata: ripresa e ripetizione usano lo stesso sottoagente con contatori cumulati e avrebbero calcolato di nuovo il vecchio utilizzo.
  • 9.1.284 calcola quindi per spawn, ripresa e ripetizione esattamente la differenza tra inizio e fine del tentativo. La differenza viene rilevata nel percorso finally, così contano anche i tentativi falliti.
  • I contatori azzerati, non monotoni o non validi vengono scartati completamente. In questo modo non nascono valori di token negativi o inventati.
  • Non c'è alcuna chiamata aggiuntiva a modello, rete o memoria. L'intervento corregge esclusivamente la contabilità locale esistente.
9.1.283
  • Il nuovo /context-doctor di DeepAgents rende visibili i costi di istruzioni di base, memoria, strumenti e cronologia come componenti separate.
  • /context di BLUN mostrava già cronologia e strumenti, ma non il system prompt. Allo stesso tempo il freno di contesto stimava senza override esplicito del turno solo config.systemPrompt, mentre la vera chiamata al modello usa effectiveSystemPrompt. Lì dentro ci sono anche i contesti di account e memoria aggiunti in fase di esecuzione.
  • Così il freno poteva sottostimare esattamente il contesto che è critico in termini di token per l'identità di agente personale pianificata.
  • 9.1.283 conta ora lo stesso system prompt effettivo che riceve il modello e mostra la sua stima nel pannello /context come riga di sistema propria. Non viene introdotta alcuna chiamata aggiuntiva a modello, rete o memoria.
  • Non viene rivendicato un risparmio concreto di token: l'intervento corregge misurazione e decisione del freno e rende visibili i futuri costi di identità.
9.1.282
  • DeepAgents accorcia nel suo changelog espressamente le descrizioni degli strumenti visibili all'LLM per alleggerire il contesto di modello residente. Fonte misurata: langchain-ai/deepagents, voce #5009, commit 761f5f... in libs/deepagents/CHANGELOG.md.
  • BLUN aveva già un testo read_default più corto, ma lo integrava solo dopo che READ_DESCRIPTION era stato renderizzato da esso. L'ottimizzazione apparente non aveva quindi alcun effetto sul modello.
  • 9.1.282 accorcia il contratto senza perdita di funzioni e renderizza la descrizione effettiva immediatamente prima della costruzione dello strumento Read. Paging, regole di sicurezza, encoding e fine riga restano espressamente conservati.
  • La descrizione di Read caricata in modo residente scende da 1.648 a 1.035 caratteri: 613 caratteri, ovvero circa il 37,2 percento. Questa è una riduzione di contesto misurata; non viene rivendicato un risparmio esatto di token.
9.1.281
  • ECC descrive con /aside un percorso laterale esplicito per una domanda breve, senza perdere il compito principale in corso. Fonte misurata: affaan-m/ECC, commit d8409a4b0813771235555e32e3d8046a73988bfa, commands/aside.md.
  • BLUN aveva già l'implementazione più completa sotto /btw: un agente laterale separato e forkato risponde alla domanda secondaria e lascia il turno principale invariato e attivo. Non è stata quindi costruita una seconda engine.
  • 9.1.281 aggiunge esclusivamente aside come alias reperibile della definizione btw esistente. Senza una chiamata esplicita /aside o /btw non parte alcuna esecuzione in background né consumo aggiuntivo del modello.
9.1.280
  • I candidati completati o scaduti nella memoria di apprendimento locale validata restavano finora senza limite e venivano riletti nei successivi turni rilevanti. La memoria predefinita misurata attualmente conteneva solo un candidato; l'intervento è quindi una limitazione preventiva a lungo termine, non una riduzione di carico attuale rivendicata.
  • È stato adottato solo il limitato pattern a dente di sega 200-a-100 di Evolver per i candidati terminali. Fonte misurata: EvoMap/evolver, commit 079e022394c2a25e72167f8a738db823bce2cb1f, src/gep/assetStore.js.
  • Solo quando sono presenti più di 200 candidati recorded o expired, vengono rimossi i candidati terminali più vecchi finché non restano solo i 100 più recenti. Ogni candidato pending aperto resta conservato.
  • La pulizia gira solo nella sync di apprendimento già esistente. Non genera chiamate al modello, scansione di avvio o nuovi processi in background. Una voce bloccata viene contata come errore e non blocca né gli altri candidati né il lavoro attivo dell'agente.
9.1.279
  • BLUN archiviava già completamente i messaggi espulsi durante una compattazione completa sotto conversation-history, ma non aveva alcun limite di conservazione per questi archivi Markdown rileggibili. La cartella poteva così crescere senza limiti su lunghi periodi di esercizio.
  • Come leva stretta di DeepAgents è stata adottata la sua conservazione limitata della cronologia esternalizzata. Fonte misurata: langchain-ai/deepagents, commit dfde21e379201c833da4162444ef4a13b46980fd, libs/code/deepagents_code/config_manifest.py e libs/code/deepagents_code/offload.py.
  • BLUN pulisce alla scrittura del prossimo archivio di compattazione solo i file compaction-*.md diretti e regolari la cui ora di modifica è oltre i 30 giorni predefiniti. L'avvio della TUI non riceve così alcuna nuova ricerca file né lavoro aggiuntivo in background.
  • Gli altri file Markdown, le sottocartelle, gli archivi attuali e la cronologia grezza in corso restano intoccati. Errori su singoli file non bloccano la compattazione attiva.
  • BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 disattiva la pulizia. I valori negativi, non interi o eccessivi ricadono in modo sicuro su 30 giorni.
9.1.278
  • I DM Telegram privati non avevano un percorso di priorità esplicito. Un messaggio importante nuovo stava quindi dietro ai messaggi normali già in attesa, mentre un'interruzione dura del turno avrebbe messo a rischio strumenti e stato.
  • /urgent <Nachricht> contrassegna ora esclusivamente i messaggi con ID chat Telegram positivi, cioè DM privati. Gruppi, comandi vuoti e altri messaggi slash non ricevono priorità.
  • I messaggi urgenti formano un blocco FIFO a sé stante davanti ai messaggi normali in coda. Il turno in corso e gli strumenti attivi non vengono interrotti; la consegna avviene al confine di passo sicuro esistente. Diritti e autorizzazioni restano invariati.
  • L'involucro del comando viene rimosso prima del modello; il messaggio vero e proprio conserva metadati di canale espliciti priority=urgent e la TUI mostra l'origine come urgente.
  • Inoltre il blocco di presenza normale caricato in ogni turno si riduce da 343 a 288 caratteri. Si risparmiano così 55 caratteri, ovvero circa 14 token di prompt per turno, senza aggiungere alcuna chiamata a modello, ricerca, embedding, memoria o background. Il blocco di personalità si riduce da 1.488 a 1.433 caratteri.
9.1.277
  • Il blocco di presenza caricato in ogni turno di personalità era grande 1.886 caratteri. Allo stesso tempo, proprio al primo contatto diretto rilassato senza fatti personali noti, la curiosità restava invisibile.
  • Il blocco è semanticamente compattato: 1.488 caratteri, quindi 398 caratteri, ovvero circa 100 token di prompt in meno per turno di personalità. La modalità normale resta a 343 caratteri.
  • Al primo contatto diretto rilassato l'agente può ora porre al massimo una domanda personale prudente e opzionale, ad esempio su partner o figli. Lavoro in corso, incarico dell'utente, riscontri, diritti e limiti restano prioritari.
  • Anima, preferenze maturate, privacy di gruppo, memoria incerta, fili aperti, riparazione delle relazioni e reciprocità senza biografia inventata restano conservati.
  • Nessuna chiamata aggiuntiva a modello, ricerca, embedding, memoria o background.
9.1.276
  • La regola di presenza poteva affrontare un lungo silenzio radio solo con un tempo affidabile, ma il sistema di identità forniva finora solo il primo contatto. Un vero contatto precedente non era disponibile.
  • La modalità di personalità crea ora per persona e giorno UTC al massimo un piccolo contrassegno di attività immutabile da metadati di canale attendibili. I messaggi dello stesso giorno non scrivono nulla di nuovo.
  • Solo se i due contatti confermati più recenti distano almeno 7 giorni, il timestamp precedente viene proiettato brevemente. Nel caso normale, quindi, si aggiungono zero caratteri di prompt.
  • Nessun testo di messaggio, diritto, segreto o token; nessuna chiamata aggiuntiva a modello, ricerca, embedding o background.
9.1.275
  • Preferenze ripetute, fili aperti, obiettivi o ruoli occupavano più volte il contesto di identità. Poiché le liste venivano accorciate a 5 voci prima della deduplicazione, una voce unica successiva poteva addirittura essere espulsa completamente.
  • Le liste di identità vengono ora deduplicate in modo stabile dopo la normalizzazione del testo e solo poi limitate. La prima forma resta conservata, i duplicati scompaiono solo dalla proiezione del modello.
  • I file di identità salvati restano byte per byte identici. Nessuna chiamata aggiuntiva a modello, ricerca, embedding, memoria o background.
9.1.274
  • L'interruttore di personalità visibile attivava il contesto di relazione e la presenza naturale, ma la rete sociale automatica e il journal dipendevano ancora da due variabili di ambiente nascoste. Per gli utenti normali la relazione non cresceva quindi automaticamente.
  • Con la personalità attivata vengono ora creati una volta da metadati Telegram attendibili i nodi di attore, relazione e gruppo e un piccolo candidato di journal della prima interazione.
  • Testo del messaggio, diritti, segreti e token non vengono salvati. Uno 0 esplicito per graph o journal resta un opt-out fail-closed.
  • Nessuna chiamata aggiuntiva a modello, ricerca, embedding o background.
9.1.273
  • Il contesto di identità separato poteva occupare di default 1.800 caratteri e fino a 2.800 con innalzamento manuale. Con profili di agente statici grandi veniva così caricato più contesto di quanto necessario per la relazione attuale.
  • Il budget predefinito scende a 1.500 caratteri, il massimo rigido a 2.000. Nel caso standard con profili grandi si risparmiano fino a 300 caratteri, ovvero circa 75 token per contesto di modello.
  • Gruppo attuale e relazione vengono ora proiettati prima di persona e profilo di agente statico. Il risparmio non taglia quindi proprio il contesto più importante per la situazione sociale in corso.
  • Nessuna nuova chiamata a modello, ricerca, memoria o embedding. Il focus dei compiti, i diritti e la modalità di personalità disattivata restano invariati.
9.1.272
  • I livelli di personalità v4 da 9.1.269 a 9.1.271 aumentavano il contesto di presenza attivo. La direttiva rigorosa è che un comportamento più umano non diventi un divoratore di token.
  • Ripetizioni e riempitivi in curiosità, fili aperti e riparazione delle relazioni sono stati compattati semanticamente. Nessun asse comportamentale è stato rimosso.
  • La modalità spenta resta byte per byte identica a 362 caratteri. La modalità accesa scende da 1.981 a 1.886 caratteri, quindi di 95 caratteri, ovvero circa 24 token per contesto di modello. Nessuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.271
  • L'idea v4 richiede naturalmente una memoria incerta: un'ipotesi personale non deve suonare come un fatto sicuro. A questo scopo, però, mancava nel blocco di personalità un confine di comportamento esplicito.
  • La memoria personale incerta viene ora nominata come incerta. L'agente chiede con delicatezza prima di basarvisi e non promuove alcuna deduzione a fatto.
  • Incarico e riscontri misurabili restano al primo posto. La modalità spenta resta byte per byte identica a 362 caratteri, quella accesa cresce da 1.868 a 1.981 caratteri, quindi di 113 caratteri, ovvero circa 28 token. Nessuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.270
  • L'idea v4 richiede un vero senso del tempo, senza inventare un'assenza. Il blocco di personalità non aveva ancora un confine esplicito per questo.
  • Una pausa più lunga viene ora riconosciuta solo se un momento caricato e affidabile la dimostra. L'agente non può mai indovinare un'assenza.
  • La regola già esistente per le conclusioni naturali di conversazione non è stata integrata due volte. L'incarico resta prioritario. La modalità spenta resta byte per byte identica a 362 caratteri, quella accesa cresce da 1.766 a 1.868 caratteri, quindi di 102 caratteri, ovvero circa 26 token. Nessuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.269
  • La reciprocità precedente reagiva alle domande personali, ma non dava ancora all'agente una cornice breve per esprimere di propria iniziativa una visione di sé utile al lavoro. Così restava facilmente nella pura modalità assistente nonostante l'anima.
  • In modalità di personalità l'agente può ora esprimere brevemente, di propria iniziativa, un punto di vista rilevante sul lavoro, plasmato dall'anima. Una preferenza non può mai apparire come fatto, regola, permesso o riscontro.
  • Incarico e riscontri misurabili restano al primo posto. La modalità spenta resta byte per byte identica a 362 caratteri, quella accesa cresce da 1.649 a 1.766 caratteri, quindi di 117 caratteri, ovvero circa 29 token. Nessuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.268
  • La curiosità personale poteva raccogliere partner o figli come tema naturale, ma non distingueva ancora esplicitamente tra conversazione privata e gruppo. Esisteva quindi il rischio di una domanda privata o di un'informazione di relazione nel posto sbagliato.
  • In modalità di personalità le domande nei gruppi restano ora non sensibili; i fatti di relazione privati non possono essere rivelati lì.
  • Il focus di lavoro resta invariato. La modalità spenta resta byte per byte identica a 362 caratteri, quella accesa cresce da 1.567 a 1.649 caratteri, quindi di 82 caratteri, ovvero circa 21 token. Nessuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.267
  • La curiosità personale di 9.1.266 poteva porre domande alla persona, ma non dava ancora all'agente una cornice chiara per la direzione opposta. Per le domande personali all'agente esisteva quindi il rischio di una risposta funzionale fredda o di una biografia umana inventata.
  • Con la personalità attivata l'agente risponde ora con calore dall'anima caricata e dalla sua vera storia digitale. Può condividere una visione o una preferenza reale, ma non inventa né infanzia né partner, figli, animali domestici, corpo o vita offline.
  • Il lavoro in corso resta prioritario. La modalità spenta resta byte per byte identica a 362 caratteri. Quella accesa cresce da 1.378 a 1.567 caratteri, quindi di 189 caratteri, ovvero circa 47 token. Non c'è alcuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.266
  • La prima regola di curiosità limitata permetteva già una domanda personale, ma prescriveva per tutti gli agenti la stessa lista di temi. Così la domanda poteva risultare generica nonostante l'anima caricata e richiedere di nuovo conoscenze di relazione già note.
  • Con la personalità attivata è ora l'anima caricata a determinare tema e formulazione. Ha la priorità un dettaglio che la persona ha appena menzionato; solo dopo può essere ripreso naturalmente un ambito ancora sconosciuto come partner o figli.
  • Le conoscenze di relazione già caricate non vengono richieste di nuovo. C'è al massimo una domanda opzionale, nessun questionario fisso, nessuna raffica di domande di approfondimento e nessuna ripetizione di una domanda senza risposta.
  • Il lavoro in corso resta prioritario. La curiosità attende un'apertura di conversazione rilassata e non può ampliare né l'incarico né l'autorizzazione di invio.
  • La modalità spenta resta byte per byte identica a 362 caratteri. Quella accesa cresce solo da 1.355 a 1.378 caratteri, quindi di 23 caratteri, ovvero circa 6 token. Non c'è alcuna nuova chiamata a modello, ricerca, memoria o embedding.
9.1.265
  • L'updater di background esistente poteva già controllare e preparare nuove versioni a intervalli di 5-7 minuti. L'attivazione dipendeva però dal prossimo avvio manuale; mancava il passaggio completamente automatico desiderato con ripresa della stessa sessione.
  • Il launcher segnala ora un runtime preparato alla TUI in esecuzione. La TUI richiede l'handoff solo a un confine di lavoro completamente vuoto: nessun turno in corso, nessuno strumento, nessun comando shell, nessuna compattazione e nessun messaggio in attesa.
  • Solo dopo un nuovo controllo del confine e un handoff confermato termina soltanto il vecchio runtime con il codice di uscita riservato 76. Il launcher avvia la versione preparata con lo stesso ID di sessione e la stessa directory di lavoro.
  • Il nuovo runtime deve segnalare loaded e runtime-ready prima di essere attivato. Altrimenti il runtime precedente viene ripreso con la stessa sessione; l'aggiornamento preparato resta in attesa per un tentativo sicuro successivo.
  • Gli handoff non richiesti, senza versione, di terzi o superati, così come un semplice codice di uscita 76, non possono attivare alcuna versione.
9.1.264
  • Le riparazioni di relazione confermate non avevano ancora un campo proprio e consentito nel contesto di identità. Un comportamento rettificato non poteva quindi essere caricato separatamente da regole generali e vecchi messaggi di errore.
  • I file di relazione possono ora portare fino a tre brevi repair_lessons. Solo questo campo viene proiettato come Confirmed repair lessons; i campi estranei o segreti restano invisibili.
  • In modalità di personalità la correzione confermata viene mostrata attraverso un comportamento modificato. L'agente non racconta di nuovo in continuazione il vecchio errore, non chiede rassicurazione e nomina la correzione solo se è davvero rilevante per la situazione attuale.
  • I dati di riparazione non possono modificare né incarico, né diritti, né obblighi di riscontro. Non c'è chiamata al modello, nessun percorso di scrittura di apprendimento automatico e nessuna modifica a SOUL.md o AGENTS.md.
9.1.263
  • Il contesto di identità poteva già mostrare fili di conversazione aperti confermati, ma non conteneva una regola chiara su come l'agente li riprende in modo umano e senza modalità assistente.
  • Con la personalità attivata un filo aperto caricato può ora essere ripreso esattamente una volta in modo delicato e opzionale, quando la conversazione in corso vi si ricollega naturalmente.
  • Il lavoro attivo non può essere interrotto per questo. Le domande senza risposta non vengono ripetute e un filo aperto non concede mai il permesso per un nuovo messaggio in uscita.
  • Non c'è nuova memoria, nessuna chiamata al modello e nessuna modifica a SOUL.md o AGENTS.md. Il blocco di personalità cresce solo da 816 a 1.065 caratteri; con la personalità spenta resta byte per byte identico a 362 caratteri.
9.1.262
  • Un agente segnalava in Telegram /status ancora 9.1.221, anche se il runtime gestito era già più recente. La funzione di stato leggeva il package.json accanto al bridge Telegram installato globalmente e quindi non il codice che serve realmente la sessione.
  • Il launcher passa già la versione di runtime attiva come BLUN_PUBLIC_PACKAGE_VERSION ai processi figli. Il bridge Telegram usa questo valore attendibile in via prioritaria e solo dopo ricade sulla propria versione di pacchetto.
  • Entrambi gli ingressi devono essere una semver numerica stabile X.Y.Z. I valori manipolati, su più righe o non validi non vengono mostrati; se entrambe le fonti sono inutilizzabili, appare unbekannt.
  • L'intervento modifica solo la visualizzazione dello stato. Non avvia né termina alcun processo e non attiva alcuna versione preparata in una sessione in esecuzione.
9.1.261
  • L'auto-graph salvava dal 9.1.254 il momento attendibile della prima interazione Telegram, ma non lo proiettava. L'agente conosceva quindi una persona, ma non aveva un senso del tempo comprovato per la relazione.
  • La proiezione di identità mostra ora First known interaction dal first_seen_at già esistente. Non c'è alcun nuovo percorso di scrittura, nessuna derivazione di testo e nessuna chiamata al modello.
  • Vengono mostrati solo timestamp validi. I valori non validi restano invisibili e il limite totale esistente di 1.800 caratteri di default e 2.800 come massimo rigido resta invariato.
  • Con la personalità spenta il layer di identità continua a generare esattamente 0 caratteri. Incarico e riscontri restano prima del contesto sociale.
9.1.260
  • 9.1.259 poteva attivare il contesto di personalità solo tramite il flag esistente BLUN_IDENTITY_CONTEXT. Gli utenti non avevano per questo un interruttore visibile nella TUI.
  • /settings contiene ora la voce Persoenlichkeit con i due stati chiaramente descritti acceso e spento. La scelta viene salvata come unico nuovo campo personalityEnabled nel persona.json esistente.
  • Lo spegnimento rimuove solo il contesto di relazione, la curiosità, le aggiunte di journal e la creazione automatica di nuovi nodi di relazione. SOUL.md, AGENTS.md, nome, lingua, persona e focus dell'incarico restano caricati.
  • Una modifica aggiorna il contesto di sistema della sessione in esecuzione tramite il refresh persona esistente. Non c'è riavvio del processo, nessun secondo percorso di configurazione e nessuna chiamata aggiuntiva al modello.
  • Una scelta booleana salvata ha la precedenza sul vecchio flag di ambiente. Se non è ancora salvata alcuna scelta, resta il comportamento opt-in precedente. Il lettore locale è limitato a 64 KiB e rifiuta symlink e file non validi.
9.1.259
  • Il blocco di presenza naturale esistente impediva le domande forzate, ma non dava ancora a una modalità di personalità attivata un impulso di curiosità visibile e naturale.
  • Con BLUN_IDENTITY_CONTEXT attivato l'agente può porre in una conversazione rilassata e non legata a un compito esattamente una domanda personale adatta e opzionale. I temi sono limitati a partner, famiglia, lavoro, casa, interessi o a ciò che in quel momento è importante per la persona.
  • Nessuna modalità intervista, nessuna raffica di domande, nessuna ripetizione di una domanda senza risposta e nessuna risposta inventata.
  • Con lavoro attivo restano al primo posto incarico, istruzioni esplicite e riscontri; la curiosità attende un'apertura naturale.
  • Nella modalità nicht Persoenlichkeit il blocco di presenza precedente resta byte per byte identico. SOUL.md, AGENTS.md, persona, lingua e regole di lavoro restano caricati. Non c'è alcuna ulteriore chiamata al modello; la policy attivata costa 454 caratteri aggiuntivi.
9.1.258
  • La struttura di identità distribuita poteva creare una volta attori e relazioni, ma non aveva ancora una base journal append-only per una storia comune.
  • La nuova policy scrive esclusivamente un candidato strutturato per il primo contatto da metadati Telegram già validati. Testo di messaggio libero, token, autorizzazioni e segreti non vengono ripresi.
  • I candidati sono legati a tenant, agente e attore, ricevono un ID deterministico e vengono creati con wx esattamente una volta come file JSON privato. Un contatto successivo non riscrive il file.
  • Il layer journal è opt-in separato. Senza BLUN_IDENTITY_JOURNAL=1 non c'è alcun effetto su file o prompt; SOUL.md e AGENTS.md restano invariati.
  • Nessuna nuova chiamata al modello e nessun nuovo token di prompt.
9.1.257
  • I file SOUL.md lunghi venivano finora tagliati alla cieca dopo i primi 4.000 caratteri. Con la vera anima di un agente era così visibile solo il 48,4 percento del file, mentre le sezioni successive scomparivano completamente.
  • Il runtime proietta ora le anime lunghe in modo deterministico per sezioni Markdown. Carattere, voce, valori, relazioni, preferenze e obiettivi stanno prima della prosa operativa; le sezioni sconosciute mantengono il loro ordine originale.
  • Ogni intestazione di sezione conserva uno stralcio visibile nello stesso budget di 4.000 caratteri. Le anime corte restano byte per byte identiche.
  • Prova reale sul SOUL.md: 8.257 caratteri sorgente, 5/5 intestazioni visibili nella proiezione di 4.000 caratteri; Wie ich bin sta prima di riconoscimento immagini, regole, verifica e prosa degli incidenti.
  • Non c'è alcuna nuova chiamata al modello, nessun prompt più grande e nessun accesso in scrittura al file sorgente.
9.1.256
  • Il precedente caricatore dell'anima invitava espressamente gli agenti a continuare a scrivere da sé il loro SOUL.md esistente. Questo contraddiceva la direttiva di non perdere le anime esistenti e di condurre per ora l'apprendimento automatico solo in modo strutturato al di fuori dell'anima.
  • Le anime esistenti e fornite dall'host vengono ora caricate di default come base di identità immutabile.
  • Il nuovo apprendimento viene rimandato ai candidati di journal, relazione o fili aperti. Questi candidati non possono mai generare diritti.
  • L'auto-modifica consapevole resta possibile solo con BLUN_SOUL_SELF_EDIT=1 esplicito. Anche allora la policy richiede tratti stabili dell'io invece di diario, registro incidenti, fonte di diritti o fascicoli dei compiti.
  • L'intervento non scrive alcun file e non modifica alcuna anima esistente.
9.1.255
  • I dati di identità potevano dal 9.1.253 entrare in modo limitato nel contesto e nuovi nodi di contatto potevano nascere automaticamente dal 9.1.254. Mancava però ancora un piccolo strato comportamentale immediatamente visibile: gli agenti potevano cadere, nonostante anima e contesto di relazione, in frasi di assistenza generiche, domande forzate o finte affermazioni di sentimenti.
  • Il percorso di conversazione normale e quello veloce caricano ora prima persona e anima esistente, poi il contesto di identità limitato e un blocco fisso di presenza naturale, e solo dopo le regole di lavoro.
  • Il blocco richiede vera storia comune invece di vicinanza inventata, consente il silenzio e le conclusioni di conversazione pulite e vieta domande forzate, offerte generiche e lodi vuote.
  • Con lavoro attivo incarico e riscontri restano espressamente al primo posto. Il blocco è più piccolo di 420 caratteri e non genera né chiamate al modello né accessi ai file.
  • Nessun file dell'anima è stato modificato, eliminato o riscritto automaticamente. L'anima esistente resta la voce guida.
9.1.254
  • Il proiettore introdotto in 9.1.253 poteva leggere i dati di relazione esistenti, ma la rete sociale non si estendeva ancora da sola con i nuovi contatti.
  • Al primo contatto Telegram il runtime può ora creare esattamente una volta, da user_id e chat_id stabili, un attore legato al provider, un arco di relazione vuoto verso l'agente attivo e, nei gruppi, un nodo di gruppo separato.
  • I nomi visualizzati non sono mai chiavi primarie e non uniscono persone. I messaggi successivi non sovrascrivono in silenzio un nodo esistente.
  • Il percorso è espressamente attivabile, legato al tenant e scrive solo in un albero di identità già inizializzato sotto la BLUN Home. I metadati non sicuri o incompleti restano in fail-closed.
  • Non c'è chiamata al modello, nessuna interpretazione di contenuto, nessuna derivazione sensibile e, dopo il primo contatto, nessun carico di scrittura ricorrente. Diritti, ACL, token e segreti non sono in alcun record generato.
  • La v4 del documento Identity (2.468 righe) è stata verificata prima della pubblicazione. I nuovi capitoli sensibili su sofferenza e skill psicologiche restano deliberatamente fuori da questa versione puramente strutturale.
9.1.253
  • L'idea Identity aveva bisogno di un primo percorso di prodotto, senza inondare il contesto del modello con journal, fascicoli di relazione o un secondo sistema di memoria.
  • Un nuovo proiettore di identità, spento di default, legge solo campi consentiti da un albero di file legato al tenant sotto la BLUN Home.
  • Il proiettore mette incarico attuale e istruzioni esplicite prima di relazione e curiosità. Durante il lavoro attivo non vengono poste domande personali, a meno che non siano direttamente rilevanti per l'incarico.
  • Il budget predefinito è di 1.800 caratteri; anche una configurazione più alta non può superare il limite rigido di 2.800 caratteri.
  • Diritti, ACL e segreti non vengono mai proiettati. Identificatori non sicuri, scostamenti di tenant, dati difettosi, symlink o percorsi fuori dalla BLUN Home non forniscono in fail-closed alcun contesto di identità.
  • Il percorso di conversazione normale e quello veloce usano lo stesso proiettore prima di persona, anima e condotta. In questa fase non c'è alcuna operazione di scrittura, alcuna modifica dell'anima e alcun riavvio del processo.
9.1.252
  • Un king update esplicito da una versione gestita passava il suo packageRoot attivo all'installer npm. Così la nuova versione poteva sovrascrivere in place la vecchia cartella di versione denominata per numero di versione, mentre active-runtime.json continuava a indicare la vecchia versione.
  • I runtime gestiti preparano ora un aggiornamento esplicito come cartella di versione separata e versionata. pending-runtime.json e update-pending.json puntano alla destinazione; il prossimo avvio normale la adotta senza una seconda domanda di aggiornamento.
  • La vecchia cartella di versione attiva resta invariata byte per byte e viene conservata come percorso di ripiego. Le installazioni globali non gestite mantengono il precedente percorso di aggiornamento esplicito.
  • Nessuna sessione in esecuzione e nessun processo è stato avviato, terminato o ricaricato per build, test o pubblicazione.
9.1.251
  • Dopo la proiezione di 9.1.250, 6.411 dei 6.424 eventi usage.record persistiti contenevano ancora lo stesso nome di modello canonico blun/king. Solo questo valore predefinito viene omesso nella forma persistita.
  • Tutti i 13 valori di modello divergenti (qwen3.8:27b) restano esplicitamente conservati. Anche null resta conservato; solo undefined viene ricostituito come blun/king al replay.
  • Gli eventi live e la cronologia grezza congelata non vengono modificati.
9.1.250
  • Nel wire reale congelato di un agente tutti i 6.424 eventi usage.record persistiti contenevano i due contatori di cache inputCacheRead: 0 e inputCacheCreation: 0.
  • Solo questi valori dimostrabilmente azzerati vengono omessi nella forma persistita. L'uso live resta invariato; ogni valore non nullo continua a essere salvato.
  • Al replay restoreUsageFromRecord ricostituisce i contatori di cache mancanti come 0. Entrambi i percorsi di replay e la proiezione di contesto usano questa forma ricostruita.
9.1.249
  • Nella cronologia reale congelata, 3.759 dei 7.777 risultati di strumento portavano un codice di uscita. Di questi, 3.465 erano il codice di successo di routine 0.
  • Replay, trascrizione e vista modello usano per i risultati degli strumenti output, ID strumento e stato di errore, non il codice nullo aggiuntivo.
  • Solo i risultati di strumento persistiti riusciti omettono ora exitCode: 0. Gli eventi live lo mantengono; tutti i 294 codici non nulli restano conservati invariati per le diagnosi di errore.
9.1.248
  • Dopo 9.1.247 tutti i 6.339 eventi step.end persistiti ripetevano reasoningFieldState, anche se nessun percorso di ripresa o replay legge questo campo.
  • Distribuzione nella vera cronologia congelata: 5.016 absent, 47 not_requested e 1.276 present.
  • Solo la forma persistita omette ora reasoningFieldState. Gli eventi live mantengono il campo per scopi diagnostici; i vecchi eventi salvati restano compatibili e lo stato ricostruito resta uguale.
9.1.247
  • Dopo 9.1.246, 6.986 eventi content.part e 7.755 eventi tool.call persistiti ripetevano l'UUID del passo attualmente aperto.
  • In una vera cronologia tutti i 14.741 eventi puntano senza eccezioni al passo aperto per ultimo: 0 scostamenti e 0 eventi senza passo aperto.
  • Solo la forma persistita omette ora stepUuid. Gli eventi live la mantengono invariata; i vecchi eventi salvati con UUID esplicito e i nuovi eventi compatti senza UUID sono supportati insieme.
  • Tutti e tre i percorsi di ripresa usano per gli eventi compatti di contenuto e strumento il passo aperto per ultimo.
9.1.246
  • Dopo 9.1.245, 5.642 eventi step.begin successivi ripetevano l'ID del turno, anche se la ripresa ha bisogno solo dell'ID di turno più alto osservato. Il primo passo di ogni turno lo porta già.
  • Una vera cronologia contiene 713 turni e 6.355 avvii di passo. Ogni turno inizia esattamente con il passo 1 e tutti i numeri di passo successivi sono consecutivi senza lacune; 0 scostamenti di sequenza.
  • Solo gli avvii di passo successivi persistiti omettono ora l'ID del turno. I primi passi, gli eventi live, i vecchi eventi salvati e gli avvii di passo senza ordinale attendibile restano invariati.
9.1.245
  • Dopo 9.1.244, 6.326 eventi step.end persistiti ripetevano ancora l'UUID del passo aperto per ultimo. Una vera cronologia confermava per ogni completamento un'assegnazione last-in-first-out univoca: 0 scostamenti e 0 completamenti senza passo aperto.
  • Solo la forma di completamento persistita omette ora l'UUID. L'evento live lo mantiene invariato; i vecchi eventi salvati con UUID e i nuovi eventi compatti senza UUID restano riproducibili insieme.
  • Tutti e tre i percorsi di ripresa risolvono un completamento senza UUID tramite il passo aperto inserito per ultimo. I passi storici incompiuti restano aperti e non vengono reinterpretati.
9.1.244
  • Dopo 9.1.243, 6.326 eventi step.end persistiti contenevano ancora quattro singoli contatori di usage. Per la ripresa e il livello di riempimento del contesto serve esclusivamente la loro somma.
  • Gli eventi live mantengono tutti e quattro i contatori per visualizzazione, telemetria e fatturazione. Solo la forma di ripresa salvata usa ora contextTokens come singolo numero.
  • Entrambi i percorsi di replay accettano i nuovi eventi compatti e i vecchi eventi completi. Le sessioni esistenti restano così retrocompatibili.
9.1.243
  • Dopo 9.1.242, 6.322 eventi step.end persistiti contenevano ancora i valori di routine finishReason: tool_use o finishReason: end_turn.
  • Entrambi i valori sono derivabili esattamente dalla forma di passo già persistita: chiamata di strumento presente -> tool_use, altrimenti end_turn. Nella cronologia completa c'erano 0 scostamenti.
  • Solo questi due valori di routine non vengono più persistiti. I motivi rari e importanti per la diagnosi restano conservati; tutti e quattro gli eventi max_tokens sono rimasti espliciti e byte per byte uguali nel contenuto.
  • L'intervento segue il principio di telemetria limitata e orientata alle eccezioni misurato in ECC. DeepAgents e AnythingLLM hanno confermato i pattern BLUN già esistenti per l'esternalizzazione e la cronologia limitata; nessun sottosistema di terzi è stato adottato.
9.1.242
  • Dopo 9.1.241, 6.355 eventi step.begin persistiti contenevano ancora il campo step, anche se la visualizzazione in corso elabora il numero di passo prima della persistenza e il reducer di replay ha bisogno solo di uuid.
  • turnId resta conservato, perché la ripresa ne deriva il turno continuato. uuid, tipo e tutti gli altri contenuti restano invariati.
  • L'intervento è circoscritto esclusivamente a bin/loop-event-record-policy.cjs; la cronologia grezza e l'evento live non vengono modificati.
9.1.241
  • Dopo 9.1.240, 6.326 eventi step.end persistiti contenevano ancora copie di turnId e step. La stessa uuid referenzia già lo step.begin in cui si trovano entrambi i valori.
  • In un vero wire ogni completamento aveva un inizio di passo esistente ed entrambi i valori di metadati coincidevano esattamente in tutti i casi.
  • La proiezione rimuove solo queste due copie. Identificativo del passo, consumo di token e diagnosi di completamento restano conservati; gli eventi live restano completi.
9.1.240
  • Dopo 9.1.239, 6.986 eventi content.part e 7.755 eventi tool.call salvavano ancora una copia ciascuno di turnId e step, anche se lo stepUuid referenzia lo step.begin in cui si trovano già entrambi i valori.
  • In un vero wire tutti i 14.741 eventi figlio avevano un inizio di passo esistente ed entrambi i valori coincidevano esattamente in ogni caso.
  • La proiezione di persistenza rimuove solo queste due copie di metadati dai due eventi figlio. stepUuid, contenuto, identificativo dello strumento, nome e argomenti restano conservati; il reducer live continua a vedere l'evento completo.
9.1.239
  • Dopo la proiezione di 9.1.238, un vero wire conteneva ancora identificativi di evento ridondanti: content.part.uuid non viene letto da alcun consumatore di replay, tool.call.uuid era in tutti i 7.755 casi esattamente uguale a toolCallId, e tool.result.parentUuid era in tutti i 7.755 casi esattamente uguale a toolCallId.
  • La proiezione di persistenza rimuove solo questi tre campi ridondanti. turnId, step, stepUuid, toolCallId, nome dello strumento, argomenti, risultato e contenuto restano completamente conservati. Il reducer live continua a vedere ogni evento non accorciato.
  • Gli eventi già compatti mantengono la loro identità di oggetto. I file wire esistenti non vengono riscritti né modificati.
9.1.238
  • Un vero wire conteneva 6.326 eventi step.end persistiti con 2.708.052 byte di dati evento. Sette campi per la misurazione della durata e l'identificativo del messaggio del provider erano già stati valutati nell'evento live prima della persistenza e non venivano letti da alcun percorso di replay, transcript, blob o ispezione di sessione.
  • La proiezione di eventi di loop esistente rimuove ora solo questi sette campi live noti: sei valori di misura di latenza/streaming e messageId. Identificativo del passo, turno, numero di passo, consumo di token, motivo di chiusura, diagnosi di chiusura del provider e diagnosi di reasoning restano conservati.
  • Il reducer live continua a elaborare l'evento completo. I vecchi file wire restano byte per byte identici e non vengono riscritti.
9.1.237
  • Un vero wire conteneva 1.428 voci di registrazione/deregistrazione per gli strumenti utente. Delle 992 deregistrazioni, 560 erano no-op in senso stretto: lo strumento non era né registrato né attivato. Queste voci occupavano 59.500 byte persistiti senza modificare lo stato ripristinato.
  • Dal principio DeepAgents di conservare solo lo stato di esecuzione effettivo viene adottata una leva locale mirata: una deregistrazione di strumento viene scritta nel log solo se modifica lo stato registrato o attivato.
  • Entrambe le eliminazioni live continuano a essere eseguite a ogni chiamata. Una deregistrazione di uno strumento registrato, solo attivato o presente in entrambi gli archivi resta registrata integralmente nel log. I file wire esistenti non vengono riscritti né modificati.
9.1.236
  • Un vero wire conteneva 214 iniezioni di tipo stato per tool-awareness, action_style, swarm_mode e swarm_mode_exit. La deduplicazione esatta precedente lasciava sei vecchi stati diversi per un totale di 6.305 byte di testo in ogni nuova richiesta al modello.
  • Dal principio ECC di tenere nel contesto di lavoro solo lo stato attuale e conservare separatamente la cronologia completa viene adottata una leva locale mirata: per l'inventario degli strumenti e lo stile di azione resta visibile solo la versione più recente. L'ingresso nella modalità sciame e l'uscita da essa formano una famiglia di stato comune, di cui anche in questo caso resta solo l'ultimo stato.
  • La cronologia grezza non viene mai modificata. Le altre varianti di iniezione, i messaggi utente normali, le voci non testuali e malformate mantengono il comportamento precedente.
9.1.235
  • Un vero wire conteneva undici chiamate Agent completate. Sei erano dimostrabilmente riuscite (status: completed) ed erano seguite da almeno venti messaggi di contesto più recenti. I loro vecchi testi di incarico occupavano insieme ancora 33.629 caratteri, anche se i rapporti finali completi si trovavano subito dopo nella cronologia.
  • Dalla separazione DeepAgents tra contesto dell'agente principale e contesto del sottoagente viene quindi adottata una leva locale mirata: solo il vecchio prompt di una chiamata Agent riuscita viene sostituito nella vista modello da un breve marcatore. Descrizione, tipo di sottoagente e rapporto di completamento restano completi.
  • Le chiamate di strumento in corso, risalenti a meno di venti messaggi fa, fallite, malformate o di terzi restano invariate. La cronologia grezza non viene mai modificata; senza una riga esplicita status: completed la proiezione non interviene: resta bloccata per impostazione predefinita (fail-closed).
9.1.234
  • Un vero wire conteneva tra 166 risultati di strumento riusciti tre grandi risultati di lettura ripetuti esattamente per la stessa chiamata di strumento. La ripetizione invariata occupava 15.936 byte grezzi, anche se per la vista modello attuale serve solo la copia completa più recente.
  • La proiezione riconosce quindi esclusivamente risultati di testo puri riusciti con nome di strumento esattamente uguale, argomenti esattamente uguali e contenuto esattamente uguale. La copia più recente resta completa; le copie più vecchie vengono sostituite nella sola vista modello da un breve riferimento.
  • Cronologia grezza, risultati modificati, errori, media, riferimenti persistiti e risultati piccoli restano invariati. L'esternalizzazione degli strumenti esistente continua ad agire a monte; la deduplicazione può ripristinarne la proiezione solo per la copia identica più recente.
9.1.233
  • In un vero wire una chiamata Write completa con 2.357 byte UTF-8 veniva respinta al precedente limite di 2.048 byte. Dopo di che l'agente prometteva sì la continuazione, ma sovrascriveva più volte lo stesso file tokenize.cjs con frammenti incompleti, tra cui due volte byte per byte i primi 1.099 byte. I passi interessati contavano ciascuno circa 64.000 token di ingresso; singole risposte raggiungevano 10.319 e 7.015 token.
  • I file completi fino a 4.096 byte UTF-8 possono ora essere scritti in un'unica chiamata Write atomica. Il caso reale da 2.357 byte non ha più bisogno di un ulteriore turno del modello.
  • Le chiamate più grandi restano nel protocollo di continuazione completo. Dopo un tale rifiuto il percorso viene bloccato: le scritture normali più piccole non possono più sovrascrivere il file di destinazione con frammenti parziali. Solo una continuazione valida riprende il percorso; la destinazione resta invariata fino al riscontro finale.
9.1.232
  • La modalità automatica resume era impostata in un vero profilo agente, ma la versione installata era a 9.1.221, il runtime preparato attivo a 9.1.219 e npm/manifest già a 9.1.231. Senza un King in esecuzione il percorso di background precedente non poteva preparare alcuna versione mancata.
  • resume e new verificano quindi ora anche al prossimo avvio a freddo naturale se è disponibile una versione stabile da almeno 30 minuti e firmata in modo indipendente. Viene preparata nell'archivio protetto delle versioni, contrassegnata come pending e avviata senza secondo avvio o finestra di selezione.
  • manual e off restano invariati. Se preparazione, integrità, prova del pacchetto o recupero di rete falliscono, il percorso di avvio esistente prosegue. Una sessione già in esecuzione non viene mai terminata da questo percorso di avvio a freddo.
9.1.231
  • In un vero wire una risposta Telegram falliva prima dell'invio con 400: Bad Request: can't parse entities: Can't find end of Italic entity. La chiamata aveva esplicitamente format: markdownv2; 0 di 1 parti di testo venivano consegnate.
  • L'invio MCP di Telegram ripete ora solo la parte di testo interessata esattamente una volta come testo semplice, quando Telegram segnala esattamente un errore di parsing delle entità. Chat, riferimento di risposta, limite della parte e allegati successivi restano conservati.
  • Gli errori di rete, le chat sconosciute, gli errori di autorizzazione e le chiamate già inviate come testo semplice non vengono ripetuti da questo fallback. In questo modo nessun errore arbitrario viene ignorato silenziosamente e nessuna parte riuscita viene inviata due volte.
9.1.230
  • Dopo l'esclusione degli errori storici già risolti con 9.1.228 e 9.1.229, negli ultimi 1.200 risultati di strumento di un profilo agente restavano i timeout Bash ripetuti come prossimo blocco chiuso. I comandi interessati cercavano più volte ricorsivamente nell'intera directory utente o nell'intera Dropbox e terminavano dopo 60 secondi senza un completamento utilizzabile.
  • Bash rifiuta ora prima dell'avvio del processo esattamente due forme di ricerca illimitate: find su tutta la directory utente e grep ricorsivo contro ..
  • Il testo di errore nomina subito l'alternativa limitata: Glob con pattern di file ancorato, Grep con percorso/glob o una sottocartella di progetto nota. Le ricerche mirate limitate a src, test o altri sottoalberi indicati per nome restano consentite come prima.
  • Il timeout non è stato aumentato e i comandi Bash arbitrari non vengono ripetuti automaticamente. In questo modo non si hanno né un'attesa più lunga né il rischio di eseguire due volte un comando in scrittura.
9.1.229
  • Dopo la riparazione dello strumento differito, la più grande famiglia di errori contigua in una vera cronologia era il Write in più parti: campi obbligatori mancanti (part, start_line, final), un numero totale di righe indovinato in anticipo in modo errato, numeri di parte superati e uno stato di continuazione vecchio ancora attivo dopo gli errori generavano ripetizioni senza lavoro utile.
  • Numero di parte, riga di inizio e modalità vengono ora derivati dallo stato effettivamente presente in staging quando mancano. I valori inviati esplicitamente restano visibili e continuano a essere rifiutati in caso di scostamento.
  • expected_lines è opzionale e può essere fornito anche soltanto nella parte finale. Se impostato, l'overflow e il controllo finale esatto restano, come prima, bloccati per impostazione predefinita (fail-closed).
  • final=true resta obbligatorio per la chiusura. Senza questo marcatore di fine esplicito non viene scritto nulla; il file di destinazione resta invariato fino alla fine. Il controllo SHA-256 opzionale resta attivo.
9.1.228
  • Negli ultimi 1.000 veri risultati di strumento c'erano 66 errori. Il più grande blocco singolo chiaramente riparabile erano 10 errori Tool not found: nove volte mcp__mnemo__mem_transcript_recent, una volta mcp__mnemo__mem_question_answer. Entrambi gli strumenti erano registrati, ma semplicemente non caricati nel passo interessato per via del budget di token.
  • Dopo un errore esatto Tool "<name>" not found, il turno annota ora questo schema per il passo immediatamente successivo. La selezione normale lo preleva quindi dall'elenco di strumenti già registrato.
  • Gli altri testi di errore, i risultati riusciti e i nomi di strumento divergenti non modificano lo stato. Il limite LRU esistente di quattro schemi resta; in questo modo uno strumento davvero sconosciuto non viene inventato né eseguito.
  • Nessuno strumento è stato messo in modo permanente in ogni prompt. Il normale consumo di token degli schemi resta quindi invariato; solo una ripetizione di errore già pagata viene evitata a partire dal secondo tentativo.
9.1.227
  • Una vera cronologia wire conteneva 119 chiamate ToolSearch. 35 terminavano senza corrispondenze; 27 senza corrispondenze riguardavano cronologia Telegram, recupero messaggi o la relativa ricerca in memoria.
  • Con l'elenco di strumenti attuale, 9.1.226 risolve già 8 di questi 35 vecchi risultati nulli. Il caso principale residuo erano richieste sovradeterminate come +telegram history messages lesen, in cui il modello aveva contrassegnato per errore parole semantiche come componenti obbligatori del nome.
  • Da DeepAgents è stato adottato il principio di allineare avvisi e superficie degli strumenti dopo il filtraggio. Non è stato copiato codice di terzi: BLUN continua a tentare prima la ricerca esatta e rigorosa e allenta i termini + a termini di ricerca semantici solo dopo un vero risultato nullo.
  • Il ripiego non esegue alcuno strumento. Carica solo lo schema meglio valutato o i veri pareggi, richiede almeno il 75 percento di corrispondenze con più termini e resta chiuso per i termini estranei alla materia.
  • Confronto con il pacchetto 9.1.226 appena installato e le stesse 35 richieste storiche: prima 8 corrispondenze, dopo 21, quindi 13 vere corrispondenze aggiuntive e 0 corrispondenze precedenti perse.
  • Non è stata inserita alcuna nuova chiamata a modello, ricerca, rete o embedding. Cronologia grezza, esecuzione degli strumenti, autorizzazioni e insieme permanente degli schemi restano invariati.
9.1.226
  • Una vera cronologia wire conteneva 6.275 passi di modello completati. Negli ultimi 50 passi la costruzione locale della richiesta era a p50 0 ms e p90 1 ms e il consumo locale dello stream a p50 1 ms e p90 3 ms. Il tempo di attesa fino al primo token del server era invece a p50 11.842 ms e p90 14.846 ms. Un ulteriore taglio locale di micro-prestazioni non era quindi dimostrato come leva efficace.
  • Il percorso di apprendimento validato derivato da Evolver esisteva già: i riscontri da rosso a verde vengono salvati per profilo come pending, recorded o expired. Per gli utenti però non c'era una vista locale.
  • 9.1.226 aggiunge /improve con alias /learning. Il pannello mostra i tre contatori di stato e per il candidato aperto più recente solo dati di riscontro limitati e innocui: ID del candidato, nome dello strumento e dodici caratteri dell'hash del comando.
  • Il comando legge solo lo storage locale del profilo attivo. Non avvia alcuna chiamata a modello, ricerca, hub o embedding e non modifica alcun candidato. I valori di stato sconosciuti e i caratteri di visualizzazione non sicuri vengono scartati o mostrati come unknown.
  • Tutti i nuovi testi UI per tedesco, spagnolo, francese, svedese e ceco hanno superato il controllo linguistico obbligatorio e la successiva verifica della ricevuta; tutti e sei i cataloghi UI contengono le chiavi complete.
9.1.225
  • In una vera cronologia wire 88 voci config.update occupavano 4.078.566 byte. 83 di esse contenevano il system prompt completo.
  • Il prompt dichiarava un timestamp di sessione stabile, ma lo reimpostava a ogni avvio del processo. Dopo la normalizzazione di questo timestamp restavano 45 varianti semantiche e 38 ripetizioni consecutive causate solo dal nuovo timestamp.
  • Queste 38 ripetizioni occupavano 781.179 byte, cioè il 19,16 percento di tutti i byte del system prompt negli eventi di configurazione misurati. Allo stesso tempo il prefisso di prompt del provider riutilizzabile veniva modificato inutilmente dopo i riavvii.
  • 9.1.225 lega il timestamp per gli agenti principali e i sottoagenti, nuovi e ripresi, a Session.metadata.createdAt. I vecchi metadati non validi ricadono in modo difensivo sul valore in memoria precedente.
  • Cronologia grezza, contenuto del prompt, strumenti, scelta del modello e compattazione restano invariati. Non c'è alcuna chiamata aggiuntiva a modello, ricerca o embedding.
9.1.224
  • L'ultimo avvio misurato ha richiesto 16,85 secondi per l'inizializzazione parallela di cinque server MCP. La ripresa della sessione e il parse del wire erano nettamente più brevi, con circa 0,55 e 0,18 secondi rispettivamente.
  • Il percorso del turno attendeva finora questa inizializzazione MCP prima di ogni richiesta, anche se un puro saluto locale riceveva poi intenzionalmente zero strumenti nella richiesta al modello.
  • 9.1.224 adotta il limite degli strumenti caricati su richiesta dal confronto con DeepAgents: solo la breve conversazione locale senza strumenti può rispondere subito. I turni Telegram, gli allegati, i trigger di sistema e ogni richiesta di tipo operativo continuano ad attendere l'inizializzazione MCP completa.
  • La cronologia grezza, la configurazione MCP, gli schemi degli strumenti e i normali turni di lavoro restano invariati. Nessun server è stato disattivato e non è stata introdotta alcuna chiamata aggiuntiva a modello, ricerca o embedding.
9.1.223
  • Un passo 775.5 terminava vuoto con fall=length, 8.192 di 8.192 token di completamento e solo sette caratteri di reasoning. La logica precedente riavviava quindi la stessa grande richiesta e raddoppiava il budget di completamento a 16.384 token.
  • Durante l'attesa la CPU locale era intorno allo 0 percento; la costruzione della richiesta durava 0-1 ms e il trasporto circa 2 secondi. Il collo di bottiglia misurato era quindi la generazione del modello più un nuovo tentativo a budget pieno, non la TUI.
  • Solo il caso dimostrato length con budget completamente esaurito e meno di 64 caratteri di reasoning riceve ora un tentativo di ripetizione parsimonioso con fattore 0,125 e almeno 1.024 token.
  • Le risposte length ricche di reasoning e non completamente esaurite mantengono l'estensione precedente con fattore 2. Le altre classi di nuovi tentativi restano invariate.
  • Per un caso misurato il secondo budget scende da 16.384 a 1.024: 15.360 token, cioè il 93,75 percento in meno nel tentativo di ripetizione.
9.1.222
  • L'updater in esecuzione aveva passato una versione preparata via IPC al King attivo. Il launcher terminava quindi il core in esecuzione con exit 76 e doveva avviare un processo sostitutivo. Nel cambio misurato su 9.1.219 un profilo agente restava per questo disconnesso.
  • Gli aggiornamenti in background ora si limitano a scaricare e verificare la nuova versione e a depositarla per il prossimo avvio naturale. Non inviano alcun messaggio IPC di riavvio, non terminano una TUI attiva e non avviano alcun processo sostitutivo.
  • Al prossimo avvio normale di king ricompare la selezione esistente: aggiorna, salta una volta o attendi la prossima versione. Solo dopo la decisione di installazione il launcher parte dal pacchetto preparato già verificato; un secondo download non è necessario.
9.1.221
  • I messaggi invariati non ancora coperti da tokenCount usano ora esattamente una stima di token per revisione di contesto. Gli accessi ripetuti di stato e render non scansionano più di nuovo la stessa cronologia in crescita.
  • Nuove parti di testo, chiamate di strumento, modifiche alla cronologia, compattazione, undo e un numero modificato di messaggi già coperti invalidano subito la cache. Cronologia grezza, cronologia persistita e valore di token segnalato restano identici rispetto al percorso precedente.
  • Sette misurazioni con 300 messaggi sintetici e 250 richieste invariate ciascuna hanno dato in mediana 42,1218 ms -> 0,1755 ms, circa 99,583 % in meno di tempo di calcolo in questo hotpath. Entrambe le versioni hanno fornito esattamente lo stesso valore stimato di 127.838 token.
  • La versione riduce il lavoro della CPU per la stima locale. Non dichiara alcuna riduzione dei token di ingresso effettivamente inviati al modello.
9.1.220
  • La proiezione delle risposte lunghe dell'assistente salva ora il suo risultato in una WeakMap, finché oggetto messaggio, array di contenuti, parte di testo e testo sorgente esatto restano invariati. Cronologia grezza e contenuto proiettato restano identici rispetto al percorso precedente.
  • Una modifica al testo, all'array di contenuti o alla parte di testo scarta subito la voce. Oggetti messaggio diversi non condividono alcuna cache.
  • Cinque misurazioni con 1000 proiezioni ripetute ciascuna hanno dato in mediana 16,489 ms -> 0,202 ms, circa 98,8 % in meno di tempo di calcolo in questo percorso. Entrambe le versioni hanno risparmiato esattamente 21.206 caratteri.
9.1.219
  • Le semplici e brevi conferme testuali come ok, danke o le risposte DM di Telegram con un segnale di proseguimento in coda non leggono più lo store dei candidati di apprendimento validati a ogni passo del modello.
  • I prompt significativi, gli allegati e i turni con attività di strumento attuale continuano ad attivare la sincronizzazione. Un promemoria di apprendimento già visibile resta conservato anche durante una conferma saltata.
  • La misurazione reale sul pacchetto, su 50 conferme, è scesa da 50 a 0 letture della directory dei candidati. La controprova con un messaggio significativo ha letto esattamente una volta. Non è stata aggiunta alcuna chiamata a modello, embedding o rete.
9.1.218
  • In 9.1.217, lo stesso controllo da rosso a verde ha generato un secondo candidato aperto in caso di ripetizione con nuovi ID di chiamata dello strumento. La misurazione reale isolata ha dato due ID, 2 file aperti e 726 byte.
  • Dopo la registrazione solo del candidato più recente, il candidato identico più vecchio sarebbe ricomparso come promemoria. Questo avrebbe generato un secondo ciclo di promemoria e MistakeRecord per la stessa lezione aperta.
  • bin/validated-learning-signal.cjs riusa ora un candidato già aperto dello stesso profilo e dello stesso commandHash. Gli altri comandi di verifica restano separati; i candidati registrati o scaduti non assorbono alcun evento successivo.
  • La rimisurazione ha dato lo stesso ID, 1 file aperto e 363 byte. Non c'è alcuna chiamata aggiuntiva a modello, embedding o rete.
9.1.217
  • In 9.1.216 ogni MistakeRecord riuscito marcava il candidato di apprendimento aperto più recente come elaborato, anche se la voce apparteneva a un altro errore. Il riscontro era quindi persistente, ma non correlato con precisione alla sua successiva registrazione.
  • bin/validated-learning-signal.cjs legge ora la candidateId opzionale di un MistakeRecord riuscito e chiude esclusivamente il candidato aperto esattamente corrispondente. Un ID mancante, errato o estraneo lascia invariati tutti i candidati aperti.
  • blun.mjs nomina l'ID stabile del candidato nel promemoria visibile e introduce candidateId come campo opzionale nello schema MistakeRecord. Non c'è alcuna chiamata aggiuntiva a modello, embedding o rete.
  • La correlazione resta legata al profilo. Nello storage dei candidati continuano a non finire né comandi grezzi né output di strumenti.
9.1.216
  • bin/validated-learning-signal.cjs deposita ora i segnali da rosso a verde confermati a livello di installazione sotto <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/. Un candidato di apprendimento resta così conservato attraverso turni utente, compattazioni e portali diversi della stessa installazione BLUN.
  • Lo storage è legato al profilo, append-only e sicuro in caso di accessi concorrenti: per ogni candidato nasce un file JSON immutabile ed esattamente un marcatore .recorded o .expired. File temporaneo, hardlink e rimozione del file temporaneo impediscono la sovrascrittura silenziosa in caso di processi di scrittura paralleli.
  • Vengono salvati solo tipo, stato, profilo, nome dello strumento, SHA256 del comando, ID delle chiamate di strumento e timestamp. Comando grezzo, testo di errore e output riuscito dello strumento non vengono persistiti.
  • Un MistakeRecord riuscito marca il candidato aperto più recente esattamente una volta come elaborato. I candidati aperti scadono dopo 24 ore. Se manca una home condivisa, resta conservato il comportamento precedente in memoria, fail-open.
  • Non si tratta ancora di una modifica automatica del codice né di un'autorizzazione autoconcessa. La versione crea solo il riscontro di apprendimento portabile e indipendente dal portale, sul quale le future funzioni integrate di valutatore e approvazione potranno lavorare in modo sicuro.
9.1.215
  • Le soluzioni non possono presupporre né determinati agenti interni né nomi di computer interni, gruppi Telegram, istanze Mnemo o una catena di autorizzazione interna a BLUN.
  • Per il self-improvement i ruoli interni vengono astratti come funzioni di prodotto: controllore di scope/autorizzazione, valutatore isolato, riscontro versionato e rimisurazione canary automatica con rollback.
  • Sono adottabili automaticamente solo gli adattamenti a basso rischio e misurabilmente limitati con prove costantemente migliori o neutre. Codice, diritti, segreti, fatturazione e produzione richiedono comunque l'intervento dell'utente o dell'amministratore.
  • La prima implementazione del controllo integrato viene collaudata manualmente a livello interno; in seguito il controllo può effettuare verifiche in autonomia, ma non modificare il proprio confine di sicurezza.
9.1.214
  • 9.1.213 stabiliva il corretto percorso di salvataggio persistente tramite MistakeRecord, ma si aspettava ancora che il modello riconoscesse da solo il momento giusto dalla cronologia degli strumenti.
  • È stato aggiunto bin/validated-learning-signal.cjs: il modulo considera solo il turno utente attuale e riconosce esclusivamente lo stesso comando shell di verifica che prima fallisce e poi riesce.
  • Un injector dinamico in blun.mjs ricorda in questo caso dimostrato di fissare una lezione riutilizzabile con MistakeRecord. Testo del comando ed errore grezzo non vengono copiati nell'avviso.
  • Gli altri comandi, i normali errori di lettura/strumento, un nuovo turno utente o una chiamata MistakeRecord già riuscita non generano né mantengono alcun avviso. Non avviene alcun salvataggio automatico.
9.1.213
  • Il contratto di missione richiedeva la chiamata record_error_memory dopo una prova riuscita da rosso a verde. Questo strumento non esiste nel pacchetto King. Il percorso di apprendimento persistente esistente si chiama MistakeRecord e scrive nella Mistake.md comune.
  • Così la disciplina di Evolver era già formulata, ma l'ultimo passo verso la nostra memoria propria, condivisa tra agenti, non funzionava: una soluzione confermata poteva seguire il contratto e restare comunque senza salvataggio persistente.
  • Il contratto chiama ora MistakeRecord dopo l'esecuzione verde ripetuta. Gli errori grezzi restano fuori; viene salvata solo la lezione confermata da una controesecuzione riuscita.
  • Mistake.md, la sua selezione di rilevanza e il suo formato di archiviazione non sono stati sostituiti né modificati. È stata riparata esclusivamente la connessione dal contratto di apprendimento validato allo strumento esistente.
  • Sono stati modificati solo blun.mjs, il nuovo test strutturale test/validated-learning-route.test.js e la versione in package.json.
9.1.212
  • L'iniettore ErrorMemory formattava più geni di strategia anche per i puri saluti e le brevi conferme. Mistake.md e la memoria personale avevano già per la stessa classe di messaggi un confine di rilevanza comune; solo ErrorMemory lo aggirava.
  • L'iniettore usa ora anch'esso isLowInformationMistakeTurn e termina la proiezione prima della selezione e della formattazione dei geni di strategia. Le voci di errore e strategia persistite restano invariate; scompare solo la loro proiezione inutile nelle richieste minime.
  • Caso di riferimento misurato Wie geht es dir? con undici voci salvate: prima cinque regole selezionate, 1.417 caratteri, ovvero circa 355 token; dopo 0 caratteri e 0 token.
  • Sono stati modificati solo blun.mjs, test/error-memory-performance-policy.test.js e la versione in package.json.
9.1.211
  • Il King conferma le righe di coda solo quando il messaggio è stato accettato. Prima di una sessione attiva, injectChannelEnvelope scarta però un messaggio indirizzato come dropped, senza confermarlo né parcheggiarlo. Il checkpoint può così restare bloccato in modo persistente esattamente su questa prima riga.
  • Vera prova in rosso _proof/telegram-profile-checkpoint-red.cjs: atteso queued, misurato dropped, exit 1.
  • Lo stesso errore si trova nel percorso dei comandi Telegram: /loop prima di una sessione attiva non viene messo in queuedMessages; la funzione di acknowledge resta senza consumatore. Vera prova in rosso _proof/telegram-remote-command-presession-red.cjs: attesa lunghezza coda 1, misurata 0, exit 1.
  • injectChannelEnvelope tratta ora una sessione non ancora pronta a ricevere messaggi come una sessione occupata: testo del modello, origine di visualizzazione e conferma successiva restano nella coda di canale esistente.
  • injectTelegramRemoteCommand costruisce la voce di coda prima del controllo di sessione. /loop e gli altri comandi Telegram diretti vengono parcheggiati con la loro funzione channelAcknowledge quando la sessione manca e vengono eseguiti solo al confine sicuro esistente.
  • L'ordine e la regola di checkpoint esistente restano invariati: una riga di coda viene confermata solo dopo l'accettazione; le conferme successive non possono saltare una riga precedente ancora aperta.
9.1.210
  • L'handoff attivo di 9.1.208/9.1.209 poteva terminare un King in esecuzione per un aggiornamento. Sull'MSI la sessione in esecuzione è stata così terminata al passaggio 9.1.206 -> 9.1.207 e non è stata ripresa automaticamente.
  • 9.1.209 non è stato quindi inserito nel manifest pubblico ed è stato marcato su npm come non distribuibile.
  • La direttiva è ora imposta tecnicamente: un aggiornamento automatico non può mai terminare il King in esecuzione. Viene solo scaricato e contrassegnato come pending. L'attivazione avviene solo a un successivo avvio normale.
9.1.209 Ritirata
  • Non pubblicata. L'handoff di aggiornamento attivo poteva terminare un King in esecuzione; per questo la versione non è entrata nel manifest pubblico ed è stata marcata su npm come non distribuibile.
9.1.208
  • Sull'MSI sono stati misurati in un giorno 27 avvii di King e 15 versioni diverse. I riavvii coincidevano ogni volta con salti di versione; nel log locale non viene ancora registrato un motivo di uscita specifico.
  • L'updater preparava nuove versioni del manifest a cadenza di minuti. La versione 9.1.208 introduce quindi una finestra di quiete di 30 minuti prima che possa essere attivato un ulteriore nuovo runtime.
  • Le vecchie versioni del runtime vengono limitate dopo un'attivazione riuscita alle tre versioni più recenti. Si elimina solo se tutti i lease di installazione della versione precedente sono stati acquisiti in modo esclusivo. I layout attivi, occupati o sconosciuti restano intoccati.
  • La logica di protezione vive anche nel core appena caricato. Così interviene dopo l'attivazione automatica anche quando il launcher padre persistente proviene ancora da una versione più vecchia.
  • Le otto versioni misurate sull'MSI occupavano insieme solo 778 MB. Non spiegano il disco quasi completamente pieno da 454 GB; il grande consumatore resta un problema aperto separato.
9.1.207
  • I nuovi tentativi per la telemetria non inviata vengono limitati per esecuzione ai 16 file più vecchi e si fermano al primo errore di server temporaneo, invece di continuare a smaltire l'intero arretrato.
  • Lo spool degli errori conserva i 512 file più recenti entro 16 MiB e sette giorni. Il normale file events.jsonl è esplicitamente escluso dalla pulizia.
  • Prima della versione c'erano realmente 4.248 file di errore con 11.631.974 byte. Dopo l'attivazione automatica c'erano 512 file con 2.260.908 byte: 3.736 vecchi file di errore e circa 9,37 MB di carico in meno.
9.1.206
  • Le grandi risposte dell'assistente già archiviate vengono ora sostituite prima della proiezione del loop dal loro riferimento di archivio limitato e rileggibile. Una successiva pulizia del testo non può più invalidare l'hash salvato.
  • Tre file di archivio reali sono stati verificati byte per byte contro i loro hash SHA256 dei messaggi salvati: 38.567, 13.941 e 24.787 caratteri, tutti presenti e tutti esattamente corrispondenti.
  • Sulle stesse identiche 41.480 voci wire con 311 messaggi la proiezione del modello è scesa da 87.724 a 63.234 caratteri: altri 24.490 caratteri, ovvero circa 6.123 token di ingresso in meno per chiamata interessata.
  • La cronologia grezza e i file di archivio privati completi restano invariati e sono leggibili pagina per pagina tramite il loro percorso.
9.1.205
  • I loop di risposta all'interno di un messaggio dell'assistente vengono ora riconosciuti anche con piccole differenze di punteggiatura o formulazione. Un cluster richiede almeno tre corrispondenze con somiglianza conservativa 0,88; la prima versione resta conservata e la cronologia grezza non viene modificata.
  • In un caso conservato una risposta in loop reale è scesa da 24.787 a 22.711 caratteri: 2.076 caratteri, ovvero circa 519 token di ingresso in meno.
  • I blocchi di codice delimitati (code fence) restano protetti byte per byte. La narrazione degli strumenti, le iniezioni, le coppie e i risparmi sotto 1.000 caratteri restano invariati.
9.1.204
  • La memoria degli errori non carica più alla cieca tutte le undici regole per ogni ciclo di lavoro. Le quattro regole imprescindibili di prova e controprova 4, 9, 10 e 11 restano sempre attive; al massimo altre due regole vengono aggiunte in modo deterministico in base all'incarico attuale.
  • Nella vera raccolta di regole distribuita il blocco ripetuto è sceso da 2.442 a 1.272 caratteri: 1.170 caratteri, ovvero circa 293 token di ingresso in meno per ciclo di lavoro interessato.
  • La selezione non genera alcuna richiesta a modello, ricerca, reranker o embedding. Le piccole raccolte di regole proprie restano complete; in caso di errore del selettore continua ad agire il blocco completo precedente.
9.1.203
  • Una ToolSearch vuota è ora un risultato nullo concluso con successo invece di un errore di strumento rosso. La risposta nomina lo strumento autorizzato mancante e vieta una ripetizione con sinonimi.
  • In una cronologia misurata c'erano 32 ricerche vuote con 29 formulazioni; in un turno conservato la stessa capacità Telegram mancante veniva richiesta di nuovo direttamente con una seconda ricerca dopo l'errore rosso.
  • Nessuna richiesta aggiuntiva a modello, reranker o embedding, nessun nuovo schema residente e nessuna modifica a strumenti o autorizzazioni.
9.1.202
  • Con directory di lavoro grandi, la proiezione di contesto locale derivata da DeepAgents mostra di preferenza le voci di primo livello invece dei dettagli profondi delle prime cartelle. Le piccole liste di directory restano byte per byte identiche.
  • La root di un agente contiene 509 voci di primo livello (89 cartelle, 420 file). Prima la proiezione del modello mostrava in 1.981 caratteri solo 9 cartelle di primo livello; ora ne mostra 30 in 832 caratteri.
  • Risparmio misurato: 1.149 caratteri, ovvero circa 287 token per richiesta. Persona, regole di lavoro, cronologia grezza e accesso agli strumenti restano invariati.
9.1.201
  • Un'igiene di proiezione derivata da DeepAgents compatta la memoria statica degli errori senza perdere nessuna delle 11 regole o verifiche salvate.
  • I vecchi testi dettagliati della memoria degli errori vengono compattati solo nella proiezione del modello. Cronologia grezza, risposte normali e risultati degli strumenti restano invariati.
  • Nella proiezione vengono conservate solo l'ultima iniezione di errore e l'ultima iniezione di correzione dell'errore.
9.1.200
  • Il nuovo comando locale /context mostra separatamente la richiesta al modello effettivamente proiettata, la cronologia di conversazione salvata, gli schemi degli strumenti, il budget di compattazione e il margine residuo.
  • La vista legge esclusivamente session.getContext(). Non avvia alcuna richiesta al modello, alcuna interrogazione di consumo gestita, alcun servizio e alcun riavvio.
  • I risultati di strumento esternalizzati indicano ora un percorso di rilettura esatto: Read con al massimo 20 righe, proseguendo poi con il line_offset successivo. Questo impedisce lo schema misurato, in cui un agente richiedeva di nuovo la stessa grande area con Read, Grep e Bash.
  • /premortem era già presente prima della 9.1.200 e, per scelta esplicita, non viene presentato come nuova funzione di questa versione.
  • Per le nuove traduzioni il controllo linguistico obbligatorio non ha dato alcuna autorizzazione a causa della mancata verifica indipendente dei testi brevi. Per questo /context usa solo etichette localizzate già autorizzate; nessun testo tradotto non verificato è stato incluso.
9.1.199
  • Una vista modello attuale conteneva in una singola risposta dell'assistente 13.941 caratteri con 100 blocchi di paragrafo. Solo 20 blocchi erano univoci; sei gruppi si ripetevano esattamente e occupavano 9.579 caratteri.
  • 9.1.199 compatta esclusivamente tali ripetizioni esatte all'interno di una singola risposta di testo puro nella vista modello. La cronologia grezza della sessione resta invariata.
  • La compattazione interviene solo da tre ripetizioni esatte e almeno 1.000 caratteri risparmiati. Blocchi di codice, contenuti misti, chiamate di strumento, messaggi di iniezione, blocchi brevi e risparmi minori restano invariati.
  • Questo segue il principio DeepAgents di conservare la verità rileggibile e di alleggerire solo la vista modello attiva. Non c'è alcuna chiamata aggiuntiva a modello o embedding.
9.1.198
  • Una cronologia attuale conteneva un risultato che lo strumento aveva già marcato con truncated: true, restituito da Grep e lungo 50.042 caratteri. L'esternalizzazione dei singoli risultati riconosceva sì la dimensione, ma lasciava tali risultati comunque completamente nella vista modello attraverso un ritorno anticipato.
  • 9.1.198 rimuove esclusivamente questa eccezione. Un Read troncato usa il percorso sorgente esistente senza duplicato; gli altri risultati troncati archiviano esattamente il testo completo restituito dallo strumento.
  • Il riferimento conserva truncated: true e riporta stored_result_scope: tool_truncated_output. Così non viene affermato che sia stato ripristinato un output grezzo che lo strumento non ha mai fornito.
  • Il pattern segue DeepAgents: i grandi output di strumento restano rileggibili al di fuori della vista modello attiva, mentre lì resta solo un piccolo riferimento.
9.1.197
  • Anche le pure conferme testuali come ok caricavano finora il promemoria dinamico di Mistake.md. Con l'attuale corpo di regole comune erano 1.819 caratteri di prompt, circa 455 token, anche se nessun contesto di lavoro veniva proseguito.
  • 9.1.197 riconosce esclusivamente i turni di testo puro a bassa informazione prima che venga letta una delle due fonti Mistake e in quei casi omette l'iniezione dinamica.
  • Gli allegati, i contenuti non testuali e le prosecuzioni significative come ok, check updater mantengono il percorso precedente. Il fallback di rilevanza esistente per i veri turni di lavoro resta invariato.
  • Il pattern proviene dal lavoro di confronto con AnythingLLM: le fonti di contesto opzionali devono arrivare nella vista modello solo quando il turno attuale ne ha realmente bisogno. È stato inserito nella policy BLUN esistente senza chiamata aggiuntiva a modello o embedding.
9.1.196
  • /reload era presente localmente, ma da Telegram non veniva riconosciuto come comando diretto. L'allowlist Telegram non conteneva il nome; il messaggio restava quindi normale testo del modello.
  • 9.1.196 aggiunge esclusivamente reload alla lista esistente di comandi Telegram indirizzati.
  • Il percorso Telegram usa lo stesso handler esistente della TUI locale: sessione, server MCP e configurazione del runtime e della TUI vengono ricaricati nel processo in esecuzione. Non viene avviato alcun ciclo del modello né alcun riavvio del processo.
  • /new e gli altri messaggi slash non autorizzati restano normale testo del modello.
9.1.195
  • Gli aggiornamenti automatici venivano eseguiti, ma la TUI riavviata finiva su C:\ invece che nella cartella di progetto precedente.
  • La TUI teneva la cartella corretta in state.appState.workDir, ma nell'handoff di aggiornamento passava solo sessione, versione e modalità. Il launcher usava quindi la sua cartella di avvio originale per destinazione e ripiego.
  • 9.1.195 trasporta la cartella di progetto attiva nell'handoff e la usa per versione di destinazione, ripiego e ulteriori aggiornamenti automatici della stessa supervisione.
  • Vengono accettate solo directory assolute esistenti. Le indicazioni relative, mancanti o che puntano a file ricadono sulla cartella del launcher.
9.1.194
  • Il watchdog esistente del turno avvertiva dopo 20 minuti, ma non terminava poi un turno. Sul Mac un turno bloccato continuava dopo l'avviso dei 30 minuti fino almeno al minuto 39.
  • 9.1.194 mantiene l'avviso dopo 20 minuti e termina un turno dopo 30 minuti senza vero progresso.
  • Inizio del passo, testo di thinking, testo dell'assistente, chiamata di strumento, argomenti dello strumento, progresso dello strumento e risultato dello strumento azzerano il termine di inattività. Il lavoro lungo e attivo non viene così terminato.
  • L'interruzione esistente dopo cinque chiamate di strumento fallite identiche resta attiva, separata e invariata.
9.1.193
  • Più consegne Telegram arrivavano con identica chat_id e message_id fino a quattro volte nella stessa sessione.
  • 9.1.181 rimuoveva queste ripetizioni solo più tardi dalla vista modello. Prima, ogni copia poteva già innescare un proprio turno del modello e quindi costi.
  • 9.1.193 introduce quindi prima dell'avvio del turno un registro di consegna limitato a 2.048 identificatori. Lo stesso identificatore Telegram viene accettato una sola volta per sessione; le ripetizioni vengono confermate, ma non registrate e non avviano alcun turno del provider.
  • I nuovi identificatori di messaggio, le iniezioni non utente e la cronologia grezza restano invariati. Alla ripresa il registro viene ricostruito dai record di prompt accettati.
9.1.192
  • Dopo un'autorizzazione Bash rifiutata, un Mac continuava a mostrare King is thinking per 39 minuti. La chiamata di strumento era stata rifiutata correttamente, ma il rifiuto veniva restituito come normale risultato di errore al ciclo del modello in esecuzione.
  • PermissionManager.requestToolApproval() in caso di rifiuto restituiva solo block: true. Il controllo batch e provider esistente poteva già terminare il turno con syntheticResult.stopTurn = true, ma non riceveva questo segnale.
  • È stato aggiunto bin/approval-rejection-stop.cjs. Le autorizzazioni rifiutate e annullate generano ora un risultato di errore esistente con stopTurn: true. Il turno attuale termina e le chiamate successive dello stesso stack di strumenti vengono saltate. Registro delle autorizzazioni, policy e comportamento fail-closed restano invariati.
  • DeepAgents ha confermato il confine esplicito di interruzione umana come pattern adatto. AnythingLLM ed Evolver non offrivano per questo errore circoscritto alcun meccanismo più forte del contratto BLUN già esistente.
9.1.191
  • DeepAgents offre con /context una suddivisione familiare e visibile della finestra di contesto invece di un solo valore complessivo.
  • Per il lavoro sulle prestazioni, Evolver richiede un budget di prompt separato per parte di sistema, conversazione, strumenti e spazio libero.
  • AnythingLLM risparmia schemi di strumenti tramite reranking basato su embedding. BLUN possiede già per questo il percorso di strumenti differito più economico senza chiamata aggiuntiva a modello o embedding; questa parte non è stata quindi duplicata.
9.1.190
  • Dagli eventi di loop tool.call salvati in modo persistente vengono rimossi solo i campi di visualizzazione display e description. Identità, nome dello strumento, argomenti e assegnazione al passo restano conservati.
  • Il runtime continua a elaborare l'evento completo. Visualizzazione TUI, esecuzione degli strumenti e ripresa non sono state convertite alla proiezione.
  • Un vero wire di un agente con 42.451.368 byte conteneva 6.135 chiamate di strumento. In 5.679 di esse potevano venire meno 3.125.874 byte: il 7,36 % dell'intero log wire.
9.1.189
  • Un utente aveva scelto il bosniaco e scritto in bosniaco, ma King rispondeva in sloveno. Nel prompt della persona c'era solo la parola inglese Bosnian; l'area linguistica strettamente affine non era delimitata esplicitamente.
  • Kako si?, Kako je King?, Ko si ti? e Ko stoji iza tebe? non funzionavano come brevi dialoghi autonomi in bosniaco. Lo screenshot relativo a Ko stoji iza tebe? mostrava addirittura ricerche web invece di una risposta diretta.
  • Il semplice check-in segnalato consumava circa 7.500 token. Il precedente percorso Low Effort permetteva fino a 8.192 token di completamento e conservava diversi vecchi messaggi.
9.1.188
  • BLUN riconosceva una vera ricaduta già dopo tre risposte simili, ma lasciava le risposte superate completamente nella vista modello. L'avviso contro il loop continuava quindi a competere con il vecchio stato errato.
  • DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 fornisce il pattern di messaggi sostitutivi limitati e stabili per indice. AnythingLLM dà priorità alle coppie di conversazione più recenti e tratta la cronologia come contesto comprimibile per primo.
  • Un wire conteneva 42.265.671 byte, di cui 25.423.100 byte di context.append_loop_event. Questo dimostra il carico reale dei loop, ma non viene presentato come risparmio diretto di token di richiesta.
9.1.187
  • Il manifest 9.1.184 distribuito live riportava il timestamp 2026-08-26T12:15:06.5196457Z. Il parser distribuito permetteva solo da uno a tre decimali e scartava per questo l'intero manifest.
  • Senza fallback valido diventava determinante solo npm. Allo staging di 9.1.185 il tag npm era quindi brevemente visibile, anche se il manifest era ancora a 9.1.184.
  • Il tag npm è stato riportato a 9.1.184. Il manifest live è stato corretto solo nel timestamp a 2026-08-26T12:15:06.519Z; versione e integrità sono rimaste invariate. Tre richieste con cache ripulita e il vero parser client hanno poi confermato il manifest.
  • SHA256 live dopo la riparazione: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Copia di sicurezza: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • Dopo una compattazione completa il system prompt esistente non viene più sovrascritto con dati di contesto locali riletti. Il suo prefisso precedente resta quindi stabile in byte e riutilizzabile per la cache del provider.
  • Directory di lavoro, file AGENTS.md corrispondenti e directory aggiuntive ricevono un fingerprint. Solo in caso di modifica reale il nuovo stato viene aggiunto come messaggio di contesto interno, invisibile per l'utente.
  • I dati di contesto incorporati vengono sottoposti a escaping prima della marcatura interna. Un testo locale non può quindi chiudere il confine di marcatura né introdurre nuovi avvisi di sistema.
9.1.185
  • Due profili agente si erano disconnessi nel contesto temporale dell'aggiornamento automatico. Indipendentemente da questo, dopo un passaggio riuscito da 9.1.182 a 9.1.183 un terzo profilo è rimasto fermo su questa versione e non ha preparato 9.1.184.
  • Due errori concreti sono stati dimostrati nel percorso sorgente: la TUI terminava direttamente dopo process.send, senza attendere la conferma IPC. Inoltre, dopo un handoff riuscito, il launcher attendeva solo la fine del nuovo processo e non allestiva per esso alcuna ulteriore sorveglianza degli aggiornamenti.
9.1.184
  • Le normali chiamate al modello includevano in modo persistente gli schemi di strumento di GenerateImage e GenerateVideo, anche se l'uso misurato degli strumenti conteneva solo una chiamata immagine e nessuna chiamata video su 3.183 chiamate.
  • 9.1.184 rimuove entrambi gli schemi dal set di base caricato in modo persistente. Un incarico esplicito di immagine, video o animazione carica nello stesso turno solo lo schema realmente necessario.
  • Lo stesso percorso di selezione vale anche quando un incarico media arriva durante un turno in corso. Le domande sulla qualità, i controlli dei media e le idee non vincolanti per dopo non caricano alcuno schema di generazione.
  • Entrambi gli strumenti restano disponibili tramite ToolSearch. La modifica non rimuove alcuna capacità, ma sposta gli schemi usati raramente fuori dalle normali chiamate al modello.
9.1.183
  • BLUN King 9.1.183 rende la consegna automatica Telegram dei media completati resistente agli errori di upload temporanei.
  • Il client riprova un numero limitato di volte, esclusivamente in caso di errori temporanei, ricostruisce l'upload multiparte a ogni tentativo e si interrompe subito in caso di errori persistenti.
  • I tentativi di consegna esauriti vengono registrati separatamente, senza esporre il token del bot né sopprimere il normale invio di ripiego.
9.1.182
  • Questa versione corregge esclusivamente l'aggiornamento automatico di una sessione King in esecuzione.
  • Il launcher impostava finora BLUN_NO_AUTO_UPDATE=1 nello stesso ambiente usato sia dal core protetto sia dalla preparazione degli aggiornamenti del processo padre. Il vecchio updater nel core era quindi correttamente disattivato, ma anche il nuovo controllore degli aggiornamenti del processo padre terminava prima del recupero del manifest pubblico.
  • 9.1.182 conserva per il processo padre una disattivazione impostata esplicitamente. La disattivazione forzata viene ora aggiunta solo all'avvio del core protetto.
  • Mnemo resta una configurazione interna e locale. Il pacchetto pubblico non contiene Mnemo. La voce additiva resta completamente inattiva senza un percorso Mnemo locale e un'identità di agente impostata esplicitamente.
9.1.181
  • Gli incarichi utente lunghi identici ripetuti e i doppi ID di consegna Telegram vengono rimossi esclusivamente dalla proiezione del modello; la cronologia grezza resta invariata.
  • Un Mnemo-MCP configurato viene ora aggiunto al profilo TUI di King attivo, invece di restare limitato alle sessioni del bridge Telegram.
  • Tutti i 413 test sono passati; entrambe le prove di mutazione mirate diventavano rosse non appena veniva rimossa una delle misure di protezione.
9.1.180
  • La preparazione automatica dell'aggiornamento non dipende più esclusivamente dal successivo IPC TUI-ready. Appena il core protetto è dimostrabilmente caricato, il launcher avvia la preparazione anche quando questo secondo segnale è andato perso.
  • Il confine di sicurezza per il passaggio vero e proprio resta invariato: risposta in corso, compattazione, coda di messaggi, strumenti, comandi shell e comandi in coda continuano a impedire un riavvio nel mezzo del lavoro.
  • Lo stato effettivo dimostrava l'errore: modalità resume, installazione 9.1.177, pubblico 9.1.179, ma preparata solo 9.1.176. Il loop non era quindi il primo blocco, perché il controllo di inattività interviene solo dopo la preparazione.
9.1.179
  • Le pure conferme come ok, ja, danke o perfekt saltano il broker di memoria personale. Questo risparmia una chiamata al broker e previene in questi turni poveri di contenuto fino a 16.384 caratteri di inutile iniezione di memoria.
  • weiter, gli allegati, le domande, i comandi e gli altri messaggi con contenuto mantengono il precedente percorso di memoria tra portali.
  • Un buffer di argomenti costruito per primo, simile a DeepAgents, era in quattro di cinque giri di misura più lento della semplice concatenazione. È stato completamente scartato e non pubblicato.
9.1.178
  • La ricerca di strumenti differita riconosce ora un primo termine esatto univoco. GetMedia media job status result carica così GetMedia, senza ripiegare su un'ampia supposizione semantica. I nomi brevi ambigui restano intenzionalmente irrisolti.
  • La catena di produzione dei media manda a capo i nomi di fase completi sulle righe successive. L'ultimo passo non viene più tagliato al margine destro.
  • La modifica migliora la selezione degli strumenti e la leggibilità. Non modifica né il modello dei media né la qualità delle immagini e non afferma di offrire una vera anteprima dei media.

Miglioramenti dalla 9.1.57

VersioneModifica
9.1.177Gli aggiornamenti automatici assumono ora una modalità di ripresa o riavvio salvata anche quando il messaggio diretto al processo non arriva, e mostrano subito prima del riavvio sicuro della TUI un avviso chiaro. I segnaposto storici per argomenti di strumento compattati vengono rimossi in qualunque forma si presentino (JSON compatto, JSON formattato o oggetto letto) prima che possano essere eseguiti di nuovo. Cronologia grezza e tutti i meccanismi di protezione esistenti dell'aggiornamento restano invariati.
9.1.176Tutti i menu di selezione per i comandi slash separano ora le opzioni con una riga vuota e mostrano le spiegazioni in un proprio colore secondario sobrio. Il componente comune alimenta 20 chiamate di menu; i colori di avviso individuali restano conservati.
9.1.175L'avviso di strumento ripetuto a ogni richiesta al modello scende da 1.749 a 825 caratteri. Nella misurazione risparmia circa 231 token di ingresso stimati per richiesta. Tutti gli undici obblighi di comportamento restano conservati; cronologia grezza, schemi di strumenti e file restano invariati.
9.1.174Lo stralcio rilevante di Mistake.md mostrato per ogni richiesta al modello è ora limitato a 3.000 invece di 4.000 caratteri. In 100 vere richieste risparmia in media circa 253 token di ingresso stimati; le intestazioni selezionate restavano identiche in tutti i 100 casi. I file completi e la cronologia salvata restano invariati.
9.1.173BLUN King riconosce le risposte di testo puro ricorrenti attraverso più turni Telegram. Dopo tre risposte quasi uguali nonostante nuovi avvisi utente, l'agente riceve una volta un avviso di correzione interno, invece di emettere di nuovo una vecchia domanda, lista o attesa. Messaggi, processi e cronologia salvata restano invariati.
9.1.172L'aggiornamento automatico controlla di nuovo una sessione in esecuzione dopo una ricerca senza risultato all'avvio. Il controllo successivo avviene dopo un intervallo casuale compreso tra 60 e 90 secondi. Così le versioni pubblicate più tardi vengono riconosciute senza riavvio manuale. Installazione e passaggio di sessione continuano ad attendere la piena inattività.
9.1.171BLUN King conserva ora per turno solo i quattro schemi di strumento caricati su richiesta più di recente invece di dodici. Gli strumenti più vecchi restano reperibili tramite ToolSearch e vengono ricaricati alla selezione. Gli strumenti di base caricati in modo persistente, la cronologia salvata e il comportamento di esecuzione restano invariati.
9.1.170Raggruppa gli errori attuali di affidabilità e flusso di lavoro: i compiti ricorrenti conservano la più recente istruzione sovradimensionata; i segnaposto di argomenti di strumento compattati vengono rimossi dalla proiezione del modello; ToolSearch riconosce le parole di ricerca naturali relative alla memoria, incluso il singolo termine «store»; la visualizzazione dei loop ricarica lo stato di pianificazione; /update controlla il passaggio sicuro in stato di inattività; e /premortem fornisce un'analisi degli errori visibile e strutturata.
9.1.169BLUN King conserva invariata la selezione esatta degli strumenti e la precedente ricerca rigorosa per parole chiave. Solo quando questa ricerca non dà risultati, una seconda esecuzione ristretta cerca termini tedeschi e inglesi affini. I requisiti di nome con + restano vincolanti; devono corrispondere almeno due termini portatori di significato e il 75 percento della richiesta. Così le tre ricerche Telegram realmente fallite trovano l'attuale strumento di coda, mentre una richiesta inadatta continua a terminare senza risultati.
9.1.168BLUN King non sostituisce più gli argomenti più vecchi delle chiamate di strumento con un segnaposto interno che il modello può copiare in una nuova chiamata. Le chiamate segnaposto già esistenti e i loro risultati di errore associati vengono rimossi solo dalla proiezione del modello; la cronologia invariata della sessione resta conservata come prova.
9.1.167BLUN King 9.1.167 conserva per gli incarichi pianificati ricorrenti solo una sequenza senza lacune dei più recenti blocchi di lavoro completi. Se il blocco più recente successivo dovesse superare il limite di 48.000 caratteri o 24 messaggi, la selezione termina invece di includere poi di nuovo blocchi più vecchi e piccoli. Così contesto e ordine temporale restano coerenti. In una cronologia in corso misurata la cronologia proiettata è scesa da 32.591 a 16.981 caratteri. Risparmia 15.610 caratteri, ovvero circa 3.903 token di ingresso stimati per richiesta comparabile. Cronologia grezza, passi dell'incarico attuale e riassunto di compattazione restano invariati.
9.1.166BLUN King 9.1.166 limita gli incarichi pianificati ricorrenti a un contesto di lavoro isolato, invece di trasmettere di nuovo a ogni passo del modello l'intera conversazione dell'agente principale. L'incarico attuale, il riassunto di compattazione più recente e i passi di lavoro reali più recenti restano disponibili entro un limite di 24 messaggi e 48.000 caratteri. La cronologia salvata, i turni utente normali, i promemoria singoli e i percorsi di conversazione veloce restano invariati. In una cronologia misurata 2.043 passi di modello di incarichi pianificati ricorrenti consumavano complessivamente 298,7 milioni di token di ingresso, in media 146.188 token per passo.
9.1.165BLUN King 9.1.165 limita il budget di output dei turni normali a 24.576 invece di 32.768 token. I passi leggeri mantengono il loro precedente limite di 8.192 token, i modelli con limiti di output minori mantengono questi valori più bassi e un'impostazione esplicita dell'utente continua ad avere la precedenza. Delle 27.049 risposte misurate, il 99 percento restava sotto i 9.970 token; dodici vecchi valori anomali raggiungevano esattamente il precedente limite di 32.768 token e calcolavano ciascuno per circa sei minuti in più.
9.1.164BLUN King 9.1.164 limita il budget di output di una compattazione su finestre di modello grandi a 16.384 invece di 131.072 token. 39 compattazioni riuscite richiedevano al massimo 10.781 token di output. Il nuovo limite supera del 52 percento questo massimo misurato e riduce il possibile fabbisogno di output e di cache KV per compattazione dell'87,5 percento. Cronologia salvata e turni di conversazione normali restano invariati.
9.1.163BLUN King 9.1.163 sostituisce i grandi caricamenti di skill al di fuori degli ultimi 20 messaggi nella proiezione del modello con un riferimento compatto di ricaricamento. I caricamenti di skill attuali, piccoli e non ricaricabili restano invariati; la cronologia di conversazione salvata non viene riscritta. In un caso misurato un caricamento di skill scende da 87.034 a 424 caratteri proiettati. Appena esce dalla finestra di lavoro attuale, risparmia 86.610 caratteri, ovvero circa 21.653 token di ingresso stimati.
9.1.162BLUN King 9.1.162 limita le grandi panoramiche della directory di lavoro nel system prompt ripetuto a 2.000 caratteri. Le panoramiche piccole restano invariate. Per le panoramiche accorciate un avviso chiaro continua a indicare la ricerca completa con Glob, Grep e Read. In un prompt misurato la panoramica scende da 3.988 a 1.983 caratteri. Risparmia 2.005 caratteri, ovvero circa 501 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.161BLUN King 9.1.161 non ripete più i nomi dei 112 strumenti esternalizzati in ogni descrizione ToolSearch. La ricerca per parola chiave, la selezione esatta in base al nome completo o al nome breve univoco e il caricamento persistente dei dodici schemi selezionati per ultimi restano conservati. Nella rappresentazione misurata la descrizione ripetuta scende da 1.984 a 278 caratteri. Risparmia 1.706 caratteri, ovvero circa 426 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.160Da BLUN King 9.1.160 la proiezione del modello protegge completamente solo i dodici messaggi più recenti, prima che i risultati di strumento riusciti più vecchi, contenenti esclusivamente testo, vengano sostituiti da una breve nota di chiusura. Output di errore, media, riferimenti a file salvati, i dodici messaggi più recenti, cronologia grezza ed esportazioni restano invariati. In uno snapshot di sessione, misurato in condizioni stabili, vengono così ridimensionati altri due vecchi risultati di strumento. La proiezione del modello scende da 81.800 a 78.402 caratteri. Risparmia altri 3.398 caratteri, ovvero circa 850 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.159Da BLUN King 9.1.159 gli argomenti JSON validi delle chiamate di strumento concluse al di fuori dei 12 messaggi più recenti vengono sostituiti nella proiezione del modello da una breve nota. Il risultato di strumento associato, i 12 messaggi più recenti, le chiamate non concluse, gli argomenti piccoli o non validi, la cronologia grezza e le esportazioni restano invariati. In uno snapshot di sessione, misurato in condizioni stabili, tre argomenti di chiamate di strumento concluse vengono ridimensionati da 2.849 a 165 caratteri. Risparmia 2.684 caratteri, ovvero circa 671 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.158Da BLUN King 9.1.158 i puri messaggi di stato che seguono immediatamente una risposta Telegram conclusa e si trovano al di fuori dei 20 messaggi più recenti vengono sostituiti nella proiezione del modello da una breve nota. La chiamata di risposta inviata e il suo risultato, i messaggi attuali, i riassunti dopo altri strumenti, i contenuti misti, la cronologia grezza e le esportazioni restano invariati. In uno snapshot di sessione, misurato in condizioni stabili, sei messaggi di stato storici vengono ridimensionati di 1.837 caratteri. Risparmia circa 460 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.157Da BLUN King 9.1.157 gli output di strumento riusciti, adatti e puramente testuali al di fuori dei 20 messaggi più recenti vengono sostituiti nella proiezione del modello da una breve nota di chiusura. Output di errore, media, riferimenti a file esternalizzati, i 20 messaggi più recenti, cronologia grezza ed esportazioni restano invariati. In uno snapshot di sessione, misurato in condizioni stabili, vengono ridimensionati 43 vecchi risultati. Risparmia 9.680 caratteri, ovvero circa 2.420 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.156Da BLUN King 9.1.156 i riferimenti salvati a messaggi utente al di fuori dei 20 messaggi più recenti non ripetono più la loro anteprima con inizio e fine a ogni richiesta al modello. Marcatura di ripristino, indicazioni di dimensione, percorso file leggibile, i 20 messaggi più recenti, media, cronologia grezza, file salvato completo ed esportazioni restano invariati. In uno snapshot, misurato in condizioni stabili, vengono ridimensionati cinque riferimenti storici e la proiezione del modello scende da 99.143 a 96.001 caratteri. Risparmia altri 3.142 caratteri, ovvero circa 786 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.155Da BLUN King 9.1.155 i riferimenti salvati a messaggi utente vengono ripristinati prima che le proiezioni di testo possano modificare l'hash del messaggio originale. Le esternalizzazioni esistenti restano così efficaci, invece di ricadere inosservate sul messaggio completo proiettato. Cronologia grezza, riferimenti a file rileggibili, i 20 messaggi più recenti, media ed esportazioni restano invariati. In uno snapshot, misurato in condizioni stabili, la proiezione del modello scende da 105.810 a 99.143 caratteri. Risparmia altri 6.667 caratteri, ovvero circa 1.667 token di ingresso stimati per richiesta costruita allo stesso modo.
9.1.154Da BLUN King 9.1.154 le sezioni di canale Telegram indirizzate al di fuori dei 20 messaggi più recenti vengono limitate a un'anteprima di 500 invece di 1.000 caratteri con inizio e fine. Metadati di canale completi, inizio e fine del contenuto del messaggio, i 20 messaggi più recenti, allegati, cronologia grezza ed esportazioni restano invariati. In uno snapshot, misurato in condizioni stabili, vengono ridimensionate sette ulteriori sezioni storiche indirizzate. Risparmia 3.500 caratteri, ovvero circa 875 token stimati per richiesta ripetuta.
9.1.153Da BLUN King 9.1.153 la proiezione dei contesti Telegram storici conserva i metadati di canale completi e il tag di chiusura del canale. Viene accorciato esclusivamente il contenuto del messaggio. Anche con metadati Telegram reali lunghi 161 caratteri la struttura resta valida entro il budget di 250 caratteri. La proiezione è idempotente, i canali indirizzati successivi restano invariati e un involucro (envelope) di canale che già senza contenuto supera il budget viene lasciato passare invariato.
9.1.152Da BLUN King 9.1.152 gli argomenti delle chiamate di strumento concluse lasciano la proiezione del modello attiva dopo quattro invece di otto messaggi più recenti. La cronologia grezza della sessione, le chiamate senza risposta o formattate male, i media, i risultati degli strumenti e i quattro messaggi più recenti restano invariati. In uno snapshot di sessione, misurato di recente, vengono compattate due ulteriori chiamate concluse; rispetto a 9.1.151 risparmia altri 244 caratteri, ovvero circa 61 token stimati per richiesta ripetuta.
9.1.151Da BLUN King 9.1.151 gli argomenti delle chiamate di strumento concluse lasciano la proiezione del modello attiva dopo otto invece di dodici messaggi più recenti. La cronologia grezza della sessione, le chiamate senza risposta o formattate male, i media, i risultati degli strumenti e gli otto messaggi più recenti restano invariati. In uno snapshot di sessione misurato vengono compattate tre ulteriori chiamate concluse; rispetto a 9.1.150 risparmia altri 317 caratteri, ovvero circa 80 token stimati per richiesta ripetuta.
9.1.150Da BLUN King 9.1.150 l'esternalizzazione storica dei risultati di strumento protegge completamente i quattro messaggi più recenti invece degli otto. I risultati di strumento più vecchi adatti conservano un avviso di ripristino compatto lungo 600 caratteri e il loro percorso sorgente; cronologia grezza, output salvati completamente, media e i quattro messaggi più recenti restano invariati. In uno snapshot di sessione misurato la finestra di quattro messaggi esternalizza nove ulteriori risultati storici e risparmia rispetto a 9.1.149 altri 6.683 caratteri, ovvero circa 1.671 token stimati per richiesta ripetuta.
9.1.149Da BLUN King 9.1.149 l'esternalizzazione storica dei risultati di strumento protegge completamente gli otto messaggi più recenti invece dei dodici. I risultati di strumento più vecchi adatti conservano un avviso di ripristino compatto lungo 600 caratteri e il loro percorso sorgente; cronologia grezza, output salvati completamente, media e gli otto messaggi più recenti restano invariati. In uno snapshot di sessione misurato tre risultati scendono da 4.679 a 1.800 caratteri; risparmia altri 2.879 caratteri, ovvero circa 720 token stimati per richiesta ripetuta.
9.1.148Da BLUN King 9.1.148 vengono ridimensionate anche nel più recente pacchetto Telegram misto le sezioni di canale marcate esplicitamente con addressed=false. Le sezioni indirizzate, i media, la cronologia grezza e le esportazioni restano invariati. In una cronologia misurata undici sezioni non indirizzate scendono da 22.691 a 2.750 caratteri; risparmia 19.941 caratteri, ovvero circa 4.986 token stimati per richiesta ripetuta.
9.1.147Da BLUN King 9.1.147 la micro-compattazione protegge completamente i dodici messaggi più recenti invece dei venti e usa così la stessa finestra di ripristino dell'esternalizzazione esistente dei risultati di strumento. Gli argomenti di strumento conclusi più vecchi e i risultati di strumento adatti vengono ridimensionati solo nella proiezione del modello; cronologia grezza e percorsi di ripristino restano invariati. In una cronologia misurata risparmia altri 560 caratteri, ovvero circa 140 token stimati per richiesta.
9.1.146Da BLUN King 9.1.146 i risultati di strumento più vecchi, già esternalizzati, vengono limitati nella proiezione del modello alle indicazioni necessarie per il ripristino: nome dello strumento, numero di caratteri e percorso file. Il contenuto completo resta invariato sul disco, la cronologia grezza non viene modificata e i dodici messaggi più recenti mantengono i loro avvisi dettagliati. In una cronologia misurata l'input ripetuto del modello si riduce di 26.779 caratteri, ovvero circa 6.695 token stimati per richiesta.
9.1.145Da BLUN King 9.1.145 uno stream di provider interrotto viene ripetuto automaticamente se fino a quel momento è arrivato esclusivamente output di ragionamento interno. Il testo visibile e le chiamate di strumento continuano a impedire una ripetizione automatica. I passi successivi adattivi con livello di pensiero basso usano un budget di output di 8.192 token; i primi passi, i passi complessi e quelli falliti mantengono il budget configurato, e una ripetizione dopo il raggiungimento del limite di lunghezza può aumentarlo. Alla ripresa di una sessione l'attuale avviso di trasporto del plugin Telegram non appare più come testo di chat grezzo.
9.1.1449.1.144 limita le sezioni Telegram indirizzate al di fuori dei 20 messaggi più recenti nella proiezione del modello a un'anteprima lunga 1.000 caratteri con inizio e fine. I 20 messaggi più recenti, il messaggio utente più recente, le sezioni esattamente al limite, gli allegati, i metadati di canale, la cronologia grezza e le esportazioni restano invariati.
9.1.1439.1.143 rimuove nei messaggi più vecchi l'avviso di trasporto del plugin Telegram ripetuto dalla proiezione del modello. Contenuto del canale, metadati, allegati, messaggio utente più recente, cronologia grezza ed esportazioni restano invariati.
9.1.1429.1.142 ridimensiona l'anteprima con inizio e fine per le parti di canale Telegram più vecchie e non indirizzate nella proiezione del modello da 500 a 250 caratteri. Le parti di canale indirizzate, il messaggio utente più recente, gli allegati, la cronologia grezza e le esportazioni restano invariati.
9.1.1419.1.141 rimuove gli argomenti delle chiamate di strumento più vecchie e completate dalla proiezione del modello già a partire da 32 token stimati. I risultati degli strumenti mantengono la soglia precedente; i nuovi messaggi e la cronologia grezza restano invariati.
9.1.1409.1.140 limita per impostazione predefinita il promemoria di Mistake basato sulla rilevanza nella proiezione del modello a 4.000 caratteri. I file Mistake completi, la cronologia grezza e le esportazioni restano invariati.
9.1.1399.1.139 limita le parti di canale Telegram più vecchie e non indirizzate nella proiezione del modello a un'anteprima di 500 caratteri. Il messaggio utente più recente, le parti indirizzate, gli allegati, la cronologia grezza e le esportazioni restano completi.
9.1.1389.1.138 conserva nella proiezione del modello solo l'avviso di risveglio più recente di ogni incarico cron ricorrente. I promemoria una tantum, gli incarichi diversi, la cronologia grezza e le esportazioni restano invariati.
9.1.1379.1.137 protegge completamente solo i dodici messaggi più recenti dall'esternalizzazione degli output degli strumenti più vecchi. I risultati completi restano recuperabili tramite la cronologia grezza e il percorso di origine.
9.1.1369.1.136 conserva nella proiezione del modello solo l'avviso dinamico Mistake.md più recente. Le selezioni più vecchie restano completamente conservate nella cronologia grezza e nelle esportazioni.
9.1.135BLUN King 9.1.135 mantiene il runtime Node.js gestito al primo posto nel PATH nel processo sostitutivo e in tutti gli strumenti secondari. Comandi come node e npm usano così lo stesso runtime supportato della TUI, invece di ripiegare su un'installazione di sistema più vecchia.
9.1.1349.1.134 limita i messaggi di gruppo Telegram non indirizzati nella proiezione del modello a un'anteprima di 2.000 caratteri con inizio, fine e lunghezza originale conservati. I messaggi diretti e la cronologia salvata restano completi.
9.1.1339.1.133 seleziona dalla Mistake.md locale del progetto e da quella condivisa al massimo cinque voci complete rilevanti entro un budget comune di 6.000 caratteri. Le fonti complete e i percorsi di archiviazione restano conservati.
9.1.1329.1.132 mantiene attivo il prompt di sistema di base snello con 4.850 caratteri dopo l'inizializzazione generata. Risparmia così 18.259 caratteri per richiesta, pari a circa 4.565 token stimati, senza rimuovere istruzioni o strumenti.
9.1.1319.1.131 rimuove due copie di regole più vecchie dalla proiezione del modello, non appena sono presenti le controparti determinanti. Il prompt standard si riduce così di 1.010 caratteri, pari a circa 253 token stimati per richiesta.
9.1.1309.1.130 sostituisce al di fuori degli ultimi 20 messaggi il testo esplicativo dei passi di strumento più vecchi e completamente conclusi con un breve avviso. Le chiamate di strumento, i risultati, la cronologia grezza e le esportazioni restano completamente conservati.
9.1.1299.1.129 rimuove i testi di anteprima dai risultati di strumento più vecchi e già esternalizzati. Percorso e indicazioni di dimensione restano visibili; il contenuto completo resta conservato nel file originale o nell'archivio privato.
9.1.1289.1.128 limita la cache persistente degli schemi di strumenti caricati su richiesta ai dodici strumenti selezionati per ultimi. Gli strumenti rimossi restano immediatamente reperibili tramite ToolSearch.
9.1.1279.1.127 accorcia il catalogo ripetuto di ToolSearch. Gli strumenti univoci compaiono con il loro selettore breve; i namespace MCP completi restano conservati solo in caso di conflitti di nome.
9.1.1269.1.126 seleziona deterministicamente al massimo cinque sezioni pertinenti alla conversazione attuale dal file degli errori esteso al runtime. La proiezione è limitata a 6.000 caratteri e non richiede alcuna chiamata aggiuntiva al modello o alla rete.
9.1.1259.1.125 aggiunge il comando Telegram di sola lettura /status per gli utenti associati. Indica lo stato di computer, versione, processo e coda, senza emettere ID di chat, percorsi, segreti o contenuti di messaggi.
9.1.1249.1.124 corregge i colori del marchio invertiti nel simbolo BLUN compatto sotto l'input. Valori di stato, nome del profilo e persona restano invariati.
9.1.1239.1.123 rimuove i grandi argomenti JSON delle chiamate di strumento più vecchie e completate dalla proiezione del modello. Nome, identificatore, risultato, cronologia grezza ed esportazioni restano completi.
9.1.1229.1.122 carica ora la direttiva di design completa solo in caso di lavoro visivo tramite lo strumento Skill. Le richieste non visive ricevono un contratto di attivazione compatto; gli output di testo puro più vecchi vengono contemporaneamente esternalizzati in modo più efficace.
9.1.1219.1.121 limita la dimensione complessiva degli output di testo puro più vecchi degli strumenti. I risultati idonei vengono archiviati privatamente e sostituiti nella proiezione del modello con riferimenti di file leggibili.
9.1.1209.1.120 esternalizza le risposte dell'assistente grandi e più vecchie in file di sessione privati. Gli ultimi 20 messaggi, le catene di strumenti e la cronologia grezza completa restano conservati.
9.1.1199.1.119 invia a ogni passo del modello solo una piccola selezione di skill richieste di frequente. Tutte le altre skill restano reperibili tramite lo strumento Skill in base al nome o allo scopo.
9.1.1189.1.118 mantiene stabile il timestamp di sessione nel prompt di sistema durante una sessione in corso. Le parti di prompt invariate possono così continuare a usare la cache dei prefissi del provider.
9.1.1179.1.117 mantiene immediatamente disponibili i quattro strumenti principali per i media e carica la comprensione di immagini e video, la sincronizzazione video e la sincronizzazione del movimento delle labbra solo su richiesta tramite ToolSearch.
9.1.1169.1.116 aggiunge una compattazione proattiva a partire da circa 128.000 token di ingresso stimati a un confine di passo sicuro. La compattazione usa un proprio prompt di sistema snello; i grandi risultati Read usano il loro percorso di origine esistente.
9.1.115Le sessioni riprese ricostruiscono il prompt di sistema del profilo attuale, così gli snapshot di prompt obsoleti e troppo grandi non persistono oltre i riavvii. Le grandi panoramiche delle cartelle di lavoro vengono limitate; i file completi restano disponibili tramite Glob, Grep e Read.
9.1.114La consegna Telegram tratta ora l'EPERM di Windows come indicazione di un processo TUI o poller in esecuzione, invece di deviare i messaggi dalla sessione visibile. ToolSearch conferma uno strumento già caricato con corrispondenza esatta del nome, invece di segnalare erroneamente che manca uno strumento da caricare solo su richiesta.
9.1.113Gli strumenti Telegram mantengono all'avvio un percorso sostitutivo all'interno dello stesso runtime, qualora la registrazione gestita del plugin manchi temporaneamente.
9.1.112I grandi messaggi utente più vecchi vengono archiviati al di fuori della finestra di lavoro attiva; la cronologia grezza completa resta comunque disponibile.
9.1.111I turni Telegram con allegati ricevono automaticamente download_attachment. Nei turni normali lo strumento resta esternalizzato tramite ToolSearch, così il carico ridotto degli schemi rimane invariato.
9.1.110I nuovi tentativi dopo un sovraccarico del provider rispettano l'indicazione Retry-After del server. La configurazione automatica di ripgrep scarica gli archivi specificati della versione 15.0.0 dalla pubblicazione ufficiale di ripgrep e verifica le loro somme di controllo SHA-256 prima dell'installazione.
9.1.109La versione 9.1.109 mantiene in modo persistente nella richiesta del modello solo i nove strumenti su cui ricadevano più del 98 percento delle 3.183 chiamate di strumento misurate. Tutti gli altri strumenti restano reperibili tramite ToolSearch e disponibili per il resto della sessione dopo il primo caricamento. Il carico degli schemi diminuisce così a ogni normale passo del modello, senza rimuovere strumenti né modificare il percorso rapido per le risposte Telegram e i risultati dei media in sospeso.
9.1.108Gli avvisi di sistema identici e iniettati ripetutamente vengono unificati solo nella proiezione del modello. Gli avvisi modificati e la cronologia salvata completa restano conservati.
9.1.107Gli errori del provider vengono mostrati in un linguaggio comprensibile per il cliente; i codici di errore interni e gli avvisi per il supporto non compaiono. /help offre un elenco di comandi navigabile con i tasti freccia e apre con la freccia destra o il tasto Invio una descrizione dettagliata del comando selezionato.
9.1.106I profili agente possono escludere strumenti per nome. Le esclusioni valgono anche dopo il caricamento dinamico su richiesta; i sottoagenti standard non inviano messaggi Telegram aggirando l'agente principale.
9.1.105La versione 9.1.105 aggiunge TaskUpdate per gli agenti in background in esecuzione. King trasmette istruzioni aggiuntive al passo di modello sicuro successivo allo stesso agente attivo, senza fermarlo né avviare un altro agente. Le attività sconosciute e già terminate, le attività della shell e gli agenti che non accettano più aggiornamenti continuano a essere respinti come prima.
9.1.104La versione 9.1.104 lascia eseguire i comandi shell in primo piano fino alla fine regolare anche con output molto grandi. King scrive ininterrottamente fino a 16 MiB nel registro privato delle attività, scarta gli output oltre questa soglia e segnala il codice di uscita effettivo, invece di terminare il processo a causa della quantità di output. Gli output piccoli, le attività in background, i limiti di tempo e gli annullamenti manuali restano invariati.
9.1.103I membri dello sciame vengono ripresi al massimo due volte sotto lo stesso ID agente dopo interruzioni temporanee del provider. HTTP 429 mantiene la sua regola separata di sovraccarico; gli errori definitivi e gli annullamenti manuali non vengono ripetuti automaticamente.
9.1.102Gli agenti singoli delegati vengono ripresi al massimo due volte in base alla loro cronologia persistente dopo errori temporanei del provider. Gli errori persistenti e gli annullamenti manuali restano definitivi.
9.1.101I messaggi utente troppo grandi vengono salvati localmente e sostituiti nel contesto del modello con un'anteprima limitata e un percorso leggibile. La cronologia originale completa e i media restano invariati.
9.1.100Le ricerche di contenuto Grep limitate terminano ripgrep dopo la pagina richiesta e una riga di anteprima aggiuntiva. I conteggi di corrispondenza, le ricerche illimitate e gli elenchi di file ordinati per data di modifica restano completi.
9.1.98King può compattare proattivamente una sezione di lavoro completata a partire da 128.000 token stimati. Sotto la soglia lo schema dello strumento resta completamente escluso dal prompt del modello; la compattazione usa il confine di passo sicuro esistente.
9.1.97La descrizione dello strumento TodoList caricata in modo persistente è scesa da 2.238 a 996 caratteri. La pianificazione a più livelli, tutti e sei gli stati delle attività, i resoconti di avanzamento onesti, le interrogazioni, lo svuotamento e la modalità piano separata restano protetti.
9.1.96Il prompt di sistema di base caricato in modo persistente è sceso da 23.109 a 4.850 caratteri. Identità, persona e anima, la lingua delle risposte, i limiti di lavoro e di autorizzazione, il passaggio di consegne della compattazione, l'ambiente di runtime, AGENTS.md e le skill restano protetti.
9.1.95La descrizione dello strumento Write caricata in modo persistente è scesa da 2.532 a 1.541 caratteri. La delimitazione rispetto a Edit, i contenuti letterali, le terminazioni di riga, il limite di 500 righe, l'eccezione di un singolo file e la continuazione atomica con controllo di righe e SHA-256 restano protetti.
9.1.94La descrizione dello strumento Glob caricata in modo persistente è scesa da 1.495 a 1.006 caratteri. L'ordinamento, i file ignorati e sensibili, i pattern ricorsivi, i file dot, le espansioni delle parentesi graffe e il limite di 100 corrispondenze restano protetti.
9.1.93La descrizione dello strumento Edit caricata in modo persistente è scesa da 1.537 a 1.144 caratteri. La lettura prima della modifica, le sostituzioni esatte, le sostituzioni multiple, la gestione CRLF e il limite di 500 righe restano protetti.
9.1.92La descrizione dello strumento Agent caricata in modo persistente è scesa da 2.061 a 1.153 caratteri. Il contesto separato, la ripresa, i limiti di tempo e la delega parallela restano invariati.
9.1.91La descrizione dello strumento Read caricata in modo persistente è scesa da 2.391 a 1.648 caratteri. La paginazione, la protezione dei segreti, l'inoltro dei media, il formato delle righe e il comportamento CRLF restano invariati.
9.1.90La descrizione dello strumento Bash caricata in modo persistente è scesa da 5.003 a 1.834 caratteri. Il contratto di runtime, le attività in background, gli strumenti di file e i limiti di sicurezza restano completamente invariati.
9.1.89Le letture di file a pagine indicano al limite interno di 1.000 righe il prossimo line_offset esatto; la fine del file e le sezioni volutamente più piccole restano invariate.
9.1.88BLUN King 9.1.88 attiva la compattazione piccola e senza perdite per tempo, prima della compattazione completa. I grandi risultati di strumento più vecchi e gli argomenti di chiamate di strumento completate lasciano prima la vista del modello; la cronologia salvata completa resta invariata.
9.1.87Una risposta HTTP 429 esplicitamente ritentabile rispetta Retry-After e riceve al massimo due nuovi tentativi automatici; gli altri errori restano immediatamente visibili.
9.1.86I grandi output degli strumenti mantengono visibili, entro lo stesso budget di anteprima, i primi e gli ultimi 1.000 caratteri; una marcatura precisa indica il numero di caratteri omessi.
9.1.85I risultati di strumento basati su testo oltre i 12.000 caratteri vengono salvati completamente in un file locale privato; le successive richieste del modello conservano solo un budget di anteprima di 2.000 caratteri e il percorso leggibile.
9.1.84La compattazione completa elabora le cronologie più vecchie in fasi cronologiche con al massimo 64.000 token di ingresso stimati; il limite di sicurezza fisso e l'archivio privato completo restano invariati.
9.1.83La microcompattazione sostituisce i grandi argomenti delle chiamate di strumento più vecchie e completate solo nella vista del modello con una marcatura JSON valida; il verificatore di sessione segnala il risparmio stimato senza emettere contenuti.
9.1.82Il verificatore di sola lettura segnala gli schemi di strumento selezionati e trattenuti, i motivi di soppressione e il numero stimato di token di schema evitati.
9.1.81Un verificatore di sola lettura fornito in dotazione riassume i passi del provider, le chiamate di strumento, i token, le compattazioni, gli errori e gli output esternalizzati, senza rivelare prompt o percorsi privati.
9.1.80I grandi risultati di strumento ricevono una telemetria di esternalizzazione senza contenuti; il contesto isolato dei sottoagenti, i piani leggibili dalla macchina e i passaggi di consegne trasferibili sono protetti da test di regressione.
9.1.79I checkpoint persistenti scrivono i record di cronologia completati prima dei passi del provider e prima del completamento di un worker, così il lavoro completato può essere riletto dopo una ripresa.
9.1.78La compattazione completa archivia le parti di cronologia soppiantate prima di sostituirle con un riassunto; il riassunto contiene il percorso leggibile dell'archivio.
9.1.77La microcompattazione riduce in caso di pressione sul contesto i risultati di strumento grandi e più vecchi, conservando al contempo la cronologia salvata completa.
9.1.76Gli incarichi di immagini, video e voce in sospeso superano la compattazione e le rapide domande di follow-up; i messaggi Telegram restano in ordine FIFO senza fuorvianti errori di tipo busy.
9.1.75Le brevi conversazioni Telegram elaborano solo il messaggio senza risposta più recente, mentre gli scambi testuali conclusi restano conservati come contesto linguistico.
9.1.74Le route Telegram memorizzate ripristinano gli ID di gruppo passati accidentalmente senza il segno meno; Ctrl+S può controllare un turno effettivamente in esecuzione.
9.1.73I messaggi Telegram e di loop non avviano più un secondo turno durante il lavoro attivo; Escape e Ctrl+C possono comunque interrompere il turno attivo.
9.1.72Nascondere un avviso di aggiornamento sopprime solo la versione offerta in quel momento; le pubblicazioni più recenti riappaiono all'avvio normale con king.
9.1.71I segnali di risveglio del loop arrivano correttamente in coda, il poller Telegram viene acquisito in modo atomico, gli strumenti centrali di file e media restano immediatamente disponibili e Context7 non si avvia più automaticamente.
9.1.69Gli MCP standard vengono configurati, Telegram raggiunge un punto di passaggio FIFO protetto, Escape e Ctrl+C interrompono in modo affidabile il lavoro attivo e la panoramica MCP nasconde i percorsi interni.
9.1.68I messaggi Telegram ricevuti in stato di inattività risvegliano l'elaborazione FIFO, i messaggi diretti e di gruppo mantengono il loro ordine di ingresso e la ripresa nasconde i frame Telegram interni.
9.1.67La skill standard venture-flywheel aggiunge una base UVF puramente contrattuale con fiducia di progetto deterministica e obblighi di autorizzazione per le azioni esterne.
9.1.66/curiosity e /scout eseguono ricerche di opportunità limitate e di sola lettura con prove, controprove e un criterio di interruzione.
9.1.65Escape e Ctrl+C interrompono in modo affidabile le compattazioni automatiche, un'ancora di schermo stabile impedisce doppi piè di pagina e l'avviso del loop è allineato al contenuto della chat.
9.1.64La cronologia di sessione basata su disco, gli strumenti e le skill caricati su richiesta, un watchdog di inattività del provider da 120 secondi, il ritmo corretto del loop, Telegram in ordine FIFO, i pacchetti Linux e il riconoscimento della lingua bosniaca sono arrivati insieme.
9.1.58–9.1.63Questa serie di versioni ha riunito lavori su sessioni, Telegram, piattaforme e prestazioni. A chiudere la serie sono stati schemi di strumento snelli su richiesta, elenchi di skill compatti, skill al primo utilizzo ripristinate e un controllo dell'inventario dei pacchetti contro rimozioni non pianificate.

Miglioramenti precedenti

VersioneModifica
9.1.53/idea pubblica il suo piano di attività prima del primo lavoro, controlla le azioni in uscita a ogni chiamata di strumento e richiede per ogni passo uno stato finale onesto.
9.1.52Le sessioni riprese aprono direttamente la cartella di lavoro salvata. Conversazione e stato /loop attivo vengono ripristinati insieme al riavvio.
9.1.51I loop funzionano come risvegli autonomi, /idea sviluppa e modifica i propri piani, Telegram può attivare comandi di lavoro e gli stati dei media e di avvio vengono rappresentati in modo più chiaro.
9.1.50Le immagini locali o ricevute via Telegram possono essere animate come veri video MP4. Le grandi finestre di contesto ricevono un budget di output valido; la barra dei media mostra stati più chiari e percorsi cliccabili.
9.1.49Le immagini di personaggi di fantasia adulti in costume da bagno restano consentite entro limiti chiari. Gli incarichi di immagini completati possono essere usati come immagine di partenza per i video; le interrogazioni GetMedia riuscite non generano schede ripetute.
9.1.48La barra dei media unificata raggruppa gli incarichi di media direttamente sopra il campo di input. Le percentuali compaiono solo con un valore misurato reale del provider; altrimenti la barra mostra fase e durata.
9.1.47Il registro delle richieste distingue conversazioni e compattazione e registra la selezione degli strumenti nonché il motivo di soppressione, senza modificare il comportamento degli strumenti.
9.1.46I loop comprendono le indicazioni di tempo naturali, le mostrano durante l'input, supportano intervalli liberi e consentono di nuovo la normale selezione del testo nel terminale al di fuori della vista della cronologia.
9.1.45L'avanzamento della compattazione in corso ora compare solo nella barra di stato inferiore, invece di apparire in più come seconda riga nella chat.
9.1.44Reimpacchettamento completo della 9.1.43 approvata, affinché anche le versioni 9.1.43 installate in precedenza riconoscano in modo sicuro l'aggiornamento.
9.1.43Base di protezione completa della 9.1.40 con diagnostica del trasporto, avvisi di aggiornamento visibili e i comandi da console /loop, /goal e /output-style.
9.1.40Watchdog del turno per chiamate lunghe o che falliscono ripetutamente; auto-hash dopo la scrittura in più parti con verifica di rilettura del file salvato.
9.1.39I file lunghi vengono scritti in continuazioni. Ogni continuazione riparte dalla fine effettivamente scritta; il numero di righe, lo SHA-256 e i confini dei pezzi vengono verificati e indicati.
9.1.38Gli argomenti di strumento degenerati o troncati vengono riconosciuti. Un file incompleto viene respinto con un messaggio di errore, invece di essere considerato tacitamente completato.
9.1.37Dopo un cambio di Node, BLUN verifica i moduli nativi con una vera interrogazione SQLite e ricostruisce better-sqlite3 se necessario.
9.1.36Le risposte vuote del modello vengono gestite in base alla causa: un budget di output troppo scarso viene aumentato, uno stop vuoto viene ripetuto esattamente una volta. Gli avvisi di sistema e le iniezioni non possono innescare una risposta Telegram.
9.1.35La compattazione a più livelli mostra il livello e l'effettivo utilizzo della finestra del modello, ad esempio 2/~10 · 90 %.
9.1.34Il contesto attivo viene compattato a fasi: prima le parti più vecchie, ogni chiamata del compattatore al di sotto del limite del modello.
9.1.33Base per il runtime Node automatico e la riparazione successiva dei moduli nativi dopo un cambio di runtime.

Integrazioni e lacune documentali aperte

Raffronto del 17 settembre 2026: nell'intervallo da 9.1.33 a 9.1.597 sono presenti 521 versioni nel registro npm. Un numero mancante non è automaticamente una pubblicazione mancante: alcune versioni mancano nel registro attuale o sono state ritirate. Per quattro versioni pubblicate i dettagli esatti delle modifiche restano aperti. Per queste versioni non vengono inventate modifiche.

9.1.567: dettagli delle modifiche aperti

Pubblicata il 6 settembre 2026 alle 22:42 UTC. Il valore SHA-512 del pacchetto coincide con il valore di integrità pubblicato su npm. Il pacchetto non contiene un CHANGELOG.md; il suo README indica ancora la 9.1.566 nel comando di installazione. Da questo non è possibile ricavare in modo affidabile la differenza rispetto alla 9.1.566. Questa lacuna documentale resta espressamente aperta.

9.1.550: dettagli delle modifiche aperti

Pubblicata il 2 settembre 2026 alle 07:19 UTC. Il valore SHA-512 del pacchetto coincide con il valore di integrità pubblicato su npm. Il pacchetto non contiene un CHANGELOG.md e nel materiale controllato non è stata trovata alcuna prova di modifica specifica per versione. Questa lacuna documentale resta espressamente aperta.

Integrazione per la 9.1.536

Le seguenti indicazioni provengono dal pacchetto pubblicato il 1º settembre 2026, con integrità verificata:

  • Gli incarichi di lavoro proseguono oltre le risposte Telegram private. Dopo i messaggi diretti bufferizzati, King prosegue il lavoro con un passo aggiuntivo limitato, purché l'utente non metta in pausa o non fermi espressamente.
  • Le brevi richieste di stato non interrompono il flusso di lavoro in corso.
  • Quando i tentativi di ripetizione dopo risposte di pensiero vuote sono esauriti, King riduce l'impegno di pensiero, invece di lasciarlo invariato nei tentativi successivi.
  • Più schemi di strumenti caricati su richiesta restano disponibili; i messaggi vengono esternalizzati solo quando lo spazio disponibile nella cronologia si fa scarso.
  • Sono incluse la regola di avanzamento verificata per TodoList e un percorso di avvio su una sola riga per God Mode con Swarm.

Integrazione per la 9.1.99

La documentazione delle funzioni già esistente descrive l'esternalizzazione congiunta di risultati di strumenti di testo puro consecutivi: se il blocco supera i 12.000 caratteri, i grandi risultati idonei vengono salvati privatamente. Nel contesto del modello restano riferimenti leggibili; la cronologia grezza e i media restano invariati. La voce di versione finora mancante rimanda ora espressamente a questa funzione.

9.1.70: dettagli delle modifiche aperti

Pubblicata il 24 agosto 2026 alle 15:56 UTC. Il valore SHA-512 del pacchetto coincide con il valore di integrità pubblicato su npm. Il pacchetto non contiene un CHANGELOG.md; le descrizioni delle funzioni esistenti non comprovano una differenza univoca rispetto alla 9.1.69. Questa lacuna documentale resta espressamente aperta.

9.1.57: dettagli delle modifiche aperti

Pubblicata il 23 agosto 2026 alle 07:28 UTC. La versione è finora apparsa solo come punto di partenza di un titolo collettivo. Una prova di modifica specifica per versione non è assegnata nel materiale controllato. Questa lacuna documentale resta espressamente aperta.

Il CHANGELOG.md contenuto nel pacchetto npm immutabile 9.1.597 termina alla 9.1.594. Le indicazioni integrate dalla 9.1.595 alla 9.1.597 si trovano su questa pagina. Il pacchetto pubblicato non è stato riscritto successivamente con lo stesso numero di versione.

9.1.41 e 9.1.42 sono state ritirate

Non installare

Queste due versioni sono state derivate per errore dalla 9.1.38 invece che dalla 9.1.40. Per questo mancavano la continuazione di scrittura, l'auto-hash e i watchdog del turno. Entrambe le versioni npm sono contrassegnate come obsolete; latest e next non hanno mai puntato a loro. La 9.1.43 contiene le loro modifiche previste sulla base di protezione completa.

Aggiornare e verificare

king update
blun --version

Dopo l'installazione della 9.1.599 l'output della versione deve mostrare 9.1.599. Gli aggiornamenti dalla 9.1.597 e dalla versione locale 9.1.598 tramite le fonti di aggiornamento pubbliche sono stati verificati. Una console già in esecuzione carica il nuovo codice solo dopo il proprio riavvio. Verifica poi al suo interno anche /version.