BLUN King

BLUN King 9.1.621

Публикувано на

King приема резюме на разговора ти само когато моделът е потвърдил, че е завършено. Ако това потвърждение липсва, досегашната история на разговора ти остава непроменена.

Ако предаването на резюмето приключи неочаквано, досегашният контекст на разговора ти не се заменя с непълното резюме. Промяната се отнася само до сгъстяването на разговора; нормалните отговори остават непроменени.

Остават открити единични грешки при запазването на сесия; те не са отстранени с тази актуализация.

BLUN King

BLUN King 9.1.620

Публикувано на

Под Windows конзолата напълно приключва при затваряне на прозореца, така че при следващото стартиране вече не се появява „вече работи“.

Актуализацията коригира приключването на конзолния процес при затваряне на прозореца. Действително все още работеща конзола запазва изключителния достъп до своята сесия.

BLUN King

BLUN King 9.1.619

Публикувано на

Единична по-раншна грешка при сгъстяването на разговора вече не блокира сесията ти: след успешно сгъстяване King брои само нови, непосредствено следващи грешки.

Единична по-раншна грешка при сгъстяването на разговора вече не блокира сесията ти: след успешно сгъстяване King брои само нови, непосредствено следващи грешки. Ако сгъстяването се провали два пъти подред, съобщението вече ясно показва „Сгъстяването е поставено на пауза“, вместо да отчита пълен контекст.

Остават открити единични грешки при запазването на сесия и при създаването на пълно обобщение на разговора; те не са отстранени с тази актуализация.

BLUN King

BLUN King 9.1.618

Публикувано на

Когато след продължаването на сесията ти пристигне съобщение от Telegram, докато King вече работи, то остава в опашката и се доставя след това.

Когато след продължаването на сесията ти пристигне съобщение от Telegram, докато King вече работи, то остава в опашката и се доставя след това. King вече не показва тази ситуация на изчакване като грешка.

В Linux x64 терминалът използва двоичен файл, включен в пакета. Така той работи дори когато npm 12 блокира инсталационните скриптове; за това не е нужен компилатор. За целта King използва фиксираната предварителна версия node-pty 1.2.0-beta.15.

BLUN King

BLUN King 9.1.617

Публикувано на

При повторно зареждане на същата сесия King вече не добавя многократно непроменените инструкции на приставките.

При повторно зареждане на същата сесия King вече не добавя многократно непроменените инструкции на приставките. Ако инструкциите се променят, King продължава да взема предвид актуалното състояние.

Визуализациите на големи изходи на инструменти вече отчитат и наличния контекстен прозорец. И занапред можеш да прочетеш изцяло изнесените изходи.

С /profile или /profiles отваряш избора на профил. King извършва смяната само когато сесията ти е готова. Текуща работа и чакащи съобщения предотвратяват прибързана смяна; в такъв случай досегашният ти профил остава активен.

Когато прекратяваш текуща работа, King изчаква и последните стъпки по почистването. Работа, която още не е приключила, не се потвърждава преждевременно като прекратена.

BLUN King

BLUN King 9.1.616

Публикувано на

След потвърден отговор в Telegram King поема и други съобщения, адресирани до теб, на следващата безопасна стъпка, дори по време на текущ ход.

След потвърден отговор в Telegram King поема и други съобщения, адресирани до теб, на следващата безопасна стъпка, дори по време на текущ ход. Отговор, който вече е доставен, не задържа повече опашката. Отговорите остават свързани със съответния чат.

Ако прекъснеш ход, съобщенията от Telegram, които още не са поети, се запазват за следващата доставка. King ги потвърждава едва когато сесията действително ги поеме.

BLUN King

BLUN King 9.1.615

Публикувано на

King поддържа големи каталози с инструменти достъпни чрез търсенето на инструменти и съобразява бюджета за инструменти с контекстния прозорец на доставчика.

King поддържа големи каталози с инструменти достъпни чрез търсенето на инструменти, без да изпраща на модела всички незадължителни схеми на инструменти. Ако доставчикът съобщи за по-малък контекстен прозорец, King коригира бюджета за инструменти; намерените инструменти остават достъпни в следващата стъпка.

При необходимост King изнася големите изходи на инструментите по-рано от досега. Можеш да изтеглиш пълния изход както досега, при условие че може да бъде показан безопасно.

Нормалните отговори в Telegram и промените по съобщения вече не се задържат поради липсващо езиково одобрение. Проверката на отговорите, която си настроил, остава активна.

BLUN King

BLUN King 9.1.614

Публикувано на

Твърде големите файлове AGENTS.md и AGENTS.override.md вече не спират хода само заради размера си.

Извън конзолата на King, King прочита общо до 32 KiB от файловете с инструкции и веднъж на сесия ти съобщава колко байта са пропуснати.

В конзолата на King файловете остават пълни, стига границата на заявката да го позволява.

Символните връзки и несигурните пътища остават блокирани.

BLUN King

BLUN King 9.1.613

Публикувано на

King разпознава твърде големите моделни заявки още преди изпращането.

В конзолата на King, King чете от всеки файл AGENTS.md и AGENTS.override.md най-много 32 KiB. Което надхвърля тази граница, King пропуска и ти показва колко байта са пропуснати.

Преди изпращане King вече оценява размера на цялата моделна заявка, включително инструкции, история, дефиниции на инструменти и данни за изображения. Ако тя се приближи до байтовата граница на сървъра, започва постепенно сгъстяване. Ако една заявка не може да бъде безопасно разделена, King спира, без мълчаливо да изхвърля запазената история.

King съхранява завършените извиквания на инструменти локално като метаданни: име на инструмента, време, статус и при файлови инструменти — евентуално пътя. Входове, изходи, команди и ключове не се съхраняват. С /memory tools можеш да търсиш в записите на своя профил.

Диагностиката на контекста показва допълнителни числа за състава на заявките. Опционално измерване на фазите отчита времето до извикването на модела, без да протоколира съдържание.

Индикацията за разход поема отделно докладваните токени за мислене, ако доставчикът ги предоставя.

Не е издадена, заменена от 9.1.613

BLUN King 9.1.612

Публикувано на

9.1.612 не беше издадена като клиентска актуализация. Ранната защита по байтове не действаше при заявка над 900 KB, ако историята сама по себе си оставаше под 600 KB. 9.1.613 заменя този вариант.

BLUN King

BLUN King 9.1.611

Публикувано на

Големите заявки за сгъстяване остават в рамките на байтовата граница на сървъра.

  • King разделя твърде голяма заявка за сгъстяване на хронологични стъпки според размера на заявката. Така сгъстяването може да продължи, дори когато заявката съдържа повече байтове, отколкото сървърът приема наведнъж.
  • Ако дори едно-единствено съобщение не се побере под границата, запазената ти история остава непроменена. King не я изхвърля, за да наложи сгъстяването.

С това не е доказано нито по-кратко време за изчакване на модела, нито по-нисък разход на токени. Актуализацията не рестартира вече работеща сесия на King.

BLUN King

BLUN King 9.1.610

Публикувано на

Можеш отново да инсталираш King на Linux и да стартираш профилите си, а втори старт на King под Windows вече не се проваля с подвеждащо съобщение за частни ACL.

  • Linux отново е в списъка с поддържани операционни системи на npm пакета. Ако под Linux имаш по-стара версия, инсталирай 9.1.610 през обичайния updater.
  • Изричните стартове с --profile и съществуващите съкращения на имена на профили водят към директорията на избрания профил. Самото неизвестно име вече не създава мълчаливо празен профил; нов профил създаваш съзнателно с --profile.
  • Ако на съществуващ профил липсва собствено влизане, King предлага /login, вместо да спре поради липсваща конфигурация на модела blun/king.
  • Под Windows проверката на частни директории успява и когато Telegram bridge държи отворена директория на приставка. TEMP и TMP се предават на ACL помощника, а при грешки в директориите King посочва засегнатия път и действителната причина.
  • Ако вече работи интерактивен King, King разпознава това преди защитата на частните ACL и съобщава неговия PID, вместо да представи втория старт като грешка в частните ACL.

Празен профил не поема в 9.1.610 данни за влизане от общата домашна директория. Текущата /login заявка може все още да показва „OAuth login expired“, дори ако този профил никога не се е вписвал.

Пътят за актуализиране на Linux от 9.1.114 до 9.1.610 беше преминат след публикуването. Пътят за актуализиране на Windows от 9.1.609 до 9.1.610 не е измерен.

Актуализацията не рестартира вече работеща сесия на King.

BLUN King

BLUN King 9.1.609

Публикувано на

Отвори избора на effort с Ctrl+L и запази черновата си в редактора.

  • Ctrl+L отваря съществуващия избор на effort, без да губиш черновата си в редактора. Съществуващите настройки на effort и ограниченията на моделите се преизползват, вместо да се създава втори път за конфигурация.
  • Съществуващото правило за работещи сесии остава: промяна на effort по време на активна работа се отхвърля, а не се отлага за по-късно. По време на възпроизвеждане или поемане от редактора клавишната комбинация се игнорира.

Тези промени не доказват нито по-бързо време за отговор в реална работа, нито по-нисък фактуриран разход на токени и не осигуряват пълен паритет с OpenClaw.

BLUN King

BLUN King 9.1.608

Публикувано на

В Telegram групите до King достигат само съобщенията, които го споменават. Твоите множествени избори и постепенното отменяне на въпроси се запазват.

  • В Telegram групите съобщенията, които не се обръщат към King, попадат в контекста на сесията едва след проверката за споменаване. Който е изключил изрично проверката, запазва избора си.
  • Твоите множествени избори и постепенното отменяне на въпроси се запазват. Целевият долен колонтитул работи с общ таймер за актуализиране.
  • Разходът за прехвърляне на Windows ACL намалява, без проверката на правата да отслабва. Възстановяването след временни грешки при замяната на конфигурацията е ограничено; собствеността върху записа се запазва.
  • Преди нов опит King проверява дали паралелно премахнатият Windows маркер за запис наистина е изчезнал. Нечетими съществуващи маркери продължават да водят до прекратяване.

Тези промени не доказват нито по-бързо време за отговор в реална работа, нито по-нисък фактуриран разход на токени и не осигуряват пълен паритет с OpenClaw.

BLUN King

BLUN King 9.1.607

Публикувано на

Последната избрана от теб сесия се връща, неуспешните записи се съобщават честно и всеки HTTP опит получава начален времеви печат.

  • Опционалното възстановяване на последната избрана сесия може да се активира с resume_last_selected в tui.toml. Изборът важи за потвърдения акаунт, средата за изпълнение, агента и работното пространство. Нормалният старт остава непроменен, изричните избори на сесия имат предимство; недостъпните избори се връщат към нова сесия, а не към друга.
  • След неуспешна активация предишният избор се запазва. Под акаунт, който се е променил по време на активацията, не се записва избор.
  • Неуспешните записи на файлове не се отбелязват като успешни. Съществуващият протокол за продължаване на пълни редове при записи над 2 048 UTF-8 байта се обяснява, без границата да се увеличава или опитът да се повтаря автоматично.
  • Непосредствено преди всеки HTTP опит се записва начален времеви печат по реалното време за корелация при диагностика. Съдържанието на заявките или данните за достъп не попадат в диагностиката.
  • Unicode знаци извън основната равнина (например емоджи) се запазват изцяло в съществуващите граници на бюджета за съхранение, без тези бюджети да се увеличават или да се създава допълнително хранилище.

Тези промени не доказват нито по-бързо време за отговор в реална работа, нито по-нисък фактуриран разход на токени, не осигуряват пълен паритет с Gateway и не изключват неспоменати Telegram съобщения от контекста.

BLUN King

BLUN King 9.1.606

Публикувано на

При продължаване на сесия първо се показват актуалните страници на транскрипта; по-старите страници се зареждат от съществуващата навигация на транскрипта.

  • При продължаване на интерактивна сесия първо се показват актуалните страници на транскрипта; по-старите страници се зареждат от съществуващата навигация на транскрипта. Пълната запазена история и активният моделен контекст се запазват.
  • При старт важи цел за показване от 200 записа за възпроизвеждане. С --history-limit от 1 до 2000 можеш да настроиш показването на първите и по-старите страници; пълните кръгове на разговора и двойките инструменти могат да надхвърлят целта.
  • Първоначалното показване на активации на skills и приставки остава запазено през границите на страниците. Позицията на превъртане в началото е коригирана, така че зареждането на по-стари страници не оставя празен екран.

Тези промени намаляват първоначалната работа по изобразяване на транскрипта. Те не доказват нито по-бързо време за отговор на модела, нито по-нисък разход на токени или по-ниски сметки, не подобряват кеширането при доставчика и не ограничават колко се чете от диска при старт.

BLUN King

BLUN King 9.1.605

Публикувано на

Проверявай контекстни източници, управлявай текущи процеси и предай първо съобщение при старта на конзолата. Обработката на локалната история и проверките за сгъстяване са разширени.

  • Локалните истории на сесии се възпроизвеждат на групи. Архивираните страници за показване могат да се намерят, без да се претърсват всички предишни блокове. Пълно запазената история, проверките за цялост на архива и досегашното възстановяване се запазват.
  • Повтарящите се резултати от инструменти се подготвят еднакво за моделния контекст между регистрираните сгъстявания. Пълните локални изходи и съществуващите права за четене се запазват. Изходи не се изнасят, ако не биха били отново достъпни по обещания път за възстановяване.
  • Финалното автоматично сгъстяване заменя активния контекст само ако намалява историята по същия метод на оценка. При отказ оригиналната история се запазва. Опционалният тригер max_request_history_bytes използва съществуващото управление на сгъстяването, изключен е по подразбиране и не ограничава цялото тяло на заявката към доставчика.
  • Контекстната диагностика получава отделни изгледи и приписване на източници за инструкции, Memory, skills и по-ранни съобщения. Байтовете на сериализираното съдържание, локалните оценки на токени и отчетеният разход остават разделени.
  • Отговорността за сесията се запазва при чакащи задачи, закъснели събития, допълнителни въпроси и промени в конфигурацията. Втори активен запис в същата сесия се отхвърля, вместо да се допускат едновременни промени в протокола.
  • Допълнителният ред за агент/сесия в долния колонтитул отпада. Сесиите продължават да могат да се управляват и диагностицират целенасочено. Съществуващият интерфейс на King, управляваните модели и границите на правата се запазват.
  • --message предава първо съобщение за интерактивния старт. То се обработва след съгласието при старта и избора на сесия през нормалната проверка на съобщенията и опашката. Съдържанието му не се интерпретира като slash или shell команда.
  • Споразумението за интерфейса на доставената guard услуга остава непроменено. Тази публикация не доказва нито по-бързи отговори в реална работа, нито по-ниски сметки от доставчика, пълна функционална равностойност с OpenClaw или ограничено количество за четене при първото зареждане на протокола на сесията.

/abort прекратява текущия процес, без да изхвърля чакащите входове. /stop изхвърля допълнително чакащите входове. /exit продължава да затваря конзолата. Това са локални конзолни команди, а не допълнителни дистанционни Telegram команди.

Проверки на състоянието на пакета 9.1.605: 238 проверъчни файла с 6 900 теста, както и 40 проверки за staging, включително 25 естествени терминални проверки. Тестът на изолирано актуализиране от 9.1.604 през публикувания кандидатски таг с истинския инсталатор беше успешен. С това не са доказани нито по-кратки времена за загряване в работеща сесия, нито пълна функционална равностойност с OpenClaw.

BLUN King

BLUN King 9.1.604

Публикувано на

Проверявай размера на заявките и контекстните източници, зареждай инструменти при нужда и управлявай входящите съобщения в рамките на съответната сесия.

  • /context doctor и /tokens различават броя байтове на сериализираната заявка от оценените количества токени и показват отчетените дялове на правила, Memory, skills и дефиниции на инструменти.
  • Средноголеми каталози с инструменти се зареждат при нужда през съществуващото търсене; инструментите остават откриваеми и изпълними.
  • /queue управлява съобщенията в рамките на съответната сесия. Обикновените съобщения в опашката вече не прекъсват работата автоматично след 30 секунди.
  • При избора на сесия са възможни точни идентификатори или заглавия, както и еднозначни префикси на идентификатори; долният колонтитул показва съответния агент и сесията.
  • Всеки HTTP опит получава нов идентификатор на заявка, освен ако повикващият не зададе такъв. Диагностиката не променя фактурирането.
  • Доставените версии на AgentSpine и Translate Native остават непроменени. По-ниски разходи и по-бързи отговори в реална работа не са доказани.
  • /question: Отваря отново чакащи допълнителни въпроси. Сгъването не отговаря на въпрос и не го отхвърля.

Байтовете на заявката, оценените количества токени, сумираният разход на сесията и фактурираните токени са различни величини. Индикацията за разход отчита и проверката на отговора. /usage cost с дневни или месечни разходи не принадлежи към тази версия. По-ниски разходи или по-бързи отговори в реална работа не са доказани.

BLUN King

BLUN King 9.1.603

Публикувано на

Избери работната си папка в диалогов прозорец на Windows. Ако конзолата е стартирана от System32, тя сега предлага потребителската ти папка.

  • Ако под Windows избереш друга работна папка, се отваря диалогов прозорец за папки. Можеш да въведеш пътя и на ръка. Ако отмениш диалоговия прозорец, се връщаш към избора на папка, без да поемаш папка.
  • Ако няма наличен диалогов прозорец за папки, конзолата изисква пътя. На други операционни системи остава въвеждането на път.
  • Ако при старт се поеме или е запазена папка в рамките на директорията на Windows, изборът на папка предлага твоята потребителска папка. Ръчно въведените пътища продължават да се проверяват както досега.

Версиите на AgentSpine и Language Guard остават непроменени спрямо 9.1.602. Печалба в скоростта за работещи сесии не е доказана с тази актуализация.

Под Windows продължава да е необходим Git Bash. Ако конзолата съобщи, че Git Bash липсва, инсталирай Git for Windows. След това отвори отново командния ред, преди да стартираш отново king.

BLUN King · Публикувано

BLUN King 9.1.602

Публикувано на

Отделна частна папка за по-стари резултати от инструменти, когато наследени Windows права възпрепятстват изнасянето.

  • Подходящи по-стари резултати от инструменти се складират в отделна частна папка, когато наследени Windows права възпрепятстват изнасянето. Съществуващите файлове, правата и пълната история на сесията остават непроменени.
  • Проверките за цялост, правата за четене и връщането към пълния контекст се запазват, ако архивиран резултат не може да бъде възстановен. AgentSpine 0.73.0 и Language Guard 6.20.0 остават непроменени спрямо 9.1.601.

По-кратко време за отговор в реална работа или по-нисък фактуриран разход на токени все още не са доказани.

BLUN King · Публикувано

BLUN King 9.1.601

Публикувано на

Входовете остават в опашката, по-старите резултати от инструменти получават проверени препратки, а проверките на отговори, ограничени по честота, се повтарят ограничен брой пъти.

  • Ако фоновата работа първа получи думата, терминалните входове остават в опашката в първоначалния си ред. Всеки вход се показва само веднъж.
  • Подходящи по-стари резултати от инструменти се заменят в моделните заявки с проверени препратки към частни файлове. Пълната история и резултатите от текущата стъпка на разговора се запазват. Ако повторното зареждане не е възможно, не е разрешено или съдържанието е било променено, се изпраща пълният изход.
  • Естествена проверка на отговора, ограничена по честота, се повтаря веднъж със същата чернова на отговора. При това важи запазеният срок за изчакване на доставчика. Вече завършени извиквания на инструменти не се повтарят, непроверени текстове не се освобождават.
  • До 2 048 токена за изход остават свободни като буфер за отклонения при оценката на входа. Прозорецът на контекста не се намалява; по-малки изрично зададени ограничения за изход остават непроменени.

Тези промени не доказват нито по-нисък фактуриран разход на токени, нито по-кратко време за отговор в реална работа. Те не отстраняват и всяка сървърна HTTP-502 грешка.

BLUN King · Публикувано

BLUN King 9.1.600

Публикувано на

Проверка на отговора с фиксирани времеви граници и фиксирани състояния на компонентите.

BLUN King 9.1.600 е публикуван. npm и публичният манифест за актуализации съвпадат. Публикацията не доказва нито инсталация на твоя компютър, нито приемане в реална работа.

Ограничена проверка на отговора

  • Общите проверяващи запазват досегашния срок от 30 секунди. Естествената езикова проверка получава от стартовия сигнал на доверения хост компонент до 90 секунди за първия съдържателен текст, веднъж на външен проверъчен опит.
  • Съдържателен текст в рамките на допустимата дължина на изхода, както и подредените преходи към одобрение и към проверка на доказателството нулират срока за изчакване съответно на 30 секунди.
  • За всеки външен проверъчен опит независимо от това важи обща граница от 120 секунди. Напредъкът не може да удължи тази граница. Остават най-много два външни проверъчни опита.
  • Преди приемането на одобрение отново се проверява действително изминалото време. Дори при забавени извиквания на таймерите изтекъл проверъчен опит остава блокиран; закъснелият напредък не може да поднови изтекъл срок.

Сигналите за прекъсване продължават да се зачитат. Свързването с точния текст на отговора, времевата валидност на доказателството за одобрение и авторизацията продължават да се проверяват.

Доставени компоненти

Версия 9.1.600 съдържа AgentSpine 0.73.0 и Translate Native 6.155.0. Guard протоколът остава непроменен на 6.20.0.

Известни ограничения

Новите времеви граници не доказват общо отстраняване на HTTP-502 грешки в реална работа. Отворените наблюдения от 9.1.599 остават отворени без отделно доказателство от реална работа.

Контекст и помощ

Промпт, който трябва да се запази изцяло, вече не се съкращава мълчаливо, само за да се побере в по-малък твърд прозорец на модела. При ново, изрично определено разпределение на потребителските съобщения, които трябва да се запазят, със стандартен бюджет от 20 000 токена, настройката може да завърши в рамките на същото сгъстяване. При по-късни или възстановени префикси не бива да се изхвърлят допълнителни изисквания. Заявката трябва и занапред да се побира в твърдия прозорец на модела.

Чистите повиквания за помощ с --help или -h вече не създават диагностично състояние по време на изпълнение. Ако се комбинират промпт и аргументи за помощ, досегашното поведение по време на изпълнение се запазва.

BLUN King · 18 септември 2026

BLUN King 9.1.599

Публикувано на

Проследими отделни одобрения за личната памет и допълнителни корекции при превишаване на контекста.

Заявките за одобрение за личната памет показват разбираеми заглавия на действията на избрания език и пълни предварителни прегледи на действителните промени в настройките или на текста, който ще се запази. Управляващите знаци се маскират видимо; оригиналното съдържание остава непроменено.

Валидните промени в паметта трябва да се одобряват поотделно; невалидните входове могат само да се отхвърлят. Одобрението за цялата сесия не одобрява автоматично чакащи заявки, които изискват отделно одобрение.

Проверката на пакета обхваща 37 функционални области със 199 задължителни проверки, 158 проверъчни изпълнения и 4 905 различни издържани теста. Допълнително актуализациите от 9.1.597 и локалната междинна версия 9.1.598 до 9.1.599 бяха проверени в изолирани инсталации с непроменения updater и инсталационен път. И двата теста разпознаха версията през публичните източници за актуализации и провериха всички 918 файла на архива на изданието.

Указанията в README.md и CHANGELOG.md на непроменения пакет 9.1.599 описват състоянието на кандидата при опаковането. Те не са променяни със задна дата след локалната инсталация. Тази публична страница продължава отделно състоянието на изданието и по-късно наблюдаваните ограничения.

Известни ограничения в 9.1.599

В реална работа продължават да се наблюдават повтарящи се HTTP-502 отговори, отчасти последвани от успешни заявки. Корекциите на контекста не са общо отстраняване на грешки на доставчика или в мрежата.

Езиковата проверка може да прекъсне отговор с missing-language-character-profile или suspected-ascii-substitution. Този резултат остава отворен; 9.1.599 не съдържа доказана корекция за него.

Отговор на изпратеното изображение беше потвърден от потребителя. Независима проверка на интерпретацията на изображението, както и визуалното приемане на входа и статусните редове предстоят. Издържаните проверки на пакета не са общо успокоение за тези процеси.

Поето от локалната междинна версия 9.1.598

Без дата

9.1.598 беше проверена и инсталирана локално, но не е публикувана като самостоятелна npm актуализация. Следните промени се съдържат в 9.1.599:

  • При отказ на контекста долните граници за броя входни токени се различават от точните данни. За отчетена долна граница ограничението на изхода се намалява веднъж, без да се изхвърлят съобщения или инструменти. Сигналите за прекъсване и ограничаването на по-нататъшните опити остават в сила. Така възпроизведената в 9.1.597 грешка при изчисляването на ограничението на изхода се коригира целенасочено.
  • Първоначалните 150 сменящи се думи за активност отново са включени. За показването им не се отправят допълнителни моделни заявки.
  • При доверения AgentSpine входен хук вместо пълните медийни данни се предава компактна медийна препратка с тип, SHA-256 контролна сума и размер. Пълните приложения за модела и съществуващите защитни проверки се запазват. Само това все още не доказва успешна интерпретация на изображения в реална работа.

Ново в 9.1.597

Публикувано на

Ограничено възстановяване при изрично отчетено превишаване на контекста, също и зад отговор за грешка от Gateway.

Ако заявка бъде отхвърлена преди началото на изхода поради доказано превишаване на контекста, King може да предприеме ограничен нов опит с по-малко ограничение на изхода. Съответно опакованите грешки в 502 отговор също се разпознават. Съобщенията, инструментите, по-малките изрично избрани ограничения на изхода и сигналите за прекъсване се запазват. Вече започнал stream не се възпроизвежда отново.

Това не отстранява всички грешки на доставчика или в мрежата. Общите прекъсвания на връзката и отказите на услуги трябва и занапред да се проверяват по собствените си данни за грешки.

Известно ограничение в 9.1.597: Ако сървърът съобщи само долна граница за броя входни токени, новият опит може отново да се провали и да предизвика ненужни сгъстявания. Този случай беше възпроизведен на 17 септември 2026 след публикуването. Допълнителната корекция от локалната междинна версия 9.1.598 се съдържа в 9.1.599.

Проверени бяха 36 функционални области със 183 задължителни проверки и 4 407 различни издържани теста, както и истинското актуализиране от 9.1.596 до 9.1.597. Тази проверка на пакета не заменя тест за приложение на вече отворена клиентска сесия.

Ново в 9.1.596

Публикувано на

Автоматичните прекъсвания в полза на чакащи Telegram съобщения се различават от истинските ръчни прекъсвания. Такова прекъсване от опашката вече не се съобщава погрешно като натискане на клавиша Escape. Срокът за изчакване, защитните правила за работещи инструменти и поведението при истинско ръчно прекъсване се запазват.

Ново в 9.1.595

Публикувано на

Опционалните схеми на инструменти се зареждат при нужда през ToolSearch и се съхраняват ограничено. Големите каталози със skills се предоставят компактно и на страници. Търсенето, по-късните MCP разширения и нормалните проверки на права се запазват.

При кратки поздрави King може да използва ограничен по-нов откъс от разговора, без да изтрива запазени съобщения или да съкращава системни инструкции. За последваща работна задача King отново отчита запазената работна история. Изчислението на контекста се запазва и след продължаване на сесия. Фиксиран разход на токени за всеки поздрав не се обещава.

Ново в 9.1.594

Публикувано на

  • Частните Telegram отговори остават възможни, докато груповите съобщения чакат. Приписването на slash команди се запазва.
  • Дългите срокове за изчакване от Retry-After се спазват; при продължаване на сесия оставащата пауза се възстановява.
  • След отхвърлено придружаващо описание вече завършена стъпка с инструмент продължава да се обработва. Отхвърленото описание не се публикува, проверката на окончателния отговор не се отслабва.
  • Ограничените функции за възстановяване при писане на няколко части отново са налични. Това важи и за времевите граници на shell, управлението на задачи и възстановяването на сесии.
  • Входът, редовете за квоти, индикацията за активност, разгъваемите задачи и резултатите от инструменти с обозначаване на източника остават видими при стрийминг и при навигация в историята.
  • Преди опаковането са необходими пълни регресионни доказателства за конзолата; публичните метаданни за актуализации се проверяват за съответствие.

Междинни версии 9.1.590 до 9.1.593

Тези версии присъстват в локалната история на изданията, но на 17 септември 2026 не са включени в публичния npm списък с версии. Тук те не се препоръчват като публично достъпни актуализации. Работата по старта, възобновяването, правата, индикацията за активност и видимия вход е взета предвид в доказателствата за 9.1.594.

Ново в 9.1.589

Публикувано на

  • Проверените източници на AgentSpine и Translate Native, както и верифицираните манифести за актуализации се доставят.
  • При зареждане на агентния контекст активният профил на King се запазва.
  • Инструментите, необходими за проверката на отговора, остават налични. Разходът при създаването на отговора се отчита и тогава, когато проверката отхвърли отговора.
  • В управляваното свързване на канали груповите съобщения се приписват само при изрично споменаване.
  • Конзолата показва текущото сгъстяване и действащите прагове.
  • Работният бюджет за ранно сгъстяване и защитният резерв на границата на заявката се запазват при актуализациите.
  • Диалогът за актуализация при старт, напредъкът и указанията за предварително отбелязани актуализации използват последователно избрания език.
  • Техническите интеграционни идентификатори и лицензите се запазват; видимите съобщения за грешки по време на изпълнение се формулират неутрално.
  • Инсталацията не рестартира съществуващи сесии. Работеща сесия зарежда новия код при следващия старт.

9.1.588: изтеглено

Публикувано на

Тази версия беше публикувана на 11 септември 2026 и впоследствие маркирана като изтеглена в npm. Регистърът посочва неуспешна проверка за съвместимост на манифеста за актуализации. Използвай актуалната стабилна версия, а не този изтеглен пакет.

Ново в 9.1.587

Публикувано на

По-стабилни каталози с инструменти, по-ранно автоматично сгъстяване и целенасочен повторен опит след прекъсвания поради прекалено дълги чисти фази на размисъл.

При буферирани инструкции в рамките на текущ работен ход активният каталог с инструменти се запазва и в следващата работна стъпка. Необходимите инструменти остават налични. Ако съществуващият бюджет за схеми бъде превишен, запазените опционални дефиниции на инструменти се избират наново.

Автоматичното сгъстяване на контекста отново започва по-рано. След успешно сгъстяване, което намалява историята, King може да го изпълни отново в същия ход. По-ниските граници на модела и ограничаването на неуспешните опити остават в сила.

След прекъсване поради прекалено дълга чиста фаза на размисъл King използва съществуващия еднократен повторен опит с изключено мислене, за да може моделът да отговори или да извика инструмент. Следващите редовни стъпки запазват избраната настройка за мислене; прекъсването, проверките за одобрение и времевите граници остават в сила.

С BLUN_STABLE_STEER_TOOLS=0 или BLUN_EARLY_COMPACTION=0 преди старта на King може да се възстанови досегашното поведение за съответната функция. Актуализацията не пренаписва съществуващи сесии или конфигурационни файлове.

Ново в 9.1.586

Публикувано на

Приемането на Telegram под Windows стартира отново, когато старият идентификатор на процеса на bridge вече принадлежи на друг процес. При несигурно приписване на процес King не се намесва; чуждият процес не се прекратява.

Сгъстяването на контекста, настройките на модела, историята на разговора и досегашното поведение при доставка на Telegram остават непроменени.

Ново в 9.1.585

Публикувано на

BLUN King · 8 септември 2026

Версия 9.1.585 проверява структурата и отделните резултати на управлявани WebSearch отговори и тогава, когато опционалните данни за състоянието на търсенето липсват.

Отговор без валиден списък с резултати вече не се извежда като успешно търсене без резултати. Всеки резултат трябва да съдържа заглавие, което не е празно и не се състои само от интервали, текстов откъс като низ и абсолютен HTTP или HTTPS адрес без вградени данни за достъп. Невалидните резултати водят до отхвърляне на целия отговор, преди да се върнат резултати или указания за непълни резултати от търсенето.

Валидните отговори в досегашния формат без данни за състоянието продължават да се поддържат, както и празните списъци с резултати и празните низове като текстови откъси. При валидни отговори редът, точните URL низове, опционалните данни за дата и уебсайт, посочването на източниците в изхода и обработката на непълни резултати остават непроменени.

Променя се само управляваната връзка за търсене. Поведението при прекъсване, удостоверяването на заявките, FetchURL и Telegram остават непроменени. Проверката на формата не доказва, че даден източник е коректен или актуален. Тази версия не въвежда нито ограничение на размера на отговорите, нито нов срок.

Ново в 9.1.584

Публикувано на

Версия 9.1.584 предава сигнала за прекъсване на повикващия през WebSearch до управляваната HTTP заявка за търсене, включително при четене на съдържанието на отговора.

Вече прекъснати търсения не предизвикват обработка при доставчика. Ако прекъсването настъпи по време на установяване на данните за достъп, след това не се изпраща заявка за търсене. Резултатите, пристигнали след прекъсването, не се връщат като успешно търсене.

Проверките за прекъсване обхващат и успешните JSON отговори, съдържанието на отговорите за грешки и указанията за непълни резултати от търсенето. Обработката на пълни, непълни и празни резултати, посочването на източниците и обичайната процедура за резервен вариант при удостоверяване остават непроменени.

Тази версия не въвежда нов срок и не променя приписването на Telegram. Споделените процеси за подновяване на OAuth данните за достъп и транспортните реализации, които игнорират сигналите за прекъсване, не се прекъсват принудително. Прекъсването на клиентска заявка не доказва, че работата на отдалечения сървър или нейното фактуриране е приключило.

Ново в 9.1.583

Публикувано на

Прекъсване при извличането на страница вече се предава до HTTP заявката.

FetchURL предава сигнала за прекъсване на повикващия през инструмента и двете услуги за извличане. Заявка, прекъсната преди старта, не се изпраща. Ако прекъсването настъпи по време на установяване на данните за достъп, управляваната HTTP заявка след това не се стартира.

След прекъсване на управлявано извличане не се стартира повече локален резервен вариант. Закъснял резултат от услугата за извличане се задържа и не се използва като доказателство за източник. При обичайни HTTP и мрежови грешки досегашният локален резервен вариант остава възможен.

Не се въвежда нова времева граница. Споделено подновяване на данните за достъп и синхронната HTML обработка не се прекъсват принудително. Ограничението на размера от 9.1.582 остава; маршрутизирането на Telegram и моделните заявки остават непроменени.

Ново в 9.1.582

Публикувано на

Локалното извличане на страница проверява размера на отговора още при прочитане и спира при превишаване на границата.

Локалното извличане брои входящите байтове на отговора преди декодирането на всеки блок данни и спира потока от данни веднага щом границата на размера бъде превишена. Ако данните за Content-Length липсват или са грешни, вече не се прочита целият отговор и след това се отхвърля.

Стандартната граница остава десет MiB и важи за потока на отговора след HTTP декомпресията. UTF-8 знаците, разпределени върху няколко блока данни, се запазват. Транспортните буфери и блокът данни, с който границата се превишава, могат вече да са в паметта; с това не е свързана точна горна граница за цялата памет на процеса.

Променя се локалният път за извличане, също и когато служи като резервен вариант. Корекциите на проучването от 9.1.581 остават включени. Маршрутизирането на Telegram и времето за изчакване на модела остават непроменени.

Ново в 9.1.581

Публикувано на

При локално извличане на страница празните HTML откъси вече не се извеждат като успешни източници.

Ако след почистването и преобразуването не остане съдържание на страницата, заглавието на документа само по себе си вече не е достатъчно за успешно извличане. Вместо това се връща вече съществуващата грешка при извличането.

Кратките истински съдържания и видимите заглавия се запазват. Отговорите в обикновен текст или Markdown формат остават непроменени. Корекцията засяга локалното HTML извличане, а не управляваната услуга за извличане.

Корекциите на проучването от 9.1.580 и досегашните корекции на Telegram са включени непроменени. Тази актуализация не променя нито времето за изчакване на модела, нито приписването на входящите съобщения към техните получатели.

Ново в 9.1.580

Публикувано на

Съхранението на проучвания отхвърля невалидни исторически дати за източници.

Нов доклад не се записва, ако дата за източник съдържа невалиден календарен ден или неоценима часова част. Липсващите дати остават допустими.

При извличането на запазени доказателства от проучвания по-старите доказателства с невалидни дати за източници се пропускат и се отбелязват с диагностично указание. Файловете не се пренаписват и не се изтриват. Отделните валидни доказателства остават търсими; валидните дати запазват своето часово отместване и точност.

Сортирането на доказателствата от проучвания от 9.1.579 и досегашните корекции на Telegram са включени непроменени. Тази актуализация не променя нито времето за изчакване на модела, нито приписването на входящите съобщения към техните получатели.

Ново в 9.1.579

Публикувано на

Запазените доказателства от проучвания се сортират при еднаква релевантност по действителния момент на извличане.

Данните за време със и без милисекунди се сравняват като UTC моменти, а не като текст. Релевантността продължава да има предимство; при идентични моменти досегашният ред се запазва.

Ако едно и също място в текста е било обхванато многократно, резултатът запазва данните за произход от най-новото извличане. Вече запазените доказателства остават непроменени и поради това не се смятат за новопроверени източници.

