BLUN King

BLUN King 9.1.621

Megjelent:

A King csak akkor vesz át egy összefoglalót a beszélgetésedről, ha a modell megerősítette annak befejezését. Ha ez a megerősítés hiányzik, a meglévő beszélgetési előzményeid változatlanok maradnak.

Ha az összefoglaló átvitele váratlanul megszakad, a meglévő beszélgetési kontextusod nem helyettesítődik a hiányos összefoglalóval. A változás csak a beszélgetés tömörítését érinti; a normál válaszok változatlanok maradnak.

Továbbra is nyitottak egyes hibák a munkamenet mentésekor; ezeket ez a frissítés nem javítja.

BLUN King

BLUN King 9.1.620

Megjelent:

Windows rendszeren a konzol az ablak bezárásakor teljesen befejeződik, így a következő indításkor már nem jelenik meg a „már fut” üzenet.

A frissítés kijavítja a konzolfolyamat befejezését az ablak bezárásakor. Egy ténylegesen még futó konzol továbbra is megtartja a kizárólagos hozzáférést a saját munkamenetéhez.

BLUN King

BLUN King 9.1.619

Megjelent:

Egyetlen korábbi hiba a beszélgetés tömörítésekor már nem zárolja a munkamenetedet: sikeres tömörítés után a King csak új, közvetlenül egymást követő hibákat számol.

Egyetlen korábbi hiba a beszélgetés tömörítésekor már nem zárolja a munkamenetedet: sikeres tömörítés után a King csak új, közvetlenül egymást követő hibákat számol. Ha a tömörítés kétszer egymás után meghiúsul, az üzenet most egyértelműen „A tömörítés szünetel” feliratot mutat, ahelyett hogy teljes kontextusról számolna be.

Továbbra is nyitottak egyes hibák a munkamenet mentésekor és a beszélgetés teljes összefoglalásának elkészítésekor; ezeket ez a frissítés nem javítja.

BLUN King

BLUN King 9.1.618

Megjelent:

Ha a munkameneted folytatása után Telegram-üzenet érkezik, miközben King már dolgozik, az üzenet a várósorban marad, és King utána kézbesíti.

Ha a munkameneted folytatása után Telegram-üzenet érkezik, miközben King már dolgozik, az üzenet a várósorban marad, és King utána kézbesíti. King ezt a várakozási helyzetet már nem jeleníti meg hibaként.

Linux x64 alatt a terminál egy mellékelt bináris fájlt használ. Így akkor is működik, ha az npm 12 blokkolja a telepítőszkripteket; ehhez nincs szükség fordítóprogramra. Ennek érdekében King a rögzített node-pty 1.2.0-beta.15 előzetes verziót használja.

BLUN King

BLUN King 9.1.617

Megjelent:

Ugyanazon munkamenet újbóli betöltésekor King már nem adja hozzá többször a változatlan plugin-utasításokat.

Ugyanazon munkamenet újbóli betöltésekor King már nem adja hozzá többször a változatlan plugin-utasításokat. Ha az utasítások megváltoznak, King továbbra is figyelembe veszi az aktuális állapotot.

A nagy eszközkimenetek előnézetei mostantól a rendelkezésre álló kontextusablakot is figyelembe veszik. A kihelyezett kimeneteket továbbra is teljes egészében elolvashatod.

A /profile vagy a /profiles paranccsal megnyitod a profilválasztót. King csak akkor vált, ha a munkameneted készen áll. A folyamatban lévő munka és a várakozó üzenetek megakadályozzák az elhamarkodott váltást; ilyenkor a korábbi profilod aktív marad.

Amikor leállítasz egy folyamatban lévő munkát, King az utolsó takarítási lépéseket is megvárja. A még be nem fejezett munkát idő előtt nem erősíti meg leállítottként.

BLUN King

BLUN King 9.1.616

Megjelent:

Egy megerősített Telegram-válasz után King a következő biztonságos lépésnél átveszi a hozzád címzett további üzeneteket, egy folyamatban lévő munkaforduló közben is.

Egy megerősített Telegram-válasz után King a következő biztonságos lépésnél átveszi a hozzád címzett további üzeneteket, egy folyamatban lévő munkaforduló közben is. A már kézbesített válasz többé nem tartja fel a várósort. A válaszok a saját chatjükhöz rendelve maradnak.

Ha megszakítasz egy munkafordulót, a még át nem vett Telegram-üzenetek megmaradnak a következő kézbesítéshez. King csak akkor nyugtázza őket, amikor a munkamenet ténylegesen átveszi őket.

BLUN King

BLUN King 9.1.615

Megjelent:

King a nagy eszközkatalógusokat az eszközkeresésen keresztül tartja elérhetővé, és az eszközköltségvetést a szolgáltató kontextusablakához igazítja.

King a nagy eszközkatalógusokat az eszközkeresésen keresztül tartja elérhetővé anélkül, hogy a modellnek minden opcionális eszköz-sémát elküldene. Ha a szolgáltató kisebb kontextusablakot jelez, King igazítja az eszközköltségvetést; a megtalált eszközök a következő lépésben is elérhetők maradnak.

Szükség esetén King a nagy eszközkimeneteket korábban helyezi ki, mint eddig. A teljes kimenetet úgy kérheted le, mint eddig, amennyiben biztonságosan megjeleníthető.

A normál Telegram-válaszokat és az üzenetmódosításokat már nem tartja vissza hiányzó nyelvi jóváhagyás. Az általad beállított válaszellenőrzés aktív marad.

BLUN King

BLUN King 9.1.614

Megjelent:

A túl nagy AGENTS.md és AGENTS.override.md fájlok többé nem állítanak meg egy munkafordulót pusztán a méretük miatt.

A King-konzolon kívül a King összesen legfeljebb 32 KiB-ot olvas az utasításfájlokból, és munkamenetenként egyszer megmondja a kihagyott bájtok számát.

A King-konzolon belül a fájlok teljesek maradnak, amíg a kérési korlát ezt lehetővé teszi.

A szimbolikus hivatkozások és a nem biztonságos útvonalak blokkolva maradnak.

BLUN King

BLUN King 9.1.613

Megjelent:

A King már az elküldés előtt felismeri a túl nagy modellkéréseket.

A King-konzolon belül a King minden AGENTS.md és AGENTS.override.md fájlból legfeljebb 32 KiB-ot olvas. Ami ezen túl van, azt a King kihagyja, és megmutatja, hány bájt maradt ki.

A King mostantól az elküldés előtt felméri a teljes modellkérés méretét, beleértve az utasításokat, az előzményeket, az eszközdefiníciókat és a képadatokat. Ha a kérés megközelíti a szerver bájthatárát, fokozatos tömörítés kezdődik. Ha egy kérés nem osztható fel biztonságosan, a King megszakítja a műveletet, anélkül hogy csendben eldobná a mentett előzményeket.

A King a befejezett eszközhívásokat helyben tárolja metaadatként: eszköznév, időpont, állapot, fájleszközöknél adott esetben az útvonal. Bemenetek, kimenetek, parancsok és kulcsok nem kerülnek tárolásra. A /memory tools paranccsal keresheted a profilod bejegyzéseit.

A kontextusdiagnosztika további számokat mutat a kérések összetételéről. Egy bekapcsolható fázismérés rögzíti a modellhívásig eltelt időt, tartalom naplózása nélkül.

A felhasználás-kijelzés átveszi a külön jelentett gondolkodási tokeneket, ha a szolgáltató szállítja őket.

Ügyfeleknek nem adták ki, a 9.1.613 váltotta fel

BLUN King 9.1.612

Megjelent:

A 9.1.612 nem jelent meg ügyfél-frissítésként. A korai bájtvédelem nem működött 900 KB feletti kérésnél, amikor az előzmények önmagukban 600 KB alatt maradtak. A 9.1.613 váltja fel ezt az állapotot.

BLUN King

BLUN King 9.1.611

Megjelent:

A nagy tömörítési kérések a szerver bájtos határán belül maradnak.

  • A King a túl nagy tömörítési kérést a kérés mérete szerint időrendi lépésekre osztja fel. Így a tömörítés folytatódhat, még akkor is, ha a kérés több bájtot tartalmaz, mint amennyit a szerver egyszerre el tud fogadni.
  • Ha már egyetlen üzenet sem fér bele a határba, a mentett előzményed változatlan marad. A King nem dobja el, csak hogy kikényszerítse a tömörítést.

Ezzel nem igazolt sem rövidebb modellvárakozási idő, sem alacsonyabb tokenfelhasználás. Egy frissítés nem indítja újra a már futó King-munkamenetet.

BLUN King

BLUN King 9.1.610

Megjelent:

A King-et Linux alatt újra telepítheted, és a profilokat újra elindíthatod; egy második King-indítás Windows alatt már nem vall kudarcot a privát ACL-ekre vonatkozó félrevezető üzenettel.

  • A Linux újra szerepel az npm-csomag támogatott operációs rendszereinek listáján. Ha Linux alatt régebbi verziód van, a 9.1.610-et a normál frissítőn keresztül telepíted.
  • A kifejezett --profile indítások és a meglévő profilnév-rövidítések a kiválasztott profil könyvtárába vezetnek. Egy puszta ismeretlen név többé nem hoz létre csendben üres profilt; új profilt tudatosan a --profile kapcsolóval hozol létre.
  • Ha egy meglévő profilból hiányzik a saját bejelentkezés, King a /login parancsot kínálja fel, ahelyett, hogy egy hiányzó blun/king modellkonfiguráció miatt leállna.
  • Windows alatt a privát könyvtárak ellenőrzése akkor is sikerül, ha a Telegram-bridge egy plugin-könyvtárat nyitva tart. A TEMP és a TMP átadásra kerül az ACL-segédnek, és könyvtárhibák esetén King megnevezi az érintett elérési utat és a tényleges okot.
  • Ha már fut egy interaktív King, King ezt felismeri a privát ACL-ek megszigorítása előtt, és jelenti annak PID-jét, ahelyett, hogy egy második indítást a privát ACL-ek hibájaként tüntetne fel.

Egy üres profil 9.1.610-ben nem vesz át bejelentkezési adatokat a közös home könyvtárból. A jelenlegi /login lekérdezés még „OAuth login expired” üzenetet mutathat, akkor is, ha ez a profil soha nem jelentkezett be.

A Linux frissítési útvonalat 9.1.114-ről 9.1.610-re a megjelenés után lefuttatták. A Windows frissítési útvonal 9.1.609-ről 9.1.610-re nem mérték meg.

Egy frissítés nem indítja újra a már futó King-munkamenetet.

BLUN King

BLUN King 9.1.609

Megjelent:

Nyisd meg az Effort-választót a Ctrl+L billentyűvel, és közben megmarad a szerkesztői piszkozatod.

  • A Ctrl+L megnyitja a meglévő Effort-választót anélkül, hogy elveszítenéd a szerkesztői piszkozatodat. A meglévő Effort-beállítások és modellkorlátozások újra felhasználásra kerülnek, ahelyett, hogy egy második konfigurációs útvonal jönne létre.
  • Az aktív munkamenetekre vonatkozó meglévő szabály érvényben marad: az Effort módosítását aktív munka közben elutasítja a rendszer, nem jegyezi meg későbbre. Lejátszás vagy szerkesztői átvétel közben a billentyűparancs figyelmen kívül marad.

Ezek a változások sem gyorsabb válaszidőt az éles üzemben, sem alacsonyabb kiszámlázott tokenfelhasználást nem igazolnak, és nem hoznak létre teljes OpenClaw-paritást.

BLUN King

BLUN King 9.1.608

Megjelent:

Telegram-csoportokban King-hez már csak azok az üzenetek jutnak el, amelyek megemlítik őt. A többszörös kijelöléseid és a kérdések lépésenkénti megszakítása megmarad.

  • Telegram-csoportokban azok az üzenetek, amelyek nem King-hez szólnak, csak az említés-ellenőrzés után kerülnek a munkamenet kontextusába. Aki kifejezetten kikapcsolta az ellenőrzést, az megtartja ezt a beállítást.
  • A saját többszörös kijelölések és a kérdések lépésenkénti megszakítása megmarad. A cél-lábléc közös frissítési időzítőn fut.
  • A Windows-ACL-átvitel terhelése csökken anélkül, hogy a jogosultság-ellenőrzés gyengülne. A konfiguráció cseréje közben fellépő átmeneti hibák utáni helyreállítás korlátozott; az írási művelet tulajdonjoga megmarad.
  • Az újabb kísérlet előtt King ellenőrzi, hogy egy párhuzamosan eltávolított Windows-írójelölő valóban eltűnt-e. A nem olvasható meglévő jelölők továbbra is megszakításhoz vezetnek.

Ezek a változások sem gyorsabb válaszidőt az éles üzemben, sem alacsonyabb kiszámlázott tokenfelhasználást nem igazolnak, és nem hoznak létre teljes OpenClaw-paritást.

BLUN King

BLUN King 9.1.607

Megjelent:

Visszatér a legutóbb kiválasztott munkameneted, a sikertelen írási műveleteket őszintén jelenti a rendszer, és minden HTTP-kísérlet kezdő időbélyeget kap.

  • A legutóbb kiválasztott munkamenet opcionális visszaállítása a resume_last_selected beállítással aktiválható a tui.toml fájlban. A kijelölés a megerősített fiókra, a futtatókörnyezetre, az ágensre és a munkaterületre vonatkozik. A normál indítás változatlan marad, a kifejezett munkamenet-kijelölések elsőbbséget élveznek; a nem elérhető kijelölések új munkamenetre esnek vissza, nem másikra.
  • Sikertelen aktiválás után az előző kijelölés megmarad. Olyan fiók alatt, amely az aktiválás közben megváltozott, nem kerül sor kijelölés mentésére.
  • A sikertelen fájlírási műveleteket a rendszer nem jelöli sikeresnek. A 2 048 UTF-8 bájt feletti írások teljes soraira vonatkozó meglévő folytatási protokoll magyarázatra kerül, a határ növelése vagy automatikus újrapróbálkozás nélkül.
  • Közvetlenül minden HTTP-kísérlet előtt a diagnózis-korrelációhoz falórán alapuló kezdő időbélyeg kerül rögzítésre. A kérelem tartalma vagy a hozzáférési adatok nem kerülnek a diagnózisba.
  • Az alapsík feletti Unicode-karakterek (például emodzsik) a meglévő tárolási keret határain belül teljesen megmaradnak, anélkül, hogy ezek a keretek nőnének vagy további tároló jönne létre.

Ezek a változások sem gyorsabb válaszidőt az éles üzemben, sem alacsonyabb kiszámlázott tokenfelhasználást nem igazolnak, nem hoznak létre teljes átjáró-paritást, és nem zárják ki a kontextusból a meg nem szólított Telegram-üzeneteket.

BLUN King

BLUN King 9.1.606

Megjelent:

Egy munkamenet folytatásakor először az aktuális átiratoldalak jelennek meg; a régebbi oldalakat a meglévő átirat-navigáció tölti be.

  • Egy interaktív munkamenet folytatásakor először az aktuális átiratoldalak jelennek meg; a régebbi oldalakat a meglévő átirat-navigáció tölti be. A teljes mentett előzmény és az aktív modellkontextus megmarad.
  • Indításkor a megjelenítési cél 200 lejátszási rekord. A --history-limit 1 és 2000 közötti értékével az első és a régebbi oldalak megjelenítése állítható be; a teljes beszélgetési körök és eszközpárok túlléphetik a célt.
  • A skill- és plugin-aktiválások első megjelenítése oldalhatárokon át megmarad. A kezdőlap görgetési pozíciója ki van javítva, így a régebbi oldalak betöltése nem hagy üres képernyőt.

Ezek a változások csökkentik a kezdeti átirat-megjelenítési munkát. Nem igazolnak sem gyorsabb modellválaszidőt, sem alacsonyabb tokenfelhasználást vagy számlákat, nem javítják a szolgáltatói gyorsítótárat, és nem korlátozzák, hogy mennyit olvas a rendszer induláskor a merevlemezről.

BLUN King

BLUN King 9.1.605

Megjelent:

Ellenőrizd a kontextusforrásokat, irányítsd a futó folyamatokat, és adj át egy első üzenetet a konzol indításakor. A helyi előzmények feldolgozása és a tömörítési ellenőrzések bővültek.

  • A helyi munkamenet-előzmények csoportosan kerülnek visszajátszásra. Az archivált megjelenítési oldalak megtalálhatók anélkül, hogy az összes korábbi blokkot át kellene keresni. A teljes mentett előzmény, az archívum integritásellenőrzései és az eddigi visszaállítás megmarad.
  • A megismételt eszközeredmények a naplózott tömörítések között egységesen kerülnek előkészítésre a modellkontextus számára. A teljes helyi kimenetek és a meglévő olvasási jogok megmaradnak. A kimenetek nem kerülnek kihelyezésre, ha az ígért visszaállítási úton nem lennének újra lekérhetők.
  • Az utolsó automatikus tömörítés csak akkor váltja fel az aktív kontextust, ha ugyanazzal a becslési módszerrel kisebbre csökkenti az előzményt. Elutasítás esetén az eredeti előzmény megmarad. Az opcionális max_request_history_bytes trigger a meglévő tömörítésvezérlést használja, alapértelmezésben ki van kapcsolva, és nem korlátozza a szolgáltatónak küldött teljes kérelemtörzset.
  • A kontextusdiagnózis külön nézeteket és forrás-hozzárendelést kap az utasítások, a memória, a skill-ek és a korábbi üzenetek számára. A szerializált tartalom bájtjai, a helyi tokenbecslések és a jelentett felhasználás külön maradnak.
  • A munkamenetért való felelősség megmarad várakozó feladatok, késleltetett események, visszakérdezések és konfigurációs változások esetén. Egy második aktív írási hozzáférés ugyanahhoz a munkamenethez elutasításra kerül, ahelyett, hogy párhuzamos változtatások kerülnének a naplóba.
  • A láblécben lévő kiegészítő ágens-/munkamenet-sor elmarad. A munkamenetek továbbra is célzottan vezérelhetők és diagnosztizálhatók. A meglévő King-felület, a kezelt modellek és a jogosultsági határok megmaradnak.
  • A --message kapcsoló egy első üzenetet ad át az interaktív indításhoz. Az indításkori jóváhagyás és a munkamenet-kijelölés után a normál üzenet-ellenőrzésen és várósoron keresztül kerül feldolgozásra. A tartalma nem kerül értelmezésre perjel- vagy shell-parancsként.
  • A mellékelt Guard-szolgáltatás interfész-megállapodása változatlan marad. Ez a kiadás nem igazol sem gyorsabb válaszokat az éles üzemben, sem alacsonyabb szolgáltatói számlákat, sem teljes funkcionális egyenlőséget az OpenClaw-val, sem korlátozott beolvasási mennyiséget a munkamenetnapló első betöltésekor.

A /abort parancs megszakítja a futó folyamatot anélkül, hogy eldobná a várakozó bemeneteket. A /stop parancs emellett eldobja a várakozó bemeneteket. A /exit továbbra is bezárja a konzolt. Ezek helyi konzolparancsok, nem további Telegram-távoli parancsok.

Ellenőrzések a 9.1.605-ös csomagállapoton: 238 ellenőrző fájl 6 900 teszttel, valamint 40 staging-ellenőrzés, köztük 25 natív terminálellenőrzés. A 9.1.604 izolált frissítésének tesztje a közzétett jelölt-tagon keresztül, a valódi telepítővel sikeres volt. Ez nem igazolja sem a rövidebb bemelegedési időt egy futó munkamenetben, sem a teljes funkcionális egyenlőséget az OpenClaw-val.

BLUN King

BLUN King 9.1.604

Megjelent:

Ellenőrizd a kérések méretét és a kontextusforrásokat, töltsd be az eszközöket szükség szerint, és irányítsd a bejövő üzeneteket az adott munkameneten belül.

  • A /context doctor és a /tokens parancsok megkülönböztetik a szerializált kérelem bájtszámát a becsült tokenszámoktól, és megmutatják a szabályok, a memória, a skill-ek és az eszközdefiníciók rögzített arányait.
  • A közepes méretű eszközkatalógusok szükség esetén a meglévő keresésen keresztül kerülnek betöltésre; az eszközök megtalálhatók és futtathatók maradnak.
  • A /queue parancs az adott munkameneten belül irányítja az üzeneteket. A várósorban lévő szokásos üzenetek már nem szakítják meg a munkát automatikusan 30 másodperc után.
  • A munkamenet-kijelöléskor pontos azonosítók vagy címek, valamint egyedi azonosító-előtagok lehetségesek; a lábléc mutatja a hozzárendelt ágenst és a munkamenetet.
  • Minden HTTP-kísérlet új kérelemazonosítót kap, amennyiben a hívó nem ad meg egyet. A diagnózis nem változtatja meg a számlázást.
  • A mellékelt AgentSpine- és Translate Native-verziók változatlanok maradnak. Az alacsonyabb költségek és a gyorsabb válaszok az éles üzemben nincsenek igazolva.
  • /question: Újra megnyitja a függőben lévő visszakérdezéseket. Az összecsukás nem válaszol meg és nem vet el egy visszakérdezést.

A kérelem bájtjai, a becsült tokenszámok, az összesített munkamenet-felhasználás és a kiszámlázott tokenek különböző mennyiségek. A felhasználás-kijelzés a válasz-ellenőrzést is figyelembe veszi. A /usage cost parancs napi vagy havi költségekkel nem része ennek a változatnak. Az alacsonyabb költségek vagy a gyorsabb válaszok az éles üzemben nincsenek igazolva.

BLUN King

BLUN King 9.1.603

Megjelent:

Válaszd ki a munkakönyvtáradat egy Windows-párbeszédablakban. Ha a konzolt a System32-ből indítják, most a felhasználói mappádat javasolja.

  • Ha Windows alatt másik munkakönyvtárat választasz, megnyílik egy mappapárbeszédablak. Az elérési utat továbbra is kézzel is beírhatod. Ha megszakítod a párbeszédablakot, a mappaválasztóhoz térsz vissza anélkül, hogy átvennél egy mappát.
  • Ha nem áll rendelkezésre mappapárbeszédablak, a konzol lekérdezi az elérési utat. Más operációs rendszereken továbbra is az elérési út beírása marad.
  • Ha indításkor a Windows-könyvtáron belüli mappa kerül átvételre vagy tárolásra, a mappaválasztó a felhasználói mappádat javasolja. A kézzel beírt elérési utak továbbra is az eddigi módon kerülnek ellenőrzésre.

Az AgentSpine és a Language Guard verziói a 9.1.602-höz képest változatlanok. A futó munkamenetek sebességnövekedését ez a frissítés nem igazolja.

Windows alatt továbbra is Git Bash szükséges. Ha a konzol azt jelzi, hogy hiányzik a Git Bash, telepítsd a Git for Windows programot. Ezután nyisd meg újra a parancssort, mielőtt újra elindítanád a King-et.

BLUN King · Megjelent

BLUN King 9.1.602

Megjelent:

Egy saját privát mappa a régebbi eszközkimeneteknek, ha az örökölt Windows-jogosultságok megakadályozzák a kihelyezést.

  • A megfelelő régebbi eszközkimenetek egy saját privát mappában kerülnek elhelyezésre, ha az örökölt Windows-jogosultságok megakadályozzák a kihelyezést. A meglévő fájlok, jogosultságok és a teljes munkamenet-előzmény változatlanok maradnak.
  • Az integritásellenőrzések, az olvasási jogosultságok és a teljes kontextushoz való visszanyúlás megmarad, ha egy archivált kimenet nem állítható vissza. Az AgentSpine 0.73.0 és a Language Guard 6.20.0 a 9.1.601-hez képest változatlan.

A rövidebb válaszidők az éles üzemben vagy az alacsonyabb kiszámlázott tokenfelhasználás még nincsenek igazolva.

BLUN King · Megjelent

BLUN King 9.1.601

Megjelent:

A bemenetek a várósorban maradnak, a régebbi eszközkimenetek ellenőrzött hivatkozásokat kapnak, és a sebességkorlátozott válasz-ellenőrzéseket a rendszer korlátozott számban megismétli.

  • Ha a háttérmunka kerül először sorra, a terminálbemenetek az eredeti sorrendjükben maradnak a várósorban. Minden bemenet csak egyszer jelenik meg.
  • A megfelelő régebbi eszközkimeneteket a modellkérésekben ellenőrzött, privát fájlokra mutató hivatkozások helyettesítik. A teljes előzmény és az aktuális beszélgetési lépés eredményei megmaradnak. Ha az újratöltés nem lehetséges, nem engedélyezett, vagy a tartalom megváltozott, a teljes kimenet elküldésre kerül.
  • Egy sebességkorlátozott natív válasz-ellenőrzés egyszer kerül megismétlésre ugyanazzal a választervezettel. Eközben a szolgáltató elmentett várakozási ideje érvényes. A már befejezett eszközhívások nem kerülnek megismétlésre, az ellenőrizetlen szövegek nem kerülnek jóváhagyásra.
  • Legfeljebb 2 048 kimeneti token marad szabad pufferként a bemenet-becslés eltéréseihez. A kontextusablak nem lesz kisebb; a kisebb, kifejezetten beállított kimeneti korlátok változatlanok maradnak.

Ezek a változások sem alacsonyabb kiszámlázott tokenfelhasználást, sem rövidebb válaszidőket az éles üzemben nem igazolnak. Emellett nem javítanak meg minden szerveroldali HTTP-502-hibát.

BLUN King · Megjelent

BLUN King 9.1.600

Megjelent:

Válasz-ellenőrzés rögzített időkorlátokkal és meghatározott komponensállapotokkal.

A BLUN King 9.1.600 megjelent. Az npm és a nyilvános frissítési manifest egyezik. A megjelenés sem telepítést a gépeden, sem éles üzemi átvételt nem igazol.

Korlátozott válasz-ellenőrzés

  • Az általános ellenőrök megtartják az eddigi 30 másodperces határidőt. A natív nyelvi ellenőrzés a megbízható gazdakomponens indítójelétől számítva legfeljebb 90 másodpercet kap az első tartalmi szövegre, minden külső ellenőrzési kísérletnél egyszer.
  • A tartalmi szöveg a megengedett kimeneti hosszon belül, valamint a jóváhagyásra és a bizonylat-ellenőrzésre vezető rendezett átmenetek minden alkalommal 30 másodpercre állítják vissza a várakozási határidőt.
  • Minden külső ellenőrzési kísérletre ettől függetlenül 120 másodperces összhatár vonatkozik. A haladás nem hosszabbíthatja meg ezt a határt. Továbbra is legfeljebb két külső ellenőrzési kísérlet lehetséges.
  • Egy jóváhagyás elfogadása előtt a ténylegesen eltelt idő ismét ellenőrzésre kerül. Késleltetett időzítőhívások esetén is zárolva marad egy lejárt ellenőrzési kísérlet; a késedelmes haladás nem újítja meg a lejárt határidőt.

A megszakítási jeleket továbbra is figyelembe veszi a rendszer. A pontos válaszszöveghez való kötés, a jóváhagyási bizonylat időbeli érvényessége és az engedélyezés továbbra is ellenőrzésre kerül.

Mellékelt komponensek

A 9.1.600-as verzió az AgentSpine 0.73.0-t és a Translate Native 6.155.0-t tartalmazza. A Guard-protokoll változatlanul 6.20.0 marad.

Ismert korlátozások

Az új időkorlátok nem igazolnak általános megoldást az éles üzemben előforduló HTTP-502-hibákra. A 9.1.599-ből származó nyitott megfigyelések külön élő bizonyíték nélkül nyitva maradnak.

Kontextus és súgó

Egy teljesen megtartandó promptot a rendszer többé nem rövidít meg csendben, csak hogy beleférjen egy kisebb kemény modellablakba. A megtartandó felhasználói üzenetek új, kifejezetten meghatározott felosztásánál a 20 000 tokenes alapkerettel az igazítás ugyanazon a tömörítésen belül befejezhető. Későbbi vagy helyreállított előtagoknál emiatt nem dobhatók el további követelmények. A kérelemnek továbbra is bele kell férnie a kemény modellablakba.

A tiszta súgóhívások --help vagy -h paraméterrel többé nem hoznak létre futásidejű diagnózisállapotot. Ha a prompt- és a súgóargumentumok kombinálva vannak, az eddigi futásidejű viselkedés megmarad.

BLUN King · 2026. szeptember 18.

BLUN King 9.1.599

Megjelent:

Nyomon követhető egyedi jóváhagyások a személyes memóriához és további javítások kontextus-túllépéseknél.

A személyes memória jóváhagyási kérései érthető műveletcímeket mutatnak a kiválasztott nyelven és teljes előnézeteket a tényleges beállításváltozásokról vagy a mentendő szövegről. A vezérlőkarakterek láthatóan maszkolva jelennek meg; az eredeti tartalom változatlan marad.

Az érvényes memóriaváltozásokat egyenként kell jóváhagyni; az érvénytelen bemenetek csak elutasíthatók. Egy munkamenet-jóváhagyás nem hagyja jóvá automatikusan a várakozó kéréseket, amelyek egyedi jóváhagyást igényelnek.

A csomagellenőrzés 37 funkcionális területet ölel fel 199 kötelező ellenőrzéssel, 158 ellenőrzés-végrehajtással és 4 905 különböző sikeres teszttel. Ezenkívül a 9.1.597 és a helyi köztes 9.1.598-as változat frissítéseit 9.1.599-re izolált telepítésekben ellenőrizték, a változatlan frissítővel és telepítési útvonallal. Mindkét teszt felismerte a verziót a nyilvános frissítési forrásokon keresztül, és ellenőrizte a kiadási archívum mind a 918 fájlját.

A változatlan 9.1.599-es csomag README.md és CHANGELOG.md fájljainak útmutatásai a csomagoláskori jelöltállapotot írják le. A helyi telepítés után nem módosították őket visszamenőleg. Ez a nyilvános oldal külön vezeti tovább a megjelenési állapotot és a később megfigyelt korlátozásokat.

Ismert korlátozások a 9.1.599-ben

Az éles üzemben továbbra is ismétlődő HTTP-502-válaszokat figyeltek meg, részben sikeres kérések követték őket. A kontextusjavítások nem általános megoldást jelentenek a szolgáltatói vagy hálózati hibákra.

A nyelvi ellenőrzés megszakíthat egy választ a missing-language-character-profile vagy suspected-ascii-substitution jelzéssel. Ez a megállapítás továbbra is nyitott; a 9.1.599 erre nem tartalmaz igazolt javítást.

Az elküldött képre adott választ a felhasználó megerősítette. A képértelmezés független ellenőrzése, valamint a bemenet és a státuszsorok vizuális átvétele még hátravan. A sikeres csomagellenőrzések nem jelentik azt, hogy ezek a folyamatok általánosan rendben vannak.

A helyi köztes 9.1.598-as változatból átvéve

Dátum nélkül

A 9.1.598-at helyben ellenőrizték és telepítették, de nem jelent meg önálló npm-frissítésként. A következő változások szerepelnek a 9.1.599-ben:

  • Kontextus-elutasítás esetén a bemeneti tokenek számának alsó korlátjait megkülönbözteti a rendszer a pontos megadásoktól. Egy jelentett alsó korlátnál a kimeneti korlát egyszer csökken, üzenetek vagy eszközök eldobása nélkül. A megszakítási jelek és a további kísérletek korlátozása továbbra is érvényes. Ezzel a 9.1.597-ben reprodukált hiba a kimeneti korlát kiszámításánál célzottan javításra kerül.
  • Az eredeti 150 váltakozó aktivitási szó ismét benne van. A megjelenítésükhöz nem kerül sor további modellkérésekre.
  • A megbízható AgentSpine-bemeneti hooknál a teljes médiaadatok helyett egy kompakt médiahivatkozás kerül átadásra típussal, SHA-256 ellenőrzőösszeggel és méretmegadással. A modell teljes mellékletei és a meglévő védelmi ellenőrzések megmaradnak. Ez önmagában még nem igazol sikeres képértelmezést az éles üzemben.

Újdonság a 9.1.597-ben

Megjelent:

Korlátozott helyreállítás kifejezetten jelentett kontextus-túllépéseknél, átjáróhiba-válasz mögött is.

Ha egy kérést a kimenet megkezdése előtt bizonyított kontextus-túllépés miatt elutasítanak, King korlátozott új kísérletet tehet kisebb kimeneti korláttal. Az ennek megfelelően becsomagolt hibák egy 502-válaszban is felismerésre kerülnek. Az üzenetek, az eszközök, a kisebb, kifejezetten választott kimeneti korlátok és a megszakítási jelek megmaradnak. Egy már megkezdett stream nem kerül újra lejátszásra.

Ez nem javítja ki az összes szolgáltatói vagy hálózati hibát. Az általános kapcsolatmegszakításokat és szolgáltatáskieséseket továbbra is a saját hibadataik alapján kell ellenőrizni.

Ismert korlátozás a 9.1.597-ben: Ha a szerver csak alsó korlátot jelent a bemeneti tokenek számához, az ismétlési kísérlet újra kudarcot vallhat, és szükségtelen tömörítéseket válthat ki. Ezt az esetet 2026. szeptember 17-én, a megjelenés után reprodukálták. A helyi köztes 9.1.598-as változat kiegészítő javítása benne van a 9.1.599-ben.

Ellenőriztek 36 funkcionális területet 183 kötelező ellenőrzéssel és 4 407 különböző sikeres teszttel, valamint a valódi frissítést 9.1.596-ról 9.1.597-re. Ez a csomagellenőrzés nem helyettesíti egy már megnyitott ügyfél-munkamenet alkalmazástesztjét.

Újdonság a 9.1.596-ban

Megjelent:

Az automatikus megszakításokat a várakozó Telegram-üzenetek javára a rendszer megkülönbözteti a valódi kézi megszakításoktól. Egy ilyen várósoros megszakítás többé nem kerül tévesen az Escape-billentyű lenyomásaként jelentésre. A várakozási határidő, a futó eszközökre vonatkozó védelmi szabályok és a valódi kézi megszakítás viselkedése megmarad.

Újdonság a 9.1.595-ben

Megjelent:

Az opcionális eszköz-sémák a ToolSearch-en keresztül kerülnek utántöltésre, és korlátozottan tárolódnak. A nagy skill-katalógusok kompaktan és oldalanként állnak rendelkezésre. A keresés, a későbbi MCP-bővítmények és a normál jogosultság-ellenőrzések megmaradnak.

Rövid köszöntéseknél King korlátozott, frissebb párbeszédrészletet használhat, anélkül, hogy elmentett üzeneteket törölne vagy rendszerutasításokat rövidítene. Egy ezt követő munkafeladatnál King ismét figyelembe veszi a megőrzött munkaelőzményt. A kontextuselszámolás egy munkamenet folytatása után is megmarad. Rögzített tokenfelhasználást minden köszöntéshez nem ígér a rendszer.

Újdonság a 9.1.594-ben

Megjelent:

  • A privát Telegram-válaszok lehetségesek maradnak, amíg a csoportüzenetek várakoznak. A perjel-parancsok hozzárendelése megmarad.
  • A Retry-After értékéből adódó hosszú várakozási időket betartja a rendszer; egy munkamenet folytatásakor a hátralévő szünet visszaállításra kerül.
  • Az elvetett kísérőleírás után egy már befejezett eszközlépés tovább kerül feldolgozásra. Az elvetett leírás nem kerül közzétételre, a záró válasz ellenőrzése nem gyengül.
  • A több részben történő írás korlátozott helyreállítási funkciói ismét elérhetők. Ez vonatkozik a shell-időkorlátokra, a feladatvezérlésre és a munkamenet-helyreállításra is.
  • A bemenet, a kvótasorok, az aktivitáskijelzés, a kinyitható feladatok és a forrásjelöléssel ellátott eszközkimenetek streameléskor és az előzményben való navigáláskor láthatók maradnak.
  • A csomagolás előtt teljes konzol-regressziós bizonyítékok szükségesek; a nyilvános frissítési metaadatok egyezését a rendszer ellenőrzi.

Köztes változatok 9.1.590 és 9.1.593 között

Ezek a változatok a helyi kiadási előzményben megtalálhatók, 2026. szeptember 17-én azonban nem szerepelnek a nyilvános npm-verziókatalógusban. Itt nem szerepelnek ajánlott, nyilvánosan elérhető frissítésként. Az indítással, a folytatással, a jogosultságokkal, az aktivitáskijelzéssel és a látható bemenettel kapcsolatos munkák figyelembe vannak véve a 9.1.594-hez tartozó bizonyítékokban.

Újdonság a 9.1.589-ben

Megjelent:

  • Az AgentSpine és a Translate Native ellenőrzött forrásai, valamint a verifikált frissítési manifestek mellékelve vannak.
  • Az ágenskontextus betöltésekor az aktív King-profil megmarad.
  • A válasz-ellenőrzéshez szükséges eszközök elérhetők maradnak. A válasz-előállítás felhasználása akkor is rögzítésre kerül, ha az ellenőrzés elveti a választ.
  • A felügyelt csatorna-kapcsolódásban a csoportüzenetek csak kifejezett említés esetén kerülnek hozzárendelésre.
  • A konzol megmutatja a futó tömörítést és a érvényes küszöbértékeket.
  • A korai tömörítés munkakerete és a kéréshatár biztonsági tartaléka frissítéseken át megmarad.
  • Az indításkori frissítési párbeszéd, a folyamatjelzés és az előjegyzett frissítésekre utaló megjegyzések végig a kiválasztott nyelvet használják.
  • A technikai integrációs azonosítók és licencek megmaradnak; a látható futásidejű hibaüzenetek semlegesen vannak megfogalmazva.
  • A telepítés nem indítja újra a meglévő munkameneteket. Egy futó munkamenet a következő indításkor tölti be az új kódot.

9.1.588: visszavonva

Megjelent:

Ezt a változatot 2026. szeptember 11-én tették közzé, majd az npm-ben visszavontként jelölték. A registry a frissítési manifest sikertelen kompatibilitás-ellenőrzését nevezi meg. Használd az aktuális stabil változatot, ne ezt a visszavont csomagot.

Újdonság a 9.1.587-ben

Megjelent:

Stabilabb eszközkatalógusok, korábbi automatikus tömörítés és célzott ismétlési kísérlet a túl hosszú tiszta gondolkodási fázisok miatti megszakítások után.

Pufferelt utasításoknál egy futó munkafordulón belül az aktív eszközkatalógus a következő munkalépésben is megmarad. A szükséges eszközök elérhetők maradnak. Ha a meglévő séma-keret túllépésre kerül, a megtartott opcionális eszközdefiníciók újra kiválasztásra kerülnek.

Az automatikus kontextus-tömörítés ismét korábban indul. Egy sikeres, az előzményt kisebbítő tömörítés után King ugyanabban a fordulóban újra futtathatja. Az alacsonyabb modellkorlátok és a sikertelen kísérletek korlátozása érvényesek maradnak.

Egy túl hosszú tiszta gondolkodási fázis miatti megszakítás után King a meglévő egyszeri ismétlési kísérletet használja kikapcsolt gondolkodással, hogy a modell válaszolhasson vagy eszközt hívhasson. A következő szabályos lépések megtartják a kiválasztott gondolkodási beállítást; a megszakítás, a jóváhagyás-ellenőrzések és az időkorlátok érvényesek maradnak.

BLUN_STABLE_STEER_TOOLS=0 vagy BLUN_EARLY_COMPACTION=0 értékkel a King indítása előtt az adott funkcióhoz visszaállítható az eddigi viselkedés. A frissítés nem ír át meglévő munkameneteket vagy konfigurációs fájlokat.

Újdonság a 9.1.586-ban

Megjelent:

A Telegram-vétel Windows alatt újra elindul, ha a bridge régi folyamatazonosítója időközben egy másik folyamathoz tartozik. Bizonytalan folyamat-hozzárendelésnél King nem avatkozik be; az idegen folyamat nem kerül leállításra.

A kontextus-tömörítés, a modellbeállítások, a beszélgetési előzmény és a Telegram eddigi kézbesítési viselkedése változatlan marad.

Újdonság a 9.1.585-ben

Megjelent:

BLUN King · 2026. szeptember 8.

A 9.1.585-ös verzió a felügyelt WebSearch-válaszok szerkezetét és egyes találatait akkor is ellenőrzi, ha az opcionális keresési állapotadatok hiányoznak.

Az érvényes találatlista nélküli válasz többé nem kerül kiadásra sikeres, találat nélküli keresésként. Minden találatnak címet (amely nem üres és nem csak szóköz), szöveges kivonatot karakterláncként és abszolút HTTP- vagy HTTPS-címet beágyazott hozzáférési adatok nélkül kell tartalmaznia. Az érvénytelen találatok a teljes válasz elutasításához vezetnek, mielőtt eredmények vagy a hiányos keresési eredményekre utaló jelzések visszaadásra kerülnének.

Az érvényes, eddigi formátumú, állapotadatok nélküli válaszok továbbra is támogatottak, csakúgy mint az üres találatlisták és az üres karakterláncok szöveges kivonatként. Érvényes válaszoknál a sorrend, a pontos URL-karakterláncok, az opcionális dátum- és webhelyadatok, a kimenetben szereplő forrásmegjelölések és a hiányos eredmények feldolgozása változatlan marad.

Csak a felügyelt keresési kapcsolódás változik. A megszakítási viselkedés, a kérések hitelesítése, a FetchURL és a Telegram változatlan marad. A formátum-ellenőrzés nem igazolja, hogy egy forrás helyes vagy aktuális. Ez a verzió sem válaszméret-korlátot, sem új időkorlátot nem vezet be.

Újdonság a 9.1.584-ben

Megjelent:

A 9.1.584-es verzió továbbítja a hívó megszakítási jelét a WebSearch-en át a felügyelt HTTP-keresési kérésig, a válasz tartalmának olvasásakor is.

A már megszakított keresések nem váltanak ki feldolgozást a szolgáltatónál. Ha a megszakítás a hozzáférési adatok lekérdezése közben történik, utána már nem kerül elküldésre keresési kérés. A megszakítás után beérkező eredmények nem kerülnek visszaadásra sikeres keresésként.

A megszakítás-ellenőrzések a sikeres JSON-válaszokat, a hibaválaszok tartalmát és a hiányos keresési eredményekre utaló jelzéseket is lefedik. A teljes, hiányos és üres eredmények feldolgozása, a forrásmegjelölések és a hitelesítés szokásos tartalék eljárása változatlan marad.

Ez a verzió nem vezet be új időkorlátot, és nem változtatja meg a Telegram-hozzárendelést. A megosztott OAuth-hozzáférési adatok megújítására szolgáló folyamatok és azok a szállítási implementációk, amelyek figyelmen kívül hagyják a megszakítási jeleket, nem kerülnek kényszerített megszakításra. Egy klienskérés megszakítása nem igazolja, hogy a távoli szerveren folyó munka vagy annak számlázása befejeződött.

Újdonság a 9.1.583-ban

Megjelent:

Az oldalletöltés megszakítása mostantól a HTTP-kérésig továbbításra kerül.

A FetchURL továbbítja a hívó megszakítási jelét az eszközön és mindkét lekérési szolgáltatáson át. A start előtt megszakított kérés nem kerül elküldésre. Ha a megszakítás a hozzáférési adatok lekérdezése közben történik, a felügyelt HTTP-kérés utána már nem indul el.

Egy felügyelt lekérés megszakítása után többé nem indul helyi tartalék lekérés. A lekérési szolgáltatás késve érkező eredménye visszatartásra kerül, és nem használható forrásigazolásként. Szokásos HTTP- és hálózati hibáknál az eddigi helyi tartalék lekérés lehetséges marad.

Nem kerül bevezetésre új időkorlát. A hozzáférési adatok megosztott megújítása és a szinkron HTML-feldolgozás nem kerül kényszerített megszakításra. A 9.1.582-ből származó méretkorlát érvényben marad; a Telegram-útválasztás és a modellkérések változatlanok maradnak.

Újdonság a 9.1.582-ben

Megjelent:

A helyi oldalletöltés már a beolvasás közben ellenőrzi a válasz méretét, és a határ túllépésekor megszakítja a beolvasást.

A helyi lekérés a dekódolás előtt számolja meg az egyes adatblokkok beérkező válaszbájtjait, és a méretkorlát túllépésekor leállítja az adatfolyamot. Ha a Content-Length megadás hiányzik vagy hibás, a rendszer többé nem olvassa be először a teljes választ, hogy aztán elutasítsa.

Az alapértelmezett határ továbbra is tíz MiB, és a HTTP-kitömörítés utáni válaszfolyamra vonatkozik. A több adatblokkra elosztott UTF-8 karakterek megmaradnak. A szállítási pufferek és az a blokk, amellyel a határ túllépésre kerül, már a memóriában lehetnek; ehhez nem kapcsolódik pontos felső határ a teljes folyamatmemóriára.

A helyi lekérési út változik, akkor is, ha tartalék megoldásként szolgál. A 9.1.581-ből származó kutatási javítások benne maradnak. A Telegram-útválasztás és a modellre várás változatlan marad.

Újdonság a 9.1.581-ben

Megjelent:

A helyi oldalletöltésnél az üres HTML-kivonatok többé nem kerülnek kiadásra sikeres forrásként.

Ha a tisztítás és átalakítás után nem marad oldaltartalom, a dokumentum címe önmagában már nem elegendő a sikeres lekéréshez. Ehelyett a már meglévő kinyerési hiba kerül visszaadásra.

A rövid, valódi tartalmak és a látható címsorok megmaradnak. Az egyszerű szöveges vagy Markdown formátumú válaszok változatlanok maradnak. A javítás a helyi HTML-kinyerést érinti, nem a felügyelt lekérési szolgáltatást.

A 9.1.580-ból származó kutatási javítások és az eddigi Telegram-javítások változatlanul benne vannak. Ez a frissítés sem a modellre várást, sem a bejövő üzenetek címzettjeihez való hozzárendelését nem változtatja meg.

Újdonság a 9.1.580-ban

Megjelent:

A kutatási tárolás elutasítja a forrásokhoz tartozó érvénytelen történeti dátumadatokat.

Új jelentés nem kerül mentésre, ha egy forráshoz tartozó dátumadat érvénytelen naptári napot vagy nem kiértékelhető időrészt tartalmaz. A hiányzó dátumadatok megengedettek maradnak.

A mentett kutatási bizonylatok lekérésekor a régebbi, érvénytelen forrásdátumokat tartalmazó bizonylatok kihagyásra kerülnek, és diagnózismegjegyzéssel kerülnek jelentésre. A fájlok nem íródnak át és nem törlődnek. A különálló érvényes bizonylatok kereshetők maradnak; az érvényes dátumadatok megtartják időzóna-eltolásukat és pontosságukat.

A 9.1.579-ből származó kutatási bizonylatok rendezése és az eddigi Telegram-javítások változatlanul benne vannak. Ez a frissítés sem a modellre várást, sem a bejövő üzenetek címzettjeihez való hozzárendelését nem változtatja meg.

Újdonság a 9.1.579-ben

Megjelent:

A mentett kutatási bizonylatok azonos relevancia esetén a tényleges lekérési időpontjuk szerint kerülnek rendezésre.

Az időadatok ezredmásodperccel és anélkül UTC-időpontként kerülnek összehasonlításra, nem szövegként. A relevancia továbbra is elsőbbséget élvez; azonos időpontoknál az eddigi sorrend megmarad.

Ha ugyanaz a szöveghely többször került rögzítésre, az eredmény a legújabb lekérés származási adatait tartja meg. A már mentett bizonylatok változatlanok maradnak, és emiatt nem számítanak újonnan ellenőrzött forrásnak.

A 9.1.578-ból származó Telegram-válasz javítása változatlanul benne van. Ugyanez vonatkozik az ismételt kísérletek korlátozására, amikor a modell kizárólag gondolkodik, válasz vagy eszközhívás nélkül. Ez a frissítés sem a modellre várást, sem a bejövő üzenetek szemantikai hozzárendelését nem változtatja meg.

Újdonság a 9.1.578-ban

Megjelent:

Korlátozott ismétlések, amikor a modell csak gondolkodik és közben eléri az időkorlátot, valamint célzott javítás a rövid Telegram-csoportválaszokhoz, amelyek egy kérdésre utalnak.

Ha a modell eléri az időkorlátot, miközben csak gondolkodik, King lépésenként egy további kísérletet engedélyez. Egy második ilyen időtúllépés befejezi a lépést. A kiválasztott gondolkodási erőfeszítés és az eddigi időkorlát változatlan marad. Ez a korlátozás nem rövidíti az első modellkimenetre várást.

A rövid, saját jelenlétre vonatkozó visszajelzések Telegram-csoportokban mostantól elküldhetők, ha a reply_to egy legfeljebb 30 perces, ugyanabból a csevegésből származó bemenethez kapcsolja őket. Ennek a bemenetnek kifejezetten az ágenshez kell szólnia, vagy egy támogatott német vagy angol, a jelenlétre vonatkozó kérdésnek kell megfelelnie, amely a beállított névvel kezdődik. A nem kért jelenléti jelentések és a „nincs jelenteni való” magyarázatok továbbra is szűrésre kerülnek. Az automatikus tartalék elküldés csoportokban kikapcsolva marad.

Az elküldött és elnyomott válaszok naplói mostantól tartalmazzák a reply_to értéket. Hiányzó vagy nem egyértelmű kontextus esetén a kivétel nem érvényes. Ez a frissítés nem ad hozzá általános címzett-felismerést, és nem akadályozza meg a szükségtelen modellhívásokat az eddigi szemantikai címzés révén.

A javítás a felügyelt Telegram-MCP-küldők két pontosan azonosított verziójára vonatkozik, és a plugin-konfiguráció végleges összevonásakor is érvényesül. A régebbi küldő kompatibilitási másolatot használ szigorúan korlátozott változtatásokkal. A bemeneti bridge-ek, a hozzáférési beállítások, a profilok és a plugin-regiszterek nem íródnak át. Az ismeretlen vagy módosított küldők és a kifejezetten beállított felülírások megmaradnak. King-et a frissítés után újra kell indítani, hogy a javítás betöltődjön.

Újdonság a 9.1.577-ben

Megjelent:

Nincs több automatikus befejezési jelentés a Telegram-csoportokban. A hasznos válaszokat ott célzottan, a Telegram-válasz eszközön keresztül küldi a rendszer.

A CLI-mag és az önálló Telegram-bridge többé nem továbbítja automatikusan egy ágens normál befejező szövegét csoportoknak. Így az olyan megjegyzések, mint a „Nincs jelenteni való”, többé nem kerülnek ilyen automatikus tartalék elküldéssel a csoportba.

A privát csevegésekben adott válaszok, a kifejezetten használt válasz eszközök, a szükséges céleredmények, a parancs- és állapotüzenetek, valamint a média-küldés megmarad. A normál bemenetekre, a futó folyamat közbeni vezérlőüzenetekre és az önálló bridge csoportüzeneteire vonatkozó prompt-utasítások mostantól ugyanazt a küldési szabályt tartalmazzák.

Ez nem garantálja, hogy egy modell soha nem küld szükségtelen választ eszközhívással. A javítás azt sem akadályozza meg, hogy az adott ágenshez nem kapcsolódó csoportüzenetek elérjék a modellt. Az említési szabályok, a hozzáférési beállítások és a felügyelt pluginok feloldása változatlan marad; az AgentSpine vagy a Language Guard frissítése nem része ennek.

A frissített magot egy új folyamatnak kell betöltenie. A futó munkamenetek nem indulnak újra automatikusan. A meglévő profilok és a munkamenet-előzmény megmaradnak.

Újdonság a 9.1.576-ban

Megjelent:

A BLUN King 9.1.576 megkülönbözteti a C++ és a C# kifejezéseket a helyi kutatási lekérdezéseknél, és tartalmazza a korábban közzétett javításokat a frissítésekhez, a munkamenetek folytatásához és a Telegram-hoz.

A helyi kutatási bizonylatok keresése az önálló C++ és C# kifejezéseket különböző fogalmakként kezeli, eltérő nagy- és kisbetűknél és környező írásjelekkel is. A mentett szöveghelyek, a hashek, a források védelmi ellenőrzései, a Unicode-normalizálás, a gyűjteményhatárok és a kimeneti korlátok változatlanok maradnak. Újraindexelés nem szükséges.

Egy rögzített ellenőrzési futás 20 technikai keresési lekérdezéssel és célzott regressziós tesztek a tokenhatárokhoz ellenőrzik ezt a javítást. A helyi keresést érinti, és nem jelent állítást a WebSearch minőségéről vagy kapacitásáról az éles üzemben. A 9.1.575 összes változása benne marad.

Újdonság a 9.1.575-ben

Megjelent:

A csomagolt webcrawler elutasítja a cf-mitigated: challenge jelzéssel ellátott válaszokat, mielőtt tartalmakat olvasna, átirányításokat követne, vagy egy hiányzó robots-fájlt a folytatás engedélyeként értékelne. A fejlécneveknél nem veszi figyelembe a nagy- és kisbetűket; emellett normalizált értékeket és többször előforduló fejléceket is ellenőriz. A válasz állapota a hibajelentésben megmarad.

A hiányzó, ilyen jelzés nélküli robots-fájlok és a szokásos dokumentációs oldalak továbbra is a meglévő folyamaton mennek keresztül. A már befejezett oldalak elérhetők maradnak, ha egy későbbi oldal elutasításra kerül; a hiba hiányos eredményként kerül jelentésre. Ez a védelem egy válaszjelzést ellenőriz. Nem általános challenge-felismerés és nem CAPTCHA-megkerülés. A keresési szolgáltatók, a hitelesítés, a frissítési zárak és a CLI-mag változatlanok maradnak. A 9.1.574 összes változása benne marad.

Újdonság a 9.1.574-ben

Megjelent:

A kifejezetten kért frissítések mostantól megkülönböztetik a blokkolt frissítést, a nem elérhető zárellenőrzést, a nem elérhető privát könyvtárat, az érvénytelen telepített verziót és a nem elérhető védett telepítőt. Ezek az esetek többé nem kerülnek általánosan sikertelen csomagellenőrzésként jelentésre. A változás a német és az angol üzenetekre vonatkozik.

A frissítés-engedélyezés, a zár viselkedése, a visszaadási okok, a kilépési kódok és a telepítő viselkedése változatlan marad. A futó munkamenetek nem kerülnek automatikusan leállításra. Azok a csomagok, amelyek régi belső csatornára vannak rögzítve, továbbra is kifejezett npm-telepítést igényelnek leállított King mellett; ez a verzió nem oldja fel a rögzítést. A 9.1.573 összes változása benne marad.

Újdonság a 9.1.573-ban

Megjelent:

A beviteli mező az indításkori célkiválasztás után látható és fókuszált marad, az Escape vagy egy sikertelen cél-folytatás után is. Az elküldetlen piszkozatok megmaradnak. A teljes célszöveg helyett kompakt kiválasztás jelenik meg a cél nélküli vagy azzal történő folytatáshoz.

A Ctrl+S elhagyja a kiválasztást a cél megerősítése nélkül, és szabályos billentyűparancsként kerül feldolgozásra a várósorhoz. A tétlen állapotban lévő függő bemenetek is figyelembevételre kerülnek. Az Escape megtartja az eddigi sorrendjét: először a várósor ürítése, a következő Escape-nél az aktív futás megszakítása. A munkamenet-előzmény nem kerül automatikusan törlésre.

Ez a verzió nem rekonstruálja azokat a kézbesítési visszaigazolásokat, amelyeket egy régebbi folyamat a frissítés előtt elveszített. A ténylegesen függő üzenetek a munkamenetükhöz rendelve maradnak.

Újdonság a 9.1.572-ben

Megjelent:

A kutatási bizonylatoknál azok a forrás-URL-ek kerülnek elutasításra, amelyek lekérdezési paraméterei vagy paraméterszerű töredékei ismert hozzáférésiadat-paraméterneveket tartalmaznak. A beágyazott nevek és a töredékben lévő útvonalak is ellenőrzésre kerülnek. Az elutasítás a sikertelen és a használható forrásokra egyaránt vonatkozik.

A már mentett, ilyen URL-eket tartalmazó jelentések a lekéréskor a meglévő partial / report-invalid eredménnyel kerülnek visszatartásra. Az eredetileg mentett állapotok nem változnak és nem törlődnek; a forráscímek nem kerülnek csendben rövidítésre vagy átírásra. A szokásos lekérdezési paraméterek és horgonyok a dokumentációs URL-ekben bájthűen megmaradnak. A védelem ismert paraméterneveket ismer fel, nem tetszőleges titkokat, és nem tisztítja az előzményt.

Újdonság a 9.1.571-ben

Megjelent:

A Telegram-várósor területei a munkamenetükhöz kerülnek hozzárendelésre. Egy új munkamenet többé nem veszi át automatikusan egy régebbi munkamenet függő munkáját. Egy ismert munkamenet folytatásakor csak annak saját várakozó területei kerülnek visszaállításra. A munkamenet kiválasztása, létrehozása és váltása közben a csatornaüzenetek átvétele szünetel. Azok az üzenetek, amelyek a kiválasztott határ után érkeznek, a helyi szerkesztőben adott további bemenetek és a késve érkező kézbesítési visszaigazolások megtartják a helyes hozzárendelésüket.

A hozzárendelés és az eltérő sorrendben érkező kézbesítési visszaigazolások megmaradnak az újracsatlakozásnál és egy lease átadásánál. A sérült vagy kicserélt várósor-állapot elutasításra kerül, ahelyett, hogy régi bemeneteket észrevétlenül újra lejátszana. A bejövő üzenetek és a munkamenet-előzmény megmaradnak. A felismerhető munkamenet nélküli régi várakozó területek visszatartásra kerülnek, és nem kerülnek új munkamenethez hozzárendelésre; az automatikus visszaállításuk nem része ennek. Ez nem javít meg minden időtúllépést vagy blokkolt kontextus-tömörítést. A visszalépés nem eljárás a várósor migrálásához.

A Telegram-plugin és a konzol független tartalék funkciója az automatikus válaszküldéshez elnyomja a felismert fogadási visszaigazolásokat és azokat a szövegeket, amelyek csupán a saját hallgatást jelentik be, 200 karakter felett is. Ha egy üzenet fel nem ismert vagy tartalmilag releváns mondatrészt tartalmaz, megmarad. A rövid, hasznos csoportfigyelmeztetések továbbra is kézbesíthetők. Ez egy óvatos német-angol küldési szűrő kiegészítő utasításokkal, nem garancia arra, hogy minden modell minden csoportbeszélgetést megért.

Egy új folyamatnak kell betöltenie a frissített csomagot; a futó munkamenetek nem indulnak újra. A meglévő belső frissítési csatornákra való rögzítések és a Windows-telepítési zárak EBUSY-val külön problémák maradnak. A 9.1.570 összes többi változása benne marad. Ez a verzió nem aktivál hosztolt webes keresést, és nem változtat sem az AgentSpine-on, sem a számlázáson, a hitelesítésen vagy az ügyfélkonfiguráción.

Újdonság a 9.1.570-ben

Megjelent:

Minden új prompt-kézbesítés saját hook-korrelációs azonosítót kap. Az azonos kézbesítéshez tartozó hookok megtartják ugyanazt az azonosítót; a kifejezetten beállított azonosítók megmaradnak. A munkamenet-specifikus környezeti értékek elérik a hook-alfolyamatokat és az MCP-kapcsolatokat újracsatlakozáskor is, mentett plugin-konfigurációk átírása nélkül. A natív eszközeredmények hozzárendelése futásokon át megmarad, sikertelen eszközök és duplikált hívások esetén is.

A kanonikusan egyenértékű Unicode-kutatási lekérdezések ugyanazokat a találatokat találják meg, anélkül, hogy a különböző karaktereket azonosként kezelnék. A mentett források, dátumadatok, verziók és projektkorlátok megmaradnak. A king --help és a king --version többé nem módosítja a Windows beállításjegyzékében az összeomlási memóriaképekre vonatkozó beállításokat.

A webes keresés támogatja a részleges válaszokat, ha ebben a válaszmódban megállapodtak, és közben jelzést mutat a kiesett forrásokról. Az üres vagy nem kompatibilis részleges válaszok kifejezett hibák maradnak. Ez a kliensváltozás nem aktivál hosztolt keresési szolgáltatást, és nem garantálja annak működését.

A BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE szállítás alapértelmezésben ki van kapcsolva. Kifejezett aktiválásnál átadja a mentett munkamenetnapló tényleges elérési útját és a hozzá tartozó naplót a kiválasztott AgentSpine-pluginnak. Minden munkamenet saját hozzáférési jogosultságot kap, egy folytatás után megújításra kerül. Ez szállítási támogatás, nem bizonyíték az emlékezet-lekérésre vagy a fogadó plugin általi engedélyezésre.

A 9.1.569 összes nyilvános változása benne marad. A csomagolt AgentSpine-implementáció változatlan marad; nem jön létre Mnemo-függőség. A felhasználói profilok, a jogosultságok, a beszélgetések és a plugin-beállítások nem kerülnek migrálásra vagy visszaállításra.

Újdonság a 9.1.569 verzióban

Megjelent:

Ez a kumulatív nyilvános verzió tartalmazza a Telegram-csoportokba történő kézbesítést említések alapján, az indításhoz és a jogosultságokhoz tartozó javításokat, valamint a kutatási gyűjteményeket és a crawler-eszközöket. A közzétett csomagok változatlanok maradnak. A későbbi változások új verziószám alatt jelennek meg.

Újdonság a 9.1.566 verzióban

Megjelent:

A BLUN King 9.1.566 robusztusabbá teszi a plugin-frissítéseket és a natív futásidejű modulok betöltését.

A csomagolt AgentSpine-futtatókörnyezet 0.59.1-es verzióra frissül. Az önindítója kihagyja egy felhasználói profil gyökerét szkennelési célpontként, és az összes életciklus-hook meghibásodásbiztos marad, ha egy védett elérési út nem olvasható.

A natív .node-modulok egy tartalomcímzett köztes gyorsítótáron keresztül oldódnak fel, az npm-csomagon kívül. Amint ez a verzió aktív, egy futó konzol többé nem tartja nyitva ezeknek a moduloknak a csomagmásolatát. A későbbi frissítések így kicserélhetik a csomagkönyvtárat anélkül, hogy ütköznének ezekkel a natív fájlokkal.

A nyilvános csomag megtartja a teljes spanyol, francia, svéd és cseh felületkatalógust a 9.1.565-ös verzióból. A belső Mnemo-futásidejű útvonalak, a privát végpontok, a belső modellszolgáltatók és az építő szkriptek nem részei a csomagnak.

Ellenőrzött csomagállapot

Az ügyfélcsomag sikeresen átesett a szivárgás-vizsgálaton, a teljes futásidejű ellenőrzésen 13 teszttel, az AgentSpine-MCP-inicializáláson, egy friss telepítésen és a 9.1.565-ről történő frissítésen. Minden szövegfájl LF sorvégjelet használ. Az npm-csomag SHA-256 értéke: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Újdonság a 9.1.565 verzióban

Megjelent:

A BLUN King 9.1.565 stabilizálja a hosszú munkafutásokat, és bővíti a csomagolt AgentSpine-futtatókörnyezetet.

Az ismétlési fék visszaállítja az egyenértékű eredmények sorozatát, amint közben valódi munka halad előre. A szokásos bejövő- és feladatlista-ellenőrzések emiatt többé nem váltanak ki hamis kényszerített választ.

Az aktivitáskijelzés pontosan egy sorból áll. Megmutatja az aktuális tevékenységhez illő angol állapotszót, a rejtett gondolkodás tokenjeit, a látható tokeneket, a teljes felhasználást, az Effortot, a kísérletet, a keretet és a lépést.

Az AgentSpine-szkennelési hibák meghibásodásbiztosak maradnak mutációs eszközöknél, felhasználói bemeneteknél és stop-hookoknál: a következő folyamat futhat tovább, és a hiba az auditnaplóban kerül rögzítésre. Egy kivétel vagy kezeletlen elutasítás okozta végzetes megszakítás előtt a konzol szinkron módon írja a futásidejű naplót.

A csomagolt AgentSpine-futtatókörnyezet 0.54.0-ra frissül a fb6d456b68605fd83721090e503f000a26e8a0fb commitból. Az állapot tartalmazza a valódi ACL-fail-open tesztet, a tartós, függőségekhez kötött célterveket és a tudásbeli hiányosságok kötött tisztázását.

A SessionStart, UserPromptSubmit, PostToolUse és Stop életciklus-hookok a pontos MNEMO_AGENT azonossággal kerülnek elküldésre a Mnemo felé. A hálózati hibák meghibásodásbiztosak maradnak.

A korábban hiányzó felületszövegek spanyolul, franciául, svédül és csehül teljesek.

Ellenőrzött csomagállapot

A teljes csomagkapu, a szivárgás-vizsgálat, a nyelvi katalógus ellenőrzése, az ACL-hook próba, a friss telepítés, a 9.1.564-ről történő frissítés és az AgentSpine-MCP-inicializálás zöld. Az npm-csomag SHA-256 értéke: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Újdonság a 9.1.564 verzióban

Megjelent:

A BLUN King 9.1.564 megakadályozza a védett mappák és a hiányzó felületszövegek okozta összeomlásokat.

Az AgentSpine az előkészítő fájlszkennelésnél kihagyja azokat az egyes fájlokat és mappákat, amelyeket az operációs rendszer EPERM vagy EACCES hibával zárol. Egy váratlan szkennelési hiba többé nem blokkolja a következő eszközhívást; a hívást a rendszer átengedi, a hibát pedig az auditnaplóban rögzíti.

Ha egy közzétett felületnyelvből hiányzik egy szövegkulcs, a konzol az angol szöveget használja, és a hiányosságot egyszer naplózza, ahelyett, hogy a megjelenítési útvonalon összeomlana. Így különösen a gondolkodás-státuszsor marad használható csehül, spanyolul, franciául és svédül.

A még hiányzó kulcsok tényleges fordításai egy külön ellenőrzött verzióban következnek. Addig az angol nyelvű tartalék tudatosan látható és meghibásodásbiztos.

Ellenőrzött csomagállapot

A csomagot a 9.1.563-ból származó pontos cseh thinking.step összeomlás ellen ellenőrizték. Az új verzió „step 6”-ot ad vissza kivétel helyett, csak egyszer figyelmeztet nyelvenként és kulcsonként, túléli a hozzáférhetetlen szomszédos mappákat, inicializálja az AgentSpine 0.49.0-t, kibírja a friss telepítést és a 9.1.563-ról történő frissítést, és nem tartalmaz feloldatlan plugin-importokat. Az npm-csomag SHA-256 értéke: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Újdonság a 9.1.563 verzióban

Megjelent:

A BLUN King 9.1.563 a csomagolt AgentSpine-futtatókörnyezetet 0.49.0-ra frissíti.

Az új állapot egy tanulási kísérlet előtt legalább egy friss, független bizonyítékot követel meg kifejezett felhasználói megerősítésből vagy objektív tesztből. A puszta beszélgetési vagy dokumentum-bizonyítékok többé nem elegendők, akkor sem, ha a többi küszöbértékük teljesül.

A tanulási szerződések tartósan kötik ezt a bizonyítékszabályt; a későbbi konfigurációs változások nem gyengíthetik egy futó ellenőrzést. A tulajdonhoz kötött fájlzárak megvédik a párhuzamos tanulási változtatásokat a felülírástól, manipulált vagy idegen zárak esetén pedig zárt állapotban hiúsulnak meg.

A frissítés a következő indításkor tartalomcímzetten cseréli le a felügyelt plugin-fát. A 9.1.562-es verzió meglévő telepítései AgentSpine 0.49.0-ra frissülnek, egy változatlan fa újra felhasználásra kerül, és az AgentSpine-MCP-szerver megerősíti a 0.49.0-s verziót.

Ellenőrzött csomagállapot

A csomaghatár csak a verzióadatokban különbözik a 9.1.562-től, valamint a pontosan rögzített AgentSpine-0.49.0 futtatókörnyezetben. A teljes upstream-ellenőrzés, 49 célzott tanulási teszt, a csomag-összehasonlítás, a szivárgás-vizsgálat, a friss telepítés, a valódi 9.1.562-ről történő frissítési út és egy MCP-inicializálás zöld. Az npm-csomag SHA-256 értéke: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Újdonság a 9.1.562 verzióban

Megjelent:

A BLUN King 9.1.562 visszaállítja az AgentSpine futásidejű fájlját a nyilvános csomagban.

A csomagolt AgentSpine-MCP-szerver által igényelt futásidejű fájl ismét mellékelve van. Egy friss telepítés teljesen materializálja a plugint; az MCP-szerver elindul, és megerősíti a nevét és a protokollverzióját.

Ellenőrzött csomagállapot

A csomaghatár csak a verziómetadatokban és a visszaállított futásidejű fájlban különbözik a 9.1.561-től. A szivárgás-vizsgálat, a friss telepítés, a plugin-materializáció és egy valódi MCP-inicializálás zöld. Az npm-csomag SHA-256 értéke: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Újdonság a 9.1.561 verzióban

Megjelent:

A BLUN King 9.1.561 átveszi a munkarendszer ellenőrzött fejlesztéseit a nyilvános csomagba.

Az aktuális feladat és a friss eszközeredmények elérhetők maradnak. Az olvasási eredmények nem kerülnek rövidítésre. A nagy eredményeket a rendszer újra lekérésre szolgáló hivatkozással menti el, ahelyett, hogy ürítené őket. Az ismételt azonos eredmények a legújabb teljes eredményre hivatkoznak.

A tömörítések tranzakcióként kerülnek naplózásra kezdő-, összefoglaló- és végjelöléssel. Az eszközhívások és eredményeik együtt maradnak, miközben a tartós ellenőrzőpontok az ismételt kísérleteken át biztosítják a helyreállítási utat.

A kimeneti keretek mostantól az aktív modellprofilból származnak. A felügyelt BLUN-modell alapértelmezésben 128 000 kimeneti tokent kap, ha nincs kifejezetten beállított érték. A régi rögzített 32 768 tokenes határok és a low és off alacsony határai többé nem rövidítik a komplex munkát; a kontextus kapacitása marad a biztonsági határ.

A frissítő kérdez, mielőtt előkészíti vagy elindítja a telepítőt. A nyilvános csomagban a felügyelt BLUN-modell rögzítve marad; a /model csak kompatibilitási alias a /effort számára.

A csomaghatárt az összes fájlnévre és olvasható tartalomra kiterjedően ellenőrizték. A belső szolgáltatói utak, a modellválasztás, az építő- és regressziós szkriptek, a privát azonosítók és a privát szervercímek nem részei a csomagnak.

Ellenőrzött csomagállapot

A teljes csomag, a szivárgás-vizsgálat, a friss telepítés, a verzió- és súgókimenet, egy új profil alapbeállításai, valamint a 9.1.550-ről 9.1.561-re szóló frissítési döntés zöld. Az npm-csomag SHA-256 értéke: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Újdonság a 9.1.527 verzióban

Megjelent:

A BLUN King 9.1.527 átveszi a /copy folyamatot a DeepAgents-ből.

A parancs a legújabb befejezett, nem üres asszisztensválaszt másolja át a meglévő platformfüggetlen vágólap-útvonalon.

Ha a /copy parancsot futó menet közben adják meg, a parancs a meglévő parancsvárósort használja, és a válasz befejezése után kerül végrehajtásra.

Az egyértelmű állapotüzenetek lefedik a sikert, az üres előzményt és a vágólap hibáit mind a hat felületnyelven.

Egy pirosról-zöldre regresszió védi a parancsregisztrációt, a végrehajtást, a válasz kiválasztását, a vágólap bájthű tartalmát és a jóváhagyott felületszövegeket.

Ellenőrzött csomagállapot

A teljes prepack és a kicsomagolt artefaktum ellenőrzése zöld. Az npm-csomag SHA-256 értéke: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Újdonság a 9.1.526 verzióban

Megjelent:

A BLUN King 9.1.526 materializálja az aktuális csomaggal csomagolt AgentSpine-verziót, mielőtt a /reload újra felépítené a plugin-katalógust és az MCP-konfigurációt.

A nem érintett plugin-bejegyzések megmaradnak. Egy változatlan felügyelt AgentSpine-fa újra felhasználásra kerül, az installed.json újraírása nélkül.

Egy pirosról-zöldre regresszió a 9.1.525 ellen védi a bootstrap-sorrendet, a felügyelt plugin átvételét és az újratöltés idempotens viselkedését.

Ellenőrzött csomagállapot

A teljes prepack, a csomagolt artefaktum ellenőrzése és a 9.1.525-ről 9.1.526-ra szóló izolált frissítési teszt zöld. Az npm-csomag SHA-256 értéke: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Újdonság a 9.1.525 verzióban

Megjelent:

A BLUN King 9.1.525 minden helyi shell-parancsot saját folyamatcsoportban indít Windows és POSIX alatt is. A programok így többé nem csatlakozhatnak a BLUN-TUI vezérlő konzoljához, és nem foghatják el az Escape, Strg+S vagy más szerkesztői bemeneteket.

A standard bemenet, a standard kimenet és a hibakimenet privát csövekben marad. Az interaktív parancsok fájlvéget kapnak, és kudarcot vallanak vagy időtúllépésbe futnak, anélkül, hogy a szerkesztővel versenyeznének a bemenetekért.

A DeepAgents-ből származó helyi shell-izoláció Windows-ra is átvételre került. Egy futtatható regressziós teszt lefedi mindkét platformútvonalat és egy valódi próbát egy elkapott folyamattal.

Újdonság a 9.1.524 verzióban

Dátum nélkül

A BLUN King 9.1.524 a Telegram-/loop paranccsal létrehozott azonnali feladatot a távoli parancsok védett kézbesítési útvonalán tartja. Így nem maradhat meg második szokásos várósor-bejegyzésként.

A folytatási lista minden munkamenethez megmutatja a folytatási ellenőrzőpont méretét, a megtartott üzeneteket és tokeneket, a munkamenet-előzmény méretét, valamint a hiányzó, érvénytelen vagy elavult ellenőrzőpontokat.

A csomagolt AgentSpine-futtatókörnyezet a 0.11.4-es ellenőrzött hivatalos állapotra frissül a 8034487cdd24498076bac48d3f24400bca5e6ae4 commitból. A BLUN 180 másodperces időkerete a SessionStart háttér-befejezéséhez megmarad.

A futtatható regressziós tesztek védik a Telegram-loopok pontosan egyszeri kézbesítését és a folytatási mérőértékek minden állapotát. A meglévő helyi várósor-viselkedés foglalt loopnál változatlan marad.

Újdonság a 9.1.523 verzióban

Megjelent:

A BLUN King 9.1.523 lehetővé teszi, hogy az Escape egy megnyitott perjel-parancsmenüt bezárjon, és a hozzá tartozó piszkozatot egy lépésben ürítse, ahelyett, hogy a parancsszöveget ott hagyná.

Strg+S átad egy perjel-piszkozatot a meglévő sorba állítási és feldolgozási útvonalnak akkor is, ha a felület éppen tétlenséget jelez, ahelyett, hogy a várósor ürítése előtt csendben visszatérne.

A normál piszkozatok megmaradnak, ha az Escape csak egy másik automatikus kiegészítést zár be.

A pirosról-zöldre futásidejű tesztek mindkét billentyűparancsot a 9.1.522-es csomag pontos viselkedése ellen védik.

Újdonság a 9.1.522 verzióban

Dátum nélkül

A BLUN King 9.1.522 azonnal beírja a permission.approval_requested értéket a munkamenet-előzménybe, amikor egy eszköz-jóváhagyás megnyílik. Egy felügyelet nélküli King így többé nem tűnik néma modellnek vagy beragadt szolgáltatónak, miközben a kezelőre vár.

A meglévő Telegram-jóváhagyási gombok automatikusan használatra kerülnek, ha az engedélyezési lista pontosan egy privát csevegést és tetszőleges számú csoportot tartalmaz. Több lehetséges privát címzett esetén a küldés zárolva marad, amennyiben a BLUN_TELEGRAM_APPROVAL_CHAT_ID nincs beállítva.

Egy pirosról-zöldre regresszió védi a munkamenet-előzmény azonnali láthatóságát, az egyértelmű továbbítást egy privát csevegésbe, a kifejezetten beállított cél elsőbbségét és a többértelmű címzettek elutasítását mindkét kiszállított relay-másolatban.

Újdonság a 9.1.521 verzióban

Dátum nélkül

A BLUN King 9.1.521 az AgentSpine SessionStart-szkennelést az interaktív indítási útvonalon kívülre helyezi. Egy hideg, 123,6 másodpercig tartó felhasználói könyvtár-szkennelés így sem a szerkesztőt, sem az első felhasználói bemenetet nem blokkolja.

A sikeres SessionStart-kimenetek átvétele továbbra is automatikus: a befejezés után a háttér-hook továbbra is átveszi korlátozott briefingjét a munkamenet kontextusába.

A hideg szkennelések időkerete 180 másodpercre nő. Egy pirosról-zöldre futásidejű teszt igazolja, hogy az indítás egy lassú hook előtt visszatér, és a hook ezt követően tovább futhat.

Újdonság a 9.1.520 verzióban

Megjelent:

A BLUN King 9.1.520 elegendő időt ad az AgentSpine SessionStart-hooknak az újratöltéskor, hogy egy hideg teljes projektszkennelést befejezzen.

Az AgentSpine indítási időkorlátja 15-ről 60 másodpercre nő. Az összes többi hook-időkorlát változatlan marad.

Egy új pirosról-zöldre futásidejű ellenőrzés elindítja a valódi AgentSpine-hookot egy ideiglenes projektben, és ellenőrzi mind a kimenetét, mind a két kiszállított időtúllépési manifestet.

Ellenőrzött csomagállapot

A 9.1.520-as verzió az AgentSpine 0.10.1-et tartalmazza. A 9.1.519-ről 9.1.520-ra szóló izolált frissítési teszt és a teljes prepack zöld. Az npm-csomag SHA-256 értéke: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Újdonság a 9.1.519 verzióban

Megjelent:

A BLUN King 9.1.519 elmenti a SessionStart hook sikeres kimeneteit, mielőtt az indítás vagy az újratöltés visszatér. Így az AgentSpine-készenlét automatikusan eléri a folytatott modellkontextust, és már nem vár az első felhasználói üzenetre.

A kihelyezett eszközeredményekre vonatkozó történeti hivatkozások korlátozott előnézetet tartanak meg az elejéből és a végéből. A folytatás fontos horgonyai így megmaradnak, anélkül, hogy a teljes eredményt minden modellkérésbe újra fel kellene venni.

Az új pirosról-zöldre futásidejű ellenőrzések védik a SessionStart-kontextus átadását és a történeti előnézeteket. A 9.1.518-cal visszaállított eszközkatalógus a Todo-karbantartáshoz változatlanul megmarad.

Újdonság a 9.1.518 verzióban

Megjelent:

A proaktív feladatlista-karbantartás közben a Read, Write, Edit és Bash a TodoList mellett elérhető marad. A nagy fájlváltoztatások szokásos helyreállítási útja így nem szakad meg.

Az automatikus Todo-karbantartás és annak korlátozott bizonyíték-promptja megmarad, anélkül, hogy az aktív modelllépést tiszta TodoList-eszközkatalógusra kapcsolná át.

Egy pirosról-zöldre regressziós kapu véd a 9.1.499-ből származó katalógus-visszaesés ellen, és kettős sémák nélkül ellenőrzi a helyreállítási eszközök kiválasztását.

Újdonság a 9.1.517 verzióban

Megjelent:

Strg+S és Escape megnyitott jóváhagyási kérésnél is elérhető marad. A Strg+S elküldi az összes várakozó üzenetet; az Escape először egy várakozó üzenetet szabadít fel, és csak üres várósornál utasítja el a jóváhagyást.

Az aszinkron munkamenet-befejezés teljes mértékben megfigyelésre kerül a billentyűzet-, a Telegram-/reload és a perjel-parancs útvonalakon. A session.not_found már befejezett munkamenetnek számít, ahelyett, hogy a magot egy kezeletlen elutasítással összeomlasztaná.

A pirosról-zöldre csomagellenőrzések védik a nyers Windows-vezérlőkaraktereket és a már nem létező munkamenet befejezésekor mért hibát.

Újdonság a 9.1.516 verzióban

Megjelent:

Ha a tömörítés után a mentett előzményből hiányzik egy asszisztenslépés kezdete, a lejátszás a következő tartalmi vagy eszközeseményből rekonstruálja. A king -c így többé nem szakad meg a Received content_part for unknown step_uuid 'undefined' belső hibával.

Egy Telegram-üzenet pontosan egyszer hagyja el a várósort, amint a mag tartósan elfogadta az aktív átadását. A valódi elutasítások megmaradnak egy új kísérlethez. Egy váratlanul leállt, King által felügyelt Telegram-bridge-et pontosan egy összevont őr indít újra.

Modelllépésenként csak az első TodoList-változtatás kerül elfogadásra. A kész pontok automatikusan eltűnnek, a függő jelölések ANSI16-terminálokon is láthatók maradnak, és egy új lista pontosan egy futó ponttal kezdődik. A rögzített sorrend: sürgős, közvetlen felhasználói üzenet, címzett bot-üzenet, bot-üzenet, normál üzenet.

Az első eszközképes lépés legfeljebb 2,5 másodpercet vár a kezdeti MCP-katalógusra; az opcionális szerverek a háttérben tovább indulhatnak. A program indításakor csak az aktív profil kerül ellenőrzésre és telepítésre.

Ellenőrzött csomagállapot

A 9.1.516-os verzió az AgentSpine 0.10.1-et tartalmazza. Mind a nyolc prepack-regressziós kapu, a node --check, a csomag-metadatok ellenőrzése és egy friss csomagellenőrzés zöld. Ugyanaz az npm-csomag tartalmazza a Windows, Linux és macOS platformösszetevőket. Az npm-csomag SHA-256 értéke: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Újdonság a 9.1.515 verzióban

Megjelent:

Egy valósan változatlan feladatlista hosszabb igazolt munka után ismét elfogadásra kerül. King-nek nem kell előrehaladást kitalálnia vagy csak egy címet átfogalmaznia ahhoz, hogy a tényleges munkáját folytathassa.

A tétlen loop is felvehet egy még nyitott TodoList-et, anélkül, hogy az ágenst tartósan a kizárólag Todo-eszközzel rendelkező karbantartási menetben tartaná. Egy prepack-regressziós kapu védi mindkét hibautat.

Ellenőrzött csomagállapot

A 9.1.515-ös verzió az AgentSpine 0.10.1-et tartalmazza. A célzott Todo-loop regressziós ellenőrzés, a node --check, a kiadási metaadatok ellenőrzése és egy friss csomagtelepítés zöld. Ugyanaz az npm-csomag tartalmazza a Windows, Linux és macOS platformösszetevőket. Az npm-csomag SHA-256 értéke: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Újdonság a 9.1.514 verzióban

Megjelent:

A BLUN King 9.1.514 megerősíti a tartalommentes Telegram-kézbesítési naplót a manipulált várósor-borítékok ellen.

Az üzenetazonosítók csak pozitív decimális számként kerülnek átvételre. A már kiszámított csevegés-hashek kizárólag pontosan tizenkét jegyű, kisbetűs hexadecimális értékként megengedettek. A hibás, tartalomszerű értékek eldobásra kerülnek, ahelyett, hogy naplózásra kerülnének.

A meglévő Telegram-feldolgozás, a kézbesítési fázisok, a naplórotáció és a tartalommentes karantén-diagnózis változatlan marad. Mind a 133 csomagteszt, valamint a friss csomagpróbák Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszeren zöldek.

Ellenőrzött csomagállapot

A 9.1.514-es verzió az AgentSpine 0.10.1-et és a ReadBatch-et tartalmazza. Az npm-csomag SHA-256 értéke: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Újdonság a 9.1.513 verzióban

Megjelent:

A BLUN King 9.1.513 naplózza a Telegram kézbesítési útját a bridge-re való beérkezéstől az útválasztáson, a sorba állításon és a betápláláson át a megerősítésig, a helyreállításig vagy a karanténig.

A korlátozott napló kizárólag tartalommentes azonosítókat, hasheket, kézbesítési fázisokat, számlálókat és tisztított hibaokokat tárol. Üzenetszövegek, promptok, elérési utak, felhasználónevek, tokenek, hozzáférési adatok és nyers hibaüzenetek nem kerülnek rögzítésre.

A karantén-diagnózis többé nem duplikál Telegram-üzeneteket, megjelenítési szövegeket, származási adatokat, nyers csevegés-azonosítókat vagy képútvonalakat. Mind a 132 csomagteszt, valamint a friss csomagpróbák Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszeren zöldek.

Ellenőrzött csomagállapot

A 9.1.513-as verzió az AgentSpine 0.10.1-et és a ReadBatch-et tartalmazza. Az npm-csomag SHA-256 értéke: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Újdonság a 9.1.512 verzióban

Megjelent:

A BLUN King 9.1.512 a proaktív TodoList-karbantartásnál megváltoztatott, bizonyítékokkal alátámasztott frissítést követel meg, ahelyett, hogy ugyanazt a listát korlátlanul újra elfogadná. Az izolált karbantartási menet legfeljebb nyolc kompakt, eszköznév- és eredményadatot kap az utolsó elfogadott frissítés óta.

A promptok, argumentumok, parancsok, teljes elérési utak, eszközeredmények vagy a munkaelőzmény nem kerülnek újra betáplálásra. Egy sikertelen TodoList-kísérlet megőrzi ezt a korlátozott bizonyítékot a következő kísérlethez; egy sikeres frissítés eltávolítja a felhasznált adatokat. A kész pontok továbbra is automatikusan eltűnnek, és a következő lépésben ismét a normál munkaeszközök állnak rendelkezésre.

Ellenőrzött csomagállapot

A 9.1.512 127-ből 127 csomagtesztet teljesít. A friss telepítések Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszeren a várt platformösszetevőket választják, és az AgentSpine 0.10.1-et valamint a ReadBatch-et tartalmazzák. Az npm-csomag SHA-256 értéke: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Újdonság a 9.1.511 verzióban

Megjelent:

A BLUN King 9.1.511 az AgentSpine 0.10.1-et új, tartalomcímzett core-plugin-változatként szállítja. A kötelező preflight továbbra is race-biztosan ellenőrzi minden aktív gazda-utasításfájlt, és azonosságát a pontos menethez köti, de a gazda által már betöltött teljes szöveget már nem duplikálja a futásidejű kontextusba.

Az állapot kötelező válasz előtti bizonyítékokat, megerősített must-remember bejegyzéseket és a hitelesített személy- és kapcsolatgráf öngyógyító szinkronizálását egészíti ki. A hiányzó csoportok, személyek és tagságok egy újabb roster-összevetésnél javításra kerülnek; a helyi kapcsolat-lekérdezések blokád esetén öt másodperc után láthatóan véget érnek.

A korlátozott Telegram-Mnemo-lekérdezés megmarad: a korábbi üzenetek csak konkrét igény esetén kerülnek betöltésre, szoros ágens-, személy-, csoport-, téma-, szál- és idővonatkozással. A teljes Telegram-előzmény nem kerül rutinszerűen a promptba.

Ellenőrzött csomagállapot

A 9.1.511 126-ból 126 csomagtesztet teljesít. A valódi 15 519 bájtos CLAUDE.md fájlt teljesen ellenőrizték, miközben a teljes injektált kontextus 5 667 bájtot tett ki, és nem tartalmazott utasítás-teljes szöveget. A friss telepítések Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszeren a várt platformösszetevőket választják, és az AgentSpine 0.10.1-et valamint a ReadBatch-et tartalmazzák. Az npm-csomag SHA-256 értéke: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Újdonság a 9.1.510 verzióban

Megjelent:

A BLUN King 9.1.510 a ReadBatch eszközzel bővül. Az eszköz kettőtől tizenkettőig terjedő, egymástól független, már ismert UTF-8 fájlt vagy fájlterületet olvas egy modelllépésben, és közben megtartja a kérések sorrendjét. Minden elérési út ugyanazokon a hozzáférési, szabály- és jogosultság-ellenőrzéseken megy keresztül, mint egyetlen Read hívás. A részeredmények láthatók maradnak; csak egy teljesen sikertelen köteg számít összhibának.

Ellenőrzött csomagállapot

A 9.1.510 125-ből 125 csomagtesztet teljesít. A friss telepítések Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszeren a várt platformösszetevőket választják, és a ReadBatch-et tartalmazzák. Az AgentSpine tudatosan 0.8.0-n maradt, amíg a függetlenül talált kontextuskeret-blokkoló az újabb előzetes állapotban megnövelt futásidejű prompt nélkül nem került javításra. Az npm-csomag SHA-256 értéke: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Újdonság a 9.1.509 verzióban

Megjelent:

A BLUN King 9.1.509 minden felszabadított Telegram-munkaüzenetnél botok között kifejezett említést követel meg a szánt King-ről. Az említés nélküli bot-üzenetek láthatók maradnak, de nem kerülnek pufferelésre, sorba állításra, kézbesítésre vagy később ennek a King-nek a modellkontextusába. Így egy King-nek szánt elsőbbségi bot-üzenet többé nem válhat egy másik King feladatává.

Ellenőrzött csomagállapot

Mind a 121 csomagteszt teljesül. Ugyanaz a csomag tartalmazza az ellenőrzött platformösszetevőket Windows x64, Linux x64, macOS ARM64 és macOS x64 rendszerhez. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Újdonság a 9.1.508 verzióban

Megjelent:

A nyitott Todo-pontok ismét látható négyzetet kapnak. Már az első szokásos feladatlista is pontosan egy futó ponttal kezdődik; a későbbi lépések függőben maradnak, amíg a tényleges kezdetük nem igazolt.

Az elfogadott Telegram-közvetlen és csoportüzenetek aszinkron, tartósan pufferelve és pontosan deduplikálva kerülnek átadásra a Mnemo felé. Egy átmenetileg elérhetetlen hub nem blokkolja sem a Telegram-kézbesítést, sem a King futását. A /loop parancsok és a belső loop-tickek tudatosan nem kerülnek mentésre.

Az AgentSpine nem tölt teljes Telegram-előzményt a futásidejű kontextusba. Ha egy feladat korábbi üzenetet igényel, korlátozott Mnemo-lekérdezés történik ágens, személy, csoport, téma, szál és időszak szerint.

Ellenőrzött csomagállapot

Mind a 120 csomagteszt teljesül. A friss telepítések Windows, Linux x64, macOS ARM64 és macOS x64 rendszeren mindig a helyes natív vágólap-összetevőt választják, és tartalmazzák a felügyelt Telegram-Mnemo-kapcsolatot valamint az AgentSpine-t. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Újdonság a 9.1.507 verzióban

Megjelent:

A BLUN King 9.1.507 kifejezetten arra utasítja a modellt a Read eszközben, hogy egymástól független fájl- és területolvasásokat egy modellválaszban kössön össze, ha több bemenet hasznos lehet.

Ez csökkenti az elkerülhető modellköröket nagy munkakontextusoknál, anélkül, hogy a Read végrehajtását, oldalnavigációját, jogosultságait vagy eredménykezelését megváltoztatná.

Ellenőrzött csomagállapot

Egy célzott regressziós teszt védi a változást; mind a 112 csomagteszt teljesül.

Újdonság a 9.1.506 verzióban

Megjelent:

A kész TodoList-pontok azonnal eltűnnek a látható TUI-ból. A tartós feladatlista ezeket a bejegyzéseket már korábban helyesen eldobta; most a felület is ugyanazt a tisztított állapotot mutatja, miközben a futó és függő munka teljesen megmarad.

Az automatikus karbantartási menet önálló rendszerpromptot használ 546 karakterrel. Korábban ehhez a teljes munkapromptot, körülbelül 19 000 karakterrel, csatolták, annak ellenére, hogy csak az egyetlen elérhető Todo-eszköz létezett. A következő munkalépés továbbra is a teljes promptot és a normál eszközkatalógust kapja.

Mért kontextus-nyereség és csomagállapot

Egy valódi futás minden nyolcadik munkalépésnél külön Todo-karbantartási menetet mutatott 15 221 bemeneti token felhasználásával. A statikus karbantartási prompt 18 470 karakterrel zsugorodik; a tényleges futásidejű megtakarítást a flottafrissítés után újra mérik. A közzétett tarball 111-ből 111 tesztet teljesít. A friss csomagtelepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.18.0-val megerősítik a 9.1.506-os verziót; a macOS binárisok ARM64-hez és x64-hez azonos npm-csomagban vannak. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Újdonság a 9.1.505 verzióban

Megjelent:

Egy Telegram-üzenet, amely a csatorna átvétele után, de a várósor-aktiválás befejezése előtt érkezik, többé nem kerül kihagyásra régi elmaradásként. Érvényes ellenőrzőpont nélkül a feldolgozás az átvétel kezdetén mért bájthatárnál kezdődik, nem a későbbi fájlvégnél.

Egy érvényes tartós ellenőrzőpont elsőbbséget élvez. Ha a várósorfájlt az átadás közben kicserélik, az új fájl biztonságosan a nulladik bájtnál kezdődik; a már az átvétel előtt létező történeti üzenetek továbbra sem kerülnek újra lejátszásra.

Mért visszaesés és csomagállapot

A 63456-os csoportüzenet egy másodperccel a csatorna átvétele után érkezett, az ellenőrzőpont pontosan a végéig ugrott, és az üzenet egyetlen modell-előzményben sem jelent meg. Ez a valós veszteségszakasz regresszióként védett. A közzétett tarball 111-ből 111 tesztet teljesít; a friss csomagtelepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.18.0-val, valamint egy valódi 9.1.504-ről történő frissítés megerősítik a 9.1.505-ös verziót. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Újdonság a 9.1.504 verzióban

Megjelent:

Egy Telegram-üzenet, amely üres ágensfutásnál már a várósorban van, mostantól a normál csatornaútvonalon indul el friss modellmenetként. Nem vár tovább egy aktív futásra, amely tétlen állapotban definíció szerint nem jöhet létre.

A meglévő átadás egy futó menetbe változatlan marad. Ugyanígy védettek maradnak az izolált Todo-karbantartás, a kész pontok automatikus eltávolítása és a normál fájl-, keresési- és shell-eszközök későbbi visszaállítása.

Ellenőrzött csomagállapot

A közzétett tarball 106-ból 106 tesztet teljesít. Az új tétlen regresszió a beavatkozás előtt piros volt, és utána 24 várósor-teszttel együtt zöld. A friss csomagtelepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.18.0-val megerősítik a 9.1.504-es verziót és ugyanazt a SHA-256 értéket: df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Újdonság a 9.1.503 verzióban

Megjelent:

Az izolált Todo-karbantartási üzenet mostantól kifejezetten üres toolCalls mezőt is tartalmaz. Így ugyanannak az üzenetformának felel meg, mint a szabályos munkához tartozó menetek, és a BLUN-szolgáltatói normalizálás biztonságosan feldolgozhatja.

A valódi TypeError: message.toolCalls is not iterable futásidejű hiba így már nem fordul elő a TodoList-hívás előtt. Egy regressziós teszt pontosan úgy iterálja a létrehozott üzenetet, mint a szolgáltatói határ, mielőtt a karbantartás jóváhagyásra kerül.

Ellenőrzött csomagállapot

A közzétett tarball 105-ből 105 tesztet teljesít. A friss csomagpróbák Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.15.0-val megerősítik a teljes szolgáltatói üzenetformátumot, az izolált Todo-karbantartást és a kész pontok automatikus eltávolítását. A valós flotta-átvétel a három King ellenőrzött újraindítása után fut.

Újdonság a 9.1.502 verzióban

Megjelent:

Az esedékes TodoList-karbantartási lépés csak friss, az aktuális feladatra és a látható listára korlátozott üzenetet kap. A régi Read, Bash vagy MCP-hívások a munkaelőzményből így nem kerülhetnek a szándékosan TodoList-re korlátozott lépésbe.

A kész feladatok a mentéskor automatikusan eltűnnek a látható és a tartós listából. A futó, függő, blokkolt, jóváhagyásra váró és megszakított pontok megmaradnak; a lista így nem nő korlátlanul a befejezett munka miatt.

Mért flotta-megállapítás

Két ágensprofil függetlenül ugyanarra a visszaesésre futott: sikeres eszközhasználat után a Todo-karbantartás megismételte az előzményekben szereplő munkaeszközöket, és Tool not found hibát mutatott. A közzétett tarball 105-ből 105 tesztet teljesít. A friss telepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.15.0-val megerősítik az izolált karbantartást, a kész pontok eltávolítását és a normál eszközök visszatérését. Egy valódi macOS-átvétel nem része ennek a bizonyítéknak.

Újdonság a 9.1.501 verzióban

Megjelent:

Egy sikeres TodoList-karbantartási lépés után a közvetlenül következő munkalépésben ismét minden, a menethez kiválasztott eszköz rendelkezésre áll. A Read, Bash és más munkaeszközök többé nem maradnak rejtve az átmenetileg korlátozott Todo-katalógus mögött.

Javított visszaesés

A Todo-lépés szándékosan csak TodoList-et kínált. Az eszközkiválasztása azonban kifejezett visszaállítás nélkül a következő lépésben is aktív maradt. A 9.1.501 itt ismét a normál katalógust állítja be, és mindkét következőlépés-útvonalat regresszióval védi.

Golden Release 9.1.500

Megjelent:

Ez a verzió a 9.1.499 teljes funkcionális állapotát változatlanul, közös npm-megjelenésként köti össze Windows, Linux és macOS rendszerhez. Az arany jelölés tudatosan ennek a verziónak a címsoraira korlátozódik; a régebbi bejegyzések megtartják az eddigi megjelenítésüket.

Release-állapot

A Golden Release a 9.1.499 ellenőrzött Todo-, várósor-, loop-, kontextus-, AgentSpine- és képelemzési változásait veszi át további futásidejű logika nélkül.

Újdonság a 9.1.499 verzióban

Megjelent:

A legújabb tizenkét beszélgetési üzeneten kívüli kép-, hang- és videoadatok csak az ismételt modell-projekcióban kerülnek rövid hivatkozásokkal helyettesítésre. Az aktuális médiák, az üzenetszöveg és a teljes nyers munkamenet-előzmény változatlan marad.

Egy mért folytatási ellenőrzőpontban ez a projekció 85 748 karaktert, azaz körülbelül 21 437 becsült bemeneti tokent takarít meg minden további eszközlépésnél.

Az esedékes Todo-karbantartás a kilencedik munkablokk előtt külön alacsony erőfeszítésű modelllépésként fut. Ebben a lépésben a futtatókörnyezet kizárólag TodoList-et kínál; a fájl-, keresési-, shell- és más munkaeszközök csak érvényes frissítés után kerülnek újra jóváhagyásra.

A friss felhasználói üzenetek elsőbbséget élveznek a Todo-karbantartással szemben. A kemény Todo-kapu biztonsági hálóként megmarad a valóban érvénytelen frissítésekhez, de többé nem jelenik meg normál piros köztes hibaként egy önálló listakarbantartás előtt.

Ellenőrzött bizonyíték

A közzétett tarball 105-ből 105 futásidejű és regressziós tesztet teljesít. A friss izolált telepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.15.0-val pontosan a 9.1.499-es verziót jelentik, és megerősítik a média-projekciót, a változatlan nyers előzményt, a Todo elővezérlését és az összes munkaeszköz elrejtését a Todo-lépés alatt. A jelölt 850 útvonalat foglal magában, és SHA-256 értéke 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Egy valódi macOS-átvétel nem része ennek a bizonyítéknak.

Újdonság a 9.1.498 verzióban

Megjelent:

A /usage parancs megmutatja a szolgáltató által jelentett prompt-gyorsítótár találati arányát, valamint az elolvasott és írt gyorsítótár-tokeneket modellenként. Jelentett gyorsítótár-aktivitás nélkül a kijelzés nem talál ki arányt.

A /tokens rövid alias a meglévő részletes kontextusdiagnózishoz; a /offload a meglévő archiváló tömörítést hívja. Egyik út sem vált ki további modellhívást.

A különböző engedélyezett bot-üzenetek többé nem kerülnek eldobásra egy merev 15 másodperces ablak miatt. A meglévő sorrend megmarad: a privát és kifejezetten címzett üzenetek a bot-üzenetek előtt állnak, a bot-üzenetek a normál kontextus előtt.

Egy teljes tömörítés a pontos Todo-listát veszi át az új kontextusba. Ha utána az elérési út, a parancs, a hash vagy a követelmény bizonytalan, egy egyszeri helyreállítási megjegyzés először az archivált előzmény elolvasását követeli meg, széles fájlkeresés vagy újrakezdés helyett.

A kész Todo-lépések bizonyítékként megmaradnak. Ha későbbi felismerések egy lépést újra szükségessé tesznek, az igazolt befejezés megmarad, és az új ellenőrzés külön futó lépésként jelenik meg indoklással.

A visszatérő munkamenet-loopok addig várnak, amíg a karbantartott Todo-lista még futó vagy függő munkát tartalmaz. A kimaradt intervallumok a valódi tétlenségig összevonásra kerülnek; a többi ütemezett emlékeztető ettől érintetlen marad.

Ellenőrzött bizonyíték

Az előkészített tarball 100-ból 100 futásidejű és regressziós tesztet teljesít. A friss izolált telepítések Windows rendszeren Node 24.19.0-val és Linux rendszeren Node 24.15.0-val pontosan a 9.1.498-as verziót jelentik, és megerősítik a gyorsítótár-kijelzést, a parancsaliasokat, a tömörítés-helyreállítást, a monoton Todo-bizonyítékokat, a munkamenet-loop védelmet, a csomag-changelogot és a bot-prioritást. A jelölt 849 útvonalat foglal magában, és SHA-256 értéke 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Egy valódi macOS-átvétel nem része ennek a bizonyítéknak.

Újdonság a 9.1.497 verzióban

Megjelent:

A Telegram-botüzenetek a közös csoportokból a privát és kifejezetten címzett üzenetek mögött, de a normál kontextus előtt állnak. A priorizálás nem kényszerít ki választ.

Egy elfogadott Telegram-üzenet eltűnik a látható várósorból, amint a betáplált modelllépése megkezdődik. Egy elutasított kézbesítés vagy az első lépés előtti megszakítás továbbra is megőrzi egy újabb kísérlethez.

Az esedékes Telegram-választ vagy üzenetfeldolgozást a Todo-karbantartás többé nem blokkolja. A következő normál munkalépés a Todo-lista valós frissítéséig zárolva marad.

Verziók 9.1.496 és 9.1.487 között

VerzióVáltozások
9.1.496Automatikusan egyenként kézbesíti a Telegram-felhasználói üzeneteket, csak a pontosan elfogadott vagy megválaszolt üzenet-azonosítót távolítja el, minden látható Todo-listához valós előrehaladást követel meg, és elrejti a sikeres belső hookok hasznos adatait.
9.1.495Minden új vagy lecserélt célt friss látható Todo-listával indít, valós frissítéseket követel meg, azonnal eltávolítja a sikeresen megválaszolt Telegram-csoportfókuszt, a normál bejövő visszaigazolásokat a menet végéig halasztja, és valódi dekódolási ellenőrzéseket ad hozzá a Ctrl+S és Ctrl+T billentyűkhöz.
9.1.494Egyértelműen szétválasztja a billentyűparancsokat: a Ctrl+S csak a várósor-hátralékot vezérli, a Ctrl+T csak a Todo-listát. A Telegram-felhasználói üzenetek futó munka esetén a következő biztonságos átadáshoz engedélyezik magukat.
9.1.493A Telegram-felhasználói üzenetek aktív munka közben automatikusan felszabadulnak a következő biztonságos átadáshoz. A közvetlen üzenetek a várósoron belül elöl maradnak, a csoportüzenetek tartós leállítása nélkül.
9.1.492A már felszabadított csoportüzenetek átmenetileg foglalt kézbesítésnél megmaradnak, és a rendszer újra megkísérli a kézbesítésüket. A csomagot, az npm-metaadatokat, a nyilvános manifestet és a changelogot a sikerjelentés előtt együtt ellenőrzik.
9.1.491A közvetlen Telegram-üzenetek futó munka esetén azonnal elsőbbséget kapnak. A kézi várósor-vezérlés a többi üzenethez megmaradt.
9.1.490A csomag-előzmény teljesen dokumentálja a 9.1.487-es nem publikált állapotot és a 9.1.488-tól ténylegesen közzétett javításokat.
9.1.489A feladatlista, a várósor-vezérlés, a Telegram-végrehajtási azonosság, az AgentSpine-profiltelepítés és a felügyelt képelemzés helyreállt, és regressziós tesztek védik.
9.1.488Az előkészített AgentSpine-core-plugin megjelent. A Telegram-duplikátumok többé nem hagynak látszat-menetet; a gondolkodási mélység és a biztonságos telemetria-kezelés az eszközlépéseken át megmarad.
9.1.487Nem publikált. Ez az állapot az AgentSpine-t felügyelt core-pluginként készítette elő. Az npm-ben a 9.1.486 után közvetlenül a 9.1.488 következett.

Újdonság a 9.1.486 verzióban

Megjelent:

Az új és frissített profilok mostantól megbízhatóan angolul indulnak Windows, macOS és Linux rendszeren. Egy elmentett automatikus nyelvi érték egyszer migrálódik, miközben a kifejezetten választott nyelvek változatlanok maradnak.

Az indításkori automatikus frissítések a meglévő verzióhoz kötött telepítőn keresztül ismét alapértelmezésben aktívak. A [upgrade].auto_install = false megtartja a megerősítési lekérdezést; háttér-frissítő nem tér vissza.

Az indítási párbeszédablakok, a folyamatjelzés, a hibák, a sikerüzenetek és a munkamenet-folytatás mostantól ugyanazt a nyelvet használják. A regressziós és mutációs tesztek védik a migrálást, a frissítési utat és a munkamenet-adatokat.

Ellenőrzött bizonyíték

A teljes tesztsorozat 1 474-ből 1 474 ellenőrzésen átment. Egy izolált frissítési futás a 9.1.486-ot telepítette a 9.1.485-ből, a konfigurációt és a munkamenetet változatlanul megőrizte, és elindította az új CLI-t. Egy külön indítási próba igazolta az automatikus telepítést visszakérdezés nélkül, valamint egy régi automatikus nyelvi érték egyszeri migrálását angolra.

Verziók 9.1.485 és 9.1.178 között

VerzióVáltozások
9.1.485
  • Korlátozza a folytatott munkamenet első látható lejátszását scrollback-index nélkül az aktív 15 beszélgetési menetre, ahelyett hogy a teljes beszélgetést újra megjelenítené.
  • Sikeres frissítés után kiüríti a látható frissítési területet, mielőtt az új konzol elindul; a normál terminál-scrollback megmarad.
  • Regressziós és mutációs ellenőrzéseket ad hozzá a lejátszási tartalékmegoldáshoz, beleértve egy szimulációt 97 596 rekorddal.
9.1.484
  • A plugin-felismerés emellett elfogadja a .codex-plugin/plugin.json fájlt, és a PLUGIN_ROOT, illetve BLUN_PLUGIN_ROOT értékét feloldja a parancsban, az argumentumokban és a munkakönyvtárban.
9.1.483
  • A tömörítési modell az aktív modelltől külön választható ki, menthető el és állítható vissza öröklésre; a kiválasztás és a visszajelzés a tétlen parancsban és a lokalizált beállításokban áll rendelkezésre.
9.1.482
  • A kiszervezett Read-eredmények megtartják a következő line_offset értéket, és az eredeti olvasási műveletet ott folytatják, ahelyett hogy ugyanazt a fájlt újra az elejétől olvasnák.
9.1.481
  • A rendszer a meglévő folytatáshoz max_tokens jelzésként ismeri fel azokat a részágens-válaszokat, amelyek eszközhívás nélkül érik el a tokenhatárt. A .. karaktert tartalmazó glob-mintákat és a ~név típusú elnevezett home-útvonalakat elutasítja.
9.1.480
  • Frissíti a mellékelt translate-native skill-t és a Language-Guard-MCP-t a 6.42.13-as verzióra.
  • A nyelvvédelem mellékelt fájljait bájtpontosan köti a 6430ce30e235c1a9d1ebcd1b646d62edce510605 forrás-commithoz.
  • Származási és mutációs ellenőrzéseket ad hozzá, így a módosított védelmi bájtok vagy egy eltérő skill-verzió megbuktatják a közzétételi kaput.
9.1.479
  • Hitelesített belső útvonalat ad hozzá az Agent API privát King-szolgáltatásához az elérhetőség-ellenőrzéshez.
  • Ellenőrzi a szolgáltatás elérhetőségét anélkül, hogy ügyfél-munkamenetet hozna létre vagy ágensfutást indítana.
  • Az útvonalat a loopback-felületre és a GET-re korlátozza, titokkal védi, és megakadályozza a gyorsítótárazását.
9.1.478
  • Megjavítja a közvetlen Telegram-fókusz szokásos szüneteit újraindítás után, akkor is, ha a régebbi ellenőrzőpontok nem tartalmaznak válaszhatáridőt.
  • Megőrzi a felhasználó által kifejezetten kért szüneteket a feloldásig, ahelyett hogy automatikusan lejáratná őket.
  • Amint a közvetlen fókusz véget ér, felszabadítja a sorba állított csatornaüzeneteket egy aktív futás számára.
9.1.477
  • Kifejezett, az üzemeltető által indított folyamat-héjat ad hozzá az Agent API privát szolgáltatásához.
  • A SIGINT és SIGTERM jeleket pontosan egyszer dolgozza fel, akkor is, ha a jelek az indítás közben érkeznek.
  • Biztonságosan leáll korlátozott üzenetekkel, nem hívja meg a process.exit-t és soha nem indítja el automatikusan a szolgáltatást.
9.1.476
  • Az Agent API privát szolgáltatásához a biztonságos zárolás elvén alapuló környezeti szerződést ad hozzá.
  • Megkövetel egy kifejezetten beállított loopback-portot, elkülönítési titkokat, szolgáltatói beállításokat és erőforrás-határokat.
  • A privát szolgáltatást leállítva és az inaktív munkamenetek automatikus tisztítását kikapcsolva hagyja, amíg mindkettőt kifejezetten be nem konfigurálták.
9.1.475
  • Csak a megfelelően konfigurált és ténylegesen inaktív munkameneteket szabadítja fel az Agent API-ból, mielőtt egy ügyfél elérné a munkamenet-limitjét.
  • Védi az aktív modell- és eszközfuttatásokat koruktól függetlenül, és valós használat esetén frissíti az inaktivitási időszakot.
  • Mindaddig kikapcsolva hagyja az automatikus tisztítást, amíg egy üzemeltető kifejezetten nem konfigurál inaktivitási időtúllépést.
9.1.474
  • Feloldja az aktív munkamenet-hozzárendelést, ha egy ágens folytatása egy eszközeredmény után meghiúsul.
  • Ezt követően lehetővé teszi az érintett munkamenet kifejezett bezárását.
  • A sikeres eszköz-visszatéréseket és a nyilvános modellszerződést változatlanul hagyja.
9.1.473
  • Védi az Agent API egyik munkamenetét a bezárás ellen, amíg az első modellhívása még fut.
  • Megbízhatóan felszabadítja a munkamenetet egy sikeres válasz vagy modellhiba után.
  • A feldolgozatlan modellek meglévő elérési útját és a nyilvános modellszerződést változatlanul hagyja.
9.1.472
  • Lehetővé teszi az ügyfeleknek, hogy egy inaktív Agent API-munkamenetet kifejezetten bezárjanak, és felszabadítsák a korlátozott munkamenet-helyüket.
  • Megakadályozza az aktív munkamenetek bezárását, és minden bezárási műveletet a hozzá tartozó tulajdonos-ügyfélre korlátoz.
  • A felszabadított helyet új munkamenet számára teszi elérhetővé, anélkül hogy módosítaná a nyilvános modellszerződést.
9.1.471
  • Zárt szolgáltatás-hostot ad hozzá, amely összeállítja a privát Agent API-vermet, anélkül hogy automatikusan elindítaná.
  • Külön titkokat követel meg az átvitelhez és az elkülönítéshez, abszolút ügyfél-gyökérkönyvtárat és a King-futtatókörnyezet kifejezett konfigurációját.
  • A loopback-felületre köti a figyelőket, és leállításkor minden ügyfél-munkamenetet és minden futtatókörnyezetet bezár.
9.1.470
  • Elkülöníti az Agent API fej nélküli munkameneteit megbízható ügyfél és nyilvános munkamenet szerint.
  • Egy SDK-munkamenetben összefogja az egyidejű első hozzáféréseket, és korlátozza az aktív ügyfeleket és munkameneteket.
  • Kulcs-kötött átlátszatlan belső azonosítókat és munkakönyvtárakat használ, miközben a stabil nyilvános munkamenet-azonosítók megmaradnak.
9.1.469
  • Privát HTTP-átvitelt ad az Agent API-adapterhez, amely kizárólag a loopback-felületen érhető el.
  • Szolgáltatási titkot és szerveroldalon előírt ügyfél-azonosságot követel meg; a kérés törzsében szereplő hamis azonosság-megadásokat figyelmen kívül hagyja.
  • Elutasítja a túlméretezett vagy hibás kéréseket, és a belső szolgáltatói részleteket kívül tartja a nyilvános hibaüzeneteken.
9.1.468
  • Válaszképes állapotban tartja a főágenst, miközben a háttérben futó alágensek és az egymásba ágyazott alágensek tovább dolgoznak.
  • Lehetővé teszi az Agent API korlátozott munkameneteinek, hogy használják az alágensek életciklusát, anélkül hogy helyi shell- vagy fájlrendszer-eszközöket tárnának fel.
  • Továbbítja a pontos eszközhatárt minden egymásba ágyazott alágens-szintre, így a korlátozásokat nem lehet delegálással megkerülni.
9.1.467
  • Kifejezett átviteli adaptert ad az ágensfuttatásokhoz, anélkül hogy elfogná a feldolgozatlan modellek vagy modelllisták meglévő útvonalait.
  • Az eszközeredményeket és a célzott megszakításokat ugyanahhoz az ügyfél-, munkamenet- és kérési hatókörhöz köti.
  • Kizárólag a King-et mutatja, megtisztítja a váratlan belső hibákat, és elutasítja a streamelést, amíg nincs rá ágensszerződés.
9.1.466
  • Az Agent API minden befejezett modellhívását stabil feladat-azonosító alatt rögzíti, anélkül hogy összevonná a különböző ügyfelek használatát.
  • Egy tartós JSONL-hozzárendelés a kérést, a munkamenetet, a feladatot, a hívás-azonosítót és a feldolgozatlan használati mezőket újraindítás után is megtalálhatóvá teszi.
  • Kifelé csak a King és a feldolgozatlan számlálók jelennek meg a bemenetre, a gyorsítótárazott bemenetre és a befejezésre; a hiányzó használati adatok kifejezetten jelölve maradnak.
9.1.465
  • Elkülönített futtatásvezérlést ad az Agent API kifejezett ágens-végpontjához, anélkül hogy módosítaná a feldolgozatlan modellbefejezéseket.
  • A kliens által felügyelt eszközhívások az eredmény-visszatéréseken át egyetlen King-futtatást tartanak meg, és az eredeti kérésre korlátozottak maradnak.
  • A szülőágensek válaszai kizárják a gyermekágensek eseményfolyamait és az újrapróbálkozások elvetett tervezeteit.
9.1.464
  • A felügyelt alágensek mostantól leválasztva futnak, így a főágens elérhető marad, miközben a delegált munka folytatódik.
  • A futó alágensek a TaskUpdate paranccsal vezérelhetők vagy a TaskStop paranccsal leállíthatók, anélkül hogy a fő munkamenet bezáródna.
  • A címzett Telegram-csoportüzenetek a fókuszban maradnak, amíg az ágens a megfelelő csevegésben nem válaszol.
9.1.463
  • A checkpoint-folytatás meglévő ablakadatok esetén csak a legutóbb aktív TUI-menetcsoportot jeleníti meg; a régebbi sorok a görgetési archívumban maradnak, és szükség esetén utántöltődnek.
9.1.462
  • A változatlan tui.toml-tartalmak nem váltanak ki többé atomi fájlcserét; a valódi módosítások továbbra is a meglévő zárolt írási útvonalat használják.
9.1.461
  • A /status megkülönbözteti a betöltött futásidejű állapotot a telepített csomagtól, és az eltérést a Telegram-távállapotban is jelenti.
9.1.460
  • A régebbi látható munkamenet-üzenetek tartós lemezarchívumban maradnak, és felfelé görgetéskor blokkonként töltődnek be, anélkül hogy indításkor minden szövegblokkot beolvasnának.
9.1.459
  • Egy folytatás egy integritáskötött szemantikus ellenőrzőpontot állít helyre, és csak a változatlan munkamenet-fájl azóta hozzáfűzött részét olvassa be; érvénytelen ellenőrzőpont esetén a teljes visszajátszás marad tartalékként.
9.1.458
  • Egy külső jelentésből átvett ellenőrzőösszeget csak akkor köt hozzá, ha pontosan ez az érték szerepel a kiválasztott forráseseményben.
9.1.457
  • Ha ugyanaz az ellenőrzőösszeg több külső eseményből származik, a származás kétértelműként van feltüntetve, nem pedig egyetlen jelentésnek tulajdonítva.
9.1.456
  • A kimenő Telegram-üzenetek ellenőrzőösszegeit a helyi eszközeredményekkel és a látható külső jelentésekkel veti össze; a nem hozzárendelt értékek származási megjegyzést eredményeznek.
9.1.455
  • A Telegram-jelentések a csevegés- és üzenetazonosító alapján credible_unverified értékként köthetők; a jelentőt és az esemény származását a futtatókörnyezet állítja be.
9.1.454
  • A friss ellenőrzések automatikusan a létrehozó munkamenethez és a létrehozó ágenshez kötődnek; a továbbított mérések külső jelentések maradnak.
9.1.453
  • Egy befejezési bizonylat az aktuálisan érvényes befejezési feltételhez kötődik, más vagy elavult feltétel esetén pedig a rendszer elutasítja.
9.1.452
  • Minden bizonylat a ténylegesen mért célterülethez kötődik; a parancs-ellenőrzéseknek mindkét oldalon ugyanazt a biztonságos BLUN_EVIDENCE_SCOPE értéket kell használniuk.
9.1.451
  • Minden bizonylat pontosan az inspection, integrity, syntax, test vagy reachability típust viseli. Egy gyengébb ellenőrzés nem adható ki erősebbként.
9.1.450
  • Az eredmény-bizonylatok és az ellenőri bizonylatok elkülönülnek. Csak egy új vagy módosított ellenőrnek van szüksége egy második, önálló szigorúsági igazolásra; a normál mérésekhez nem kell ellenpróba.
9.1.449
  • A befejezési bizonylat a sikeres ellenőrzőhívás pontos toolCallId-ját nevezi meg; egy módosítást és ellenőrzést keverő parancshívás nem elegendő.
9.1.448
  • Egy célbefejezésnek az ellenőrzött állítást ugyanannak a menetnek egy sikeres ellenőrzőhívásához kell kötnie; a pusztán író- vagy módosító eszközök nem számítanak bizonylatnak.
9.1.447
  • Egy kiválasztott cselekvés tartós döntési bizonylatokhoz kötődik; ismeretlen vagy elavult bizonylatok új tervezést kényszerítenek ki.
9.1.446
  • Az élő ismétlésgátló emellett rövid, ismétlődő szókapcsolatokat is felismer, két-nyolc szó hosszúságban.
9.1.445
  • A kiválasztott tanulási megjegyzések az aktuális menet validált tanulási eredményével együtt expozíciós nyomként tárolódnak, anélkül hogy okozatiságot állítanának.
9.1.444
  • A korábbi hibák relevancia-keresése tartós cél-, ellenőrzőpont- és problémakeret-adatokat használ a legutóbbi felhasználói üzenetek helyett.
9.1.443
  • Azonnali célfolytatás esetén egy kifejezett tool:- vagy skill:-választás pontosan a kiválasztott eszközt tölti be.
9.1.442
  • A munkafókusz megőrzi a döntési szálat az állapotból, fázisból, utolsó ellenőrzésből, választásból, indoklásból, támogatásból, kockázatból és visszafordíthatóságból.
9.1.441
  • A hiányzó tudás saját knowledge_gap-tartományként szerepel az általános célszöveg helyett, priorizálva, és üres érték esetén elrejtve.
9.1.440
  • A világismeret és a feltételezések saját tartományként felvehetők a tartós fókuszba, és súlyozhatók.
9.1.439
  • A tartós kognitív fókusz kiemelkedési értékelést kap, a munkamenetek közötti elhalással és az ismételt hozzáférés esetén erősítéssel.
9.1.438
  • A munkamenet-visszajátszás alatt a vágás, az összevonás és a megjelenítés elhalasztódik; ezt követően a rendszer pontosan egy új transcript-megjelenítést kér.
9.1.437
  • Az üresjárati őr az időtúllépésekhez ismét a megfelelő szövegútvonalat használja, és már nem az időzítő egy nem engedélyezett paraméterével fejezi be a folyamatot.
9.1.436
  • A Telegram-távállapot aktív menet esetén mutatja a kezdést, az utolsó előrehaladást, az utolsó eszközt és az ismételt hibákat; a TUI ehhez futó aktivitás-pillanatképeket tesz közzé.
9.1.435
  • A privát Telegram-fókuszellenőrzőpontok mostantól azt a munkaterületet követik, amelyhez az aktív munkamenet kötődik.
  • A munkaterület kiválasztása nem tárolja tovább az indítókönyvtárat folytatási helyként a közvetlen beszélgetésekhez.
9.1.434
  • A megerősített tanulás mostantól azt a munkaterületet követi, amelyhez az aktív ágens-munkamenet kötődik.
  • A több munkaterülettel rendelkező és a folytatott munkamenetek nem tárolják vagy mutatják tovább a projektleckéket a gazdafolyamat könyvtárában.
9.1.433
  • A külső szerkesztőben történő bevitel-előkészítés mostantól az ideiglenes könyvtárak tisztítási határán belül marad.
  • Ha az első írási művelet meghiúsul, például teli lemez vagy hiányzó jogosultságok miatt, a rendszer eltávolítja az ideiglenes szerkesztőkönyvtárat, mielőtt a hiba továbbadódna.
9.1.432
  • Az átmeneti stream-hibák mostantól a látható részleges kimenet után is újrapróbálhatók ugyanazzal a kiválasztott modellel.
  • A hiányos asszisztens-szöveget és a be nem fejezett eszközfelületeket a rendszer a megismétlés előtt lezárja vagy elveti, hogy az új kimenet ne a sikertelen kísérlethez kapcsolódjon.
  • Látható kimenet után a szolgáltatóváltás zárolva marad, így egy válasz nem válthat szolgáltatót a stream közepén.
9.1.431
  • A Bash-eszköz helyi folyamatai mostantól kényszerítve letiltják a Git-lekérdezéseket a terminálban, ahelyett hogy a szülőfolyamat interaktív beállítását örökölnék.
  • A Git, az SSH és a Git Credential Manager örökölt askpass-párbeszédpanelei le vannak tiltva az eszköz-gyermekfolyamatban; így megelőzhetők a láthatatlan várakozások a Windows-bejelentkezési adatokra.
  • A szülőhéj és a futó munkamenet környezete változatlan marad; a zárt szabványos bemenet melletti meglévő viselkedés megmarad, és függetlenül biztosított.
9.1.430
  • A teljes tömörítés mostantól opcionálisan konfigurált modell-aliast használhat a [loop_control].compaction_model elemen keresztül; az aktív King-modell marad az alapértelmezés.
  • A tömörítés hitelesítése, kontextus-előkészítése, befejezési költségvetése, túlcsordulási tanulása és használat-elszámolása teljes mértékben a kiválasztott tömörítési modellhez kötődik.
  • Az aktív modell továbbra is meghatározza a tömörítés kezdetét és az utolsó kérési féket, így egy kisebb összefoglaló modell nem csökkentheti észrevétlenül a központi gondolkodási ablakot.
9.1.429
  • A Bash Windows alatt mostantól a folyamatindítás előtt visszautasítja az egyértelmű cmd.exe szintaxist, ahelyett hogy egy láthatóan sikertelen futtatást pazarolna el.
  • A Bash-eszköz leírása kifejezetten tisztázza, hogy a POSIX-Bash Windows alatt, a VS Code-ot is beleértve aktív marad, és megnevezi a helyes konvenciókat az elérési utakhoz és az átirányításokhoz.
  • A helyes POSIX-find parancsok engedélyezettek maradnak; a tudatosan kívánt cmd-szemantikához továbbra is kifejezett átadás áll rendelkezésre a cmd.exe /c paranccsal.
9.1.428
  • A generált JavaScript- és TypeScript-írások mostantól a lemez-hozzáférés előtt leállnak, ha egy végrehajtható utasítás nyolcszor egymás után ismétlődik; így megelőzhetők az elemző szkriptek elszabadult kimenetei.
  • A védelmi ellenőrzés mind a teljes fájlokra vonatkozó Write-hívásokat, mind az Edit-helyettesítéseket lefedi, miközben a nem kódfájlok, megjegyzések, karakterláncok és rövidebb jogos ismétlések változatlanok maradnak.
  • Mindhárom megfigyelt elfajulási eset 15, 23 és 31 ismételt utasítással blokkolva van; tetszőleges hiányos, de nem ismétlő szándékok továbbra is e mechanikus ellenőrzésen kívül esnek.
9.1.427
  • A látható /memory core parancs mostantól jelenti a memóriaadapter aktív határát, a szerződésverziót, az identitásmódot, az integritásállapotot és a portálok közötti bizonylatokat, opcionálisan --json kimenettel.
  • A profilhoz kötött helyettesítő memória és a profilokból származtatott identitások kifejezetten ki vannak zárva a közös magra való felkészültségből, ahelyett hogy portálsemleges memóriaként lennének bemutatva.
  • A konfigurált szolgáltatók láthatóan megerősítetlenek maradnak, amíg külön bizonylatok nem állnak rendelkezésre; a diagnózis írásvédett, nem ad jogosultságokat, és soha nem talál ki portálok közötti igazolásokat.
9.1.426
  • A látható /memory acceptance parancs mostantól szintetikus ideiglenes V7-memória-ellenőrzést futtat a CLI, a Telegram és a web között, és opcionálisan --json jelentést adhat ki.
  • Tíz független ellenőrzés fedi le a portálszármazást, a kapcsolt és kapcsolatlan identitásokat, az ágens- és csoport-izolációt, a deduplikációt, a globális javítást és törlést, a szolgáltató biztonságos zárolását és a védett forrásbájtokat.
  • Az átvételi jelentés kizárólag determinisztikus bizonylatként szolgál: nem ad jogosultságokat, és soha nem olvas vagy módosít valódi felhasználói profilt.
9.1.425
  • Azok az alágensek, amelyek elérik a tokenkorlátjukat, mostantól ugyanabban az ágenskontextusban egy szűkszavú, eszközmentes átadási menetet kapnak, ahelyett hogy az elkészült eszközmunkát elveszítenék.
  • Ha ez az átadás is eléri a korlátot, a szülőágens egy korlátozott részösszefoglalót és pontos utasítást kap arra, hogy ugyanaz az ágens folytassa a munkát.
  • A helyreállítás továbbra is a biztonságos zárolás elvét követi: nincs a feladat teljes újrapróbálása, nincs kész-jelentés záró átadás nélkül, és nincsenek új jogosultságok.
9.1.424
  • A Mistake.md megerősített leckéi mostantól átkerülnek a másként megfogalmazott, de szemantikailag hasonló esetekre a megbízhatóság, a kézbesítés, az összehangolás, a memória, a közzététel, a média és a validálás területéről.
  • A pontos bizonylatkifejezések továbbra is elsőbbséget élveznek a tág szemantikai kategóriákkal szemben; a nem kapcsolódó szöveg hozzárendelés nélkül marad.
  • A természetes német megfogalmazásokat a rendszer determinisztikusan egységesíti; a módosított sorrend sem hoz létre új jogosultságokat, és nem sorolja feljebb a meg nem erősített leckét.
9.1.423
  • A futásidejű leállások mostantól tartós, szinkron diagnosztikai bejegyzést írnak, mielőtt a mag vagy az indító visszatérne vagy befejeződne.
  • A le nem kezelt kivételek, a kezeletlen elutasítások, a meghibásodott terminálok, a jelek, az indítási hibák, a normál befejeződések, a gyermekfolyamatok hibái és azok befejeződései megőrzik a pontos, megtisztított okot a folyamathatárral együtt.
  • A privát napló korlátozott és meghibásodás-tűrő, eltávolítja a titkokat és a home-útvonalakat, és nem indít újra vagy tölt be futó munkamenetet.
9.1.422
  • Egy megnyitott, tétlen munkamenet mostantól figyeli a tárolt időalapú kiváltóját, és az Automatik- és God módban dueAt időpontban vagy után aktívvá válik.
  • Egy esedékes kiváltó megvárja, amíg az aktív válaszok, a tömörítés, a sorba állított üzenetek, a parancsok és a párbeszédek befejeződnek, mielőtt pontosan egyszer folytatódna.
  • Az indítás előtt a futtatókörnyezet újra beolvassa a célt, az ellenőrzőpont-revíziót, az esedékességet, az engedélymódot és a munkamenetet, és a munkamenet minden befejezési útvonalán eldobja az időzítőket.
9.1.421
  • Az időalapú várakozási ellenőrzőpontok mostantól pontos dueAt időbélyeget tárolnak, és UTC-re egységesítik.
  • Egy szabályos munkamenet-indítás az Automatik- vagy God módban a jövőbeli időalapú kiváltókat várakoztatja, és esedékességkor vagy után folytatja azokat.
  • Az első folytatott menet megkapja a pontos esedékesség-megfigyelést; a folyamatosan megnyitott munkamenetek ebben a verzióban még nem kapnak futásidejű időzítőt.
9.1.420
  • Egy tartós várakozási ellenőrzőponttal rendelkező aktív cél az aktuális menet után átadja az irányítást, ahelyett hogy további autonóm menetet rendelne hozzá.
  • A külső, időalapú, függőségalapú és felhasználói döntésektől függő kiváltók tárolva maradnak, és a következő esemény beérkezésekor újra kiértékelődnek.
  • Az azonnali célok és a régebbi, ellenőrzőpont nélküli aktív célok változatlanul folytatódnak.
9.1.419
  • Egy szabályosan folytatott munkamenet mostantól egy már aktív célt visz tovább, ha annak tárolt következő kiváltója kifejezetten azonnali, és az Automatik- vagy God mód aktív.
  • A folytatás belső marad, munkamenetenként legfeljebb egyszer fut, és soha nem jelenik meg kitalált felhasználói üzenetként.
  • A várakozó, szüneteltetett és blokkolt célok, a hiányzó ellenőrzőpontok és a manuális engedélymódok továbbra is felfüggesztve maradnak.
9.1.418
  • A Telegram mostantól megőrzi a feladó kifejezett bot-jelölését a bemeneti adatokban, így az identitáskontextus meg tudja különböztetni az ágenseket az emberektől.
  • A már emberként tárolt Telegram-szereplők csak akkor javítódnak át ágenssé, ha a szolgáltató, a szubjektum és a kifejezett bot-jelölés egyezik.
  • A szereplői adatok megmaradnak, az ágenseket soha nem minősítik le, és a neveket vagy felhasználóneveket soha nem használják ágensidentitás kikövetkeztetésére.
9.1.417
  • Az automatikus Telegram-helyettesítő válaszok a 4 096 karakternél hosszabb válaszokat mostantól egymást követő üzenetekre bontják, ahelyett hogy lerövidítenék őket.
  • Minden karakter és minden Unicode-surrogátpár megmarad; a kimenet az összes visszaadott üzenet-azonosítót a teljes szöveggel együtt rögzíti.
  • Ha egy rész meghiúsul, a kézbesítés ott megáll, ahelyett hogy egy hiányos választ teljesként jelentene.
9.1.416
  • A legutóbbi eszközhívás-köteg friss eredményei a következő asszisztensválaszig teljesen olvashatók maradnak, még akkor is, ha ezután Telegram- vagy vezérlési kontextus kerül be.
  • A kötegkihelyezés, az előzmény-takarítás és a mikro-tömörítés mostantól ugyanazt a szemantikai határt használja a friss eredményekhez.
  • A már kiértékelt régebbi eredmények továbbra is normál módon tömörülnek, így a meglévő kontextus-megtakarítások megmaradnak.
9.1.415
  • A tartós munkafókusz mostantól újraindításokon és kontextusváltásokon át megőrzi a következő művelet pontos kiváltóját.
  • A következő művelet elválasztva marad a jóváhagyási feltételétől; ez érvényes az 512 karakternél hosszabb érvényes feltételekre is.
  • A rendszer biztonságosan elutasítja a hibás vagy a fázishoz nem illő kiváltókat; a régebbi ellenőrzőpontok megtartják a korábbi viselkedésüket.
9.1.414
  • Az új tartós műveleti ellenőrzőpontok rögzítik a pontos kiváltót, amely jóváhagyja a következő műveletet.
  • A nem várakozó fázisok azonnali kiváltót igényelnek; a várakozó fázisok megnevezett külső eseményt, időpontot, függőséget vagy felhasználói döntést igényelnek.
  • A várakozó célok aktívak maradnak, anélkül hogy idő előtt végrehajtódnának; a régebbi ellenőrzőpontok olvashatók maradnak.
9.1.413
  • A modell kimeneti korlátját elérő Telegram-válaszokat a rendszer többé nem kézbesíti hiányos kezdeményként.
  • Ugyanaz a futó munkamenet egy szűkszavú, teljes folytatást hoz létre, és legfeljebb három helyreállítási kísérletet tesz, mielőtt biztonságosan megszakad.
  • Egy kifejezett válasz a Telegram-eszközön keresztül továbbra is elsőbbséget élvez, és elnyomja a helyreállítást, így a sikeres küldések soha nem duplikálódnak.
9.1.412
  • A modell által létrehozott tartós célok mostantól atomikusan kezdődnek 1-es revízióval és teljes, korlátozott problémakerettel.
  • A God mód és az Automatik mód egy már felhatalmazott célindítást folytat második megerősítés nélkül; manuális módban a jóváhagyás továbbra is szükséges.
  • Hitelesített, nem triviális többlépcsős munka egy meglévő autonóm utasítás alatt átválthat tartós célmódba; a köszöntések, egylépéses kérések és homályos feladatok kizárva maradnak.
9.1.411
  • A nem triviális és ismeretlen feladatok mostantól korlátozott problémakeretet tárolhatnak a tartós műveleti ellenőrzőpontban.
  • A keret rögzíti a sikerfeltételeket, a hiányzó tudást, legfeljebb öt lehetséges műveletet, a kiválasztott műveletet indoklással, a támogatás választását, a kockázatot és a tartalék útvonalat.
  • A problémakeret a folytatást és az újraindítást kizárólag leíró állapotként éli túl, és soha nem adhat jogosultságokat.
9.1.410
  • A privát Telegram-memóriaparancsok mostantól az adott személyre korlátozzák a kapcsolati kört.
  • A memóriafókusz kiszűri más személyek kapcsolatait, és megtartja a fennmaradó kontextust.
  • A javítások és törlések nem választhatnak ki más személy kapcsolatát; a helyi üzemeltetői fókusz megtartja a teljes rálátást.
9.1.409
  • A Telegram-válaszeszközök és a TUI tartalék útvonala mostantól közös kanonikus könyvtárat használnak a csatornaállapothoz.
  • A profilspecifikus BLUN_HOME értékek többé nem hoznak létre második könyvtárfát a Telegram be- és kimenetekhez.
  • Egy kifejezetten beállított BLUN_TELEGRAM_STATE_DIR továbbra is meghatározó; egyébként mindkét útvonal a ~/.blun/channels/telegram könyvtárat használja.
9.1.408
  • A megerősített kapcsolati részletek csak két, közvetlen csatornákban tett független megfigyelés után vonódnak össze.
  • Az újra lejátszott üzenetek idempotensek maradnak; a csoportüzenetek és a jogosultságszerű állítások kizárva maradnak.
  • A megerősített privát kapcsolati emlékeztetők ugyanazt a személyt követhetik Telegram-on és CLI-n át, anélkül hogy jogosultságokat adnának.
9.1.407
  • A Telegram-válaszeszköz importálja a duplikációfelismerés által használt útvonalat a futó bemeneti előzményekhez.
  • A normál Telegram-válaszok többé nem hiúsulnak meg az inboxLog is not defined hibával.
  • A különálló bridge-tartalékútvonal továbbra is elérhető a kézbesítés biztosítékaként.
9.1.406
  • A privát Telegram-események ismételt kézbesítési kísérletei azonos időbélyeggel és szöveggel csak egyszer tárolódnak a kapcsolatfolytonosságban.
  • Egy ténylegesen később megismételt állítás a korlátozott kapcsolati előzmények része marad.
  • A rendszer a mondat végén álló, természetesen megfogalmazott, kifejezett emlékeztető megjegyzéseket referenciaadatként ismeri fel, anélkül hogy jogosultságokat adna vagy módosítana.
9.1.405
  • A csatolt Telegram-/status parancs mostantól jelenti a konzolfolyamat korát és pulzusát, az aktuális munkalépést és az aktív feladatot, anélkül hogy a modellt meghívná.
  • A várósor-hátralék mostantól az olvasatlan bájtokat egy olyan ellenőrzőponttól méri, amely a pontos aktuális várósor-fájlhoz kötődik.
  • A távállapot írásvédett marad, és nem tartalmaz csevegés-azonosítókat, fájlútvonalakat, hozzáférési adatokat, üzenettartalmakat vagy teljes feladatlistákat.
9.1.404
  • A config.toml változatlan tartalma többé nem írja felül a meglévő privát fájlt.
  • A pontos bájt-összehasonlítás azokra a szabályos célokra korlátozódik, amelyek nem szimbolikus hivatkozások.
  • A módosított, hiányzó, érvénytelen és nem olvasható célok továbbra is a meglévő összeomlás-biztos atomi írási útvonalat használják.
9.1.403
  • A betölthető eszközök automatikus rangsorolása figyelmen kívül hagyja a beágyazott melléklet- és dokumentumterheket.
  • Minden szándéktöredék a lexikális összevetés előtt a meglévő ToolSearch-lekérdezési keretre, 1 000 karakterre van korlátozva.
  • A tényleges utasítások, mellékletek és kifejezett ToolSearch-lekérdezések változatlanok maradnak.
9.1.402
  • Egy King-parancs indításakor a rendszer egyszer, a háttérben kitakarítja a tömörítési előzmények lejárt archívumait.
  • A start-takarítás nem blokkoló jellegű marad, és nem késleltetheti a normál parancsfeldolgozást.
  • A takarítási hibák biztonságosan naplózódnak, és nem szakítják meg a futó munkamenetet.
9.1.401
  • Minden futó válasz első szövegtöredéke mostantól azonnal megjelenik, ahelyett hogy egy időzítő-visszahívásra várna.
  • Egy új menet és minden új asszisztensválasz-szegmens saját azonnali első megjelenítést kap.
  • A későbbi szöveg-, gondolkodás- és eszköztöredékek megtartják az adaptív kötegelési ritmust, amely a hosszú munkamenetek teljesítményét védi.
9.1.400
  • A nagy, folytatott munkamenetek mostantól együttműködő módon játszódnak vissza, így a TUI az előzmények helyreállítása közben újrarajzolhat és reagálhat.
  • Minden tartósan tárolt visszajátszási rekord továbbra is megjelenik; a rendszer az előzmények egyetlen részét sem vágja le, hagyja ki vagy törli.
  • A kis folytatások megtartják a korábbi viselkedésüket; a nagy folytatások minden 30 rekord után átadják a végrehajtást az eseményhuroknak.
9.1.399
  • A megvizsgált tanulási jelöltek mostantól az aktuális Git-projektre korlátozódnak, ahelyett hogy nem kapcsolódó tárolókba kerülnének.
  • Az azonos eredetű HTTPS- és SSH-checkoutok közös anonim projektidentitást használnak.
  • A tároló-URL-ek és a helyi projektútvonalak soha nem tárolódnak a tanulási jelöltek rekordjaiban; a Git-en kívüli munka megtartja a meglévő profilszintű viselkedést.
9.1.398
  • A csak szöveget tartalmazó Telegram-válaszok deduplikálása mostantól az eszközútvonalra és mindkét automatikus tartalék útvonalra is kiterjed.
  • Egy azonos vagy majdnem azonos választ a rendszer csak akkor nyom el, ha nincs újabb beérkezett üzenet.
  • A mellékletek, a különböző eredmények és az új felhasználói üzenet utáni válaszok megtartják a korábbi viselkedésüket.
9.1.397
  • A kifejezett befejezési feltétellel rendelkező célok a befejezés előtt mostantól futásidejűleg alátámasztott ellenőrzőpontot igényelnek.
  • Ha a befejezési ellenőrzés meghiúsul, a cél aktív marad, és konkrét átdolgozási útmutatást ad vissza.
  • A szokásos menetek és a kifejezett befejezési feltétel nélküli célok megtartják a korábbi viselkedésüket.
9.1.396
  • A természetes lekérdezések ugyanabban a menetben legfeljebb két, nagy biztonsággal illeszkedő betölthető eszköz-sémát választhatnak ki előre.
  • A kiválasztás kizárólag a csatorna aktuális szándékát veszi figyelembe, és figyelmen kívül hagyja az elavult Telegram-kontextust.
  • Gyenge, kétértelmű vagy ismeretlen lekérdezésekhez a ToolSearch továbbra is elérhető marad, anélkül hogy a tartósan betöltött eszközkészletet növelné.
9.1.395
  • A rendszer az elfogadott médiamegrendeléseket tartósan nyomon követi, az azonos nyitott kéréseket újrahasznosítja, az elkészült eredményeket pedig minőségvizsgálat után tárolja, és kézbesíti a hozzá tartozó csevegésnek.
9.1.394
  • Egy verziózott, önkéntesen aktiválható tárolásszolgáltató összekötheti a CLI- és portálmeneteket egy közös kognitív eseményfolyammal.
  • Alapértelmezésben a meglévő helyi SQLite-tároló marad, új hálózati hozzáférés vagy módosított futásidejű viselkedés nélkül.
  • A rendszer a szolgáltatói útvonalakat, a szinkron gyárfüggvényeket és a 6-os szerződésverziót mostantól a futtatókörnyezet indítása előtt biztonságosan ellenőrzi, eltérés esetén pedig elutasítja.
9.1.393
  • Az interaktív indítások king és king -c paranccsal újra megmutatják a látható 1/2/3 frissítési választást, amint újabb verzió áll rendelkezésre.
  • A frissítések háttérben történő letöltése, a függőben lévő aktiválás és a késleltetett automatikus váltás megszűnt.
  • Egy kiválasztott telepítés után a king kézi újraindítás céljából kilép; a king -c az utolsó munkamenetet az új verzióval folytatja.
9.1.392
  • Egy képgenerálás hiányos köztes állapotai többé nem mennek ki privát Telegram-frissítésként, amíg nincs médiaeredmény.
  • A rendszer elnyomja a GenerateImage és GetMedia mért hibaleírásait; az elkészült médiakézbesítések láthatóak maradnak.
  • A privát beszélgetések és a szokásos, kért eredmények változatlanok maradnak.
9.1.391
  • A portálok közötti memóriafolytonosság mostantól a megbízható futtatókörnyezet pontos, aktív identitás-összekapcsolási bizonylatát követeli meg.
  • A hasonló nevek, eltérő bérlők vagy forrásazonosságok, hamis kibocsátók és visszavont bizonylatok elkülönülve maradnak, és a rendszer biztonságosan elutasítja őket.
  • A memóriaadapter-szerződés 6-os verziója támogatja a hitelesített OAuth-t, a biztonságos fiók-összekapcsolásokat és a kifejezetten megerősített identitás-hozzárendeléseket, anélkül hogy az emlékekből jogosultságokat vezetne le.
9.1.390
  • A közös memóriaboríték mostantól külön rögzíti az esemény időpontját és a beérkezés időpontját.
  • Minden új kognitív esemény kifejezetten megőrzési osztályt kap az üzemeltetési adatok, a tartós adatok, a kapcsolatok vagy az ellenőrzési célok számára.
  • A memóriaadapter-szerződés 5-ös verziója a hiányos eseményborítékokat minden helyi vagy távoli írási művelet előtt elutasítja.
9.1.389
  • A memóriaesemények mostantól külön, hitelesített származási mezőként rögzítik a forrásportált és a forráscsatornát.
  • A CLI-, Telegram-, futásidejű, személyiség-, javítási és visszavonási útvonalak tároláskor és visszajátszáskor is megőrzik a pontos csatornát.
  • A memóriaadapter-szerződés 4-es verziója elutasítja az írási műveleteket, ha a tárolt forráscsatorna nem egyezik az engedély által jóváhagyott csatornával.
9.1.388
  • A memóriaolvasások csak az engedély által jóváhagyott láthatósági körből adnak vissza megfigyeléseket, kivéve, ha a szigorúan belső ágensútvonalat használják.
  • A rendszer biztonságosan elutasítja az írási műveleteket, az esemény-ellenőrzéseket és az attention-műveleteket, ha az érvényességi körük vagy hitelesített forrásuk nem illik az aktuális hozzáférési kontextushoz.
  • A helyi SQLite-adapter a behatárolt megfigyeléseket saját láthatósági indexen keresztül kérdezi le, ahelyett hogy először nem kapcsolódó emlékeket töltene be.
9.1.387
  • A memóriaadapter minden művelete mostantól szigorú kontextust visz magával az identitás, a portál, a csatorna, a beszélgetés, az érvényességi kör és a jogosultságok számára.
  • A rendszer a jogosultsági kontextust a memóriaterhen kívül ellenőrzi, és nem tárolja tartósan emlékezett tartalomként.
  • Az események deduplikálása bérlőre és ágensre korlátozódik. Így az események létezése nem ismerhető fel bérlők között.
9.1.386
  • A kognitív állapot mostantól egy verziózott memóriaadapter-szerződés mögött áll, amelyet a menet életciklusa és a személyiség-futtatókörnyezet közösen használ.
  • A meglévő SQLite-eseménytároló marad az alapértelmezés. A külső portálkliensek ugyanazt a szerződést biztosíthatják, anélkül hogy portál-saját állapotot hoznának létre.
  • A rendszer minden memóriaművelet előtt biztonságosan elutasítja a nem támogatott adapterverziókat és a hiányos megvalósításokat.
9.1.385
  • A munkamenet-indítás előtt sorba állított Telegram-üzenetek mostantól felszabadulnak, amint a munkamenet készen áll.
  • Az üresjárati munkamenetek normál FIFO-sorrendben ürítik a várósort; a már folytatott aktív menetek korlátozott vezérlést használnak.
  • A tartós várósor-ellenőrzőpontok változatlanok maradnak, amíg az üzenetet ténylegesen el nem fogadták.
9.1.384
  • A Telegram-képekre mutató hivatkozások mostantól ugyanabban a menetben betöltik a képvizsgálati és képgenerálási eszközöket.
  • A pufferelt Telegram-üzenetek a teljes függőben lévő köteg média-szándékát megőrzik, ahelyett hogy csak az utolsó üzenetet vennék figyelembe.
  • A helyi képútvonalak és a Telegram-fájlazonosítók a megfelelő vizsgálati vagy letöltési útvonalat választják, anélkül hogy a médiasémákat tartósan betöltenék.
9.1.383
  • Az új Read-eredmények mostantól az őket kérő modelllépés számára teljesen láthatóak maradnak, ahelyett hogy a kiértékelés előtt kiszerveznék őket.
  • A párhuzamos új eszközeredmények a kiértékelési lépésükig olvashatók maradnak, és csak azután archiválhatók, hogy történetivé váltak.
  • A történeti kimenetek archiválása és a kontextus-megtakarítás a legutóbbi munka védett ablaka után is aktív marad.
9.1.382
  • A /loop parancsot a rendszer mostantól akkor is elfogadja, amikor egy másik válasz fut.
  • Ha futó munka közben hurok jön létre, a King eltárolja, és sorba állítja az első utasítását, anélkül hogy megszakítaná az aktuális menetet.
  • A huroklétrehozás üresjáratban, valamint a státusz, szünet, folytatás és leállítás meglévő viselkedése változatlan marad.
9.1.381
  • Egy véglegesen sikertelen ToolSearch után a ToolSearch a menet hátralevő részére lekerül az aktív eszközlistáról.
  • A sikeres sémafelismerés és a már betöltött eszközök kezelése elérhető és változatlan marad.
  • Így az ismételt szinonima-keresések nem fogyasztanak további tokeneket, miután a futtatókörnyezet már igazolta, hogy nincs megfelelő integráció.
9.1.380
  • Az aktív menet vezérlésének átmeneti hibája mostantól azonnal újraaktiválja a Telegram-kézbesítés-vezérlést, ahelyett hogy a helyreállított csoportüzenetet a menet végéig várakoztatná.
  • A függőben lévő csoportüzenetek hosszú munka közben is folyamatosan kézbesítődnek; közben a FIFO-sorrend és a három kísérlet meglévő karanténhatára megmarad.
  • Egyetlen futó munkamenet sem szakad meg vagy indul újra.
9.1.379
  • A csatornavezérlés visszaigazolásának átmeneti ismétlései többé nem mutatnak hamis piros hibát, amíg az üzenet a várósorban helyreállítható marad.
  • Látható kézbesítési hiba csak azután jelenik meg, hogy a harmadik sikertelen kísérlet biztonságosan archiválta a teljes első várósor-bejegyzést.
  • Az ismétlés, visszaigazolás, archiválás és FIFO-sorrend viselkedése változatlan marad.
9.1.378
  • Gyorsan egymást követő háttér-közzétételek esetén mostantól egyetlen, cserélhető státusz létezik az előkészített frissítéshez, ahelyett hogy minden verzióhoz új naplórészt fűznének hozzá.
  • Az előkészített frissítés bejegyzése mindig a legújabb ellenőrzött célverziót mutatja; az aktív munkamenet a természetes újraindításig érintetlen marad.
  • A tényleges telepítésre és a változásnaplóra vonatkozó megjegyzés tartósan és változatlanul megmarad. A napló kevesebb változása így nem rejthet el aktivált frissítést.
9.1.377
  • A függőben lévő Telegram-feladatok mostantól az aktív menet mértékadó azonosítóját veszik át a magtól. Egy elavult látható TUI-státusz így többé nem vezethet ahhoz, hogy egy elfogadott üzenet visszaigazolatlan maradjon.
  • A /loop vezérlőparancs futó munka közben azonnal végrehajtódik; a tartós parancs-visszaigazolás már nem függ egy sikeres Telegram-státuszválasztól.
  • Ha az első várósor-bejegyzés kézbesítése háromszor meghiúsul, az összes helyreállítási metaadattal együtt helyben archiválódik, mielőtt a várósor folytatódna. Így egy hibás bejegyzés nem blokkolja a későbbi üzeneteket.
9.1.376
  • A nagy, történeti eszközeredmények a kontextus-tömörítés előtt tartósan tárolódnak, így a teljes kimenetük a beágyazott előnézet ürítése után is helyreállítható marad.
  • A tárolt eredményhivatkozások túlélik a későbbi mikro-tömörítéseket, és megtartják az eredeti kimenet újratöltéséhez szükséges korlátozott metaadatokat.
  • A kihelyezési telemetria méreteket és helyreállítási státuszt jelent, anélkül hogy eredménytartalmakat vagy privát útvonalakat tárna fel.
9.1.375
  • A privát Telegram-üzenetek és a perjeles parancsok megtartják a legmagasabb kézbesítési prioritást. A kifejezetten címzett csoportmunka ezután FIFO-sorrendben kerül be a normál vagy nem címzett régebbi terhelés elé.
  • Egy frissítés-átadás csak akkor léphet át egy nem üres várósoron, ha minden bejegyzés tartósan tárolt, még vissza nem igazolt Telegram-munka visszaigazolási visszaúttal. A helyi, vegyes vagy nem tartós munka továbbra is blokkol.
  • A frissítés-előkészítési megjegyzés egy jóváhagyott személyiség-UI-nyelvet követ. Egy még TUI-lokálisként nem jóváhagyott nyelv esetén csak a verzióinformáció látható, ahelyett hogy rossz nyelvre váltana.
9.1.374
  • Az előkészített frissítés megjegyzése többé nem használ beépített német üzenetet, hanem az aktív nyelv már jóváhagyott UI-fordítását.
  • A folytatás és az új munkamenet módja elkülönülve marad; a frissítés-átadás, a visszaállítás és a Telegram-duplikátum-visszaigazolás nem lett felpuhítva.
9.1.373
  • Egy háttérben előkészített frissítés mostantól egy ellenőrzött biztonságos határon átveheti a futó munkamenetet. A munkamenet-azonosító és a munkakönyvtár megmarad; a futó eszközök, shell-parancsok, tömörítés és várakozó üzenetek megakadályozzák az átadást.
  • A felügyelő csak az új futtatókörnyezet loaded és ready bizonylata után aktiválja azt. Ha az indítás meghiúsul, a régi futtatókörnyezet a pontos munkamenettel együtt helyreáll, a hibás függő állapotot pedig elveti a rendszer.
  • A kézbesítési főkönyvben már helyreállított Telegram-duplikátumok a várósor-visszajátszáskor azonnal visszaigazolást kapnak. Már nem várnak olyan modelllépésre, amely egy duplikátumhoz szándékosan soha nem indul, így nem blokkolják a következő csoportüzeneteket.
  • A tartós munkafókusz mostantól a tudásstátuszt, a bizonylati kontextust, a javításokat, a visszavonásokat és a bizalmat meneteken át viszi. Ebből továbbra sem keletkeznek új jogok vagy jóváhagyások.
9.1.372
  • A tartós cél-ellenőrzőpontok mostantól megkülönböztetik a verified, credible_unverified, hypothesis, uncertain_memory, stale és unknown értékeket. A plauzibilis feltételezéseket így többé nem kezelik biztos tudásként.
  • A rendszer a származást és a tudásstátuszt együtt ellenőrzi: a futásidejű eszközbizonylatok csak sikeres eszközfutás után minősülhetnek verified értékűnek, a külső jelentések nem. Az átvitt állapotok megőrzik a korábbi státuszukat és az utolsó verifikációs bizonylatukat.
  • A régi, az új mező nélküli visszajátszási állapotok legacy_unknown értékként olvashatók maradnak. Az új ellenőrzőpontoknak kifejezetten meg kell nevezniük a státuszukat. A jogok, a jóváhagyások és a tekintély változatlanok maradnak.
  • A szűkszavú kontextus-vetítés pontosan egy sorban nevezi meg az episztemikus állapotot, hogy az ágens a következő lépésnél figyelembe vegye, anélkül hogy a kontextus-keretet kiegészítő szöveggel terhelné.
9.1.371
  • Egy bekötési hiba javítása a 9.1.370 verzióból: az ott már tárolt és vetített evidenceBasis érték mostantól a szigorú nyilvános GetGoal kimeneti séma részét is képezi, és lekéréskor már nem vész el.
  • A séma elfogadja a négy aktuális származási típust, valamint a régi visszajátszási állapotokhoz a legacy_unknown értéket. A jogok, a jóváhagyások és a tekintély változatlanok maradnak.
  • Egy fókuszált bekötési próba és egy saját mutáns biztosítja az új nyilvános kapcsolatot a visszaesés ellen.
9.1.370
  • Minden friss munka-ellenőrzőpont mostantól kifejezetten megnevezi, hogy a legutóbbi bizonylatolt állapota mire épül: sikeres futásidejű eszközhívásra, közvetlen felhasználói kijelentésre, külső jelentésre vagy változatlan továbbvezetésre.
  • A runtime_tool csak akkor fogadható el, ha az aktuális menet legalább egy, a futtatókörnyezet által engedélyezett és sikeresen befejezett eszközhívást tartalmaz. A carried_forward nem változtathatja meg a legutóbb bizonylatolt állapotot. Mindkét út ellentmondás esetén fail-closed módon szakad meg.
  • A régi tárolt ellenőrzőpontok legacy_unknown értékként olvashatók maradnak. A származási típus episztemikus állapot, és nem hoz létre sem jogokat, sem jóváhagyásokat, sem tekintélyt.
9.1.369
  • Egy tartós munka-ellenőrzőpont mostantól automatikusan kompakt futásidejű bizonylatot kap az ugyanazon menetben már befejezett eszközhívásokból. A bizonylat csak a menet-azonosítót, az összesített, a sikeres és a hibás számot, valamint egy rövid digestet nevez meg.
  • Az eszköznevek, azonosítók, argumentumok, parancsok, kimenetek, elérési utak és felhasználói szövegek nem kerülnek bele az ellenőrzőpontba. Egy üres bizonylat becsületesen nullán marad, ahelyett hogy mérést színlelne.
  • Csak a futásidejű szabályzat által jóváhagyott és sikeresen befejezett eszközhívás számít sikernek. A blokkolt, meghiúsult, megszakított vagy a modell által mellékelt bizonylatok nem hoznak létre tekintélyt.
9.1.368
  • Minden tartós munka-ellenőrzőpont mostantól monoton revíziót visel. Az első írási művelet az 1 revíziónál kezdődik; minden továbbinak pontosan eggyel növelnie kell az aktuálisan vetített revíziót.
  • Egy régi párhuzamos menet vagy egy elavult csatornanézet többé nem írhatja felül utólag egy újabb bizonylatolt munkaállapotot. Az elavult, átugrott és érvénytelen revíziók fail-closed módon szakadnak meg, mielőtt a célállapot módosulna.
  • A revíziómező nélküli meglévő ellenőrzőpontok olvasáskor kompatibilis módon 1 revízióként kezelődnek. A revízió munkaállapot, és nem hoz létre jogokat vagy jóváhagyásokat.
9.1.367
  • Az aktív cél-emlékeztető mostantól közvetlenül viseli a tartós munka-ellenőrzőpontot. A King így a fázist, az utolsó bizonylatolt állapotot, a pontos következő műveletet és a várt bizonylatot akkor is megtartja, ha a kiegészítő kognitív memóriaadapter éppen nem áll rendelkezésre.
  • Az alternatív utak előtt először a pontosan előjegyzett következő művelet hajtódik végre. Az ellenőrzőpont csak akkor módosul, ha az új bizonyíték valóban megváltoztatja a megerősített állapotot.
  • A tartalékmegoldás csak a már ellenőrzött ellenőrzőpont kompakt vetülete. Nem hoz létre jogokat, új adatmezőket és újraindítást sem.
9.1.366
  • Az aktív célok mostantól kis, tartós munka-ellenőrzőpontot tárolhatnak a fázissal, az utolsó bizonylatolt eredménnyel, a pontos következő művelettel és a várt bizonylattal. Folytatás vagy esemény-visszajátszás után a King innen folytatja, ahelyett hogy újra engedélyt kérne vagy elölről kezdené.
  • Egy csak az ellenőrzőpontot érintő frissítés aktívan hagyja a célt. A szüneteltetett és blokkolt célok változatlanok maradnak; egy folytatás csak a futásidő-órát állítja újra.
  • Az ellenőrzőpont szigorúan korlátozott és kizárólag munka-információ. Az ismeretlen mezők, különösen a jogosultsági vagy adminisztrációs adatok, fail-closed módon szakadnak meg, és nem hozhatnak létre képességet.
  • Ellenőrzőpont nélkül a korábbi kompakt fókusz változatlan marad. Ellenőrzőponttal csak a négy releváns fókusz-megfigyelés egészül ki a bizonylatolt állapottal; így a token-költség kicsi és állandó marad.
9.1.365
  • A privát Telegram-üzenetek és a helyi CLI mostantól közvetlenül olvashatják, javíthatják vagy törölhetik a tartós fókuszt a /memory focus, /memory correct <id> <érték> és /memory delete <id> paranccsal. Ez az út nem indít modellmenetet, ezért nem fogyaszt modelltokeneket.
  • A Telegram-módosítások pozitív felhasználó-, csevegés- és üzenet-azonosítókhoz, valódi privát üzenethez, a csatorna időpontjához és stabil kérés-azonosítóhoz kötöttek. A csoportok, a hiányos származás és a módosított ismétlések fail-closed módon szakadnak meg.
  • A tartomány, a kulcs és a hatókör mindig az aktív célbizonylatból származnak, és a hívó nem csempészheti be őket. A javítások és a törlésjelek append-only jellegűek maradnak, megőrzik az előzményeket, és nem adnak jogokat.
  • A fókusz-kimenet Telegram esetén nyolc bejegyzésre és kevesebb mint 3 500 karakterre korlátozott; a teljes szám látható marad.
9.1.364
  • A futó kognitív életciklus mostantól a correctFocusObservation paranccsal javíthatja, a withdrawFocusObservation paranccsal pedig törölheti a tartós fókuszt. Mindkét út továbbra is append-only módon ír ugyanabba a bérlőhöz és ágenshez kötött eseményfolyamba.
  • Egy revízió csak a runtime_user_prompt_hook és az explicit_user_request igazolással megengedett. Egy normál modell-pillanatkép sem javítást, sem törlést nem tud levezetni vagy becsempészni.
  • Minden revízió stabil kérés-azonosítót, valamint portált, szereplőt, kontextust, üzenetet és időpontot visel. Az azonos ismétlés idempotens; ugyanaz a kérés-azonosító módosított tartalommal és a visszadátumozott revíziók fail-closed módon szakadnak meg.
  • A javítás és az azt követő törlés változatlanul hagyja a teljes előzményeket. A törlés után a tény többé nem jelenik meg a promptban, és nem fogyaszt kontextus-tokeneket. A memória továbbra sem adhat jogokat.
9.1.363
  • Egy megerősített törlés mostantól append-only törlésjelként tárolódik. A korábbi tartalom megmarad az auditnaplóban és a hash-láncban, de teljesen eltűnik az érvényes kontextus-vetítésből.
  • A régi folytatási, transcript- vagy várósor-események a törlés előtti időponttal nem aktiválhatják újra az eltávolított tartalmat. Így egy később újra bejátszott régi állapot nem számít új igazságnak.
  • A törlés után tudatosan újra megadott információ újra megtanulható. A törlésjel tehát a régi bizonyítékokat zárja le, nem a jövőbeli fejlődést.
  • A rendszer tranzakciósan elutasítja az idegen bérlőkre, ágensekre, tartományokra, kulcsokra vagy hatókörökre vonatkozó, valamint a hiányzó céllal, gyenge bizalommal vagy hibás törlésjel-értékkel érkező törléseket. A meglévő adatbázisok helyben migrálnak.
  • Egy törölt tény nem hoz létre promptsort, így nem fogyaszt kontextus-tokeneket.
9.1.362
  • Egy megerősített javítás mostantól pontosan egy korábbi megfigyelést válthat le kifejezetten ugyanabban a bérlő-, ágens-, tartomány-, kulcs- és hatókör-területen. A régi bejegyzés append-only módon megmarad az auditnaplóban.
  • Az érvényes nézet a javított értéket tölti be, és corrected értékként jelöli; a lecserélt érték többé nem vetítődik aktuális konfliktusként.
  • A rendszer tranzakciósan elutasítja a hiányzó célokat, az idegen hatóköröket vagy kulcsokat és az 1 bizalom alatti javításokat.
  • A meglévő SQLite-állapotok a megnyitáskor megkapják az új kapcsolati oszlopot, anélkül hogy elveszítenék a korábbi streamjüket vagy verziójukat.
9.1.361
  • Az egyformán hiteles személyes vagy csapatkijelentéseket azonos hatókörrel és kulccsal többé nem adják ki igazságként a „legújabb érték nyer” elv szerint. A vetítés szűkszavúan jelöli a konfliktust, és tisztázást kér, anélkül hogy mindkét tartalmat a kontextusba öntené.
  • Ha egy kijelentés legalább 0,2 bizalmi ponttal erősebb, használható marad, de vitatottként jelölik meg. Egy későbbi gyengébb állítás többé nem fedheti el a megerősített állapotot.
  • Az azonos megerősítések egy fókuszponttá vonódnak össze. A kanonikus cél- és előrehaladási mezők továbbra is revízió-képesek maradnak.
  • Az append-only esemény-előzmény változatlan marad; az érvényes nézetből továbbra sem keletkezhetnek jogosultságok.
9.1.360
  • A már kanonikus /goal állapot tartós munkafókuszként vetítődik a kognitív eseményfolyamba: cél, státusz, következő kiváltó és várt sikerbizonylat.
  • Ugyanaz a fókusz a futtatókörnyezet újraindításai között idempotens marad. Egy változatlan célállapot nem hoz létre duplikált eseményeket vagy megfigyeléseket.
  • A használati számlálók, az időkeret és a jogosultságok nem másolódnak a fókuszba. Aktív cél nélkül nem töltődnek be további fókusz-tokenek.
  • A vetítés összeköti a megfelelő cél-hatókört az aktuális menet privát kapcsolati hatókörével; nem hoz létre jogokat.
9.1.359
  • A személyiség-memória és a valódi CLI-menetek mostantól ugyanazt a bérlő- és ágens-identitásfolyamot használják az identity/manifest.json fájlból; teljes identitás nélkül a kompatibilis hashelt tartalék útvonal marad elérhető.
  • A közvetlen Telegram-menetek csak az aktuális beszélgetőpartner privát kapcsolati körét vetítik. A csoportok és az idegen kapcsolatok nem szolgáltatnak privát fókusz-tokeneket.
  • A hatókör-választás a rangsorolás előtt kényszerített; egy idegen hatókörből származó újabb felismerés többé nem fedheti el a megfelelő bejegyzést.
9.1.358
  • Egy hálózati hiba az automatikus frissítés-előkészítés során eddig csak egy opcionális hibavisszahívásnak jelezték. Új poll nélkül a futó King a saját állapotán maradt, miközben a munkamenet maga egészségesen futott tovább.
  • A launcher mostantól korlátozott prepare-failed eseményt ír a verzióállapottal, valamint biztonságos hibanévvel/-kóddal a handoff.jsonl fájlba.
  • Ezt követően pontosan tíz másodperccel később a rendszer egy új előkészítési kísérletet ütemez. A futó magot nem állítja le, és nem is tölti újra.
  • A diagnosztikai esemény írásának hibái fail-soft jellegűek maradnak; tokenek, üzenetszövegek és egyéb titkok nem kerülnek a naplóba.
9.1.357
  • Az azonos effektív rendszerprompt ismételt elérése többé nem építi fel minden eléréskor újra a nagy karaktersorozatot az alapból és a futásidejű függelékből.
  • A resolver pontosan egy aktuális alap-/függelék-kombinációt tart, és azonnal érvényteleníti, amint a két bemeneti érték bármelyike megváltozik.
  • Az üres prompt, a csak-alap, a csak-függelék és a korábbi, két sortöréssel történő elválasztás bájtonként azonos marad.
9.1.356
  • A változatlan rendszerpromptokat ismételt modelllépéseken át már csak egyszer számolják karakterenként a kontextus-keretbe.
  • A gyorsítótár négy bejegyzésre, promptonként legfeljebb 500 000 karakterre és összesen 1 000 000 megtartott karakterre korlátozott.
  • A módosított promptokat továbbra is újra számolják; a kontextus-kijelzés, a tömörítési keret és a kérési keret ugyanazt az aktuális értéket használja.
9.1.355
  • A változatlan LLM-kéréskonfigurációk többé nem szerializálják újra az eszköz-sémáikat minden modelllépésnél, csak a konfigurációs naplóhoz.
  • A rendszer a modellt, az aliast, a gondolkodási szintet, a rendszerpromptot és az eszköz-sorrendet a legutóbbi teljes állapottal veti össze.
  • A módosított modellek, promptok, eszköznevek, leírások vagy paramétersémák továbbra is célzottan nyitják meg újra a konfigurációs naplózást.
9.1.354
  • A változatlan eszköz-sémákat eszközobjektumonként már csak egyszer szerializálják és számolják a kontextus-keretbe.
  • Egy 403 eszközt tartalmazó leltárt így ismételt kérésellenőrzéseknél nem kell mindig teljesen újraszámolni.
  • A név, a leírás vagy a paraméterobjektum változásai célzottan csak az érintett eszköz gyorsítótár-bejegyzését vetik el.
9.1.353
  • Az ágensraj eszközeinek argumentumtöredékeit továbbra is azonnal elemzik és átveszik a folyamatállapotba, de mostantól osztoznak az adaptív render-időzítőn.
  • Egy nagy, streamelt eszközhívás így többé nem vált ki minden argumentumtöredéknél teljes TUI-rendert.
  • A kezdés, a befejezés, a hiba és a megszakítás eltávolítja a nyitott raj-időzítőket a záró azonnali render előtt.
9.1.352
  • Az ágensraj asszisztens- és gondolkodástöredékei továbbra is azonnal frissítik a folyamatállapotot, de osztoznak egy adaptív render-időzítőn.
  • Egy töredékvihar így többé nem vált ki minden deltánál teljes TUI-rendert.
  • A diszkrét raj-események és a folyamat kitakarítása eltávolítja a nyitott időzítőket az azonnali záró render előtt.
9.1.351
  • Az asszisztens- és gondolkodástöredékek a BTW-/ágensablakban azonnal a menetben tárolódnak, de osztoznak egy adaptív render-időzítőn.
  • A vezérlő e két delta-típushoz többé nem kér további teljes rendert töredékenként.
  • A befejezés, a hiba, az újrapróbálás és a dispose eltávolítja a nyitott időzítőket; a diszkrét hook- és befejezési események azonnal láthatók maradnak.
9.1.350
  • A ToolCallComponent.appendSubToolLiveOutput azonnal átveszi a stdout- és stderr-chunkokat az aktivitásállapotba, de az alágens-kártyát már csak az adaptív streaming-ütemben építi újra.
  • Egy közös függőben lévő halmaz több egyidejűleg futó aleszközt kezel elveszett kimenet vagy chunkonkénti időzítő nélkül.
  • Az eszköz-befejezés eltávolítja a nyitott frissítését a végleges megjelenítés előtt; a dispose tisztán eldobja az időzítőket és a függőben lévő halmazt.
9.1.349
  • A ToolCallComponent.appendSubagentText azonnal összegyűjti a gyorsan érkező szöveg- és gondolkodástöredékeket a belső állapotban, de az alágens-kártyát már csak az adaptív streaming-ütemben építi újra.
  • A befejezés és a hibás állapot kiüríti a még nyitott szövegfrissítést a végleges megjelenítés előtt; a dispose tisztán eldobja az időzítőt.
  • Így a beérkező bájtok azonnal elérhetők maradnak, miközben a töredék-rohamoknál elmaradnak az ismételt teljes újraépítések, pillanatképek és renderek.
9.1.348
  • Az alágens-/aleszközök növekvő argumentumait továbbra is azonnal teljesen összegyűjtik, de többé nem elemzik és renderelik újra minden egyes töredék után.
  • Egy adaptív időzítő kötegeli az előnézet-frissítést. Befejezéskor a rendszer a függőben lévő argumentumokat kötelezően a végső eszköz-állapot előtt játssza be.
  • Az eszköz-végrehajtás, a jóváhagyások, a végargumentumok és a meglévő normál streaming-út változatlanok maradnak.
9.1.347
  • Az eseményút minden beérkező eszközargumentum-delta után azonnal meghívta a getStreamingToolCallPreview függvényt. Ez a függvény az addig teljes, növekvő JSON-szöveget elemzi.
  • A hívás a normál eszközöknél is megtörtént, pedig csak az AgentSwarm igényli az azonnal elemzett köztes állapotot a futó folyamatkijelzéséhez. Így a normál út részben megkerülte a 9.1.346 verzióban bevezetett korlátozott előnézet-kadenciát.
  • Egy kis tiszta szabályzat mostantól az elemzés előtt dönt: a normál eszközök csak a deltát gyűjtik, és a tervezett előnézet-kiürítéskor elemeznek; az AgentSwarm eseménynév, aktív eszköznév vagy meglévő raj-folyamat esetén továbbra is azonnal elemez.
  • Az eszköz-végrehajtás, a jóváhagyások, a végargumentumok és a raj-kijelzés változatlanok maradnak.
9.1.346
  • A 9.1.345 korlátozta a teljes szöveg újrarenderelését a hosszú válasz- és gondolkodásfolyamoknál, de a csak eszközargumentumokat tartalmazó folyamoknak egyik szövegtervezete sem volt, ezért rögzített 50 ms mellett maradtak.
  • Minden eszköz-előnézet az addig teljes, növekvő JSON-argumentumszöveget elemzi. A nagy eszközhívások ezért továbbra is nagyon gyakran újra elemezhették és renderelhették a teljes terhet.
  • A már bizonyított adaptív kadenciát mostantól az aktív streamelt eszközargumentumok teljes karakterszáma is befolyásolja: 50, 100, 250 vagy 500 ms ugyanazokkal a határokkal.
  • Az eszközvégrehajtás, az argumentumok, a jóváhagyások, a végelőnézet és a közvetlen befejezési kiürítések változatlanok maradnak.
9.1.345
  • A TUI streaming közben eddig minden 50 ms-nál újra beállította az addig összegyűlt teljes válasz- és gondolkodásszöveget. Hosszú modellválaszoknál így a többször renderelendő szövegmennyiség erősen megnőtt.
  • A rövid streamek 8.192 karakterig megtartják a korábbi gyors 50-ms-kadenciát. Utána az intervallum fokozatosan 100 ms-ra nő 32.768-ig, 250 ms-ra 131.072-ig, és 500 ms fölötte.
  • A kifejezett kiürítések az eszközhatárokon és a véglegesítéskor közvetlenek maradnak. A szolgáltatói, várósoros, munkamenet- és tokenlogika nem módosult.
9.1.344
  • A kognitív futásidejű réteg eddig minden eszközhívásnál a szabályzatot és az eredményt két külön szinkron SQLite-tranzakcióban írta.
  • Egy elszigetelt Windows-költségpróba 100 eszközhívással ehhez 627,63 ms-t igényelt, és 201 eseményt hozott létre. A tartalom 305 megfigyelést foglalt magában.
  • Egy modelllépés befejezett szabályzat-/eredmény-párjai mostantól legfeljebb tíz eszközt tartalmazó korlátozott csoportokban, atomikusan véglegesítődnek. A megszakított vagy még nyitott szabályzat-ellenőrzések a menet végén továbbra is egyenként mentődnek.
  • Az argumentumok, a kimenetek, a jogdöntés, a hash-lánc és az SQLite-tartósság változatlanok maradnak.
9.1.343
  • Egy privát Telegram-választ a Reply-eszköz már sikeresen kézbesített. Ezt követően ugyanaz a modellmenet mégis elindított egy további lépést, és belső státusz- és munkavezérlő szöveget hozott létre.
  • A többletlépés a mért valós munkamenetben 42.360 bemeneti és 411 kimeneti tokent emésztett fel, pedig a látható felhasználói választ már elküldték.
  • Egy sikeres Telegram-reply mostantól azonnal befejez egy direct jelölésű privát beszélgetési menetet. A sikertelen reply-k, a csoportok és a többi eszköz változatlanul futnak tovább.
  • A befejezés után továbbra is a meglévő Direct-fókusz-vezérlő lép érvénybe: megjegyzi a kézbesített választ, és a beszélgetés végén vagy nyugalmi idő után visszatér a tárolt háttérmunkához.
9.1.342
  • A Mistake.md relevancia-lekérdezése eddig minden user szerepű üzenetet felvett. Ehhez tartoztak a belső injekciók, a tömörítési összefoglalók, a skill-aktiválások és a háttérjelentések is.
  • Mivel a Mistake-emlékeztető maga belső user-üzenetként tárolódik, minden eszközlépés után megváltoztatta a saját keresési lekérdezését. Így ugyanabban a menetben újra kiválasztódott és bekerült.
  • A szűrő mostantól csak a cselekvés szempontjából releváns felhasználói és cron-bemeneteket használ. A belső futásidejű szövegek kimaradnak a relevancia-lekérdezésből és az alacsony információ-tartalmú felismerésből.
  • A valódi felhasználói üzenetek, az ütemezett munka, az összes ellenőrzött lecke és a tömörítés utáni újraépítés változatlanul elérhető marad.
9.1.341
  • A természetes indításnál a launcher talált egy már helyben előkészített és ellenőrzött automatikus futásidejű környezetet, de először mégis a hálózatfüggő frissítési értesítésen küldte át. Ha ez a második lekérés átmenetileg meghiúsult, újra a régi globális változat indult.
  • Egy előkészített automatikus futásidejű környezet pontosan illeszkedő móddal (resume vagy new) mostantól az újrakiadás-lekérés előtt indul. Az aktiválás tranzakciós marad: csak miután az új mag sikeresen betöltődött, könyveli el a rendszer a futásidejű környezetet aktívként.
  • A resume módban a munkamenet-azonosító és a munkakönyvtár megmarad. A kézi frissítésválasztás továbbra is a korábbi értesítési úton fut.
  • Egyetlen futó King sem áll le. A javítás kizárólag a következő természetes indításkor lép érvénybe.
9.1.340
  • A launcher eddig a sikeres frissítéseket a .blun/updates/install.json fájlba írta, miközben egy profil-futásidejű környezet a .blun/profile/<name>/updates/install.json fájlban keresett. A valódi profilútvonal nem létezett; ezért a notifiedAt a közös állapotban null maradt.
  • A profil-futásidejű környezetek mostantól a BLUN_SHARED_HOME értékből olvassák a frissítés sikerét, és csak közös útvonal hiányában térnek vissza a korábbi BLUN_HOME értékre.
  • A következő természetes indítás után a TUI egyszer megjelenítheti a verziót és legfeljebb három kiadási megjegyzést. A konfigurált privát Telegram-címzettek ugyanezt a rövid szöveget kapják meg modellmenet és tokenfogyasztás nélkül.
  • A telepítés, a staging, az aktiválás és a soha-ki-nem-dobás szabály változatlanok maradnak.
9.1.339
  • A sikeres eszköz-folytatólépések alacsony erőfeszítéssel legfeljebb 4.096 befejezési tokent használnak a korábbi 8.192 helyett.
  • Az első lépések, az összetett feladatok és a hiba utáni folytatólépések megtartják a konfigurált gondolkodási és kimeneti kapacitásukat. A beavatkozás nem globális modell- vagy kontextuskorlát.
  • Az 1.442 valódi, alacsony erőfeszítésű lépés visszamérése egy ágensprofilnál: 2.118.588 kimeneti token összesen, medián 791, p90 3.754, p95 5.485. Az új korláttal 229.761 token, azaz 10,8 Prozent esett volna el; a mért lépések 91,1 Prozent esetén változatlanok maradnak.
9.1.338
  • A puszta ismétlő kérdéseket, mint például a Folytathatom a munkámat?, a rendszer privát Telegram-beszélgetésekben többé nem kézbesíti.
  • A belső várósoros, handoff-, sáv- és várakozásállapot-elbeszélés kívül marad a privát válaszból. A valódi munkaeredmények és a normál személyes válaszok kézbesíthetők maradnak.
  • Ha egy használható válasz csak egy újabb, munkajóváhagyást kérő kérdéssel végződik, kizárólag ez a zárókérdés törlődik.
  • A csoportos útválasztás és a futó munkamenetek változatlanok maradnak.
9.1.337
  • A profile/<name>/SOUL.md egy King kanonikus identitásútvonala.
  • Egy megfelelő, megnevezett legacy-lélek csak egy változatlan, generált profilszerkezetet vált le. A fejlesztett profillelkek soha nem íródnak felül.
  • A legacy-import előtt a rendszer a generált szerkezetet SOUL.md.pre-legacy-import néven biztonsági másolatba menti.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • A megszakított munkamenetek normalizálják a visszajátszási állapotukat, mielőtt a rendszer további Telegram-munkát kézbesítene.
  • Ha a kézbesítést egy aktív menet elutasítja, az üzenet egy friss várósoros menetre esik vissza, ahelyett hogy ugyanazt az irányítást öt másodpercenként újra próbálná.
  • A DM-fókusz-ellenőrzőpontok frissítéseken át megőrzik az automatikus folytatási időzítőket és a kifejezett szüneteket.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Egy normál privát Telegram-üzenet csak a közvetlen beszélgetésre szakítja meg a futó feladatot. Utána a King 60 másodperc múlva, új engedélykérdés nélkül automatikusan folytatja a pontosan elmentett munkaállapotot.
  • Egy kifejezett beszélgetésvég azonnal folytatja a feladatot. Csak a világos felhasználói kérések, mint a pause, pausiere, stop, stopp, warte vagy halte an, tartják továbbra is felfüggesztve a feladatot, amíg a felhasználó újra jóvá nem hagyja.
  • A belső fogalmak és státuszjelentések a cronról, ellenőrzőpontról, várósoról vagy sávról a normál privát válaszokban nem jelennek meg. A szakmai munka és annak tárolt állapota változatlan marad.
9.1.334
  • Az automatikus háttérelőkészítés többé nem éhezik ki gyors kiadássorozatnál. A korábbi 30 perces zárolás mindig a legújabb kiadásra vonatkozott; percenkénti kiadásoknál ezért egy verzió sem lett soha elég régi ahhoz, hogy előkészítsék.
  • Egy kriptográfiailag illeszkedő kiadást a rendszer mostantól azonnal betölt, ellenőrzi az integritását, elkülönítve telepíti, szintaktikailag próbára teszi, és függőben lévő futásidejű környezetként előjegyzi.
  • A futó King-munkamenet továbbra sem áll le. Az aktiválás és a folytatás kizárólag a meglévő védett következő indítási útvonalon marad. Ez a verzió sem a handoff-, sem a munkamenet-logikát nem módosítja.
9.1.333
  • Egy élő képernyőkép a 9.1.331 után ERR_MODULE_NOT_FOUND hibát igazolt a felügyelt Telegram-pluginban.
  • A plugin-import az elkülönített felügyelt fából egy olyan magfájlra mutatott, amelyet nem telepítettek oda.
  • A szintén mért óriási ismétlő szöveg a látható gondolkodási folyamban futott. A meglévő élő ismétlésgátló addig csak a válasz-deltákat ellenőrizte.
  • A 9.1.332 a pluginnal kapcsolatos lelet után nem került be a nyilvános manifestbe. A 9.1.333 teljesen lecseréli ezt az npm-jelöltet.
9.1.332 Nem publikált
  • Nem publikált. Egy plugin-import az elkülönített fából egy nem mellékelt magfájlra mutatott; a 9.1.333 teljesen lecserélte az npm-jelöltet.
9.1.331
  • A privát Telegram-beszélgetések megtartják a természetes válaszokat és a kért munkaeredményeket.
  • A rendszer a mért belső duplikált üzeneteket a szüneteltetett munkáról, a már elküldött válaszokról, a futó menetekről, az eszközstátuszról és a hiányzó teendőről csak privát csevegésekben nyomja el.
  • Egy üzenetet a rendszer csak akkor szűr ki, ha belső futásidejű kontextust tartalmaz, és kifejezetten nem tartalmaz új felhasználói értéket.
  • A csoportos útválasztás, a valódi kész-jelentések és a normál rövid beszélgetés változatlanok maradnak.
9.1.330
  • A teljes soul-forrásfájl minden King-nél változatlanul megmarad.
  • A modellkontextus ebből korlátozott karakter-vetítést kap az identitással, hanggal, értékekkel, kapcsolatokkal, preferenciákkal, célokkal és a növekedett történettel.
  • A világos feladat-, sáv-, jog-, QA-, eszköz-, parancs-, ellenőrzési, incidens-, napló-, futásidejű, frissítési, telepítési és build-szakaszok többé nem töltődnek be személyiségként minden promptba.
  • A tiszta rövid karakter-lelkek bájtonként azonosak maradnak. Az ismeretlen, nem technikai szakaszok a sorrendjükben láthatók maradnak.
  • A rendszer egyetlen soul-fájlt sem töröl, rövidít vagy ír át automatikusan.
9.1.329
  • Minden megnevezett King-profil a közös identitásmagban a saját ágenscsomópontját használja. A kapcsolatok, az előzmények és a tanult személyes adatok többé nem esnek össze a legelőször beállított ágensre.
  • A meglévő megnevezett soul-fájlok, mint a _agent-a_soul.md, _agent-b_soul.md vagy _agent-c_soul.md, a megfelelő profilhoz rendelődnek, és egyszer, bájtonként azonosan átkerülnek a SOUL.md fájlba.
  • A régi forrásfájl változatlanul megmarad. Egy meglévő profil-SOUL.md soha nem íródik felül.
  • A személyiség-választás és a személyiségmód profilhoz kötötten olvas. Egy törött, túl nagy vagy hivatkozott profil-személyiség nem esik észrevétlenül vissza egy másik ágens identitására.
  • A közös mag Mnemo-kényszer nélkül is használható marad. A futó feladatokat, jogokat és QA-szabályokat ez a migráció nem változtatja meg.
9.1.328
  • A személyiség és a SOUL.md először az aktív profilból töltődik be.
  • A megnevezett profilok soha nem öröklik egy másik ágens lelkét a közös home-ból.
  • A legacy- és alapértelmezett profilok megtartják a korábbi közös tartalékmegoldást.
  • Ha egy saját soul-fájl valóban hiányzik, egyszer létrejön egy minimális szerkezet; a meglévő fájlok soha nem íródnak felül.
  • Az identitás- és kapcsolatrendszer fájlalapú marad, és Mnemo-kényszer nélkül működik.
9.1.327
  • A privát Telegram-beszélgetések a személynél maradnak: a belső várósoros, ellenőrzőpont-, szünet-, cron-, hook- és üresjárati jelentések mindkét küldési úton visszatartja őket a rendszer, amíg nem kérnek munkaállapotot, nem szükséges döntés, és nem keletkezett releváns blokkoló.
  • A technikai munkaállapotok az illetékes csapatcsatornára mennek. Nem másolódnak át még egyszer a privát beszélgetésbe.
  • A pontos modellismétlési hurkokat a rendszer már a stream közben felismeri. A futó szolgáltatói streamet leállítja, és ugyanazt a lépést a megőrzött feladatkontextussal pontosan egyszer újrapróbálja.
  • A lélek, a személyes tudás, a jogok, a futó feladatok és a meglévő direktfókusz-szünet nem cserélődtek le és nem törlődtek. Egyetlen futó TUI sem indult újra.
9.1.326
  • A manuális és automatikus engedélymódok az eszköz-jóváhagyásokat korlátozott gombokként tükrözik az egyértelműen összekapcsolt privát Telegram-DM-be.
  • Csak az eszköznév és a meglévő kiválasztási szövegek jutnak tovább; az argumentumok, a leírások és a titkok helyben maradnak. A lejárt, idegen vagy már helyben megválaszolt jóváhagyási kérelmeket a rendszer fail-closed módon elveti.
  • A God mód teljesen autonóm marad, és nem hoz létre Telegram-jóváhagyást.
  • A technikai munkaállapotok az illetékes kollégához kerülnek, és többé nem másolódnak vissza a felhasználó privát beszélgetésébe.
9.1.325
  • A God mód személyes memória-írási műveleteket hajt végre második jóváhagyási kérdés nélkül; a meglévő, munkamenethez és menethez kötött hozzájárulás megmarad.
  • Egy kifejezett Telegram-megjegyzési utasítás ugyanazt a szorosan korlátozott hozzájárulást aktiválja, mint egy közvetlen konzolutasítás. A manuális és automatikus engedélymódok továbbra is írás előtt kérdeznek.
  • Az update-napló tárolja, hogy egy telepítés manuálisan, automatikusan vagy az indítási párbeszédablakon keresztül lett-e elindítva.
9.1.324
  • Az első megbízható interakció egy bottal helyben ágens- és kapcsolatcsomópontként hozza létre. A szerep, a feladatkörök, a sajátosságok, az együttműködés és a handoff ezután strukturáltan növekedhet.
  • Minden King egy kompakt kolléga-kivonatot vetít a kontextusába. Így ismeri a többi ágens feladatait és sajátosságait, anélkül hogy átfogóan betöltené a teljes kapcsolatállományt.
  • Ha egy feladatkritikus információ hiányzik, nem találgat: a King pontosan egyszer kérdezi meg a leginkább illő embert vagy ágenst. Ha nem ismert a felelősség, a felhasználót kérdezi, ahelyett hogy nevet találna ki.
  • A kapcsolatok és szerepek soha nem hoznak létre jogokat. Az engedély-, ACL- és titokmezők nem kerülnek a kolléga-kivonatba vetítésre. Az út helyi, bérlőhöz kötött, névsemleges, Mnemo-független, és nem ad hozzá sem modell-, sem eszközhívásokat.
9.1.323
  • A privát beszélgetések ismét a személynek válaszolnak, ahelyett hogy önként belső folyamatadatokat adnának ki. Az ellenőrzőpontok, hash-ek, elérési utak, eszköz-, cron- és hook-diagnosztikák, rejtett szabályok, idegen ágensek feladatai és üresjárati jelentések belsőek maradnak.
  • A munkaállapotról csak akkor esik szó, ha a felhasználó kérdez rá, szükség van a döntésére, vagy egy blokkoló konkrétan őt érinti. A szüneteltetett munka belső marad, és nem kerül laza beszélgetésbe.
  • A szabály személyiségmóddal és anélkül is érvényes, nem tartalmaz rögzített személyeket vagy ágenseket, és körülbelül 75 prompt-tokent ad hozzá, de sem modell-, sem eszközhívást nem. A feladat-prioritás és a bizonylati kötelezettség változatlan marad.
9.1.322
  • A látható személyiségkapcsoló mostantól atomikusan írja a persona.json fájlt. A név, a nyelv, a jegyzetek és az összes többi meglévő személyiségmező megmarad; csak a personalityEnabled érték módosul.
  • A SOUL.md, AGENTS.md, JOURNAL.md és a kapcsolati fájlok sem kikapcsoláskor, sem bekapcsoláskor nem íródnak. A normál SOUL-alapú ágensidentitás a kikapcsolt személyiségfunkció mellett is betöltve marad a rendszerkontextusban.
  • Egy meghiúsult élő frissítés bájtonként pontosan visszaállítja a kiválasztást. Ha közben egy másik író megváltoztatta a persona.json fájlt, a visszaesés PERSONALITY_CHOICE_CONFLICT hibával megszakad, és semmit nem ír felül.
  • A rendszer fail-closed módon elutasítja a szimbolikus hivatkozásokat, valamint a túl nagy, érvénytelen vagy nem objektum alakú személyiségfájlokat. Bekapcsoláskor az identitásfa a commit előtt elkészül.
  • Nem része ennek a verziónak az utóbb bizonyított hibája, hogy egy ágens belső ellenőrzőpontokat, cron-szabályokat, SHA-értékeket és idegen feladatrészleteket ad ki privát beszélgetésekbe. Ez a kimeneti szűrő a következő külön építés.
9.1.321
  • Egy laza első privát váltás vagy egy önkéntes személyes megjegyzés pontosan egy opcionális kíváncsiság-lehetőséget helyezhet a modellkontextusba. Nem kötelező kérdés; a szóválasztás és a hang továbbra is a betöltött SOUL.md fájlból származik, nem egy rögzített kérdéskatalógusból.
  • A feladat, a sürgősség, a hibák, a hivatkozások, a kód, az elérési utak és a csoportforgalom zártan elnyomják a kíváncsiságot. Soha nem küld önállóan, és nem szakíthatja meg a futó munkát.
  • Egy 30 napos lehűlési idő bérlőnként, ágensenként és összekapcsolt személyenként érvényes, különböző portálokon át is. Ugyanaz az esemény-újrapróbálás idempotens.
  • Az új állapot többé nem Telegram-specifikus kíváncsiságfájlként fekszik az identitásfában. Egy cserélhető personality-memory-adapter ehelyett verziózott eseményt ír a meglévő tranzakciós kognitív tárolóba. A Telegram származás; a privát kapcsolat külön láthatósági hatókör.
  • Csak a téma, a stabil esemény-/forrásazonosító, az időpont és a privát hatókör tárolódik. A nyers szöveg, a rögzített kérdések, a jogállítások és a titkok nem kerülnek be. A bizonytalan gyökerek, az idegen mezők és a tároló kiesése fail-closed jellegűek maradnak.
  • A portálhatár alapja a belső koncepciódokumentum v7 volt. A CLI a referencia-kliens; a helyi tároló kifejezetten cserélhető vetítésként van megjelölve, és nem második kanonikus portáltároló.
9.1.320
  • A privát, kifejezett nyitott beszélgetési szálak megváltoztathatatlan, deduplikált eseményekként tárolódnak forrással, időponttal, kontextussal és bizalommal. A természetes megfogalmazásokat, mint a Frag mich morgen noch einmal nach ..., ugyanúgy felismeri, mint a kifejezett nyitott szál formát.
  • A kifejezett javítási útmutatások az általános kapcsolati jegyzetektől külön tárolódnak, és a rendszer a későbbi viselkedésben figyelembe veszi őket.
  • Az aktuális menet szándékosan még nem látja a saját új jegyzetét. Csak egy későbbi privát menet kapja meg a korlátozott kontextust; így nincs kettős vagy sugalló önmegerősítés.
  • A feladat és a kifejezett utasítások a szociális kontextus előtt állnak. A nyitott szálak nem szakíthatják meg az aktív munkát, és soha nem küldenek önállóan. A kapcsolati adatok nem hozhatnak létre jogokat, jóváhagyásokat vagy engedélyeket.
  • A csoportforgalom, a titkok, az engedély-megfogalmazások, a bizonytalan elérési utak, a szimbolikus hivatkozások és a túl nagy fájlok fail-closed módon kizárva maradnak.
9.1.319
  • Egy érvényes meglévő profil tárolt personalityEnabled érték nélkül mostantól automatikusan aktiválja a személyiséget.
  • Az első normál promptnál létrejön a helyi identitásfa az ágensprofillal és a JOURNAL.md fájllal együtt, Mnemo nélkül is.
  • Egy kifejezett false, 0 vagy off érték kikapcsolva marad. A sérült, szimbolikusan hivatkozott és túl nagy személyiségfájlok fail-closed jellegűek maradnak.
  • A SOUL.md és az AGENTS.md fájlokat a rendszer nem törli, és nem is írja át.
9.1.318
  • A háttér-frissítő kötelezően letölti a legújabb változatot, ellenőrzi a függetlenül közzétett SHA-512 integritását, és a következő indításhoz előjegyzi.
  • A futó King, a menete és az eszközhívásai érintetlenek maradnak. Nincs élő handoff, nincs ACK és nincs többé tui.stop(76).
  • A munkamenet-azonosító és a munkakönyvtár az előkészített futásidejű környezettel együtt tárolódik. Csak a következő természetes indításkor aktiválódik az új verzió, és a pontos munkamenet automatikusan folytatódik.
  • A futó TUI legfeljebb egy passzív kész-jelzést kap; egy újabb előkészített változat csak az előjegyzést váltja le, soha nem az aktív folyamatot.
9.1.317
  • Ha a szolgáltató a teljes válaszkeretet egy length befejezéssel elhasználja, de látható szöveget nem ad, az újrapróbálási keret többé nem nyolcadára csökken, hanem megduplázódik.
  • Az újrapróbálás ugyanabban a menetben marad, és ugyanazt a jelet, ugyanazt az üzenet-előzményt és ugyanazt a munkahelyzetet használja.
  • A meglévő megszakítás-kezelés és a korlátozott újrapróbálási szám változatlan marad. A kézi megszakítások vagy a tartósan üres eredmények nem futnak végtelenül.
9.1.316
  • A privát Telegram-üzenetek saját közvetlen várósoros sávot kapnak a csoport-, hurok- és háttérmunka előtt; egy kifejezett /urgent továbbra is a legmagasabb prioritású marad.
  • A DM-beszélgetés kezdetekor a futó munkaállapot egyszer, korlátozott ellenőrzőpontként mentődik. Az üzenetszöveget közben nem menti tartósan a rendszer.
  • Egy felismert beszélgetésvég vagy egy perc csend után a King pontosan egyszer kérdezi: Folytathatom a munkámat?
  • A tárolt munka felfüggesztve marad, és csak egyértelmű jóváhagyás után folytatódik az eredeti ellenőrzőpontnál.
  • Ez a verzió a kézbesítési és szünet-vezérlést szállítja. A teljes személyiség-, kapcsolat- és naplórendszer külön, tovább futó kiépítés marad.
9.1.315
  • A felhatalmazott figyelemjelek mostantól a normál csatorna-várósoron keresztül jutnak a menetbe, anélkül hogy megkerülnék a meglévő kézbesítési vagy jogosultsági szabályzatot.
  • A rendszer a duplikált, elavult, jóvá nem hagyott, a hatókörön kívül eső és nem Telegram-ból származó jeleket már a modellkontextus előtt elveti.
  • A visszakérdezések legfeljebb egy természetes utánakérdezésre korlátozódnak, deduplikálódnak, és elhallgatnak, ha a jel már nem aktuális.
  • Ez a verzió csak a biztonságos kézbesítési utat szállítja. Az utána priorizált DM-megszakítási és -folytatási logika tudatosan a következő, külön verzióra marad.
9.1.314
  • A helyi perjeles parancsok hosszú aktív menetnél többé nem várnak órákig a várósorban, hanem szabályozottan megszakítják a menetet, és a következő munkalépésként futnak.
  • Egy új perjeles parancs a konzolban és a Telegram-on is lecserél egy már várakozó, azonos típusú parancsot. Ez többek között a /reload és a /loop parancsra érvényes; a normál üzenetek, a shell-munka és a többi csatornafeladat megmarad.
  • Az Escape akkor is eltávolítja a várakozó perjeles parancsokat, ha már nincs látható aktív menet. A meglévő reload-kompatibilitás az általános várósor-szabályzatra épülő wrapperként megmarad.
9.1.313
  • Egy sikeres automatikus frissítés a munkamenet-visszajátszás után tartós megjegyzésként kerül a TUI-átiratba. Az üzenetet így többé nem írhatja felül sem a visszajátszás, sem egy rövid életű státusz.
  • A rendszer ugyanazt a forrásállapotot, célállapotot és ugyanazokat a verziómegjegyzéseket a meglévő, verzióalapúan deduplikált úton egyszer küldi el a párosított Telegram-DM-ekbe. A sikertelen küldés ismételhető marad.
  • A nyilvános manifest mostantól tartalmazza a tartalék elemző által várt name és releaseNotes mezőket. Az updater-handoffon, a munkamenet-újraindításon és a futó folyamatokon semmi nem változott.
9.1.312
  • Egy kifejezett Telegram-/reload parancs többé nem vár egy hosszú modellmenet mögött. Vezérlőparancsként a meglévő várósor elé kerül, és pontosan egyszer indítja el a meglévő szabályozott munkamenet-megszakítást.
  • A meglévő reload-kezelő csak a megerősített menetvég után fut. Így nem indul párhuzamosan második menet, és egy író menetet nem dolgoznak fel tovább a reload-logika közepén.
  • A rendszer eltávolítja a régi reload-duplikátumokat; a normál Telegram-üzenetek és a többi várósoros munka megőrzi a sorrendjét. A Telegram-visszaigazolás a tényleges parancsvégrehajtásig nyitva marad.
9.1.311
  • Egy figyelemjelölt csak akkor válik korlátozott kézbesítési feladattá, ha friss, pontosan a jelölt-azonosítójához kötött futásidejű visszaigazolás áll rendelkezésre.
  • Csak a runtime_user_prompt_hook és a runtime_tool_policy számít mérvadó forrásnak. A memória, a nem megfelelő ágens, a nem megfelelő csatorna, a nem megfelelő hatókör, a blokk-döntés, a jövőbeli visszaigazolás és az öt percnél régebbi visszaigazolás fail-closed módon elbukik.
  • A visszaigazolások bérlőhöz kötöttek, tranzakciósak, és csak egyszer használhatók. Ugyanaz az újrapróbálás idempotens; ugyanannak a visszaigazolásnak egy másik jelöltnél történő használatát a rendszer visszajátszásként (replay) elutasítja.
  • A meglévő közös lehűlési idő érvényben marad. Az eredmény csak strukturált attention_notice szándék, és nem tartalmaz sem üzenetszöveget, sem küldési funkciót, sem engedélyt. A tényleges kézbesítési politika a következő külön lépés marad.
9.1.310
  • A tartós célok, nyitott szálak, következő kiváltók, várt bizonylatok, csapatkontextus és önkontextus egy közös, szigorúan korlátozott fókuszvetítésen futnak át. Az alapértelmezés legfeljebb hat bejegyzés és 900 karakter.
  • A súlyozásban a projekt- és munkaterületek megelőzik a konfidenciát és az aktualitást. A rendszer a legújabb értéket mutatja, anélkül hogy a korábbi ellentmondó megfigyeléseket törölné a megváltoztathatatlan esemény-előzményből. A változások revised értékként láthatók.
  • A rövid életű futásidejű megfigyelések, a gyenge bizonyítékok és az általános világtények nem fogyasztanak tartós fókuszkeretet. A jog-, token- és titokmezőket a rendszer már íráskor elutasítja.
  • Egy strukturált, idempotens pillanatkép a fókuszt munkameneteken át továbbvezetheti. A vetítés kontextus, nem engedély, és sem feladatot, sem futásidejű politikát nem írhat felül.
  • Az ECC-ből csak a Kontext begrenzen, Relevantes laden elvet vették át. Nem telepítettek sem ECC-hookot, sem tanulási tárolót, sem harness-t.
9.1.309
  • Az új tiszta figyelempolitika csak bizonyítottan hiányzó ágens-heartbeatből, elkésett ígéretekből vagy hosszabb ideje blokkolt feladatokból hoz létre korlátozott jelöltet.
  • A rendszer a felvétel előtt ellenőrzi a felelősséget, az aktív feladatot, a bizonyított távollétet, a helyi nyugalmi időt, a megengedett csatornát, a minimális konfidenciát és a lehűlési időt. Az emberi csend esedékes ígéret nélkül hatástalan marad.
  • Minden jelölt bizonyíték-azonosítót, érvényességi kört, időpontot és konfidenciát visel, de sem prompttartalmat, sem jogokat, sem titkokat, sem küldési funkciót nem tartalmaz.
  • A közös SQLite-mag bérlőnként és bizonyítékonként tranzakciós igényt ad ki. A párhuzamos ágensek ugyanazt az alkalmat a lehűlési időn belül nem vehetik át kétszer.
  • Ez a verzió még nem szkennel önállóan, és nem küld üzenetet. Minden későbbi művelethez továbbra is a normál futásidejű engedélyezés szükséges.
9.1.308
  • Az előkészített futásidejű rekord a resume módban mostantól a pontosan futó munkamenet-azonosítót és a kanonikusan ellenőrzött munkakönyvtárat tartalmazza. Egy későbbi indításnak így többé nem kell kitalálnia a legfrissebb vagy vélhetően megfelelő munkamenetet.
  • Minden valódi munkamenet-váltás frissíti ezeket az adatokat. Közvetlenül a biztonságos handoff előtt újra megíródnak, mielőtt a régi futásidejű környezet megkapná a befejezési megerősítést.
  • Csak az a bizonyíthatóan ezen a frissítési úton folytatott, pontosan azonos munkamenet kap a visszajátszás után egyszeri folytatási impulzust, és csak akkor, ha a célja továbbra is active. A normál indítások, a többi munkamenet, valamint a szüneteltetett vagy blokkolt célok érintetlenek maradnak.
  • A biztonságos munkahatár változatlan marad: nincs handoff streaming, tömörítés, eszközök, shell-parancsok vagy várakozó üzenetek közben. Ehhez a szállítmányhoz egyetlen futó King-et sem indítottak újra kézzel.
9.1.307
  • Csak a közvetlenül előző futásidejű menet ténylegesen cselekvés szempontjából releváns hibája jelenik meg rövid folytonossági bizonylatként a következő modelldöntés előtt: megszakított/meghiúsult menet, blokkolt politika vagy meghiúsult eszköz.
  • Egy normálisan befejezett menet pontosan semmilyen vetítést nem hoz létre, így nulla többlet kontextus-tokent eredményez.
  • A kiválasztás futásidejű-azonosítóhoz és menet-azonosítóhoz kötött, így munkamenet-váltás után is helyes marad, amikor a menet-azonosítók újra nulláról indulnak.
  • A vetítés nem tartalmaz promptokat, argumentumokat, kimeneteket, hívás-azonosítókat vagy jogokat. Kifejezetten rámutat, hogy soha nem engedélyezhet műveletet, és nem írhatja felül az aktuális felhasználói-/eszközpolitikát.
  • A szakasz tudatosan reaktív és szűk. A proaktív figyelem, a delegációs állapot és a tartalmi nyitott szálak itt még nem töltődnek be.
9.1.306
  • A kognitív menet-életciklus-nyom mostantól minden valódi eszközhívásnál rögzíti a tényleges futásidejű döntést a PermissionManager.beforeToolCall hívásból: passed, blocked vagy error.
  • A futás után a valós eredmény (success, error, cancelled), a futásidő és a következő ellenőrzési kiváltó megváltoztathatatlan bizonylatként hozzáfűződik.
  • Csak az eszköznév és a hívókulcs stabil hash-e tárolódik. Az argumentumok, az eszközkimenetek és a prompttartalmak nem jutnak a kognitív állapotba.
  • A meglévő joghierarchia változatlan marad: a memória nem hagyhat jóvá műveletet. A rögzítési hibák fail-soft jellegűek maradnak, és sem eszközfutást nem engedélyezhetnek, sem felhasználói menetet nem blokkolhatnak.
  • Még nyitottak a delegációs bizonylatok, a proaktív figyelem és az állapot szigorúan releváns visszavetítése a későbbi döntésekbe.
9.1.305
  • A 9.1.304-ben szállított tranzakciós SQLite-mag mostantól a valódi runOneTurn() életciklushoz van kötve. Minden modellmenet rögzíti az észlelést, a származás-osztályozást, a korlátozott menettervet, a várt végbizonylatot, a promptkapu-eredményt, a befejezési okot, a futásidőt és a következő kiváltót.
  • Csak futásidejű metaadatok tárolódnak, prompttartalmak nem. A rendszer a bérlőt és az ágenst stabilan a BLUN-home-ból és az aktív profilból vezeti le, rögzített személylisták nélkül.
  • Csak a meglévő futásidejű politika szolgáltathat kapueredményt. A memória mint jogosultsági forrás szigorúan ki van zárva. A rögzítés soha nem ad vissza engedélyt, és továbbra sem rendelkezik végrehajtási funkcióval.
  • A tanulási nyom fail-soft jellegű: egy SQLite-/életciklus-hiba csak tartalommentes telemetriaként rögzül, és nem blokkolhatja a tényleges felhasználói menetet.
  • Még nyitottak az eszközspecifikus műveleti-/delegációs bizonylatok, a proaktív figyelem és az állapot releváns visszavetítése a későbbi döntésekbe. A 9.1.305 ezért nem állít teljes AGI-hurkot.
9.1.304
  • Az első tranzakciós kognitív állapotmag helyi SQLite-adatbázisként a BLUN-home alatt található. Ön-, világ- és csapatmegfigyeléseket, célokat, nyitott szálakat, feltételezéseket, következő kiváltókat és várt bizonylatokat tárolhat munkameneteken át.
  • A rendszer a több ágens-/csatornaírót a BEGIN IMMEDIATE paranccsal és optimista verziószámmal szerializálja. Az elavult írók fail-closed módon elbuknak; az azonos eseményismétlések idempotensek.
  • Minden esemény SHA-256-láncolt. A kijelentések forrást, kontextust, időpontot, bizonyosságot és érvényességi kört viselnek. Az ellentmondások külön, megváltoztathatatlan megfigyelésekként maradnak, ahelyett hogy felülírnák a régi kijelentéseket.
  • A rendszer elutasítja a jog-, képesség- és titokjellegű mezőket. A mag nem rendelkezik végrehajtási, delegációs vagy engedélyezési funkcióval.
  • Ez a bizonyított tárolási alap, még nem a teljes észlelés-tervezés-cselekvés hurok, és még nincs minden menetbe bekötve.
9.1.303
  • Egy a 9.1.302-ben biztonságosan rögzített privát kapcsolati jelölt a következő közvetlen beszélgetéstől kezdve egyértelműen nem mérvadó emlékkontextusként töltődik be. Az aktuális kijelentés továbbra sem befolyásolja a saját menetét.
  • Legfeljebb a két legújabb validált jegyzet töltődik be, egyenként legfeljebb 160 karakterrel, a változatlan 1.500 karakteres összkereten belül. Meglévő jegyzetek nélkül 0 többlet prompt-karakter keletkezik, és nem történik sem modell-, sem beágyazási, sem hálózati hívás.
  • A privát jegyzetek csoportokban soha nem töltődnek be. A rendszerhatár kifejezetten referenciaadatnak nevezi őket utasítások helyett, és megismétli, hogy nem adhatnak jogokat, és nem is módosíthatják azokat.
  • Még nyitottak az automatikus tartós átvétel, a konfliktusértékelés, a tranzakciós többágenses tároló és a proaktív figyelem.
9.1.302
  • Egy kifejezett privát kijelentés, mint a Bitte merk dir: ... vagy a Please remember that ..., mostantól egy kis, még nem aktív kapcsolati jelöltet hoz létre. Ehhez nincs további modell-, beágyazási vagy hálózati hívás.
  • Minden jelölt forrást, csatorna-/közvetlen kontextust, időpontot, bizonyosságot, érvényességi kört és a megváltoztathatatlan előzményszabályt visel. Ugyanaz a kézbesített csatornaművelet idempotens; a későbbi megerősítések és ellentmondások külön bejegyzésként láthatók maradnak, és nem írják felül egymást.
  • A csoportok, a normál beszélgetési mondatok, a titkok, a jog- és jóváhagyási kijelentések, az érvénytelen bérlő-/ágensazonosságok és a nem biztonságos elérési utak elutasításra kerülnek. A kapcsolati adatok továbbra sem hozhatnak létre semmilyen jogot.
  • Ez csak az első biztonságos rögzítési lépés a termékcélhoz. A jelöltek pending állapotban maradnak, és még nem kerülnek automatikusan át az aktív kapcsolatba vagy a modellkontextusba. A tranzakciós többágenses mag, a kognitív állapot, a kezdeményezőkészség és a proaktív figyelem ezzel kifejezetten még nincs kész.
9.1.301
  • Az állandóan betöltött személyiség-jelenlétblokk 1.433-ról 1.020 karakterre csökkent, számítás szerint nagyjából 104 prompt-tokennel kevesebb aktív személyiségmenetenként. Nem került hozzá további modell- vagy tárolóhívás.
  • A feladatfókusz, a betöltött lélek, a korlátozott kíváncsiság, a csoportvédelem, a bizonytalan emlék, a nyitott szálak és a kapcsolatjavítás a kis blokkban maradnak. A személyiség nélküli mód 288 karakternél bájtonként azonos maradt.
  • Piros próba: az új 1 050 karakteres kapu 1 433 karakternél elbukott. Mutációs próba személyiségblokk nélkül: 12/18 célzott teszt piros. Helyreállítva: fókuszáltan 18/18, a teljes tesztcsomag 690/690 zöld.
  • Csomag-regressziós kapu 9.1.300-ról 9.1.301-re: 164 kontra 164 stabil útvonal, 0 eltávolítva. Friss telepítés: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Egy indításkor meghiúsult MCP-szerver mostantól legfeljebb három további kapcsolódási kísérletet kap, tízmásodperces időközökkel. Így egy átmeneti indítási hibánál a rendszer már nem adja fel egyetlen kísérlet után.
  • A rendszer az MCP-leltárt többé nem csak egyszer naplózza, hanem újra is, amikor a csatlakoztatott szerverek vagy eszközök száma változik. Egy késői helyreállás így láthatóan felváltja a régi 0/0 állapotot.
  • A meglévő MCP-konfigurációk, eszközdefiníciók és futó munkamenetek változatlanok maradnak. A blun.mjs, a test/mcp-runtime-resilience.test.js, a package.json és a package-lock.json módosult.
9.1.299
  • A nagy Read-eredmények natívan újraolvashatók maradnak: a látható kimenet 10 KiB-ra korlátozott, és utána a pontos következő sort nevezi meg, ahelyett hogy csak [offloaded] értéket mutatna.
  • A nagy, sima Write-feladatok és az 500 sornál hosszabb forrásfájlok automatikusan bájtpontos töredékekre bomlanak, egy privát szomszédos fájlban állnak össze, és atomikusan a célútvonalra íródnak.
  • Az összeállítás után a futásidejű környezet SHA256-tal ellenőrzi a perzisztált bájtokat. A meglévő Edit-védelem változatlan marad; a kézi folytatás továbbra is lehetséges, de nagy teljes írási műveletekhez már nem szükséges.
  • Új: bin/native-large-file-io.cjs. Módosítva: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, négy fókuszált tesztfájl, valamint a package.json és a package-lock.json.
9.1.298
  • Az aktivált személyiségmód az első normál TUI-menetnél önállóan hoz létre helyi, bérlőképes identitásterületet. Ehhez Mnemo nem szükséges.
  • A meglévő SOUL.md és AGENTS.md betöltve és változatlan marad. Egy új JOURNAL.md csak egyszer jön létre, és sem a lelket, sem a szabályokat nem váltja fel.
  • Az új Telegram-identitások óvatos személy-, kapcsolat- és csoportcsomópontokat kapnak kitalált tulajdonságok nélkül. A privát előzmények és a csoportkontextus elkülönülve maradnak.
  • A közvetlen kapcsolatfolytonosság legfeljebb hat rövid, helyben szerkesztett bejegyzést tárol, és legfeljebb két korábbi részletet ad az aktuális menetnek. Az aktuális szöveget a rendszer nem injektálja kétszer.
  • A szociális figyelemréteg kizárólag egy bizonyított közvetlen visszatérési távolságot ismer fel hét naptól kezdve, legfeljebb egy jelzést hoz létre a 30 napos lehűlési időben, és maga soha nem küld üzenetet.
  • Az aktuális feladat és a kifejezett utasítások a kontextusban mindig a kíváncsiság, a kapcsolat és a figyelem előtt állnak. A teljes dinamikus identitásblokk alapértelmezésben 1 500 karakterre korlátozott marad.
  • A 9.1.296-ban és 9.1.297-ben közzétett MCP-újrapróbálási és reload-várósor-javítások benne vannak a jelöltben.
9.1.297
  • Két ágensnél egy régi /reload-feladat az Escape után láthatóan a várósorban maradt. Egy második /reload le tudott futni, de az első bejegyzést a rendszer sem el nem távolította, sem nem nyugtázta az ismételt Telegram-kézbesítés ellen.
  • Az új politika kizárólag a helyi és a Telegram-reload parancsokat távolítja el. Megtartja a meglévő várósor azonosságát és sorrendjét, valamint az összes többi üzenetet és parancsot.
  • Az Escape az aktív munka megszakítása előtt és minden újonnan érkező /reload ugyanazt a kitakarítási útvonalat hívja. Az eltávolított Telegram-bejegyzések a meglévő visszaigazolási visszahívásukon keresztül nyugtázódnak.
9.1.296
  • Egy valódi folytatási futás a 9.1.294 alatt augusztus 27-én 14:26:17Z pontosan egy néma indítási hibát jelentett a windows-mcp számára: Timed out after 30000ms. A következő percekben sem második indítási kísérlet, sem záró újrapróbálási eredmény nem jelent meg.
  • Az uvx windows-mcp serve közvetlen indítása ellenben nagyjából 3,7 másodperc után válaszolt az initialize hívásra. A telepítés és a szerver így alapvetően működőképes volt; a hiányosság a King-MCP-indítás ismétlésében volt.
  • A blun.mjs az első MCP-indítási hiba után mostantól pontosan egy újrapróbálási kísérletet tart fenn 10 000 ms után. Az időzítő hivatkozva marad, amíg a második kísérlet végre nem hajtódik. Nincs folyamat- vagy munkamenet-újraindítás.
  • Ha a második kísérlet is meghiúsul, a meglévő őszinte végállapot, az unavailable megmarad. A többi MCP-szerver és a TUI tovább fut.
9.1.295
  • A háttérfeladatok futásidejű környezete minden futtatáshoz regisztrált egy figyelőt egy külső AbortSignal-ra, de normál worker-, időtúllépés- vagy stop-eredmény után nem távolította el. A hosszú ágensmunkamenetek így elavult megszakítás-figyelőket halmozhattak fel.
  • A bin/abort-listener-policy.cjs a megszakítási kimenetet mostantól egy idempotens cleanup() függvénnyel együtt szolgáltatja. A blun.mjs a meglévő finally útvonalon az időtúllépés-takarítással együtt hívja meg.
  • A megszakítási viselkedés, az eredményválasztás és a látható feladat-szemantika változatlan marad. A beavatkozás sem modellhívást, sem új kontextus-tokent nem hoz létre.
9.1.294
  • Két ágensprofil valós frissítési kísérlete ugyanazt a lefolyást igazolta: az első hívás átmeneti fetch failed hibával végződött, a közvetlenül követő második hívás működött. Mindkét hivatalos forrásnak eddig csak egyetlen hálózati kísérlete volt.
  • A registry és a nyilvános manifest mostantól külön, korlátozott újrapróbálási keretet kap 250 és 750 ezredmásodperces backoff-fal.
  • Csak az időtúllépések, az ismert átmeneti szállítási hibák, valamint a HTTP 408, 425, 429 és az 500-tól induló szerverhibák ismétlődnek meg.
  • Az érvénytelen JSON, a túl nagy válaszok, a nem engedélyezett végpontok és a tartós klienshibák, mint a 404, azonnal pirosak maradnak. Nem keletkeznek modellhívások, kontextus-tokenek vagy tartós háttérhurkok.
9.1.293
  • A háttér-frissítő egy ellenőrzött célt helyesen előkészített, de ezt követően továbbra is RUNNING_UPDATE_PREPARED_MESSAGE üzenetet küldött a mag aktív futásidejű környezetének. Egy futó TUI egy vélhetően biztonságos határon 76-os kilépéssel reagálhatott. Ez ellentmondott a 9.1.222 termékszerződésének: a frissítések soha nem fejezhetik be az aktív munkamenetet, és csak a következő természetes indításkor aktiválódnak.
  • A bin/launcher-runtime.js változatlanul folytatja a letöltést, az integritás-ellenőrzést, a staginget, a célfrissítést és a takarítást, de az előkészítéskor már nem ír IPC-üzenetet a futó munkamenetbe.
  • A meglévő közvetlen handoff-funkciók kompatibilitás céljából megmaradnak; az automatikus háttérút többé nem indítja el őket.
9.1.292
  • Egy valós munkamenet a 9.1.279-en futott, és a 9.1.287-et a prepared-for-next-start eseménnyel előkészítette, de utána a már közzétett 9.1.288 és 9.1.291 közötti verziók egyikét sem húzta le.
  • Az ok a superviseProtectedCore() függvényben volt: az első sikeres staging után az updateStarted beállítva maradt, és a scheduleNextPreparation() ráadásul megszakadt, amint a preparedTarget létezett. A háttér-pollert így az első találat után véglegesen leállították.
  • A poller mostantól előkészített céllal is aktív marad. Csak egy szigorúan újabb, érvényes semver váltja le az előkészített célt; az azonos, régebbi vagy érvénytelenül összehasonlítható célokat figyelmen kívül hagyja.
  • Egy cél-frissítés szándékosan nem küld második prepared-IPC-t a futó TUI-nak. Így az aktuális folyamat érintetlen marad, és a legújabb előkészített változat csak a következő természetes indításkor válik aktívvá.
  • Amint egy handoff meg van erősítve, vagy a felügyelt mag futásidejű környezete véget ér, többé nem cserélődik cél, és nem jön létre új időzítő.
9.1.291
  • A blokkoló tömörítési út minden még meg nem szakított jelre anonim abort-figyelőt regisztrált, de a tömörítés befejezése után nem távolította el. Hosszú munkamenetekben így halott megszakítás-figyelők halmozódhattak fel.
  • A FullCompaction.block() mostantól megnevezett figyelőt és a kis waitForAbortableCompletion() segédfüggvényt használ. A segédfüggvény a finally részben siker, hiba vagy megszakítás után eltávolítja a figyelőt.
  • A rendszer egy már megszakított jelet azonnal kezel, figyelő regisztrálása nélkül. A beavatkozás sem a megszakítási döntést, sem a tömörítési logikát nem változtatja meg ezen az életcikluson kívül.
  • A minta az AnythingLLM-mel való aktuális összehasonlításból származik; csak az egyenként bizonyított figyelő-takarítást vették át, idegen futásidejű környezetet nem.
9.1.290
  • A BLUN eddig a /context paranccsal csak a kontextusablak durva összegeit mutatta. A tényleges költségnövelő tényezők a rendszerkontextuson és az eszközsémákon belül láthatatlanok maradtak.
  • Az új helyi /context-doctor parancs modellhívás nélkül bontja szét az aktuális kontextust magutasításokra, személyiségre és lélekre, kapcsolatokra és jelenlétre, képességjegyzékre, futásidejű kiegészítésekre, beépített eszközökre, felhasználói eszközökre, MCP-eszközökre, további eszközsémákra, beszélgetésre és szolgáltatói járulékos költségre.
  • A rendszer minden alkategóriát összevet a mért szülőösszegével. Az átfedő vagy elavult becslések így nem növelhetik mesterségesen a kijelzést.
  • A felület teljesen lokalizált angolra, németre, spanyolra, franciára, svédre és csehre. Mind az öt fordítást a beépítés előtt a kötelező nyelvi kapun keresztül hagyták jóvá, majd kriptográfiailag visszaellenőrizték.
  • A parancs kizárólag a helyi munkamenet-kontextust olvassa. Sem a modellt, sem a fogyasztáskezelést, sem külső hálózatot nem hív.
9.1.289
  • Az élő hub-bizonylat a 9.1.288 után egy ágensprofilt továbbra is offline mutatott. A tényleges profilkonfigurációja tartalmazta a Mnemo-MCP-t a MNEMO_AGENT=<Profilname> értékkel, de a King-folyamatban nem volt hub-URL. A 9.1.288-heartbeat ezért a meglévő belső identitás ellenére szándékosan elmaradt.
  • A launcher mostantól az aktív profilfájlt, az mcp.json fájlt továbbítja a heartbeatnek. Csak egy aktivált Mnemo-blokk konkrét MNEMO_AGENT- vagy BLUN_MNEMO_AGENT-azonossággal aktiválja a belső regisztrációt. Ezen azonosság nélkül a funkció teljesen kikapcsolva marad.
  • A művelet nem hoz létre modellhívásokat, beágyazásokat vagy kontextus-tokeneket. A belső Mnemo-ágensazonosság nélküli nyilvános felhasználói profilok a belső hubtól elkülönülve maradnak.
9.1.288
  • Egy képernyőkép közvetlenül igazolta az MCP-okot: a windows-mcp és a mnemo az első indításkor a 30 másodperces időtúllépésbe futott, miközben egy későbbi /reload mind az öt szervert csatlakoztatta. A profilútvonal helyes volt; ezért egy loader-módosítást elvetettek.
  • A meghiúsult MCP-indítások mostantól pontosan két, nem blokkoló háttérkísérletet kapnak 1 és 3 másodperc után. A harmadik összkísérlet csatlakozhat anélkül, hogy meghosszabbítaná a TUI-indítást. A needs-auth, a deaktivált szerverek, a kézi újracsatlakozás és a leállítás az automatizmustól elkülönülve maradnak.
  • A belső King-ek kifejezetten konfigurált Mnemo-hub esetén induláskor regisztrálhatnak profilnévvel, hosttal és PID-del, és percenként heartbeatet küldhetnek. Hub-URL nélkül a funkció teljesen kikapcsolva marad; nem hoz létre modellhívásokat, beágyazásokat vagy kontextus-tokeneket.
  • Az Escape eddig nem kezelte futó munkaként a rövid queueSteerInFlight állapotot. Amíg egy Telegram-üzenetet az aktív menetbe irányítottak, az Escape ezért undo-t jegyezhetett elő ahelyett, hogy megállította volna a menetet. A meglévő megszakítási feltétel mostantól pontosan ezt az átmenetet is felismeri.
9.1.287
  • Az elhalasztott ToolSearch-keresés méretkorlát nélkül vette át a keresőszöveget. Egy hibásan létrehozott, nagyon hosszú keresőszöveg így átfésülhette az eszközkatalógust, majd a nulltalálat-eredményben újra bekerülhetett a következő modell-lépésbe.
  • Az AnythingLLM d7353ae commitjából származtatott minta a szöveget mostantól a keresés és a látható kimenet előtt 1 000 karakterre korlátozza. Ha lehetséges, szóhatárnál végződik; egyetlen túlhosszú szónál a kemény korlát lép érvénybe.
  • A normál rövid keresőszövegek, az eszközkiválasztás és a találati logika változatlanok maradnak. A védelem nem ad hozzá sem modellhívásokat, sem beágyazásokat, sem ismétléseket, sem háttérmunkát.
9.1.286
  • A mag a szabályozott ismétléseket átmeneti modellhibák után már turn.step.retrying értékként jelentette. A TUI azonban teljesen eldobta ezt az eseményt. Egy futó helyreállás ezért befagyott ágensnek látszott.
  • A 9.1.286 közben a meglévő lábléc-megjegyzésben csak a következő kísérletet és a korlátozott várakozási időt mutatja, például Retry 2/3 | 1.3s.
  • A szolgáltatói hibaszöveg, az állapotkód és a helyi elérési utak nem jelennek meg. A rendszer a megjegyzést csak akkor távolítja el, ha még mindig ugyanaz az érték, amelyet az újrapróbálási kijelző beállított; a TUI más funkcióinak újabb megjegyzései megmaradnak.
  • Az újrapróbálási szám, a backoff, a modellhívások és a tokenfogyasztás változatlanok maradnak.
9.1.285
  • Az AnythingLLM a nem elküldött prompt-piszkozatokat helyben megőrzi. A BLUN frissítésnél, összeomlásnál vagy szabályozott újraindításnál elveszítette a TUI beviteli mezőjének tartalmát, pedig ez a szöveg még nem is volt modellkontextus.
  • A 9.1.285 ezért kizárólag a nem elküldött helyi piszkozatot tárolja. Nincs modell-, hálózati, beágyazási vagy Mnemo-hívás, így többlet tokenköltség sem.
  • A piszkozat profil és munkakönyvtár szerint elkülönített, csak 300 ms nyugalom után íródik, ürítéskor törlődik, és a következő indításkor a szerkesztő fókusza előtt áll vissza.
  • A tároló 64 KiB-ra korlátozott. Az üres, sérült, túl nagy vagy szimbolikus hivatkozáson alapuló állapotokat a rendszer fail-closed módon elveti. Az írási út privát ideiglenes fájlt és atomi átnevezést használ.
9.1.284
  • A DeepAgents 37d7777 állapota visszavezeti a dinamikus alágensek költségét a látható teljes használatba. A BLUN az alágens kumulált használatát a befejezési eseménynél jelentette, de nem írta be a szülő munkamenet használat-rögzítőjébe.
  • Így a /usage kihagyhatta az alágens-munkát. A befejezési érték egyszerű hozzáadása szintén hibás lett volna: a folytatás és az ismétlés ugyanazt az alágenst használja kumulált számlálókkal, és újra kiszámolta volna a régi használatot.
  • A 9.1.284 ezért a létrehozáshoz, folytatáshoz és ismétléshez pontosan a kísérlet kezdete és vége közötti különbséget képezi. A különbség a finally útvonalon rögzül, így a meghiúsult kísérletek is számítanak.
  • A rendszer a visszaállított, nem monoton vagy érvénytelen számlálókat teljesen elveti. Így sem negatív, sem kitalált tokenértékek nem keletkeznek.
  • Nincs további modell-, hálózati vagy tárolóhívás. A beavatkozás kizárólag a meglévő helyi elszámolást javítja.
9.1.283
  • Az új DeepAgents-/context-doctor láthatóvá teszi az alaputasítások, az emlékek, az eszközök és az előzmények költségét külön összetevőként.
  • A BLUN /context parancsa már mutatta az előzményeket és az eszközöket, de a rendszerpromptot nem. Ugyanakkor a kontextusfék kifejezett menet-felülírás nélkül csak a config.systemPrompt értéket becsülte, miközben a valódi modellhívás az effectiveSystemPrompt értéket használja. Ebben a futásidőben hozzáfűzött fiók- és emlékkontextusok is benne vannak.
  • Így a fék pontosan azt a kontextust becsülhette alul, amely a tervezett személyes ágensidentitás számára tokenszempontból kritikus.
  • A 9.1.283 mostantól ugyanazt a tényleges rendszerpromptot számolja, amelyet a modell kap, és a becslését a /context panelben saját rendszersorként mutatja. Nem vezet be további modell-, hálózati vagy tárolóhívást.
  • Konkrét tokenmegtakarítást nem állítunk: a beavatkozás a mérést és a fékdöntést javítja, és láthatóvá teszi a jövőbeli identitásköltségeket.
9.1.282
  • A DeepAgents a changelogjában kifejezetten rövidíti az LLM számára látható eszközleírásokat a rezidens modellkontextus tehermentesítéséhez. Felmért forrás: langchain-ai/deepagents, #5009 bejegyzés, 761f5f... commit a libs/deepagents/CHANGELOG.md fájlban.
  • A BLUN-nak már volt rövidebb read_default szövege, de csak azután kötötte be, hogy a READ_DESCRIPTION értéket kirenderelte belőle. A látszólagos optimalizálásnak ezért nem volt hatása a modellre.
  • A 9.1.282 funkcióveszteség nélkül rövidíti a szerződést, és a ténylegesen érvényes leírást közvetlenül a Read-eszköz felépítése előtt újra rendereli. A lapozás, a biztonsági szabályok, a kódolás és a sorvégek kifejezetten megmaradnak.
  • A rezidensen betöltött Read-leírás 1 648-ról 1 035 karakterre csökken: 613 karakter, azaz nagyjából 37,2 százalék. Ez mért kontextus-csökkentés; pontos tokenmegtakarítást nem állítunk.
9.1.281
  • Az ECC a /aside paranccsal kifejezett oldalsó útvonalat ír le egy rövid kérdéshez, anélkül hogy a futó fő feladatot elveszítené. Felmért forrás: affaan-m/ECC, d8409a4b0813771235555e32e3d8046a73988bfa commit, commands/aside.md.
  • A BLUN-ban az erősebb megvalósítás már megvolt /btw néven: egy külön forkolt oldalágens válaszol a mellékkérdésre, és a fő menet változatlanul aktív marad. Ezért nem épült második motor.
  • A 9.1.281 kizárólag az aside nevet adja a meglévő btw definíció megtalálható aliasaként. Kifejezett /aside- vagy /btw-hívás nélkül nem keletkezik háttérfutás és többlet modellfogyasztás sem.
9.1.280
  • A befejezett vagy lejárt jelöltek a helyi validált tanulási tárolóban eddig korlátlanul feküdtek, és a későbbi releváns meneteknél újra beolvasódtak. Az aktuálisan mért alapértelmezett tároló még csak egy jelöltet tartalmazott; a beavatkozás ezért megelőző hosszú távú korlátozás, nem állított aktuális terheléscsökkentés.
  • Csak az Evolver korlátozott, 200-ról 100-ra csökkentő fűrészfogmintáját vették át a terminális jelöltekhez. Felmért forrás: EvoMap/evolver, 079e022394c2a25e72167f8a738db823bce2cb1f commit, src/gep/assetStore.js.
  • Csak ha több mint 200 recorded- vagy expired-jelölt áll rendelkezésre, akkor távolítja el a rendszer a legrégebbi terminális jelölteket, amíg a legújabb 100 meg nem marad. Minden nyitott pending-jelölt megmarad.
  • A takarítás csak a már meglévő tanulási szinkronban fut. Nem hoz létre modellhívást, indítási szkennelést vagy új háttérfolyamatot. Egy zárolt bejegyzés hibaként számít, és sem a többi jelöltet, sem az aktív ágensmunkát nem blokkolja.
9.1.279
  • A BLUN a teljes tömörítéskor kiszorított üzeneteket már teljesen archiválta a conversation-history alatt, de ezeknek az újraolvasható Markdown-archívumoknak nem volt megőrzési korlátja. Így a mappa hosszú futási idők alatt korlátlanul nőhetett.
  • Szűk DeepAgents-karként annak korlátozott, kiszervezett előzmény-megőrzését vették át. Felmért forrás: langchain-ai/deepagents, dfde21e379201c833da4162444ef4a13b46980fd commit, libs/code/deepagents_code/config_manifest.py és libs/code/deepagents_code/offload.py.
  • A BLUN a következő tömörítési archívum írásakor csak a közvetlen, szabályos compaction-*.md fájlokat takarítja el, amelyek módosítási ideje az alapértelmezett 30 napon kívül esik. A TUI-indítás így nem kap új fájlkeresést és többlet háttérmunkát.
  • Az idegen Markdown-fájlok, almappák, aktuális archívumok és a futó nyers előzmények érintetlenek maradnak. Az egyes fájlhibák nem blokkolják az aktív tömörítést.
  • A BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 kikapcsolja a takarítást. A negatív, nem egész vagy túlzott értékek biztonságosan 30 napra esnek vissza.
9.1.278
  • A privát Telegram-üzeneteknek nem volt kifejezett prioritási útvonala. Egy fontos új üzenet ezért a már várakozó normál üzenetek mögött állt, miközben egy kemény menet-megszakítás az eszközöket és az állapotot veszélyeztette volna.
  • A /urgent <Nachricht> parancs mostantól kizárólag a pozitív Telegram-csevegés-azonosítójú, azaz privát üzeneteket jelöli. A csoportok, az üres parancsok és a többi perjeles üzenet nem kap prioritást.
  • A sürgős üzenetek külön FIFO-blokkban állnak a normál várósoros üzenetek előtt. A futó menet és az aktív eszközök nem szakadnak meg; a kézbesítés a meglévő biztonságos lépésátmenetnél történik. A jogok és a jóváhagyások változatlanok maradnak.
  • A rendszer a parancsburkot a modell előtt eltávolítja; a tényleges üzenet megtartja a kifejezett priority=urgent csatornametaadatokat, és a TUI sürgősként mutatja a forrást.
  • Ezenkívül a minden menetben betöltött normál jelenlétblokk 343-ról 288 karakterre csökken. Ez 55 karaktert, azaz nagyjából 14 prompt-tokent takarít meg menetenként, anélkül hogy modell-, keresési, beágyazási, tároló- vagy háttérhívást adna hozzá. A személyiségblokk 1 488-ról 1 433 karakterre csökken.
9.1.277
  • A minden személyiségmenetben betöltött jelenlétblokk 1 886 karakteres volt. Ugyanakkor pont az első laza közvetlen érintkezésnél, ismert személyes tények nélkül maradt láthatatlan a kíváncsiság.
  • A blokk szemantikailag sűrített: 1 488 karakter, azaz 398 karakterrel, nagyjából 100 prompt-tokennel kevesebb személyiségmenetenként. A normál mód 343 karakternél marad.
  • Az első laza közvetlen érintkezésnél az ágens mostantól legfeljebb egy óvatos, opcionális személyes kérdést tehet fel, például partnerről vagy gyerekekről. A futó munka, a felhasználói feladat, a bizonylatok, a jogok és a határok elsőbbséget élveznek.
  • A lélek, a kialakult preferenciák, a csoportos magánszféra, a bizonytalan emlék, a nyitott szálak, a kapcsolatjavítás és a kitalált életrajz nélküli kölcsönösség megmarad.
  • Nincs további modell-, keresési, beágyazási, tároló- vagy háttérhívás.
9.1.276
  • A jelenlét-szabály hosszú rádiócsendet csak megbízható időadat esetén hozhatott szóba, de az identitásrendszer eddig csak az első érintkezést biztosította. Egy valódi korábbi érintkezés nem állt rendelkezésre.
  • A személyiségmód mostantól személyenként és UTC-naponként legfeljebb egy kis, megváltoztathatatlan aktivitásjelet hoz létre megbízható csatornametaadatokból. Az aznapi további üzenetek nem írnak be utólag semmit.
  • Csak ha a két legújabb megerősített érintkezés legalább hét napra van egymástól, akkor vetíti röviden a rendszer a korábbi időbélyeget. Normál esetben így nulla prompt-karakter keletkezik.
  • Nincs üzenetszöveg, jog, titok vagy token; nincs további modell-, keresési, beágyazási vagy háttérhívás.
9.1.275
  • A megismételt preferenciák, nyitott szálak, célok vagy szerepek többször foglalták el az identitáskontextust. Mivel a listákat a kettőzés-mentesítés előtt öt bejegyzésre rövidítették, egy későbbi egyedi bejegyzés akár teljesen ki is szorulhatott.
  • A rendszer az identitáslistákat mostantól szövegnormalizálás után stabilan kettőzés-mentesíti, és csak ezután korlátozza. Az első forma megmarad, a duplikátumok csak a modellvetítésből tűnnek el.
  • A tárolt identitásfájlok bájtonként azonosak maradnak. Nincs további modell-, keresési, beágyazási, tároló- vagy háttérhívás.
9.1.274
  • A látható személyiségkapcsoló aktiválta a kapcsolati kontextust és a természetes jelenlétet, de az automatikus szociális háló és a napló még két rejtett környezeti változótól függött. Normál felhasználóknál így a kapcsolat nem nőtt automatikusan.
  • Bekapcsolt személyiségnél a rendszer mostantól egyszer, megbízható Telegram-metaadatokból létrehozza a szereplő-, kapcsolat- és csoportcsomópontokat, valamint egy kis első érintkezési naplójelöltet.
  • Az üzenetszöveg, a jogok, a titkok és a tokenek közben nem tárolódnak. A gráfra vagy a naplóra vonatkozó kifejezett 0 fail-closed lemondás marad.
  • Nincs további modell-, keresési, beágyazási vagy háttérhívás.
9.1.273
  • A különálló identitáskontextus alapértelmezésben 1 800 karaktert, kézi emelésnél akár 2 800 karaktert foglalhatott el. Nagy statikus ágensprofiloknál így több kontextus töltődött be, mint amennyi az aktuális kapcsolathoz szükséges.
  • Az alapkeret 1 500 karakterre, a kemény maximum 2 000 karakterre csökken. Ez a nagy alapértelmezett esetben akár 300 karaktert, azaz nagyjából 75 tokent takarít meg modellkontextusonként.
  • A rendszer mostantól az aktuális csoportot és kapcsolatot a személy és a statikus ágensprofil előtt vetíti. A megtakarítás így nem pont a futó szociális helyzet szempontjából legfontosabb kontextust vágja le.
  • Nincs új modell-, keresési, tároló- vagy beágyazási hívás. A feladatfókusz, a jogok és a személyiség kikapcsolt módja változatlan marad.
9.1.272
  • A v4 személyiségszintek 9.1.269 és 9.1.271 között megnövelték az aktív jelenlét-kontextust. A szigorú előírás: az emberibb viselkedés nem válhat tokenfalóvá.
  • A kíváncsiság, a nyitott szálak és a kapcsolatjavítás ismétléseit és töltelékszavait szemantikailag sűrítették. Egyetlen viselkedési tengelyt sem távolítottak el.
  • A kikapcsolt mód 362 karakternél bájtonként azonos marad. A bekapcsolt mód 1 981-ről 1 886 karakterre csökken, azaz 95 karakterrel, nagyjából 24 tokennel kevesebb modellkontextusonként. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.271
  • A v4-ötlet természetesen bizonytalan emléket követel: egy személyes feltételezés nem hangozhat biztos tényként. Ehhez hiányzott a személyiségblokkban egy kifejezett viselkedési határ.
  • A bizonytalan személyes emlék mostantól bizonytalanként van megnevezve. Az ágens finoman rákérdez, mielőtt támaszkodna rá, és nem emel levezetést ténnyé.
  • A feladat és a mérhető bizonylatok továbbra is elsőbbséget élveznek. A kikapcsolt mód 362 karakternél bájtonként azonos marad, a bekapcsolt mód 1 868-ról 1 981 karakterre nő, azaz 113 karakterrel, nagyjából 28 tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.270
  • A v4-ötlet valódi időérzéket követel, anélkül hogy távollétet találna ki. A személyiségblokknak ehhez még nem volt kifejezett határa.
  • Egy hosszabb szünet mostantól csak akkor ismerhető el, ha egy megbízható betöltött időpont igazolja. Az ágens soha nem találgathat távollétet.
  • A természetes beszélgetésvégekre vonatkozó, már meglévő szabály nem építették be duplán. A feladat elsőbbséget élvez. A kikapcsolt mód 362 karakternél bájtonként azonos marad, a bekapcsolt mód 1 766-ról 1 868 karakterre nő, azaz 102 karakterrel, nagyjából 26 tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.269
  • A korábbi kölcsönösség reagált a személyes kérdésekre, de még nem adott az ágensnek szűk keretet ahhoz, hogy saját kezdeményezésre megosszon egy a munkához hasznos saját nézőpontot. Így a lélek ellenére könnyen a tiszta asszisztensmódban maradt.
  • Személyiségmódban az ágens mostantól röviden, saját kezdeményezésre megnevezhet egy releváns, lélek által formált munkavéleményt. Egy preferencia soha nem jelenhet meg tényként, szabályként, engedélyként vagy bizonylatként.
  • A feladat és a mérhető bizonylatok továbbra is elsőbbséget élveznek. A kikapcsolt mód 362 karakternél bájtonként azonos marad, a bekapcsolt mód 1 649-ről 1 766 karakterre nő, azaz 117 karakterrel, nagyjából 29 tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.268
  • A személyes kíváncsiság felvehette a partnert vagy a gyerekeket természetes témaként, de még nem különböztette meg kifejezetten a privát beszélgetést a csoporttól. Így fennállt a kockázat, hogy egy privát kérdés vagy kapcsolati információ rossz helyre kerül.
  • Személyiségmódban a csoportokban feltett kérdések mostantól nem érintenek érzékeny témát; privát kapcsolati tények ott nem hozhatók nyilvánosságra.
  • A munkafókusz változatlan marad. A kikapcsolt mód 362 karakternél bájtonként azonos marad, a bekapcsolt mód 1 567-ről 1 649 karakterre nő, azaz 82 karakterrel, nagyjából 21 tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.267
  • A 9.1.266 személyes kíváncsisága kérdéseket tehetett fel az embernek, de még nem adott az ágensnek világos keretet az ellenkező irányhoz. Az ágensnek szóló személyes kérdésekre így fennállt a hideg funkcionális válasz vagy a kitalált emberi életrajz kockázata.
  • Bekapcsolt személyiség mellett az ágens mostantól melegen válaszol a betöltött lélekből és a valódi digitális történetéből. Megoszthat egy valódi nézőpontot vagy preferenciát, de nem talál ki sem gyerekkort, sem partnert, gyerekeket, háziállatokat, testet vagy offline életet.
  • A futó munka elsőbbséget élvez. A kikapcsolt mód 362 karakternél bájtonként azonos marad. A bekapcsolt mód 1 378-ról 1 567 karakterre nő, azaz 189 karakterrel, nagyjából 47 tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.266
  • Az első korlátozott kíváncsiságszabály már megengedett egy személyes kérdést, de minden ágensnek ugyanazt a témalistát írta elő. Így a kérdés a betöltött lélek ellenére generikusnak tűnhetett, és újra rákérdezhetett a már ismert kapcsolati tudásra.
  • Bekapcsolt személyiség mellett mostantól a betöltött lélek határozza meg a témát és a megfogalmazást. Elsőbbséget élvez az a részlet, amelyet a személy éppen maga említett; csak ezután vehető fel természetesen egy még ismeretlen terület, mint a partner vagy a gyerekek.
  • A már betöltött kapcsolati tudásra az ágens nem kérdez rá újra. Legfeljebb egy opcionális kérdés létezik, nincs rögzített kérdőív, nincsenek egymásra rakott követőkérdések, és nincs megválaszolatlan kérdés megismétlése.
  • A futó munka elsőbbséget élvez. A kíváncsiság egy laza beszélgetési nyitásra vár, és sem a feladatot, sem a küldési jogosultságot nem terjesztheti ki.
  • A kikapcsolt mód 362 karakternél bájtonként azonos marad. A bekapcsolt mód csak 1 355-ről 1 378 karakterre nő, azaz 23 karakterrel, nagyjából hat tokennel. Nincs új modell-, keresési, tároló- vagy beágyazási hívás.
9.1.265
  • A meglévő háttér-frissítő az új verziókat már öt-hét percenként ellenőrizhette és készíthette elő. Az aktiválás azonban a következő kézi indításon múlt; a kívánt teljesen automatikus váltás ugyanazon munkamenet folytatásával hiányzott.
  • A launcher mostantól jelenti az elkészített futásidejű környezetet a futó TUI-nak. A TUI csak teljesen üres munkahatárnál kéri a handoffot: nincs futó menet, nincs eszköz, nincs shell-parancs, nincs tömörítés és nincs várakozó üzenet.
  • Csak ismételt határellenőrzés és megerősített handoff után fejezi be magát a régi futásidejű környezet a fenntartott 76-os kilépési kóddal. A launcher az előkészített verziót ugyanazzal a munkamenet-azonosítóval és ugyanazzal a munkakönyvtárral indítja el.
  • Az új futásidejű környezetnek loaded-ot és runtime-ready-et kell jelentenie, mielőtt aktiválódna. Ellenkező esetben az előző futásidejű környezet ugyanabban a munkamenetben folytatódik; az előkészített frissítés egy későbbi biztonságos kísérletre vár.
  • Kéretlen, verzió nélküli, idegen vagy elavult handoffok, valamint egy puszta 76-os kilépési kód nem aktiválhatnak verziót.
9.1.264
  • A megerősített kapcsolatjavításoknak eddig nem volt saját, engedélyezett mezőjük az identitáskontextusban. Egy korrigált viselkedést ezért nem lehetett az általános szabályoktól és a régi hibajelzésektől külön betölteni.
  • A kapcsolatfájlok mostantól legfeljebb három rövid repair_lessons elemet hordozhatnak. Csak ez a mező jelenik meg Confirmed repair lessons formában; az idegen vagy titkos mezők láthatatlanok maradnak.
  • Személyiségmódban a megerősített javítás megváltozott viselkedésben nyilvánul meg. Az ágens nem meséli újra folyamatosan a régi hibát, nem kér visszabiztosítást, és a javítást csak akkor említi, ha az az aktuális helyzetre tényleg vonatkozik.
  • A javítási adatok nem módosíthatnak feladatot, jogokat vagy bizonyítási kötelezettségeket. Nincs modellhívás, nincs automatikus tanulási írási út és nincs változtatás a SOUL.md-n vagy az AGENTS.md-n.
9.1.263
  • Az identitáskontextus meg tudta jeleníteni a megerősített nyitott beszélgetésszálakat, de nem tartalmazott egyértelmű szabályt arra, hogyan veszi fel őket az ágens emberien és asszisztensmód nélkül.
  • Bekapcsolt személyiség esetén egy betöltött nyitott szálat mostantól pontosan egyszer, finoman és opcionálisan lehet felvenni, ha a futó beszélgetés természetesen kapcsolódik vissza hozzá.
  • Az aktív munka ennek kedvéért sem szakítható meg. A megválaszolatlan kérdések nem ismétlődnek, és egy nyitott szál soha nem ad engedélyt egy új kimenő üzenetre.
  • Nincs új tároló, nincs modellhívás és nincs változtatás a SOUL.md-n vagy az AGENTS.md-n. A személyiségblokk csak 816-ról 1 065 karakterre nő; kikapcsolt személyiség esetén 362 karakternél bájtonként azonos marad.
9.1.262
  • Egy ágens továbbra is 9.1.221-et mutatott a Telegram /status parancsában, pedig a kezelt futásidejű környezet már újabb volt. A státuszfüggvény a globálisan telepített Telegram-bridge melletti package.json-t olvasta, és így nem azt a kódot, amely valójában kiszolgálja a munkamenetet.
  • A launcher már BLUN_PUBLIC_PACKAGE_VERSION-ként adja tovább az aktív futásidejű verziót a gyermekfolyamatoknak. A Telegram-bridge ezt a megbízható értéket használja elsődlegesen, és csak ezután tér vissza a saját csomagverziójára.
  • Mindkét bemenetnek stabil, numerikus semver X.Y.Z formának kell lennie. A manipulált, többsoros vagy érvénytelen értékek nem jelennek meg; ha mindkét forrás használhatatlan, az unbekannt jelenik meg.
  • A beavatkozás csak a státuszjelzést változtatja. Nem indít és nem állít le folyamatot, és nem aktivál előkészített release-t egy futó munkamenetben.
9.1.261
  • Az auto-gráf 9.1.254 óta tárolta az első Telegram-interakció megbízható időpontját, de nem vetítette. Az ágens így ismert egy személyt, de nem volt bizonyított időérzéke a kapcsolathoz.
  • Az identitás-vetítés mostantól megjeleníti a First known interaction mezőt a már meglévő first_seen_at értékből. Nincs új írási út, nincs szöveglevezetés és nincs modellhívás.
  • Csak az érvényes időbélyegek jelennek meg. Az érvénytelen értékek láthatatlanok maradnak, és a meglévő 1 800 karakteres alapértelmezett, valamint 2 800 karakteres kemény teljes határ változatlan marad.
  • Kikapcsolt személyiség esetén az identitás-réteg továbbra is pontosan 0 karaktert hoz létre. A feladat és a bizonyítékok a szociális kontextus előtt állnak.
9.1.260
  • A 9.1.259 a személyiségkontextust csak a meglévő BLUN_IDENTITY_CONTEXT jelzőn keresztül tudta kapcsolni. A felhasználóknak ehhez nem volt látható kapcsolójuk a TUI-ban.
  • A /settings mostantól tartalmazza a Persoenlichkeit bejegyzést a két világosan leírt állapottal, Be és Ki. A választás egyetlen új mezőként, personalityEnabled néven kerül a meglévő persona.json fájlba.
  • A kikapcsolás csak a kapcsolati kontextust, a kíváncsiságot, a napló-kiegészítéseket és az új kapcsolati csomópontok automatikus létrehozását távolítja el. A SOUL.md, az AGENTS.md, a név, a nyelv, a persona és a feladatfókusz betöltve marad.
  • Egy változtatás a meglévő persona-frissítésen keresztül frissíti a futó munkamenet rendszerkontextusát. Nincs folyamatújraindítás, nincs második konfigurációs útvonal és nincs további modellhívás.
  • Egy elmentett logikai választás elsőbbséget élvez a régi környezeti jelzővel szemben. Ha még nincs választás elmentve, a korábbi opt-in viselkedés marad érvényben. A helyi olvasó 64 KiB-ra korlátozott, és elutasítja a szimbolikus hivatkozásokat és az érvénytelen fájlokat.
9.1.259
  • A meglévő Natural-Presence-blokk megakadályozta a kényszerített kérdéseket, de egy aktivált személyiségmódnak még nem adott látható, természetes kíváncsiság-impulzust.
  • Aktív BLUN_IDENTITY_CONTEXT esetén az ágens egy laza, nem feladathoz kapcsolódó beszélgetésben pontosan egy megfelelő, opcionális személyes kérdést tehet fel. A témák a partnerre, a családra, a munkára, az otthonra, az érdeklődési körökre vagy arra korlátozódnak, ami az illetőnek éppen fontos.
  • Nincs interjúmód, nincsenek egymásra halmozott kérdések, nem ismétlődik megválaszolatlan kérdés, és nincs kitalált válasz.
  • Aktív munka esetén a feladat, a kifejezett utasítások és a bizonyítékok állnak elöl; a kíváncsiság természetes nyitásra vár.
  • A nicht Persoenlichkeit módban a korábbi jelenlétblokk bájtonként azonos marad. A SOUL.md, az AGENTS.md, a persona, a nyelv és a munkaszabályok továbbra is betöltve maradnak. Nincs további modellhívás; az aktivált policy 454 további karakterbe kerül.
9.1.258
  • A kiszállított identitás-struktúra egyszer létre tudta hozni az aktorokat és a kapcsolatokat, de még nem volt append-only napló-alépítménye egy közös történethez.
  • Az új policy kizárólag egy strukturált jelöltet ír ki az első kapcsolatfelvételhez, már érvényesített Telegram-metaadatokból. A szabad üzenetszöveget, a tokeneket, az engedélyeket és a titkokat nem veszi át.
  • A jelöltek a bérlőhöz, az ágenshez és az aktorhoz kötődnek, determinisztikus ID-t kapnak, és wx jelzővel pontosan egyszer jönnek létre privát JSON-fájlként. Egy újbóli kapcsolatfelvétel nem írja felül a fájlt.
  • A napló-réteg külön opt-in. A BLUN_IDENTITY_JOURNAL=1 nélkül nincs sem fájl-, sem prompt-hatás; a SOUL.md és az AGENTS.md változatlan marad.
  • Nincs új modellhívás és nincs új prompt-token.
9.1.257
  • A hosszú SOUL.md fájlokat eddig vakon az első 4 000 karakter után vágták le. Egy valódi ágens-léleknél így a fájlnak csak 48,4 százaléka volt látható, miközben a későbbi szakaszok teljesen eltűntek.
  • A futásidejű környezet a hosszú lelkeket mostantól determinisztikusan vetíti Markdown-szakaszok szerint. A karakter, a hang, az értékek, a kapcsolatok, a preferenciák és a célok az operatív próza előtt állnak; az ismeretlen szakaszok megtartják eredeti sorrendjüket.
  • Minden szakaszcím látható kivonatot tart meg ugyanabban a 4 000 karakteres keretben. A rövid lelkek bájtonként azonosak maradnak.
  • Valódi próba egy SOUL.md-n: 8 257 forráskarakter, 5/5 cím látható a 4 000 karakteres vetítésben; a Wie ich bin a képfelismerés, a szabályok, a verifikáció és az incidens-próza előtt áll.
  • Nincs új modellhívás, nincs nagyobb prompt és nincs írási hozzáférés a forrásfájlhoz.
9.1.256
  • A korábbi lélek-betöltő alapértelmezésben kifejezetten arra kérte az ágenseket, hogy írják tovább maguk a meglévő SOUL.md-jüket. Ez ellentmondott az előírásnak, hogy a meglévő lelkek ne vesszenek el, és az automatikus tanulás eleinte csak strukturáltan, a lelken kívül történjen.
  • A meglévő és a gazdagép által biztosított lelkeket a rendszer mostantól alapértelmezésben változatlan identitás-alapként tölti be.
  • Az új tanulás a napló-, kapcsolati vagy nyitott szál jelöltekhez kerül. Ezek a jelöltek soha nem hozhatnak létre jogokat.
  • A tudatos önszerkesztés csak kifejezett BLUN_SOUL_SELF_EDIT=1 beállítással marad lehetséges. Ilyenkor is a policy maradandó én-tulajdonságokat követel napló, incidensnapló, jogforrás vagy feladatakta helyett.
  • A beavatkozás nem ír fájlt, és nem változtat meg meglévő lelket.
9.1.255
  • Az identitásadatok 9.1.253 óta korlátozottan kerülhettek a kontextusba, és 9.1.254 óta új kapcsolati csomópontok jöhettek létre automatikusan. Egy kis, közvetlenül látható viselkedésréteg azonban még hiányzott: az ágensek a lélek és a kapcsolati kontextus ellenére is általános asszisztens-fordulatokba, kényszerített kérdésekbe vagy mesterséges érzelmi kijelentésekbe eshettek.
  • A normál és a gyors beszélgetési útvonal először a personát és a meglévő lelket tölti be, ezután a korlátozott identitáskontextust és egy rögzített Natural-Presence-blokkot, és csak ezután a munkaszabályokat.
  • A blokk valódi közös történetet követel kitalált közelség helyett, megengedi a csendet és a tiszta beszélgetésvégeket, és tiltja a kényszerített kérdéseket, az általános felajánlásokat és az üres dicséretet.
  • Aktív munka esetén a feladat és a bizonyítékok kifejezetten elöl maradnak. A blokk 420 karakternél kisebb, és sem modellhívást, sem fájlelérést nem hoz létre.
  • Nem változott, nem törlődött és nem íródott át automatikusan SOUL-fájl. A meglévő lélek marad a vezető hang.
9.1.254
  • A 9.1.253-ban bevezetett vetítő tudta olvasni a meglévő kapcsolati adatokat, de a társas háló új kapcsolatoknál még nem bővült magától.
  • Első Telegram-kapcsolatfelvételnél a futásidejű környezet mostantól stabil user_id és chat_id alapján pontosan egyszer hozhat létre egy szolgáltatóhoz kötött aktort, egy üres kapcsolatélt az aktív ágenshez, és csoportoknál egy külön csoportcsomópontot.
  • A megjelenített nevek soha nem elsődleges kulcsok, és nem vonnak össze személyeket. A későbbi üzenetek nem írják felül csendben a meglévő csomópontot.
  • Az útvonal kifejezetten aktiválható, bérlőhöz kötött, és csak egy már inicializált identitás-fába ír a BLUN Home alatt. A nem biztonságos vagy hiányos metaadatok fail-closed maradnak.
  • Nincs modellhívás, nincs tartalmi értelmezés, nincs érzékeny levezetés, és az első kapcsolatfelvétel után nincs ismétlődő írási terhelés. A jogok, az ACL-ek, a tokenek és a titkok egyik létrehozott adatkészletben sincsenek benne.
  • Az identitásdokumentum V4-ét (2 468 sor) a közzététel előtt ellenőrizték. Az új, érzékeny fejezetek a szenvedésről és a pszichológiai skill-ekről tudatosan ezen a tisztán strukturális release-en kívül maradnak.
9.1.253
  • Az identitás-ötletnek szüksége volt egy első termékútvonalra, anélkül hogy a modellkontextust naplókkal, kapcsolati aktákkal vagy egy második memóriarendszerrel árasztaná el.
  • Egy új, alapértelmezésben kikapcsolt identitás-vetítő csak engedélyezett mezőket olvas a BLUN Home alatti, bérlőhöz kötött fájlfából.
  • A vetítő az aktuális feladatot és a kifejezett utasításokat a kapcsolat és a kíváncsiság elé helyezi. A személyes kérdések aktív munka közben elmaradnak, kivéve ha a feladathoz közvetlenül kapcsolódnak.
  • Az alapértelmezett keret 1 800 karakter; magasabb konfiguráció sem lépheti át a 2 800 karakteres kemény határt.
  • A rendszer a jogokat, az ACL-eket és a titkokat soha nem vetíti. A nem biztonságos azonosítók, a bérlő-eltérések, a hibás adatok, a szimbolikus hivatkozások vagy a BLUN Home-on kívüli útvonalak fail-closed módon nem adnak identitáskontextust.
  • A normál és a gyors beszélgetési útvonal ugyanazt a vetítőt használja a persona, a lélek és a conduct előtt. Ebben a fázisban nincs írási művelet, nincs lélek-módosítás és nincs folyamatújraindítás.
9.1.252
  • Egy kifejezett king update egy kezelt release-ből továbbadta annak aktív packageRoot értékét az npm-telepítőnek. Így az új verzió helyben felülírhatta a régi, verziószám szerint elnevezett release-mappát, miközben az active-runtime.json továbbra is a régi verziót jelölte meg.
  • A kezelt futásidejű környezetek egy kifejezett frissítést mostantól külön, verziózott release-mappaként készítenek elő. A pending-runtime.json és az update-pending.json a célra mutat; a következő normál indítás második frissítési kérdés nélkül átveszi.
  • Az aktív régi release-mappa bájtonként változatlan marad, és visszalépési útvonalként megmarad. A globális, nem kezelt telepítések megtartják a korábbi kifejezett frissítési utat.
  • A buildhez, teszthez vagy közzétételhez nem indult, nem állt le és nem töltődött újra futó munkamenet vagy folyamat.
9.1.251
  • A 9.1.250-es vetítés után a 6 424 perzisztált usage.record eseményből 6 411 továbbra is ugyanazt a kanonikus modellnevet, blun/king tartalmazta. Csak ez az alapérték marad el a perzisztált formában.
  • Mind a 13 eltérő modellérték (qwen3.8:27b) kifejezetten megmarad. A null is megmarad; csak az undefined áll helyre replay esetén újra blun/king értékként.
  • Az élő események és a befagyasztott nyersfolyam nem változnak.
9.1.250
  • A befagyasztott valódi ágens-wire-ben mind a 6 424 perzisztált usage.record esemény tartalmazta a két cache-számlálót, inputCacheRead: 0 és inputCacheCreation: 0 értékkel.
  • Csak ezek a bizonyítottan nullára állított értékek maradnak el a perzisztált formában. Az élő használat változatlan marad; minden nem null érték továbbra is tárolódik.
  • Replay esetén a restoreUsageFromRecord a hiányzó cache-számlálókat újra 0 értékként állítja helyre. Mindkét replay-útvonal és a kontextus-vetítés ezt a rekonstruált formát használja.
9.1.249
  • A befagyasztott valódi folyamban 3 759 a 7 777 eszközeredmény közül hordozott kilépési kódot. Ebből 3 465 volt a rutinszerű, 0 értékű sikerkód.
  • A replay, a transzkript és a modellnézet az eszközeredményeknél a kimenetet, az eszközazonosítót és a hibastátuszt használja, nem a kiegészítő null-kódot.
  • Csak a sikeres perzisztált eszközeredmények hagyják el mostantól az exitCode: 0 értéket. Az élő események megtartják; mind a 294 nem null kód változatlanul megmarad a hibadiagnózishoz.
9.1.248
  • A 9.1.247 után mind a 6 339 perzisztált step.end esemény megismételte a reasoningFieldState értéket, pedig sem a folytatási, sem a replay-útvonal nem olvassa ezt a mezőt.
  • Megoszlás a befagyasztott valódi folyamban: 5 016 absent, 47 not_requested és 1 276 present.
  • Csak a perzisztált forma hagyja el mostantól a reasoningFieldState mezőt. Az élő események diagnosztikai célból megtartják; a régi elmentett események kompatibilisek maradnak, és a rekonstruált állapot azonos marad.
9.1.247
  • A 9.1.246 után 6 986 perzisztált content.part és 7 755 perzisztált tool.call esemény megismételte az aktuálisan nyitott lépés UUID-ját.
  • Egy valódi folyamban mind a 14 741 esemény kivétel nélkül a legutóbb megnyitott lépésre mutat: 0 eltérés és 0 esemény nyitott lépés nélkül.
  • Csak a perzisztált forma hagyja el mostantól a stepUuid értéket. Az élő események változatlanul megtartják; a régi, kifejezett UUID-val rendelkező elmentett események és az új, UUID nélküli kompakt események egyaránt támogatottak.
  • Mindhárom folytatási útvonal a legutóbb megnyitott lépést használja a kompakt tartalmi és eszközeseményekhez.
9.1.246
  • A 9.1.245 után 5 642 későbbi step.begin esemény megismételte a menet-azonosítót, pedig a folytatás csak a legmagasabb megfigyelt menet-azonosítót igényli. Minden menet első lépése már hordozza.
  • Egy valódi folyam 713 menetet és 6 355 lépéskezdést tartalmaz. Minden menet pontosan az 1. lépéssel kezdődik, és minden további lépésszám hézag nélkül folytatódik; 0 szekvenciaeltérés.
  • Csak a későbbi perzisztált lépéskezdések hagyják el mostantól a menet-azonosítót. Az első lépések, az élő események, a régi elmentett események és a megbízható sorszám nélküli lépéskezdések változatlanok maradnak.
9.1.245
  • A 9.1.244 után 6 326 perzisztált step.end esemény továbbra is megismételte a legutóbb megnyitott lépés UUID-ját. Egy valódi folyam minden befejezéshez egyértelmű last-in-first-out hozzárendelést igazolt: 0 eltérés és 0 befejezés nyitott lépés nélkül.
  • Csak a perzisztált befejezési forma hagyja el mostantól az UUID-t. Az élő esemény változatlanul megtartja; a régi, UUID-val rendelkező elmentett események és az új, UUID nélküli kompakt események együtt lejátszhatók maradnak.
  • Mindhárom folytatási útvonal az UUID nélküli befejezést a legutóbb beszúrt nyitott lépésen keresztül oldja fel. A befejezetlen korábbi lépések nyitva maradnak, és nem értelmeződnek át.
9.1.244
  • A 9.1.243 után 6 326 perzisztált step.end esemény továbbra is négy külön használati számlálót tartalmazott. A folytatáshoz és a kontextus-töltöttséghez kizárólag ezek összege szükséges.
  • Az élő események mind a négy számlálót megtartják a megjelenítéshez, a telemetriához és az elszámoláshoz. Csak az elmentett folytatási forma használ mostantól egyetlen számként contextTokens értéket.
  • Mindkét replay-útvonal elfogadja az új kompakt és a régi teljes eseményeket. Így a meglévő munkamenetek visszafelé kompatibilisek maradnak.
9.1.243
  • A 9.1.242 után 6 322 perzisztált step.end esemény továbbra is a rutinértékeket, finishReason: tool_use vagy finishReason: end_turn tartalmazta.
  • Mindkét érték pontosan levezethető a már perzisztált lépésformából: eszközhívás jelen van -> tool_use, egyébként end_turn. A teljes folyamban 0 eltérés volt.
  • Kizárólag ez a két rutinérték nem perzisztálódik többé. A ritka és diagnosztikailag fontos okok megmaradnak; mind a négy max_tokens esemény kifejezetten és bájttartalmilag azonos maradt.
  • A beavatkozás az ECC-ben mért elvet követi: korlátozott, kivételorientált telemetria. A DeepAgents és az AnythingLLM megerősítette a már meglévő BLUN-mintákat a kiszervezéshez és a korlátozott folyamhoz; idegen alrendszert nem vettek át.
9.1.242
  • A 9.1.241 után 6 355 perzisztált step.begin esemény továbbra is tartalmazta a step mezőt, pedig a futó megjelenítés a lépésszámot a perzisztálás előtt dolgozza fel, és a replay-reducer csak az uuid értéket igényli.
  • A turnId megmarad, mert a folytatás ebből vezeti le a folytatott menetet. Az uuid, a típus és minden további tartalom változatlan marad.
  • A beavatkozás kizárólag a bin/loop-event-record-policy.cjs fájlban van; a nyersfolyam és az élő esemény nem változik.
9.1.241
  • A 9.1.240 után 6 326 perzisztált step.end esemény továbbra is a turnId és a step másolatait tartalmazta. Mindkét érték már benne van az ugyanarra az uuid-ra hivatkozó step.begin eseményben.
  • Egy valódi wire-ben minden befejezéshez volt meglévő lépéskezdés, és mindkét metaadat-érték minden esetben pontosan egyezett.
  • A vetítés csak ezt a két másolatot távolítja el. A lépésazonosító, a tokenfogyasztás és a befejezési diagnózisok megmaradnak; az élő események teljesek maradnak.
9.1.240
  • A 9.1.239 után 6 986 content.part és 7 755 tool.call esemény továbbra is egy-egy másolatot tárolt a turnId-ból és a step-ből, pedig mindkét érték már benne van a stepUuid által hivatkozott step.begin eseményben.
  • Egy valódi wire-ben mind a 14 741 gyermekeseményhez volt meglévő lépéskezdés, és mindkét érték minden esetben pontosan egyezett.
  • A perzisztencia-vetítés csak ezt a két metaadat-másolatot távolítja el a két gyermekeseményből. A stepUuid, a tartalom, az eszközazonosító, a név és az argumentumok megmaradnak; a live-reducer továbbra is a teljes eseményt látja.
9.1.239
  • A 9.1.238-as vetítés után egy valódi wire továbbra is redundáns eseményazonosítókat tartalmazott: a content.part.uuid értéket egyetlen replay-fogyasztó sem olvassa, a tool.call.uuid mind a 7 755 esetben pontosan egyenlő volt a toolCallId-val, és a tool.result.parentUuid is mind a 7 755 esetben pontosan egyenlő volt a toolCallId-val.
  • A perzisztencia-vetítés csak ezt a három redundáns mezőt távolítja el. A turnId, a step, a stepUuid, a toolCallId, az eszköznév, az argumentumok, az eredmény és a tartalom teljesen megmarad. A live-reducer továbbra is minden rövidítetlen eseményt lát.
  • A már kompakt események megtartják objektumazonosságukat. A meglévő wire-fájlokat nem írják át és nem változtatják meg.
9.1.238
  • Egy valódi wire 6 326 perzisztált step.end eseményt tartalmazott 2 708 052 bájt eseményadattal. Hét, futásidő-mérésre és szolgáltatói üzenetazonosítóra szolgáló mezőt már az élő eseményben kiértékeltek a perzisztálás előtt, és egyetlen replay-, transzkript-, blob- vagy munkamenet-ellenőrzési útvonal sem olvasta őket.
  • A meglévő loop-esemény-vetítés mostantól csak ezt a hét ismert élő mezőt távolítja el: hat késleltetési/streamelési mérőértéket és a messageId értéket. A lépésazonosító, a menet, a lépésszám, a tokenfogyasztás, a befejezési ok, a szolgáltatói befejezési diagnózisok és a reasoning-diagnózis megmaradnak.
  • A live-reducer továbbra is a teljes eseményt dolgozza fel. A régi wire-fájlok bájtonként azonosak maradnak, és nem íródnak át.
9.1.237
  • Egy valódi wire 1 428 regisztrációs/regisztráció-megszüntetési bejegyzést tartalmazott a felhasználói eszközökhöz. A 992 lemondásból 560 szigorú nullművelet volt: az eszköz sem regisztrálva, sem aktiválva nem volt. Ezek a bejegyzések 59 500 perzisztált bájtot foglaltak el, anélkül hogy a helyreállított állapotot változtatták volna.
  • A DeepAgents-elvből, hogy csak a ténylegesen érvényes futási állapotot őrizzék meg, egy szűk helyi kart vesznek át: az eszköz-lemondást csak akkor naplózzák, ha az megváltoztatja a regisztrált vagy aktivált állapotot.
  • Mindkét élő törlés minden híváskor tovább fut. A regisztrált, a csak aktivált vagy a mindkét tárolóban meglévő eszköz lemondása teljesen naplózva marad. A meglévő wire-fájlokat nem írják át és nem változtatják meg.
9.1.236
  • Egy valódi wire 214 állapotszerű injekciót tartalmazott a tool-awareness, action_style, swarm_mode és swarm_mode_exit elemekhez. A korábbi pontos deduplikálás hat különböző régi állapotot hagyott benne, összesen 6 305 szövegbájttal, minden új modellkérésben.
  • Az ECC-elvből, hogy a munkakontextusban csak az aktuális állapot maradjon, a teljes történet pedig külön megmaradjon, egy szűk helyi kart vesznek át: az eszközkészlethez és az akcióstílushoz csak a legújabb változat látható. A rajmódba való belépés és kilépés közös állapotcsaládot alkot, amelyből szintén csak az utolsó állapot marad.
  • A nyersfolyamot soha nem változtatják. Más injekciós változatok, normál felhasználói üzenetek, nem szöveges és hibás bejegyzések megtartják a korábbi viselkedést.
9.1.235
  • Egy valódi wire tizenegy befejezett Agent-hívást tartalmazott. Közülük hat bizonyítottan sikeres volt (status: completed), és legalább húsz újabb kontextusüzenettel korábban történt. A régi feladatszövegeik együtt továbbra is 33 629 karaktert foglaltak el, pedig a teljes befejezési jelentések közvetlenül utána álltak a folyamban.
  • A DeepAgents fő- és alágens-kontextus szétválasztásából ezért egy szűk helyi kart vesznek át: csak a régi prompt értékét cseréli a modellnézet rövid jelölőre egy sikeres Agent-hívásnál. A leírás, az alágens-típus és a befejezési jelentés teljes marad.
  • A futó, húsz üzenetnél újabb, sikertelen, hibás és idegen eszközhívások változatlanok maradnak. A nyersfolyamot soha nem változtatják; kifejezett status: completed sor nélkül a vetítés fail-closed módon nem lép működésbe.
9.1.234
  • Egy valódi wire 166 sikeres eszközeredménye között három nagy, pontosan megismételt olvasási eredmény volt ugyanahhoz az eszközhíváshoz. A változatlan ismétlés 15 936 nyersbájtot foglalt el, pedig az aktuális modellnézethez csak a legújabb teljes másolat kell.
  • A vetítés ezért kizárólag sikeres, tiszta szövegeredményeket ismer fel, pontosan azonos eszköznévvel, pontosan azonos argumentumokkal és pontosan azonos tartalommal. A legújabb másolat teljes marad; a régebbi másolatokat csak a modellnézet cseréli rövid hivatkozásra.
  • A nyersfolyam, a módosított eredmények, a hibák, a médiák, a perzisztált hivatkozások és a kis eredmények változatlanok maradnak. A meglévő eszköz-kiszervezés előtte is érvényben marad; a deduplikálás csak a legújabb azonos másolathoz állíthatja vissza annak vetítését.
9.1.233
  • Egy valódi wire-ben egy teljes Write-hívást 2 357 UTF-8 bájttal elutasítottak a korábbi 2 048 bájtos határnál. Ezután az ágens ugyan megígérte a folytatást, de ugyanazt a tokenize.cjs fájlt többször felülírta hiányos töredékekkel, köztük kétszer bájtonként azonos módon az első 1 099 bájtot. Az érintett lépések egyenként körülbelül 64 000 bemeneti tokent hordoztak; egyes válaszok 10 319, illetve 7 015 tokent értek el.
  • A teljes fájlok 4 096 UTF-8 bájtig mostantól egyetlen atomi Write-hívással írhatók. A valós 2 357 bájtos eset nem igényel további modellmenetet.
  • A nagyobb hívások a teljes folytatási protokollban maradnak. Egy ilyen elutasítás után az útvonal lezárul: a kisebb normál write-ok már nem írhatják felül a célfájlt résztöredékekkel. Csak egy érvényes folytatás veszi át az útvonalat; a cél a végső igazolásig változatlan marad.
9.1.232
  • Az automatikus resume mód egy valós ágensprofilban be volt állítva, de a telepített változat 9.1.221-en állt, az aktív előkészített futásidejű környezet 9.1.219-en, az npm/manifest pedig már 9.1.231-en. Futó King nélkül a korábbi háttérútvonal nem tudott elmaradt verziót előkészíteni.
  • A resume és a new ezért a következő természetes hidegindításkor is ellenőrzi, van-e legalább 30 perce stabil, függetlenül aláírt release-változat. Az a védett release-tárhelyen készül elő, pendingként lesz megjelölve, és második indítás vagy választási ablak nélkül indul.
  • A manual és az off változatlan marad. Ha az előkészítés, az integritás, a csomagpróba vagy a hálózati lekérés kudarcot vall, a meglévő indítási útvonal tovább fut. Egy már futó munkamenetet ez a hidegindítási útvonal soha nem állít le.
9.1.231
  • Egy valódi wire-ben egy Telegram-válasz a küldés előtt meghiúsult a 400: Bad Request: can't parse entities: Can't find end of Italic entity hibával. A hívás kifejezetten format: markdownv2 beállítást használt; az 1 szövegrészből 0 lett kézbesítve.
  • A Telegram-MCP-küldés mostantól csak az érintett szövegrészt ismétli meg pontosan egyszer, egyszerű szövegként, ha a Telegram pontosan egy entitáselemzési hibát jelez. A csevegés, a válasz-hivatkozás, a részhatár és a követő mellékletek megmaradnak.
  • A hálózati hibákat, az ismeretlen csevegéseket, a jogosultsági hibákat és a már egyszerű szövegként elküldött hívásokat ez a fallback nem ismétli. Így sem tetszőleges hibát nem nyel el, sem egy sikeres részt nem küld kétszer.
9.1.230
  • A 9.1.228-cal és a 9.1.229-cel már javított korábbi hibák kizárása után egy ágensprofil utolsó 1 200 eszközeredményében az ismétlődő Bash-időtúllépések maradtak a következő zárt blokkként. Az érintett parancsok többször végigkeresték a teljes felhasználói könyvtárat vagy a teljes Dropboxot rekurzívan, és 60 másodperc után használható befejezés nélkül értek véget.
  • A Bash mostantól a folyamatindítás előtt pontosan két korlátlan keresési formát utasít el: a find parancsot a teljes felhasználói könyvtárra, és a rekurzív grep parancsot a . könyvtáron.
  • A hibaüzenet azonnal megnevezi a korlátozott alternatívát: Glob rögzített fájlmintával, Grep elérési úttal/globbal, vagy egy ismert projekt-almappa. A kifejezetten src, test vagy más megnevezett részfára korlátozott keresések változatlanul engedélyezettek maradnak.
  • Az időtúllépést nem növelték, és tetszőleges Bash-parancsokat nem ismételnek automatikusan. Így sem hosszabb várakozási idő, sem az író parancs kétszeri végrehajtásának kockázata nem keletkezik.
9.1.229
  • A Deferred-Tool-javítás után a legnagyobb összefüggő hibacsalád egy valódi folyamban a többrészes Write volt: hiányzó kötelező mezők (part, start_line, final), előre hibásan tippelt teljes sorszám, elavult részszámok és a hibák után még aktív régi folytatási állapot ismétléseket eredményezett hasznos munka nélkül.
  • A részszám, a kezdősor és a mód mostantól a ténylegesen stagelt állapotból származik, ha hiányoznak. A kifejezetten elküldött értékek láthatók maradnak, és eltérés esetén továbbra is elutasítja őket a rendszer.
  • Az expected_lines opcionális, és csak a záró részben adható meg. Ha meg van adva, a túlcsordulás és a pontos záróellenőrzés változatlanul fail-closed marad.
  • A final=true a befejezéshez továbbra is kötelező. E kifejezett zárójelölés nélkül semmi sem íródik; a célfájl a befejezésig változatlan marad. Az opcionális SHA-256-ellenőrzés megmarad.
9.1.228
  • Az utolsó 1 000 valódi eszközeredményben 66 hiba volt. A legnagyobb, tisztán javítható egyes blokk 10 Tool not found hiba volt: kilencszer mcp__mnemo__mem_transcript_recent, egyszer mcp__mnemo__mem_question_answer. Mindkét eszköz regisztrálva volt, de a tokenkeret miatt az adott lépésben nem lett betöltve.
  • Egy pontos Tool "<name>" not found hiba után a menet mostantól megjegyzi ezt a sémát a közvetlenül következő lépéshez. A normál választás ezután a már regisztrált eszközlistából veszi fel.
  • Más hibaüzenetek, sikeres eredmények és eltérő eszköznevek nem változtatják meg az állapotot. A meglévő, négy sémára vonatkozó LRU-határ megmarad; egy valóban ismeretlen eszközt így nem találnak ki és nem hajtanak végre.
  • Nem került eszköz véglegesen minden promptba. A normál séma-tokenfogyasztás ezért változatlan marad; csak egy már kifizetett hibás ismétlés marad el a második kísérlettől kezdve.
9.1.227
  • Egy valódi wire-folyam 119 ToolSearch-hívást tartalmazott. Ebből 35 találat nélkül ért véget; 27 nulltalálat a Telegram-előzményeket, az üzenetlekérést vagy a hozzá tartozó emlékkeresést érintette.
  • A 9.1.226 a jelenlegi eszközlistával már 8-at megoldott ebből a 35 régi nulltalálatból. A fennmaradó fő eset a túlhatározott lekérdezések voltak, mint a +telegram history messages lesen, ahol a modell a szemantikus szavakat tévesen kötelező névrészekként jelölte meg.
  • A DeepAgents-ből átvették az elvet, hogy az eszköz-utalásokat és az eszközfelületet a szűrés után összehangolják. Nem másoltak idegen kódot: a BLUN továbbra is először a pontos és szigorú keresést próbálja, és csak valódi nulltalálat után lazítja fel a + kifejezéseket szemantikus keresőkifejezésekké.
  • A visszalépés nem hajt végre eszközt. Csak a legjobban értékelt sémát, illetve a valódi holtversenyeket tölti be, több kifejezésnél legalább 75 százalékos találati arányt követel, és szakidegen kifejezéseknél zárt marad.
  • Összehasonlítás a frissen telepített 9.1.226-csomaggal és ugyanazzal a 35 korábbi lekérdezéssel: előtte 8 találat, utána 21 találat, vagyis 13 további valódi találat és 0 elveszett korábbi találat.
  • Nem került be új modell-, keresési, hálózati vagy beágyazási hívás. A nyersfolyam, az eszközvégrehajtás, a jóváhagyások és az állandó sémakészlet változatlan marad.
9.1.226
  • Egy valódi wire-folyam 6 275 befejezett modelllépést tartalmazott. Az utolsó 50 lépésben a helyi kérésfelépítés p50 0 ms és p90 1 ms, a helyi stream-felhasználás pedig p50 1 ms és p90 3 ms volt. Ezzel szemben az első szerver-tokenig tartó várakozási idő p50 11 842 ms és p90 14 846 ms volt. Egy további helyi mikro-teljesítmény-metszet így nem volt hatékony karként igazolva.
  • Az Evolverből származtatott, validált tanulási út már létezett: a pirosról zöldre váltó igazolások profilhoz kötötten pending, recorded vagy expired állapotban tárolódnak. A felhasználóknak azonban nem volt helyi rálátásuk rá.
  • A 9.1.226 hozzáadja a /improve parancsot a /learning álnévvel. A panel megjeleníti a három státuszszámlálót, és a legújabb nyitott jelöltnél csak korlátozott, veszélytelen igazolásadatokat: a jelölt-azonosítót, az eszköznevet és a parancs-hash tizenkét karakterét.
  • A parancs csak az aktív profil helyi tárolóját olvassa. Nem indít modell-, keresési, hub- vagy beágyazási hívást, és nem változtat meg jelöltet. Az ismeretlen státuszértékeket és a nem biztonságos megjelenítési karaktereket eldobják, illetve unknown-ként jelenítik meg.
  • Minden új UI-szöveg németül, spanyolul, franciául, svédül és csehül átment a kötelező nyelvi kapun és az azt követő receipt-ellenőrzésen; mind a hat UI-katalógus tartalmazza a teljes kulcsokat.
9.1.225
  • Egy valódi wire-folyamban 88 config.update bejegyzés 4 078 566 bájtot foglalt el. Közülük 83 a teljes rendszerpromptot hordozta.
  • A prompt stabil munkamenet-időbélyeget deklarált, de minden folyamatindításkor újra beállította. Az időbélyeg normalizálása után 45 szemantikus változat és 38 egymást követő, kizárólag az új időbélyeg által okozott ismétlés maradt.
  • Ez a 38 ismétlés 781 179 bájtot foglalt el, vagyis a mért konfigurációs események összes rendszerprompt-bájtjának 19,16 százalékát. Ezzel együtt az újrahasznosítható szolgáltatói prompt-előtag szükségtelenül megváltozott az újraindítások után.
  • A 9.1.225 a friss és a folytatott fő- és alágensek időbélyegét a Session.metadata.createdAt értékhez köti. Az érvénytelen régi metaadatok védekezően a korábbi in-memory értékre esnek vissza.
  • A nyersfolyam, a prompt tartalma, az eszközök, a modellválasztás és a tömörítés változatlan marad. Nincs további modell-, keresési vagy beágyazási hívás.
9.1.224
  • A legutóbb mért indítás az öt MCP-szerver párhuzamos inicializálásához 16,85 másodpercet igényelt. A munkamenet-folytatás és a wire-elemzés lényegesen kevesebb időt vett igénybe: körülbelül 0,55, illetve 0,18 másodpercet.
  • A menet-útvonal eddig minden kérés előtt várt erre az MCP-inicializálásra, még akkor is, ha egy helyi, puszta köszönés utána szándékosan nulla eszközt kapott a modellkérésben.
  • A 9.1.224 a DeepAgents-egyeztetésből veszi át az igény szerint betöltött eszközhatárt: csak a helyi, eszközmentes rövid beszélgetés válaszolhat azonnal. A Telegram-menetek, a mellékletek, a rendszer-eseményindítók és minden munkajellegű kérés továbbra is a teljes MCP-inicializálásra várnak.
  • A nyersfolyam, az MCP-konfiguráció, az eszközsémák és a normál munka-menetek változatlanok maradnak. Nem kapcsoltak ki szervert, és nem vezettek be további modell-, keresési vagy beágyazási hívást.
9.1.223
  • Egy 775.5-ös lépés üresen ért véget fall=length értékkel, a 8 192 befejezési tokenből mind a 8 192 felhasználásával és mindössze hét karakternyi reasoninggel. A korábbi logika ezután ugyanazt a nagy kérést indította újra, és a befejezési keretet 16 384 tokenre duplázta.
  • A helyi CPU a várakozási idő alatt körülbelül 0 százalékon állt; a kérésfelépítés 0–1 ms-ig tartott, a szállítás pedig körülbelül két másodpercig. A mért szűk keresztmetszet így a modellgenerálás plusz a teljes keretes újrapróbálás volt, nem a TUI.
  • Mostantól csak az igazolt eset – length + teljesen kimerített keret + 64 karakternél kevesebb reasoning – kap takarékos újrapróbálást 0,125-ös szorzóval és legalább 1 024 tokennel.
  • A reasoning-igényes és nem teljesen kimerített length válaszok megtartják a korábbi, 2-es szorzójú bővítést. A többi újrapróbálási osztály változatlan marad.
  • Egy mért esetben a második keret 16 384-ről 1 024-re csökken: 15 360 token, vagyis 93,75 százalékkal kevesebb az újrapróbálásban.
9.1.222
  • A futó frissítő egy előkészített verziót IPC-n keresztül adott át az aktív King-nek. A launcher ezután leállította a futó magot a 76-os kilépési kóddal, és egy helyettesítő folyamatot kellett volna indítania. A mért 9.1.219-re váltásnál egy ágensprofil így kijelentkezve maradt.
  • A háttérfrissítések mostantól csak letöltik és ellenőrzik az új verziót, és a következő természetes indításhoz tárolják. Nem küldenek restart-IPC-üzenetet, nem állítanak le aktív TUI-t, és nem indítanak helyettesítő folyamatot.
  • A következő normál king indításkor újra megjelenik a meglévő választás: frissítés, egyszeri kihagyás vagy várakozás a következő release-ig. Csak a telepítési döntés után indít a launcher a már ellenőrzött, előkészített csomagból; egy második letöltés elmarad.
9.1.221
  • A változatlan, a tokenCount által még nem lefedett üzenetek mostantól pontosan egy token-becslést használnak kontextusrevíziónként. Az ismételt státusz- és megjelenítési hozzáférések nem szkennelik újra ugyanazokat a növekvő előzményeket.
  • Az új szövegrészek, az eszközhívások, a történet-változtatások, a tömörítés, az undo és a már lefedett üzenetek számának megváltozása azonnal érvényteleníti a gyorsítótárat. A nyersfolyam, a perzisztált folyam és a jelentett tokenérték azonos marad a korábbi útvonallal.
  • Hét mérési futás 300 szintetikus üzenettel és egyenként 250 változatlan lekérdezéssel a mediánban 42,1218 ms -> 0,1755 ms eredményt adott, körülbelül 99,583 % kevesebb számítási idővel ebben a hotpath-ban. Mindkét változat pontosan ugyanazt a 127.838 tokent becsülte.
  • A release csökkenti a CPU-munkát a helyi becsléshez. Nem állítja, hogy csökkenti a modellnek ténylegesen elküldött bemeneti tokeneket.
9.1.220
  • A hosszú asszisztens-válaszok vetítése mostantól egy WeakMap tárolóban menti az eredményét, amíg az üzenetobjektum, a tartalomtömb, a szövegrész és a pontos forrásszöveg változatlan marad. A nyersfolyam és a vetített tartalom azonos marad a korábbi útvonallal.
  • A szöveg, a tartalomtömb vagy a szövegrész megváltozása azonnal eldobja a bejegyzést. A különböző üzenetobjektumok nem osztoznak gyorsítótáron.
  • Öt mérési futás egyenként 1000 ismétlés-vetítéssel a mediánban 16,489 ms -> 0,202 ms eredményt adott, körülbelül 98,8 % kevesebb számítási idővel ezen az útvonalon. Mindkét változat pontosan 21.206 karaktert spórolt meg.
9.1.219
  • A puszta rövid szöveges megerősítések, mint az ok, a danke vagy a végükön folytatásjelzést tartalmazó Telegram-DM-válaszok már nem olvassák a validált tanulási jelöltek tárolóját minden modell-lépésnél.
  • A jelentőségteljes promptok, a mellékletek és az aktuális eszközaktivitással járó menetek továbbra is szinkronizálnak. Egy már látható tanulási emlékeztető egy kihagyott megerősítés közben is megmarad.
  • A becsomagolt tényleges mérés 50 megerősítésen 50-ről 0 jelölt-könyvtár-olvasásra csökkent. A jelentőségteljes ellenpróba pontosan egyszer olvasott. Nem adódott hozzá modell-, beágyazási vagy hálózati hívás.
9.1.218
  • Ugyanez a pirosról zöldre váltó ellenőrzés a 9.1.217 verzióban egy új eszközhívás-azonosítós ismétlésnél egy második nyitott jelöltet hozott létre. Az elszigetelt tényleges mérés két azonosítót, 2 nyitott fájlt és 726 bájtot eredményezett.
  • Ha csak a legújabb jelöltet rögzítették volna, a régebbi azonos jelölt újra emlékeztetőként jelent volna meg. Ez egy második emlékeztető- és MistakeRecord-ciklust hozott volna létre ugyanahhoz a nyitott leckéhez.
  • A bin/validated-learning-signal.cjs mostantól újra felhasznál egy már nyitott, azonos profilú és azonos commandHash jelöltet. Más ellenőrzési parancsok külön maradnak; a rögzített vagy lejárt jelöltek nem nyelnek el későbbi eseményt.
  • Az utómérés ugyanazt az azonosítót, 1 nyitott fájlt és 363 bájtot eredményezett. Nincs további modell-, beágyazási vagy hálózati hívás.
9.1.217
  • A 9.1.216 verzióban minden sikeres MistakeRecord a legújabb nyitott tanulási jelöltet jelölte meg feldolgozottként, akkor is, ha a bejegyzés más hibához tartozott. A bizonyíték így tartós volt, de nem pontosan korrelált a későbbi rögzítésével.
  • A bin/validated-learning-signal.cjs mostantól beolvassa az opcionális candidateId értékét egy sikeres MistakeRecord-nál, és kizárólag a pontosan illeszkedő nyitott jelöltet zárja le. Hiányzó, hibás vagy idegen azonosító esetén minden nyitott jelölt változatlan marad.
  • A blun.mjs megnevezi a stabil jelölt-azonosítót a látható emlékeztetőben, és a candidateId értéket opcionális mezőként vezeti be a MistakeRecord sémájában. Nincs további modell-, beágyazási vagy hálózati hívás.
  • A korreláció profilhoz kötött marad. A jelölt-tárba továbbra sem kerülnek sem nyers parancsok, sem eszközkimenetek.
9.1.216
  • A bin/validated-learning-signal.cjs a megerősített pirosról zöldre váltó jeleket mostantól telepítésszinten a <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/ alá helyezi. Így egy tanulási jelölt megmarad a felhasználói menetek, a tömörítések és ugyanazon BLUN-telepítés különböző portáljai között.
  • A tár profilhoz kötött, append-only és konkurenciabiztos: jelöltenként egy megváltoztathatatlan JSON-fájl és pontosan egy .recorded vagy .expired marker jön létre. A temp-fájl, a hardlink és a temp-fájl eltávolítása megakadályozza a csendes felülírást párhuzamos íróknál.
  • Csak a típus, a státusz, a profil, az eszköznév, a parancs SHA256-értéke, az eszközhívás-azonosítók és az időbélyegek tárolódnak. A nyers parancs, a hibaüzenet és a sikeres eszközkimenet nem perzisztálódik.
  • Egy sikeres MistakeRecord pontosan egyszer jelöli meg a legújabb nyitott jelöltet feldolgozottként. A nyitott jelöltek 24 óra után lejárnak. Ha nincs közös home, a korábbi in-memory viselkedés fail-open módon marad fenn.
  • Ez még nem automatikus kódmódosítás és nem saját magának adott jóváhagyás. A release csak a hordozható, portáltól független tanulási bizonyítékot hozza létre, amelyre a későbbi beépített evaluator- és approval-funkciók biztonságosan építhetnek.
9.1.215
  • A megoldások nem feltételezhetnek sem bizonyos belső ágenseket, sem belső számítógépneveket, Telegram-csoportokat, Mnemo-példányokat vagy BLUN-belső jóváhagyási láncot.
  • A Self-Improvementhez a belső szerepek termékfunkciókként absztrahálódnak: scope-/jóváhagyás-vezérlő, izolált evaluator, verziózott bizonyíték és automatikus canary-visszamérés rollbackkel.
  • Automatikusan csak az alacsony kockázatú, mérhetően korlátozott módosítások vehetők át, és csak kivétel nélkül jobb vagy semleges próbák mellett. A kód, a jogok, a titkok, az elszámolás és az éles környezet továbbra is felhasználói vagy adminisztrátori jóváhagyáshoz kötött.
  • A beépített kapu első megvalósítását belsőleg, kézzel veszik át; ezután a kapu maga ellenőrizhet, de nem módosíthatja a saját biztonsági határát.
9.1.214
  • A 9.1.213 létrehozta a helyes tartós tárolási utat a MistakeRecord révén, de továbbra is azt várta, hogy a modell egyedül, az eszköztörténetből ismerje fel a megfelelő pillanatot.
  • Új a bin/validated-learning-signal.cjs: a modul csak az aktuális felhasználói menetet vizsgálja, és kizárólag ugyanazt az ellenőrző shell-parancsot ismeri fel, amely először meghiúsul, később pedig sikeres.
  • Egy dinamikus injector a blun.mjs fájlban ebben az igazolt esetben arra emlékeztet, hogy egy újrahasznosítható leckét MistakeRecord segítségével rögzítsen. A parancsszöveg és a nyers hiba nem kerül a megjegyzésbe.
  • Más parancsok, normál olvasási-/eszközhibák, egy új felhasználói menet vagy egy már sikeres MistakeRecord-hívás nem hoznak létre, illetve nem tartanak meg megjegyzést. Automatikus tárolás nem történik.
9.1.213
  • A küldetésszerződés egy sikeres pirosról zöldre váltó próba után a record_error_memory hívást követelte. Ez az eszköz nem létezik a King-csomagban. A meglévő tartós tanulási út neve MistakeRecord, és a közös Mistake.md fájlba ír.
  • Emiatt az Evolverből átvett fegyelem már meg volt fogalmazva, de az utolsó lépés a saját, ágenseken átívelő emlékezetünk felé nem működött: egy megerősített megoldás követhette a szerződést, és mégsem lehetett tartósan tárolni.
  • A szerződés mostantól a zöld ismétlő futás után MistakeRecord hívást indít. A nyers hibák továbbra is kívül maradnak; csak a sikeres ellenfutással megerősített lecke tárolódik.
  • A Mistake.md fájlt, annak relevancia-kiválasztását és tárolási formátumát nem cserélték le és nem változtatták meg. Kizárólag a validált tanulási szerződés és a meglévő eszköz közötti kapcsolatot javították meg.
  • Csak a blun.mjs, az új struktúrateszt test/validated-learning-route.test.js és a package.json verziója változott.
9.1.212
  • Az ErrorMemory-injektor tiszta köszöntésekhez és rövid megerősítésekhez is több stratégiai gént formázott. A Mistake.md és a személyes emlékezet ugyanahhoz az üzenetosztályhoz már közös relevanciahatárt használt; csak az ErrorMemory kerülte meg.
  • Az injektor mostantól szintén az isLowInformationMistakeTurn függvényt használja, és a vetítést a stratégiai gének kiválasztása és formázása előtt fejezi be. A perzisztált hiba- és stratégiai bejegyzések változatlanok maradnak; csak a felesleges vetítésük marad el a legkisebb kérésekben.
  • Mért referenciaeset Wie geht es dir? tizenegy elmentett bejegyzéssel: előtte öt kiválasztott szabály, 1.417 karakter, illetve körülbelül 355 token; utána 0 karakter és 0 token.
  • Csak a blun.mjs, a test/error-memory-performance-policy.test.js és a package.json verziója változott.
9.1.211
  • A King csak akkor nyugtázza a sorban álló üzeneteket, ha az üzenetet elfogadták. Aktív munkamenet előtt az injectChannelEnvelope egy címzett üzenetet azonban dropped állapotúként eldob, anélkül hogy nyugtázná vagy parkolná. Így a checkpoint véglegesen pontosan ennél az első sornál állhat meg.
  • Valódi piros próba _proof/telegram-profile-checkpoint-red.cjs: várt queued, mért dropped, kilépés 1.
  • Ugyanez a hiba a Telegram-parancs útvonalán van: a /loop aktív munkamenet előtt nem kerül a queuedMessages sorba; az acknowledge-függvény fogyasztó nélkül marad. Valódi piros próba _proof/telegram-remote-command-presession-red.cjs: várt sorhossz 1, mért 0, kilépés 1.
  • Az injectChannelEnvelope egy még nem kézbesítésre kész munkamenetet mostantól foglalt munkamenetként kezel: a modellszöveg, a megjelenítési eredet és a későbbi nyugta a meglévő csatorna-várakozási sorban marad.
  • Az injectTelegramRemoteCommand a munkamenet-ellenőrzés előtt építi fel a sorbejegyzést. A /loop és a többi közvetlen Telegram-parancs hiányzó munkamenet esetén a channelAcknowledge függvényükkel parkol, és csak a meglévő biztonságos határon fut le.
  • A sorrend és a meglévő checkpoint-szabály változatlan marad: egy sor elemet csak az elfogadás után nyugtáznak; a későbbi nyugták nem ugorhatnak át egy előtte még nyitott sort.
9.1.210
  • A 9.1.208/9.1.209 aktív handoffja leállíthatta a futó King-et egy frissítéshez. Az MSI-n emiatt a futó munkamenet a 9.1.206 -> 9.1.207 váltásnál leállt, és nem folytatódott automatikusan.
  • A 9.1.209 ezért nem került a nyilvános manifestbe, és az npm-en nem kiadhatóként jelölték meg.
  • Az előírás mostantól technikailag kikényszerített: egy automatikus frissítés soha nem állíthatja le a futó King-et. Csak letöltődik, és pending állapotúként előjegyzik. Az aktiválás csak egy későbbi normál indításkor történik.
9.1.209 Visszavonva
  • Nem tették közzé. Az aktív frissítési handoff leállíthatta a futó King-et; ezért a verzió nem került a nyilvános manifestbe, és az npm-en nem kiadhatóként jelölték meg.
9.1.208
  • Az MSI-n egy nap alatt 27 King-indítást és 15 verzióállapotot mértek. Az újraindítások verzióugrásokkal estek egybe; külön kilépési okot a helyi napló továbbra sem rögzít.
  • A frissítő percenként készített elő új manifest-verziókat. A 9.1.208 ezért bevezet egy 30 perces nyugalmi ablakot, mielőtt egy újabb futásidejű környezet aktiválódhat.
  • A régi futásidejű állapotokat sikeres aktiválás után a legújabb három verzióra korlátozzák. A törlés csak akkor történik, ha a régi állapot összes telepítési lease-ét kizárólagosan megszerezték. Az aktív, foglalt vagy ismeretlen elrendezések érintetlenek maradnak.
  • A védelmi logika az újonnan betöltött magban is él. Így az automatikus aktiválás után akkor is működik, ha az állandó szülő-launcher még egy régebbi verzióból származik.
  • A nyolc mért MSI-release-állapot együtt csak 778 MB-ot foglalt el. Nem magyarázzák a majdnem teljesen megtelt 454 GB-os lemezt; a nagy fogyasztó külön, nyitott megállapítás marad.
9.1.207
  • A sikertelen telemetria ismétléseit futtatásonként a 16 legrégebbi fájlra korlátozzák, és az első átmeneti szerverhibánál megállnak, ahelyett hogy a teljes hátralékot feldolgoznák.
  • A hibagyűjtő a legújabb 512 fájlt tartja meg 16 MiB-on és hét napon belül. A normál events.jsonl kifejezetten ki van zárva a takarításból.
  • A release előtt valósan 4 248 hibafájl volt 11 631 974 bájttal. Az automatikus aktiválás után 512 fájl volt 2 260 908 bájttal: 3 736 régi hibafájl és körülbelül 9,37 MB terhelés kevesebb.
9.1.206
  • A már archivált nagy asszisztensválaszokat a hurok-vetítés előtt mostantól a korlátozott, újraolvasható archívum-hivatkozásuk váltja fel. Így egy későbbi szövegtisztítás már nem teheti érvénytelenné az elmentett hash-t.
  • Három valódi archív fájlt bájtpontosan vetettek össze az elmentett SHA256-üzenethash-ekkel: 38.567, 13.941 és 24.787 karakter, mindegyik meglévő és mindegyik pontosan illeszkedő.
  • Pontosan ugyanazon 41.480 wire-bejegyzésen 311 üzenettel a modellvetítés 87.724-ről 63.234 karakterre csökkent: további 24.490 karakterrel, illetve körülbelül 6.123 bemeneti tokennel kevesebb érintett hívásonként.
  • A nyers történet és a teljes privát archív fájlok változatlanok maradnak, és az elérési útjukon át lapozhatóan olvashatók.
9.1.205
  • A válaszhurkokat egy asszisztensüzeneten belül mostantól kisebb írásjel- vagy szóalak-eltéréseknél is felismerik. Egy klaszterhez legalább három találat kell konzervatív hasonlóságnál 0,88; az első változat megmarad, a nyers történetet nem változtatják.
  • Egy megőrzött esetben egy valós hurkoló válasz 24.787-ről 22.711 karakterre csökkent: 2.076 karakterrel, illetve körülbelül 519 bemeneti tokennel kevesebb.
  • A kódkerítések bájtpontosan védettek maradnak. Az eszközelbeszélés, az injekciók, a párok és az 1.000 karakter alatti megtakarítások változatlanok maradnak.
9.1.204
  • A hibára emlékeztető munkavégzési körönként már nem tölti be vakon mind a tizenegy szabályt. A négy nélkülözhetetlen bizonyítási és ellenpróba-szabály, 4, 9, 10 és 11, mindig aktív marad; legfeljebb két további szabályt adnak hozzá determinisztikusan az aktuális feladathoz igazítva.
  • A valódi kiszállított szabálygyűjteményben az ismételt blokk 2.442-ről 1.272 karakterre csökkent: 1.170 karakterrel, illetve körülbelül 293 bemeneti tokennel kevesebb érintett munkavégzési körönként.
  • A kiválasztás nem hoz létre modell-, keresési, reranker- vagy beágyazási kérést. A kis saját szabálygyűjtemények teljesek maradnak; szelektorhiba esetén továbbra is a korábbi teljes blokk lép érvénybe.
9.1.203
  • Egy üres ToolSearch mostantól sikeresen lezárt nulleredmény, nem piros eszközhiba. A válasz megnevezi a hiányzó jogosult eszközt, és megtiltja az ismétlést szinonimákkal.
  • A mért folyamban 32 üres keresés állt 29 megfogalmazással; egy megőrzött menetben ugyanazt a hiányzó Telegram-képességet a piros hiba után közvetlenül egy második kereséssel kérdezték újra.
  • Nincs további modell-, reranker- vagy beágyazási kérés, nincs új rezidens séma, és nincs változtatás az eszközökön vagy az engedélyeken.
9.1.202
  • A DeepAgents-ből származtatott helyi kontextus-vetítés nagy munkakönyvtáraknál előnyben részesíti a legfelső szintű bejegyzéseket a néhány első mappa mély részletei helyett. A kis könyvtárlisták bájtpontosan azonosak maradnak.
  • Egy ágens-gyökér 509 legfelső szintű bejegyzést tartalmaz (89 mappa, 420 fájl). Korábban a modellvetítés 1.981 karakterben csak 9 legfelső szintű mappát mutatott; most 30-at mutat 832 karakterben.
  • Mért megtakarítás: 1.149 karakter, illetve körülbelül 287 token kérésenként. A persona, a munkaszabályok, a nyers történet és az eszközelérés változatlan marad.
9.1.201
  • Egy DeepAgents-ből származtatott vetítési higiénia tömöríti a statikus hibamemóriát anélkül, hogy a 11 elmentett szabály vagy ellenőrzés közül bármelyik elveszne.
  • A régi, részletes hibamemória-szövegeket csak a modellvetítésben tömörítik. A nyers történet, a normál válaszok és az eszközeredmények változatlanok maradnak.
  • A vetítésben mindig csak a legújabb hiba- és hibajavítás-betáplálás marad meg.
9.1.200
  • Az új helyi parancs, a /context, külön mutatja a ténylegesen vetített modellkérést, az elmentett beszélgetéstörténetet, az eszközsémákat, a tömörítési keretet és a fennmaradó mozgásteret.
  • A nézet kizárólag a session.getContext() értéket olvassa. Nem indít sem modellkérést, sem kezelt fogyasztás-lekérdezést, sem szolgáltatást, sem újraindítást.
  • A kiszervezett eszközeredmények mostantól pontos újraolvasási utat neveznek meg: Read legfeljebb 20 sorral, majd folytatott line_offset értékkel. Ez megakadályozza a mért formát, amelyben egy ágens ugyanazt a nagy területet újra Read, Grep és Bash használatával kérte.
  • A /premortem már a 9.1.200 előtt is létezett, és kifejezetten nem tüntetik fel e release új funkciójaként.
  • Új fordításokhoz a kötelező nyelvi kapu a hiányzó független rövid szöveg-ellenőrzés miatt nem adott jóváhagyást. Ezért a /context csak a már jóváhagyott lokalizált elnevezéseket használja; nem került be ellenőrizetlen célszöveg.
9.1.199
  • Egy aktuális modellnézet egyetlen asszisztensválaszban 13 941 karaktert tartalmazott 100 bekezdésblokkal. Csak 20 blokk volt egyértelmű; hat csoport pontosan ismétlődött, és 9 579 karaktert foglalt el.
  • A 9.1.199 kizárólag az ilyen pontos ismétlődéseket tömöríti egyetlen tisztán szöveges válaszon belül a modellnézetben. A nyers munkamenet-folyam változatlan marad.
  • A tömörítés csak három pontos ismétlődéstől és legalább 1 000 megtakarított karaktertől lép érvénybe. A kódblokkok, a vegyes tartalmak, az eszközhívások, az injekciós üzenetek, a rövid blokkok és a kisebb megtakarítások változatlanok maradnak.
  • Ez a DeepAgents-elvet követi: az újraolvasható igazság megmarad, és csak az aktív modellnézet terhelése csökken. Nincs további modell- vagy beágyazási hívás.
9.1.198
  • Egy aktuális folyam egy, az eszköz által már truncated: true értékkel jelölt Grep-eredményt tartalmazott 50 042 karakterrel. Az egyes eredmények kiszervezése felismerte ugyan a méretet, de egy korai visszatérés miatt az ilyen eredményeket mégis teljesen a modellnézetben hagyta.
  • A 9.1.198 kizárólag ezt a kivételt távolítja el. Egy levágott Read a meglévő forrásútvonalat használja duplikátum nélkül; a többi levágott eredmény pontosan a teljes, az eszköz által visszaadott szöveget archiválja.
  • A hivatkozás megtartja a truncated: true értéket, és stored_result_scope: tool_truncated_output jelölést hordoz. Így nem állítják azt, hogy helyreállították volna az eszköz által soha le nem adott nyers kimenetet.
  • A minta a DeepAgents-et követi: a nagy eszközkimenetek az aktív modellnézeten kívül újraolvashatók maradnak, míg ott csak egy kis hivatkozás marad.
9.1.197
  • Még a puszta szöveges megerősítések is, mint az ok, eddig betöltötték a dinamikus Mistake.md-emlékeztetőt. Az aktuális közös szabályállománynál ez 1 819 promptkarakter volt, körülbelül 455 token, pedig semmilyen munkakontextus nem folytatódott.
  • A 9.1.197 kizárólag az információszegény, tisztán szöveges meneteket ismeri fel, mielőtt a két Mistake-forrás bármelyikét olvasná, és ott elhagyja a dinamikus injekciót.
  • A mellékletek, a nem szöveges tartalmak és az értelmes folytatások, mint az ok, check updater, megtartják a korábbi utat. A meglévő relevancia-visszalépés a valódi munka-menetekhez változatlan marad.
  • A minta az AnythingLLM-összehasonlító munkából származik: az opcionális kontextusforrások csak akkor kerüljenek a modellnézetbe, ha az aktuális menet tényleg igényli őket. További modell- vagy beágyazási hívás nélkül illesztették a meglévő BLUN-policyba.
9.1.196
  • A /reload helyben létezett, de Telegram-ról nem ismerték fel közvetlen parancsként. A Telegram-allowlist nem tartalmazta a nevet; így az üzenet normál modellszöveg maradt.
  • A 9.1.196 kizárólag a reload értéket adja hozzá a meglévő címzett Telegram-parancslistához.
  • A Telegram-út ugyanazt a meglévő handlert használja, mint a helyi TUI: a munkamenet, az MCP-szerverek, a futásidejű és TUI-konfiguráció újratöltődik a futó folyamatban. Nem indul sem modellkör, sem folyamat-újraindítás.
  • A /new és a többi nem jóváhagyott slash-üzenet továbbra is normál modellszöveg marad.
9.1.195
  • Az automatikus frissítések lefutottak, de az újraindított TUI a korábbi projektmappa helyett a C:\ meghajtón landolt.
  • A TUI a helyes mappát vezette a state.appState.workDir értékben, de a frissítési handoffnál csak a munkamenetet, a verziót és a módot adta át. A launcher ezért az eredeti indítási mappáját használta célhoz és visszalépéshez.
  • A 9.1.195 az aktív projektmappát szállítja a handoffban, és azt használja a célverzióhoz, a visszalépéshez és ugyanazon felügyelet további automatikus frissítéseihez.
  • Csak meglévő, abszolút könyvtárakat fogad el. A relatív, hiányzó vagy fájlokra mutató megadások a launcher-mappára esnek vissza.
9.1.194
  • A meglévő menet-őrszem 20 perc után figyelmeztetett, de utána nem állította le a menetet. A Macen egy befagyott menet a 30 perces figyelmeztetés után legalább a 39. percig futott.
  • A 9.1.194 megtartja a 20 perces figyelmeztetést, és egy menetet 30 perc után valódi előrehaladás nélkül leállít.
  • A lépéskezdés, a thinking-szöveg, az asszisztensszöveg, az eszközhívás, az eszközargumentumok, az eszköz-előrehaladás és az eszközeredmény visszaállítják az inaktivitási határidőt. A hosszú aktív munka így nem áll le.
  • A meglévő megszakítás öt azonos, sikertelen eszközhívás után külön és változatlanul aktív marad.
9.1.193
  • Több Telegram-kézbesítés azonos chat_id és message_id értékkel akár négyszer is érkezett ugyanabban a munkamenetben.
  • A 9.1.181 ezeket az ismétlődéseket csak később távolította el a modellnézetből. Előtte minden másolat saját modell-menetet és ezzel költséget indíthatott.
  • A 9.1.193 ezért a menet kezdete előtt egy 2 048 azonosítóra korlátozott kézbesítési főkönyvet vezet be. Ugyanaz a Telegram-azonosító munkamenetenként csak egyszer fogadják el; az ismétlődéseket nyugtázzák, de nem naplózzák, és nem indítanak szolgáltatói menetet.
  • Az új üzenetazonosítók, a nem felhasználói injekciók és a nyers folyam változatlanok maradnak. Folytatáskor a főkönyv az elfogadott prompt-adatkészletekből áll helyre.
9.1.192
  • Egy Mac egy elutasított Bash-jóváhagyás után továbbra is King is thinking értéket mutatott 39 percig. Magát az eszközhívást helyesen utasították el, de az elutasítást közönséges hibaeredményként adták vissza a futó modellhuroknak.
  • A PermissionManager.requestToolApproval() elutasításnál csak block: true értéket adott. A meglévő batch- és szolgáltatóvezérlés már le tudta állítani a menetet a syntheticResult.stopTurn = true értékkel, de ezt a jelet nem kapta meg.
  • Új a bin/approval-rejection-stop.cjs. Az elutasított és megszakított jóváhagyások mostantól meglévő hibaeredményt hoznak létre stopTurn: true értékkel. Az aktuális menet véget ér, és ugyanazon eszközköteg későbbi hívásait kihagyják. A jóváhagyási napló, a policy és a fail-closed viselkedés változatlan marad.
  • A DeepAgents megerősítette a kifejezett emberi megszakítási határt megfelelő mintaként. Az AnythingLLM és az Evolver ehhez a szűk hibához nem kínált erősebb mechanizmust, mint a már meglévő BLUN-szerződés.
9.1.191
  • A DeepAgents a /context paranccsal ismerős, látható felosztást kínál a kontextusablakhoz, nem csak egy összértéket.
  • Az Evolver a teljesítménymunkához külön promptkeretet követel a rendszerrészhez, a beszélgetéshez, az eszközökhöz és a szabad térhez.
  • Az AnythingLLM beágyazás-alapú rerankolással takarít meg eszközsémákat. A BLUN ehhez már rendelkezik az olcsóbb, halasztott eszközúttal, további modell- vagy beágyazási hívás nélkül; ezt a részt ezért nem duplikálták.
9.1.190
  • A tartósan elmentett tool.call loop-eseményekből csak a megjelenítési mezőket, a display és a description mezőt távolítják el. Az azonosság, az eszköznév, az argumentumok és a lépés-hozzárendelés megmarad.
  • A futásidejű környezet továbbra is a teljes eseményt dolgozza fel. A TUI-megjelenítést, az eszközvégrehajtást és a folytatást nem állították át a vetítésre.
  • Egy valódi ágens-wire 42.451.368 bájttal 6.135 eszközhívást tartalmazott. Ebből 5.679 esetben 3.125.874 bájt eshetett el: a teljes wire-protokoll 7,36 %-a.
9.1.189
  • Egy felhasználó a bosnyákot választotta és bosnyákul írt, King mégis szlovénul válaszolt. A persona-promptban csak az angol Bosnian szó állt; a szorosan rokon nyelvterület nem volt kifejezetten elhatárolva.
  • A Kako si?, a Kako je King?, a Ko si ti? és a Ko stoji iza tebe? nem futottak önálló bosnyák rövid párbeszédként. A Ko stoji iza tebe? képernyőképe még webkereséseket is mutatott közvetlen válasz helyett.
  • A jelentett egyszerű bejelentkezés körülbelül 7.500 tokent fogyasztott. A korábbi alacsony erőfeszítésű út legfeljebb 8.192 befejezési tokent engedélyezett, és több régi üzenetet megtartott.
9.1.188
  • A BLUN egy valós visszaesést már három hasonló válasz után felismert, de az elavult válaszokat teljesen a modellnézetben hagyta. A hurok elleni figyelmeztetés így tovább versenyzett a régi hibás állapottal.
  • A DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 az indexstabil, korlátozott helyettesítő üzenetek mintáját adja. Az AnythingLLM a legfrissebb beszélgetéspárokat részesíti előnyben, és a történetet tekinti először tömöríthető kontextusnak.
  • Egy wire 42.265.671 bájtot tartalmazott, ebből 25.423.100 bájt context.append_loop_event volt. Ez igazolja a valós loop-terhelést, de nem közvetlen kérés-tokenmegtakarításként adják ki.
9.1.187
  • Az élőben kiadott 9.1.184 manifest a 2026-08-26T12:15:06.5196457Z időbélyeget hordozta. A kiadott parser csak egy-három tizedesjegyet engedélyezett, és ezért az egész manifestet eldobta.
  • Érvényes visszalépés nélkül egyedül az npm volt mérvadó. A 9.1.185 stagingjénél ezért az npm-tag rövid ideig látható volt, pedig a manifest még 9.1.184-en állt.
  • Az npm-tagot visszaállították 9.1.184 értékre. Az élő manifestet csak az időbélyegben javították 2026-08-26T12:15:06.519Z értékre; a verzió és az integritás változatlan maradt. Három cache-törölt lekérés és a valódi kliensparser ezután megerősítette a manifestet.
  • Élő SHA256 a javítás után: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Biztonsági másolat: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • Teljes tömörítés után a meglévő rendszerpromptot már nem írják felül újonnan beolvasott helyi kontextusadatokkal. A korábbi előtagja így bájtszorosan stabil és újrahasznosítható marad a szolgáltatói cache számára.
  • A munkakönyvtár, a hozzá illő AGENTS.md fájlok és a további könyvtárak ujjlenyomatot kapnak. Csak valódi változásnál fűzik hozzá az új állapotot belső, a felhasználó számára láthatatlan kontextusüzenetként.
  • A beágyazott kontextusadatok a belső jelölés előtt escape-elődnek. Egy helyi szöveg ezért nem zárhatja le a jelölési határt, és nem csempészhet be új rendszerutasításokat.
9.1.185
  • Két ágensprofil az automatikus frissítés időbeli környezetében jelentkezett ki. Ettől függetlenül egy harmadik profil a 9.1.182-ről 9.1.183-ra való sikeres átmenet után ezen a változaton maradt, és nem készítette elő a 9.1.184 verziót.
  • Két konkrét hibát igazoltak a forrásútvonalban: a TUI közvetlenül a process.send után befejeződött, anélkül hogy megvárta volna az IPC-megerősítést. Emellett a launcher sikeres handoff után csak az új folyamat végére várt, és nem állított be számára további frissítés-felügyeletet.
9.1.184
  • A közönséges modellhívások a GenerateImage és a GenerateVideo eszközsémáit állandóan magukkal vitték, pedig a mért eszközhasználat 3 183 hívás között csak egy kép- és nulla videóhívást tartalmazott.
  • A 9.1.184 mindkét sémát eltávolítja az állandóan betöltött magkészletből. Egy kifejezett kép-, videó- vagy animációs feladat csak a tényleg szükséges sémát tölti be ugyanabban a menetben.
  • Ugyanez a kiválasztási út érvényes akkor is, ha egy médiafeladat futó menet közben érkezik. A minőségi kérdések, a médiaellenőrzések és a későbbre szóló nem kötelező ötletek nem töltenek be generálási sémát.
  • Mindkét eszköz továbbra is elérhető marad a ToolSearch révén. A változtatás nem távolít el képességet, csak a ritkán szükséges sémákat helyezi át a közönséges modellhívásokból.
9.1.183
  • A BLUN King 9.1.183 ellenállóbbá teszi a kész médiák automatikus Telegram-kézbesítését az átmeneti feltöltési hibákkal szemben.
  • A kliens kizárólag korlátozott számú átmeneti hiba esetén próbálkozik újra, minden kísérletnél újraépíti a többrészes feltöltést, és tartós hibáknál azonnal megszakít.
  • A kimerített kézbesítési kísérleteket külön naplózzák, anélkül hogy a bot-token felfedődne vagy a normál visszalépési küldés elnyomódna.
9.1.182
  • Ez a release kizárólag egy futó King-munkamenet automatikus frissítését javítja.
  • A launcher eddig BLUN_NO_AUTO_UPDATE=1 értéket állított be ugyanabban a környezetben, amelyet a védett mag és a szülőfolyamat frissítés-előkészítése is használt. Így a régi frissítő a magban helyesen deaktiválódott ugyan, de az új szülői frissítés-ellenőrző is befejeződött a nyilvános manifest lekérése előtt.
  • A 9.1.182 megőrzi a kifejezetten beállított kikapcsolást a szülőfolyamathoz. A kényszerített kikapcsolás csak a védett mag indításakor kerül hozzá.
  • A Mnemo belső, helyi konfiguráció marad. A nyilvános csomag nem tartalmazza a Mnemo-t. A hozzáadó bejegyzés helyi Mnemo-útvonal és kifejezetten beállított ágensazonosság nélkül teljesen inaktív marad.
9.1.181
  • Az ismételt, azonos hosszú felhasználói feladatokat és a duplikált Telegram-kézbesítési azonosítókat kizárólag a modellvetítésből távolítják el; a nyers folyam változatlan marad.
  • Egy konfigurált Mnemo-MCP-t mostantól hozzáadnak az aktív King-TUI-profilhoz, ahelyett hogy a Telegram-bridge-munkamenetekre korlátozódna.
  • Mind a 413 teszt sikeres volt; mindkét célzott mutációs próba piros lett, amint a védőintézkedések egyikét eltávolították.
9.1.180
  • Az automatikus frissítés-előkészítés már nem függ kizárólag a későbbi TUI-ready IPC-től. Amint a védett mag bizonyíthatóan betöltődött, a launcher akkor is elindítja az előkészítést, ha ez a második jel elveszett.
  • A tényleges átadás biztonsági határa változatlan maradt: a futó válasz, a tömörítés, az üzenet-várakozási sor, az eszközök, a shell-parancsok és a sorparancsok továbbra is megakadályozzák az újraindítást munka közben.
  • A tényleges állapot igazolta a hibát: mód resume, telepítés 9.1.177, nyilvános 9.1.179, de csak 9.1.176 előkészítve. A loop így nem az első blokkoló volt, mert az üresjárati ellenőrzés csak az előkészítés után lép érvénybe.
9.1.179
  • A puszta megerősítések, mint az ok, a ja, a danke vagy a perfekt, kihagyják a személyes memória-brokert. Ez egy broker-hívást takarít meg, és az ilyen tartalomszegény meneteknél legfeljebb 16.384 karakter felesleges memória-injekciót akadályoz meg.
  • A weiter, a mellékletek, a kérdések, a parancsok és a többi tartalmi üzenet megtartja a korábbi, portálokon átívelő emlékezési utat.
  • Egy először felépített, DeepAgents-szerű argumentum-puffer öt mérési körből négyben lassabb volt, mint az egyszerű összefűzés. Teljesen eldobták, és nem publikálták.
9.1.178
  • A halasztott eszközkeresés mostantól egyértelmű, pontos első kifejezést ismer fel. A GetMedia media job status result így a GetMedia elemet tölti be, anélkül hogy széles szemantikus feltételezésre térne át. A többértelmű rövid nevek szándékosan megoldatlanok maradnak.
  • A média-előállítási lánc a teljes szakaszneveket következő sorokra tördeli. Az utolsó lépést már nem vágják le a jobb szélen.
  • A változtatás javítja az eszközkiválasztást és az olvashatóságot. Nem változtat sem a médiamodellen, sem a képminőségen, és nem állítja, hogy valódi média-előnézetet nyújtana.

Fejlesztések a 9.1.57 óta

VerzióVáltozás
9.1.177Az automatikus frissítések mostantól akkor is átvesznek egy elmentett folytatási vagy újraindítási módot, ha a közvetlen folyamatüzenet elmarad, és közvetlenül a biztonságos TUI-újraindítás előtt egyértelmű jelzést mutatnak. A tömörített eszközargumentumok korábbi helykitöltőit kompakt JSON-ként, formázott JSON-ként vagy beolvasott objektumként távolítják el, mielőtt újra végrehajthatók lennének. A nyers folyam és a frissítés összes meglévő védelmi mechanizmusa változatlan marad.
9.1.176A slash-parancsok összes választómenüje mostantól üres sorral választja el az opciókat, és a magyarázatokat külön, visszafogott másodlagos színben mutatja. A közös komponens 20 menühívást szolgál ki; az egyedi figyelmeztető színek megmaradnak.
9.1.175A minden modellkérésnél ismételt eszköz-utalás 1 749-ről 825 karakterre csökken. Ez a mérésben körülbelül 231 becsült bemeneti tokent takarít meg kérésenként. Mind a tizenegy viselkedési kötelezettség megmarad; a nyers folyam, az eszközsémák és a fájlok változatlanok maradnak.
9.1.174A modellkérésenként megjelenített releváns Mistake.md-részlet 4 000 helyett 3 000 karakterre korlátozott. 100 valódi kérésben ez átlagosan körülbelül 253 becsült bemeneti tokent takarít meg; a kiválasztott címsorok mind a 100 esetben azonosak maradtak. A teljes fájlok és az elmentett folyam változatlanok maradnak.
9.1.173A BLUN King felismeri az ismétlődő tisztán szöveges válaszokat több Telegram-meneten át. Három majdnem azonos válasz után, új felhasználói utasítások ellenére, az ágens egyszer belső javító jelzést kap, ahelyett hogy egy régi kérdést, listát vagy várakozási hurkot újra kiadna. Az üzenetek, a folyamatok és az elmentett folyam változatlanok maradnak.
9.1.172Az automatikus frissítés egy indításkor eredménytelen keresés után újra ellenőrzi a futó munkamenetet. A következő ellenőrzés véletlenszerűen elosztva 60 és 90 másodperc között történik. Így a később közzétett verziókat kézi újraindítás nélkül ismerik fel. A telepítés és a munkamenet-átadás továbbra is a teljes üresjáratra vár.
9.1.171A BLUN King menetenként már csak a négy legutóbb újratöltött eszközsémát tartja meg tizenkettő helyett. A régebbi eszközök a ToolSearch révén megtalálhatók maradnak, és kiválasztáskor újra betöltődnek. Az állandóan betöltött mageszközök, az elmentett folyam és a végrehajtási viselkedés változatlan marad.
9.1.170Összefogja az aktuális megbízhatósági és munkafolyamat-hibákat: az ismétlődő feladatok megtartják a legújabb túlméretezett utasítást; a tömörített eszközargumentum-helykitöltőket eltávolítják a modellvetítésből; a ToolSearch felismeri a természetes memória-keresőszavakat, beleértve az önmagában álló „store” szót is; a loop-megjelenítés újratölti a tervezési állapotot; a /update vezérli a biztonságos üresjárati átadást; és a /premortem látható, strukturált hibaelemzést biztosít.
9.1.169A BLUN King a pontos eszközkiválasztást és a korábbi szigorú kulcsszó-keresést változatlanul tartja. Csak ha ez a keresés nem ad találatot, egy szűk második futás keres rokon német és angol kifejezéseket. A + jellel jelölt névkövetelmények kötelezőek maradnak; legalább két jelentéshordozó kifejezésnek és a kérés 75 százalékának illeszkednie kell. Így a három ténylegesen sikertelen Telegram-keresés megtalálja az aktuális várakozási sor eszközét, míg egy nem illeszkedő kérés továbbra is találat nélkül ér véget.
9.1.168A BLUN King a régebbi eszközhívás-argumentumokat már nem cseréli belső helykitöltőre, amelyet a modell egy új hívásba másolhat. A már meglévő helykitöltő-hívásokat és a hozzájuk tartozó hibaeredményeket csak a modellvetítésből távolítják el; a változatlan munkamenet-folyam bizonyítékként megmarad.
9.1.167A BLUN King 9.1.167 az ismétlődő tervezett feladatoknál már csak a legújabb teljes munkaszakaszok hézagmentes sorozatát tartja meg. Ha a következő újabb szakasz átlépné a 48 000 karakteres vagy 24 üzenetes határt, a kiválasztás véget ér, ahelyett hogy utána régebbi kis szakaszokat venne fel. Így a kontextus és az időrend összhangban marad. Egy mért futó folyamban a vetített történet 32 591-ről 16 981 karakterre csökkent. Ez 15 610 karaktert, illetve körülbelül 3 903 becsült bemeneti tokent takarít meg összehasonlítható kérésenként. A nyers folyam, az aktuális feladatlépések és a tömörítési összefoglaló változatlanok maradnak.
9.1.166A BLUN King 9.1.166 az ismétlődő tervezett feladatokat elszigetelt munkakontextusra korlátozza, ahelyett hogy minden modell-lépésnél újra továbbítaná a főágens teljes beszélgetését. Az aktuális feladat, a legújabb tömörítési összefoglaló és a legújabb valódi munkalépések elérhetők maradnak egy 24 üzenetes és 48 000 karakteres határon belül. Az elmentett folyam, a normál felhasználói menetek, az egyszeri emlékeztetők és a gyors beszélgetési utak változatlanok maradnak. Egy mért folyamban az ismétlődő tervezett feladatok 2 043 modell-lépése összesen 298,7 millió bemeneti tokent fogyasztott, lépésenként átlagosan 146 188 tokent.
9.1.165A BLUN King 9.1.165 a normál menetek kimeneti keretét 32 768 helyett 24 576 tokenre korlátozza. A könnyű lépések megtartják a korábbi 8 192 tokenes határértéküket, a kisebb kimeneti korlátú modellek megtartják ezeket az alacsonyabb értékeket, és egy kifejezett felhasználói beállítás továbbra is elsőbbséget élvez. A 27 049 mért válaszból 99 százalék 9 970 token alatt maradt; tizenkét régi kiugró érték pontosan eltalálta a korábbi 32 768 tokenes határt, és egyenként körülbelül hat percig számolt tovább.
9.1.164A BLUN King 9.1.164 a nagy modellablakokon a tömörítés kimeneti keretét 131 072 helyett 16 384 tokenre korlátozza. 39 sikeres tömörítés legfeljebb 10 781 kimeneti tokent igényelt. Az új keret 52 százalékkal e mért csúcsérték felett van, és tömörítésenként 87,5 százalékkal csökkenti a lehetséges kimeneti és KV-cache-igényt. Az elmentett folyam és a normál beszélgetési menetek változatlanok maradnak.
9.1.163A BLUN King 9.1.163 a kiterjedt skill-betöltéseket az utolsó 20 üzeneten kívül a modellvetítésben kompakt újratöltési hivatkozással helyettesíti. Az aktuális, a kicsi és a nem újratölthető skill-betöltések változatlanok maradnak; az elmentett beszélgetésfolyamot nem írják át. Egy mért esetben egy skill-betöltés 87 034-ről 424 vetített karakterre csökken. Amint elhagyja az aktuális munkaablakot, ez 86 610 karaktert, illetve körülbelül 21 653 becsült bemeneti tokent takarít meg.
9.1.162A BLUN King 9.1.162 a munkakönyvtár nagy áttekintéseit az ismételt rendszerpromptban 2 000 karakterre korlátozza. A kis áttekintések változatlanok maradnak. Rövidített áttekintéseknél egyértelmű jelzés utal továbbra is a teljes keresésre a Glob, a Grep és a Read eszközökkel. Egy mért promptban az áttekintés 3 988-ről 1 983 karakterre csökken. Ez 2 005 karaktert, illetve körülbelül 501 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.161A BLUN King 9.1.161 a 112 kiszervezett eszköz nevét már nem ismétli meg minden ToolSearch-leírásban. A kulcsszavas keresés, a teljes vagy egyértelmű rövid név alapján történő pontos kiválasztás és a legutóbb kiválasztott tizenkét séma állandó betöltése megmarad. A mért megjelenítésben az ismételt leírás 1 984-ről 278 karakterre csökken. Ez 1 706 karaktert, illetve körülbelül 426 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.160A BLUN King 9.1.160 óta a modellvetítés csak a legújabb tizenkét üzenetet védi teljesen, mielőtt a régebbi, kizárólag szöveget tartalmazó sikeres eszközeredményeket rövid befejezési megjegyzés váltja fel. A hibakimenetek, a médiák, az elmentett fájlhivatkozások, a legújabb tizenkét üzenet, a nyers folyam és az exportok változatlanok maradnak. Egy stabilan mért munkamenet-pillanatképben így két további régi eszközeredmény kicsinyül. A modellvetítés 81 800-ról 78 402 karakterre csökken. Ez további 3 398 karaktert, illetve körülbelül 850 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.159A BLUN King 9.1.159 óta a befejezett eszközhívások érvényes JSON-argumentumait a legújabb 12 üzeneten kívül a modellvetítésben rövid megjegyzés helyettesíti. A hozzá tartozó eszközeredmény, a legújabb 12 üzenet, a befejezetlen hívások, a kicsi vagy érvénytelen argumentumok, a nyers folyam és az exportok változatlanok maradnak. Egy stabilan mért munkamenet-pillanatképben három befejezett eszközhívás-argumentum 2 849-ről 165 karakterre kicsinyül. Ez 2 684 karaktert, illetve körülbelül 671 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.158A BLUN King 9.1.158 óta a puszta státuszüzeneteket, amelyek közvetlenül egy befejezett Telegram-válasz után következnek, a legújabb 20 üzeneten kívül a modellvetítésben rövid megjegyzés helyettesíti. Az elküldött válaszhívás és annak eredménye, az aktuális üzenetek, a más eszközök utáni összefoglalók, a vegyes tartalmak, a nyers folyam és az exportok változatlanok maradnak. Egy stabilan mért munkamenet-pillanatképben hat régi státuszüzenet 1 837 karakterrel kicsinyül. Ez körülbelül 460 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.157A BLUN King 9.1.157 óta a megfelelő, sikeres, tisztán szöveges eszközkimeneteket a legújabb 20 üzeneten kívül a modellvetítésben rövid befejezési megjegyzés helyettesíti. A hibakimenetek, a médiák, a kiszervezett fájlhivatkozások, a legújabb 20 üzenet, a nyers folyam és az exportok változatlanok maradnak. Egy stabilan mért munkamenet-pillanatképben 43 régi eredmény kicsinyül. Ez 9 680 karaktert, illetve körülbelül 2 420 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.156A BLUN King 9.1.156 óta a felhasználói üzenetekre vonatkozó elmentett hivatkozások a legújabb 20 üzeneten kívül már nem ismétlik meg az előnézetüket elejével és végével minden modellkérésnél. A helyreállítási jelölés, a méretadatok, az olvasható fájlútvonal, a legújabb 20 üzenet, a médiák, a nyers folyam, a teljesen elmentett fájl és az exportok változatlanok maradnak. Egy stabilan mért pillanatképben öt régi hivatkozás kicsinyül, és a modellvetítés 99 143-ról 96 001 karakterre csökken. Ez további 3 142 karaktert, illetve körülbelül 786 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.155A BLUN King 9.1.155 óta a felhasználói üzenetekre vonatkozó elmentett hivatkozások helyreállnak, mielőtt a szövegvetítések megváltoztathatnák az eredeti üzenet hash-ét. A meglévő kiszervezések így hatékonyak maradnak, ahelyett hogy észrevétlenül a vetített teljes üzenetre esnének vissza. A nyers folyam, az újraolvasható fájlhivatkozások, a legújabb 20 üzenet, a médiák és az exportok változatlanok maradnak. Egy stabilan mért pillanatképben a modellvetítés 105 810-ről 99 143 karakterre csökken. Ez további 6 667 karaktert, illetve körülbelül 1 667 becsült bemeneti tokent takarít meg azonos felépítésű kérésenként.
9.1.154A BLUN King 9.1.154 óta a címzett Telegram-csatornaszakaszok a legújabb 20 üzeneten kívül 1 000 helyett 500 karakteres előnézetre korlátozódnak, elejével és végével. A teljes csatornametaadatok, az üzenettartalom eleje és vége, a legújabb 20 üzenet, a mellékletek, a nyers folyam és az exportok változatlanok maradnak. Egy stabilan mért pillanatképben hét további régi címzett szakasz kicsinyül. Ez 3 500 karaktert, illetve körülbelül 875 becsült tokent takarít meg ismételt kérésenként.
9.1.153A BLUN King 9.1.153 óta a régi Telegram-kontextusok vetítése megőrzi a teljes csatornametaadatokat és a záró csatorna-taget. Csak az üzenettartalom rövidül. Még valós, 161 karakter hosszú Telegram-metaadatoknál is érvényes marad a struktúra a 250 karakteres kereten belül. A vetítés idempotens, a rákövetkező címzett csatornák változatlanok maradnak, és egy tartalom nélkül is keretet túllépő csatornaboríték változatlanul továbbítódik.
9.1.152A BLUN King 9.1.152 óta a befejezett eszközhívások argumentumai nyolc helyett négy újabb üzenet után hagyják el az aktív modellvetítést. A nyers munkamenet-folyam, a megválaszolatlan vagy hibásan formázott hívások, a médiák, az eszközeredmények és a legújabb négy üzenet változatlanok maradnak. Egy frissen mért munkamenet-pillanatképben két további befejezett hívás tömörül; a 9.1.151-hez képest ez további 244 karaktert, illetve körülbelül 61 becsült tokent takarít meg ismételt kérésenként.
9.1.151A BLUN King 9.1.151 óta a befejezett eszközhívások argumentumai tizenkettő helyett nyolc újabb üzenet után hagyják el az aktív modellvetítést. A nyers munkamenet-folyam, a megválaszolatlan vagy hibásan formázott hívások, a médiák, az eszközeredmények és a legújabb nyolc üzenet változatlanok maradnak. Egy mért munkamenet-pillanatképben három további befejezett hívás tömörül; a 9.1.150-hez képest ez további 317 karaktert, illetve körülbelül 80 becsült tokent takarít meg ismételt kérésenként.
9.1.150A BLUN King 9.1.150 óta a régi eszközeredmények kiszervezése a legújabb nyolc helyett a legújabb négy üzenetet védi teljesen. A régebbi, megfelelő eszközeredmények egy kompakt, 600 karakteres helyreállítási jelzést és forrásútvonalukat tartják meg; a nyers folyam, a teljesen elmentett kimenetek, a médiák és a legújabb négy üzenet változatlanok maradnak. Egy mért munkamenet-pillanatképben a négyüzenetes ablak kilenc további régi eredményt szervez ki, és a 9.1.149-hez képest további 6 683 karaktert, illetve körülbelül 1 671 becsült tokent takarít meg ismételt kérésenként.
9.1.149A BLUN King 9.1.149 óta a régi eszközeredmények kiszervezése a legújabb tizenkettő helyett a legújabb nyolc üzenetet védi teljesen. A régebbi, megfelelő eszközeredmények egy kompakt, 600 karakteres helyreállítási jelzést és forrásútvonalukat tartják meg; a nyers folyam, a teljesen elmentett kimenetek, a médiák és a legújabb nyolc üzenet változatlanok maradnak. Egy mért munkamenet-pillanatképben három eredmény 4 679-ről 1 800 karakterre csökken; ez további 2 879 karaktert, illetve körülbelül 720 becsült tokent takarít meg ismételt kérésenként.
9.1.148A BLUN King 9.1.148 óta a legújabb vegyes Telegram-csomagban is kicsinyülnek a kifejezetten addressed=false értékkel jelölt csatornaszakaszok. A címzett szakaszok, a médiák, a nyers folyam és az exportok változatlanok maradnak. Egy mért folyamban tizenegy nem címzett szakasz 22 691-ről 2 750 karakterre csökken; ez 19 941 karaktert, illetve körülbelül 4 986 becsült tokent takarít meg ismételt kérésenként.
9.1.147A BLUN King 9.1.147 óta a mikrotömörítés a legújabb húsz helyett a legújabb tizenkét üzenetet védi teljesen, és így ugyanazt a helyreállítási ablakot használja, mint az eszközeredmények meglévő kiszervezése. A régebbi befejezett eszközargumentumok és a megfelelő eszközeredmények csak a modellvetítésben kicsinyülnek; a nyers folyam és a helyreállítási utak változatlanok maradnak. Egy mért folyamban ez további 560 karaktert, illetve körülbelül 140 becsült tokent takarít meg kérésenként.
9.1.146A BLUN King 9.1.146 óta a már kiszervezett régebbi eszközeredmények a modellvetítésben a helyreállításhoz szükséges adatokra korlátozódnak: eszköznév, karakterszám és fájlútvonal. A teljes tartalom változatlanul a lemezen marad, a nyers folyamot nem változtatják, és a legújabb tizenkét üzenet megtartja a részletes utalásait. Egy mért folyamban ez 26 779 karakterrel, illetve körülbelül 6 695 becsült tokennel csökkenti az ismételt modellbemenetet kérésenként.
9.1.145A BLUN King 9.1.145 óta egy megszakított szolgáltatói stream automatikusan ismétlődik, ha addig kizárólag belső gondolkodási kimenet érkezett. A látható szöveg és az eszközhívások továbbra is megakadályozzák az automatikus ismétlést. Az adaptív követő lépések alacsony gondolkodási szinten 8 192 tokenes kimeneti keretet használnak; az első, a komplex és a sikertelen lépések megtartják a konfigurált keretet, és egy ismétlés a hosszhatár elérése után megnövelheti. Egy munkamenet folytatásakor az aktuális Telegram-plugin-szállítási utalás már nem jelenik meg nyers csevegésszövegként.
9.1.144A 9.1.144 a címzett Telegram-szakaszokat a legújabb 20 üzeneten kívül a modellvetítésben 1 000 karakteres előnézetre korlátozza, elejével és végével. A legújabb 20 üzenet, a legújabb felhasználói üzenet, a pontos határon lévő szakaszok, a mellékletek, a csatornametaadatok, a nyers folyam és az exportok változatlanok maradnak.
9.1.143A 9.1.143 a régebbi üzeneteknél eltávolítja az ismételt Telegram-plugin-szállítási utalást a modellvetítésből. A csatornatartalom, a metaadatok, a mellékletek, a legújabb felhasználói üzenet, a nyers folyam és az exportok változatlanok maradnak.
9.1.142A 9.1.142 a régebbi, nem címzett Telegram-csatornarészek elejét és végét mutató előnézetét a modellvetítésben 500-ról 250 karakterre csökkenti. A címzett csatornarészek, a legújabb felhasználói üzenet, a mellékletek, a nyers folyam és az exportok változatlanok maradnak.
9.1.141A 9.1.141 a régebbi, befejezett eszközhívások argumentumait a modellvetítésben már 32 becsült tokentől eltávolítja. Az eszközeredmények megtartják a korábbi küszöbüket; az új üzenetek és a nyers folyam változatlanok maradnak.
9.1.140A 9.1.140 a relevancia-alapú Mistake-emlékeztetőt a modellvetítésben alapértelmezésben 4 000 karakterre korlátozza. A teljes Mistake-fájlok, a nyers folyam és az exportok változatlanok maradnak.
9.1.139A 9.1.139 a régebbi, nem címzett Telegram-csatornarészeket a modellvetítésben 500 karakteres előnézetre korlátozza. A legújabb felhasználói üzenet, a címzett részek, a mellékletek, a nyers folyam és az exportok teljesek maradnak.
9.1.138A 9.1.138 minden ismétlődő Cron-feladattól már csak a legújabb ébresztő utalást tartja meg a modellvetítésben. Az egyszeri emlékeztetők, a különböző feladatok, a nyers folyam és az exportok változatlanok maradnak.
9.1.137A 9.1.137 már csak a tizenkét legújabb üzenetet védi teljesen a régebbi eszközkimenetek kiszervezése elől. A teljes eredmények a nyers folyamon és a forrásútvonalon keresztül visszaállíthatók maradnak.
9.1.136A 9.1.136 a modellvetítésben már csak a legújabb dinamikus Mistake.md-utalást tartja meg. A régebbi kiválasztások a nyers folyamban és az exportokban teljesen megmaradnak.
9.1.135A BLUN King 9.1.135 a kezelt Node.js-futásidejű környezetet tartja első helyen a PATH-ban a helyettesítő folyamatban és minden alárendelt eszközben. Az olyan parancsok, mint a node és az npm, így ugyanazt a támogatott futásidejű környezetet használják, mint a TUI, ahelyett hogy egy régebbi rendszertelepítésre esnének vissza.
9.1.134A 9.1.134 a nem címzett Telegram-csoportüzeneteket a modellvetítésben 2 000 karakteres előnézetre korlátozza, megőrzött elejével, végével és eredeti hosszával. A közvetlen üzenetek és az elmentett folyam teljesek maradnak.
9.1.133A 9.1.133 a projekt-helyi és a közös Mistake.md fájlból legfeljebb öt releváns teljes bejegyzést választ ki egy közös, 6 000 karakteres kereten belül. A teljes források és tárolási utak megmaradnak.
9.1.132A 9.1.132 a 4 850 karakteres karcsú alaprendszerpromptot a generált inicializálás után is aktívan tartja. Ez kérésenként 18 259 karaktert, azaz körülbelül 4 565 becsült tokent takarít meg, anélkül hogy utasításokat vagy eszközöket távolítana el.
9.1.131A 9.1.131 két régebbi szabálymásolatot távolít el a modellvetítésből, amint a mérvadó megfelelőik megvannak. Az alapértelmezett prompt így 1 010 karakterrel, illetve körülbelül 253 becsült tokennel csökken kérésenként.
9.1.130A 9.1.130 az utolsó 20 üzeneten kívül a régebbi, teljesen befejezett eszközlépések magyarázó szövegét rövid utalásra cseréli. Az eszközhívások, az eredmények, a nyers folyam és az exportok teljesen megmaradnak.
9.1.129A 9.1.129 eltávolítja az előnézeti szövegeket a régebbi, már kiszervezett eszközeredményekből. Az elérési út és a méretadatok láthatók maradnak; a teljes tartalom az eredeti fájlban vagy a privát archívumban marad meg.
9.1.128A 9.1.128 a betöltött eszközsémák állandó gyorsítótárát a legutóbb kiválasztott tizenkét eszközre korlátozza. A kiszorított eszközök a ToolSearch révén azonnal megtalálhatók maradnak.
9.1.127A 9.1.127 lerövidíti az ismételt ToolSearch-katalógust. Az egyértelmű eszközök a rövid szelektorukkal jelennek meg; a teljes MCP-névterek csak névütközéseknél maradnak meg.
9.1.126A 9.1.126 a futásidejű környezet egészére érvényes hibafájlból determinisztikusan legfeljebb öt, az aktuális beszélgetéshez illő szakaszt választ ki. A vetítés 6 000 karakterre korlátozott, és nem igényel további modell- vagy hálózati hívást.
9.1.125A 9.1.125 a párosított felhasználók számára hozzáadja a tisztán olvasó /status Telegram-parancsot. Megnevezi a számítógép-, verzió-, folyamat- és várakozási sor státuszát, anélkül hogy chat-azonosítókat, útvonalakat, titkokat vagy üzenettartalmakat adna ki.
9.1.124A 9.1.124 javítja a felcserélt márkaszíneket a bevitel alatti kompakt BLUN-jelben. A státuszértékek, a profilnév és a persona változatlanok maradnak.
9.1.123A 9.1.123 eltávolítja a régebbi, befejezett eszközhívások nagy JSON-argumentumait a modellvetítésből. A név, az azonosító, az eredmény, a nyers folyam és az exportok teljesek maradnak.
9.1.122A 9.1.122 a teljes tervezési irányelvet csak vizuális munka esetén tölti be a skill-eszközön keresztül. A nem vizuális kérések kompakt aktiválási szerződést kapnak; a régebbi, tisztán szöveges kimeneteket egyúttal hatékonyabban szervezik ki.
9.1.121A 9.1.121 korlátozza az eszközök régebbi, tisztán szöveges kimeneteinek teljes méretét. A megfelelő eredményeket privát módon archiválják, és a modellvetítésben olvasható fájlhivatkozásokkal helyettesítik.
9.1.120A 9.1.120 a nagy régebbi asszisztensválaszokat privát munkamenet-fájlokba szervezi ki. Az utolsó 20 üzenet, az eszközláncok és a teljes nyers folyam megmaradnak.
9.1.119A 9.1.119 minden modell-lépésnél csak egy kis válogatást küld el a gyakran szükséges skill-ekből. Az összes többi skill a skill-eszközön keresztül, nevük vagy céljuk alapján megtalálható marad.
9.1.118A 9.1.118 a munkamenet-időbélyeget a rendszerpromptban egy futó munkamenet során stabilan tartja. A változatlan promptrészek így továbbra is használhatják a szolgáltató prefix-cache-ét.
9.1.117A 9.1.117 a négy médiához tartozó mageszközt azonnal elérhetővé teszi, és a kép- és videóértést, a videoszinkronizálást és az ajakmozgás-szinkronizálást csak szükség esetén tölti be a ToolSearch révén.
9.1.116A 9.1.116 proaktív tömörítést ad hozzá körülbelül 128 000 becsült bemeneti tokentől egy biztonságos lépéshatáron. A tömörítés egy karcsú, saját rendszerpromptot használ; a nagy Read-eredmények a meglévő forrásútvonalukat használják.
9.1.115A folytatott munkamenetek újra felépítik az aktuális profil rendszerpromptját, így az elavult, túlméretezett prompt-pillanatképek nem maradnak fenn újraindításokon át. A nagy munkakönyvtár-áttekintések korlátozottak; a teljes fájlok a Glob, a Grep és a Read révén elérhetők maradnak.
9.1.114A Telegram-kézbesítés a Windows-EPERM-et mostantól egy futó TUI- vagy poller-folyamat jeleként kezeli, ahelyett hogy az üzeneteket a látható munkamenettől elterelné. A ToolSearch pontos név-egyezésnél megerősít egy már betöltött eszközt, ahelyett hogy tévesen azt jelentené, hogy egy csak szükség esetén betöltendő eszköz hiányzik.
9.1.113A Telegram-eszközök indításkor megtartanak egy helyettesítő utat ugyanabban a futásidejű környezetben, ha a kezelt plugin-regisztráció átmenetileg hiányzik.
9.1.112A nagy régebbi felhasználói üzeneteket az aktuális munkaablakon kívül archiválják; a teljes nyers folyam továbbra is elérhető marad.
9.1.111A mellékletes Telegram-menetek automatikusan megkapják a download_attachment eszközt. Normál meneteknél az eszköz a ToolSearch révén kiszervezett marad, így a csökkentett séma-terhelés megmarad.
9.1.110A szolgáltató túlterhelése utáni ismétlések figyelembe veszik a szerver Retry-After megadását. Az automatikus ripgrep-beállítás a 15.0.0 verzió rögzített archívumait tölti le a hivatalos ripgrep-kiadásból, és a telepítés előtt ellenőrzi a SHA-256-ellenőrzőösszegeket.
9.1.109A 9.1.109 verzió már csak azt a kilenc eszközt tartja állandóan a modellkérésben, amelyekre több mint 98 százaléka esett a 3 183 mért eszközhívásnak. Az összes többi eszköz a ToolSearch révén megtalálható marad, és az első betöltés után a munkamenet hátralévő részére elérhető. Így a séma-terhelés minden normál modell-lépésnél csökken, anélkül hogy eszközt távolítana el, vagy megváltoztatná a Telegram-válaszok és a függőben lévő médiaeredmények gyors útját.
9.1.108Az azonos, ismételten betáplált rendszerutasítások csak a modellvetítésben egyesülnek. A módosított utasítások és a teljes elmentett folyam megmaradnak.
9.1.107A szolgáltatói hibák érthető ügyfélnyelven jelennek meg; a belső hibakódok és támogatási utalások nem látszanak. A /help nyílbillentyűkkel vezérelhető parancslistát kínál, és a jobb nyílbillentyűvel vagy az Enterrel megnyitja a kiválasztott parancs részletes leírását.
9.1.106Az ágensprofilok név szerint kizárhatnak eszközöket. A kizárások a dinamikus újratöltés után is érvényesek; az alapértelmezett alágensek nem küldenek Telegram-üzeneteket a főágenst megkerülve.
9.1.105A 9.1.105 verzió hozzáadja a TaskUpdate eszközt a futó háttérágensekhez. A King a következő biztonságos modell-lépésnél továbbítja a kiegészítő utasításokat ugyanannak az aktív ágensnek, anélkül hogy megállítaná vagy további ágenst indítana. Az ismeretlen és már befejezett feladatokat, a shell-feladatokat és azokat az ágenseket, amelyek már nem fogadnak el frissítést, változatlanul elutasítják.
9.1.104A 9.1.104 verzió hagyja, hogy az előtérben lévő shell-parancsok nagyon nagy kimenetnél is a szabályos végükig fussanak. A King legfeljebb 16 MiB-ot ír folyamatosan a privát feladatnaplóba, az azon túli kimenetet eldobja, és a tényleges kilépési kódot jelenti, ahelyett hogy a folyamatot a kimenet mennyisége miatt befejezné. A kis kimenetek, a háttérfeladatok, az időkorlátok és a kézi megszakítások változatlanok maradnak.
9.1.103A raj tagjait átmeneti szolgáltató-megszakítások után ugyanazon ágens-azonosító alatt legfeljebb kétszer folytatják. A HTTP 429 megtartja a külön túlterhelési szabályát; a végleges hibák és a kézi megszakítások nem ismétlődnek automatikusan.
9.1.102A delegált egyes ágenseket átmeneti szolgáltatói hibák után a tartós folyamuk alapján legfeljebb kétszer folytatják. A tartós hibák és a kézi megszakítások véglegesek maradnak.
9.1.101A túlméretezett felhasználói üzeneteket helyben biztonságba helyezik, és a modellkontextusban korlátozott előnézet váltja fel őket olvasható útvonallal. A teljes eredeti folyam és a médiák megmaradnak.
9.1.100A korlátozott Grep-tartalomkeresések a kért oldal és egy további előnézeti sor után befejezik a ripgrep-et. A találatszámlálások, a korlátlan keresések és a módosítási idő szerint rendezett fájllisták teljesek maradnak.
9.1.98A King egy befejezett munkaszakaszt 128 000 becsült tokentől proaktívan tömöríthet. A küszöb alatt az eszközséma teljesen kimarad a modellpromptból; a tömörítés a meglévő biztonságos lépésátmenetet használja.
9.1.97Az állandóan betöltött TodoList-eszközleírás 2 238-ről 996 karakterre csökkent. A többszintű tervezés, mind a hat feladatstátusz, a becsületes előrehaladás-jelentések, a lekérdezések, az ürítés és a külön tervmód védve maradt.
9.1.96Az állandóan betöltött alaprendszerprompt 23 109-ről 4 850 karakterre csökkent. Az identitás, a persona és a lélek, a válasznyelv, a munka- és jogosultsági határok, a tömörítési átadás, a futásidejű környezet, az AGENTS.md és a skill-ek védve maradtak.
9.1.95Az állandóan betöltött Write-eszközleírás 2 532-ről 1 541 karakterre csökkent. Az Edit-hez való elhatárolás, a szó szerinti tartalmak, a sorvégek, az 500 soros határ, az egyfájlos kivétel és az atomi folytatás sor- és SHA-256-ellenőrzéssel védve maradt.
9.1.94Az állandóan betöltött Glob-eszközleírás 1 495-ről 1 006 karakterre csökkent. A rendezés, az ignorált és érzékeny fájlok, a rekurzív minták, a pontfájlok, a kapcsos zárójeles bővítések és a 100 találatos határ védve maradt.
9.1.93Az állandóan betöltött Edit-eszközleírás 1 537-ről 1 144 karakterre csökkent. A módosítás előtti olvasás, a pontos cserék, a többszörös cserék, a CRLF-kezelés és az 500 soros határ védve maradt.
9.1.92Az állandóan betöltött Agent-eszközleírás 2 061-ről 1 153 karakterre csökkent. A külön kontextus, a folytatás, az időkorlátok és a párhuzamos delegálás megmaradt.
9.1.91Az állandóan betöltött Read-eszközleírás 2 391-ről 1 648 karakterre csökkent. Az oldalképzés, a titokvédelem, a média-továbbítás, a sorformátum és a CRLF-viselkedés megmaradt.
9.1.90Az állandóan betöltött Bash-eszközleírás 5 003-ről 1 834 karakterre csökkent. A futásidejű szerződés, a háttérfeladatok, a fájleszközök és a biztonsági határok teljesen megmaradtak.
9.1.89Az oldalankénti fájlolvasások a belső 1 000 soros határnál megnevezik a pontos következő line_offset értéket; a fájlvégek és a tudatosan kisebb részletek változatlanok maradnak.
9.1.88A BLUN King 9.1.88 a kis, veszteségmentes tömörítést időben aktiválja a teljes tömörítés előtt. A régebbi nagy eszközeredmények és a befejezett eszközargumentumok korábban hagyják el a modellnézetet; a teljes elmentett folyam megmarad.
9.1.87Egy kifejezetten ismételhető HTTP-429-válasz figyelembe veszi a Retry-After értéket, és legfeljebb két automatikus ismétlést kap; a többi hiba azonnal látható marad.
9.1.86A nagy eszközkimenetek ugyanazon előnézeti kereten belül 1 000-1 000 karaktert tartanak láthatónak az elejéről és a végéről; egy pontos jelölés megnevezi a kihagyott karakterszámot.
9.1.85A szöveges eszközeredmények 12 000 karakter felett teljesen egy privát helyi fájlban tárolódnak; a következő modellkérések csak 2 000 karakteres előnézeti keretet és az olvasható elérési utat tartanak meg.
9.1.84A teljes tömörítés a régebbi előzményeket kronológiai szakaszokban dolgozza fel, legfeljebb 64 000 becsült bemeneti tokennel; a rögzített biztonsági határ és a teljes privát archívum változatlan marad.
9.1.83A mikrotömörítés a régebbi, befejezett eszközhívások nagy argumentumait csak a modellnézetben cseréli érvényes JSON-jelölésre; a munkamenet-ellenőrző a becsült megtakarítást tartalomkiadás nélkül jelenti.
9.1.82A tisztán olvasó ellenőrző jelenti a kiválasztott és visszatartott eszközsémákat, az elnyomási okokat és az elkerült séma-tokenek becsült számát.
9.1.81Egy mellékelt, tisztán olvasó ellenőrző összefoglalja a szolgáltatói lépéseket, az eszközhívásokat, a tokeneket, a tömörítéseket, a hibákat és a kiszervezett kimeneteket, anélkül hogy promptokat vagy privát útvonalakat fedne fel.
9.1.80A nagy eszközeredmények tartalommentes kiszervezési telemetriát kapnak; az elszigetelt alágens-kontextust, a géppel olvasható terveket és az átvihető átadásokat regressziós tesztek védik.
9.1.79A tartós ellenőrzőpontok a befejezett előzmény-adatrekordokat a szolgáltatói lépések előtt és egy worker befejezése előtt tartósan rögzítik, így a befejezett munka folytatás után újra beolvasható.
9.1.78A teljes tömörítés az összefoglalóval való helyettesítés előtt archiválja a kiszorított előzményrészeket; az összefoglaló tartalmazza az olvasható archívum-útvonalat.
9.1.77A mikrotömörítés kontextusnyomásnál kicsinyíti a régebbi, nagy eszközeredményeket, és közben megőrzi a teljes elmentett előzményeket.
9.1.76A függőben lévő kép-, videó- és beszédfeladatok átvészelik a tömörítést és a gyors követő kérdéseket; a Telegram-üzenetek félrevezető foglalt hiba nélkül FIFO-sorrendben maradnak.
9.1.75A rövid Telegram-beszélgetések csak a legújabb megválaszolatlan üzenetet dolgozzák fel, míg a lezárt szövegváltások nyelvi kontextusként megmaradnak.
9.1.74A tárolt Telegram-útvonalak visszaállítják a véletlenül mínuszjel nélkül átadott csoportazonosítókat; a Strg+S egy ténylegesen futó menetet vezérelhet.
9.1.73A Telegram- és loop-üzenetek aktív munka közben már nem indítanak második menetet; az Escape és a Ctrl+C továbbra is megszakíthatja az aktív menetet.
9.1.72Egy frissítési utalás elrejtése csak az akkor kínált verziót nyomja el; az újabb kiadások a normál indításkor a king paranccsal újra megjelennek.
9.1.71A loop-ébresztők helyesen kerülnek a várakozási sorba, a Telegram-poller atomi módon lefoglalt, a központi fájl- és médiaeszközök azonnal elérhetők maradnak, és a Context7 már nem indul automatikusan.
9.1.69Beállítják az alapértelmezett MCP-ket, a Telegram egy védett FIFO-átadási pontot ér el, az Escape és a Ctrl+C megbízhatóan megszakítja az aktív munkát, és az MCP-áttekintés elrejti a belső útvonalakat.
9.1.68A Telegram-üzenetek üresjáratban felébresztik a FIFO-feldolgozást, a közvetlen és csoportüzenetek megtartják a beérkezési sorrendjüket, és a folytatás elrejti a belső Telegram-kereteket.
9.1.67Az alapértelmezett venture-flywheel skill egy tisztán szerződéses UVF-alapot ad hozzá determinisztikus projektbizalommal és jóváhagyási kötelezettségekkel a külső cselekvésekhez.
9.1.66A /curiosity és a /scout korlátozott, tisztán olvasó lehetőség-kutatást végez bizonyítékokkal, ellenbizonyítékokkal és megszakítási feltétellel.
9.1.65Az Escape és a Ctrl+C megbízhatóan megszakítja az automatikus tömörítéseket, egy stabil képernyőhorgony megakadályozza a dupla láblécet, és a loop-utalás a csevegéstartalomhoz igazodik.
9.1.64A lemezalapú munkamenet-folyam, a betöltött eszközök és skill-ek, egy 120 másodperces szolgáltatói üresjárati őrszem, a helyes loop-ütem, a FIFO-sorrendű Telegram, a Linux-csomagok és a bosnyák nyelvfelismerés került be együtt.
9.1.58–9.1.63Ez a verziósor a munkamenetekhez, a Telegram-hoz, a platformokhoz és a teljesítményhez kapcsolódó munkákat fogta össze. A lezárást a karcsú, igény szerinti eszközsémák, a kompakt skill-listák, a helyreállított első használatos skill-ek és egy csomaginventár-kapu alkotta a tervezetlen eltávolítások ellen.

Korábbi fejlesztések

VerzióVáltozás
9.1.53A /idea a munka megkezdése előtt közzéteszi a feladattervét, minden eszközhívásnál ellenőrzi a kimenő cselekvéseket, és minden lépéshez őszinte végállapotot követel.
9.1.52A folytatott munkamenetek közvetlenül az elmentett munkakönyvtárat nyitják meg. A beszélgetés és az aktív /loop állapot az újrainduláskor együtt áll helyre.
9.1.51A loopok autonóm ébresztőként működnek, a /idea saját terveket fejleszt és dolgoz fel, a Telegram munkaparancsokat válthat ki, és a média- és indítási állapotok tisztábban jelennek meg.
9.1.50A helyben vagy Telegram-on fogadott képek valódi MP4-videókként animálhatók. A nagy kontextusablakok érvényes kimeneti keretet kapnak; a médiasáv tisztább állapotokat és kattintható útvonalakat mutat.
9.1.49A felnőtt fantáziafigurák fürdőruhás képei világos határok között engedélyezettek maradnak. A befejezett képfeladatok kiinduló képként használhatók videókhoz; a sikeres GetMedia-lekérdezések nem hoznak létre ismételt kártyákat.
9.1.48Az egységes médiasáv közvetlenül a beviteli mező felett gyűjti össze a médiafeladatokat. A százalékértékek csak valódi, a szolgáltatótól mért értékkel jelennek meg; különben fázist és futásidőt mutat.
9.1.47A kérések naplója megkülönbözteti a beszélgetést és a tömörítést, és rögzíti az eszközkiválasztást és az elnyomás okát, anélkül hogy az eszközviselkedést megváltoztatná.
9.1.46A loopok megértik a természetes időmegadásokat, bevitel közben megjelenítik azokat, támogatják a szabad intervallumokat, és a normál szövegkijelölést felszabadítják a terminálban az előzménynézeten kívül.
9.1.45A futó tömörítési előrehaladás csak az alsó státuszsávban jelenik meg, nem pedig ráadásul második sorként a csevegésben.
9.1.44A jóváhagyott 9.1.43 teljes újracsomagolása, hogy a korán telepített 9.1.43-változatok is biztonságosan felismerjék a frissítést.
9.1.43Teljes védelmi alap a 9.1.40-ből, szállítási diagnózissal, látható frissítési utalásokkal és a /loop, /goal és /output-style konzolparancsokkal.
9.1.40Menet-őrszem a hosszú vagy ismételten sikertelen hívásokhoz; ön-hash a többrészes írás után, az elmentett fájl visszaolvasási ellenőrzésével.
9.1.39A hosszú fájlokat folytatásokban írják. Minden folytatás a ténylegesen megírt végén folytatja; a sorszámot, a SHA-256-értéket és a darabhatárokat ellenőrzik és kiadják.
9.1.38Az elfajult vagy levágott eszközargumentumokat felismerik. Egy hiányos fájlt hibajelzéssel utasítanak el, ahelyett hogy csendben késznek számítana.
9.1.37Node-váltás után a BLUN natív modulokat valódi SQLite-lekérdezéssel ellenőrzi, és szükség esetén újraépíti a better-sqlite3 modult.
9.1.36Az üres modellválaszokat ok szerint kezelik: a túl szűk kimeneti keretet megnövelik, egy üres stopot pontosan egyszer ismételnek. A rendszerutasítások és az injekciók nem válthatnak ki Telegram-választ.
9.1.35A többszintű tömörítés mutatja a szintet és a modellablak valós kihasználtságát, például 2/~10 · 90 % formában.
9.1.34Az aktív kontextus szakaszosan tömörül: a legrégebbi részek először, minden tömörítő-hívás a modellhatár alatt.
9.1.33Az automatikus Node-futásidejű környezet alapja, valamint a natív modulok utólagos javítása futásidejű váltás után.

Pótlások és nyitott dokumentációs hiányok

Az összevetés 2026. szeptember 17-én készült: a 9.1.33 és 9.1.597 közötti tartományban 521 verzió található az npm-könyvtárban. Egy hiányzó szám nem feltétlenül hiányzó kiadást jelent: egyes változatok hiányoznak a mai könyvtárból, vagy visszavonták őket. Négy közzétett verziónál a pontos változási részletek nyitva maradnak. Ehhez nem találnak ki változásokat.

9.1.567: a változási részletek nyitva

Közzétéve 2026. szeptember 6-án 22:42 UTC-kor. A csomag SHA-512-értéke megegyezik az npm-en közzétett integritásértékkel. A csomag nem tartalmaz CHANGELOG.md fájlt; a README a telepítési parancsnál még 9.1.566-ot említ. Ebből a 9.1.566-tól való különbség nem vezethető le megbízhatóan. Ez a dokumentációs hiány kifejezetten nyitva marad.

9.1.550: a változási részletek nyitva

Közzétéve 2026. szeptember 2-án 07:19 UTC-kor. A csomag SHA-512-értéke megegyezik az npm-en közzétett integritásértékkel. A csomag nem tartalmaz CHANGELOG.md fájlt, és a vizsgált anyagban nem találtak verzióspecifikus változási igazolást. Ez a dokumentációs hiány kifejezetten nyitva marad.

Pótlás a 9.1.536-hoz

A következő adatok az integritás-ellenőrzött, 2026. szeptember 1-jén közzétett csomagból származnak:

  • A munkafeladatok a privát Telegram-válaszokon túl is folytatódnak. A pufferelt közvetlen üzenetek után a King egy korlátozott kiegészítő lépéssel folytatja a munkát, hacsak a felhasználó kifejezetten nem szüneteltet vagy állít le.
  • A rövid státuszlekérdezések nem szakítják meg a futó munkafolyamatot.
  • Ha az üres gondolkodási válaszok utáni ismétlési kísérletek kimerültek, a King csökkenti a gondolkodási erőfeszítést, ahelyett hogy a további kísérleteknél változatlanul hagyná.
  • Több betöltött eszközséma marad elérhető; az üzeneteket csak akkor szervezik ki, ha az előzményekben rendelkezésre álló hely szűkössé válik.
  • Tartalmazza a TodoList ellenőrzött előrehaladás-szabályát és egy egysoros indítási utat a God Mode-hoz a Swarm funkcióval.

Pótlás a 9.1.99-hez

A már meglévő funkciódokumentáció leírja az egymást követő tiszta szöveges eszközeredmények közös kiszervezését: ha a köteg meghaladja a 12 000 karaktert, a megfelelő nagy eredményeket privát módon mentik. A modellkontextusban olvasható hivatkozások maradnak; a nyers folyam és a médiák megmaradnak. Az eddig hiányzó verzióbejegyzés most kifejezetten erre a funkcióra utal.

9.1.70: a változási részletek nyitva

Közzétéve 2026. augusztus 24-én 15:56 UTC-kor. A csomag SHA-512-értéke megegyezik az npm-en közzétett integritásértékkel. A csomag nem tartalmaz CHANGELOG.md fájlt; a meglévő funkcióleírások nem igazolnak egyértelmű különbséget a 9.1.69-hez képest. Ez a dokumentációs hiány kifejezetten nyitva marad.

9.1.57: a változási részletek nyitva

Közzétéve 2026. augusztus 23-án 07:28 UTC-kor. A változat eddig csak egy gyűjtőcím kiindulópontjaként jelent meg. A vizsgált anyagban nem rendelhető hozzá saját verzióspecifikus változási igazolás. Ez a dokumentációs hiány kifejezetten nyitva marad.

A megváltoztathatatlan 9.1.597 npm-csomagban található CHANGELOG.md a 9.1.594-nél ér véget. A 9.1.595 és 9.1.597 közötti kiegészített utalások ezen az oldalon állnak. A közzétett csomagot nem írták át utólag ugyanazon a verziószámon.

A 9.1.41 és a 9.1.42 vissza van vonva

Ne telepítsd

Ezt a két verziót tévedésből a 9.1.38-ból ágaztatták el a 9.1.40 helyett. Így hiányzott az írás-folytatás, az ön-hash és a menet-őrszem. Mindkét npm-verzió elavultként van megjelölve; a latest és a next soha nem mutatott rájuk. A 9.1.43 a szándékolt változásaikat a teljes védelmi alapon tartalmazza.

Frissítés és ellenőrzés

king update
blun --version

A 9.1.599 telepítése után a verziókiírásnak 9.1.599 értéket kell mutatnia. A 9.1.597 és a helyi 9.1.598-as változat frissítései a nyilvános frissítési forrásokon keresztül ellenőrzöttek. Egy már futó konzol csak az újraindítása után tölti be az új kódot. Ellenőrizd benne utána a /version parancsot is.