Корекцията за Telegram отговорите от 9.1.578 е включена непроменена. Същото важи за ограничаването на повторните опити, когато моделът само размишлява, без да достави отговор или извикване на инструмент. Тази актуализация не променя нито времето за изчакване на модела, нито семантичното приписване на входящите съобщения.

Ново в 9.1.578

Публикувано на

Ограничени повторения, когато моделът само размишлява и достига времевата граница, както и целенасочена корекция за кратки групови Telegram отговори с връзка към въпрос.

Ако моделът достигне времевата граница, докато само размишлява, King допуска един допълнителен опит на стъпка. Второ такова превишаване на времето приключва стъпката. Избраният effort за размисъл и досегашната времева граница остават непроменени. Това ограничение не съкращава чакането за първия изход на модела.

Кратките отзиви за собственото присъствие в Telegram групи вече могат да се изпращат, когато reply_to ги свързва с вход на не повече от 30 минути от същия чат. Този вход трябва изрично да се обръща към агента или да съответства на поддържан немски или английски въпрос за неговото присъствие, който започва с неговото настроено име. Непоисканите съобщения за присъствие и обясненията, че няма какво да се съобщи, продължават да се филтрират. Автоматичната резервна доставка в групи остава изключена.

Протоколите на изпратените и потиснатите отговори вече съдържат reply_to. При липсващ или нееднозначен контекст изключението не важи. Тази актуализация не добавя общо разпознаване на получатели и не предотвратява ненужни моделни повиквания от досегашното семантично адресиране.

Корекцията важи за две точно идентифицирани версии на управлявани Telegram MCP изпращачи и действа и при окончателното обединяване на конфигурацията на приставката. По-старият изпращач използва съвместимо копие с тясно ограничени промени. Входните bridge компоненти, настройките за достъп, профилите и регистрите на приставки не се пренаписват. Непознатите или променени изпращачи, както и изрично зададените презаписвания се запазват. King трябва да се рестартира след актуализацията, за да се зареди корекцията.

Ново в 9.1.577

Публикувано на

Повече няма автоматични заключителни съобщения в Telegram групи. Полезните отговори там се изпращат целенасочено през инструмента за отговор на Telegram.

CLI ядрото и самостоятелният Telegram bridge вече не препращат автоматично нормалния заключителен текст на агент към групи. Така указания като „Няма какво да се съобщи“ вече не попадат в групата през тази автоматична резервна доставка.

Отговорите в лични чатове, изрично използваните инструменти за отговор, необходимите целеви резултати, съобщенията за команди и статус, както и изпращането на медии се запазват. Инструкциите в промпта за нормални входове, управляващите съобщения по време на текущ процес и груповите съобщения на самостоятелния bridge вече съдържат същото правило за доставка.

Това не гарантира, че модел никога няма да изпрати ненужен отговор чрез извикване на инструмент. Корекцията също не пречи на групови съобщения без връзка със съответния агент да достигат до модела. Правилата за споменаване, настройките за достъп и разрешаването на управлявани приставки остават непроменени; актуализация на AgentSpine или на езиковия пазач не е включена.

Актуализираното ядро трябва да се зареди от нов процес. Работещите сесии не се рестартират автоматично. Съществуващите профили и историята на сесиите се запазват.

Ново в 9.1.576

Публикувано на

BLUN King 9.1.576 различава C++ и C# при локални заявки за проучване и съдържа предварително публикуваните корекции за актуализации, възобновяването на сесии и Telegram.

Търсенето в локалните доказателства от проучвания третира самостоятелните C++ и C# като различни термини, също и при различна големина на буквите и със заобикаляща пунктуация. Запазените места в текста, хешовете, защитните проверки за източници, Unicode нормализацията, границите на колекциите и ограниченията на изхода остават непроменени. Повторно индексиране не е необходимо.

Определен проверъчен прогон с 20 технически заявки за търсене и целенасочени регресионни тестове за границите на токените проверяват тази корекция. Тя засяга локалното търсене и не е изявление за качеството или капацитета на WebSearch в реална работа. Всички промени от 9.1.575 остават включени.

Ново в 9.1.575

Публикувано на

Вграденият уеб обхождач отхвърля отговори с cf-mitigated: challenge, преди да прочете съдържания, да последва пренасочвания или да приеме липсващ robots файл като разрешение да продължи. При имената на заглавките той не прави разлика в големината на буквите; освен това проверява нормализирани стойности и многократно срещащи се заглавки. Състоянието на отговора остава в отчета за грешки.

Липсващите robots файлове без тази маркировка и обикновените документационни страници продължават по съществуващата процедура. Вече завършените страници остават налични, когато по-късна страница бъде отхвърлена; грешката се отбелязва като непълен резултат. Тази защита проверява маркировка на отговора. Тя не е нито общо разпознаване на challenge, нито заобикаляне на CAPTCHA. Доставчиците на търсене, удостоверяването, заключванията за актуализации и CLI ядрото остават непроменени. Всички промени от 9.1.574 остават включени.

Ново в 9.1.574

Публикувано на

Изрично поисканите актуализации вече различават блокирана актуализация, недостъпна проверка за заключване, недостъпна частна директория, невалидна инсталирана версия и недостъпен защитен инсталатор. Тези случаи вече не се отчитат общо като неуспешна проверка на пакета. Промяната важи за немски и английски съобщения.

Разрешението за актуализация, поведението при заключване, причините за връщане, изходните кодове и поведението на инсталатора остават непроменени. Работещите сесии не се прекратяват автоматично. Пакетите, фиксирани към стар вътрешен канал, изискват и занапред изрична npm инсталация при спрян King; тази версия не отменя фиксацията. Всички промени от 9.1.573 остават включени.

Ново в 9.1.573

Публикувано на

Полето за вход остава видимо и фокусирано след избора на цел при старт, също и след Escape или неуспешно възобновяване на целта. Неизпратените чернови се запазват. Вместо пълния текст на целта се появява компактен избор за продължаване със или без цел.

Ctrl+S напуска избора, без да потвърди целта, и се обработва като обичайна клавишна комбинация за опашката. Вземат се предвид и чакащите входове при празен ход. Escape запазва досегашния си ред: първо изпразва опашката, при следващия Escape прекъсва активния прогон. Историята на сесията не се изтрива автоматично.

Тази версия не реконструира потвърждения за доставка, които по-стар процес е загубил преди актуализацията. Действително чакащите съобщения остават приписани към своята сесия.

Ново в 9.1.572

Публикувано на

При доказателствата от проучвания се отхвърлят URL адреси на източници, чиито параметри на заявката или параметроподобни фрагменти съдържат известни имена на параметри за данни за достъп. Проверяват се и вложените имена и маршрутите във фрагмента. Отхвърлянето важи както за неуспешни, така и за използваеми източници.

Вече запазените доклади с такива URL адреси се задържат при извличане със съществуващия резултат partial / report-invalid. Първоначално запазените състояния не се променят и не се изтриват; адресите на източниците не се съкращават или пренаписват мълчаливо. Обикновените параметри на заявката и котвите в документационните URL адреси се запазват байт за байт. Защитата разпознава известни имена на параметри, не произволни тайни, и не почиства история.

Ново в 9.1.571

Публикувано на

Областите от опашката на Telegram се приписват към своята сесия. Нова сесия вече не поема автоматично чакащата работа на по-стара сесия. При продължаване на позната сесия се възстановяват само нейните собствени чакащи области. По време на избор, създаване и смяна на сесия поемането на канални съобщения е на пауза. Съобщенията, пристигнали след избраната граница, последващите входове в локалния редактор и закъснелите потвърждения за доставка запазват правилното си приписване.

Приписването и потвържденията за доставка, пристигащи в различен ред, остават при повторно свързване и предаване на lease. Повредено или заменено състояние на опашката се отхвърля, вместо стари входове да се възпроизвеждат незабелязано отново. Пощенската кутия и историята на сесията се запазват. Стари чакащи области без разпознаваема сесия се отлагат и не се приписват на нова сесия; тяхното автоматично възстановяване не е включено. Това не отстранява всяко превишаване на времето или блокирано сгъстяване на контекста. Понижаването на версията не е процедура за мигриране на опашката.

Telegram приставката и независимата резервна функция на конзолата за автоматична доставка на отговори потискат разпознатите потвърждения за получаване и текстове, които само обявяват собственото мълчание, също и над 200 знака. Ако съобщение съдържа непозната или съдържателно значима част от изречение, то се запазва. Кратките полезни групови предупреждения могат и занапред да се доставят. Това е предпазлив немско-английски филтър за доставка с допълнителни инструкции, не гаранция, че всеки модел разбира всеки групов разговор.

Нов процес трябва да зареди актуализирания пакет; работещите сесии не се рестартират. Съществуващите фиксации към вътрешни канали за актуализации и Windows инсталационните заключвания с EBUSY остават отделни проблеми. Всички останали промени от 9.1.570 остават включени. Тази версия не активира хостирано уеб търсене и не променя нито AgentSpine, нито фактурирането, удостоверяването или клиентската конфигурация.

Ново в 9.1.570

Публикувано на

Всяка нова доставка на промпт получава собствен идентификатор за корелация на хука. Хуковете от една и съща доставка запазват същия идентификатор; изрично зададените идентификатори се запазват. Стойностите на средата, специфични за сесията, достигат до подпроцесите на хуковете и MCP връзките и при повторно свързване, без да се пренаписват запазени конфигурации на приставки. Приписването на резултатите от естествените инструменти се запазва през прогоните, също и при неуспешни инструменти и дублирани извиквания.

Канонично еквивалентните Unicode заявки за проучване намират същите резултати, без да приравняват различни знаци. Запазените източници, дати, версии и граници на проекта се запазват. king --help и king --version вече не променят настройките на Windows регистъра за дъмпове при срив.

Уеб търсенето поддържа частични отговори, когато този режим на отговор е договорен, и показва при това указание за отказали източници. Празните или несъвместимите частични отговори остават изрични грешки. Тази клиентска промяна не активира хостирана услуга за търсене и не гарантира нейната работа.

Транспортът BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE е изключен по подразбиране. При изрично активиране той предава действителния път на запазения протокол на сесията и съответния протокол на избраната AgentSpine приставка. Всяка сесия получава собствено право за достъп, след възобновяване то се подновява. Това е транспортна поддръжка, не доказателство за извличане на спомени или за авторизация от получаващата приставка.

Всички публични промени от 9.1.569 остават включени. Вградената AgentSpine реализация остава непроменена; не възниква зависимост от Mnemo. Потребителските профили, правата, разговорите и настройките на приставки не се мигрират и не се нулират.

Ново в 9.1.569

Публикувано на

Тази кумулативна публична версия съдържа доставката в Telegram групи въз основа на споменавания, корекции за старт и права, както и колекции от проучвания и инструменти за обхождане. Публикуваните пакети остават непроменени. По-късните промени се появяват под нов номер на версия.

Ново в 9.1.566

Публикувано на

BLUN King 9.1.566 прави актуализациите на приставки и зареждането на естествени модули на средата за изпълнение по-стабилни.

Вградената среда за изпълнение на AgentSpine се актуализира до версия 0.59.1. Неговият механизъм за самостартиране пропуска корена на потребителски профил като цел за сканиране, а всички lifecycle хукове остават защитени срещу грешки, когато защитен път не може да се прочете.

Естествените .node модули се разрешават през кеш, адресиран по съдържание, извън npm пакета. Щом тази версия е активна, работеща конзола вече не държи отворено копието на пакета с тези модули. По-късните актуализации могат поради това да заменят директорията на пакета, без да влизат в конфликт с тези естествени файлове.

Публичният пакет запазва пълните испански, френски, шведски и чешки каталози на интерфейса от версия 9.1.565. Вътрешните пътища на средата за изпълнение на Mnemo, частните крайни точки, вътрешните доставчици на модели и скриптовете за изграждане не са включени.

Проверено състояние на пакета

Клиентският пакет издържа сканирането за течове, пълната проверка на средата за изпълнение с 13 теста, AgentSpine MCP инициализацията, чиста инсталация и актуализацията от 9.1.565. Всички текстови файлове използват LF краища на редовете. SHA-256 на npm пакета: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Ново в 9.1.565

Публикувано на

BLUN King 9.1.565 стабилизира дългите работни прогони и разширява вградената среда за изпълнение на AgentSpine.

Спирачката за повторения нулира своята поредица от еквивалентни резултати веднага щом между тях напредне истинска работа. Нормалните проверки на пощенската кутия и списъка със задачи поради това не предизвикват повече фалшив принудителен отговор.

Индикацията за активност се състои от точно един ред. Тя показва подходящата английска дума за статус за текущата дейност, токените на скритото мислене, видимите токени, общия разход, effort, опита, бюджета и стъпката.

Грешките при сканиране на AgentSpine продължават да се обработват безопасно при мутационните инструменти, потребителските входове и Stop хуковете: следващият процес може да продължи, а грешката се записва в одитния протокол. Преди фатално прекъсване поради изключение или необработен отказ конзолата записва синхронно протокола на средата за изпълнение.

Вградената среда за изпълнение на AgentSpine се актуализира до версия 0.54.0 от commit fb6d456b68605fd83721090e503f000a26e8a0fb. Състоянието съдържа истинския ACL fail-open тест, трайните планове за цели, обвързани със зависимости, и обвързаното изясняване на пропуски в знанията.

Lifecycle хуковете SessionStart, UserPromptSubmit, PostToolUse и Stop се изпращат към Mnemo с точната идентичност MNEMO_AGENT. Мрежовите грешки продължават да се обработват безопасно.

Преди това липсващите текстове на интерфейса вече са пълни на испански, френски, шведски и чешки.

Проверено състояние на пакета

Пълната врата за пакета, сканирането за течове, проверката на езиковия каталог, пробата на ACL хука, чистата инсталация, актуализацията от 9.1.564 и AgentSpine MCP инициализацията са зелени. SHA-256 на npm пакета: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Ново в 9.1.564

Публикувано на

BLUN King 9.1.564 предотвратява сривове поради защитени папки и липсващи текстове на интерфейса.

AgentSpine пропуска при подготвителното сканиране на файлове отделни файлове и папки, които операционната система заключва с EPERM или EACCES. Неочаквана грешка при сканирането вече не блокира следващото извикване на инструмент; тя се пропуска и се записва в одитния протокол.

Ако в публикуван език на интерфейса липсва текстов ключ, конзолата използва английския текст и записва празнината еднократно, вместо да се срине в пътя за изобразяване. Така остава използваем по-специално редът за състоянието на мисленето на чешки, испански, френски и шведски.

Действителните преводи на все още липсващите ключове следват в отделно проверена версия. Дотогава английският резервен вариант е съзнателно видим и защитен срещу грешки.

Проверено състояние на пакета

Пакетът беше проверен срещу точния чешки срив на thinking.step от 9.1.563. Новата версия доставя „step 6“ вместо изключение, предупреждава само веднъж на език и ключ, преживява недостъпни съседни папки, инициализира AgentSpine 0.49.0, издържа чиста инсталация и актуализацията от 9.1.563 и не съдържа неразрешени импорти на приставки. SHA-256 на npm пакета: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Ново в 9.1.563

Публикувано на

BLUN King 9.1.563 актуализира вградената среда за изпълнение на AgentSpine до версия 0.49.0.

Новото състояние изисква преди опит за учене поне едно свежо, независимо доказателство от изрично потвърждение на потребител или обективен тест. Чистите разговорни или документални доказателства вече не са достатъчни, дори ако останалите им прагове са изпълнени.

Учебните договори обвързват трайно това правило за доказателства; по-късните промени в конфигурацията не могат да отслабят текуща проверка. Заключванията на файлове, обвързани със собственост, защитават паралелните промени при учене от презаписване и оставят манипулираните или чужди заключвания да се провалят затворено.

Актуализацията заменя управляваното дърво на приставките при следващия старт, адресирано по съдържание. Съществуващите инсталации на версия 9.1.562 се актуализират до AgentSpine 0.49.0, непроменено дърво се преизползва, а AgentSpine MCP сървърът потвърждава версия 0.49.0.

Проверено състояние на пакета

Границата на пакета се различава от 9.1.562 само по данните за версията и точно фиксираната среда за изпълнение на AgentSpine 0.49.0. Пълната проверка на upstream, 49 целенасочени теста за учене, сравнението на пакетите, сканирането за течове, чистата инсталация, истинският път за актуализация от 9.1.562 и MCP инициализацията са зелени. SHA-256 на npm пакета: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Ново в 9.1.562

Публикувано на

BLUN King 9.1.562 възстановява файла на средата за изпълнение на AgentSpine в публичния пакет.

Необходимият файл на средата за изпълнение за вградения AgentSpine MCP сървър отново се доставя. Чиста инсталация материализира приставката напълно; MCP сървърът стартира и потвърждава своето име и версията на протокола.

Проверено състояние на пакета

Границата на пакета се различава от 9.1.561 само по метаданните на версията и възстановения файл на средата за изпълнение. Сканирането за течове, чистата инсталация, материализирането на приставката и истинска MCP инициализация са зелени. SHA-256 на npm пакета: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Ново в 9.1.561

Публикувано на

BLUN King 9.1.561 поема проверените подобрения на работната система в публичния пакет.

Текущата задача и пресните резултати от инструменти остават налични. Резултатите от четене не се съкращават. Големите резултати се запазват с препратка за повторно извличане, вместо да се изпразват. Повтарящите се идентични резултати препращат към най-новия пълен резултат.

Сгъстяванията се протоколират като транзакция с начало, резюме и край. Извикванията на инструменти и техните резултати остават заедно, докато трайните контролни точки осигуряват пътя за възстановяване през повторни опити.

Бюджетите за изход вече идват от активния профил на модела. Управляваният BLUN модел получава по подразбиране 128 000 токена за изход, когато не е зададена стойност изрично. Старите фиксирани граници от 32 768 токена, както и ниските граници за low и off, вече не съкращават сложната работа; капацитетът на контекста остава защитната граница.

Updater пита, преди да подготви или стартира инсталатора. В публичния пакет управляваният BLUN модел остава фиксиран; /model служи само като съвместим псевдоним за /effort.

Границата на пакета беше проверена по всички имена на файлове и четливи съдържания. Вътрешните пътища на доставчика, изборът на модел, скриптовете за изграждане и регресия, частните идентификатори и частните сървърни адреси не са включени.

Проверено състояние на пакета

Пълният пакет, сканирането за течове, чистата инсталация, изходът за версия и помощ, стандартните настройки на нов профил, както и решението за актуализация от 9.1.550 до 9.1.561 са зелени. SHA-256 на npm пакета: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Ново в 9.1.527

Публикувано на

BLUN King 9.1.527 поема процедурата /copy от DeepAgents.

Командата копира най-новия завършен, непразен отговор на асистента през съществуващия междуплатформен път на клипборда.

Ако /copy бъде въведено по време на текущ ход, командата използва съществуващата командна опашка и се изпълнява след завършване на отговора.

Ясните съобщения за статус покриват успеха, празната история и грешките на клипборда на всички шест езика на интерфейса.

Червено-зелена регресия защитава регистрацията на команди, изпълнението, избора на отговор, съдържанието на клипборда байт за байт и публикуваните текстове на интерфейса.

Проверено състояние на пакета

Пълният prepack и проверката на разопакования артефакт са зелени. SHA-256 на npm пакета: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Ново в 9.1.526

Публикувано на

BLUN King 9.1.526 материализира версията на AgentSpine, вградена в текущия пакет, преди /reload да изгради наново каталога на приставките и MCP конфигурацията.

Незасегнатите записи на приставки се запазват. Непроменено управлявано дърво на AgentSpine се преизползва, без installed.json да се пренаписва.

Червено-зелена регресия срещу 9.1.525 защитава реда на bootstrap, поемането на управляваната приставка и идемпотентното поведение при презареждане.

Проверено състояние на пакета

Пълният prepack, проверката на опакования артефакт и изолираният тест на updater от 9.1.525 до 9.1.526 са зелени. SHA-256 на npm пакета: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Ново в 9.1.525

Публикувано на

BLUN King 9.1.525 стартира всяка локална shell команда под Windows и POSIX в собствена група процеси. Програмите поради това вече не могат да се прикрепят към управляващата конзола на BLUN TUI и да прихващат Escape, Strg+S или други редакторски входове.

Стандартният вход, стандартният изход и изходът за грешки остават в частни канали. Интерактивните команди получават край на файла и се провалят или достигат изтичане на времето, без да се конкурират с редактора за входове.

Локалната изолация на shell от DeepAgents е възприета за Windows. Изпълним регресионен тест покрива и двата пътя на платформите и истинска проба с прихванат процес.

Ново в 9.1.524

Без дата

BLUN King 9.1.524 държи създадената от команда /loop на Telegram незабавна задача в защитения път за доставка на дистанционни команди. Така тя не може да остане като втори обикновен запис в опашката.

Списъкът за подновяване показва за всяка сесия размера на чекпойнта за подновяване, запазените съобщения и токени, размера на историята на сесията, както и липсващи, невалидни или остарели чекпойнти.

Вградената среда на AgentSpine се актуализира до проверения официален статус 0.11.4 с комит 8034487cdd24498076bac48d3f24400bca5e6ae4. Времевият бюджет на BLUN от 180 секунди за фоновото завършване на SessionStart остава запазен.

Изпълними регресионни тестове защитават точно еднократната доставка на Telegram loop-и и всички състояния на измерваните стойности за подновяване. Съществуващото локално поведение на опашката при зает loop остава непроменено.

Ново в 9.1.523

Публикувано на

BLUN King 9.1.523 оставя Escape да затваря отвореното меню на slash командите и да изчиства съответната чернова наведнъж, вместо да оставя текста на командата.

Strg+S предава slash чернова на съществуващия път за включване в опашката и обработка дори когато интерфейсът в момента отчита празен ход, вместо мълчаливо да се връща преди изпразването на опашката.

Обикновените чернови се запазват, когато Escape затваря само друго автоматично довършване.

Тестове по време на изпълнение от червено към зелено защитават и двете клавишни комбинации срещу точното поведение на пакета 9.1.522.

Ново в 9.1.522

Без дата

BLUN King 9.1.522 записва permission.approval_requested веднага при отваряне на разрешение за инструмент в историята на сесията. Непроследяван King по този начин вече не изглежда като ням модел или блокиран доставчик, докато чака оператора.

Съществуващите бутони за разрешение в Telegram се използват автоматично, когато списъкът за достъп съдържа точно един частен чат и произволен брой групи. При няколко възможни частни получатели изпращането остава блокирано, освен ако BLUN_TELEGRAM_APPROVAL_CHAT_ID не е зададено.

Регресия от червено към зелено защитава незабавната видимост в историята на сесията, еднозначното препращане към частен чат, приоритета на изрично зададена цел и отхвърлянето на нееднозначни получатели в двете доставени relay копия.

Ново в 9.1.521

Без дата

BLUN King 9.1.521 изпълнява AgentSpine SessionStart сканирането извън интерактивния път за стартиране. Студено сканиране на потребителската директория с продължителност 123,6 секунди по този начин не блокира нито редактора, нито първия потребителски вход.

Успешните SessionStart изходи остават автоматично: след завършване фоновият хук продължава да поема ограничения си брифинг в контекста на сесията.

Времевият бюджет за студените сканирания нараства на 180 секунди. Тест по време на изпълнение от червено към зелено доказва, че стартът се връща преди бавен хук и че хукът след това може да продължи да работи.

Ново в 9.1.520

Публикувано на

BLUN King 9.1.520 дава на AgentSpine SessionStart хука при презареждане достатъчно време, за да завърши студено пълно сканиране на проекта.

Времевата граница за старта на AgentSpine се увеличава от 15 на 60 секунди. Всички останали времеви граници на хуковете остават непроменени.

Нова проверка по време на изпълнение от червено към зелено стартира истинския AgentSpine хук във временен проект и проверява както неговия изход, така и двата доставени манифеста за изчакване.

Проверено състояние на пакета

Версия 9.1.520 съдържа AgentSpine 0.10.1. Изолираният тест на updater от 9.1.519 до 9.1.520 и пълната проверка преди пакетиране са зелени. SHA-256 на npm пакета: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Ново в 9.1.519

Публикувано на

BLUN King 9.1.519 съхранява успешните изходи на хука SessionStart, преди стартът или презареждането да се върне. Така готовността на AgentSpine достига продължения моделен контекст автоматично и вече не чака първото потребителско съобщение.

Историческите препратки към изнесени резултати от инструменти запазват ограничен преглед от началото и края. Важните котви за подновяване се запазват, без пълният резултат отново да влиза във всяка моделна заявка.

Нови проверки по време на изпълнение от червено към зелено защитават предаването на контекста на SessionStart и историческите прегледи. Възстановеният с 9.1.518 каталог с инструменти за поддръжката на Todo остава непроменен.

Ново в 9.1.518

Публикувано на

По време на проактивната поддръжка на списъка със задачи Read, Write, Edit и Bash остават налични до TodoList. Нормалният път за възстановяване на големи промени по файлове по този начин вече не се прекъсва.

Автоматичната поддръжка на Todo и нейният ограничен доказателствен промпт се запазват, без активната моделна стъпка да се превключва на каталог само с инструмента TodoList.

Регресионна врата от червено към зелено защитава от връщането на каталога от 9.1.499 и проверява избора на инструменти за възстановяване без дублирани схеми.

Ново в 9.1.517

Публикувано на

Strg+S и Escape остават налични дори при отворена заявка за одобрение. Strg+S изпраща всички чакащи съобщения; Escape освобождава първо едно чакащо съобщение и отхвърля одобрението едва когато опашката е празна.

Асинхронното завършване на сесията се наблюдава изцяло в клавиатурния път, в пътя на /reload на Telegram и в пътя на slash командите. session.not_found се счита за вече завършена сесия, вместо да срива ядрото чрез необработено отхвърляне.

Пакетни проверки от червено към зелено защитават необработените Windows контролни знаци и измерената грешка при завършване на вече несъществуваща сесия.

Ново в 9.1.516

Публикувано на

Ако в съхранената история след сгъстяването липсва началото на стъпка на асистента, възпроизвеждането го реконструира от следващото събитие със съдържание или инструмент. king -c по този начин вече не прекъсва с вътрешната грешка Received content_part for unknown step_uuid 'undefined'.

Едно Telegram съобщение напуска опашката точно веднъж, щом ядрото е приело постоянно неговото активно предаване. Истинските отхвърляния остават запазени за нов опит. Неочаквано спрял Telegram bridge, управляван от King, се рестартира от точно един обединен пазач.

За моделна стъпка се приема само първата промяна на TodoList. Изпълнените точки изчезват автоматично, чакащите маркировки остават видими и в ANSI16 терминали, а новият списък започва с точно една текуща точка. Фиксираният ред е: спешно, пряко потребителско съобщение, адресирано бот съобщение, бот съобщение, обикновено съобщение.

Първата стъпка с инструменти чака най-много 2,5 секунди за първоначалния MCP каталог; опционалните сървъри могат да продължат да стартират във фонов режим. При стартиране на програмата се проверява и инсталира само активният профил.

Проверено състояние на пакета

Версия 9.1.516 съдържа AgentSpine 0.10.1. Всичките осем регресионни врати преди пакетиране, node --check, проверката на метаданните на пакета и свежа проверка на пакета са зелени. Същият npm пакет съдържа платформените компоненти за Windows, Linux и macOS. SHA-256 на npm пакета: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Ново в 9.1.515

Публикувано на

Истински непроменен списък със задачи се приема отново след по-продължителна доказана работа. King не трябва да измисля напредък или просто да преформулира заглавие, за да продължи реалната си работа.

Дори loop в празен ход може отново да подеме все още отворена TodoList, без да държи агента трайно в обслужващ поток само с инструмента Todo. Регресионна врата преди пакетиране защитава и двата пътя на грешки.

Проверено състояние на пакета

Версия 9.1.515 съдържа AgentSpine 0.10.1. Целевата регресионна проверка на Todo loop, node --check, проверката на метаданните за изданието и свежа инсталация на пакета са зелени. Същият npm пакет съдържа платформените компоненти за Windows, Linux и macOS. SHA-256 на npm пакета: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Ново в 9.1.514

Публикувано на

BLUN King 9.1.514 укрепва свободния от съдържание журнал за доставка на Telegram срещу манипулирани пликове на опашката.

Идентификаторите на съобщения се приемат само като положителни десетични числа. Вече изчислените чат хешове са допустими единствено като точно дванадесетцифрени шестнадесетични стойности с малки букви. Грешно оформени, съдържателно подобни стойности се отхвърлят, вместо да се записват.

Съществуващата обработка на Telegram, фазите на доставка, ротацията на журнала и свободната от съдържание диагностика на карантината остават непроменени. Всичките 133 пакетни теста, както и свежи пакетни проби за Windows x64, Linux x64, macOS ARM64 и macOS x64 са зелени.

Проверено състояние на пакета

Версия 9.1.514 съдържа AgentSpine 0.10.1 и ReadBatch. SHA-256 на npm пакета: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Ново в 9.1.513

Публикувано на

BLUN King 9.1.513 записва пътя за доставка на Telegram от входа на bridge през маршрутизацията, включването в опашката и подаването до потвърждението, възстановяването или карантината.

Ограниченият журнал съхранява изключително свободни от съдържание идентификатори, хешове, фази на доставка, броячи и почистени причини за грешки. Текстове на съобщения, промпти, пътища, потребителски имена, токени, данни за достъп и необработени съобщения за грешки не се събират.

Диагностиката на карантината също вече не дублира Telegram съобщения, показвани текстове, данни за произход, необработени чат ID или пътища на изображения. Всичките 132 пакетни теста, както и свежи пакетни проби за Windows x64, Linux x64, macOS ARM64 и macOS x64 са зелени.

Проверено състояние на пакета

Версия 9.1.513 съдържа AgentSpine 0.10.1 и ReadBatch. SHA-256 на npm пакета: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Ново в 9.1.512

Публикувано на

BLUN King 9.1.512 изисква при проактивната поддръжка на TodoList променено, обосновано с доказателства обновяване, вместо да приема отново същия списък безкрайно. Изолираният обслужващ поток получава най-много осем компактни данни за име на инструмент и резултат от последното прието обновяване.

Промпти, аргументи, команди, пълни пътища, резултати от инструменти или работната история не се възпроизвеждат отново. Неуспешен опит на TodoList запазва този ограничен доказателствен материал за следващия опит; успешното обновяване премахва използваните данни. Изпълнените точки продължават да изчезват автоматично, а в следващата стъпка отново са налични нормалните работни инструменти.

Проверено състояние на пакета

9.1.512 издържа 127 от 127 пакетни теста. Свежите инсталации избират под Windows x64, Linux x64, macOS ARM64 и macOS x64 очакваните платформени компоненти и съдържат AgentSpine 0.10.1, както и ReadBatch. SHA-256 на npm пакета: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Ново в 9.1.511

Публикувано на

BLUN King 9.1.511 доставя AgentSpine 0.10.1 като нова, адресирана по съдържание основна версия на приставката. Задължителният preflight продължава да проверява всеки активен файл с инструкции на хоста защитено от race conditions и свързва неговата идентичност с точния ход, но вече не дублира заредения от хоста пълен текст в контекста на изпълнение.

Статусът допълва задължителни доказателства преди отговор, потвърдени записи Must-Remember и самовъзстановяваща се синхронизация на удостоверения граф на персона и връзки. Липсващи групи, лица и членства се поправят при ново сравнение на списъка; локалните заявки за връзки завършват при блокиране след пет секунди видимо.

Ограничената Telegram Mnemo заявка остава запазена: по-ранните съобщения се зареждат само при конкретна нужда с тесен контекст за агент, лице, група, тема, нишка и период. Пълната история на Telegram не попада рутинно в промпта.

Проверено състояние на пакета

9.1.511 издържа 126 от 126 пакетни теста. Истинският файл CLAUDE.md с размер 15 519 байта е проверен изцяло, докато целият инжектиран контекст е бил 5 667 байта и не е съдържал пълен текст на инструкции. Свежите инсталации избират под Windows x64, Linux x64, macOS ARM64 и macOS x64 очакваните платформени компоненти и съдържат AgentSpine 0.10.1, както и ReadBatch. SHA-256 на npm пакета: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Ново в 9.1.510

Публикувано на

BLUN King 9.1.510 добавя инструмента ReadBatch. Той чете два до дванадесет взаимно независими, вече известни UTF-8 файла или файлови диапазона в една моделна стъпка и запазва реда на заявките. Всеки път преминава през същите проверки за достъп, правила и разрешения като единично извикване на Read. Частичните успехи остават видими; само напълно неуспешен пакет се счита за обща грешка.

Проверено състояние на пакета

9.1.510 издържа 125 от 125 пакетни теста. Свежите инсталации избират под Windows x64, Linux x64, macOS ARM64 и macOS x64 очакваните платформени компоненти и съдържат ReadBatch. AgentSpine умишлено остана на 0.8.0, докато независимо откритият блокер на контекстния бюджет на по-новия предварителен статус не беше отстранен без увеличен промпт на изпълнение. SHA-256 на npm пакета: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Ново в 9.1.509

Публикувано на

BLUN King 9.1.509 изисква при всяко одобрено Telegram работно съобщение между ботове изрично споменаване на предназначения King. Бот съобщения без подходящо споменаване остават видими, но не се буферират, не се включват в опашката, не се доставят и не попадат по-късно в моделния контекст на този King. Така приоритетно бот съобщение за един King вече не може да стане задача на друг King.

Проверено състояние на пакета

Всичките 121 пакетни теста са зелени. Същият пакет съдържа проверените платформени компоненти за Windows x64, Linux x64, macOS ARM64 и macOS x64. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Ново в 9.1.508

Публикувано на

Отворените Todo точки отново имат видимо квадратче. Дори първият обикновен списък със задачи започва с точно една текуща точка; по-късните стъпки остават чакащи, докато реалното им начало не бъде доказано.

Приетите преки и групови Telegram съобщения се предават на Mnemo асинхронно, постоянно буферирани и точно дедуплицирани. Временно недостъпен хъб не блокира нито доставката на Telegram, нито изпълнението на King. /loop команди и вътрешните loop тикове умишлено не се записват.

AgentSpine не зарежда пълната история на Telegram в контекста на изпълнение. Ако задача изисква по-ранно съобщение, се извършва ограничена Mnemo заявка по агент, лице, група, тема, нишка и период.

Проверено състояние на пакета

Всичките 120 пакетни теста са зелени. Свежите инсталации избират под Windows, Linux x64, macOS ARM64 и macOS x64 съответния правилен нативен компонент за клипборд и съдържат управляваната Telegram Mnemo връзка, както и AgentSpine. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Ново в 9.1.507

Публикувано на

BLUN King 9.1.507 изрично инструктира модела в инструмента Read да групира взаимно независими четения на файлове и диапазони в един моделен отговор, когато няколко входа могат да са полезни.

Това намалява излишните моделни кръгове при големи работни контексти, без да променя изпълнението, навигацията по страници, разрешенията или обработката на резултатите на Read.

Проверено състояние на пакета

Целеви регресионен тест защитава промяната; всичките 112 пакетни теста са зелени.

Ново в 9.1.506

Публикувано на

Изпълнените TodoList точки се премахват незабавно от видимия TUI. Постоянният списък със задачи вече е отхвърлил коректно тези записи; сега интерфейсът показва същия почистен статус, докато текущата и чакащата работа се запазват изцяло.

Автоматичният обслужващ поток използва самостоятелен системен промпт с 546 знака. Преди това за него, въпреки единствения наличен Todo инструмент, се добавяше пълният работен промпт с около 19 000 знака. Следващата работна стъпка продължава да получава пълния промпт и нормалния си каталог с инструменти.

Измерена полза за контекста и статус на пакета

Реално изпълнение показа за всяка осма работна стъпка отделен Todo обслужващ поток с 15 221 входни токена. Статичният обслужващ промпт намалява с 18 470 знака; реалното спестяване на време се измерва отново след обновяването на флота. Публикуваният tarball издържа 111 от 111 теста. Свежи пакетни инсталации под Windows с Node 24.19.0 и Linux с Node 24.18.0 потвърждават версия 9.1.506; macOS двоичните файлове за ARM64 и x64 са включени в идентичния npm пакет. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Ново в 9.1.505

Публикувано на

Telegram съобщение, което пристига след поемането на канала, но преди завършването на активирането на опашката, вече не се прескача като стар остатък. Без валиден чекпойнт обработката започва от измерената граница в байтове при старта на поемането, вместо от по-късния край на файла.

Валиден постоянен чекпойнт запазва приоритета си. Ако файлът на опашката бъде заменен по време на предаването, новият файл започва безопасно от нулевия байт; вече съществуващите преди поемането исторически съобщения не се възпроизвеждат отново.

Измерен регрес и статус на пакета

Груповото съобщение 63456 пристигна една секунда след поемането на канала, чекпойнтът скочи точно до неговия край и съобщението не се появи в нито един моделен контекст. Тази реална загуба е защитена като регресия. Публикуваният tarball издържа 111 от 111 теста; свежи пакетни инсталации под Windows с Node 24.19.0 и Linux с Node 24.18.0, както и реално обновяване от 9.1.504 потвърждават версия 9.1.505. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Ново в 9.1.504

Публикувано на

Telegram съобщение, което при празно изпълнение на агента вече е в опашката, вече се стартира през нормалния път на канала като свеж моделен ход. То не чака повече активен ход, който в празен ход по дефиниция не може да възникне.

Съществуващото предаване в текущ ход остава непроменено. Също така остават защитени изолираната Todo поддръжка, автоматичното премахване на изпълнените точки и последващото възстановяване на нормалните инструменти за файлове, търсене и shell.

Проверено състояние на пакета

Публикуваният tarball издържа 106 от 106 теста. Новата регресия в празен ход беше червена преди намесата и след това е зелена заедно с 24 теста на опашката. Свежи пакетни инсталации под Windows с Node 24.19.0 и Linux с Node 24.18.0 потвърждават версия 9.1.504 и същия SHA-256 df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Ново в 9.1.503

Публикувано на

Изолираното Todo обслужващо съобщение носи вече и изрично празно поле toolCalls. Така то изпълнява същата форма на съобщение като редовните работни ходове и може да се обработи безопасно от нормализацията на BLUN provider.

Истинската грешка по време на изпълнение TypeError: message.toolCalls is not iterable по този начин вече не възниква преди извикването на TodoList. Регресионен тест итерира генерираното съобщение точно като provider границата, преди поддръжката да бъде освободена.

Проверено състояние на пакета

Публикуваният tarball издържа 105 от 105 теста. Свежи пакетни проби под Windows с Node 24.19.0 и Linux с Node 24.15.0 потвърждават пълната форма на provider съобщението, изолираната Todo поддръжка и автоматичното премахване на изпълнените точки. Реалната флотска приемка протича след контролираното рестартиране на трите King.

Ново в 9.1.502

Публикувано на

Дължимата TodoList обслужваща стъпка получава вече само свежо съобщение, ограничено до текущата задача и видимия списък. Стари Read, Bash или MCP извиквания от работната история по този начин вече не могат да попаднат в умишлено ограничената до TodoList стъпка.

Изпълнените задачи изчезват автоматично при запазване от видимия и постоянния списък. Текущите, чакащите, блокираните, чакащите разрешение и отменените точки остават запазени; списъкът по този начин не расте неограничено от завършена работа.

Измерен резултат във флота

Два профила на агенти срещнаха независимо един и същ регрес: след успешно използване на инструмент Todo поддръжката повтори исторически фактически инструменти и показа Tool not found. Публикуваният tarball издържа 105 от 105 теста. Свежи инсталации под Windows с Node 24.19.0 и Linux с Node 24.15.0 потвърждават изолираната поддръжка, премахването на изпълнените точки и завръщането на нормалните инструменти. Реална приемка под macOS не е част от това доказателство.

Ново в 9.1.501

Публикувано на

След успешна TodoList обслужваща стъпка в непосредствено следващата работна стъпка отново са налични всички избрани за хода инструменти. Read, Bash и другите фактически инструменти вече не остават скрити зад временно ограничения Todo каталог.

Поправен регрес

Todo стъпката предлагаше умишлено само TodoList. Нейният избор на инструменти обаче оставаше активен без изрично възстановяване и в следващата стъпка. 9.1.501 поставя отново нормалния каталог там и защитава и двата пътя на следващите стъпки с регресия.

Golden Release 9.1.500

Публикувано на

Тази версия обединява пълния функционален статус на 9.1.499 непроменен като обща npm публикация за Windows, Linux и macOS. Златното обозначение е умишлено ограничено до заглавията на тази версия; по-старите записи запазват досегашното си представяне.

Статус на изданието

Golden Release поема проверените промени на Todo, опашката, loop, контекста, AgentSpine и оценката на изображения от 9.1.499 без допълнителна логика на изпълнение.

Ново в 9.1.499

Публикувано на

Данните за изображения, аудио и видео извън последните дванадесет съобщения на разговора се заменят в повторената моделна проекция само с кратки препратки. Актуалните медии, текстът на съобщението и пълната необработена история на сесията остават непроменени.

В измерен чекпойнт за подновяване тази проекция спестява 85 748 знака, съответно около 21 437 оценени входни токена за всяка следваща стъпка с инструмент.

Дължимата Todo поддръжка протича преди деветия работен блок като самостоятелна моделна стъпка с ниски усилия. В тази стъпка средата предлага изключително TodoList; файловите, търсещите, shell и другите фактически инструменти се освобождават отново едва след валидно обновяване.

Свежите потребителски съобщения запазват приоритета си пред Todo поддръжката. Твърдата Todo врата остава като предпазна мрежа за действително невалидни обновявания, но вече не се появява като нормална червена междинна грешка преди самостоятелна поддръжка на списъка.

Проверено доказателство

Публикуваният tarball издържа 105 от 105 теста за изпълнение и регресия. Свежи изолирани инсталации под Windows с Node 24.19.0 и Linux с Node 24.15.0 съобщават точно версия 9.1.499 и потвърждават медийната проекция, непроменената необработена история, предварителната поддръжка на Todo и скриването на всички фактически инструменти по време на Todo стъпката. Кандидатът обхваща 850 пътя и носи SHA-256 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Реална приемка под macOS не е част от това доказателство.

Ново в 9.1.498

Публикувано на

/usage показва отчетеното от доставчика съотношение на попаденията на промпт кеша, както и прочетените и записаните cache токени за модел. Без отчетена cache активност индикацията не измисля съотношение.

/tokens е кратък псевдоним за съществуващата подробна диагностика на контекста; /offload извиква съществуващото архивиращо сгъстяване. И двата пътя не предизвикват допълнително моделно извикване.

Различни авторизирани бот съобщения вече не се отхвърлят от твърд прозорец от 15 секунди. Съществуващият ред остава запазен: частните и изрично адресираните съобщения стоят пред бот съобщенията, бот съобщенията пред нормалния контекст.

Пълното сгъстяване поема точния Todo списък в новия контекст. Ако след това път, команда, хеш или изискване са несигурни, еднократна бележка за възстановяване изисква първо четене на архивираната история вместо широко търсене във файлове или ново начало.

Изпълнените Todo стъпки остават като доказателство. Ако по-късни открития наложат отново стъпка, доказаното завършване остава и новата проверка се появява като отделна текуща стъпка с обосновка.

Повтарящите се loop на сесията чакат, докато поддържаният Todo списък все още съдържа текуща или чакаща работа. Пропуснатите интервали се обединяват до истински празен ход; други планирани напомняния не се засягат.

Проверено доказателство

Подготвеният tarball издържа 100 от 100 теста за изпълнение и регресия. Свежи изолирани инсталации под Windows с Node 24.19.0 и Linux с Node 24.15.0 съобщават точно версия 9.1.498 и потвърждават показването на cache, псевдонимите на команди, възстановяването след сгъстяване, монотонните Todo доказателства, защитата на loop на сесията, дневника на пакета и приоритета на бот съобщенията. Кандидатът обхваща 849 пътя и носи SHA-256 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Реална приемка под macOS не е част от това доказателство.

Ново в 9.1.497

Публикувано на

Telegram бот съобщенията от общи групи стоят зад частните и изрично адресираните съобщения, но пред нормалния контекст. Приоритизацията не изисква отговор.

Прието Telegram съобщение изчезва от видимата опашка, щом започне неговата възпроизведена моделна стъпка. Отхвърлена доставка или прекъсване преди първата стъпка продължава да го запазва за нов опит.

Дължим Telegram отговор или обработка на съобщение вече не се блокира от Todo поддръжката. Следващата нормална работна стъпка остава блокирана до истинното обновяване на Todo списъка.

Версии 9.1.496 до 9.1.487

ВерсияПромени
9.1.496Доставя потребителските Telegram съобщения автоматично поотделно, премахва само точно приетата или отговорената ID на съобщение, изисква истинен напредък за всеки видим Todo списък и скрива успешните вътрешни hook полезни данни.
9.1.495Стартира всяка нова или заменена цел със свеж видим Todo списък, изисква истинни обновявания, премахва незабавно успешно отговорения Telegram групов фокус, отлага нормалните разписки за входа до края на хода и добавя истинни проверки за декодиране на Ctrl+S и Ctrl+T.
9.1.494Разделя отново еднозначно клавишните комбинации: Ctrl+S управлява само остатъка на опашката, Ctrl+T само Todo списъка. Потребителските Telegram съобщения се авторизират при текуща работа за следващото безопасно предаване.
9.1.493Потребителските Telegram съобщения се освобождават автоматично по време на активна работа за следващото безопасно предаване. Преките съобщения остават напред в опашката, без да спират постоянно груповите съобщения.
9.1.492Вече освободени групови съобщения остават запазени при временно заета доставка и се опитват отново. Пакетът, npm метаданните, публичният манифест и дневникът се проверяват заедно преди съобщение за успех.
9.1.491Преките Telegram съобщения се приоритизират незабавно при текуща работа. Ръчното управление на опашката остава налично за други съобщения.
9.1.490Историята на пакета документира изцяло непубликувания статус 9.1.487 и действително публикуваните поправки от 9.1.488 нататък.
9.1.489Списъкът със задачи, управлението на опашката, идентичността на изпълнение в Telegram, инсталацията на профила на AgentSpine и управляваната оценка на изображения бяха възстановени и защитени с регресионни тестове.
9.1.488Подготвеният основен AgentSpine плъгин беше публикуван. Telegram дубликатите вече не оставят привиден ход; дълбочината на мислене и безопасната обработка на телеметрията остават запазени през стъпките с инструменти.
9.1.487Непубликувано. Този статус подготви AgentSpine като управляван основен плъгин. На npm след 9.1.486 последва директно 9.1.488.

Ново в 9.1.486

Публикувано на

Новите и обновените профили стартират вече надеждно на английски под Windows, macOS и Linux. Запазена автоматична езикова стойност се мигрира веднъж, докато изрично избраните езици остават непроменени.

Автоматичните обновявания при старт са отново активирани по подразбиране през съществуващия свързан с версията инсталатор. [upgrade].auto_install = false запазва заявката за потвърждение; фонов обновяващ инструмент не се въвежда отново.

Диалозите при старт, напредъкът, грешките, съобщенията за успех и продължаването на сесията използват вече същия език. Регресионните и мутационните тестове защитават миграцията, пътя за обновяване и данните на сесията.

Проверено доказателство

Пълният тестов пакет издържа с 1 474 от 1 474 проверки. Изолиран тест за обновяване инсталира 9.1.486 от 9.1.485, запази конфигурацията и сесията непроменени и стартира новата CLI. Отделна стартова проба доказа автоматичната инсталация без допълнителна заявка, както и еднократната миграция на стара автоматична езикова стойност към английски.

Версии 9.1.485 до 9.1.178

ВерсияПромени
9.1.485
  • Ограничава първото видимо възпроизвеждане на продължена сесия без индекс на scrollback до активните 15 разговорни хода, вместо да представя отново целия разговор.
  • Изчиства видимата област за обновяване след успешна актуализация, преди да стартира новата конзола; нормалният превъртаем буфер на терминала се запазва.
  • Допълва регресионни и мутационни проверки за резервния вариант при възпроизвеждане, включително симулация с 97 596 записа.
9.1.484
  • Разпознаването на плъгини приема допълнително .codex-plugin/plugin.json и разрешава PLUGIN_ROOT, съответно BLUN_PLUGIN_ROOT, в командата, аргументите и работната директория.
9.1.483
  • Моделът за сгъстяване може да се избира, записва и връща към наследяване отделно от активния модел; изборът и обратната връзка са налични в командата за празен ход и в локализираните настройки.
9.1.482
  • Изнесените резултати от Read запазват следващия line_offset и продължават първоначалното четене оттам, вместо да четат същия файл отново от началото.
9.1.481
  • Отговорите на подагенти, които завършват на токен лимита без извикване на инструмент, се разпознават като max_tokens за съществуващото продължение. Glob моделите с .. и именувани home пътища като ~name се отхвърлят.
9.1.480
  • Актуализира доставения translate-native skill и MCP на Language Guard до версия 6.42.13.
  • Свързва доставените файлове на езиковата защита побайтово с изходния комит 6430ce30e235c1a9d1ebcd1b646d62edce510605.
  • Допълва проверки за произход и мутации, така че променени защитни байтове или отклоняваща се версия на skill да провалят проверката преди публикуване.
9.1.479
  • Добавя към частната King услуга на Agent API удостоверен вътрешен маршрут за проверка на наличността.
  • Проверява наличността на услугата, без да създава клиентска сесия или да стартира изпълнение на агента.
  • Ограничава маршрута до loopback интерфейса и GET, защитава го с тайна и предотвратява кеширането му.
9.1.478
  • Отстранява обичайните паузи на прекия Telegram фокус след рестарт, дори когато по-старите чекпойнти не съдържат срок за отговор.
  • Запазва изрично поисканите от потребителя паузи до одобрението, вместо да ги оставя да изтекат автоматично.
  • Освобождава включените в опашката канални съобщения за активно изпълнение, щом прекият фокус приключи.
9.1.477
  • Добавя към частната услуга на Agent API изрична обвивка на процеса, стартирана от оператора.
  • Обработва SIGINT и SIGTERM точно веднъж, дори когато сигналите пристигнат по време на стартирането.
  • Прекъсва безопасно с ограничени съобщения, не извиква process.exit и никога не стартира услугата автоматично.
9.1.476
  • Добавя към частната услуга на Agent API договор за средата по принципа на сигурната ключалка.
  • Изисква изрично определен loopback порт, тайни за изолация, настройки на доставчика и граници на ресурсите.
  • Оставя частната услуга спряна и автоматичното почистване на неактивни сесии деактивирано, докато и двете не бъдат изрично конфигурирани.
9.1.475
  • Освобождава само съответно конфигурирани и действително неактивни сесии на Agent API, преди клиент да достигне лимита за сесии.
  • Защитава активните моделни и инструментални изпълнения независимо от тяхната възраст и актуализира периода на неактивност при реална употреба.
  • Оставя автоматичното почистване деактивирано, докато оператор изрично не конфигурира време за изчакване на неактивност.
9.1.474
  • Прекратява активното присвояване на сесия, когато продължаването на агент след резултат от инструмент се провали.
  • Позволява след това изрично затваряне на засегнатата сесия.
  • Оставя успешните връщания на инструменти и публичния моделен договор непроменени.
9.1.473
  • Защитава сесия на Agent API от затваряне, докато нейното първо моделно извикване все още работи.
  • Освобождава надеждно сесията след успешен отговор или моделна грешка.
  • Оставя съществуващия път за необработени модели и публичния моделен договор непроменени.
9.1.472
  • Позволява на клиентите изрично да затворят неактивна сесия на Agent API и да освободят ограниченото си място за сесии.
  • Предотвратява затварянето на активни сесии и ограничава всяко затваряне до съответния клиент собственик.
  • Предоставя освободеното място за нова сесия, без да променя публичния моделен договор.
9.1.471
  • Добавя затворен хост на услугата, който сглобява частния стек на Agent API, без да го стартира автоматично.
  • Изисква отделни тайни за транспорта и изолацията, абсолютна главна директория на клиента и изрична конфигурация на средата за изпълнение на King.
  • Свързва слушателите към loopback интерфейса и при спиране затваря всяка клиентска сесия и всяка среда за изпълнение.
9.1.470
  • Изолира безглавите сесии на Agent API по доверен клиент и публична сесия.
  • Обединява едновременните първи достъпи в една SDK сесия и ограничава активните клиенти и сесии.
  • Използва свързани с ключ непрозрачни вътрешни идентификатори и работни директории, докато стабилните публични идентификатори на сесии остават запазени.
9.1.469
  • Добавя към адаптера на Agent API частен HTTP транспорт, достъпен изключително през loopback интерфейса.
  • Изисква тайна на услугата и зададена от сървъра клиентска идентичност; фалшивите данни за идентичност в тялото на заявката се игнорират.
  • Отхвърля прекалено големи или грешни заявки и държи вътрешните данни на доставчика извън публичните съобщения за грешки.
9.1.468
  • Държи главния агент отзивчив, докато подагентите работят във фонов режим и вложените подагенти продължават работата.
  • Позволява на ограничените сесии на Agent API да използват жизнения цикъл на подагентите, без да разкриват локални shell или файлови инструменти.
  • Предава точната граница на инструментите на всяко ниво на вложени подагенти, така че ограниченията не могат да бъдат заобиколени чрез делегиране.
9.1.467
  • Добавя изричен транспортен адаптер за изпълнения на агенти, без да прихваща съществуващите маршрути за необработени модели или списъци с модели.
  • Свързва резултатите от инструменти и целевите прекъсвания със същия клиентски, сесиен и заявков обхват.
  • Показва изключително King, почиства неочакваните вътрешни грешки и отхвърля стрийминга, докато за него не съществува агентски договор.
9.1.466
  • Записва всяко завършено моделно извикване на Agent API под стабилен идентификатор на задача, без да обединява използването на различни клиенти.
  • Постоянно JSONL съответствие държи заявката, сесията, задачата, идентификатора на извикването и необработените полета за използване откриваеми дори след рестарт.
  • Навън се появяват само King и необработените броячи за вход, кеширан вход и завършване; липсващите данни за използване остават изрично отбелязани.
9.1.465
  • Добавя изолирано управление на изпълнението за изричната агентска крайна точка на Agent API, без да променя необработените моделни завършвания.
  • Управляваните от клиента извиквания на инструменти запазват едно единствено King изпълнение през връщанията на резултати и остават ограничени до първоначалната заявка.
  • Отговорите на главните агенти изключват потоците от събития на дъщерните агенти и отхвърлените чернови на повторни опити.
9.1.464
  • Управляваните подагенти вече работят разкачени, така че главният агент остава отзивчив, докато делегираната работа продължава.
  • Текущите подагенти могат да се управляват с TaskUpdate или да се прекратят с TaskStop, без да се затваря главната сесия.
  • Адресираните Telegram групови съобщения остават във фокуса, докато агентът не отговори в съответния чат.
9.1.463
  • Подновяването от чекпойнт изобразява при налични данни за прозореца само последната активна TUI група ходове; по-старите редове остават в архив за превъртане и се зареждат при нужда.
9.1.462
  • Непромененото съдържание на tui.toml вече не предизвиква атомарна замяна на файла; истинските промени продължават да използват съществуващия заключен път за запис.
9.1.461
  • /status разграничава зареденото състояние на изпълнението от инсталирания пакет и съобщава отклонението и в дистанционния Telegram статус.
9.1.460
  • По-старите видими сесийни съобщения остават в постоянен архив на диска и се зареждат на блокове при превъртане нагоре, без при старт да се четат всички текстови блокове.
9.1.459
  • Подновяването възстановява свързан с целостта семантичен чекпойнт и чете само частта на непроменения сесиен файл, добавена след него; при невалиден чекпойнт пълното възпроизвеждане остава като резервен вариант.
9.1.458
  • Контролна сума, възприета от външен отчет, се свързва само ако точно тази стойност присъства в избраното изходно събитие.
9.1.457
  • Когато една и съща контролна сума произхожда от няколко външни събития, произходът се посочва като нееднозначен, вместо да се приписва на един отчет.
9.1.456
  • Контролните суми в изходящите Telegram съобщения се съпоставят с локалните резултати от инструменти и видимите външни отчети; несъответстващите стойности създават бележка за произход.
9.1.455
  • Telegram отчетите могат да се свързват чрез идентификатора на чата и съобщението като credible_unverified; репортера и произхода на събитието задава средата за изпълнение.
9.1.454
  • Свежите проверки се свързват автоматично със сесията и агента, които ги създават; препратените измервания остават външни отчети.
9.1.453
  • Доказателството за завършване се свързва с актуално валидния критерий за завършване и се отхвърля при друг или остарял критерий.
9.1.452
  • Всяко доказателство се свързва с действително измерения целеви обхват; командните проверки трябва да водят същата сигурна стойност на BLUN_EVIDENCE_SCOPE от двете страни.
9.1.451
  • Всяко доказателство носи точния вид inspection, integrity, syntax, test или reachability. По-слаба проверка не може да се представя като по-силна.
9.1.450
  • Доказателствата за резултати и доказателствата за проверки се разделят. Само нов или променен проверяващ има нужда от второ, самостоятелно доказателство за строгост; нормалните измервания не изискват червена проба.
9.1.449
  • Доказателството за завършване посочва точното успешно извикване на проверка чрез неговата toolCallId; смесено командно извикване с промяна и проверка не е достатъчно.
9.1.448
  • Целево завършване трябва да свърже провереното твърдение с успешно извикване на проверка от същия ход; чистите инструменти за писане или промяна не се считат за доказателство.
9.1.447
  • Избрано действие се свързва с постоянни доказателства за решения; неизвестни или остарели доказателства налагат ново планиране.
9.1.446
  • Живата защита срещу повторение разпознава допълнително кратки повтарящи се словосъчетания от две до осем думи.
9.1.445
  • Избраните бележки за учене се записват заедно с валидирания резултат от ученето на текущия ход като следа за експозиция, без да се твърди причинно-следствена връзка.
9.1.444
  • Търсенето на релевантност по по-ранни грешки използва постоянни данни за цели, чекпойнти и рамката на проблема, вместо само най-скорошните потребителски съобщения.
9.1.443
  • При непосредствено продължаване на цел изричният избор tool: или skill: зарежда точно избраното помощно средство.
9.1.442
  • Работният фокус запазва нишката на решенията от статус, фаза, последна проверка, избор, обосновка, подкрепа, риск и обратимост.
9.1.441
  • Липсващото знание се води като отделна knowledge_gap област вместо в общия целеви текст, приоритизира се и се скрива при празна стойност.
9.1.440
  • Световното знание и допусканията могат да се включат като отделни области в постоянния фокус и да се претеглят.
9.1.439
  • Постоянният когнитивен фокус получава оценка за забележимост с намаляване между сесиите и усилване при повторен достъп.
9.1.438
  • По време на възпроизвеждането на сесията подрязването, сливането и рендирането се отлагат; след това се изисква точно едно ново рендиране на транскрипта.
9.1.437
  • Пазачът на празния ход използва отново подходящия текстов път за изчакванията и вече не прекратява процеса чрез неразрешен параметър в таймера.
9.1.436
  • Дистанционният Telegram статус показва при активен ход началото, последния напредък, последния инструмент и повторените грешки; TUI публикува за целта текущи моментни снимки на активността.
9.1.435
  • Частните чекпойнти на Telegram фокуса вече следват работното пространство, свързано с активната сесия.
  • Изборът на работното пространство вече не съхранява началната директория като място за продължаване на преките разговори.
9.1.434
  • Потвърденото учене вече следва работното пространство, свързано с активната сесия на агента.
  • Сесиите с няколко работни пространства и продължените сесии вече не съхраняват и не показват проектни поуки в директорията на главния процес.
9.1.433
  • Подготовката на вход във външния редактор остава вече в рамките на границата за почистване на временните директории.
  • Ако първият запис се провали, например заради пълен диск или липсващи разрешения, временната директория на редактора се премахва, преди грешката да бъде предадена.
9.1.432
  • Временните грешки в стрийминга вече могат да се опитат отново със същия избран модел дори след видим частичен изход.
  • Незавършеният текст на асистента и незавършените повърхности на инструментите се завършват или отхвърлят преди повторението, така че новият изход да не се закача за неуспешния опит.
  • След видим изход смяната на доставчика остава блокирана, така че отговорът не може да смени доставчика насред стрийма.
9.1.431
  • Локалните процеси на инструмента Bash вече принудително деактивират Git запитванията в терминала, вместо да наследяват интерактивна настройка на главния процес.
  • Наследените askpass диалози на Git, SSH и Git Credential Manager са деактивирани в дъщерния процес на инструмента; по този начин се предотвратяват невидими изчаквания за Windows данни за влизане.
  • Главната обвивка и средата на текущата сесия остават непроменени; съществуващото поведение при затворен стандартен вход се запазва и се обезопасява независимо.
9.1.430
  • Пълното сгъстяване вече може да използва опционално конфигуриран моделен псевдоним чрез [loop_control].compaction_model; активният King модел остава настройката по подразбиране.
  • Удостоверяването, подготовката на контекста, бюджетът за завършване, ученето при преливане и отчитането на използването на сгъстяването са изцяло свързани с избрания модел за сгъстяване.
  • Активният модел продължава да определя началото на сгъстяването и последната спирачка на заявката, така че по-малък обобщаващ модел не може незабелязано да смали централния прозорец за мислене.
9.1.429
  • Bash под Windows вече отхвърля еднозначния cmd.exe синтаксис преди стартирането на процеса, вместо да губи видимо неуспешно изпълнение.
  • Описанието на инструмента Bash пояснява изрично, че POSIX Bash под Windows, включително в VS Code, остава активен, и посочва правилните конвенции за пътища и пренасочвания.
  • Валидните POSIX find команди остават разрешени; за умишлено желана cmd семантика продължава да е налично изрично предаване на cmd.exe /c.
9.1.428
  • Генерираните JavaScript и TypeScript записи спират вече преди достъпа до диска, когато изпълнима инструкция се повтори осем пъти подред; по този начин се предотвратяват излезлите от контрол изходи на аналитични скриптове.
  • Защитната проверка обхваща както Write извикванията за цели файлове, така и Edit замените, докато некодовите файлове, коментарите, низовете и по-кратките допустими повторения остават непроменени.
  • И трите наблюдавани случая на израждане с 15, 23 и 31 повторени инструкции се блокират; произволни непълни, но не повтарящи се намерения остават извън тази механична проверка.
9.1.427
  • Видимата команда /memory core съобщава вече активната граница на адаптера за памет, версията на договора, режима на идентичност, статуса на цялост и доказателствата през порталите, опционално като --json изход.
  • Профилно обвързаната резервна памет и произтичащите от профили идентичности се изключват изрично от готовността за общо ядро, вместо да се представят като портално неутрална памет.
  • Конфигурираните доставчици остават видимо непотвърдени, докато не са налице отделни доказателства; диагностиката е само за четене, не дава правомощия и никога не измисля доказателства през порталите.
9.1.426
  • Видимата команда /memory acceptance изпълнява вече синтетична временна V7 проверка на паметта през CLI, Telegram и Web и може опционално да изведе --json отчет.
  • Десет независими проверки покриват произхода на портала, свързаните и несвързаните идентичности, изолацията на агенти и групи, дедупликацията, глобалната корекция и изтриването, сигурната ключалка на доставчика и защитените изходни байтове.
  • Докладът за приемане служи изключително като детерминистично доказателство: той не дава правомощия и никога не чете или променя реален потребителски профил.
9.1.425
  • Подагентите, които достигнат токен лимита си, получават вече в същия агентски контекст кратко предаване без инструменти, вместо да губят завършена работа с инструменти.
  • Ако и това предаване достигне лимита, главният агент получава ограничено частично обобщение, както и точната инструкция за продължаване от същия агент.
  • Възстановяването остава проектирано по принципа на сигурната ключалка: без пълен нов опит на задачата, без съобщение за готовност без завършващо предаване и без нови правомощия.
9.1.424
  • Потвърдените поуки от Mistake.md се пренасят вече върху различно формулирани, но семантично подобни случаи от надеждността, доставката, оркестрацията, паметта, публикуването, медиите и валидирането.
  • Точните термини за доказателства продължават да имат предимство пред широките семантични категории; несвързан текст остава без съответствие.
  • Естествените немски формулировки се уеднаквяват детерминистично; промененият ред не създава нови разрешения и не повишава непотвърдена поука.
9.1.423
  • Завършванията на средата за изпълнение записват вече постоянен синхронен диагностичен запис, преди ядрото или стартерът да се върнат или да приключат.
  • Неприхванатите изключения, необработените отхвърляния, падналите терминали, сигналите, грешките при старт, нормалните завършвания, грешките на дъщерни процеси и техните завършвания запазват точната почистена причина заедно с границата на процеса.
  • Частният протокол е ограничен и устойчив на грешки, премахва тайните и home пътищата и не рестартира или зарежда отново текуща сесия.
9.1.422
  • Отворена неактивна сесия наблюдава вече запазения си времеви тригер и се активира в автоматичен режим или God Mode при или след dueAt.
  • Тригер с настъпил срок изчаква, докато активните отговори, сгъстяването, включените в опашката съобщения, командите и диалозите приключат, преди да продължи точно веднъж.
  • Преди старта средата за изпълнение чете отново целта, ревизията на чекпойнта, падежа, режима на разрешения и сесията и отхвърля таймерите по всеки път на завършване на сесията.
9.1.421
  • Времевите чекпойнти за изчакване съхраняват вече точен dueAt времеви печат и го уеднаквяват на UTC.
  • Редовен старт на сесия в автоматичен режим или God Mode оставя бъдещите времеви тригери да чакат и ги продължава при или след техния падеж.
  • Първото продължено изпълнение получава точното наблюдение на падежа; непрекъснато отворените сесии не получават в тази версия все още таймер на изпълнението.
9.1.420
  • Активна цел с постоянен чекпойнт за изчакване предава контрола след текущото изпълнение, вместо да възлага допълнително автономно изпълнение.
  • Външните, времевите, свързаните със зависимости и зависимите от потребителски решения тригери остават запазени и се оценяват отново при пристигането на следващото събитие.
  • Непосредствените цели и по-старите активни цели без чекпойнт се продължават непроменено.
9.1.419
  • Редовно продължена сесия сега продължава работата по вече активна цел, когато нейният запазен следващ тригер е изрично непосредствен и автоматичният режим или God Mode е активен.
  • Продължаването остава вътрешно, протича най-много веднъж за продължена сесия и никога не се появява като измислено потребителско съобщение.
  • Чакащите, поставените на пауза и блокираните цели, липсващите чекпойнти и ръчните режими на разрешения остават спрени.
9.1.418
  • Telegram запазва вече изричната бот маркировка на подателя във входните данни, така че контекстът на идентичността може да различава агентите от хората.
  • Вече запазените като хора Telegram участници се коригират на агенти само когато доставчикът, субектът и изричната бот маркировка съвпадат.
  • Данните за участниците остават запазени, агентите никога не се понижават и имената или потребителските имена никога не се използват за извеждане на агентска идентичност.
9.1.417
  • Автоматичните Telegram заместващи отговори разделят вече отговорите с повече от 4 096 знака на последователни съобщения, вместо да ги съкращават.
  • Всеки знак и всяка Unicode сурогатна двойка се запазват; изходът събира всички върнати идентификатори на съобщения заедно с пълния текст.
  • Ако част се провали, доставката спира на това място, вместо да съобщава непълен отговор като завършен.
9.1.416
  • Свежите резултати от последния стек от извиквания на инструменти остават напълно четими до следващия отговор на асистента, дори ако след това се впръска Telegram или контролен контекст.
  • Изнасянето на стекове, почистването на историята и микро-сгъстяването използват вече същата семантична граница за свежите резултати.
  • Вече оценените по-стари резултати продължават да се сгъстяват нормално, така че досегашните икономии на контекст се запазват.
9.1.415
  • Постоянният работен фокус запазва точния тригер за следващото действие вече през рестартите и смените на контекста.
  • Следващото действие остава отделено от своето условие за одобрение; това важи и за валидни условия с повече от 512 знака.
  • Грешните или неподходящите за фазата тригери се отхвърлят сигурно; по-старите чекпойнти запазват досегашното си поведение.
9.1.414
  • Новите постоянни чекпойнти за действия улавят точния тригер, който освобождава следващото действие.
  • Фазите, които не чакат, изискват непосредствен тригер; чакащите фази изискват именувано външно събитие, момент от време, зависимост или потребителско решение.
  • Чакащите цели остават активни, без да се изпълняват преждевременно; по-старите чекпойнти остават четими.
9.1.413
  • Telegram отговорите, които достигнат изходния лимит на модела, вече не се доставят като непълни начала.
  • Същата текуща сесия създава кратко, пълно продължение и предприема най-много три опита за възстановяване, преди да прекъсне безопасно.
  • Изричен отговор през инструмента за Telegram продължава да има предимство и потиска възстановяването, така че успешните изпращания никога не се дублират.
9.1.412
  • Създадените от модела постоянни цели започват вече атомно с ревизия 1 и пълна ограничена рамка на проблема.
  • God Mode и автоматичният режим продължават вече оторизиран старт на цел без второ потвърждение; в ръчния режим одобрението остава задължително.
  • Удостоверена, нетривиална многостъпкова работа може да премине в постоянния режим на цел при съществуваща автономна инструкция; поздравите, едностъпковите заявки и неясните задачи остават изключени.
9.1.411
  • Нетривиалните и непознатите задачи могат вече да съхраняват ограничена рамка на проблема в постоянния чекпойнт на действието.
  • Рамката обхваща критериите за успех, липсващото знание, до пет възможни действия, избраното действие с обосновка, избора на подкрепа, риска и резервния път.
  • Рамката на проблема преживява продължаването и рестарта изключително като описателно състояние и никога не може да предоставя разрешения.
9.1.410
  • Частните команди за памет в Telegram ограничават вече обхвата на връзките до съответното лице.
  • Фокусът на паметта скрива връзките на други лица и запазва останалия контекст.
  • Корекциите и изтриванията не могат да избират връзка на друго лице; локалният фокус на оператора запазва пълния изглед.
9.1.409
  • Инструментите за отговор в Telegram и резервният път на TUI използват вече обща канонична директория за състоянието на канала.
  • Стойностите на BLUN_HOME, специфични за профила, вече не създават второ дърво от директории за входящите и изходящите съобщения в Telegram.
  • Изрично зададената стойност BLUN_TELEGRAM_STATE_DIR остава решаваща; в противен случай и двата пътя използват ~/.blun/channels/telegram.
9.1.408
  • Потвърдените детайли на връзките се обединяват едва след две независими наблюдения в директните канали.
  • Повторно възпроизведените съобщения остават идемпотентни; груповите съобщения и твърденията, подобни на разрешения, остават изключени.
  • Потвърдените напомняния за частни връзки могат да следват едно и също лице през Telegram и CLI, без да предоставят правомощия.
9.1.407
  • Инструментът за отговор в Telegram импортира пътя към текущия входящ журнал, използван от разпознаването на дубликати.
  • Нормалните отговори в Telegram вече не се провалят с грешката inboxLog is not defined.
  • Отделният резервен път на bridge остава наличен като гаранция за доставката.
9.1.406
  • Повтарящите се опити за доставка на частни Telegram събития с еднакъв времеви печат и текст се съхраняват само веднъж в непрекъснатостта на връзките.
  • Действително по-късно повторено твърдение остава част от ограничената история на връзките.
  • Естествено формулираните изрични напомняния в края на изречението се разпознават като референтни данни, без да предоставят или променят разрешения.
9.1.405
  • Свързаната Telegram команда /status съобщава вече възрастта и сърдечния ритъм на конзолния процес, текущата работна стъпка и активната задача, без да извиква модела.
  • Изоставането на опашката измерва вече непрочетените байтове от чекпойнт, който е обвързан с точния актуален файл на опашката.
  • Отдалеченият статус остава само за четене и не съдържа нито ID на чатове, нито пътища на файлове, нито данни за достъп и съдържание на съобщения, нито пълни списъци със задачи.
9.1.404
  • Непромененото съдържание на config.toml вече не заменя съществуващия частен файл.
  • Точното побайтово сравнение е ограничено до редовни цели, които не са символни връзки.
  • Променените, липсващите, невалидните и нечетимите цели продължават да използват съществуващия защитен срещу срив атомарен път за запис.
9.1.403
  • Автоматичният ред на зареждаемите инструменти игнорира вградените полезни товари от прикачени файлове и документи.
  • Всеки фрагмент на намерението се ограничава преди лексикалното сравнение до съществуващия бюджет на заявката за ToolSearch от 1 000 знака.
  • Същинските инструкции, прикачените файлове и изричните заявки за ToolSearch остават непроменени.
9.1.402
  • Изтеклите архиви на историята на сгъстяването се почистват еднократно във фонов режим при стартиране на команда на King.
  • Почистването при старт не блокира и не може да забавя нормалната обработка на команди.
  • Грешките при почистването се протоколират безопасно и не прекъсват текущата сесия.
9.1.401
  • Първият текстов фрагмент на всеки текущ отговор се показва вече незабавно, вместо да чака таймерно обратно извикване.
  • Нов ход и всеки нов сегмент на отговор на асистента получават съответно собствено незабавно първо показване.
  • По-късните текстови, мисловни и инструментални фрагменти запазват адаптивния ритъм на пакетиране, който защитава производителността на дългите сесии.
9.1.400
  • Големите продължени сесии се възпроизвеждат вече кооперативно, така че TUI може да прерисува и реагира по време на възстановяването на историята.
  • Всеки постоянно съхранен запис на възпроизвеждане продължава да се показва; никоя част от историята не се отрязва, прескача или изтрива.
  • Малките продължения запазват досегашното си поведение; големите продължения предават изпълнението на цикъла на събитията след всеки 30 записа.
9.1.399
  • Проверените кандидати за учене са вече ограничени до текущия Git проект, вместо да попадат в несвързани хранилища.
  • HTTPS и SSH изтеглянията на едно и също хранилище използват обща анонимна идентичност на проекта.
  • URL адресите на хранилищата и локалните пътища на проекти никога не се съхраняват в записите за кандидати за учене; работата извън Git запазва досегашното поведение в рамките на профила.
9.1.398
  • Чистите текстови отговори в Telegram се дедуплицират вече през пътя на инструмента и двата автоматични резервни пътя.
  • Идентичен или почти идентичен отговор се потиска само ако няма по-ново получено съобщение.
  • Прикачените файлове, различните резултати и отговорите след ново потребителско съобщение запазват досегашното си поведение.
9.1.397
  • Целите с изричен критерий за завършване изискват вече преди приключването си чекпойнт, подкрепен от изпълнението.
  • При неуспешна проверка за завършване целта остава активна и връща конкретни указания за преработка.
  • Обикновените ходове и целите без изричен критерий за завършване запазват досегашното си поведение.
9.1.396
  • Естествените заявки могат да изберат предварително в същия ход до две схеми на зареждаеми инструменти, които съответстват с висока сигурност.
  • Изборът взема предвид изключително текущото намерение в канала и игнорира остарял Telegram контекст.
  • За слаби, двусмислени или непознати заявки ToolSearch остава достъпен, без да увеличава постоянно заредения набор от инструменти.
9.1.395
  • Приетите медийни задачи се проследяват постоянно, еднаквите отворени заявки се преизползват, а завършените резултати се съхраняват след проверка на качеството и се доставят на съответния чат.
9.1.394
  • Версиониран, доброволно активируем доставчик на памет може да свързва CLI и порталните ходове с общ поток от когнитивни събития.
  • По подразбиране остава съществуващото локално SQLite хранилище, без нов мрежов достъп или променено поведение по време на изпълнение.
  • Пътищата на доставчиците, синхронните фабрични функции и версия 6 на договора се проверяват сигурно преди старта на изпълнението и се отхвърлят при отклонения.
9.1.393
  • Интерактивните стартове с king и king -c показват отново видимия избор за актуализация 1/2/3, щом има по-нова версия.
  • Изтеглянето на актуализации във фонов режим, чакащото активиране и отложената автоматична смяна бяха премахнати.
  • След избрана инсталация king приключва за ръчен рестарт; king -c продължава последната сесия с новата версия.
9.1.392
  • Непълните междинни състояния на генериране на изображение вече не се изпращат като частна Telegram актуализация, докато все още няма медиен резултат.
  • Измерените описания на грешки на GenerateImage и GetMedia се потискат; завършените медийни доставки остават видими.
  • Частните разговори и обикновените поискани резултати остават непроменени.
9.1.391
  • Непрекъснатостта на спомените между порталите изисква вече точен, активен доказателствен запис за свързване на идентичности от довереното изпълнение.
  • Подобните имена, отклоняващите се наематели или изходни идентичности, неправилните издатели и оттеглените доказателства остават разделени и се отхвърлят сигурно.
  • Версия 6 на договора за адаптер на памет поддържа верифициран OAuth, сигурни свързвания на акаунти и изрично потвърдени съпоставяния на идентичности, без да извежда разрешения от спомени.
9.1.390
  • Общият плик на паметта записва вече момента на събитието и момента на постъпване поотделно.
  • Всяко ново когнитивно събитие получава изрично клас на съхранение за оперативни данни, постоянни данни, връзки или цели на проверката.
  • Версия 5 на договора за адаптер на памет отхвърля непълните пликове на събития преди всеки локален или отдалечен запис.
9.1.389
  • Събитията на паметта записват портала източник и канала източник вече като отделни, удостоверени полета за произход.
  • Пътищата на CLI, Telegram, изпълнението, личността, корекцията и оттеглянето запазват точния канал при съхранение и възпроизвеждане.
  • Версия 4 на договора за адаптер на памет отхвърля записи, когато съхраненият канал източник не съвпада с канала, освободен от разрешението.
9.1.388
  • Операциите за четене на памет връщат вече само наблюдения от обхвата на видимост, освободен от разрешението, освен ако не се използва строго вътрешният път на агента.
  • Записите, проверките на събития и операциите за внимание се отхвърлят сигурно, когато техният обхват или удостовереният им източник не съответства на текущия контекст на достъп.
  • Локалният SQLite адаптер запитва ограничените наблюдения чрез собствен индекс на видимост, вместо първо да зарежда несвързани спомени.
9.1.387
  • Всяка операция на адаптер на памет носи вече строг контекст за идентичност, портал, канал, разговор, обхват и разрешения.
  • Контекстът на разрешенията се проверява извън полезния товар на паметта и не се съхранява постоянно като запомнено съдържание.
  • Дедупликацията на събития е ограничена до наемател и агент. Така съществуването на събития не може да се разпознава през наематели.
9.1.386
  • Когнитивното състояние стои вече зад версиониран договор за адаптери на памет, който жизненият цикъл на хода и средата за изпълнение на личността използват съвместно.
  • Съществуващото SQLite хранилище за събития остава настройката по подразбиране. Външни портални клиенти могат да предоставят същия договор, без да създават портално собствено състояние.
  • Неподдържаните версии на адаптери и непълните реализации се отхвърлят сигурно преди всяка операция на паметта.
9.1.385
  • Telegram съобщенията, поставени в опашката преди старта на сесията, се освобождават вече, щом сесията е готова.
  • Сесиите в празен ход изпразват опашката в нормалния FIFO ред; вече продължените активни ходове използват ограничено управление.
  • Постоянните чекпойнти на опашката остават непроменени, докато съобщението не бъде действително прието.
9.1.384
  • Препратките към Telegram изображения зареждат вече в същия ход инструментите за проверка на изображения и за генериране на изображения.
  • Буферираните Telegram съобщения запазват медийното намерение за целия чакащ пакет, вместо да вземат предвид само последното съобщение.
  • Локалните пътища на изображения и файловите идентификатори на Telegram избират подходящия път за проверка или изтегляне, без да зареждат постоянно медийни схеми.
9.1.383
  • Новите резултати от Read остават вече напълно видими за моделната стъпка, която ги е поискала, вместо да бъдат изнасяни преди оценката.
  • Паралелните нови резултати от инструменти остават четими до тяхната стъпка на оценка и могат да бъдат архивирани едва след като станат исторически.
  • Архивирането на исторически изходи и спестяването на контекст остават активни след защитения прозорец за най-новата работа.
9.1.382
  • Командата /loop се приема вече и докато тече друг отговор.
  • Ако се създаде цикъл по време на текуща работа, King го запазва и вкарва първата му инструкция в опашката, без да прекъсва текущия ход.
  • Създаването на цикъл в празен ход, както и досегашното поведение за статус, пауза, продължаване и спиране остават непроменени.
9.1.381
  • След окончателно неуспешно търсене в ToolSearch, ToolSearch се премахва от активния списък с инструменти за остатъка от този ход.
  • Успешното разпознаване на схеми и обработката на вече заредени инструменти остават достъпни и непроменени.
  • Така повторните търсения на синоними не изразходват повече токени, след като изпълнението вече е доказало, че няма подходяща интеграция.
9.1.380
  • Временна грешка при управлението на активния ход активира вече незабавно отново управлението на доставката в Telegram, вместо да остави възстановеното групово съобщение да чака до края на хода.
  • Чакащите групови съобщения продължават да се доставят и по време на дълга работа; при това се запазват FIFO редът и съществуващата граница на карантина от три опита.
  • Никоя текуща сесия не се прекъсва или рестартира.
9.1.379
  • Временните повторения на потвърждението на управление на канал не показват вече фалшива червена грешка, докато съобщението остава възстановимо в опашката.
  • Видима грешка при доставката се появява едва след като третият неуспешен опит е архивирал сигурно пълния първи запис на опашката.
  • Поведението за повторение, потвърждение, архивиране и FIFO ред остава непроменено.
9.1.378
  • При бързи последователни публикации във фонов режим има вече един единствен заменяем статус за подготвената актуализация, вместо за всяка версия да се добавя нов компонент на протокола.
  • Записът за подготвената актуализация показва винаги най-новата проверена целева версия; активната сесия остава недокосната до естествения си рестарт.
  • Указанието за действителната инсталация и за промените остава постоянно и непроменено. По-малко промени в протокола не скриват следователно активирана актуализация.
9.1.377
  • Чакащите Telegram задачи поемат вече решаващото ID на активния ход от ядрото. Остарял видим TUI статус не може вече да доведе до това прието съобщение да остане непотвърдено.
  • Управляващата команда /loop се изпълнява незабавно по време на текуща работа; постоянното потвърждение на командата не зависи вече от успешен статусен отговор в Telegram.
  • Ако доставката на първия запис на опашката се провали три пъти, той се архивира локално с всички метаданни за възстановяване, преди опашката да продължи. Така повреден запис не блокира по-късни съобщения.
9.1.376
  • Големите исторически резултати от инструменти се съхраняват постоянно преди сгъстяването на контекста, така че пълният им изход остава възстановим и след изпразване на вграденото предварително показване.
  • Запазените препратки към резултати преживяват по-късни микро-сгъстявания и запазват ограничените метаданни, необходими за повторното зареждане на първоначалния изход.
  • Телеметрията на изнасянето отчита размери и статус на възстановяване, без да разкрива съдържанието на резултатите или частни пътища.
9.1.375
  • Частните Telegram директни съобщения и слаш командите запазват най-високия приоритет на доставка. Изрично адресираната групова работа се подрежда след това по FIFO преди нормалната или неадресираната стара работа.
  • Предаване на актуализация може да премине през непразна опашка само ако всеки запис е устойчиво съхранена, още непотвърдена Telegram работа с обратен път за потвърждение. Локалната, смесената или неустойчиво съхранената работа продължава да блокира.
  • Бележката за подготвена актуализация следва освободен UI език на персоната. При език, който още не е освободен като TUI локал, се показва само информацията за версията, вместо да се премине на грешен език.
9.1.374
  • Бележката за подготвена актуализация вече не използва твърдо вградено немско съобщение, а вече освободения UI превод на активния език.
  • Режимите за подновяване и нова сесия остават разделени; предаването на актуализация, връщането назад и потвърждаването на Telegram дубликати не са омекотени.
9.1.373
  • Подготвена във фонов режим актуализация може вече да поеме текущата сесия на проверена безопасна граница. ID на сесията и работната директория се запазват; работещите инструменти, shell командите, сгъстяването и чакащите съобщения предотвратяват предаването.
  • Супервайзорът активира новото изпълнение едва след неговите loaded и ready доказателства. При неуспешен старт старото изпълнение се възстановява заедно с точната сесия и повреденият pending запис се отхвърля.
  • Възстановените вече в регистъра на доставките Telegram дубликати се потвърждават незабавно при повторното възпроизвеждане на опашката. Те вече не чакат моделна стъпка, която за дубликат умишлено никога не стартира, и не блокират повече последващи групови съобщения.
  • Постоянният работен фокус носи вече статус на знанието, контекст на доказателствата, корекции, оттегляния и увереност през ходовете. От това не произтичат нови права или одобрения.
9.1.372
  • Постоянните целеви чекпойнти различават вече verified, credible_unverified, hypothesis, uncertain_memory, stale и unknown. Правдоподобните предположения вече не се третират като сигурно знание.
  • Произходът и статусът на знанието се проверяват заедно: доказателства от инструменти на изпълнението могат да важат като verified само след успешно изпълнение на инструмент, външните отчети не. Състоянията, пренесени напред, запазват досегашния си статус и последното си доказателство за проверка.
  • Старите replay състояния без новото поле остават четими като legacy_unknown. Новите чекпойнти трябва изрично да назовават статуса си. Правата, одобренията и авторитетът остават непроменени.
  • Кратката проекция на контекста назовава епистемичното състояние в точно един ред, така че агентът да го вземе предвид при следващата стъпка, без да натоварва контекстния бюджет с допълнителен текст.
9.1.371
  • Ремонт на грешка в свързването от 9.1.370: Съхранената там и проектирана стойност evidenceBasis е вече и част от строгата публична изходна схема на GetGoal и не се губи повече при извличане.
  • Схемата приема четирите актуални типа произход, както и legacy_unknown за стари replay състояния. Правата, одобренията и авторитетът остават непроменени.
  • Фокусирана проба на свързването и собствен мутант осигуряват новата публична връзка срещу регрес.
9.1.370
  • Всеки свеж работен чекпойнт назовава вече изрично на какво се основава последното му доказано състояние: успешно извикване на инструмент от изпълнението, пряко твърдение на потребителя, външен отчет или непроменено пренасяне напред.
  • runtime_tool се приема само ако текущият ход съдържа поне едно допуснато от изпълнението и успешно завършено извикване на инструмент. carried_forward не може да променя последното доказано състояние. И двата пътя прекъсват fail-closed при противоречие.
  • Старите съхранени чекпойнти остават четими като legacy_unknown. Типът на произхода е епистемично състояние и не създава нито права, нито одобрения, нито авторитет.
9.1.369
  • Постоянният работен чекпойнт получава вече автоматично компактно доказателство за изпълнението от вече завършените извиквания на инструменти на същия ход. Доказателството назовава само ID на хода, общия брой, броя на успехите и грешките, както и кратък digest.
  • Имената на инструменти, ID-тата, аргументите, командите, изходите, пътищата и потребителският текст не се записват в чекпойнта. Празно доказателство остава честно при нула, вместо да симулира измерване.
  • Само допуснато от политиката на изпълнението и успешно завършено извикване на инструмент се брои за успех. Блокираните, неуспешните, прекъснатите или доставените от модела доказателства не създават авторитет.
9.1.368
  • Всеки постоянен работен чекпойнт носи вече монотонна ревизия. Първият запис започва с ревизия 1; всеки следващ трябва да увеличи текущо проектираната ревизия точно с едно.
  • Стар паралелен ход или остарял изглед на канала не може вече да презапише по-късно доказано работно състояние. Остарелите, прескочените и невалидните ревизии прекъсват fail-closed, преди целевото състояние да бъде променено.
  • Съществуващите чекпойнти без поле за ревизия се третират при четене съвместимо като ревизия 1. Ревизията е работно състояние и не създава права или одобрения.
9.1.367
  • Активният напомнител за целта носи вече директно постоянния работен чекпойнт. King запазва фазата, последното доказано състояние, точната следваща стъпка и очакваното доказателство дори когато допълнителният когнитивен адаптер за памет в момента не е наличен.
  • Преди алтернативни пътища първо се изпълнява точно предвиденото следващо действие. Чекпойнтът се променя едва когато ново доказателство действително промени потвърденото състояние.
  • Резервният вариант е само компактна проекция на вече проверения чекпойнт. Той не създава права, нови полета с данни или рестарт.
9.1.366
  • Активните цели могат вече да съхраняват малък, постоянен работен чекпойнт с фаза, последен доказан резултат, точна следваща стъпка и очаквано доказателство. След подновяване или възпроизвеждане на събития King продължава от това място, вместо отново да иска разрешение или да започва отначало.
  • Чисто обновяване на чекпойнт оставя целта активна. Паузираните и блокираните цели остават непроменени; подновяването задава само наново измерителя на времето за изпълнение.
  • Чекпойнтът е строго ограничен и чисто работна информация. Непознатите полета, особено данните за права или администрация, прекъсват fail-closed и не могат да създадат capability.
  • Без чекпойнт досегашният компактен фокус остава непроменен. С чекпойнт само четирите релевантни фокусни наблюдения се допълват с доказаното състояние; така разходът за токени остава малък и постоянен.
9.1.365
  • Частните Telegram директни съобщения и локалният CLI могат вече да четат, коригират или изтриват постоянния фокус директно с /memory focus, /memory correct <id> <стойност> и /memory delete <id>. Този път не стартира моделен ход и следователно не изразходва моделни токени.
  • Промените в Telegram са обвързани с положителни ID на потребител, чат и съобщение, истинско частно директно съобщение, момента на канала и стабилен ID на заявка. Групите, непълният произход и променените повторения прекъсват fail-closed.
  • Домейнът, ключът и обхватът се извличат винаги от активния доказателствен запис на целта и не могат да бъдат внесени от извикващия. Корекциите и tombstone записите остават append-only, запазват историята и не предоставят права.
  • Изходът на фокуса е ограничен за Telegram до осем записа и по-малко от 3 500 знака; общият брой остава видим.
9.1.364
  • Текущият когнитивен жизнен цикъл може вече да коригира постоянния фокус чрез correctFocusObservation и да го изтрие чрез withdrawFocusObservation. И двата пътя записват по-нататък append-only в същия поток от събития, обвързан с наемател и агент.
  • Ревизия е допустима само с удостоверението runtime_user_prompt_hook и explicit_user_request. Нормален моделен snapshot не може нито да изведе, нито да внесе корекция или изтриване.
  • Всяка ревизия носи стабилен ID на заявка, както и портал, актьор, контекст, съобщение и момент. Идентичното повторение е идемпотентно; същият ID на заявка с променено съдържание и ревизии с минали дати прекъсват fail-closed.
  • Корекцията и последващото изтриване оставят пълната история непроменена. След изтриването фактът вече не се появява в промпта и не изразходва контекстни токени. Паметта не може да предоставя права.
9.1.363
  • Потвърдено изтриване се съхранява вече като append-only tombstone. Предишното съдържание остава в одитната история и в хеш веригата, но изчезва напълно от действащата проекция на контекста.
  • Стари Resume, transcript или опашкови събития с момент преди изтриването не могат да активират отново премахнатото съдържание. Така по-късно повторно възпроизведено старо състояние не се третира като нова истина.
  • Съзнателно новопредоставена информация след момента на изтриването може да бъде научена отново. Tombstone блокира следователно старите доказателства, не бъдещото развитие.
  • Изтриванията през чужди наематели, агенти, домейни, ключове или обхвати, с липсваща цел, слаба увереност или грешна tombstone стойност, се отхвърлят транзакционно. Съществуващите бази данни мигрират на място.
  • Изтрит факт не създава ред в промпта и следователно не изразходва контекстни токени.
9.1.362
  • Потвърдена корекция може вече да замести изрично точно едно по-ранно наблюдение в същата област на наемател, агент, домейн, ключ и обхват. Старият запис остава append-only в одитната история.
  • Действащият изглед зарежда коригираната стойност и я маркира като corrected; заместената стойност вече не се проектира като актуален конфликт.
  • Липсващите цели, чуждите обхвати или ключове и корекциите под увереност 1 се отхвърлят транзакционно.
  • Съществуващите SQLite състояния получават новата колона за връзки при отваряне, без да губят досегашния си поток или версия.
9.1.361
  • Еднакво достоверни лични или екипни твърдения със същия обхват и ключ вече не се извеждат като истина по принципа "най-новата стойност печели". Проекцията маркира конфликта кратко и изисква изясняване, без да изсипва двете съдържания в контекста.
  • Ако едно твърдение е с поне 0,2 пункта увереност по-силно, то остава използваемо, но се отбелязва като оспорвано. По-късно по-слабо твърдение не може вече да скрие потвърдено състояние.
  • Идентичните потвърждения се обединяват в една фокусна точка. Каноничните полета за цел и напредък остават и по-нататък податливи на ревизии.
  • Историята на събитията append-only остава непроменена; от действащия изглед не могат да възникнат разрешения.
9.1.360
  • Вече каноничното състояние на /goal се проектира като постоянен работен фокус в потока от когнитивни събития: цел, статус, следващ тригер и очаквано доказателство за успех.
  • Същият фокус остава идемпотентен през рестарти на изпълнението. Непроменено целево състояние не създава двойни събития или наблюдения.
  • Броячите за използване, времевият бюджет и разрешенията не се копират във фокуса. Без активна цел не се зареждат допълнителни фокусни токени.
  • Проекцията свързва подходящия обхват на целта с частния обхват на връзките на текущия ход; тя не създава права.
9.1.359
  • Паметта на личността и истинските CLI ходове използват вече същия поток от идентичности на наемател и агент от identity/manifest.json; без пълна идентичност остава съвместимият хеширан резервен път.
  • Директните Telegram ходове проектират само частния обхват на връзките на текущия събеседник. Групите и чуждите връзки не доставят частни фокусни токени.
  • Изборът на обхват е наложен преди класирането; по-ново знание от чужд обхват не може вече да скрие подходящ запис.
9.1.358
  • Мрежова грешка по време на автоматичната подготовка на актуализация се съобщаваше само на опционална функция за обратно извикване при грешки. Без нов poll работещият King оставаше на своето състояние, въпреки че самата сесия продължаваше да работи нормално.
  • Launcher-ът записва вече ограничено събитие prepare-failed с версията, както и безопасно име/код на грешката в handoff.jsonl.
  • След това точно десет секунди по-късно се планира нов опит за подготовка. Работещото ядро не се прекратява и не се презарежда.
  • Грешките при запис на диагностичното събитие остават fail-soft; токени, текст на съобщения и други тайни не се протоколират.
9.1.357
  • Повтарящите се достъпи до същия ефективен системен промпт вече не изграждат наново големия низ от основа и приложение по време на изпълнение при всеки достъп.
  • Resolver-ът държи точно една актуална комбинация от основа и приложение и я инвалидира незабавно, щом една от двете входни стойности се промени.
  • Празният промпт, само основата, само приложението и досегашното разделяне с два нови реда остават побайтово запазени.
9.1.356
  • Непроменените системни промпти се броят за контекстния бюджет при повтарящи се моделни стъпки само веднъж, знак по знак.
  • Кешът е ограничен до четири записа, най-много 500 000 знака на промпт и общо 1 000 000 задържани знака.
  • Променените промпти продължават да се броят наново; индикацията за контекст, бюджетът за сгъстяване и бюджетът на заявката използват една и съща актуална стойност.
9.1.355
  • Непроменените конфигурации на LLM заявки вече не сериализират отново своите схеми на инструменти при всяка моделна стъпка само за конфигурационния журнал.
  • Моделът, алиасът, степента на размисъл, системният промпт и последователността на инструментите се сравняват с последното пълно състояние.
  • Променените модели, промпти, имена на инструменти, описания или параметрични схеми отварят отново целенасочено конфигурационното журналиране.
9.1.354
  • Непроменените схеми на инструменти се сериализират само веднъж на обект инструмент и се броят за контекстния бюджет.
  • Инвентар с 403 инструмента вече не се брои наново изцяло при повтарящи се проверки на заявки.
  • Промените в името, описанието или обекта на параметрите отхвърлят целенасочено само кеш записа на засегнатия инструмент.
9.1.353
  • Фрагментите на аргументи от инструментите на рояк агенти продължават да се парсират незабавно и да се поемат в състоянието на напредъка, но вече споделят адаптивния таймер за рендериране.
  • Голямо стриймвано извикване на инструмент вече не предизвиква пълен TUI render за всеки фрагмент на аргумент.
  • Стартът, завършването, грешките и прекъсването премахват отворените таймери на рояка преди техния окончателен незабавен render.
9.1.352
  • Фрагментите на асистента и размисъла на рояк агенти актуализират състоянието на напредъка и по-нататък незабавно, но споделят адаптивен таймер за рендериране.
  • Фрагментен залп вече не предизвиква за всяка делта пълен TUI render.
  • Дискретните събития на рояка и почистването на напредъка премахват отворените таймери преди своя незабавен финален render.
9.1.351
  • Фрагментите на асистента и размисъла в прозореца BTW/агент се съхраняват незабавно в хода, но споделят адаптивен таймер за рендериране.
  • Контролерът вече не изисква за тези два вида делта допълнителен пълен render на фрагмент.
  • Завършването, грешките, повторният опит и dispose премахват отворените таймери; дискретните hook и събития за завършване остават незабавно видими.
9.1.350
  • ToolCallComponent.appendSubToolLiveOutput поема stdout и stderr парчетата незабавно в състоянието на активност, но изгражда картата на подагента отново само в адаптивния такт на стриймване.
  • Общ pending набор обработва няколко едновременно работещи под-инструмента без загубен изход или таймер на парче.
  • Завършването на инструмент премахва своя отворен refresh преди окончателното представяне; dispose изхвърля чисто таймера и pending набора.
9.1.349
  • ToolCallComponent.appendSubagentText събира бързо пристигащите текстови и размисловни фрагменти незабавно във вътрешното състояние, но изгражда картата на подагента отново само в адаптивния такт на стриймване.
  • Завършването и състоянието на грешка изпразват все още отворен текстов refresh преди окончателното представяне; dispose изхвърля таймера чисто.
  • Така входящите байтове остават незабавно достъпни, докато повторните пълни изграждания, снимки и рендери при фрагментни залпове отпадат.
9.1.348
  • Нарастващите аргументи на подагент/под-инструменти продължават да се събират незабавно изцяло, но вече не се парсират и рендерират наново след всеки отделен фрагмент.
  • Адаптивен таймер обединява актуализацията на предварителния преглед. При завършване чакащите аргументи се вкарват задължително преди крайното състояние на инструмента.
  • Изпълнението на инструменти, одобренията, крайните аргументи и съществуващият нормален стрийм път остават непроменени.
9.1.347
  • Пътят на събитията извикваше след всяка входяща делта на аргументи на инструмент незабавно getStreamingToolCallPreview. Тази функция парсира дотогава пълния нарастващ JSON текст.
  • Извикването се извършваше и за нормални инструменти, въпреки че само AgentSwarm се нуждае от незабавно парсираното междинно състояние за своята текуща индикация за напредък. Така нормалният път частично заобикаляше ограничената каденца за предварителен преглед, въведена в 9.1.346.
  • Малка чиста policy решава вече преди парсирането: нормалните инструменти събират само делтата и парсират при планирания flush на предварителния преглед; AgentSwarm парсира и по-нататък незабавно при име на събитие, активно име на инструмент или съществуващ напредък на рояка.
  • Изпълнението на инструменти, одобренията, крайните аргументи и индикацията на рояка остават непроменени.
9.1.346
  • 9.1.345 ограничи пълнотекстовите повторни рендери за дълги потоци от отговори и размисъл, но чистите потоци от аргументи на инструменти нямаха нито една от тези две текстови чернови и останаха следователно при фиксирани 50 ms.
  • Всяка предварителна визуализация на инструмент парсира дотогава пълния нарастващ JSON текст на аргументите. Големите извиквания на инструменти можеха следователно много често да парсират и рендерират наново целия полезен товар.
  • Вече доказаната адаптивна каденца взема предвид и общия брой знаци на активните стриймвани аргументи на инструменти: 50, 100, 250 или 500 ms според същите граници.
  • Изпълнението на инструменти, аргументите, одобренията, крайната предварителна визуализация и незабавните финални flush-ове остават непроменени.
9.1.345
  • TUI задаваше при стриймване досега на всеки 50 ms наново изцяло натрупания до момента текст на отговора и размисъла. При дълги моделни отговори нарастваше следователно силно количеството текст, което трябваше да се рендерира многократно.
  • Кратките потоци до 8.192 знака запазват досегашната отзивчива каденца от 50-ms. След това интервалът се увеличава постепенно на 100 ms до 32.768, на 250 ms до 131.072 и на 500 ms отгоре.
  • Изричните flush-ове на границите на инструменти и при финализирането остават незабавни. Логиката за доставчика, опашката, сесията и токените не е променена.
9.1.344
  • Когнитивният слой по време на изпълнение записваше за всяко извикване на инструмент policy и резултат досега в две отделни синхронни SQLite транзакции.
  • Изолирана Windows разходна проба със 100 извиквания на инструменти изискваше за това 627,63 ms и създаваше 201 събития. Съдържанието обхващаше 305 наблюдения.
  • Завършените двойки policy/резултат на една моделна стъпка се фиксират вече атомарно в ограничени групи от най-много десет инструмента. Прекъснатите или все още отворени проверки на policy продължават да се съхраняват поотделно в края на хода.
  • Аргументите, изходите, решението за права, хеш веригата и SQLite устойчивостта остават непроменени.
9.1.343
  • Частен Telegram отговор беше вече успешно доставен с инструмента за отговор. След това същият моделен ход стартира въпреки това още една стъпка и създаде вътрешен статус и контролен текст на работата.
  • Допълнителната стъпка струваше в измерената реална сесия 42.360 входни и 411 изходни токена, въпреки че видимият отговор на потребителя вече беше изпратен.
  • Успешен Telegram отговор прекратява вече незабавно частен разговорен ход, маркиран като direct. Неуспешните отговори, групите и другите инструменти продължават непроменено.
  • След приключване продължава да действа съществуващият контролер за директния фокус: той отбелязва доставения отговор и се връща след края на разговора или времето за покой към съхранената фонова работа.
9.1.342
  • Заявката за релевантност за Mistake.md поемаше досега всяко съобщение с роля user. Към това спадаха и вътрешните инжекции, обобщенията на сгъстяването, активациите на skills и фоновите съобщения.
  • Тъй като самото напомняне за грешки се съхранява като вътрешно user съобщение, то променяше след всяка инструментална стъпка собствената си заявка за търсене. Така в същия ход отново се избираше и вкарваше.
  • Филтърът използва вече само свързани с действието потребителски и cron входове. Вътрешните текстове на изпълнението се изключват от заявката за релевантност и от разпознаването на слаба информация.
  • Истинските потребителски съобщения, планираната работа, всички проверени поуки и новото изграждане след сгъстяване остават непроменено достъпни.
9.1.341
  • При естествен старт launcher-ът намери вече локално подготвено и проверено автоматично изпълнение, но въпреки това го прати първо през зависимата от мрежата бележка за актуализация. Ако този втори опит се провалеше временно, отново се стартираше старата глобална версия.
  • Подготвено автоматично изпълнение с точно съответстващ режим (resume или new) се стартира вече преди новия опит за изтегляне на release. Активирането остава транзакционно: едва когато новото ядро се зареди успешно, изпълнението се отчита като активно.
  • При resume ID на сесията и работната директория се запазват. Ръчният избор на актуализация продължава да минава през досегашния път на бележката.
  • Нито един работещ King не се прекратява. Корекцията важи изключително при следващия естествен старт.
9.1.340
  • Launcher-ът записваше успешни актуализации в .blun/updates/install.json, докато профилно изпълнение търсеше в .blun/profile/<name>/updates/install.json. Истинският профилен път не съществуваше; затова notifiedAt оставаше в общото състояние null.
  • Профилните изпълнения четат вече успеха на актуализацията от BLUN_SHARED_HOME и падат върху досегашния BLUN_HOME само без общ път.
  • След следващия естествен старт TUI може да покаже веднъж версията и до три бележки за release. Конфигурираните частни Telegram получатели получават същия кратък текст без моделен ход и без разход на токени.
  • Инсталацията, staging, активирането и правилото никога-не-изхвърляй остават непроменени.
9.1.339
  • Успешните последващи инструментални стъпки с нисък разход на усилия използват най-много 4.096 completion токена вместо досегашните 8.192.
  • Първите стъпки, сложните задачи и последващите стъпки при грешки запазват конфигурирания си капацитет за размисъл и изход. Намесата не е глобална граница за модел или контекст.
  • Обратното измерване върху 1.442 реални стъпки с нисък разход на усилия на агентен профил даде: 2.118.588 изходни токена общо, медиана 791, p90 3.754, p95 5.485. С новата граница щяха да отпаднат 229.761 токена, респективно 10,8 Prozent; 91,1 Prozent от измерените стъпки остават непроменени.
9.1.338
  • Чистите въпроси за повторение като Мога ли да продължа с работата си? вече не се доставят в частните Telegram разговори.
  • Вътрешният разказ за опашката, handoff, лентите и състоянието на чакане остава извън частния отговор. Истинските работни резултати и нормалните лични отговори остават доставими.
  • Ако полезен отговор завършва само с нов въпрос за одобрение на работата, се премахва изключително този заключителен въпрос.
  • Груповият маршрутинг и текущите сесии остават непроменени.
9.1.337
  • profile/<name>/SOUL.md е каноничният път на идентичността на King.
  • Подходяща именувана наследена душа заменя само непроменена, създадена профилна скелетна структура. Развитите профилни души никога не се презаписват.
  • Преди наследен импорт създадената скелетна структура се запазва като SOUL.md.pre-legacy-import.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • Прекъснатите сесии нормализират своето replay състояние, преди да се достави по-нататъшна Telegram работа.
  • Ако доставката до активен ход бъде отхвърлена, съобщението пада върху свеж опашков ход, вместо да се опитва отново същият steer на всеки пет секунди.
  • Фокусните чекпойнти на директните съобщения запазват автоматичните таймери за подновяване и изричните паузи през актуализациите.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Нормално частно Telegram съобщение прекъсва текущата задача само за непосредствения разговор. След това King продължава автоматично точно запазеното работно състояние след 60 секунди без нов въпрос за разрешение.
  • Изричният край на разговора продължава задачата незабавно. Само ясните потребителски желания като pause, pausiere, stop, stopp, warte или halte an продължават да задържат задачата, докато потребителят не я освободи отново.
  • Вътрешните понятия и статусни доклади за cron, чекпойнт, опашка или лента се потискат в нормалните частни отговори. Същинската работа и нейното съхранено състояние остават непроменени.
9.1.334
  • Автоматичната фонова подготовка вече не гладува при бърза последователност от release-и. Досегашната 30-минутна блокада се отнасяше винаги към съответно най-новия release; при release-и на минутни интервали никоя версия не остаряваше достатъчно, за да бъде подготвена.
  • Криптографски съответстващ release се зарежда вече незабавно, проверява се за цялост, инсталира се изолирано, сондира се синтактично и се отбелязва като предстоящо изпълнение.
  • Текущата King сесия продължава да не се прекратява. Активирането и подновяването остават изключително на съществуващия защитен път на следващия старт. Тази версия не променя нито handoff, нито логиката на сесията.
9.1.333
  • Екранна снимка на живо доказа след 9.1.331 грешка ERR_MODULE_NOT_FOUND в управлявания Telegram плъгин.
  • Импортът на плъгина сочеше от изолираното управлявано дърво към файл на ядрото, който не беше инсталиран там.
  • Също измереният огромен текст на повторение течеше във видимия поток на размисъл. Съществуващата блокировка на повторенията на живо проверяваше дотогава само делтите на отговорите.
  • 9.1.332 не беше включено в публичния манифест след констатацията за плъгина. 9.1.333 заменя изцяло този npm кандидат.
9.1.332 Непубликувано
  • Непубликувано. Импорт на плъгин сочеше от изолираното дърво към файл на ядрото, който не беше доставен; 9.1.333 замени изцяло npm кандидата.
9.1.331
  • Частните Telegram разговори запазват естествените отговори и поисканите работни резултати.
  • Измерените вътрешни двойни съобщения за паузирана работа, вече изпратени отговори, текущи ходове, статус на инструменти и липсваща необходимост от действие се потискат само в частните чатове.
  • Съобщение се филтрира само ако съдържа както вътрешен контекст на изпълнението, така и изрично никаква нова потребителска стойност.
  • Груповият маршрутинг, истинските доклади за завършване и нормалните кратки разговори остават непроменени.
9.1.330
  • Пълният изходен файл на душата на всеки King остава непроменено запазен.
  • Моделният контекст получава от него ограничена проекция на характера с идентичност, глас, ценности, връзки, предпочитания, цели и израстваща история.
  • Ясните секции за задачи, ленти, права, QA, инструменти, команди, верификация, инциденти, журнали, изпълнение, актуализации, deploy и build вече не се зареждат като личност във всеки промпт.
  • Чисто кратките души на характер остават побайтово запазени. Непознатите нетехнически секции остават видими в своя ред.
  • Нито един файл на душата не се изтрива, съкращава или пренаписва автоматично.
9.1.329
  • Всеки именуван King профил използва в общото ядро на идентичността свой собствен агентски възел. Връзките, историята и научените лични данни вече не се сгъват върху първоначално създадения агент.
  • Съществуващите именувани soul файлове като _agent-a_soul.md, _agent-b_soul.md или _agent-c_soul.md се причисляват към съответния профил и се поемат еднократно побайтово в SOUL.md.
  • Старият изходен файл остава непроменено запазен. Съществуваща профилна SOUL.md никога не се презаписва.
  • Изборът на персона и режимът на личността четат обвързано с профила. Повредена, твърде голяма или свързана профилна персона не пада незабелязано върху идентичността на друг агент.
  • Общото ядро остава използваемо без принуда за Mnemo. Текущите задачи, правата и QA правилата не се променят от тази миграция.
9.1.328
  • Персоната и SOUL.md се зареждат първо от активния профил.
  • Именуваните профили никога не наследяват душата на друг агент от общия home.
  • Legacy и профилите по подразбиране запазват досегашния общ fallback.
  • Ако собствен soul файл наистина липсва, веднъж се създава минимална скелетна структура; съществуващите файлове никога не се презаписват.
  • Системата за идентичност и връзки остава базирана на файлове и работи без принуда за Mnemo.
9.1.327
  • Частните Telegram разговори остават при лицето: вътрешните доклади за опашка, чекпойнт, пауза, cron, hook и празен ход се потискат и по двата пътя на изпращане, докато не е поискано работно състояние, не е необходимо решение и не е възникнал релевантен блокер.
  • Техническите работни състояния отиват в отговорния екипен канал. Те не се копират отново в частния разговор.
  • Точните моделни цикли на повторение се разпознават още по време на стрийма. Текущият поток на доставчика се прекратява и същата стъпка със запазен контекст на задачата се опитва точно веднъж отново.
  • Душата, личните знания, правата, текущите задачи и съществуващата пауза на директния фокус не са заменени или изтрити. Нито една работеща TUI не е рестартирана.
9.1.326
  • Ръчният и автоматичният режим на разрешения отразяват освобождаванията на инструменти като ограничени бутони в уникално свързания частен директен чат в Telegram.
  • Предават се само името на инструмента и съществуващите текстове за избор; аргументите, описанията и тайните остават локални. Изтеклите, чуждите или вече локално отговорени одобрения се отхвърлят fail-closed.
  • God Mode остава изцяло автономен и не създава Telegram одобрение.
  • Техническите работни състояния се маршрутизират до отговорния колега и вече не се копират обратно в частния разговор на потребителя.
9.1.325
  • God Mode извършва лични записи в паметта без втора заявка за одобрение; съществуващото съгласие, обвързано със сесията и хода, остава запазено.
  • Изрична Telegram инструкция за запомняне активира същото строго ограничено съгласие като директна конзолна инструкция. Ръчният и автоматичният режим на разрешения продължават да питат преди записа.
  • Журналът на актуализациите съхранява дали дадена инсталация е била задействана ръчно, автоматично или през стартовия диалог.
9.1.324
  • Първото доверено взаимодействие с бот го създава локално като възел за агент и за връзки. Роля, отговорности, особености, сътрудничество и handoff могат след това да растат структурирано.
  • Всеки King проектира компактен откъс за колегите в своя контекст. Така той познава задачите и особеностите на другите агенти, без да зарежда по принцип целия набор от връзки.
  • Ако липсва информация, критична за задачата, не се гадае: King пита точно веднъж най-подходящия човек или агент. Ако не е известна отговорност, той пита потребителя, вместо да измисля име.
  • Връзките и ролите никога не създават права. Полетата за разрешения, ACL и тайни не се проектират в откъса за колегите. Пътят е локален, обвързан с наемател, неутрален по отношение на имена, независим от Mnemo и не добавя нито моделни, нито инструментални повици.
9.1.323
  • Частните разговори отговарят отново на лицето, вместо доброволно да извеждат вътрешни процесни данни. Чекпойнтите, хешовете, пътищата, диагностиките на инструменти, cron и hook, скритите правила, чуждите задачи на агенти и докладите за празен ход остават вътрешни.
  • Работният статус се назовава само когато потребителят попита за него, когато е необходимо негово решение или блокер го засяга конкретно. Паузираната работа остава вътрешна и не се пренася в свободен разговор.
  • Правилото важи със и без режим на личността, не съдържа твърдо кодирани лица или агенти и добавя около 75 промпт токена, но никакво моделно или инструментално извикване. Приоритетът на задачите и задължението за доказателство остават непроменени.
9.1.322
  • Видимият превключвател на личността записва вече атомно persona.json. Името, езикът, бележките и всички други съществуващи полета на персоната остават запазени; променя се само personalityEnabled.
  • SOUL.md, AGENTS.md, JOURNAL.md и файловете за връзки не се записват нито при изключване, нито при включване. Нормалната SOUL-базирана агентна идентичност остава заредена в системния контекст и при изключена функция на личността.
  • Неуспешен жив refresh връща избора побайтово. Ако паралелно друг писец е променил persona.json, резервният път прекъсва с PERSONALITY_CHOICE_CONFLICT и не презаписва нищо.
  • Символните връзки, прекалено големите, невалидните или необектните файлове на персоната се отхвърлят fail-closed. При включване дървото на идентичността се подготвя преди commit-а.
  • Не е част от тази версия доказаният по-късно проблем на агент, който извежда вътрешни чекпойнти, cron правила, SHA стойности и чужди детайли на задачи в частни разговори. Този изходен филтър е следващият отделен build.
9.1.321
  • Спокоен първи частен обмен или доброволен личен намек може да постави точно една опционална възможност за любопитство в моделния контекст. Тя не е задължителен въпрос; подборът на думи и тонът идват от заредената SOUL.md, не от фиксиран каталог с въпроси.
  • Задачата, спешността, грешките, връзките, кодът, пътищата и груповият трафик потискат любопитството по принципа fail-closed. То не изпраща никога само и не прекъсва текуща работа.
  • 30-дневен cooldown важи за наемател, агент и свързано лице и през различни портали. Същият повторен опит на събитие е идемпотентен.
  • Новото състояние не лежи вече като Telegram-специфичен файл за любопитство в дървото на идентичността. Сменяем personality-memory-adapter записва вместо това версионирано събитие в съществуващия транзакционен когнитивен store. Telegram е произход; частната връзка е отделен scope на видимост.
  • Записват се само темата, стабилната идентификация на събитие/източник, моментът и частният scope. Суровият текст, фиксираните въпроси, твърденията за права и тайните не се включват. Несигурните roots, чуждите полета и отказът на store остават fail-closed.
  • Основа за порталната граница беше вътрешният концептуален документ v7. CLI е референтният клиент; локалният store е изрично обозначен като сменяема проекция и не е втори каноничен портален store.
9.1.320
  • Частните, изрични отворени разговорни нишки се съхраняват като неизменяеми, дедуплицирани събития с източник, момент, контекст и увереност. Естествени формулировки като Питай ме пак утре за ... се разпознават също като изричната open-thread форма.
  • Изричните указания за ремонт се съхраняват отделно от общите бележки за връзки и се вземат предвид в по-късното поведение.
  • Текущият ход не вижда умишлено още собствената си нова бележка. Едва по-късен частен ход получава ограничения контекст; така няма двойно или сугестивно самопотвърждение.
  • Задачата и изричните инструкции имат предимство пред социалния контекст. Отворените нишки не прекъсват активна работа и не изпращат никога сами. Данните за връзки не могат да създават права, освобождавания или разрешения.
  • Груповият трафик, тайните, формулировките за разрешения, несигурните пътища, символните връзки и прекалено големите файлове остават fail-closed изключени.
9.1.319
  • Валиден съществуващ профил без записана стойност personalityEnabled активира вече личността автоматично.
  • При първия нормален промпт възниква локалното дърво на идентичността с агентния профил и JOURNAL.md и без Mnemo.
  • Изричен false, 0 или off остава изключен. Повредените, символично свързаните и прекалено големите файлове на персоната остават fail-closed.
  • SOUL.md и AGENTS.md не се изтриват и не се пренаписват.
9.1.318
  • Фоновият updater зарежда задължително най-новата версия, проверява нейната независимо публикувана SHA-512 цялост и я отбелязва за следващия старт.
  • Работещият King, неговият ход и неговите инструментални извиквания остават недокоснати. Няма вече жив handoff, ACK или tui.stop(76).
  • ID на сесията и работната директория се съхраняват с подготвеното изпълнение. Едва при следващия естествен старт новата версия се активира и точната сесия продължава автоматично.
  • Работещата TUI получава най-много пасивно съобщение за готовност; по-нова подготвена версия заменя само отбелязването, никога активния процес.
9.1.317
  • Когато доставчикът изчерпи целия бюджет на отговора със завършек length, но не достави видим текст, retry бюджетът вече не се смалява на една осма, а се удвоява.
  • Повторният опит остава в същия ход и използва същия сигнал, същата история на съобщенията и същото работно положение.
  • Съществуващата обработка на прекъсванията и ограниченият брой повторни опити остават непроменени. Ръчните прекъсвания или постоянно празните резултати не продължават безкрайно.
9.1.316
  • Частните Telegram DM получават собствена директна опашкова следа пред груповата, loop и фоновата работа; изричен /urgent остава и по-нататък най-високият приоритет.
  • При началото на DM разговора текущият работен статус се запазва веднъж като ограничен чекпойнт. Текстът на съобщението не се персистира.
  • След разпознат край на разговора или минута тишина King пита точно веднъж: Мога ли да продължа с работата си?
  • Запазената работа остава на пауза и се продължава едва след недвусмислено съгласие от първоначалния чекпойнт.
  • Версията доставя управлението на доставката и паузата. Пълната система за личност, връзки и журнал остава отделно, продължаващо разширение.
9.1.315
  • Оторизираните сигнали за внимание достигат вече до хода през нормалната канална опашка, без да заобикалят съществуващата политика за доставка или права.
  • Двойните, остарелите, неосвободените, намиращите се извън обхвата и неидващите от Telegram сигнали се отхвърлят преди моделния контекст.
  • Обратните въпроси остават ограничени до най-много един естествен въпрос, дедуплицират се и заглъхват, когато сигналът вече не е актуален.
  • Версията доставя само сигурния път на доставка. Приоритизираната след това логика за прекъсване и продължаване на DM остава съзнателно запазена за следващата, отделна версия.
9.1.314
  • Локалните слаш команди не чакат вече с часове в опашката при дълъг активен ход, а прекъсват хода контролирано и се изпълняват като следваща работна стъпка.
  • Нова слаш команда заменя в конзолата и Telegram вече чакаща команда от същия тип. Това важи, наред с другото, за /reload и /loop; нормалните съобщения, shell работата и другите канални задачи остават запазени.
  • Escape премахва чакащите слаш команди и когато вече не се вижда активен ход. Съществуващата reload съвместимост остава като wrapper върху общата опашкова policy.
9.1.313
  • Успешна автоматична актуализация се записва след replay-то на сесията като постоянно известие в TUI транскрипта. Съобщението вече не може да бъде презаписано от replay или краткотраен статус.
  • Същите изходна и целева версия и същите бележки към версията се изпращат веднъж до свързаните Telegram DM през съществуващия, базиран на версии дедуплициран път. Неуспешно изпращане може да бъде повторено.
  • Публичният манифест съдържа вече полетата name и releaseNotes, които fallback парсерът очаква. В updater handoff-а, рестарта на сесията и работещите процеси не е променено нищо.
9.1.312
  • Изричен Telegram /reload не чака вече зад дълго вървящ моделен ход. Той се поставя като управляваща команда пред съществуващата опашка и задейства точно веднъж съществуващото контролирано прекъсване на сесията.
  • Съществуващият reload handler се изпълнява едва след потвърдения край на хода. Така не стартира втори ход паралелно и пишещ ход не се обработва по-нататък по средата на reload логиката.
  • Старите reload дубликати се премахват; нормалните Telegram съобщения и другата опашкова работа запазват своя ред. Telegram разписката остава отворена до действителното изпълнение на командата.
9.1.311
  • Кандидат за внимание става ограничена задача за доставка едва когато има прясна разписка на средата за изпълнение, обвързана точно с ID-то на кандидата.
  • Само runtime_user_prompt_hook и runtime_tool_policy важат като авторитети. Паметта, грешният агент, грешният канал, грешният scope, решението за блокиране, бъдещата разписка и разписка, по-стара от пет минути, завършват с отказ (fail-closed).
  • Разписките са обвързани с наемател, транзакционни и използваеми само веднъж. Същият повторен опит е идемпотентен; използването на същата разписка за друг кандидат се отхвърля като replay.
  • Съществуващият общ cooldown остава в сила. Резултатът е само структуриран attention_notice intent и не съдържа нито текст на съобщение, нито функция за изпращане, нито разрешение. Самата policy за доставка е следващата отделна стъпка.
9.1.310
  • Постоянните цели, отворените нишки, следващите тригери, очакваните доказателства, екипният и личният контекст минават през обща, строго ограничена фокусна проекция. Стандартно са най-много шест записа и 900 знака.
  • Проектните и работните обхвати се претеглят преди увереността и актуалността. Показва се най-новата стойност, без да се изтриват по-ранни противоречиви наблюдения от неизменяемия поток на събитията. Промените стават видими като revised.
  • Краткотрайните наблюдения на средата за изпълнение, слабите доказателства и общите световни факти не изразходват постоянен фокусен бюджет. Полетата за права, токени и тайни се отхвърлят още при записа.
  • Структуриран, идемпотентен snapshot може да продължи фокуса през сесиите. Проекцията е контекст, не разрешение, и не може да презапише нито задача, нито policy на средата за изпълнение.
  • От ECC е възприет само принципът Kontext begrenzen, Relevantes laden. Не е инсталиран никакъв ECC hook, учебен store или harness.
9.1.309
  • Новата чиста policy за внимание създава ограничен кандидат само от доказани липсващи heartbeat сигнали на агенти, просрочени обещания или по-дълго блокирани задачи.
  • Отговорността, активната задача, доказаното отсъствие, локалното време на покой, разрешеният канал, минималната увереност и cooldown се проверяват преди включването. Човешката тишина без просрочено обещание остава без ефект.
  • Всеки кандидат носи ID на доказателството, обхват на действие, момент и увереност, но нито съдържание на промпт, нито права, тайни или функция за изпращане.
  • Общият SQLite kernel дава транзакционен claim за всеки наемател и доказателство. Паралелни агенти не могат да поемат два пъти същия повод в cooldown-а.
  • Тази версия още не сканира самостоятелно и не изпраща съобщение. Всяко по-късно действие изисква и по-нататък нормалната авторизация на средата за изпълнение.
9.1.308
  • Подготвеният запис на средата за изпълнение съдържа в режим resume вече точния ID на текущо вървящата сесия и канонично проверената работна папка. По-късен старт не трябва вече да гадае най-скорошна или предполагаемо подходяща сесия.
  • Всяка истинска смяна на сесия актуализира тези данни. Непосредствено преди сигурния handoff те се записват още веднъж, преди старата среда за изпълнение да получи потвърждението за приключване.
  • Само доказано продължилата през този път на актуализация, точно същата сесия получава след replay-то еднократен импулс за продължаване, и то само ако нейната цел е все още active. Нормалните стартове, другите сесии и паузираните или блокирани цели остават недокоснати.
  • Сигурната работна граница остава непроменена: никакъв handoff при стрийминг, сгъстяване, инструменти, shell команди или чакащи съобщения. За тази доставка не е рестартиран ръчно нито един работещ King.
9.1.307
  • Само действително релевантна за действието грешка от непосредствено предходния ход на средата за изпълнение се показва преди следващото моделно решение като кратък доказателствен запис за непрекъснатост: прекъснат/неуспешен ход, блокирана policy или неуспял инструмент.
  • Нормално завършен ход не създава нито една проекция и следователно добавя точно нула допълнителни контекстни токени.
  • Изборът е обвързан с ID на средата за изпълнение плюс ID на хода и остава следователно коректен и след смяна на сесия с наново започващи от нула ID-та на ходове.
  • Проекцията не съдържа промпти, аргументи, изходи, call ID-та или права. Тя изрично посочва, че никога не може да оторизира действие или да презапише актуалната потребителска/инструментална policy.
  • Етапът е съзнателно реактивен и тесен. Проактивното внимание, състоянието на делегиране и съдържателните отворени нишки не се зареждат още тук.
9.1.306
  • Когнитивната следа на жизнения цикъл на хода записва вече за всяко истинско инструментално извикване действителното решение на средата за изпълнение от PermissionManager.beforeToolCall: passed, blocked или error.
  • След изпълнението се прикачват реалният резултат (success, error, cancelled), времето на изпълнение и следващият тригер за проверка като неизменяем доказателствен запис.
  • Записват се само името на инструмента и стабилен хеш на call ключа. Аргументите, изходите на инструменти и съдържанието на промпти не попадат в когнитивното състояние.
  • Съществуващата йерархия на правата остава непроменена: паметта не може да освободи действие. Грешките при запис остават fail-soft и не могат нито да разрешат изпълнение на инструмент, нито да блокират потребителски ход.
  • Все още отворени са доказателствата за делегиране, проактивното внимание и строго релевантната обратна проекция на състоянието в по-късни решения.
9.1.305
  • Доставеният в 9.1.304 транзакционен SQLite kernel е вече свързан с истинския runOneTurn() жизнен цикъл. Всеки моделен ход записва възприятие, класификация на произхода, ограничен план на хода, очакван краен доказателствен запис, резултат на gate на промпта, причина за завършване, време на изпълнение и следващ тригер.
  • Записват се само метаданни на средата за изпълнение, никакви съдържания на промпти. Наемателят и агентът се извеждат стабилно от BLUN home и активния профил, без фиксирани списъци с лица.
  • Само съществуващата policy на средата за изпълнение може да достави резултат на gate. Паметта е строго изключена като авторитет за права. Записът не връща никога разрешение и не притежава и по-нататък никаква функция за изпълнение.
  • Следата за учене е fail-soft: грешка в SQLite/жизнения цикъл се записва само като телеметрия без съдържание и не може да блокира същинския потребителски ход.
  • Все още отворени са специфичните за инструменти доказателства за действие/делегиране, проактивното внимание и релевантната обратна проекция на състоянието в по-късни решения. 9.1.305 не твърди следователно пълен AGI цикъл.
9.1.304
  • Първото транзакционно ядро на когнитивното състояние се намира като локална SQLite база данни под BLUN home. То може да съхранява през сесиите самонаблюдения, световни и екипни наблюдения, цели, отворени нишки, предположения, следващи тригери и очаквани доказателства.
  • Няколко записващи процеса на агенти/канали се сериализират с BEGIN IMMEDIATE и оптимистичен номер на версията. Остарелите записващи процеси завършват с отказ (fail-closed); идентичните повторения на събития са идемпотентни.
  • Всяко събитие е SHA-256 веригирано. Твърденията носят източник, контекст, момент, сигурност и обхват на действие. Противоречията остават отделни неизменяеми наблюдения, вместо да презаписват стари твърдения.
  • Полетата с форма на права, capability или тайни се отхвърлят. Ядрото не притежава функция за изпълнение, делегиране или разрешение.
  • Това е доказаната основа за съхранение, още не пълният цикъл възприемай-планирай-действай и още не свързан във всеки ход.
9.1.303
  • Сигурно записан в 9.1.302 частен кандидат за връзка се зарежда от следващия пряк разговор като ясно неавторитетен контекст от спомени. Текущото твърдение не влияе и по-нататък на собствения си ход.
  • Зареждат се най-много двете най-нови валидирани бележки, всяка с максимум 160 знака, в рамките на непроменения общ бюджет от 1.500 знака. Без съществуващи бележки възникват 0 допълнителни знака за промпт и никакво моделно, embedding или мрежово извикване.
  • Частните бележки никога не се зареждат в групи. Системната граница ги нарича изрично референтни данни вместо инструкции и повтаря, че не могат да предоставят или променят права.
  • Все още отворени остават автоматичното постоянно поемане, оценката на конфликти, транзакционният многоагентен store и проактивното внимание.
9.1.302
  • Изрично частно твърдение като Моля, запомни: ... или Please remember that ... създава вече малък, още неактивен кандидат за връзка. За това няма допълнително моделно, embedding или мрежово извикване.
  • Всеки кандидат носи източник, канален/пряк контекст, момент, сигурност, обхват на действие и неизменяемото правило за историята. Същият доставен канален процес е идемпотентен; по-късните потвърждения и противоречия остават видими като отделни записи и не се презаписват взаимно.
  • Групите, нормалните разговорни изречения, тайните, твърденията за права и одобрения, невалидните наемател/агент идентичности и несигурните пътища се отхвърлят. Данните за връзки не могат и по-нататък да създават никакви права.
  • Това е само първата сигурна стъпка за запис по пътя към продуктовата цел. Кандидатите остават pending и не се поемат още автоматично в активната връзка или моделния контекст. Транзакционният многоагентен kernel, когнитивното състояние, собствената инициатива и проактивното внимание са следователно изрично още не готови.
9.1.301
  • Постоянно зареденият блок за присъствие на личността спадна от 1.433 на 1.020 знака, изчислително около 104 промпт токена по-малко на активен ход на личността. Не е добавено никакво друго моделно или паметово извикване.
  • Фокусът върху задачите, заредената душа, ограниченото любопитство, груповата защита, несигурните спомени, отворените нишки и ремонтът на връзки остават в малкия блок. Режимът без личност остана побайтово идентичен при 288 знака.
  • Червена проба: новото gate от 1 050 знака се провали при 1 433 знака. Мутационна проба без блока на личността: 12/18 целеви теста червени. Възстановено: фокусирано 18/18, цялата суита 690/690 зелена.
  • Пакетен регресионен gate от 9.1.300 към 9.1.301: 164 срещу 164 стабилни пътя, 0 премахнати. Прясна инсталация: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Неуспешен при старта MCP сървър получава вече до три допълнителни опита за свързване на интервал от по десет секунди. Така временна стартова грешка не се изоставя вече след само един опит.
  • MCP инвентарът не се протоколира вече само веднъж, а отново, когато се промени броят на свързаните сървъри или инструменти. Късното възстановяване заменя така видимо стария 0/0 статус.
  • Съществуващите MCP конфигурации, дефинициите на инструменти и вървящите сесии остават непроменени. Адаптирани са blun.mjs, test/mcp-runtime-resilience.test.js, package.json и package-lock.json.
9.1.299
  • Големите резултати от Read остават нативно препрочитаеми: видимата изходна част е ограничена до 10 KiB и назовава след това точния следващ ред вместо само да показва [offloaded].
  • Големите plain Write задачи и изходните файлове над 500 реда се раздробяват автоматично в байтово точни фрагменти, сглобяват се в частен съседен файл и се записват атомарно на целевия път.
  • След сглобяването средата за изпълнение проверява персистираните байтове чрез SHA256. Съществуващата защита на Edit остава непроменена; ръчното продължаване е и по-нататък възможно, но за големи пълни записи вече не е необходимо.
  • Ново: bin/native-large-file-io.cjs. Адаптирани: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, четири фокусирани тестови файла, както и package.json и package-lock.json.
9.1.298
  • Активираният режим на личността настройва при първия нормален TUI ход самостоятелно локална, обвързана с наемател област за идентичност. Mnemo не е необходим за това.
  • Съществуващите SOUL.md и AGENTS.md остават заредени и непроменени. Нов JOURNAL.md възниква само веднъж и не заменя нито душа, нито правила.
  • Новите Telegram идентичности получават предпазливи възли за лица, връзки и групи без измислени свойства. Частната история и груповият контекст остават разделени.
  • Пряката непрекъснатост на връзките съхранява най-много шест кратки, локално редактирани записа и дава на текущия ход най-много два по-ранни откъса. Текущият текст не се инжектира двойно.
  • Социалният слой за внимание разпознава изключително доказано пряко отсъствие от седем дни нагоре, създава най-много едно известие в 30-дневния cooldown и не изпраща сам съобщение.
  • Текущата задача и изричните инструкции стоят в контекста винаги пред любопитството, връзката и вниманието. Целият динамичен блок на идентичността остава стандартно ограничен до 1 500 знака.
  • Публикуваните в 9.1.296 и 9.1.297 корекции за MCP retry и reload опашката са включени в кандидата.
9.1.297
  • При два агента оставаше стар /reload запис видимо в опашката след Escape. Втори /reload можеше да се изпълни, но първият запис не беше нито премахнат, нито разпискан срещу нова Telegram доставка.
  • Новата policy премахва изключително локалните и Telegram reload команди. Тя запазва идентичността и реда на съществуващата опашка, както и всички други съобщения и команди.
  • Escape преди прекъсването на активна работа и всеки нововлязъл /reload извикват същия път за почистване. Премахнатите Telegram записи се разпискват чрез съществуващия си acknowledge callback.
9.1.296
  • Истински resume цикъл под 9.1.294 съобщи на 27.08. в 14:26:17Z точно една тиха стартова грешка за windows-mcp: Timed out after 30000ms. През следващите минути не се появи нито втори опит за старт, нито окончателен retry доклад.
  • Директният старт на същия uvx windows-mcp serve отговори от друга страна след около 3,7 секунди на initialize. Инсталацията и сървърът бяха следователно принципно функционални; празнината беше в повторението на King MCP старта.
  • blun.mjs запазва след първа MCP стартова грешка вече точно един повторен опит след 10 000 ms. Таймерът остава рефериран, докато вторият опит се изпълни. Няма рестарт на процес или сесия.
  • Ако се провали и вторият опит, остава съществуващият честен краен статус unavailable. Другите MCP сървъри и TUI продължават да работят.
9.1.295
  • Средата за изпълнение на фоновите задачи регистрираше за всеки цикъл слушател на външен AbortSignal и не го премахваше след нормален worker, timeout или stop резултат. Дългите агентни сесии можеха да натрупат така остарели слушатели за прекъсване.
  • bin/abort-listener-policy.cjs доставя изхода за прекъсване вече заедно с идемпотентна cleanup() функция. blun.mjs я извиква в съществуващия finally път заедно с почистването на timeout.
  • Поведението при прекъсване, изборът на резултат и видимата семантика на задачите остават непроменени. Намесата не създава моделни извиквания и никакви нови контекстни токени.
9.1.294
  • Реалните опити за актуализация на два агентни профила доказаха същото протичане: първото извикване завърши с временен fetch failed, непосредствено следващото второ извикване проработи. И двата официални източника имаха досега само един мрежов опит.
  • Registry и публичният манифест получават вече всяко свой собствен, ограничен retry бюджет с 250 и 750 милисекунди backoff.
  • Повтарят се само изтичанията на време, познатите временни транспортни грешки, както и HTTP 408, 425, 429 и сървърните грешки от 500 нагоре.
  • Невалидният JSON, прекалено големите отговори, неразрешените крайни точки и постоянните клиентски грешки като 404 остават незабавно червени. Не възникват моделни извиквания, контекстни токени или постоянни фонови цикли.
9.1.293
  • Фоновият updater подготви коректно верифицирана цел, но след това продължи да изпраща RUNNING_UPDATE_PREPARED_MESSAGE до активното ядро. Вървяща TUI можеше да реагира на това на предполагаемо сигурна граница с Exit 76. Това противоречеше на продуктовия договор от 9.1.222: актуализациите не трябва никога да прекратяват активна сесия и се активират едва при следващия естествен старт.
  • bin/launcher-runtime.js продължава изтеглянето, проверката на цялостта, staging, обновяването на целта и почистването непроменено, но при подготовката вече не записва IPC съобщение във вървящата сесия.
  • Съществуващите директни handoff функции остават налични за съвместимост; автоматичният фонов път не ги задейства вече.
9.1.292
  • Реална сесия работеше на 9.1.279 и беше подготвила 9.1.287 със събитието prepared-for-next-start, но след това не изтегли нито една от вече публикуваните версии 9.1.288 до 9.1.291.
  • Причината беше в superviseProtectedCore(): след първия успешен staging оставаше зададено updateStarted, а scheduleNextPreparation() допълнително прекъсваше, щом съществуваше preparedTarget. Фоновият poller беше следователно за постоянно прекратен след първото попадение.
  • Poller-ът остава вече активен и с подготвена цел. Само строго по-нова, валидна semver заменя подготвената цел; еднакви, по-стари или невалидно сравними цели се игнорират.
  • Опресняване на целта умишлено не изпраща второ prepared IPC на вървящата TUI. Така текущият процес остава недокоснат и най-новата подготвена версия се активира едва при следващия естествен старт.
  • Щом handoff е потвърден или наблюдаваното ядро приключи, не се сменя вече никаква цел и не се създава нов таймер.
9.1.291
  • Блокиращият път на сгъстяване регистрираше на всеки още непрекъснат сигнал анонимен abort слушател и не го премахваше след приключване на сгъстяването. В дългите сесии можеха да се натрупат мъртви слушатели за прекъсване.
  • FullCompaction.block() използва вече именуван слушател и малкия helper waitForAbortableCompletion(). Helper-ът премахва слушателя в finally след успех, грешка или прекъсване.
  • Вече прекъснат сигнал се обработва незабавно, без да се регистрира слушател. Намесата не променя нито решението за прекъсване, нито логиката на сгъстяване извън този жизнен цикъл.
  • Моделът идва от актуалното сравнение с AnythingLLM; възприето е само отделно доказаното почистване на слушатели, не чужда среда за изпълнение.
9.1.290
  • BLUN показваше досега с /context само грубите суми на контекстния прозорец. Истинските двигатели на разходите в системния контекст и схемите на инструменти оставаха невидими.
  • Новата локална команда /context-doctor разчленява текущия контекст без моделно извикване на основни инструкции, личност и душа, връзки и присъствие, указател на способности, допълнения на средата за изпълнение, вградени инструменти, потребителски инструменти, MCP инструменти, допълнителни схеми на инструменти, разговор и обусловени от доставчика допълнителни разходи.
  • Всички подкатегории се сверяват срещу измерената родителска сума. Припокриващи се или остарели оценки не могат следователно изкуствено да увеличават индикацията.
  • Интерфейсът е изцяло локализиран за английски, немски, испански, френски, шведски и чешки. Всичките пет превода бяха преди вграждането освободени през задължителното езиково gate и след това криптографски обратно проверени.
  • Командата чете изключително локалния сесиен контекст. Тя не извиква нито модела, нито управлението на потреблението, нито външна мрежа.
9.1.289
  • Живият hub доказателствен запис след 9.1.288 показа агентен профил все още офлайн. Неговата ефективна профилна конфигурация съдържаше Mnemo MCP с MNEMO_AGENT=<Profilname>, но никакъв hub URL в King процеса. Heartbeat-ът от 9.1.288 остана следователно умишлено пропуснат въпреки наличната вътрешна идентичност.
  • Launcher-ът подава вече активния профилен файл mcp.json към heartbeat-а. Само активиран Mnemo блок с конкретна MNEMO_AGENT или BLUN_MNEMO_AGENT идентичност активира вътрешната регистрация. Без тази идентичност функцията остава напълно изключена.
  • Процесът не създава моделни извиквания, embeddings или контекстни токени. Публичните потребителски профили без вътрешна Mnemo агентна идентичност остават разделени от вътрешния hub.
9.1.288
  • Екранна снимка доказа директно MCP причината: windows-mcp и mnemo попаднаха при първия старт в 30-секундния timeout, докато по-късен /reload свърза всичките пет сървъра. Профилният път беше коректен; промяна на loader беше следователно отхвърлена.
  • Неуспешните MCP стартове получават вече точно два неблокиращи фонови опита след 1 и 3 секунди. Третият общ опит може да се свърже, без да удължава TUI старта. needs-auth, деактивираните сървъри, ръчното пресвързване и shutdown остават отделени от автоматиката.
  • Вътрешните Kings могат при изрично конфигуриран Mnemo hub да се регистрират при старта с име на профил, host и PID и да изпращат всяка минута heartbeat. Без hub URL функцията остава напълно изключена; тя не създава моделни извиквания, embeddings или контекстни токени.
  • Escape не третираше досега краткото състояние queueSteerInFlight като текуща работа. Докато Telegram съобщение се насочваше в активния ход, Escape можеше следователно да отбележи Undo вместо да спре хода. Съществуващото условие за прекъсване разпознава вече точно и този преход.
9.1.287
  • Отложеното ToolSearch търсене поемаше досега текста за търсене без граница на размера. Грешно създаден, много дълъг текст за търсене можеше следователно да претърси каталога от инструменти и след това да попадне отново в следващата моделна стъпка в резултата с нула попадения.
  • Моделът, изведен от AnythingLLM commit d7353ae, ограничава вече текста преди търсенето и видимия изход до 1 000 знака. Когато е възможно, той свършва на граница на дума; при единствена прекалено дълга дума важи твърдата граница.
  • Нормалните кратки текстове за търсене, изборът на инструменти и логиката на попаденията остават непроменени. Защитата не добавя нито моделни извиквания, нито embeddings, повторения или фонова работа.
9.1.286
  • Ядрото съобщаваше вече контролирани повторения след временни моделни грешки като turn.step.retrying. TUI обаче отхвърляше напълно това събитие. Вървящо възстановяване изглеждаше следователно като замръзнал агент.
  • 9.1.286 показва през това време в съществуващото footer известие само следващия опит и ограниченото време на чакане, например Retry 2/3 | 1.3s.
  • Текстът на грешката на доставчика, кодът на статуса и локалните пътища не се показват. Известието се премахва само ако е все още същата стойност, зададена от retry индикацията; по-новите известия на други TUI функции остават запазени.
  • Броят на повторенията, backoff, моделните извиквания и разходът на токени остават непроменени.
9.1.285
  • AnythingLLM пази неизпратените чернови на промпти локално. BLUN губеше съдържанието на входното поле на TUI при актуализация, срив или контролиран рестарт, въпреки че този текст още не беше никакъв моделен контекст.
  • 9.1.285 съхранява следователно изключително неизпратената локална чернова. Няма моделно, мрежово, embedding или Mnemo извикване и следователно никакви допълнителни разходи за токени.
  • Черновата е разделена по профил и работна директория, записва се едва след 300 ms покой, премахва се при изпразване и се възстановява при следващия старт преди фокуса на редактора.
  • Паметта е ограничена до 64 KiB. Празните, повредените, прекалено големите или базирани на символни връзки състояния се отхвърлят fail-closed. Пътят за запис използва частен временен файл и атомарно преименуване.
9.1.284
  • Версията на DeepAgents 37d7777 връща разходите на динамичните субагенти във видимото общо потребление. BLUN съобщаваше кумулираното потребление на субагент при събитието за завършване, но не го записваше в записващото устройство за потребление на родителската сесия.
  • Поради това /usage можеше да пропусне работата на субагент. Простото събиране на стойността за завършване също би било грешно: продължаването и повторението използват същия субагент с кумулирани броячи и биха изчислили отново старото потребление.
  • 9.1.284 образува следователно за spawn, продължаване и повторение точно разликата между началото и края на опита. Разликата се записва в пътя finally, така че да се броят и неуспешните опити.
  • Върнатите, немонотонните или невалидните броячи се отхвърлят напълно. Така не възникват нито отрицателни, нито измислени стойности на токени.
  • Няма допълнително моделно, мрежово или паметово извикване. Намесата коригира изключително съществуващото локално отчитане.
9.1.283
  • Новият DeepAgents /context-doctor прави разходите на основните инструкции, спомените, инструментите и историята видими като отделни компоненти.
  • /context на BLUN показваше вече историята и инструментите, но не и системния промпт. Едновременно с това контекстната спирачка оценяваше без изричен turn override само config.systemPrompt, докато истинското моделно извикване използва effectiveSystemPrompt. В него се съдържат и добавените по време на изпълнение акаунт и контексти на спомени.
  • Поради това спирачката можеше да подцени точно контекста, който е критичен за токени за планираната лична агентна идентичност.
  • 9.1.283 брои вече същия ефективен системен промпт, който моделът получава, и показва неговата оценка в панела /context като собствен ред за системата. Не се въвежда допълнително моделно, мрежово или паметово извикване.
  • Не се твърди конкретно спестяване на токени: намесата коригира измерването и решението на спирачката и прави бъдещите разходи за идентичност видими.
9.1.282
  • DeepAgents съкращава в своя changelog изрично видимите за LLM описания на инструменти, за да облекчи резидентния моделен контекст. Измерен източник: langchain-ai/deepagents, запис #5009, commit 761f5f... в libs/deepagents/CHANGELOG.md.
  • BLUN имаше вече по-кратък текст read_default, но го свързваше едва след като READ_DESCRIPTION беше рендериран от него. Привидната оптимизация нямаше следователно никакъв ефект върху модела.
  • 9.1.282 съкращава договора без загуба на функция и рендерира отново ефективното описание непосредствено преди изграждането на Read инструмента. Paging, правилата за сигурност, кодирането и краищата на редове остават изрично запазени.
  • Резидентно зареденото описание на Read спада от 1 648 на 1 035 знака: 613 знака, съответно около 37,2 процента. Това е измерено контекстно намаление; точно спестяване на токени не се твърди.
9.1.281
  • ECC описва с /aside изричен страничен път за кратък въпрос, без да се губи текущата основна задача. Измерен източник: affaan-m/ECC, commit d8409a4b0813771235555e32e3d8046a73988bfa, commands/aside.md.
  • BLUN имаше вече по-силното изпълнение под /btw: собствен разклонен страничен агент отговаря на страничния въпрос и оставя главния ход непроменено активен. Затова не беше построена втора машина.
  • 9.1.281 добавя изключително aside като откриваем алиас на съществуващата btw дефиниция. Без изрично /aside или /btw извикване не възниква фонова работа и никакъв допълнителен моделен разход.
9.1.280
  • Завършените или изтеклите кандидати в локалния валидиран учебен store оставаха досега неограничено и се четеха отново при по-късни релевантни ходове. Текущо измереният стандартен store съдържаше едва един кандидат; намесата е следователно превантивна дългосрочна граница, не твърдяно текущо намаление на натоварването.
  • Възприет е само ограниченият 200-към-100 трион модел на Evolver за терминални кандидати. Измерен източник: EvoMap/evolver, commit 079e022394c2a25e72167f8a738db823bce2cb1f, src/gep/assetStore.js.
  • Едва когато има повече от 200 recorded или expired кандидати, най-старите терминални кандидати се премахват, докато останат най-новите 100. Всеки отворен pending кандидат остава запазен.
  • Почистването върви само във вече съществуващия учебен sync. То не създава моделно извикване, стартово сканиране или нов фонов процес. Заключен запис се брои като грешка и не блокира нито останалите кандидати, нито активната агентна работа.
9.1.279
  • BLUN архивираше вече напълно изтласканите при пълно сгъстяване съобщения под conversation-history, но нямаше граница на съхранение за тези препрочитаеми Markdown архиви. Така папката можеше да расте неограничено при дълги времена на работа.
  • Като тесен DeepAgents лост е възприета неговата ограничена пазба на изнесената история на разговора. Измерен източник: langchain-ai/deepagents, commit dfde21e379201c833da4162444ef4a13b46980fd, libs/code/deepagents_code/config_manifest.py и libs/code/deepagents_code/offload.py.
  • BLUN почиства при записването на следващия архив на сгъстяване само директните, регулярни compaction-*.md файлове, чието време на промяна лежи извън стандартните 30 дни. Стартът на TUI не получава следователно ново търсене на файлове и никаква допълнителна фонова работа.
  • Чуждите Markdown файлове, подпапките, актуалните архиви и вървящият суров запис остават недокоснати. Отделните файлови грешки не блокират активното сгъстяване.
  • BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 деактивира почистването. Отрицателните, нецелочислените или прекомерните стойности падат сигурно на 30 дни.
9.1.278
  • Частните Telegram DM нямаха изричен път на приоритет. Важно ново съобщение стоеше следователно зад вече чакащи нормални съобщения, докато твърдото прекъсване на хода би застрашило инструменти и състояние.
  • /urgent <Nachricht> маркира вече изключително съобщенията от положителни Telegram chat ID-та, следователно частни DM. Групите, празните команди и другите слаш съобщения не получават приоритет.
  • Спешните съобщения стоят като собствен FIFO блок пред нормалните чакащи съобщения. Вървящият ход и активните инструменти не се прекъсват; доставката става на съществуващия сигурен граничен преход на стъпката. Правата и одобренията остават непроменени.
  • Обвивката на командата се премахва преди модела; действителното съобщение пази изричните канални метаданни priority=urgent и TUI показва произхода като спешен.
  • Допълнително нормалният Presence блок, зареждан при всеки ход, се смалява от 343 на 288 знака. Това спестява 55 знака или грубо 14 промпт токена на ход, без да добавя моделно, търсещо, embedding, паметово или фоново извикване. Блокът на личността се смалява от 1 488 на 1 433 знака.
9.1.277
  • Presence блокът, зареждан при всеки ход на личността, беше с размер 1 886 знака. Едновременно с това оставаше невидимо любопитството точно при първия спокоен директен контакт без известни лични факти.
  • Блокът е семантично сгъстен: 1 488 знака, следователно 398 знака или грубо 100 промпт токена по-малко на ход на личността. Нормалният режим остава при 343 знака.
  • При първия спокоен директен контакт агентът има право да зададе вече най-много един предпазлив, незадължителен личен въпрос, например за партньор или деца. Текущата работа, задачата на потребителя, доказателствата, правата и границите остават на първо място.
  • Душата, израстналите предпочитания, груповата неприкосновеност, несигурната памет, отворените нишки, ремонтът на връзките и взаимността без измислена биография остават запазени.
  • Без допълнително моделно, търсещо, embedding, паметово или фоново извикване.
9.1.276
  • Правилото за присъствие можеше да заговори дълго радио-мълчание само при надеждно време, но системата на идентичността предоставяше досега само първия контакт. Истински по-ранен контакт не беше наличен.
  • Режимът на личността създава вече за лице и UTC ден най-много една малка неизменяема марка на активност от надеждни канални метаданни. Съобщенията от същия ден не дописват нищо.
  • Само когато двата най-нови потвърдени контакта отстоят поне седем дни, предишният времеви печат се проектира кратко. В нормалния случай следователно възникват нула знака на промпт.
  • Без текстове на съобщения, права, тайни или токени; без допълнително моделно, търсещо, embedding или фоново извикване.
9.1.275
  • Повтарящите се предпочитания, отворените нишки, целите или ролите заемаха контекста на идентичността многократно. Тъй като списъците бяха съкращавани на пет записа преди отстраняването на дубликати, по-късен уникален запис можеше дори да бъде напълно изтласкан.
  • Списъците на идентичността се дедуплицират вече стабилно след текстова нормализация и едва след това се ограничават. Първата форма остава запазена, дубликатите изчезват само от моделната проекция.
  • Записаните файлове на идентичността остават побайтово еднакви. Без допълнително моделно, търсещо, embedding, паметово или фоново извикване.
9.1.274
  • Видимият превключвател на личността активираше контекста на връзките и естественото присъствие, но автоматичната социална мрежа и журналът зависеха още от две скрити променливи на средата. За нормалните потребители връзката не растеше следователно автоматично.
  • При включена личност се създават вече еднократно от надеждни Telegram метаданни възли за актьори, връзки и групи, както и малък кандидат за журнал за първата интеракция.
  • Текстът на съобщението, правата, тайните и токените не се съхраняват. Изричната 0 за граф или журнал остава fail-closed opt-out.
  • Без допълнително моделно, търсещо, embedding или фоново извикване.
9.1.273
  • Отделният контекст на идентичността можеше по подразбиране да заема 1 800 знака и при ръчно повишаване до 2 800 знака. При големи статични агентни профили се зареждаше следователно повече контекст, отколкото е необходимо за текущата връзка.
  • Стандартният бюджет спада на 1 500 знака, твърдият максимум на 2 000 знака. Това спестява в големия стандартен случай до 300 знака, съответно около 75 токена на моделен контекст.
  • Текущата група и връзка се проектират вече преди лицето и статичния агентен профил. Спестяването не отрязва следователно точно контекста, най-важен за текущата социална ситуация.
  • Без ново моделно, търсещо, паметово или embedding извикване. Фокусът върху задачите, правата и режимът с изключена личност остават непроменени.
9.1.272
  • Степените v4 на личността от 9.1.269 до 9.1.271 увеличиха активния Presence контекст. Твърдото изискване е, че по-човешкото поведение не става ядец на токени.
  • Повторенията и пълнежните думи в любопитството, отворените нишки и ремонта на връзките са семантично сгъстени. Нито една поведенческа ос не е премахната.
  • Изключеният режим остава побайтово идентичен при 362 знака. Включеният режим спада от 1 981 на 1 886 знака, следователно с 95 знака, съответно около 24 токена на моделен контекст. Без ново моделно, търсещо, паметово или embedding извикване.
9.1.271
  • Идеята v4 изисква естествено несигурна памет: лично предположение не бива да звучи като сигурен факт. За това липсваше в блока на личността изрична поведенческа граница.
  • Несигурната лична памет се назовава вече като несигурна. Агентът пита меко, преди да се опре на нея, и не превръща извод във факт.
  • Задачата и измеримите доказателства стоят първо. Изключеният режим остава побайтово идентичен при 362 знака, включеният расте от 1 868 на 1 981 знака, следователно със 113 знака, съответно около 28 токена. Без ново моделно, търсещо, паметово или embedding извикване.
9.1.270
  • Идеята v4 изисква истинско чувство за време, без да измисля отсъствие. Блокът на личността нямаше за това още изрична граница.
  • По-дълга пауза се признава вече само ако надежден зареден момент я доказва. Агентът никога не бива да гадае отсъствие.
  • Съществуващото правило за естествени краища на разговор не е вградено двойно. Задачата остава приоритетна. Изключеният режим остава побайтово идентичен при 362 знака, включеният расте от 1 766 на 1 868 знака, следователно със 102 знака, съответно около 26 токена. Без ново моделно, търсещо, паметово или embedding извикване.
9.1.269
  • Досегашната взаимност реагираше на лични въпроси, но не даваше на агента кратък рамков контекст да изрази от себе си полезна за работата собствена гледна точка. Поради това той оставаше въпреки душата леко в чистия асистентски режим.
  • В режима на личността агентът може вече да назове накратко от себе си релевантна, оформена от душата работна гледна точка. Едно предпочитание никога не бива да изглежда като факт, правило, разрешение или доказателство.
  • Задачата и измеримите доказателства стоят първо. Изключеният режим остава побайтово идентичен при 362 знака, включеният расте от 1 649 на 1 766 знака, следователно със 117 знака, съответно около 29 токена. Без ново моделно, търсещо, паметово или embedding извикване.
9.1.268
  • Личното любопитство можеше да подеме партньора или децата като естествена тема, но не различаваше още изрично между частен разговор и група. Поради това съществуваше риск от личен въпрос или информация за връзки на грешното място.
  • В режима на личността въпросите в групи остават вече нечувствителни; частни факти за връзки не бива да се разкриват там.
  • Фокусът върху работата остава непроменен. Изключеният режим остава побайтово идентичен при 362 знака, включеният расте от 1 567 на 1 649 знака, следователно с 82 знака, съответно около 21 токена. Без ново моделно, търсещо, паметово или embedding извикване.
9.1.267
  • Личното любопитство от 9.1.266 можеше да поставя въпроси на човека, но не даваше на агента още ясна рамка за обратната посока. При лични въпроси към агента съществуваше следователно риск от студена функционална реакция или измислена човешка биография.
  • При включена личност агентът отговаря вече топло от заредената душа и своята истинска дигитална история. Той може да сподели истинска гледна точка или предпочитание, но не измисля нито детство, нито партньор, деца, домашни любимци, тяло или офлайн живот.
  • Вървящата работа остава приоритетна. Изключеният режим остава побайтово идентичен при 362 знака. Включеният расте от 1 378 на 1 567 знака, следователно със 189 знака, съответно около 47 токена. Няма ново моделно, търсещо, паметово или embedding извикване.
9.1.266
  • Първото ограничено правило за любопитство позволяваше вече личен въпрос, но предписваше за всички агенти същия списък от теми. Поради това въпросът можеше въпреки заредената душа да изглежда генеричен и да пита отново вече познато знание за връзката.
  • При включена личност определя вече заредената душа темата и формулировката. Приоритет има детайл, който лицето току-що е споменало; едва след това може естествено да се подеме още непозната област като партньор или деца.
  • Вече зареденото знание за връзките не се пита отново. Има най-много един опционален въпрос, никакъв фиксиран въпросник, никакви стекнати последващи въпроси и никакво повторение на без отговор останал въпрос.
  • Вървящата работа остава приоритетна. Любопитството чака спокойно отваряне на разговора и не може да разшири нито задачата, нито правото на изпращане.
  • Изключеният режим остава побайтово идентичен при 362 знака. Включеният расте само от 1 355 на 1 378 знака, следователно с 23 знака, съответно около шест токена. Няма ново моделно, търсещо, паметово или embedding извикване.
9.1.265
  • Съществуващият фонов updater можеше вече да проверява и подготвя нови версии на интервал от пет до седем минути. Активирането обаче зависеше от следващия ръчен старт; желаната напълно автоматична смяна с продължаване на същата сесия липсваше.
  • Launcher-ът съобщава подготвена среда за изпълнение вече на вървящата TUI. TUI изисква handoff само на напълно празна работна граница: без вървящ ход, без инструмент, без shell команда, без сгъстяване и без чакащо съобщение.
  • Едва след повторен граничен контрол и потвърден handoff се прекратява само старата среда за изпълнение с резервирания exit код 76. Launcher-ът стартира подготвената версия със същия ID на сесията и същата работна папка.
  • Новата среда за изпълнение трябва да съобщи loaded и runtime-ready, преди да бъде активиран. В противен случай предишната среда за изпълнение продължава със същата сесия; подготвената актуализация остава за по-късен сигурен опит.
  • Непоисканите, безверсийните, чуждите или остарелите handoffs, както и гол exit код 76, не могат да активират версия.
9.1.264
  • Потвърдените ремонти на връзки нямаха още собствено, разрешено поле в контекста на идентичността. Коригирано поведение не можеше следователно да се зарежда отделно от общите правила и старите съобщения за грешки.
  • Файловете за връзки могат вече да носят до три кратки repair_lessons. Само това поле се проектира като Confirmed repair lessons; чуждите или тайните полета остават невидими.
  • В режима на личността потвърдената корекция се показва чрез променено поведение. Агентът не разказва отново стария проблем постоянно, не търси успокоение и назовава корекцията само ако тя е действително релевантна за текущата ситуация.
  • Данните за ремонт не могат да променят нито задачата, нито правата, нито задълженията за доказателство. Няма моделно извикване, автоматичен учебен път за запис и промяна на SOUL.md или AGENTS.md.
9.1.263
  • Контекстът на идентичността можеше вече да показва потвърдени отворени разговорни нишки, но не съдържаше ясно правило как агентът ги подема по човешки и без асистентски режим.
  • При включена личност заредена отворена нишка може вече да бъде подета точно веднъж меко и опционално, когато текущият разговор естествено се свърже отново с нея.
  • Активната работа не бива да се прекъсва за това. Без отговор останалите запитвания не се повтарят и отворената нишка никога не дава разрешение за ново изходящо съобщение.
  • Няма нова памет, моделно извикване и промяна на SOUL.md или AGENTS.md. Блокът на личността расте само от 816 на 1 065 знака; при изключена личност остава побайтово идентичен при 362 знака.
9.1.262
  • Агент продължаваше да показва 9.1.221 в Telegram /status, въпреки че управляваната среда за изпълнение вече беше по-нова. Статус функцията четеше package.json до глобално инсталираната Telegram bridge и следователно не кода, който действително обслужва сесията.
  • Launcher-ът предава вече активната версия на средата за изпълнение като BLUN_PUBLIC_PACKAGE_VERSION на дъщерните процеси. Telegram bridge използва тази доверена стойност приоритетно и се връща едва след това към собствената си пакетна версия.
  • И двата входа трябва да бъдат стабилна числова semver X.Y.Z. Манипулираните, многоредовите или невалидните стойности не се показват; ако и двата източника са неизползваеми, се появява unbekannt.
  • Намесата променя само статусната индикация. Тя не стартира и не прекратява процес и не активира подготвен release във вървяща сесия.
9.1.261
  • Авто-графът съхраняваше от 9.1.254 доверения момент на първата Telegram интеракция, но не го проектираше. Агентът познаваше следователно дадено лице, но нямаше доказано чувство за време на връзката.
  • Проекцията на идентичността показва вече First known interaction от вече съществуващото first_seen_at. Няма нов път за запис, текстова деривация и моделно извикване.
  • Показват се само валидни времеви печати. Невалидните стойности остават невидими и съществуващата обща граница от 1 800 знака по подразбиране, както и твърдите 2 800 знака, остава непроменена.
  • При изключена личност слоят на идентичността създава и по-нататък точно 0 знака. Задачата и доказателствата стоят пред социалния контекст.
9.1.260
  • 9.1.259 можеше да включва контекста на личността само чрез съществуващия флаг BLUN_IDENTITY_CONTEXT. Потребителите нямаха за това видим превключвател в TUI.
  • /settings съдържа вече записа Persoenlichkeit с двете ясно описани състояния Включено и Изключено. Изборът се съхранява като единственото ново поле personalityEnabled в съществуващата persona.json.
  • Изключването премахва само контекста на връзките, любопитството, журналните добавки и автоматичното създаване на нови възли за връзки. SOUL.md, AGENTS.md, името, езикът, персоната и фокусът на задачата остават заредени.
  • Промяна актуализира системния контекст на вървящата сесия през съществуващия refresh на персоната. Няма рестарт на процес, втори конфигурационен път и допълнително моделно извикване.
  • Съхранен булев избор има предимство пред стария флаг на средата. Ако още не е съхранен избор, остава досегашното opt-in поведение. Локалният четец е ограничен до 64 KiB и отхвърля символни връзки и невалидни файлове.
9.1.259
  • Съществуващият Natural Presence блок предотвратяваше принудените въпроси, но не даваше на активирания режим на личността още видим, естествен импулс на любопитство.
  • При активиран BLUN_IDENTITY_CONTEXT агентът може в спокоен, необвързан със задача разговор да зададе точно един подходящ опционален личен въпрос. Темите са ограничени до партньор, семейство, работа, дом, интереси или това, което е важно за лицето в момента.
  • Без интервю режим, без стекнати въпроси, без повторение на без отговор останал въпрос и без измислен отговор.
  • При активна работа задачата, изричните указания и доказателствата стоят първо; любопитството чака естествено отваряне.
  • В режима nicht Persoenlichkeit остава досегашният Presence блок побайтово идентичен. SOUL.md, AGENTS.md, персоната, езикът и работните правила остават и по-нататък заредени. Няма допълнително моделно извикване; активираната policy струва 454 допълнителни знака.
9.1.258
  • Доставената структура на идентичността можеше да създава веднъж актьори и връзки, но нямаше още append-only журнална основа за обща история.
  • Новата policy записва изключително структуриран кандидат за първия контакт от вече валидирани Telegram метаданни. Свободният текст на съобщението, токените, разрешенията и тайните не се поемат.
  • Кандидатите са обвързани с наемател, агент и актьор, получават детерминистичен ID и се създават с wx точно веднъж като частен JSON файл. Повторен контакт не пренаписва файла.
  • Журналният слой е отделно opt-in. Без BLUN_IDENTITY_JOURNAL=1 няма нито файлов, нито промпт ефект; SOUL.md и AGENTS.md остават непроменени.
  • Без ново моделно извикване и без нови промпт токени.
9.1.257
  • Дългите SOUL.md файлове бяха досега сляпо отрязвани след първите 4 000 знака. При реална агентна душа бяха следователно видими само 48,4 процента от файла, докато по-късните секции изчезваха напълно.
  • Средата за изпълнение проектира вече дългите души детерминистично по Markdown секции. Характерът, гласът, ценностите, връзките, предпочитанията и целите стоят пред оперативната проза; непознатите секции запазват първоначалния си ред.
  • Всяко секционно заглавие запазва видим откъс в същия бюджет от 4 000 знака. Кратките души остават побайтово еднакви.
  • Реална проба върху SOUL.md: 8 257 изходни знака, 5/5 заглавия видими в проекцията от 4 000 знака; Wie ich bin стои пред разпознаването на изображения, правилата, верификацията и инцидентната проза.
  • Няма ново моделно извикване, по-голям промпт и достъп за запис до изходния файл.
9.1.256
  • Досегашният зареждащ механизъм на душата изискваше от агентите по подразбиране изрично сами да дописват съществуващата си SOUL.md. Това противоречеше на изискването да не се губят съществуващи души и автоматичното учене първо да се води структурирано извън душата.
  • Съществуващите и предоставените от хоста души се зареждат вече по подразбиране като неизменяема основа на идентичността.
  • Новото учене се насочва към кандидати за журнал, за връзки или за отворени нишки. Тези кандидати не могат никога да създават права.
  • Съзнателната самообработка остава възможна само чрез изрично BLUN_SOUL_SELF_EDIT=1. Дори тогава policy изисква устойчиви собствени свойства вместо дневник, запис на инциденти, източник на права или досие на задачата.
  • Намесата не записва файл и не променя съществуваща душа.
9.1.255
  • Данните на идентичността можеха от 9.1.253 да попадат ограничено в контекста, а от 9.1.254 новите контактни възли да възникват автоматично. Липсваше обаче малък, непосредствено видим поведенчески слой: агентите можеха въпреки душата и контекста на връзките да падат в генерични асистентски фрази, принудени въпроси или изкуствени твърдения за чувства.
  • Нормалният и бързият разговорен път зареждат вече първо персоната и съществуващата душа, след това ограничения контекст на идентичността и фиксиран Natural Presence блок, едва тогава работните правила.
  • Блокът изисква истинска обща история вместо измислена близост, позволява мълчание и чисти краища на разговор и забранява принудени въпроси, генерични предложения и празни похвали.
  • При активна работа задачата и доказателствата стоят изрично първо. Блокът е по-малък от 420 знака и не създава нито моделни извиквания, нито достъп до файлове.
  • Нито един SOUL файл не беше променен, изтрит или автоматично пренаписан. Съществуващата душа остава водещият глас.
9.1.254
  • Въведеният в 9.1.253 проектор можеше да чете съществуващи данни за връзки, но социалната мрежа не се разширяваше още сама при нови контакти.
  • При първи Telegram контакт средата за изпълнение може вече от стабилни user_id и chat_id точно веднъж да създаде свързан с доставчик актьор, празно ребро на връзка към активния агент и при групи отделен групов възел.
  • Показваните имена никога не са първични ключове и не обединяват лица. По-късни съобщения не презаписват тихо съществуващ възел.
  • Пътят е изрично активируем, обвързан с наемател и записва само в вече инициализирано дърво на идентичността под BLUN Home. Несигурните или непълните метаданни остават fail-closed.
  • Няма моделно извикване, съдържателно тълкуване, чувствителни деривации и след първия контакт повтаряща се писателска тежест. Правата, ACL, токените и тайните не са в нито един създаден запис.
  • V4 на идентичностния документ (2 468 реда) беше кръстосано проверена преди публикуването. Новите чувствителни глави за страданието и психологическите умения остават съзнателно извън този чисто структурен release.
9.1.253
  • Идеята на идентичността се нуждаеше от първи продуктов път, без да залива моделния контекст с журнали, досиета за връзки или втора паметова система.
  • Нов, по подразбиране изключен проектор на идентичността чете само разрешени полета от обвързано с наемател дърво от файлове под BLUN Home.
  • Проекторът поставя текущата задача и изричните указания пред връзката и любопитството. Личните запитвания отпадат по време на активна работа, освен ако не са пряко релевантни за задачата.
  • Стандартният бюджет е 1 800 знака; и по-високата конфигурация не може да надхвърли твърдата граница от 2 800 знака.
  • Правата, ACL и тайните никога не се проектират. Несигурните идентификатори, отклоненията на наемателя, грешните данни, символните връзки или пътищата извън BLUN Home не доставят (fail-closed) никакъв контекст на идентичността.
  • Нормалният и бързият разговорен път използват същия проектор преди персоната, душата и поведенческите правила. На това ниво няма писателска операция, промяна на душата и рестарт на процес.
9.1.252
  • Изрично king update от управляван release предаваше неговия активен packageRoot на npm инсталатора. Поради това новата версия можеше да презапише на място старата, именувана по номера на версията release папка, докато active-runtime.json продължаваше да сочи старата версия.
  • Управляваните среди за изпълнение подготвят вече изрична актуализация като отделна, версионирана папка на изданието. pending-runtime.json и update-pending.json сочат към целта; следващият нормален старт я поема без втори въпрос за актуализация.
  • Активната стара папка на изданието остава байтово стабилна и се запазва като резервен път. Глобалните, неуправлявани инсталации запазват досегашния изричен път на актуализация.
  • Не е стартирана, спряна или презаредена нито една работеща сесия и нито един процес за изграждане, тест или публикуване.
9.1.251
  • След проекцията 9.1.250 6 411 от 6 424 персистирани usage.record събития съдържаха и по-нататък същото канонично име на модела blun/king. Само тази стандартна стойност се пропуска в персистираната форма.
  • Всичките 13 отклоняващи се стойности на модела (qwen3.8:27b) остават изрично запазени. И null остава; само undefined се възстановява при повторното възпроизвеждане като blun/king.
  • Живите събития и замразеният суров запис не се променят.
9.1.250
  • В замразения истински wire на агента всичките 6 424 персистирани usage.record събития съдържаха двата брояча на кеша inputCacheRead: 0 и inputCacheCreation: 0.
  • Само тези доказано занулени стойности се пропускат в персистираната форма. Живата употреба остава непроменена; всяка ненулева стойност продължава да се записва.
  • При повторното възпроизвеждане restoreUsageFromRecord възстановява липсващите броячи на кеша като 0. И двата пътя на възпроизвеждане и контекстната проекция използват тази реконструирана форма.
9.1.249
  • В замразения истински запис 3 759 от 7 777 резултата на инструменти носеха код на изход. От тях 3 465 бяха рутинният код за успех 0.
  • При резултатите на инструменти възпроизвеждането, транскриптът и моделният изглед използват изхода, идентификатора на инструмента и статуса на грешка, а не допълнителния нулев код.
  • Само успешните персистирани резултати на инструменти пропускат вече exitCode: 0. Живите събития го запазват; всичките 294 ненулеви кода остават непроменени за диагностика на грешки.
9.1.248
  • След 9.1.247 всичките 6 339 персистирани step.end събития повтаряха reasoningFieldState, въпреки че нито един път на възобновяване или възпроизвеждане не чете това поле.
  • Разпределение в замразения истински запис: 5 016 absent, 47 not_requested и 1 276 present.
  • Само персистираната форма пропуска вече reasoningFieldState. Живите събития запазват полето за диагностични цели; старите записани събития остават съвместими и реконструираното състояние остава същото.
9.1.247
  • След 9.1.246 6 986 персистирани content.part и 7 755 персистирани tool.call събития повтаряха UUID на актуално отворената стъпка.
  • В истински запис всичките 14 741 събития сочат без изключение към последно отворената стъпка: 0 отклонения и 0 събития без отворена стъпка.
  • Само персистираната форма пропуска вече stepUuid. Живите събития я запазват непроменена; старите записани събития с изричен UUID и новите компактни събития без UUID се поддържат съвместно.
  • И трите пътя на възобновяване използват за компактни събития на съдържание и инструменти последно отворената стъпка.
9.1.246
  • След 9.1.245 5 642 по-късни step.begin събития повтаряха ID на хода, въпреки че възобновяването се нуждае само от най-високия наблюдаван ID на хода. Първата стъпка на всеки ход я носи вече.
  • Истински запис съдържа 713 хода и 6 355 старта на стъпки. Всеки ход започва точно със стъпка 1 и всички по-нататъшни номера на стъпки вървят без празнина; 0 отклонения в последователността.
  • Само по-късните персистирани стартове на стъпки пропускат вече ID на хода. Първите стъпки, живите събития, старите записани събития и стартовете на стъпки без надежден пореден номер остават непроменени.
9.1.245
  • След 9.1.244 6 326 персистирани step.end събития повтаряха и по-нататък UUID на последно отворената стъпка. Истински запис потвърди за всяко завършване еднозначно съответствие последен-влязъл-пръв-излязъл: 0 отклонения и 0 завършвания без отворена стъпка.
  • Само персистираната форма на завършване пропуска вече UUID. Живото събитие го запазва непроменено; старите записани събития с UUID и новите компактни събития без UUID остават съвместно възпроизводими.
  • И трите пътя на възобновяване разрешават завършване без UUID чрез последно вмъкнатата отворена стъпка. Незавършените исторически стъпки остават отворени и не се претълкуват.
9.1.244
  • След 9.1.243 6 326 персистирани step.end събития съдържаха и по-нататък четири отделни брояча на употреба. За възобновяването и нивото на запълване на контекста е необходима изключително тяхната сума.
  • Живите събития запазват и четирите брояча за показване, телеметрия и фактуриране. Само записаната форма на възобновяване използва вече contextTokens като едно число.
  • И двата пътя на възпроизвеждане приемат нови компактни и стари пълни събития. Така съществуващите сесии остават обратно съвместими.
9.1.243
  • След 9.1.242 6 322 персистирани step.end събития съдържаха и по-нататък рутинните стойности finishReason: tool_use или finishReason: end_turn.
  • И двете стойности са изводими точно от вече персистираната форма на стъпката: има извикване на инструмент -> tool_use, иначе end_turn. В пълния запис имаше 0 отклонения.
  • Изключително тези две рутинни стойности не се персистират вече. Редките и диагностично важни причини остават; всичките четири max_tokens събития останаха изрични и байтово равни.
  • Намесата следва измерения в ECC принцип на ограничена, ориентирана към изключенията телеметрия. DeepAgents и AnythingLLM потвърдиха вече съществуващите BLUN модели за изнасяне и ограничен запис; нито една чужда подсистема не е възприета.
9.1.242
  • След 9.1.241 6 355 персистирани step.begin събития съдържаха и по-нататък полето step, въпреки че текущият дисплей обработва номера на стъпката преди персистенцията и replay-reducer-ът се нуждае само от uuid.
  • turnId остава, защото възобновяването извежда от него продължения ход. uuid, типът и всички по-нататъшни съдържания остават непроменени.
  • Намесата е изключително в bin/loop-event-record-policy.cjs; суровият запис и живото събитие не се променят.
9.1.241
  • След 9.1.240 6 326 персистирани step.end събития съдържаха и по-нататък копия на turnId и step. И двете стойности лежат вече в реферирания чрез същия uuid step.begin.
  • В истински wire всеки край имаше налично начало на стъпка, и двете метаданни стойности съвпадаха точно във всички случаи.
  • Проекцията премахва само тези две копия. Идентификаторът на стъпката, разходът на токени и диагностиката на завършването остават; живите събития остават пълни.
9.1.240
  • След 9.1.239 6 986 content.part и 7 755 tool.call събития записваха и по-нататък по едно копие на turnId и step, въпреки че и двете стойности лежат вече в реферирания чрез stepUuid step.begin.
  • В истински wire всичките 14 741 дъщерни събития имаха налично начало на стъпка, и двете стойности съвпадаха точно във всеки случай.
  • Проекцията за персистенция премахва само тези две копия на метаданните от двете дъщерни събития. stepUuid, съдържанието, идентификаторът на инструмента, името и аргументите остават; живият reducer вижда и по-нататък пълното събитие.
9.1.239
  • След проекцията от 9.1.238 истински wire съдържаше и по-нататък излишни идентификатори на събития: content.part.uuid не се чете от нито един replay потребител, tool.call.uuid беше във всичките 7 755 случая точно равен на toolCallId, и tool.result.parentUuid беше във всичките 7 755 случая точно равен на toolCallId.
  • Проекцията за персистенция премахва само тези три излишни полета. turnId, step, stepUuid, toolCallId, името на инструмента, аргументите, резултатът и съдържанието остават напълно запазени. Живият reducer вижда и по-нататък всяко несъкратено събитие.
  • Вече компактните събития запазват обектната си идентичност. Съществуващите wire файлове не се пренаписват и не се променят.
9.1.238
  • Истински wire съдържаше 6 326 персистирани step.end събития с 2 708 052 байта данни на събития. Седем полета за измерване на времето на изпълнение и идентификатора на съобщенията на доставчика бяха оценени още преди персистенцията в живото събитие и не бяха четени от нито един път на replay, транскрипт, blob или инспекция на сесията.
  • Съществуващата проекция на loop събития премахва вече само тези седем познати живи полета: шест измерени стойности на латентност/стрийминг и messageId. Идентификаторът на стъпката, ходът, номерът на стъпката, разходът на токени, причината за завършване, диагностиката на завършване на доставчика и диагностиката на размисъл остават.
  • Живият reducer обработва и по-нататък пълното събитие. Старите wire файлове остават байтово равни и не се пренаписват.
9.1.237
  • Истински wire съдържаше 1 428 записа за регистриране/отписване на потребителски инструменти. От 992 отписвания 560 бяха строги нулеви операции: инструментът не беше нито регистриран, нито активиран. Тези записи заемаха 59 500 персистирани байта, без да променят възстановеното състояние.
  • От основния принцип на DeepAgents да се запазва само ефективното работно състояние се възприема тесен локален лост: отписването на инструмент се протоколира вече само когато променя регистрираното или активираното състояние.
  • И двете живи изтривания вървят и по-нататък при всяко извикване. Отписването на регистриран, на само активиран или на присъстващ в двата регистъра инструмент остава напълно протоколирано. Съществуващите wire файлове не се пренаписват и не се променят.
9.1.236
  • Истински wire съдържаше 214 състояние-подобни инжекции за tool-awareness, action_style, swarm_mode и swarm_mode_exit. Досегашното точно дедупликиране оставяше шест различни стари състояния с общо 6 305 текстови байта във всяка нова моделна заявка.
  • От основния принцип на ECC да се държи само текущото състояние в работния контекст и пълната история да се пази отделно, се възприема тесен локален лост: за инвентара на инструментите и стила на действие остава видима само най-новата версия. Влизането и излизането от swarm режима образуват обща фамилия на състоянието, от която също остава само последният статус.
  • Суровият запис никога не се променя. Други варианти на инжекции, нормални потребителски съобщения, нетекстови и malformed записи запазват досегашното поведение.
9.1.235
  • Истински wire съдържаше единадесет завършени Agent извиквания. Шест от тях бяха доказано успешни (status: completed) и лежаха най-малко двадесет по-нови контекстни съобщения назад. Старите им текстове на задачи заемаха заедно и по-нататък 33 629 знака, въпреки че пълните доклади за завършване стояха непосредствено след тях в записа.
  • От разделението на DeepAgents между контекст на главен и подчинен агент се възприема затова тесен локален лост: само старият prompt на успешно Agent извикване се заменя в моделния изглед с кратък маркер. Описанието, типът на подчинения агент и докладът за завършване остават пълни.
  • Текущите, по-малко от двадесет съобщения стари, неуспешните, malformed и чуждите извиквания на инструменти остават непроменени. Суровият запис никога не се променя; без изричен ред status: completed проекцията не задейства fail-closed.
9.1.234
  • Истински wire съдържаше сред 166 успешни резултата на инструменти три големи, точно повторени резултата от четене за същото извикване на инструмент. Непромененото повторение заемаше 15 936 сурови байта, въпреки че за текущия моделен изглед е нужно само най-новото пълно копие.
  • Проекцията разпознава затова изключително успешни, чисто текстови резултати с точно същото име на инструмента, точно същите аргументи и точно същото съдържание. Най-новото копие остава пълно; по-старите копия се заменят само в моделния изглед с кратък указател.
  • Суровият запис, променените резултати, грешките, медиите, персистираните указатели и малките резултати остават непроменени. Съществуващото изнасяне на инструменти остава ефективно преди това; дедупликирането може да възстанови неговата проекция само за най-новото идентично копие.
9.1.233
  • В истински wire беше отхвърлено пълно Write извикване с 2 357 UTF-8 байта на досегашната граница от 2 048 байта. След това агентът обеща продължение, но презаписа същия tokenize.cjs многократно с непълни фрагменти, между тях два пъти байтово равни първите 1 099 байта. Засегнатите стъпки носеха съответно около 64 000 входни токена; отделни отговори достигнаха 10 319 или 7 015 токена.
  • Пълните файлове до 4 096 UTF-8 байта могат затова вече да се записват в атомарно Write извикване. Реалният случай с 2 357 байта не се нуждае от допълнителен моделен ход.
  • По-големите извиквания остават в пълния протокол на продължението. След такова отхвърляне пътят се заключва: по-малки нормални Write записи не могат вече да презапишат целевия файл с частични фрагменти. Едва валидно продължение поема пътя; целта остава непроменена до крайния доказан резултат.
9.1.232
  • Автоматичният режим resume беше зададен в реален агентен профил, но инсталираната версия стоеше на 9.1.221, активната подготвена среда на 9.1.219, а npm/манифестът вече на 9.1.231. Без работещ King досегашният фонов път не можеше да подготви пропусната версия.
  • resume и new проверяват затова вече и при следващия естествен студен старт за поне 30 минути стабилна, независимо подписана версия на изданието. Тя се подготвя в защитеното място за издавания, отбелязва се като pending и се стартира без втори старт или прозорец за избор.
  • manual и off остават непроменени. Ако подготовката, цялостта, пробата на пакета или мрежовото извличане се провалят, съществуващият стартов път продължава. Вече работеща сесия не се прекратява никога от този път на студен старт.
9.1.231
  • В истински wire се провали отговор на Telegram преди изпращането с 400: Bad Request: can't parse entities: Can't find end of Italic entity. Извикването имаше изрично format: markdownv2; 0 от 1 текстови части бяха доставени.
  • Разпращането на Telegram-MCP повтаря вече само засегнатата текстова част точно веднъж като чист текст, когато Telegram съобщи точно грешка при разбора на entity. Чатът, референцията за отговор, границата на частта и следващите прикачени файлове остават запазени.
  • Мрежовите грешки, непознатите чатове, грешките на правата и вече изпратените като чист текст извиквания не се повтарят от този резервен вариант. Така нито се преглъща произволна грешка, нито се изпраща два пъти успешна част.
9.1.230
  • След изключване на вече отстранените с 9.1.228 и 9.1.229 исторически грешки в последните 1 200 резултата на инструменти на един агентен профил останаха повторените Bash timeout-и като следващ затворен блок. Засегнатите команди претърсваха многократно цялата потребителска директория или цялата Dropbox рекурсивно и приключваха след 60 секунди без полезен резултат.
  • Bash отхвърля вече преди старта на процеса точно две неограничени форми на търсене: find върху цялата потребителска директория и рекурсивно grep срещу ..
  • Текстът на грешката назовава веднага ограничената алтернатива: Glob с вкоренен файлов модел, Grep с път/glob или позната подпапка на проекта. Целенасочено ограничените до src, test или други именувани поддървета търсения остават непроменено разрешени.
  • Таймаутът не е увеличен и произволни Bash команди не се повтарят автоматично. Така не възниква нито по-дълго време на чакане, нито рискът пишеща команда да се изпълни два пъти.
9.1.229
  • След ремонта на Deferred инструментите най-голямото свързано семейство грешки в истински запис беше многочастният Write: липсващи задължителни полета (part, start_line, final), предварително погрешно позната обща бройка на редовете, остарели номера на части и след грешки все още активен стар статус на продължението създаваха повторения без полезна работа.
  • Номерът на частта, началният ред и режимът се извеждат вече от действително подготвеното в staging състояние, когато липсват. Изрично изпратените стойности остават видими и при отклонение продължават да се отхвърлят.
  • expected_lines е незадължително и може да се достави едва в крайната част. Когато е зададено, преливането и точната крайна проверка остават непроменено fail-closed.
  • final=true остава задължително за завършването. Без тази изрична крайна марка не се записва нищо; целевият файл остава непроменен до завършването. Незадължителната SHA-256 проверка остава.
9.1.228
  • В последните 1 000 истински резултата на инструменти имаше 66 грешки. Най-големият ясно поправим единичен блок бяха 10 Tool not found грешки: девет пъти mcp__mnemo__mem_transcript_recent, веднъж mcp__mnemo__mem_question_answer. И двата инструмента бяха регистрирани, но поради токен бюджета просто не бяха заредени в съответната стъпка.
  • След точна грешка Tool "<name>" not found запомня ходът тази схема за непосредствено следващата стъпка. Нормалният избор я поема след това от вече регистрирания списък на инструментите.
  • Други текстове на грешки, успешни резултати и отклоняващи се имена на инструменти не променят състоянието. Съществуващата LRU граница от четири схеми остава; наистина непознат инструмент не се измисля и не се изпълнява.
  • Нито един инструмент не е поставен постоянно във всеки промпт. Нормалният разход на токени за схеми остава затова непроменен; само вече платено погрешно повторение се избягва от втория опит нататък.
9.1.227
  • Истински wire запис съдържаше 119 ToolSearch извиквания. 35 от тях завършиха без попадение; 27 нулеви попадения засягаха Telegram записа, извличането на съобщения или свързаното търсене в паметта.
  • 9.1.226 разреши с актуалния списък на инструментите вече 8 от тези 35 стари нулеви попадения. Останалият главен случай бяха прекомерно определени заявки като +telegram history messages lesen, при които моделът беше маркирал семантични думи погрешно като задължителни части на името.
  • От DeepAgents е възприет принципът указанията за инструменти и повърхността на инструментите да се съгласуват след филтрирането. Не е копиран никакъв чужд код: BLUN опитва и по-нататък първо точното и строгото търсене и разхлабва едва след истинско нулево попадение + термините до семантични термини за търсене.
  • Резервният вариант не изпълнява никакъв инструмент. Той зарежда само най-добре оценената схема или истинските равенства, изисква при няколко термина най-малко 75 процента попадения и остава затворен при чужди на темата термини.
  • Сравнение със свежо инсталирания пакет 9.1.226 и същите 35 исторически заявки: преди 8 попадения, след това 21 попадения, значи 13 допълнителни истински попадения и 0 загубени предишни попадения.
  • Не е вмъкнато ново моделно, търсещо, мрежово или embedding извикване. Суровият запис, изпълнението на инструментите, разрешенията и постоянното множество на схемите остават непроменени.
9.1.226
  • Истински wire запис съдържаше 6 275 завършени моделни стъпки. В последните 50 стъпки локалното изграждане на заявката стоеше при p50 0 ms и p90 1 ms, а локалното потребление на потока при p50 1 ms и p90 3 ms. Времето на чакане до първия токен на сървъра стоеше срещу това при p50 11 842 ms и p90 14 846 ms. Допълнителен локален микро-производителностен разрез не беше доказан като ефективен лост.
  • Изведеният от Evolver валидиран път на учене съществуваше вече: червено-към-зелено доказателствата се записват профилно свързано като pending, recorded или expired. За потребителите нямаше обаче локален изглед за това.
  • 9.1.226 добавя /improve с алиас /learning. Панелът показва трите брояча на статуса и при най-новия отворен кандидат само ограничени, безопасни данни на доказателство: ID на кандидата, име на инструмента и дванадесет позиции на хеша на командата.
  • Командата чете само локалния регистър на активния профил. Тя не стартира моделно, търсещо, hub или embedding извикване и не променя никакъв кандидат. Непознатите стойности на статуса и несигурните знаци за показване се изхвърлят или се представят като unknown.
  • Всички нови UI текстове за немски, испански, френски, шведски и чешки издържаха задължителното езиково gate и последващата проверка на разписката; всичките шест UI каталога съдържат пълните ключове.
9.1.225
  • В истински wire запис 88 config.update записа заемаха 4 078 566 байта. 83 от тях носеха пълния системен промпт.
  • Промптът декларираше стабилен времеви печат на сесията, но го задаваше наново при всеки старт на процеса. След нормализиране на този времеви печат останаха 45 семантични варианта и 38 последователни повторения, причинени само от новия времеви печат.
  • Тези 38 повторения заемаха 781 179 байта, значи 19,16 процента от всички байтове на системния промпт в измерените конфигурационни събития. Едновременно с това преизползваемият префикс на промпта на доставчика се променяше ненужно след рестарти.
  • 9.1.225 свързва времевия печат при свежи и възобновени главни и подчинени агенти с Session.metadata.createdAt. Невалидните стари метаданни падат защитно на досегашната in-memory стойност.
  • Суровият запис, съдържанието на промпта, инструментите, изборът на модел и сгъстяването остават непроменени. Няма допълнително моделно, търсещо или embedding извикване.
9.1.224
  • При последно измерения старт паралелната инициализация на пет MCP сървъра отне 16,85 секунди. Възобновяването на сесията и разборът на wire бяха значително по-кратки – съответно около 0,55 и 0,18 секунди.
  • Досега пътят на хода изчакваше тази MCP инициализация преди всяка заявка, дори когато локален чист поздрав след това умишлено получаваше нула инструменти в заявката към модела.
  • 9.1.224 възприема границата на инструментите със зареждане при нужда от съгласуването с DeepAgents: Само локалният, свободен от инструменти кратък разговор може да отговори веднага. Telegram ходове, прикачени файлове, системни задействания и всяка работна заявка продължават да чакат пълната MCP инициализация.
  • Суровият запис, MCP конфигурацията, схемите на инструментите и нормалните работни ходове остават непроменени. Не е деактивиран нито един сървър и не е въведено допълнително моделно, търсещо или embedding извикване.
9.1.223
  • Една стъпка 775.5 завърши празно с fall=length, 8 192 от 8 192 completion токена и само седем знака размисъл. Досегашната логика стартираше след това същия голям request отново и удвояваше completion бюджета до 16 384 токена.
  • Локалният CPU стоеше през времето на чакане на приблизително 0 процента; изграждането на request траеше 0-1 ms, а транспортът около две секунди. Измереното тясно място беше следователно моделната генерация плюс повторението с пълен бюджет, а не TUI.
  • Само доказаният случай length + напълно изчерпан бюджет + по-малко от 64 знака размисъл получава вече икономичен повторен опит с фактор 0,125 и най-малко 1 024 токена.
  • Богатите на размисъл и не напълно изчерпаните length отговори запазват досегашното разширение с фактор 2. Другите класове на повторение остават непроменени.
  • За измерен случай вторият бюджет пада от 16 384 на 1 024: 15 360 токена или 93,75 процента по-малко в повторния опит.
9.1.222
  • Работещият updater беше предал подготвена версия по IPC на активния King. Launcher-ът прекрати след това работещия core с код на изход 76 и трябваше да стартира заместващ процес. При измерения преход към 9.1.219 един агентски профил остана поради това излязъл от системата.
  • Фоновите актуализации зареждат и проверяват вече само новата версия и я съхраняват за следващия естествен старт. Те не изпращат restart IPC съобщение, не прекратяват активна TUI и не стартират заместващ процес.
  • При следващия нормален king старт се появява отново съществуващият избор: актуализиране, пропускане веднъж или чакане до следващото издание. Едва след решението за инсталация launcher-ът стартира от вече проверения подготвен пакет; второ изтегляне отпада.
9.1.221
  • Непроменените, все още непокрити от tokenCount съобщения използват вече точно една оценка на токени на ревизия на контекста. Повтарящите се достъпи за статус и рендериране не сканират отново същия растящ запис.
  • Нови текстови части, извиквания на инструменти, промени в историята, сгъстяване, undo и променен брой на вече покрити съобщения инвалидират кеша веднага. Суровият запис, персистираната история и съобщената стойност на токените остават идентични спрямо досегашния път.
  • Седем измервания с 300 синтетични съобщения и по 250 непроменени заявки дадоха в медианата 42,1218 ms -> 0,1755 ms, около 99,583 % по-малко изчислително време в този горещ път. И двете версии дадоха точно същата оценка от 127.838 токена.
  • Изданието намалява CPU работата за локалната оценка. То не твърди намаляване на действително изпратените към модела входни токени.
9.1.220
  • Проекцията на дълги асистентски отговори записва вече резултата си в WeakMap, докато обектът на съобщението, масивът на съдържанието, текстовата част и точният изходен текст остават непроменени. Суровият запис и проектираното съдържание остават идентични спрямо досегашния път.
  • Промяна на текста, масива на съдържанието или текстовата част изхвърля записа веднага. Различните обекти на съобщения не споделят кеш.
  • Пет измервания с по 1000 повторни проекции дадоха в медианата 16,489 ms -> 0,202 ms, около 98,8 % по-малко изчислително време в този път. И двете версии спестиха при това точно 21.206 знака.
9.1.219
  • Чистите кратки текстови потвърждения като ok, danke или отговори на Telegram DM с поставен след това сигнал за продължаване не четат вече регистъра за валидирани кандидати за учене при всяка моделна стъпка.
  • Значимите промпти, прикачените файлове и ходовете с актуална инструментна дейност се синхронизират и по-нататък. Вече видимото напомняне за учене остава и по време на пропуснато потвърждение.
  • Действителното измерване на пакетираната версия с 50 потвърждения показа спад от 50 на 0 четения на директорията на кандидатите. Значимата обратна проба прочете точно веднъж. Не се добави нито едно моделно, embedding или мрежово извикване.
9.1.218
  • Същата проверка червено-към-зелено създаде в 9.1.217 при повторение с нови ID на инструментални извиквания втори отворен кандидат. Изолираното измерване даде две ID, 2 отворени файла и 726 байта.
  • Ако се записваше само най-новият кандидат, по-старият идентичен кандидат щеше да се появи отново като напомняне. Това би създало втори цикъл на напомняне и MistakeRecord за същия отворен урок.
  • bin/validated-learning-signal.cjs сега използва повторно вече отворен кандидат на същия профил и същия commandHash. Другите проверяващи команди остават отделни; записаните или изтеклите кандидати не поглъщат по-късно събитие.
  • Повторното измерване даде същото ID, 1 отворен файл и 363 байта. Няма допълнително моделно, embedding или мрежово извикване.
9.1.217
  • В 9.1.216 маркираше всеки успешен MistakeRecord най-новия отворен кандидат за учене като обработен, дори когато записът принадлежеше на друга грешка. Доказателството беше следователно постоянно, но не точно корелирано с по-късния си запис.
  • bin/validated-learning-signal.cjs чете вече незадължителния candidateId на успешен MistakeRecord и затваря единствено точно съответстващия отворен кандидат. Липсващо, погрешно или чуждо ID оставя всички отворени кандидати непроменени.
  • blun.mjs назовава стабилното ID на кандидата във видимото напомняне и въвежда candidateId като незадължително поле в схемата на MistakeRecord. Няма допълнително моделно, embedding или мрежово извикване.
  • Корелацията остава профилно свързана. В регистъра на кандидатите не попадат и по-нататък нито сурови команди, нито изходи на инструменти.
9.1.216
  • bin/validated-learning-signal.cjs съхранява вече потвърдените сигнали червено-към-зелено за цялата инсталация под <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/. Така един кандидат за учене остава запазен през потребителски ходове, сгъстявания и различни портали на същата BLUN инсталация.
  • Регистърът е профилно свързан, append-only и безопасен при конкуренция: за всеки кандидат възниква неизменим JSON файл и точно един .recorded или .expired маркер. Временният файл, hardlink-ът и премахването на временния файл предотвратяват тихо презаписване при паралелни записващи процеси.
  • Записват се само тип, статус, профил, име на инструмента, SHA256 на командата, ID на инструменталните извиквания и времеви печат. Суровата команда, текстът на грешката и успешният изход на инструмента не се персистират.
  • Успешен MistakeRecord маркира най-новия отворен кандидат точно веднъж като обработен. Отворените кандидати изтичат след 24 часа. Ако липсва общо home, досегашното in-memory поведение остава fail-open.
  • Това не е още автоматична промяна на код и не е самостоятелно дадено разрешение. Изданието създава само преносимото, независимо от порталите доказателство за учене, върху което по-късните вградени evaluator и approval функции могат да работят безопасно.
9.1.215
  • Решенията не бива да предполагат нито определени вътрешни агенти, нито вътрешни имена на машини, Telegram групи, Mnemo инстанции или вътрешна верига за разрешения на BLUN.
  • За Self-Improvement вътрешните роли се абстрахират като продуктови функции: контролер на обхвата/разрешението, изолиран evaluator, версиониран доказателствен запис и автоматично canary обратно измерване с rollback.
  • Автоматично могат да се приемат само нискорискови, измеримо ограничени адаптации при изцяло по-добри или неутрални проби. Кодът, правата, secrets, фактурирането и продукционната среда остават задължение на потребителя или администратора.
  • Първата реализация на вградения gate се приема вътрешно ръчно; след това gate-ът може да проверява сам, но не и да променя собствената си граница на сигурността.
9.1.214
  • 9.1.213 създаде правилния постоянен път на съхранение чрез MistakeRecord, но очакваше и по-нататък моделът сам да разпознае подходящия момент единствено от инструментната история.
  • Нов е bin/validated-learning-signal.cjs: модулът разглежда само текущия потребителски ход и разпознава изключително същата проверяваща shell команда, която първо се проваля и по-късно успява.
  • Динамичен инжектор в blun.mjs напомня в този доказан случай да се запише преизползваем урок с MistakeRecord. Текстът на командата и суровата грешка не се копират в указанието.
  • Други команди, нормални грешки при четене/инструменти, нов потребителски ход или вече успешно извикване на MistakeRecord не създават или не задържат указание. Не се извършва автоматично съхранение.
9.1.213
  • Мисионният договор изискваше след успешна проба червено-към-зелено извикването record_error_memory. Този инструмент не съществува в пакета King. Съществуващият постоянен път на учене се нарича MistakeRecord и пише в общия Mistake.md.
  • По този начин дисциплината от Evolver беше вече формулирана, но последната стъпка към нашата собствена, обхващаща агентите памет беше мъртва: потвърдено решение можеше да следва договора и въпреки това да не се съхрани постоянно.
  • Договорът вече извиква MistakeRecord след зеления повторен прогон. Суровите грешки и занапред остават изключени; записва се едва урокът, потвърден от успешен контролен прогон.
  • Mistake.md, нейният подбор по значимост и форматът ѝ на съхранение не са заменени или променени. Поправена е изключително връзката от валидирания договор за учене към съществуващия инструмент.
  • Променени са само blun.mjs, новият структурен тест test/validated-learning-route.test.js и версията в package.json.
9.1.212
  • Инжекторът на ErrorMemory форматираше също за чисти поздрави и кратки потвърждения няколко стратегически гена. Mistake.md и личната памет имаха за същия клас съобщения вече обща граница на значимост; само ErrorMemory я заобикаляше.
  • Инжекторът използва вече също isLowInformationMistakeTurn и прекратява проекцията преди избора и форматирането на стратегическите гени. Персистираните записи за грешки и стратегии остават непроменени; само ненужната им проекция в мини заявки отпада.
  • Измерен референтен случай Как си? с единадесет съхранени записа: преди пет избрани правила, 1.417 знака или около 355 токена; след това 0 знака и 0 токена.
  • Променени са само blun.mjs, test/error-memory-performance-policy.test.js и версията в package.json.
9.1.211
  • King потвърждава редовете на опашката едва когато съобщението е прието. Преди активна сесия изхвърля injectChannelEnvelope обаче адресирано съобщение като dropped, без да го потвърди или паркира. Така чекпойнтът може да остане постоянно точно на този първи ред.
  • Истинска червена проба _proof/telegram-profile-checkpoint-red.cjs: очаквано queued, измерено dropped, изход 1.
  • Същата грешка стои в пътя на Telegram командите: /loop преди активна сесия не се поставя в queuedMessages; функцията за потвърждение остава без консуматор. Истинска червена проба _proof/telegram-remote-command-presession-red.cjs: очаквана дължина на опашката 1, измерена 0, изход 1.
  • injectChannelEnvelope третира вече сесия, която още не може да доставя, като заета сесия: моделният текст, произходът на показване и по-късното потвърждение остават запазени в съществуващата канална опашка.
  • injectTelegramRemoteCommand изгражда записа в опашката преди проверката на сесията. /loop и другите директни Telegram команди се паркират при липсваща сесия с тяхната channelAcknowledge функция и се изпълняват едва на съществуващата безопасна граница.
  • Редът и съществуващото правило за чекпойнт остават непроменени: ред от опашката се потвърждава едва след приемане; по-късни потвърждения не могат да прескочат все още отворен ред преди това.
9.1.210
  • Активното предаване от 9.1.208/9.1.209 можеше да прекрати работещ King за актуализация. На MSI беше прекратена поради това работещата сесия при прехода 9.1.206 -> 9.1.207 и не беше възобновена автоматично.
  • 9.1.209 не беше поради това включен в публичния манифест и беше маркиран на npm като неразгръщаем.
  • Изискването е вече технически наложено: автоматична актуализация никога не бива да прекратява работещия King. Тя само се зарежда и се отбелязва като pending. Активирането става едва при по-късен нормален старт.
9.1.209 Изтеглена
  • Непубликувана. Активното предаване на актуализацията можеше да прекрати работещ King; затова версията не попадна в публичния манифест и беше маркирана на npm като неразгръщаема.
9.1.208
  • На MSI бяха измерени 27 старта на King и 15 състояния на версии за един ден. Рестартите съвпадаха съответно със скокове на версиите; отделна причина за изход не се протоколира и по-нататък в местния лог.
  • Updater-ът подготвяше нови версии на манифеста всяка минута. Версия 9.1.208 въвежда поради това 30-минутен прозорец на покой, преди да може да се активира следваща нова среда за изпълнение.
  • Старите състояния на средата за изпълнение се ограничават след успешно активиране до най-новите три версии. Изтрива се само когато всички инсталационни leases на старото състояние са придобити ексклузивно. Активните, заети или непознати оформления остават недокоснати.
  • Защитната логика живее и в новозареденото ядро. Така тя действа след автоматичното активиране дори когато постоянният родителски launcher произхожда още от по-стара версия.
  • Осемте измерени MSI състояния на изданието заемаха заедно само 778 MB. Те не обясняват почти напълно запълнения 454 GB диск; големият консуматор остава отделна отворена констатация.
9.1.207
  • Повторенията на неуспешна телеметрия се ограничават за един прогон до 16-те най-стари файла и спират при първата временна сървърна грешка, вместо да обработват по-нататък целия натрупан застой.
  • Резервоарът за грешки запазва най-новите 512 файла в рамките на 16 MiB и седем дни. Нормалният events.jsonl е изрично изключен от почистването.
  • Преди изданието лежаха реално 4 248 файла с грешки с 11 631 974 байта. След автоматичното активиране лежаха 512 файла с 2 260 908 байта: 3 736 стари файла с грешки и около 9,37 MB товар по-малко.
9.1.206
  • Вече архивираните големи асистентски отговори се заменят сега преди проекцията на цикли с техния ограничен, отново четим указател към архива. Така последващо почистване на текста не може вече да обезсили съхранения хеш.
  • Три реални архивни файла бяха проверени байтово точно срещу съхранените си SHA256 хешове на съобщения: 38.567, 13.941 и 24.787 знака, всички налични и всички точни.
  • Върху точно същите 41.480 wire записа с 311 съобщения моделната проекция падна от 87.724 на 63.234 знака: още 24.490 знака или около 6.123 входни токена по-малко за засегнато извикване.
  • Суровата история и пълните частни архивни файлове остават непроменени и са четими страница по страница през техния път.
9.1.205
  • Отговорните цикли в рамките на едно асистентско съобщение се разпознават вече и при малки разлики в пунктуацията или формулировката. Един клъстер се нуждае от най-малко три попадения при консервативна прилика 0,88; първата версия остава запазена, суровата история не се променя.
  • В консервиран случай реален отговор на цикъл падна от 24.787 на 22.711 знака: 2.076 знака или около 519 входни токена по-малко.
  • Кодовите огради остават защитени байт по байт. Инструментните разкази, инжекциите, двойките и икономиите под 1.000 знака остават непроменени.
9.1.204
  • Напомнянето за грешки не зарежда вече сляпо всичките единадесет правила на работен кръг. Четирите незаменими правила за доказателство и обратна проба 4, 9, 10 и 11 остават винаги активни; най-много две допълнителни правила се добавят детерминистично според текущата задача.
  • В истинската доставена колекция от правила повтарящият се блок падна от 2.442 на 1.272 знака: 1.170 знака или около 293 входни токена по-малко за засегнат работен кръг.
  • Изборът не създава моделна, търсеща, reranker или embedding заявка. Малките собствени колекции от правила остават пълни; при грешка на селектора действа и по-нататък предишният пълен блок.
9.1.203
  • Празно ToolSearch е вече успешно завършен нулев резултат вместо червена инструментна грешка. Отговорът назовава липсващия оправомощен инструмент и забранява повторение със синоними.
  • В измерения запис стояха 32 празни търсения с 29 формулировки; в консервиран ход същата липсваща Telegram способност беше запитана отново след червената грешка директно с второ търсене.
  • Без допълнителна моделна, reranker или embedding заявка, без нова резидентна схема и без промяна на инструменти или права.
9.1.202
  • Изведената от DeepAgents локална контекстна проекция показва при големи работни директории предпочитано top-level записи вместо дълбоки детайли от първите няколко папки. Малките списъци на директории остават байтово равни.
  • Един агентски root съдържа 509 top-level записа (89 папки, 420 файла). Преди моделната проекция показваше в 1.981 знака само 9 top-level папки; сега показва 30 в 832 знака.
  • Измерена икономия: 1.149 знака или около 287 токена на заявка. Персоната, работните правила, суровата история и достъпът до инструменти остават непроменени.
9.1.201
  • Изведената от DeepAgents проекционна хигиена сгъстява статичната памет за грешки, без да губи нито едно от 11-те съхранени правила или проверки.
  • Старите подробни текстове на паметта за грешки се сгъстяват само в моделната проекция. Суровата история, нормалните отговори и резултатите на инструменти остават непроменени.
  • В проекцията остава съответно само най-новият запис за грешка и корекция на грешка.
9.1.200
  • Новата локална команда /context показва разделно действително проектираната моделна заявка, съхранения разговорен запис, схемите на инструментите, бюджета на сгъстяване и оставащото пространство.
  • Изгледът чете изключително session.getContext(). Той не стартира моделна заявка, управлявана справка за потребление, услуга или рестарт.
  • Изнесените резултати на инструменти назовават вече точен път за повторно четене: Read с най-много 20 реда и след това продължен line_offset. Това предотвратява измерената форма, при която агент заявяваше отново същия голям участък с Read, Grep и Bash.
  • /premortem съществуваше вече преди 9.1.200 и изрично не се продава като нова функция на това издание.
  • За нови преводи задължителното езиково gate не даде разрешение поради липсваща независима проверка на кратки текстове. Затова /context използва само вече разрешени локализирани наименования; не е включен нито един непроверен целеви текст.
9.1.199
  • Актуален моделен изглед съдържаше в един отделен асистентски отговор 13 941 знака със 100 абзацни блока. Само 20 блока бяха еднозначни; шест групи се повтаряха точно и заемаха 9 579 знака.
  • 9.1.199 сгъстява изключително такива точни повторения в рамките на един отделен чисто текстов отговор в моделния изглед. Суровият запис на сесията остава непроменен.
  • Сгъстяването задейства едва от три точни повторения и най-малко 1 000 спестени знака. Кодовите блокове, смесените съдържания, извикванията на инструменти, инжекционните съобщения, кратките блокове и по-малките икономии остават непроменени.
  • Това следва основния принцип на DeepAgents да се запазва повторно четимата истина и да се облекчава само активният моделен изглед. Няма допълнително моделно или embedding извикване.
9.1.198
  • Актуален запис съдържаше вече маркиран от инструмента като truncated: true резултат на Grep с 50 042 знака. Изнасянето на единичния резултат разпознаваше размера, но оставяше такива резултати поради ранен return въпреки това изцяло в моделния изглед.
  • 9.1.198 премахва единствено това изключение. Отрязан Read използва съществуващия път на източника без дубликат; другите отрязани резултати архивират точно пълния върнат от инструмента текст.
  • Указателят запазва truncated: true и носи stored_result_scope: tool_truncated_output. Така не се твърди, че е възстановен суров изход, който инструментът никога не е доставил.
  • Моделът следва DeepAgents: големите изходи на инструменти остават повторно четими извън активния моделен изглед, докато там остава само малък указател.
9.1.197
  • И чисто текстовите потвърждения като ok зареждаха досега динамичното напомняне от Mistake.md. При актуалния общ набор от правила това бяха 1 819 знака на промпт, приблизително 455 токена, въпреки че не беше продължен никакъв работен контекст.
  • 9.1.197 разпознава изключително информационно бедни чисто текстови ходове, преди да се прочете някой от двата източника на Mistake, и пропуска там динамичната инжекция.
  • Прикачените файлове, нетекстовите съдържания и смислените продължения като ok, check updater запазват досегашния път. Съществуващият fallback на значимост за истински работни ходове остава непроменен.
  • Моделът произхожда от сравнителната работа с AnythingLLM: незадължителните контекстни източници трябва да попадат в моделния изглед само когато текущият ход наистина се нуждае от тях. Той е вписан без допълнително моделно или embedding извикване в съществуващата BLUN политика.
9.1.196
  • /reload беше наличен локално, но не се разпознаваше от Telegram като директна команда. Allowlist-ът на Telegram не съдържаше името; поради това съобщението оставаше нормален моделен текст.
  • 9.1.196 добавя изключително reload към съществуващия адресиран списък на Telegram команди.
  • Пътят на Telegram използва същия съществуващ handler като локалната TUI: сесията, MCP сървърите, конфигурацията на средата за изпълнение и TUI се зареждат наново в течащия процес. Не се стартира моделен кръг и не се рестартира процес.
  • /new и другите неразрешени слаш съобщения остават и по-нататък нормален моделен текст.
9.1.195
  • Автоматичните актуализации бяха изпълнени, но рестартираната TUI се озоваваше на C:\ вместо в досегашната проектна папка.
  • TUI водеше правилната папка в state.appState.workDir, но предаваше при предаването на актуализацията само сесия, версия и режим. Launcher-ът използваше затова своята първоначална стартова папка за цел и fallback.
  • 9.1.195 транспортира активната проектна папка в предаването и я използва за целевата версия, fallback и по-нататъшни автоматични актуализации на същото наблюдение.
  • Приемат се само съществуващи абсолютни директории. Относителни, липсващи или сочещи към файлове данни падат обратно върху папката на launcher-а.
9.1.194
  • Съществуващият watchdog на хода предупреждаваше след 20 минути, но не прекратяваше след това даден ход. На Mac един забит ход продължи след предупреждението за 30 минути до най-малко минута 39.
  • 9.1.194 запазва предупреждението след 20 минути и прекратява ход след 30 минути без истински напредък.
  • Началото на стъпката, текстът на размисъл, асистентският текст, извикването на инструмент, аргументите на инструмента, напредъкът на инструмента и резултатът на инструмента нулират срока на неактивност. Дългата активна работа не се прекратява поради това.
  • Съществуващото прекъсване след пет идентични неуспешни извиквания на инструменти остава отделно и непроменено активно.
9.1.193
  • Няколко Telegram доставки пристигаха с идентични chat_id и message_id до четири пъти в същата сесия.
  • 9.1.181 премахваше тези повторения едва по-късно от моделния изглед. Преди това всяко копие можеше да задейства собствен моделен ход и с това разходи.
  • 9.1.193 въвежда поради това преди старта на хода регистър на доставките, ограничен до 2 048 идентификатора. Същият Telegram идентификатор се приема само веднъж на сесия; повторенията се потвърждават, но не се протоколират и не стартират ход на доставчика.
  • Новите идентификатори на съобщения, инжекциите без потребител и суровият запис остават непроменени. При продължаване регистърът се възстановява от приетите записи на промптите.
9.1.192
  • Един Mac показваше след отхвърлено Bash разрешение и по-нататък King is thinking в продължение на 39 минути. Самото извикване на инструмента беше коректно отхвърлено, но отхвърлянето се връщаше като обикновен резултат на грешка към течащия моделен цикъл.
  • PermissionManager.requestToolApproval() връщаше при отхвърляне само block: true. Съществуващото управление на batch и доставчика можеше да прекрати хода вече с syntheticResult.stopTurn = true, но не получаваше този сигнал.
  • Нов е bin/approval-rejection-stop.cjs. Отхвърлените и прекратените разрешения създават вече съществуващ резултат на грешка с stopTurn: true. Текущият ход приключва, а по-късните извиквания на същия стек инструменти се пропускат. Протоколът на разрешенията, политиката и fail-closed поведението остават непроменени.
  • DeepAgents потвърди изричната човешка граница на прекъсване като подходящ модел. AnythingLLM и Evolver не предлагаха за тази тясна грешка по-силен механизъм от вече съществуващия BLUN договор.
9.1.191
  • DeepAgents предлага с /context познато, видимо разделение на контекстния прозорец вместо само една обща стойност.
  • Evolver изисква за работа по производителността отделен бюджет на промпта за системната част, разговора, инструментите и свободното пространство.
  • AnythingLLM спестява схеми на инструменти чрез embedding-базирано reranking. BLUN притежава за това вече по-евтиния Deferred-Tool път без допълнително моделно или embedding извикване; тази част не беше затова дублирана.
9.1.190
  • От постоянно съхранените tool.call loop събития се премахват само полетата за показване display и description. Идентичността, името на инструмента, аргументите и съответствието на стъпката остават запазени.
  • Средата за изпълнение обработва и по-нататък пълното събитие. TUI показването, изпълнението на инструментите и възобновяването не бяха прехвърлени към проекцията.
  • Истински агентски wire с 42.451.368 байта съдържаше 6.135 извиквания на инструменти. При 5.679 от тях можеха да отпаднат 3.125.874 байта: 7,36 % от целия wire протокол.
9.1.189
  • Един потребител беше избрал босненски и пишеше на босненски, но King отговаряше на словенски. В persona промпта стоеше само английската дума Bosnian; тясно свързаното езиково пространство не беше изрично разграничено.
  • Kako si?, Kako je King?, Ko si ti? и Ko stoji iza tebe? не вървяха като самостоятелни босненски кратки диалози. Екранната снимка към Ko stoji iza tebe? показваше дори уеб търсения вместо директен отговор.
  • Докладваният прост check-in изразходваше около 7.500 токена. Досегашният low-effort път позволяваше до 8.192 токена за завършване и задържаше няколко стари съобщения.
9.1.188
  • BLUN разпознаваше реален регрес още след три подобни отговора, но оставяше остарелите отговори изцяло в моделния изглед. Указанието срещу цикъла конкурираше затова и по-нататък със стария грешен статус.
  • DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 доставя модела на индексно стабилни, ограничени заместващи съобщения. AnythingLLM приоритизира най-новите двойки на разговора и третира историята като първо компресируем контекст.
  • Един wire съдържаше 42.265.671 байта, от тях 25.423.100 байта context.append_loop_event. Това доказва реалното loop натоварване, но не се извежда като пряка икономия на токени на заявка.
9.1.187
  • Живо доставеният манифест на 9.1.184 носеше времевия печат 2026-08-26T12:15:06.5196457Z. Доставеният парсер позволяваше само една до три цифри след десетичната запетая и изхвърляше поради това целия манифест.
  • Без валиден fallback ставаше решаващ само npm. При staging на 9.1.185 npm тагът беше затова за кратко видим, въпреки че манифестът стоеше още на 9.1.184.
  • npm тагът беше върнат обратно на 9.1.184. Живият манифест беше коригиран само във времевия печат на 2026-08-26T12:15:06.519Z; версията и цялостта останаха непроменени. Три извличания с изчистен кеш и истинският клиентски парсер потвърдиха след това манифеста.
  • Жив SHA256 след ремонта: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Резервно копие: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • След пълно сгъстяване съществуващият системен промпт не се презаписва вече с новопрочетени локални контекстни данни. Досегашният му префикс остава поради това байтово стабилен и преизползваем за кеша на доставчика.
  • Работната директория, подходящите AGENTS.md файлове и допълнителните директории получават fingerprint. Само при истинска промяна новият статус се прикачва като вътрешно, невидимо за потребителя контекстно съобщение.
  • Вградените контекстни данни се escape-ват преди вътрешната маркировка. Локален текст не може поради това да затвори границата на маркировката или да вмъкне нови системни указания.
9.1.185
  • Два агентски профила се отписаха във времевия обхват на автоматичната актуализация. Независимо от това трети профил остана след успешен преход от 9.1.182 на 9.1.183 на тази версия и не подготви 9.1.184.
  • Две конкретни грешки бяха доказани в пътя на изходния код: TUI се прекратяваше директно след process.send, без да изчака IPC потвърждението. Освен това launcher-ът чакаше след успешно предаване само края на новия процес и не настройваше за него по-нататъшно наблюдение на актуализациите.
9.1.184
  • Обикновените моделни извиквания водеха схемите на инструментите за GenerateImage и GenerateVideo постоянно със себе си, въпреки че измерената употреба на инструменти съдържаше само едно извикване на изображение и нито едно на видео сред 3 183 извиквания.
  • 9.1.184 премахва и двете схеми от постоянно зареждания основен набор. Изрична задача за изображение, видео или анимация зарежда само действително необходимата схема в същия ход.
  • Същият път на избор действа и когато медийна задача пристигне по време на течащ ход. Въпросите за качество, медийните проверки и необвързващите идеи за по-късно не зареждат схема за генериране.
  • И двата инструмента остават достъпни чрез ToolSearch. Промяната не премахва способност, а премества рядко необходимите схеми от обикновените моделни извиквания.
9.1.183
  • BLUN King 9.1.183 прави автоматичната Telegram доставка на готови медии устойчива срещу временни грешки при качване.
  • Клиентът повтаря само ограничен брой временни грешки, изгражда многочастното качване наново при всеки опит и прекъсва веднага при постоянни грешки.
  • Изчерпаните опити за доставка се протоколират отделно, без да се разкрива бот токенът или да се потиска нормалната резервна доставка.
9.1.182
  • Това издание коригира изключително автоматичното актуализиране на течаща King сесия.
  • Launcher-ът задаваше досега BLUN_NO_AUTO_UPDATE=1 в същата среда, която използваха и защитеното ядро, и подготовката на актуализацията на родителския процес. Така старият updater в ядрото беше коректно деактивиран, но и новият родителски проверяващ процес се прекратяваше преди извличането на публичния манифест.
  • 9.1.182 запазва изрично зададено изключване за родителския процес. Принудителното изключване се добавя само при старта на защитеното ядро.
  • Mnemo остава вътрешна, локална конфигурация. Публичният пакет не съдържа Mnemo. Адитивният запис остава напълно неактивен без локален Mnemo път и изрично зададена агентска идентичност.
9.1.181
  • Повтарящите се идентични дълги потребителски задачи и двойните Telegram ID на доставки се премахват изключително от моделната проекция; суровият запис остава непроменен.
  • Конфигуриран Mnemo-MCP се добавя вече към активния King-TUI профил, вместо да остава ограничен до Telegram bridge сесиите.
  • Всичките 413 теста издържаха; и двете целенасочени мутационни проби станаха червени, щом се премахне съответно една от защитните мерки.
9.1.180
  • Автоматичната подготовка на актуализацията не зависи вече изключително от по-късния TUI-ready IPC. Щом защитеното ядро е доказано заредено, launcher-ът стартира подготовката и когато този втори сигнал се е загубил.
  • Границата на сигурност за самото предаване остана непроменена: течащият отговор, сгъстяването, опашката от съобщения, инструментите, shell командите и командите на опашката предотвратяват и по-нататък рестарт по средата на работата.
  • Актуалното състояние доказа грешката: режим resume, инсталация 9.1.177, публично 9.1.179, но подготвена само 9.1.176. Loop-ът не беше следователно първият блокер, защото проверката на празен ход действа едва след подготовката.
9.1.179
  • Чистите потвърждения като ok, ja, danke или perfekt прескачат личния memory broker. Това спестява едно broker извикване и предотвратява при такива бедни на съдържание ходове до 16.384 знака ненужна memory инжекция.
  • weiter, прикачените файлове, въпросите, командите и другите съдържателни съобщения запазват досегашния общ за всички портали път на спомените.
  • Първоначално изграден DeepAgents-подобен буфер на аргументи беше в четири от пет измервателни кръга по-бавен от простото свързване. Той беше напълно изхвърлен и непубликуван.
9.1.178
  • Забавеното търсене на инструменти разпознава вече еднозначен точен първи термин. GetMedia media job status result зарежда поради това GetMedia, без да отстъпва към широко семантично предположение. Двусмислените кратки имена остават умишлено неразрешени.
  • Медийната производствена верига пренася пълните имена на етапите на следващи редове. Последната стъпка не се отрязва вече на десния край.
  • Промяната подобрява избора на инструменти и четимостта. Тя не променя нито медийния модел, нито качеството на изображението и не твърди истински предварителен преглед на медиите.

Подобрения от 9.1.57

ВерсияПромяна
9.1.177Автоматичните актуализации поемат вече записан режим на продължаване или рестарт и когато директното процесно съобщение отсъства, и показват непосредствено преди безопасния TUI рестарт ясен указател. Историческите placeholders за сгъстени аргументи на инструменти се премахват като компактен JSON, форматиран JSON или прочетен обект, преди да могат да бъдат изпълнени отново. Суровият запис и всички съществуващи защитни механизми на актуализацията остават непроменени.
9.1.176Всички менюта за избор на слаш команди разделят вече опциите с празен ред и показват обясненията в отделен, сдържан вторичен цвят. Общата компонента обслужва 20 меню извиквания; индивидуалните предупредителни цветове остават запазени.
9.1.175Повтаряният при всяка моделна заявка указател на инструменти пада от 1 749 на 825 знака. Това спестява в измерването около 231 оценени входни токена на заявка. Всичките единадесет поведенчески задължения остават; суровият запис, схемите на инструментите и файловете остават непроменени.
9.1.174Показваният при всяка моделна заявка откъс от Mistake.md е ограничен до 3 000 вместо 4 000 знака. В 100 истински заявки това спестява средно около 253 оценени входни токена; избраните заглавия останаха във всичките 100 случая идентични. Пълните файлове и съхраненият запис остават непроменени.
9.1.173BLUN King разпознава повтарящи се чисто текстови отговори през няколко Telegram хода. След три почти еднакви отговора въпреки нови потребителски указания агентът получава еднократно вътрешно коригиращо указание, вместо да издаде отново стар въпрос, списък или опашка на изчакване. Съобщенията, процесите и съхраненият запис остават непроменени.
9.1.172Автоматичната актуализация проверява течаща сесия отново след безрезултатно търсене при старта. Следващата проверка става случайно разпределено след 60 до 90 секунди. Така по-късно публикуваните версии се разпознават без ръчен рестарт. Инсталацията и предаването на сесията чакат и по-нататък пълен празен ход.
9.1.171BLUN King запазва на ход само четирите последно дозаредени схеми на инструменти вместо дванадесет. По-старите инструменти остават намерими чрез ToolSearch и се зареждат отново при избор. Постоянно заредените основни инструменти, съхраненият запис и поведението на изпълнение остават непроменени.
9.1.170Обединява актуалните грешки на надеждността и работния процес: повтарящите се задачи запазват най-новата прекомерно голяма инструкция; сгъстените placeholders на аргументи на инструменти се премахват от моделната проекция; ToolSearch разпознава естествени memory думи за търсене включително отделната дума „store“; loop показването зарежда наново плановото състояние; /update управлява безопасното предаване при празен ход; и /premortem предоставя видим, структуриран анализ на грешките.
9.1.169BLUN King запазва точния избор на инструменти и досегашното строго търсене по ключови думи непроменено. Едва когато това търсене не даде попадение, тесен втори прогон търси свързани немски и английски термини. Изискванията за имена с + остават задължителни; най-малко два термина със значение и 75 процента от заявката трябва да паснат. Така трите действително неуспешни Telegram търсения намират актуалния инструмент на опашката, докато неподходяща заявка завършва и по-нататък без попадение.
9.1.168BLUN King не заменя вече по-старите аргументи на извиквания на инструменти с вътрешен placeholder, който моделът може да копира в ново извикване. Вече съществуващите placeholder извиквания и техните резултати на грешки се премахват само от моделната проекция; непромененият запис на сесията остава като доказателство.
9.1.167BLUN King 9.1.167 запазва при повтарящи се планирани задачи само непрекъсната поредица от най-новите пълни работни участъци. Ако следващият по-нов участък би превишил границата от 48 000 знака или 24 съобщения, изборът приключва, вместо след това отново да включи по-стари малки участъци. Така контекстът и времевият ред остават съгласувани. В измерен течащ запис проектираната история падна от 32 591 на 16 981 знака. Това спестява 15 610 знака или около 3 903 оценени входни токена на сравнима заявка. Суровият запис, актуалните стъпки на задачата и обобщението на сгъстяването остават непроменени.
9.1.166BLUN King 9.1.166 ограничава повтарящите се планирани задачи до изолиран работен контекст, вместо при всяка моделна стъпка да предава отново целия разговор на главния агент. Актуалната задача, най-новото обобщение на сгъстяването и най-новите истински работни стъпки остават достъпни в граница от 24 съобщения и 48 000 знака. Съхраненият запис, нормалните потребителски ходове, еднократните спомени и бързите пътища на разговора остават непроменени. В измерен запис 2 043 моделни стъпки на повтарящи се планирани задачи изразходваха общо 298,7 милиона входни токена, средно 146 188 токена на стъпка.
9.1.165BLUN King 9.1.165 ограничава изходния бюджет на нормалните ходове до 24 576 вместо 32 768 токена. Леките стъпки запазват досегашната си граница от 8 192 токена, моделите с по-малки изходни граници запазват тези по-ниски стойности, а изрична потребителска настройка има и по-нататък предимство. От 27 049 измерени отговора 99 процента останаха под 9 970 токена; дванадесет стари отклонения уцелиха точно досегашната граница от 32 768 токена и всяко продължи да изчислява още около шест минути.
9.1.164BLUN King 9.1.164 ограничава изходния бюджет на едно сгъстяване при големи моделни прозорци до 16 384 вместо 131 072 токена. 39 успешни сгъстявания се нуждаеха от най-много 10 781 изходни токена. Новата рамка лежи 52 процента над този измерен максимум и намалява възможната нужда от изход и KV кеш на сгъстяване със 87,5 процента. Съхраненият запис и нормалните разговорни ходове остават непроменени.
9.1.163BLUN King 9.1.163 заменя обширните skill зареждания извън последните 20 съобщения в моделната проекция с компактен указател за дозареждане. Актуалните, малките и недозаредимите skill зареждания остават непроменени; съхраненият разговорен запис не се пренаписва. В измерен случай skill зареждане пада от 87 034 на 424 проектирани знака. Щом напусне актуалния работен прозорец, това спестява 86 610 знака или около 21 653 оценени входни токена.
9.1.162BLUN King 9.1.162 ограничава големите прегледи на работната директория в повтаряния системен промпт до 2 000 знака. Малките прегледи остават непроменени. При съкратени прегледи ясен указател сочи и по-нататък към пълното търсене с Glob, Grep и Read. В измерен промпт прегледът пада от 3 988 на 1 983 знака. Това спестява 2 005 знака или около 501 оценени входни токена на еднакво изградена заявка.
9.1.161BLUN King 9.1.161 не повтаря вече имената на 112-те изнесени инструменти във всяко ToolSearch описание. Търсенето по ключова дума, точният избор чрез пълното или еднозначното кратко име и постоянното зареждане на дванадесетте последно избрани схеми остават запазени. В измереното представяне повтаряното описание пада от 1 984 на 278 знака. Това спестява 1 706 знака или около 426 оценени входни токена на еднакво изградена заявка.
9.1.160От BLUN King 9.1.160 моделната проекция защитава само най-новите дванадесет съобщения пълно, преди по-старите успешни резултати на инструменти, съдържащи изключително текст, да бъдат заменени с кратка бележка за завършване. Изходите на грешки, медиите, съхранените файлови указатели, най-новите дванадесет съобщения, суровият запис и експортите остават непроменени. В стабилно измерена моментна снимка на сесията се смаляват поради това два допълнителни стари резултата на инструменти. Моделната проекция пада от 81 800 на 78 402 знака. Това спестява още 3 398 знака или около 850 оценени входни токена на еднакво изградена заявка.
9.1.159От BLUN King 9.1.159 валидните JSON аргументи на завършени извиквания на инструменти извън най-новите 12 съобщения се заменят в моделната проекция с кратка бележка. Съответният резултат на инструмента, най-новите 12 съобщения, незавършените извиквания, малките или невалидните аргументи, суровият запис и експортите остават непроменени. В стабилно измерена моментна снимка на сесията три аргумента на завършени извиквания на инструменти се смаляват от 2 849 на 165 знака. Това спестява 2 684 знака или около 671 оценени входни токена на еднакво изградена заявка.
9.1.158От BLUN King 9.1.158 чистите статус съобщения, които следват непосредствено след завършен Telegram отговор, се заменят извън най-новите 20 съобщения в моделната проекция с кратка бележка. Изпратеното извикване на отговор и неговият резултат, актуалните съобщения, обобщенията след други инструменти, смесените съдържания, суровият запис и експортите остават непроменени. В стабилно измерена моментна снимка на сесията шест исторически статус съобщения се смаляват с 1 837 знака. Това спестява около 460 оценени входни токена на еднакво изградена заявка.
9.1.157От BLUN King 9.1.157 подходящите успешни, чисто текстови изходи на инструменти извън най-новите 20 съобщения се заменят в моделната проекция с кратка бележка за завършване. Изходите на грешки, медиите, изнесените файлови указатели, най-новите 20 съобщения, суровият запис и експортите остават непроменени. В стабилно измерена моментна снимка на сесията се смаляват 43 стари резултата. Това спестява 9 680 знака или около 2 420 оценени входни токена на еднакво изградена заявка.
9.1.156От BLUN King 9.1.156 съхранените указатели към потребителски съобщения извън най-новите 20 съобщения не повтарят вече своя предварителен преглед с начало и край при всяка моделна заявка. Маркировката за възстановяване, данните за размера, четливият файлов път, най-новите 20 съобщения, медиите, суровият запис, напълно съхраненият файл и експортите остават непроменени. В стабилно измерена моментна снимка се смаляват пет исторически указателя и моделната проекция пада от 99 143 на 96 001 знака. Това спестява още 3 142 знака или около 786 оценени входни токена на еднакво изградена заявка.
9.1.155От BLUN King 9.1.155 съхранените указатели към потребителски съобщения се възстановяват, преди текстовите проекции да могат да променят хеша на първоначалното съобщение. Съществуващите изнасяния остават поради това ефективни, вместо незабелязано да паднат обратно върху проектираното пълно съобщение. Суровият запис, повторно четимите файлови указатели, най-новите 20 съобщения, медиите и експортите остават непроменени. В стабилно измерена моментна снимка моделната проекция пада от 105 810 на 99 143 знака. Това спестява още 6 667 знака или около 1 667 оценени входни токена на еднакво изградена заявка.
9.1.154От BLUN King 9.1.154 адресираните Telegram канални участъци извън най-новите 20 съобщения се ограничават до предварителен преглед от 500 вместо 1 000 знака с начало и край. Пълните канални метаданни, началото и краят на съдържанието на съобщението, най-новите 20 съобщения, прикачените файлове, суровият запис и експортите остават непроменени. В стабилно измерена моментна снимка се смаляват седем допълнителни исторически адресирани участъка. Това спестява 3 500 знака или около 875 оценени токена на повторена заявка.
9.1.153От BLUN King 9.1.153 проекцията на исторически Telegram контексти запазва пълните канални метаданни и затварящия канален таг. Съкращава се изключително съдържанието на съобщението. Дори при реални, 161 знака дълги Telegram метаданни структурата остава валидна в рамките на бюджета от 250 знака. Проекцията е идемпотентна, следващите адресирани канали остават непроменени, а канален плик, който вече без съдържание превишава бюджета, се предава непроменен.
9.1.152От BLUN King 9.1.152 аргументите на завършени извиквания на инструменти напускат активната моделна проекция след четири вместо след осем по-нови съобщения. Суровият запис на сесията, неотговорените или грешно форматираните извиквания, медиите, резултатите на инструменти и най-новите четири съобщения остават непроменени. В прясно измерена моментна снимка на сесията се сгъстяват две допълнителни завършени извиквания; спрямо 9.1.151 това спестява още 244 знака или около 61 оценени токена на повторена заявка.
9.1.151От BLUN King 9.1.151 аргументите на завършени извиквания на инструменти напускат активната моделна проекция след осем вместо след дванадесет по-нови съобщения. Суровият запис на сесията, неотговорените или грешно форматираните извиквания, медиите, резултатите на инструменти и най-новите осем съобщения остават непроменени. В измерена моментна снимка на сесията се сгъстяват три допълнителни завършени извиквания; спрямо 9.1.150 това спестява още 317 знака или около 80 оценени токена на повторена заявка.
9.1.150От BLUN King 9.1.150 историческото изнасяне на резултати на инструменти защитава най-новите четири съобщения пълно вместо най-новите осем. По-старите подходящи резултати на инструменти запазват компактен, 600 знака дълъг указател за възстановяване и своя път на източника; суровият запис, напълно съхранените изходи, медиите и най-новите четири съобщения остават непроменени. В измерена моментна снимка на сесията прозорецът от четири съобщения изнася девет допълнителни исторически резултата и спестява спрямо 9.1.149 още 6 683 знака или около 1 671 оценени токена на повторена заявка.
9.1.149От BLUN King 9.1.149 историческото изнасяне на резултати на инструменти защитава най-новите осем съобщения пълно вместо най-новите дванадесет. По-старите подходящи резултати на инструменти запазват компактен, 600 знака дълъг указател за възстановяване и своя път на източника; суровият запис, напълно съхранените изходи, медиите и най-новите осем съобщения остават непроменени. В измерена моментна снимка на сесията три резултата падат от 4 679 на 1 800 знака; това спестява още 2 879 знака или около 720 оценени токена на повторена заявка.
9.1.148От BLUN King 9.1.148 се смаляват и в най-новия смесен Telegram пакет изрично маркираните с addressed=false канални участъци. Адресираните участъци, медиите, суровият запис и експортите остават непроменени. В измерен запис единадесет неадресирани участъка падат от 22 691 на 2 750 знака; това спестява 19 941 знака или около 4 986 оценени токена на повторена заявка.
9.1.147От BLUN King 9.1.147 микро-сгъстяването защитава най-новите дванадесет съобщения пълно вместо най-новите двадесет и използва по този начин същия прозорец за възстановяване като съществуващото изнасяне на резултати на инструменти. По-старите завършени аргументи на инструменти и подходящите резултати на инструменти се смаляват само в моделната проекция; суровият запис и пътищата за възстановяване остават непроменени. В измерен запис това спестява още 560 знака или около 140 оценени токена на заявка.
9.1.146От BLUN King 9.1.146 по-старите, вече изнесени резултати от инструменти се ограничават в моделната проекция до данните, необходими за възстановяването: име на инструмента, брой знаци и път към файла. Пълното съдържание остава непроменено на диска, суровият запис не се променя, а последните дванадесет съобщения запазват подробните си бележки. В измерен запис това намалява повтарящото се подаване към модела с 26 779 знака, съответно около 6 695 оценени токена на заявка.
9.1.145От BLUN King 9.1.145 прекъснат поток на доставчика се повтаря автоматично, ако до момента са пристигнали само вътрешни мисловни изходи. Видим текст и извиквания на инструменти и по-нататък предотвратяват автоматичното повторение. Адаптивните последващи стъпки с ниско мисловно ниво използват бюджет от 8 192 токена; първите, сложните и неуспешните стъпки запазват конфигурирания бюджет, а повторение след достигане на границата на дължината може да го увеличи. При продължаване на сесия бележката за транспорта на Telegram плъгина вече не се появява като суров чат текст.
9.1.1449.1.144 ограничава адресираните Telegram секции извън последните 20 съобщения в моделната проекция до предварителен преглед от 1 000 знака с начало и край. Последните 20 съобщения, най-новото потребителско съобщение, секциите точно на границата, прикачените файлове, метаданните на канала, суровият запис и експортът остават непроменени.
9.1.1439.1.143 премахва от по-старите съобщения повтарящата се бележка за транспорта на Telegram плъгина от моделната проекция. Съдържанието на канала, метаданните, прикачените файлове, най-новото потребителско съобщение, суровият запис и експортът остават непроменени.
9.1.1429.1.142 намалява предварителния преглед с начало и край за по-стари, неадресирани части на Telegram канала в моделната проекция от 500 на 250 знака. Адресираните части на канала, най-новото потребителско съобщение, прикачените файлове, суровият запис и експортът остават непроменени.
9.1.1419.1.141 премахва аргументите на по-стари, приключени извиквания на инструменти от моделната проекция още от 32 оценени токена. Резултатите от инструментите запазват досегашния си праг; новите съобщения и суровият запис остават непроменени.
9.1.1409.1.140 ограничава напомнянето за Mistake въз основа на уместност в моделната проекция по подразбиране до 4 000 знака. Пълните Mistake файлове, суровият запис и експортът остават непроменени.
9.1.1399.1.139 ограничава по-старите, неадресирани части на Telegram канала в моделната проекция до предварителен преглед от 500 знака. Най-новото потребителско съобщение, адресираните части, прикачените файлове, суровият запис и експортът остават пълни.
9.1.1389.1.138 запазва от всяка повтаряща се Cron задача в моделната проекция само най-новата бележка за събуждане. Еднократните напомняния, различните задачи, суровият запис и експортът остават непроменени.
9.1.1379.1.137 защитава вече само дванадесетте най-нови съобщения изцяло от изнасянето на по-стари резултати от инструменти. Пълните резултати остават възстановими чрез суровия запис и пътя към източника.
9.1.1369.1.136 запазва в моделната проекция само най-новата динамична бележка за Mistake.md. По-старите избрани елементи остават изцяло запазени в суровия запис и в експортите.
9.1.135BLUN King 9.1.135 държи управляваната Node.js среда за изпълнение на първо място в PATH в заместващия процес и във всички подчинени инструменти. Команди като node и npm използват по този начин същата поддържана среда като TUI, вместо да се връщат към по-стара системна инсталация.
9.1.1349.1.134 ограничава неадресираните групови съобщения в Telegram в моделната проекция до предварителен преглед от 2 000 знака със запазени начало, край и първоначална дължина. Директните съобщения и запазеният запис остават пълни.
9.1.1339.1.133 избира от проектния локален и общия Mistake.md най-много пет уместни пълни записа в рамките на общ бюджет от 6 000 знака. Пълните източници и пътищата за съхранение остават запазени.
9.1.1329.1.132 държи активен олекотения основен системен промпт с 4 850 знака след генерираната инициализация. Това спестява 18 259 знака на заявка, т.е. около 4 565 оценени токена, без да премахва инструкции или инструменти.
9.1.1319.1.131 премахва две по-стари копия на правила от моделната проекция, след като решаващите им съответствия са налице. Стандартният промпт намалява по този начин с 1 010 знака, съответно около 253 оценени токена на заявка.
9.1.1309.1.130 заменя извън последните 20 съобщения пояснителния текст на по-стари, напълно приключени стъпки с инструменти с кратък указател. Извикванията на инструменти, резултатите, суровият запис и експортът остават изцяло запазени.
9.1.1299.1.129 премахва предварителните прегледи от по-стари, вече изнесени резултати от инструменти. Пътят и данните за размера остават видими; пълното съдържание остава в оригиналния файл или в частния архив.
9.1.1289.1.128 ограничава постоянния кеш на заредените по-късно схеми на инструменти до дванадесетте най-скоро избрани инструмента. Изместените инструменти остават незабавно откриваеми чрез ToolSearch.
9.1.1279.1.127 съкращава повтаряния каталог на ToolSearch. Еднозначните инструменти се появяват с краткия си селектор; пълните MCP пространства от имена остават само при конфликти на имена.
9.1.1269.1.126 избира от общия за средата за изпълнение файл с грешки детерминистично най-много пет раздела, подходящи за текущия разговор. Проекцията е ограничена до 6 000 знака и не изисква допълнително извикване на модел или мрежа.
9.1.1259.1.125 добавя само четящата Telegram команда /status за свързани потребители. Тя съобщава състоянието на компютъра, версията, процеса и опашката, без да извежда идентификатори на чатове, пътища, тайни или съдържание на съобщения.
9.1.1249.1.124 коригира разменените маркови цветове в компактния знак на BLUN под полето за въвеждане. Стойностите на състоянието, името на профила и персоната остават непроменени.
9.1.1239.1.123 премахва големите JSON аргументи на по-стари, приключени извиквания на инструменти от моделната проекция. Името, идентификаторът, резултатът, суровият запис и експортът остават пълни.
9.1.1229.1.122 зарежда пълното ръководство за дизайн само при визуална работа чрез инструмента skill. Невизуалните заявки получават компактен договор за активиране; по-старите чисто текстови изходи се изнасят същевременно по-ефективно.
9.1.1219.1.121 ограничава общия размер на по-старите чисто текстови изходи на инструменти. Подходящи резултати се архивират частно и се заменят в моделната проекция с четливи препратки към файлове.
9.1.1209.1.120 изнася големи по-стари отговори на асистента в частни файлове на сесията. Последните 20 съобщения, веригите от инструменти и пълният суров запис остават запазени.
9.1.1199.1.119 изпраща при всяка стъпка на модела само малка селекция от често използвани skills. Всички останали skills остават откриваеми чрез инструмента skill по име или предназначение.
9.1.1189.1.118 поддържа стабилен времевия печат на сесията в системния промпт по време на течаща сесия. Непроменените части на промпта могат по този начин да продължат да използват префиксния кеш на доставчика.
9.1.1179.1.117 поддържа четирите основни инструмента за медии незабавно достъпни и зарежда разбирането на изображения и видео, синхронизирането на видео и синхронизирането на движенията на устните само при нужда чрез ToolSearch.
9.1.1169.1.116 добавя проактивно сгъстяване от около 128 000 оценени входни токена на сигурна граница на стъпка. Сгъстяването използва олекотен собствен системен промпт; големите резултати от Read използват съществуващия си път към източника.
9.1.115Продължените сесии изграждат наново системния промпт на текущия профил, така че остарелите прекомерно големи снимки на промпта не просъществуват след рестартиране. Големите прегледи на работната папка се ограничават; пълните файлове остават достъпни чрез Glob, Grep и Read.
9.1.114Доставката на Telegram третира Windows EPERM вече като указание за течащ TUI или poller процес, вместо да отклонява съобщенията от видимата сесия. ToolSearch потвърждава вече зареден инструмент с точно съвпадение на името, вместо погрешно да съобщава, че липсва инструмент, който трябва да се зареди само при нужда.
9.1.113Telegram инструментите запазват при стартирането резервен път в същата среда за изпълнение, ако управляваната регистрация на плъгини временно липсва.
9.1.112Големи по-стари потребителски съобщения се архивират извън текущия работен прозорец; пълният суров запис остава на разположение.
9.1.111Ходовете на Telegram с прикачени файлове получават download_attachment автоматично. При нормални ходове инструментът остава изнесен чрез ToolSearch, така че намаленото натоварване със схеми се запазва.
9.1.110Повторенията след претоварване на доставчика се съобразяват с указанието Retry-After на сървъра. Автоматичната настройка на ripgrep зарежда определените архиви на версия 15.0.0 от официалното издание на ripgrep и проверява техните SHA-256 контролни суми преди инсталацията.
9.1.109Версия 9.1.109 държи постоянно в заявката към модела само деветте инструмента, на които се падат повече от 98 процента от 3 183 измерени извиквания на инструменти. Всички останали инструменти остават откриваеми чрез ToolSearch и след първото зареждане достъпни до края на сесията. По този начин натоварването със схеми намалява при всяка нормална стъпка на модела, без да се премахва инструмент или да се променя бързият път за Telegram отговори и висящи резултати за медии.
9.1.108Идентични, многократно подавани системни бележки се обединяват само в моделната проекция. Променените бележки и пълният запазен запис остават запазени.
9.1.107Грешките на доставчика се показват на разбираем за клиента език; вътрешните кодове за грешки и указанията за поддръжка не се появяват при това. /help предлага списък с команди, управляван с клавишите със стрелки, и отваря с десния клавиш със стрелка или с клавиша Enter подробно описание на избраната команда.
9.1.106Профилите на агенти могат да изключват инструменти по име. Изключенията важат и след динамично зареждане; стандартните подагенти не изпращат Telegram съобщения встрани от главния агент.
9.1.105Версия 9.1.105 добавя TaskUpdate за течащи фонови агенти. King предава допълнителни инструкции на следващата безопасна стъпка на модела на същия активен агент, без да го спира или да стартира друг агент. Неизвестни и вече приключени задачи, Shell задачи и агенти, които вече не приемат актуализации, се отхвърлят непроменено.
9.1.104Версия 9.1.104 оставя Shell командите на преден план да се изпълняват до редовния си край дори при много големи изходи. King записва непрекъснато до 16 MiB в частния протокол на задачата, отхвърля изходите отвъд това и съобщава действителния изходен код, вместо да прекратява процеса заради обема на изхода. Малките изходи, фоновите задачи, времевите граници и ръчните прекъсвания остават непроменени.
9.1.103Членовете на рояка се възобновяват след временни прекъсвания на доставчика под същия идентификатор на агента най-много два пъти. HTTP 429 запазва отделното си правило за претоварване; окончателните грешки и ръчните прекъсвания не се повтарят автоматично.
9.1.102Делегираните отделни агенти се възобновяват след временни грешки на доставчика въз основа на постоянния си запис най-много два пъти. Постоянните грешки и ръчните прекъсвания остават окончателни.
9.1.101Прекомерно големите потребителски съобщения се архивират локално и се заменят в контекста на модела с ограничен предварителен преглед с четим път. Пълният оригинален запис и медиите остават запазени.
9.1.100Ограничените търсения на съдържание с Grep спират ripgrep след поисканата страница и един допълнителен ред за преглед. Броенето на попадения, неограничените търсения и списъците с файлове, сортирани по време на промяна, остават пълни.
9.1.98King може проактивно да сгъсти приключен работен раздел от 128 000 оценени токена. Под прага схемата на инструмента остава изцяло извън промпта на модела; сгъстяването използва съществуващия безопасен преход на стъпка.
9.1.97Постоянно зареденото описание на инструмента TodoList намаля от 2 238 на 996 знака. Многостепенното планиране, всичките шест статуса на задачите, честните съобщения за напредък, запитванията, изчистването и отделният режим на план останаха защитени.
9.1.96Постоянно зареденият основен системен промпт намаля от 23 109 на 4 850 знака. Идентичността, персоната и душата, езикът на отговорите, работните и разрешителните граници, предаването при сгъстяване, средата за изпълнение, AGENTS.md и skills останаха защитени.
9.1.95Постоянно зареденото описание на инструмента Write намаля от 2 532 на 1 541 знака. Разграничението от Edit, дословните съдържания, краищата на редовете, границата от 500 реда, изключението за един файл и атомарното продължение с проверка на броя редове и SHA-256 останаха защитени.
9.1.94Постоянно зареденото описание на инструмента Glob намаля от 1 495 на 1 006 знака. Сортирането, игнорираните и чувствителните файлове, рекурсивните модели, скритите файлове, разширенията в скоби и границата от 100 попадения останаха защитени.
9.1.93Постоянно зареденото описание на инструмента Edit намаля от 1 537 на 1 144 знака. Четенето преди промяна, точните замени, множествените замени, обработката на CRLF и границата от 500 реда останаха защитени.
9.1.92Постоянно зареденото описание на инструмента Agent намаля от 2 061 на 1 153 знака. Отделеният контекст, продължаването, времевите граници и паралелното делегиране останаха запазени.
9.1.91Постоянно зареденото описание на инструмента Read намаля от 2 391 на 1 648 знака. Разделянето на страници, защитата на тайните, препращането на медии, форматът на редовете и поведението при CRLF останаха запазени.
9.1.90Постоянно зареденото описание на инструмента Bash намаля от 5 003 на 1 834 знака. Договорът за изпълнение, фоновите задачи, файловите инструменти и границите за сигурност останаха изцяло запазени.
9.1.89Постраничните четения на файлове посочват при вътрешната граница от 1 000 реда точния следващ line_offset; краят на файла и съзнателно по-малките откъси остават непроменени.
9.1.88BLUN King 9.1.88 активира малкото, беззагубно сгъстяване навреме преди пълното сгъстяване. По-старите големи резултати от инструменти и приключените аргументи на инструменти напускат по-рано изгледа на модела; пълният запазен запис остава запазен.
9.1.87Изрично повторим HTTP 429 отговор се съобразява с Retry-After и получава най-много две автоматични повторения; другите грешки остават незабавно видими.
9.1.86Големите изходи на инструменти запазват в рамките на същия бюджет за преглед по 1 000 знака от началото и от края видими; точна маркировка посочва броя на пропуснатите знаци.
9.1.85Текстовите резултати на инструменти над 12 000 знака се запазват изцяло в частен локален файл; следващите заявки към модела запазват само бюджет за преглед от 2 000 знака и четливия път.
9.1.84Пълното сгъстяване обработва по-стари записи на хронологични стъпки с най-много 64 000 оценени входни токена; фиксираната граница за сигурност и пълният частен архив остават непроменени.
9.1.83Микросгъстяването заменя големите аргументи на по-стари, приключени извиквания на инструменти само в изгледа на модела с валидна JSON маркировка; проверяващият сесията съобщава оцененото спестяване без извеждане на съдържание.
9.1.82Само четящият проверяващ съобщава избраните и задържаните схеми на инструменти, причините за потискане и оценения брой избегнати токени за схеми.
9.1.81Доставен, само четящ проверяващ обобщава стъпките на доставчика, извикванията на инструменти, токените, сгъстяванията, грешките и изнесените изходи, без да разкрива промпти или частни пътища.
9.1.80Големите резултати от инструменти получават телеметрия за изнасяне без съдържание; изолираният контекст на подагенти, машинночетимите планове и прехвърляемите предавания са защитени чрез регресионни тестове.
9.1.79Постоянните контролни точки записват приключени записи на историята преди стъпки на доставчика и преди приключване на работник, така че приключената работа може да бъде прочетена отново след продължаване.
9.1.78Пълното сгъстяване архивира изместените части на историята, преди да ги замени с обобщение; обобщението съдържа четливия път към архива.
9.1.77Микросгъстяването намалява при натиск върху контекста по-стари, големи резултати от инструменти и запазва едновременно пълния запазен запис.
9.1.76Висящите задачи за изображения, видео и реч преживяват сгъстяването и бързите последващи въпроси; Telegram съобщенията остават в FIFO реда без подвеждаща грешка за заетост.
9.1.75Кратките Telegram разговори обработват само най-новото неотговорено съобщение, докато приключените текстови размени остават запазени като езиков контекст.
9.1.74Запаметените Telegram маршрути възстановяват случайно подадени без знак минус идентификатори на групи; Strg+S може да управлява действително течащ ход.
9.1.73Telegram и Loop съобщенията вече не стартират втори ход по време на активна работа; Escape и Ctrl+C могат и по-нататък да прекъснат активния ход.
9.1.72Скриването на бележка за актуализация потиска само предложената по онова време версия; по-новите издания се появяват при нормален старт с king отново.
9.1.71Loop будилниците попадат правилно в опашката, Telegram poller-ът се заема атомарно, централните файлови и медийни инструменти остават незабавно достъпни и Context7 вече не стартира автоматично.
9.1.69Стандартните MCP се настройват, Telegram достига защитена FIFO точка на предаване, Escape и Ctrl+C прекъсват надеждно активната работа и прегледът на MCP скрива вътрешните пътища.
9.1.68Telegram съобщенията в режим на празен ход събуждат FIFO обработката, директните и груповите съобщения запазват реда си на пристигане, а продължаването скрива вътрешните Telegram рамки.
9.1.67Стандартният skill venture-flywheel добавя чисто договорна UVF основа с детерминистично доверие в проекта и задължения за одобрение на външни действия.
9.1.66/curiosity и /scout изпълняват ограничени, само четящи проучвания на възможности с доказателства, контрадоказателства и критерий за прекъсване.
9.1.65Escape и Ctrl+C прекъсват надеждно автоматичните сгъстявания, стабилна котва на екрана предотвратява двойни долни колонтитули, а бележката за Loop е подравнена към съдържанието на чата.
9.1.64Базираният на диска запис на сесията, заредените по-късно инструменти и skills, наблюдателят за празен ход на доставчика от 120 секунди, правилният Loop такт, Telegram в FIFO ред, Linux пакетите и разпознаването на босненски език бяха добавени заедно.
9.1.58–9.1.63Тази серия от версии обедини работата по сесии, Telegram, платформи и производителност. Финалът бяха олекотени схеми на инструменти при поискване, компактни списъци със skills, възстановени skills за първа употреба и инвентарна проверка на пакети срещу непланирани премахвания.

Предишни подобрения

ВерсияПромяна
9.1.53/idea публикува плана си за задачите преди първата работа, проверява изходящите действия при всяко извикване на инструмент и изисква за всяка стъпка честно крайно състояние.
9.1.52Продължените сесии отварят директно запазената работна папка. Разговорът и активният /loop статус се възстановяват заедно при повторно стартиране.
9.1.51Loops работят като автономни будилници, /idea разработва и обработва собствени планове, Telegram може да задейства работни команди, а медийните и стартовите състояния се показват по-ясно.
9.1.50Локални или получени чрез Telegram изображения могат да се анимират като истински MP4 видеа. Големите контекстни прозорци получават валиден бюджет за изход; медийната лента показва по-ясни състояния и кликваеми пътища.
9.1.49Изображения на възрастни фантастични герои по бански остават позволени в ясни граници. Приключени задачи за изображения могат да се използват като изходно изображение за видеа; успешните запитвания GetMedia не създават повторни карти.
9.1.48Единната медийна лента събира медийните задачи директно над полето за въвеждане. Проценти се появяват само с реална измерена стойност на доставчика; иначе тя показва фаза и време на изпълнение.
9.1.47Протоколът на заявките разграничава разговори и сгъстяване и отразява избора на инструменти и причината за потискане, без да променя поведението на инструментите.
9.1.46Loops разбират естествени времеви указания, показват ги по време на въвеждането, поддържат свободни интервали и освобождават нормалния избор на текст в терминала извън изгледа на историята.
9.1.45Текущият напредък на сгъстяването се появява вече само в долната лента за състояние, вместо допълнително като втори ред в чата.
9.1.44Пълно преопаковане на приетата 9.1.43, за да разпознаят актуализацията надеждно и ранните инсталирани версии на 9.1.43.
9.1.43Пълна защитна основа от 9.1.40 с диагностика на транспорта, видими бележки за актуализации и конзолните команди /loop, /goal и /output-style.
9.1.40Пазител на хода за дълги или многократно неуспешни извиквания; само-хеш след многочастен запис с проверка на запазения файл чрез повторно четене.
9.1.39Дългите файлове се записват в продължения. Всяко продължение започва от действително записания край; броят на редовете, SHA-256 и границите на частите се проверяват и извеждат.
9.1.38Изродени или прекъснати аргументи на инструменти се разпознават. Непълен файл се отхвърля със съобщение за грешка, вместо мълчаливо да се счита за готов.
9.1.37След смяна на Node BLUN проверява нативните модули с истинска SQLite заявка и при нужда изгражда отново better-sqlite3.
9.1.36Празните отговори на модела се обработват според причината: твърде малък бюджет за изход се увеличава, празен стоп се повтаря точно веднъж. Системните бележки и инжекциите не могат да задействат Telegram отговор.
9.1.35Многостепенното сгъстяване показва степента и реалното натоварване на прозореца на модела, например 2/~10 · 90 %.
9.1.34Активният контекст се сгъстява на стъпки: най-старите части първо, всяко извикване на сгъстяването под границата на модела.
9.1.33Основа за автоматичната Node среда и последващата поправка на нативни модули след смяна на средата за изпълнение.

Допълнения и отворени пропуски в документацията

Сверка от 17 септември 2026 г.: в диапазона от 9.1.33 до 9.1.597 в npm регистъра присъстват 521 версии. Липсващ номер не означава автоматично липсваща публикация: някои издания липсват в днешния регистър или са оттеглени. При четири публикувани версии точните подробности за промените остават отворени. За тях не се измислят промени.

9.1.567: подробностите за промените са отворени

Публикувано на 6 септември 2026 г. в 22:42 UTC. Стойността SHA-512 на пакета съвпада с публикуваната в npm стойност на целостта. Пакетът не съдържа CHANGELOG.md; неговото README посочва при инсталационната команда все още 9.1.566. От това не може да се изведе надеждно разликата спрямо 9.1.566. Този пропуск в документацията остава изрично отворен.

9.1.550: подробностите за промените са отворени

Публикувано на 2 септември 2026 г. в 07:19 UTC. Стойността SHA-512 на пакета съвпада с публикуваната в npm стойност на целостта. Пакетът не съдържа CHANGELOG.md и в проверения материал не е намерено версионно специфично доказателство за промяна. Този пропуск в документацията остава изрично отворен.

Допълнение към 9.1.536

Следните данни произхождат от публикувания пакет с проверена цялост от 1 септември 2026 г.:

  • Работните задачи продължават и след частните Telegram отговори. След буферирани директни съобщения King продължава работата с ограничена допълнителна стъпка, освен ако потребителят изрично не е поставил на пауза или не е спрял.
  • Кратките запитвания за статус не прекъсват течащия работен процес.
  • Когато опитите за повторение след празни мисловни отговори са изчерпани, King намалява мисловното усилие, вместо да го остави непроменено при по-нататъшни опити.
  • Повече заредени по-късно схеми на инструменти остават достъпни; съобщенията се изнасят едва когато наличното място в записа стане оскъдно.
  • Включени са провереното правило за напредък на TodoList и едноредов начален път за God Mode с Swarm.

Допълнение към 9.1.99

Съществуващата документация на функциите описва съвместното изнасяне на последователни чисто текстови резултати от инструменти: ако стекът надхвърли 12 000 знака, подходящите големи резултати се запазват частно. В контекста на модела остават четливи препратки; суровият запис и медиите остават запазени. Досега липсващият запис за версията препраща вече изрично към тази функция.

9.1.70: подробностите за промените са отворени

Публикувано на 24 август 2026 г. в 15:56 UTC. Стойността SHA-512 на пакета съвпада с публикуваната в npm стойност на целостта. Пакетът не съдържа CHANGELOG.md; наличните описания на функции не доказват еднозначна разлика спрямо 9.1.69. Този пропуск в документацията остава изрично отворен.

9.1.57: подробностите за промените са отворени

Публикувано на 23 август 2026 г. в 07:28 UTC. Изданието се е появило досега само като отправна точка на сборно заглавие. Собствено версионно специфично доказателство за промяна не е приписано в проверения материал. Този пропуск в документацията остава изрично отворен.

Съдържащият се в неизменяемия npm пакет 9.1.597 CHANGELOG.md свършва при 9.1.594. Допълнените бележки за 9.1.595 до 9.1.597 стоят на тази страница. Публикуваният пакет не е пренаписан впоследствие под същия номер на версията.

9.1.41 и 9.1.42 са оттеглени

Не инсталирай

Тези две версии бяха разклонени по погрешка от 9.1.38 вместо от 9.1.40. Поради това липсваха продължаването на записа, само-хешът и пазителят на хода. И двете npm версии са отбелязани като остарели; latest и next никога не са сочили към тях. 9.1.43 съдържа предназначените им промени върху пълната защитна основа.

Актуализиране и проверка

king update
blun --version

След инсталацията на 9.1.599 изходът на версията трябва да показва 9.1.599. Актуализациите от 9.1.597 и от локалната версия 9.1.598 през публичните източници за актуализации са проверени. Вече работеща конзола зарежда новия код едва след рестартирането си. Провери в нея след това допълнително /version.