BLUN King

BLUN King 9.1.621

Veröffentlicht am

King übernimmt eine Zusammenfassung deines Gesprächs nur noch, wenn das Modell deren Abschluss bestätigt hat. Fehlt diese Bestätigung, bleibt dein bisheriger Gesprächsverlauf unverändert.

Endet die Übertragung der Zusammenfassung unerwartet, wird dein bisheriger Gesprächskontext nicht durch die unvollständige Zusammenfassung ersetzt. Die Änderung betrifft nur die Verdichtung des Gesprächs; normale Antworten bleiben unverändert.

Noch offen sind vereinzelte Fehler beim Speichern einer Sitzung; diese sind mit diesem Update nicht behoben.

BLUN King

BLUN King 9.1.620

Veröffentlicht am

Unter Windows beendet sich die Konsole beim Schließen des Fensters vollständig, damit beim nächsten Start kein „läuft bereits“ mehr erscheint.

Das Update korrigiert den Abschluss des Konsolenprozesses beim Schließen des Fensters. Eine tatsächlich noch laufende Konsole behält weiterhin den exklusiven Zugriff auf ihre Sitzung.

Die Anleitung ist auf den 620-Stand ergänzt: Linux-Installation, Fortsetzen langer Sitzungen, die letzte Sitzung beim Start, Strg+L, Skills, Plugins, Ziele und Headless-Aufträge. Zur aktuellen CLI-Anleitung.

BLUN King

BLUN King 9.1.619

Veröffentlicht am

Ein einzelner früherer Fehler beim Zusammenfassen des Gesprächs sperrt Deine Sitzung nicht mehr: Nach einer erfolgreichen Zusammenfassung zählt King nur neue, direkt aufeinanderfolgende Fehler. Scheitert die Zusammenfassung zweimal hintereinander, zeigt die Meldung jetzt klar „Verdichtung pausiert“, statt einen vollen Kontext zu melden.

Noch offen sind vereinzelte Fehler beim Speichern einer Sitzung und beim Erstellen einer vollständigen Gesprächszusammenfassung; diese sind mit diesem Update nicht behoben.

BLUN King

BLUN King 9.1.618

Veröffentlicht am

Kommt nach dem Fortsetzen deiner Sitzung eine Telegram-Nachricht an, während King bereits arbeitet, bleibt sie in der Warteschlange und wird anschließend zugestellt. King zeigt diese Wartesituation nicht mehr als Fehler an.

Unter Linux x64 nutzt das Terminal eine mitgelieferte Binärdatei. Es funktioniert damit auch, wenn npm 12 Installationsskripte sperrt; ein Compiler ist dafür nicht nötig. Dafür verwendet King die festgelegte Vorabversion node-pty 1.2.0-beta.15.

BLUN King

BLUN King 9.1.617

Veröffentlicht am

Beim erneuten Laden derselben Sitzung fügt King unveränderte Plugin-Anweisungen nicht mehr mehrfach hinzu. Ändern sich die Anweisungen, berücksichtigt King weiterhin den aktuellen Stand.

Vorschauen großer Werkzeugausgaben berücksichtigen jetzt auch das verfügbare Kontextfenster. Ausgelagerte Ausgaben kannst du weiterhin vollständig nachlesen.

Mit /profile oder /profiles öffnest du die Profilauswahl. King wechselt nur, wenn deine Sitzung bereit ist. Laufende Arbeit und wartende Nachrichten verhindern einen voreiligen Wechsel; dein bisheriges Profil bleibt dann aktiv.

Beendest du laufende Arbeit, wartet King auch auf die letzten Aufräumschritte. Noch nicht abgeschlossene Arbeit wird nicht vorzeitig als beendet bestätigt.

BLUN King

BLUN King 9.1.616

Veröffentlicht am

Nach einer bestätigten Telegram-Antwort übernimmt King weitere an dich adressierte Nachrichten am nächsten sicheren Schritt, auch während eines laufenden Zugs.

Nach einer bestätigten Telegram-Antwort übernimmt King weitere an dich adressierte Nachrichten am nächsten sicheren Schritt, auch während eines laufenden Zugs. Eine bereits zugestellte Antwort hält die Warteschlange nicht mehr auf. Antworten bleiben ihrem jeweiligen Chat zugeordnet.

Brichst du einen Zug ab, bleiben noch nicht übernommene Telegram-Nachrichten für die nächste Zustellung erhalten. King quittiert sie erst, wenn die Sitzung sie tatsächlich übernimmt.

BLUN King

BLUN King 9.1.615

Veröffentlicht am

King hält große Werkzeugkataloge über die Werkzeugsuche verfügbar und passt das Werkzeugbudget an das Kontextfenster des Anbieters an.

King hält große Werkzeugkataloge über die Werkzeugsuche verfügbar, ohne alle optionalen Werkzeugschemata an das Modell zu senden. Meldet der Anbieter ein kleineres Kontextfenster, passt King das Werkzeugbudget an; gefundene Werkzeuge bleiben im nächsten Schritt verfügbar.

Große Werkzeugausgaben lagert King bei Bedarf schon früher aus als bisher. Du kannst die vollständige Ausgabe wie bisher abrufen, sofern sie sicher wiedergegeben werden kann.

Normale Telegram-Antworten und Änderungen an Nachrichten werden nicht mehr wegen einer fehlenden Sprachfreigabe aufgehalten. Eine von dir eingerichtete Antwortprüfung bleibt aktiv.

BLUN King

BLUN King 9.1.614

Veröffentlicht am

Zu große AGENTS.md- und AGENTS.override.md-Dateien stoppen einen Zug nicht mehr allein wegen ihrer Größe.

Außerhalb der King-Konsole liest King insgesamt bis zu 32 KiB aus Anweisungsdateien und nennt dir einmal je Sitzung die Anzahl der ausgelassenen Bytes.

In der King-Konsole bleiben die Dateien vollständig, solange die Anfragegrenze das zulässt.

Verknüpfungen und unsichere Pfade bleiben gesperrt.

BLUN King

BLUN King 9.1.613

Veröffentlicht am

King erkennt zu große Modellanfragen schon vor dem Senden.

In der King-Konsole liest King aus jeder AGENTS.md- und AGENTS.override.md-Datei höchstens 32 KiB. Was darüber hinausgeht, lässt King aus und zeigt dir an, wie viele Bytes ausgelassen wurden.

King schätzt vor dem Senden nun die Größe der gesamten Modellanfrage, einschließlich Anweisungen, Verlauf, Werkzeugdefinitionen und Bilddaten. Nähert sie sich der Byte-Grenze des Servers, beginnt eine stufenweise Verdichtung. Lässt sich eine Anfrage nicht sicher aufteilen, bricht King ab, ohne den gespeicherten Verlauf stillschweigend zu verwerfen.

King speichert abgeschlossene Werkzeugaufrufe lokal als Metadaten: Werkzeugname, Zeitpunkt, Status und bei Dateiwerkzeugen gegebenenfalls den Pfad. Eingaben, Ausgaben, Befehle und Schlüssel werden nicht gespeichert. Mit /memory tools kannst du die Einträge deines Profils durchsuchen.

Die Kontextdiagnose zeigt zusätzliche Zahlen zur Zusammensetzung von Anfragen. Eine zuschaltbare Phasenmessung erfasst die Zeit bis zum Modellaufruf, ohne Inhalte zu protokollieren.

Die Nutzungsanzeige übernimmt gesondert gemeldete Denktoken, sofern der Anbieter sie liefert.

Nicht freigegeben, ersetzt durch 9.1.613

BLUN King 9.1.612

Veröffentlicht am

9.1.612 wurde nicht als Kundenupdate freigegeben. Der frühe Byte-Schutz griff bei einer Anfrage über 900 KB nicht, wenn der Verlauf allein unter 600 KB blieb. 9.1.613 ersetzt diesen Stand.

BLUN King

BLUN King 9.1.611

Veröffentlicht am

Große Verdichtungsanfragen bleiben innerhalb der Byte-Grenze des Servers.

  • King teilt eine zu große Verdichtungsanfrage nach Anfragegröße in chronologische Schritte auf. So kann die Verdichtung weiterlaufen, auch wenn die Anfrage mehr Bytes enthält, als der Server auf einmal annimmt.
  • Passt schon eine einzelne Nachricht nicht unter die Grenze, bleibt dein gespeicherter Verlauf unverändert. King verwirft ihn nicht, um die Verdichtung zu erzwingen.

Eine kürzere Modellwartezeit oder ein geringerer Tokenverbrauch ist damit nicht belegt. Ein Update startet eine bereits laufende King-Sitzung nicht neu.

BLUN King

BLUN King 9.1.610

Veröffentlicht am

Du kannst King unter Linux wieder installieren und Profile wieder starten, und ein zweiter King-Start unter Windows scheitert nicht mehr mit einer irreführenden Meldung zu privaten ACLs.

  • Linux steht wieder in der Liste der unterstützten Betriebssysteme des npm-Pakets. Hast du unter Linux eine ältere Version, installierst du 9.1.610 über den normalen Updater.
  • Ausdrückliche Starts mit --profile und bestehende Profilnamen-Kürzel führen in das Verzeichnis des gewählten Profils. Ein bloßer unbekannter Name legt nicht mehr stillschweigend ein leeres Profil an; ein neues Profil legst du bewusst mit --profile an.
  • Fehlt einem bestehenden Profil die eigene Anmeldung, bietet King /login an, statt an einer fehlenden blun/king-Modellkonfiguration abzubrechen.
  • Unter Windows gelingt die Prüfung privater Verzeichnisse auch dann, wenn die Telegram-Bridge ein Plugin-Verzeichnis geöffnet hält. TEMP und TMP werden an den ACL-Helfer weitergegeben, und bei Verzeichnisfehlern nennt King den betroffenen Pfad und die eigentliche Ursache.
  • Läuft bereits ein interaktiver King, erkennt King das vor der Härtung der privaten ACLs und meldet dessen PID, statt einen zweiten Start als Fehler bei den privaten ACLs darzustellen.

Ein leeres Profil übernimmt in 9.1.610 keine Anmeldedaten aus dem gemeinsamen Home-Verzeichnis. Die aktuelle /login-Abfrage kann noch „OAuth login expired“ anzeigen, auch wenn sich dieses Profil nie angemeldet hat.

Der Linux-Update-Weg von 9.1.114 auf 9.1.610 wurde nach der Veröffentlichung durchlaufen. Der Windows-Update-Weg von 9.1.609 auf 9.1.610 ist nicht gemessen.

Ein Update startet eine bereits laufende King-Sitzung nicht neu.

BLUN King

BLUN King 9.1.609

Veröffentlicht am

Öffne die Effort-Auswahl mit Strg+L und behalte dabei deinen Editor-Entwurf.

  • Strg+L öffnet die bestehende Effort-Auswahl, ohne deinen Editor-Entwurf zu verlieren. Die vorhandenen Effort-Einstellungen und Modellbeschränkungen werden wiederverwendet, statt einen zweiten Konfigurationsweg anzulegen.
  • Die bestehende Regel für laufende Sitzungen bleibt: Eine Effort-Änderung während aktiver Arbeit wird abgelehnt, nicht für später vorgemerkt. Während der Wiedergabe oder einer Editor-Übernahme wird das Tastenkürzel ignoriert.

Diese Änderungen belegen weder schnellere Antwortzeiten im laufenden Betrieb noch einen geringeren abgerechneten Tokenverbrauch und stellen keine vollständige OpenClaw-Parität her.

BLUN King

BLUN King 9.1.608

Veröffentlicht am

In Telegram-Gruppen erreichen King nur noch Nachrichten, die ihn erwähnen. Deine Mehrfachauswahlen und das schrittweise Abbrechen von Fragen bleiben erhalten.

  • In Telegram-Gruppen gelangen Nachrichten, die King nicht ansprechen, erst nach der Erwähnungsprüfung in den Sitzungskontext. Wer die Prüfung ausdrücklich abgeschaltet hat, behält das.
  • Eigene Mehrfachauswahlen und das schrittweise Abbrechen von Fragen bleiben erhalten. Die Ziel-Fußzeile läuft auf einem gemeinsamen Aktualisierungstimer.
  • Der Aufwand der Windows-ACL-Übertragung sinkt, ohne dass die Berechtigungsprüfung abgeschwächt wird. Die Wiederherstellung nach vorübergehenden Fehlern beim Ersetzen der Konfiguration ist begrenzt; die Eigentümerschaft des Schreibvorgangs bleibt erhalten.
  • Vor dem erneuten Versuch prüft King, ob ein parallel entfernter Windows-Writer-Marker tatsächlich verschwunden ist. Nicht lesbare vorhandene Marker führen weiterhin zum Abbruch.

Diese Änderungen belegen weder schnellere Antwortzeiten im laufenden Betrieb noch einen geringeren abgerechneten Tokenverbrauch und stellen keine vollständige OpenClaw-Parität her.

BLUN King

BLUN King 9.1.607

Veröffentlicht am

Deine zuletzt gewählte Sitzung kommt zurück, fehlgeschlagene Schreibvorgänge werden ehrlich gemeldet und jeder HTTP-Versuch erhält einen Startzeitstempel.

  • Die optionale Wiederherstellung der zuletzt gewählten Sitzung lässt sich mit resume_last_selected in tui.toml aktivieren. Die Auswahl gilt für das bestätigte Konto, die Laufzeit, den Agenten und den Arbeitsbereich. Der normale Start bleibt unverändert, ausdrückliche Sitzungswahlen haben Vorrang; nicht verfügbare Auswahlen fallen auf eine neue Sitzung zurück, nicht auf eine andere.
  • Nach einer fehlgeschlagenen Aktivierung bleibt die vorherige Auswahl erhalten. Unter einem Konto, das sich während der Aktivierung geändert hat, wird keine Auswahl gespeichert.
  • Fehlgeschlagene Datei-Schreibvorgänge werden nicht als erfolgreich gekennzeichnet. Das bestehende Fortsetzungsprotokoll für vollständige Zeilen bei Schreibvorgängen über 2.048 UTF-8 Bytes wird erklärt, ohne die Grenze zu erhöhen oder automatisch erneut zu versuchen.
  • Unmittelbar vor jedem HTTP-Versuch wird ein Startzeitstempel nach Wanduhrzeit für die Diagnose-Korrelation aufgezeichnet. Anfrageinhalte oder Zugangsdaten gelangen nicht in die Diagnose.
  • Unicode-Zeichen außerhalb der Basisebene (zum Beispiel Emoji) bleiben an den bestehenden Grenzen des Speicherbudgets vollständig erhalten, ohne dass diese Budgets erhöht oder ein weiterer Speicher angelegt wird.

Diese Änderungen belegen weder schnellere Antwortzeiten im laufenden Betrieb noch einen geringeren abgerechneten Tokenverbrauch, stellen keine vollständige Gateway-Parität her und schließen nicht angesprochene Telegram-Nachrichten nicht vom Kontext aus.

BLUN King

BLUN King 9.1.606

Veröffentlicht am

Beim Fortsetzen einer Sitzung erscheinen zuerst die aktuellen Transkriptseiten; ältere Seiten lädt die vorhandene Transkript-Navigation nach.

  • Beim Fortsetzen einer interaktiven Sitzung erscheinen zuerst die aktuellen Transkriptseiten; ältere Seiten lädt die vorhandene Transkript-Navigation nach. Der vollständige gespeicherte Verlauf und der aktive Modellkontext bleiben erhalten.
  • Beim Start gilt ein Anzeigeziel von 200 Wiedergabedatensätzen. Mit --history-limit von 1 bis 2000 lässt sich die Anzeige der ersten und älterer Seiten einstellen; vollständige Gesprächsrunden und Werkzeugpaare können das Ziel überschreiten.
  • Die erste Anzeige von Skill- und Plugin-Aktivierungen bleibt über Seitengrenzen hinweg erhalten. Die Home-Scrollposition ist korrigiert, sodass das Laden älterer Seiten keinen leeren Bildschirm hinterlässt.

Diese Änderungen verringern die anfängliche Transkript-Renderarbeit. Sie belegen weder schnellere Antwortzeiten des Modells noch geringeren Tokenverbrauch oder niedrigere Rechnungen, verbessern das Provider-Caching nicht und begrenzen nicht, wie viel beim Start von der Festplatte gelesen wird.

BLUN King

BLUN King 9.1.605

Veröffentlicht am

Prüfe Kontextquellen, steuere laufende Vorgänge und übergib beim Start der Konsole eine erste Nachricht. Die Verarbeitung des lokalen Verlaufs und die Verdichtungsprüfungen wurden erweitert.

  • Lokale Sitzungsverläufe werden gebündelt wiedergegeben. Archivierte Anzeigeseiten lassen sich finden, ohne alle vorherigen Blöcke zu durchsuchen. Der vollständig gespeicherte Verlauf, die Integritätsprüfungen des Archivs und die bisherige Wiederherstellung bleiben erhalten.
  • Wiederholte Werkzeugergebnisse werden zwischen protokollierten Verdichtungen gleichbleibend für den Modellkontext aufbereitet. Vollständige lokale Ausgaben und bestehende Leserechte bleiben erhalten. Ausgaben werden nicht ausgelagert, wenn sie über den zugesagten Wiederherstellungsweg nicht wieder abrufbar wären.
  • Die abschließende automatische Verdichtung ersetzt den aktiven Kontext nur, wenn sie den Verlauf nach derselben Schätzmethode verkleinert. Bei Ablehnung bleibt der ursprüngliche Verlauf erhalten. Der optionale Auslöser max_request_history_bytes nutzt die bestehende Verdichtungssteuerung, ist standardmäßig ausgeschaltet und begrenzt nicht den gesamten Anfragekörper an den Anbieter.
  • Die Kontextdiagnose erhält getrennte Ansichten und eine Quellenzuordnung für Anweisungen, Memory, Skills und frühere Nachrichten. Bytes des serialisierten Inhalts, lokale Tokenschätzungen und gemeldeter Verbrauch bleiben getrennt.
  • Die Zuständigkeit für die Sitzung bleibt bei wartenden Aufgaben, verspäteten Ereignissen, Rückfragen und Konfigurationsänderungen erhalten. Ein zweiter aktiver Schreibzugriff auf dieselbe Sitzung wird abgewiesen, statt gleichzeitige Änderungen am Protokoll zuzulassen.
  • Die zusätzliche Agenten-/Sitzungszeile in der Fußzeile entfällt. Sitzungen lassen sich weiterhin gezielt steuern und diagnostizieren. Die bestehende King-Oberfläche, die verwalteten Modelle und die Berechtigungsgrenzen bleiben erhalten.
  • --message übergibt eine erste Nachricht für den interaktiven Start. Sie wird nach der Zustimmung beim Start und der Sitzungsauswahl über die normale Nachrichtenprüfung und Warteschlange verarbeitet. Ihr Inhalt wird nicht als Slash- oder Shell-Befehl interpretiert.
  • Die Schnittstellenvereinbarung des mitgelieferten Guard-Dienstes bleibt unverändert. Diese Veröffentlichung belegt weder schnellere Antworten im laufenden Betrieb noch niedrigere Anbieterrechnungen, vollständige Funktionsgleichheit mit OpenClaw oder eine begrenzte Einlesemenge beim erstmaligen Laden des Sitzungsprotokolls.

/abort bricht den laufenden Vorgang ab, ohne wartende Eingaben zu verwerfen. /stop verwirft zusätzlich die wartenden Eingaben. /exit beendet weiterhin die Konsole. Dies sind lokale Konsolenbefehle, keine zusätzlichen Telegram-Fernbefehle.

Prüfungen am Paketstand 9.1.605: 238 Prüfdateien mit 6.900 Tests sowie 40 Staging-Prüfungen, darunter 25 native Terminalprüfungen. Der Test eines isolierten Updates von 9.1.604 über den veröffentlichten Kandidaten-Tag mit dem echten Installationsprogramm war erfolgreich. Damit sind weder kürzere Aufwärmzeiten in einer laufenden Sitzung noch vollständige Funktionsgleichheit mit OpenClaw belegt.

BLUN King

BLUN King 9.1.604

Veröffentlicht am

Prüfe Anfragegröße und Kontextquellen, lade Werkzeuge nach Bedarf und steuere eingehende Nachrichten innerhalb der jeweiligen Sitzung.

  • /context doctor und /tokens unterscheiden die Bytezahl der serialisierten Anfrage von geschätzten Tokenzahlen und zeigen die erfassten Anteile von Regeln, Memory, Skills und Werkzeugdefinitionen.
  • Mittelgroße Werkzeugkataloge werden bei Bedarf über die vorhandene Suche geladen; die Werkzeuge bleiben auffindbar und ausführbar.
  • /queue steuert Nachrichten innerhalb der jeweiligen Sitzung. Gewöhnliche Nachrichten in der Warteschlange unterbrechen die Arbeit nicht mehr automatisch nach 30 Sekunden.
  • Bei der Sitzungsauswahl sind exakte Kennungen oder Titel sowie eindeutige Kennungspräfixe möglich; die Fußzeile zeigt den zugeordneten Agenten und die Sitzung.
  • Jeder HTTP-Versuch erhält eine neue Anfragekennung, sofern der Aufrufer keine vorgibt. Die Diagnose verändert die Abrechnung nicht.
  • Die mitgelieferten Versionen von AgentSpine und Translate Native bleiben unverändert. Geringere Kosten und schnellere Antworten im Livebetrieb sind nicht belegt.
  • /question: Öffnet ausstehende Rückfragen erneut. Das Einklappen beantwortet oder verwirft eine Rückfrage nicht.

Anfrage-Bytes, geschätzte Tokenzahlen, aufsummierter Sitzungsverbrauch und abgerechnete Token sind unterschiedliche Größen. Die Verbrauchsanzeige berücksichtigt auch die Antwortprüfung. /usage cost mit Tages- oder Monatskosten gehört nicht zu dieser Fassung. Geringere Kosten oder schnellere Antworten im Livebetrieb sind nicht belegt.

BLUN King

BLUN King 9.1.603

Veröffentlicht am

Wähle deinen Arbeitsordner in einem Windows-Dialog aus. Wird die Konsole aus System32 gestartet, schlägt sie jetzt deinen Benutzerordner vor.

  • Wenn du unter Windows einen anderen Arbeitsordner wählst, öffnet sich ein Ordnerdialog. Du kannst den Pfad weiterhin von Hand eingeben. Wenn du den Dialog abbrichst, kehrst du zur Ordnerauswahl zurück, ohne einen Ordner zu übernehmen.
  • Ist kein Ordnerdialog verfügbar, fragt die Konsole den Pfad ab. Auf anderen Betriebssystemen bleibt es bei der Pfadeingabe.
  • Wenn beim Start ein Ordner innerhalb des Windows-Verzeichnisses übernommen wird oder gespeichert ist, schlägt die Ordnerauswahl deinen Benutzerordner vor. Von Hand eingegebene Pfade werden weiterhin wie bisher geprüft.

Die Versionen von AgentSpine und Language Guard bleiben gegenüber 9.1.602 unverändert. Ein Geschwindigkeitsgewinn für laufende Sitzungen ist durch dieses Update nicht belegt.

Unter Windows wird weiterhin Git Bash benötigt. Meldet die Konsole, dass Git Bash fehlt, installiere Git for Windows. Öffne anschließend die Eingabeaufforderung neu, bevor du king erneut startest.

BLUN King · Veröffentlicht

BLUN King 9.1.602

Veröffentlicht am

Ein eigener privater Ordner für ältere Werkzeugausgaben, wenn geerbte Windows-Berechtigungen die Auslagerung verhindern.

  • Geeignete ältere Werkzeugausgaben werden in einem eigenen privaten Ordner abgelegt, wenn geerbte Windows-Berechtigungen die Auslagerung verhindern. Bestehende Dateien, Berechtigungen und der vollständige Sitzungsverlauf bleiben unverändert.
  • Integritätsprüfungen, Leseberechtigungen und der Rückgriff auf den vollständigen Kontext bleiben erhalten, falls eine archivierte Ausgabe nicht wiederhergestellt werden kann. AgentSpine 0.73.0 und Language Guard 6.20.0 sind gegenüber 9.1.601 unverändert.

Kürzere Antwortzeiten im laufenden Betrieb oder ein geringerer abgerechneter Tokenverbrauch sind noch nicht belegt.

BLUN King · Veröffentlicht

BLUN King 9.1.601

Veröffentlicht am

Eingaben bleiben in der Warteschlange, ältere Werkzeugausgaben erhalten geprüfte Verweise, und gedrosselte Antwortprüfungen werden begrenzt wiederholt.

  • Wenn Hintergrundarbeit zuerst zum Zug kommt, bleiben Terminaleingaben in ihrer ursprünglichen Reihenfolge in der Warteschlange. Jede Eingabe wird nur einmal angezeigt.
  • Geeignete ältere Werkzeugausgaben werden in Modellanfragen durch geprüfte Verweise auf private Dateien ersetzt. Der vollständige Verlauf und die Ergebnisse des aktuellen Gesprächsschritts bleiben erhalten. Ist das Nachladen nicht möglich, nicht erlaubt oder wurde der Inhalt verändert, wird die vollständige Ausgabe mitgesendet.
  • Eine gedrosselte native Antwortprüfung wird einmal mit demselben Antwortentwurf wiederholt. Dabei gilt die gespeicherte Wartefrist des Anbieters. Bereits abgeschlossene Werkzeugaufrufe werden nicht wiederholt, ungeprüfte Texte nicht freigegeben.
  • Bis zu 2.048 Ausgabetoken bleiben als Puffer für Abweichungen bei der Eingabeschätzung frei. Das Kontextfenster wird nicht verkleinert; kleinere ausdrücklich gesetzte Ausgabelimits bleiben unverändert.

Diese Änderungen belegen weder einen geringeren abgerechneten Tokenverbrauch noch kürzere Antwortzeiten im laufenden Betrieb. Sie beheben auch nicht jeden serverseitigen HTTP-502-Fehler.

BLUN King · Veröffentlicht

BLUN King 9.1.600

Veröffentlicht am

Antwortprüfung mit festen Zeitgrenzen und festgelegten Komponentenständen.

BLUN King 9.1.600 ist veröffentlicht. npm und das öffentliche Update-Manifest stimmen überein. Die Veröffentlichung belegt weder eine Installation auf deinem Rechner noch eine Abnahme im laufenden Betrieb.

Begrenzte Antwortprüfung

  • Allgemeine Prüfer behalten die bisherige Frist von 30 Sekunden. Die native Sprachprüfung erhält ab dem Startsignal der vertrauenswürdigen Host-Komponente bis zu 90 Sekunden für den ersten inhaltlichen Text, einmal pro äußerem Prüfversuch.
  • Inhaltlicher Text innerhalb der zulässigen Ausgabelänge sowie die geordneten Übergänge zur Freigabe und zur Belegprüfung setzen die Wartefrist jeweils auf 30 Sekunden zurück.
  • Für jeden äußeren Prüfversuch gilt unabhängig davon eine Gesamtgrenze von 120 Sekunden. Fortschritt kann diese Grenze nicht verlängern. Es bleibt bei höchstens zwei äußeren Prüfversuchen.
  • Vor der Annahme einer Freigabe wird die tatsächlich verstrichene Zeit erneut geprüft. Auch bei verzögerten Timer-Aufrufen bleibt ein abgelaufener Prüfversuch gesperrt; verspäteter Fortschritt kann eine abgelaufene Frist nicht erneuern.

Abbruchsignale werden weiterhin beachtet. Die Bindung an den exakten Antworttext, die zeitliche Gültigkeit des Freigabebelegs und die Autorisierung werden weiterhin geprüft.

Mitgelieferte Komponenten

Version 9.1.600 enthält AgentSpine 0.73.0 und Translate Native 6.155.0. Das Guard-Protokoll bleibt unverändert auf 6.20.0.

Bekannte Einschränkungen

Die neuen Zeitgrenzen belegen keine allgemeine Behebung von HTTP-502-Fehlern im Live-Betrieb. Die offenen Beobachtungen aus 9.1.599 bleiben ohne gesonderten Live-Nachweis offen.

Kontext und Hilfe

Ein vollständig beizubehaltender Prompt wird nicht mehr stillschweigend gekürzt, nur um in ein kleineres hartes Modellfenster zu passen. Bei einer neuen, ausdrücklich festgelegten Aufteilung der beizubehaltenden Nutzernachrichten mit dem Standardbudget von 20.000 Token kann die Anpassung innerhalb derselben Verdichtung abgeschlossen werden. Bei späteren oder wiederhergestellten Präfixen dürfen dadurch keine weiteren Anforderungen verworfen werden. Die Anfrage muss weiterhin in das harte Modellfenster passen.

Reine Hilfeaufrufe mit --help oder -h erzeugen keinen Laufzeit-Diagnosezustand mehr. Werden Prompt- und Hilfeargumente kombiniert, bleibt das bisherige Laufzeitverhalten erhalten.

BLUN King · 18. September 2026

BLUN King 9.1.599

Veröffentlicht am

Nachvollziehbare Einzelfreigaben für das persönliche Gedächtnis und zusätzliche Korrekturen bei Kontextüberschreitungen.

Freigabeanfragen für das persönliche Gedächtnis zeigen verständliche Aktionstitel in der ausgewählten Sprache und vollständige Vorschauen der tatsächlichen Einstellungsänderungen oder des zu speichernden Textes. Steuerzeichen werden sichtbar maskiert; der Originalinhalt bleibt unverändert.

Gültige Gedächtnisänderungen müssen einzeln freigegeben werden; ungültige Eingaben lassen sich nur ablehnen. Eine Sitzungsfreigabe genehmigt wartende Anfragen, die eine Einzelfreigabe benötigen, nicht automatisch.

Die Paketprüfung umfasst 37 Funktionsbereiche mit 199 Pflichtprüfungen, 158 Prüfausführungen und 4.905 unterschiedlichen bestandenen Tests. Zusätzlich wurden die Updates von 9.1.597 und der lokalen Zwischenfassung 9.1.598 auf 9.1.599 in isolierten Installationen mit dem unveränderten Updater und Installationsweg geprüft. Beide Tests haben die Version über die öffentlichen Update-Quellen erkannt und sämtliche 918 Dateien des Releasearchivs geprüft.

Die Hinweise in README.md und CHANGELOG.md des unveränderten Pakets 9.1.599 beschreiben den Kandidatenstand beim Packen. Sie wurden nach der lokalen Installation nicht rückwirkend geändert. Diese öffentliche Seite führt den Veröffentlichungsstand und die später beobachteten Einschränkungen gesondert fort.

Bekannte Einschränkungen in 9.1.599

Im laufenden Betrieb wurden weiterhin wiederholte HTTP-502-Antworten beobachtet, teilweise gefolgt von erfolgreichen Anfragen. Die Kontextkorrekturen sind keine allgemeine Behebung von Provider- oder Netzwerkfehlern.

Die Sprachprüfung kann eine Antwort mit missing-language-character-profile oder suspected-ascii-substitution abbrechen. Dieser Befund ist weiterhin offen; 9.1.599 enthält dafür keine nachgewiesene Korrektur.

Eine Antwort auf das gesendete Bild wurde vom Nutzer bestätigt. Eine unabhängige Prüfung der Bildinterpretation sowie die visuelle Abnahme von Eingabe und Statuszeilen stehen noch aus. Bestandene Paketprüfungen sind keine allgemeine Entwarnung für diese Abläufe.

Aus der lokalen Zwischenfassung 9.1.598 übernommen

Ohne Datum

9.1.598 wurde lokal geprüft und installiert, aber nicht als eigenes npm-Update veröffentlicht. Die folgenden Änderungen sind in 9.1.599 enthalten:

  • Bei einer Kontextablehnung werden Untergrenzen für die Zahl der Eingabetoken von exakten Angaben unterschieden. Für eine gemeldete Untergrenze wird das Ausgabelimit einmal reduziert, ohne Nachrichten oder Werkzeuge zu verwerfen. Abbruchsignale und die Begrenzung weiterer Versuche bleiben wirksam. Damit wird der in 9.1.597 reproduzierte Fehler bei der Berechnung des Ausgabelimits gezielt korrigiert.
  • Die ursprünglichen 150 wechselnden Aktivitätswörter sind wieder enthalten. Für ihre Anzeige werden keine zusätzlichen Modellanfragen gestellt.
  • Beim vertrauenswürdigen AgentSpine-Eingabehook wird statt der vollständigen Mediendaten eine kompakte Medienreferenz mit Typ, SHA-256-Prüfsumme und Größenangabe übergeben. Die vollständigen Anhänge für das Modell und die bestehenden Schutzprüfungen bleiben erhalten. Das allein belegt noch keine erfolgreiche Bildinterpretation im laufenden Betrieb.

Neu in 9.1.597

Veröffentlicht am

Begrenzte Wiederherstellung bei ausdrücklich gemeldeten Kontextüberschreitungen, auch hinter einer Gateway-Fehlerantwort.

Wenn eine Anfrage vor Beginn der Ausgabe wegen einer belegten Kontextüberschreitung abgewiesen wird, kann King einen begrenzten neuen Versuch mit kleinerem Ausgabelimit unternehmen. Auch entsprechend verpackte Fehler in einer 502-Antwort werden erkannt. Nachrichten, Werkzeuge, kleinere ausdrücklich gewählte Ausgabelimits und Abbruchsignale bleiben erhalten. Ein bereits begonnener Stream wird nicht erneut abgespielt.

Das behebt nicht sämtliche Provider- oder Netzwerkfehler. Allgemeine Verbindungsabbrüche und Dienstausfälle müssen weiterhin anhand ihrer eigenen Fehlerdaten geprüft werden.

Bekannte Einschränkung in 9.1.597: Meldet der Server nur eine Untergrenze für die Zahl der Eingabetoken, kann der Wiederholungsversuch erneut scheitern und unnötige Verdichtungen auslösen. Dieser Fall wurde am 17. September 2026 nach der Veröffentlichung reproduziert. Die zusätzliche Korrektur aus der lokalen Zwischenfassung 9.1.598 ist in 9.1.599 enthalten.

Geprüft wurden 36 Funktionsbereiche mit 183 Pflichtprüfungen und 4.407 unterschiedlichen bestandenen Tests sowie das echte Update von 9.1.596 auf 9.1.597. Diese Paketprüfung ersetzt keinen Anwendungstest einer bereits geöffneten Kundensitzung.

Neu in 9.1.596

Veröffentlicht am

Automatische Unterbrechungen zugunsten wartender Telegram-Nachrichten werden von echten manuellen Abbrüchen unterschieden. Eine solche Warteschlangen-Unterbrechung wird nicht mehr fälschlich als Betätigung der Escape-Taste gemeldet. Die Wartefrist, die Schutzregeln für laufende Werkzeuge und das Verhalten bei einem echten manuellen Abbruch bleiben erhalten.

Neu in 9.1.595

Veröffentlicht am

Optionale Werkzeugschemas werden über ToolSearch nachgeladen und begrenzt aufbewahrt. Große Skill-Kataloge werden kompakt und seitenweise bereitgestellt. Suche, spätere MCP-Erweiterungen und normale Berechtigungsprüfungen bleiben erhalten.

Bei kurzen Begrüßungen kann King einen begrenzten jüngeren Dialogausschnitt verwenden, ohne gespeicherte Nachrichten zu löschen oder Systemanweisungen zu kürzen. Für einen anschließenden Arbeitsauftrag berücksichtigt King wieder den aufbewahrten Arbeitsverlauf. Die Kontextrechnung bleibt auch nach dem Fortsetzen einer Sitzung erhalten. Ein fester Tokenverbrauch für jede Begrüßung wird nicht zugesagt.

Neu in 9.1.594

Veröffentlicht am

  • Private Telegram-Antworten bleiben möglich, während Gruppennachrichten warten. Die Zuordnung von Slash-Befehlen bleibt erhalten.
  • Lange Wartezeiten aus Retry-After werden eingehalten; beim Fortsetzen einer Sitzung wird die verbleibende Pause wiederhergestellt.
  • Nach verworfener Begleitbeschreibung wird ein bereits abgeschlossener Werkzeugschritt weiterverarbeitet. Die verworfene Beschreibung wird nicht veröffentlicht, die Prüfung der abschließenden Antwort wird nicht abgeschwächt.
  • Die begrenzten Wiederherstellungsfunktionen für das Schreiben in mehreren Teilen sind wieder verfügbar. Das gilt auch für Shell-Zeitgrenzen, Aufgabensteuerung und Sitzungswiederherstellung.
  • Eingabe, Kontingentzeilen, Aktivitätsanzeige, aufklappbare Aufgaben und Werkzeugausgaben mit Quellenkennzeichnung bleiben beim Streamen und beim Navigieren im Verlauf sichtbar.
  • Vor dem Packen sind vollständige Konsolen-Regressionsnachweise erforderlich; die öffentlichen Update-Metadaten werden auf Übereinstimmung geprüft.

Zwischenfassungen 9.1.590 bis 9.1.593

Diese Fassungen sind im lokalen Release-Verlauf vorhanden, am 17. September 2026 aber nicht im öffentlichen npm-Versionsverzeichnis enthalten. Sie werden hier nicht als öffentlich verfügbare Updates empfohlen. Die Arbeiten an Start, Wiederaufnahme, Berechtigungen, Aktivitätsanzeige und sichtbarer Eingabe sind in den Nachweisen zu 9.1.594 berücksichtigt.

Neu in 9.1.589

Veröffentlicht am

  • Geprüfte Quellen von AgentSpine und Translate Native sowie verifizierte Update-Manifeste werden mitgeliefert.
  • Beim Laden des Agentenkontexts bleibt das aktive King-Profil erhalten.
  • Für die Antwortprüfung benötigte Werkzeuge bleiben verfügbar. Der Verbrauch bei der Antworterzeugung wird auch dann erfasst, wenn die Prüfung die Antwort verwirft.
  • In der verwalteten Kanalanbindung werden Gruppennachrichten nur bei ausdrücklicher Erwähnung zugeordnet.
  • Die Konsole zeigt laufende Verdichtung und die wirksamen Schwellenwerte an.
  • Das Arbeitsbudget für frühe Verdichtung und die Sicherheitsreserve an der Anfragegrenze bleiben über Updates hinweg erhalten.
  • Update-Dialog beim Start, Fortschritt und Hinweise auf vorgemerkte Updates verwenden durchgehend die ausgewählte Sprache.
  • Technische Integrationskennungen und Lizenzen bleiben erhalten; sichtbare Laufzeitfehlermeldungen werden neutral formuliert.
  • Die Installation startet bestehende Sitzungen nicht neu. Eine laufende Sitzung lädt den neuen Code beim nächsten Start.

9.1.588: zurückgezogen

Veröffentlicht am

Diese Fassung wurde am 11. September 2026 veröffentlicht und anschließend in npm als zurückgezogen markiert. Die Registry nennt eine fehlgeschlagene Kompatibilitätsprüfung des Update-Manifests. Verwende die aktuelle stabile Fassung, nicht dieses zurückgezogene Paket.

Neu in 9.1.587

Veröffentlicht am

Stabilere Werkzeugkataloge, frühere automatische Verdichtung und ein gezielter Wiederholungsversuch nach Abbrüchen wegen zu langer reiner Denkphasen.

Bei gepufferten Anweisungen innerhalb eines laufenden Arbeitsturns bleibt der aktive Werkzeugkatalog auch im anschließenden Arbeitsschritt erhalten. Benötigte Werkzeuge bleiben verfügbar. Wird das bestehende Schema-Budget überschritten, werden beibehaltene optionale Werkzeugdefinitionen neu ausgewählt.

Die automatische Kontextverdichtung setzt wieder früher ein. Nach einer erfolgreichen Verdichtung, die den Verlauf verkleinert, kann King sie im selben Turn erneut ausführen. Niedrigere Modellgrenzen und die Begrenzung fehlgeschlagener Versuche bleiben wirksam.

Nach einem Abbruch wegen zu langer reiner Denkphase nutzt King den bestehenden einmaligen Wiederholungsversuch mit ausgeschaltetem Denken, damit das Modell antworten oder ein Werkzeug aufrufen kann. Die folgenden regulären Schritte behalten die gewählte Denkeinstellung; Abbruch, Freigabeprüfungen und Zeitgrenzen bleiben wirksam.

Mit BLUN_STABLE_STEER_TOOLS=0 oder BLUN_EARLY_COMPACTION=0 vor dem Start von King lässt sich für die jeweilige Funktion das bisherige Verhalten wiederherstellen. Das Update schreibt keine bestehenden Sitzungen oder Konfigurationsdateien um.

Neu in 9.1.586

Veröffentlicht am

Der Telegram-Empfang startet unter Windows wieder, wenn die alte Prozess-ID der Bridge inzwischen zu einem anderen Prozess gehört. Bei unsicherer Prozesszuordnung greift King nicht ein; der fremde Prozess wird nicht beendet.

Kontextverdichtung, Modelleinstellungen, Gesprächsverlauf und das bisherige Zustellverhalten von Telegram bleiben unverändert.

Neu in 9.1.585

Veröffentlicht am

BLUN King · 8. September 2026

Version 9.1.585 prüft die Struktur und die einzelnen Treffer verwalteter WebSearch-Antworten auch dann, wenn die optionalen Angaben zum Suchstatus fehlen.

Eine Antwort ohne gültige Trefferliste wird nicht mehr als erfolgreiche Suche ohne Ergebnisse ausgegeben. Jeder Treffer muss einen Titel, der weder leer ist noch ausschließlich aus Leerraum besteht, einen Textauszug als Zeichenfolge und eine absolute HTTP- oder HTTPS-Adresse ohne eingebettete Zugangsdaten enthalten. Ungültige Treffer führen dazu, dass die gesamte Antwort zurückgewiesen wird, bevor Ergebnisse oder Hinweise auf unvollständige Suchergebnisse zurückgegeben werden.

Gültige Antworten im bisherigen Format ohne Statusangaben werden weiterhin unterstützt, ebenso leere Trefferlisten und leere Zeichenfolgen als Textauszüge. Bei gültigen Antworten bleiben die Reihenfolge, die exakten URL-Zeichenfolgen, optionale Datums- und Website-Angaben, die Quellenangaben in der Ausgabe und die Verarbeitung unvollständiger Ergebnisse unverändert.

Geändert wird nur die verwaltete Suchanbindung. Abbruchverhalten, Authentifizierung der Anfragen, FetchURL und Telegram bleiben unverändert. Die Formatprüfung belegt nicht, dass eine Quelle korrekt oder aktuell ist. Diese Version führt weder eine Größenbegrenzung für Antworten noch ein neues Zeitlimit ein.

Neu in 9.1.584

Veröffentlicht am

Version 9.1.584 reicht das Abbruchsignal des Aufrufers durch WebSearch bis zur verwalteten HTTP-Suchanfrage weiter, auch beim Lesen des Antwortinhalts.

Bereits abgebrochene Suchen lösen keine Verarbeitung beim Anbieter aus. Erfolgt der Abbruch während der Ermittlung der Zugangsdaten, wird danach keine Suchanfrage mehr gesendet. Ergebnisse, die nach dem Abbruch eintreffen, werden nicht als erfolgreiche Suche zurückgegeben.

Die Abbruchprüfungen erfassen auch erfolgreiche JSON-Antworten, den Inhalt von Fehlerantworten und Hinweise auf unvollständige Suchergebnisse. Die Verarbeitung vollständiger, unvollständiger und leerer Ergebnisse, die Quellenangaben und das reguläre Ausweichverfahren bei der Authentifizierung bleiben unverändert.

Diese Version führt kein neues Zeitlimit ein und ändert die Telegram-Zuordnung nicht. Gemeinsam genutzte Vorgänge zur Erneuerung der OAuth-Zugangsdaten und Transportimplementierungen, die Abbruchsignale ignorieren, werden nicht zwangsweise unterbrochen. Der Abbruch einer Client-Anfrage belegt nicht, dass die Arbeit auf dem entfernten Server oder deren Abrechnung beendet ist.

Neu in 9.1.583

Veröffentlicht am

Ein Abbruch beim Seitenabruf wird jetzt bis zur HTTP-Anfrage weitergegeben.

FetchURL gibt das Abbruchsignal des Aufrufers durch das Werkzeug und beide Abrufdienste weiter. Eine vor dem Start abgebrochene Anfrage wird nicht gesendet. Erfolgt der Abbruch während der Ermittlung der Zugangsdaten, wird die verwaltete HTTP-Anfrage danach nicht mehr gestartet.

Nach dem Abbruch eines verwalteten Abrufs wird kein lokaler Ersatzabruf mehr gestartet. Ein verspätetes Ergebnis des Abrufdienstes wird zurückgehalten und nicht als Quellenbeleg verwendet. Bei gewöhnlichen HTTP- und Netzwerkfehlern bleibt der bisherige lokale Ersatzabruf möglich.

Es wird keine neue Zeitgrenze eingeführt. Eine gemeinsam genutzte Erneuerung der Zugangsdaten und die synchrone HTML-Verarbeitung werden nicht zwangsweise unterbrochen. Die Größenbegrenzung aus 9.1.582 bleibt bestehen; Telegram-Routing und Modellanfragen bleiben unverändert.

Neu in 9.1.582

Veröffentlicht am

Der lokale Seitenabruf prüft die Antwortgröße jetzt schon beim Einlesen und bricht bei Überschreitung der Grenze ab.

Der lokale Abruf zählt die eingehenden Antwortbytes vor der Dekodierung jedes Datenblocks und bricht den Datenstrom ab, sobald die Größenbegrenzung überschritten wird. Fehlt die Content-Length-Angabe oder ist sie falsch, wird nicht mehr erst die gesamte Antwort eingelesen und dann zurückgewiesen.

Die voreingestellte Grenze bleibt bei zehn MiB und gilt für den Antwortstrom nach der HTTP-Dekomprimierung. Über mehrere Datenblöcke verteilte UTF-8-Zeichen bleiben erhalten. Transportpuffer und der Datenblock, mit dem die Grenze überschritten wird, können bereits im Speicher liegen; eine exakte Obergrenze für den gesamten Prozessspeicher ist damit nicht verbunden.

Geändert wird der lokale Abrufweg, auch wenn er als Rückfalllösung dient. Die Recherche-Korrekturen aus 9.1.581 bleiben enthalten. Telegram-Routing und die Wartezeit auf das Modell bleiben unverändert.

Neu in 9.1.581

Veröffentlicht am

Beim lokalen Seitenabruf werden leere HTML-Auszüge nicht mehr als erfolgreiche Quellen ausgegeben.

Bleibt nach der Bereinigung und Umwandlung kein Seiteninhalt übrig, reicht der Dokumenttitel allein nicht mehr für einen erfolgreichen Abruf. Stattdessen wird der bereits vorhandene Extraktionsfehler zurückgegeben.

Kurze echte Inhalte und sichtbare Überschriften bleiben erhalten. Antworten im Klartext- oder Markdown-Format bleiben unverändert. Die Korrektur betrifft die lokale HTML-Extraktion, nicht den verwalteten Abrufdienst.

Die Recherche-Korrekturen aus 9.1.580 und die bisherigen Telegram-Korrekturen sind unverändert enthalten. Dieses Update ändert weder die Wartezeit auf das Modell noch die Zuordnung eingehender Nachrichten zu ihren Empfängern.

Neu in 9.1.580

Veröffentlicht am

Die Rechercheablage weist ungültige historische Datumsangaben zu Quellen zurück.

Ein neuer Bericht wird nicht gespeichert, wenn eine Datumsangabe zu einer Quelle einen ungültigen Kalendertag oder einen nicht auswertbaren Zeitanteil enthält. Fehlende Datumsangaben bleiben zulässig.

Beim Abruf gespeicherter Recherchebelege werden ältere Belege mit ungültigen Datumsangaben zu Quellen übersprungen und mit einem Diagnosehinweis gemeldet. Die Dateien werden weder umgeschrieben noch gelöscht. Separate gültige Belege bleiben durchsuchbar; gültige Datumsangaben behalten ihren Zeitzonenversatz und ihre Genauigkeit.

Die Sortierung der Recherchebelege aus 9.1.579 und die bisherigen Telegram-Korrekturen sind unverändert enthalten. Dieses Update ändert weder die Wartezeit auf das Modell noch die Zuordnung eingehender Nachrichten zu ihren Empfängern.

Neu in 9.1.579

Veröffentlicht am

Gespeicherte Recherchebelege werden bei gleicher Relevanz nach ihrem tatsächlichen Abrufzeitpunkt sortiert.

Zeitangaben mit und ohne Millisekunden werden als UTC-Zeitpunkte verglichen, nicht als Text. Die Relevanz hat weiterhin Vorrang; bei identischen Zeitpunkten bleibt die bisherige Reihenfolge erhalten.

Wurde dieselbe Textstelle mehrfach erfasst, behält das Ergebnis die Herkunftsangaben des neuesten Abrufs. Bereits gespeicherte Belege bleiben unverändert und gelten dadurch nicht als neu geprüfte Quellen.

Die Korrektur für Telegram-Antworten aus 9.1.578 ist unverändert enthalten. Dasselbe gilt für die Begrenzung erneuter Versuche, wenn das Modell ausschließlich nachdenkt, ohne eine Antwort oder einen Werkzeugaufruf zu liefern. Dieses Update ändert weder die Wartezeit auf das Modell noch die semantische Zuordnung eingehender Nachrichten.

Neu in 9.1.578

Veröffentlicht am

Begrenzte Wiederholungen, wenn das Modell nur nachdenkt und dabei die Zeitgrenze erreicht, sowie eine gezielte Korrektur für kurze Telegram-Gruppenantworten mit Bezug auf eine Frage.

Erreicht das Modell die Zeitgrenze, während es nur nachdenkt, lässt King pro Schritt einen weiteren Versuch zu. Eine zweite solche Zeitüberschreitung beendet den Schritt. Der gewählte Denkaufwand und die bisherige Zeitgrenze bleiben unverändert. Diese Begrenzung verkürzt nicht das Warten auf die erste Modellausgabe.

Kurze Rückmeldungen zur eigenen Anwesenheit in Telegram-Gruppen dürfen jetzt gesendet werden, wenn reply_to sie mit einer höchstens 30 Minuten alten Eingabe aus demselben Chat verknüpft. Diese Eingabe muss den Agenten ausdrücklich ansprechen oder einer unterstützten deutschen oder englischen Frage nach seiner Anwesenheit entsprechen, die mit seinem eingestellten Namen beginnt. Ungefragte Anwesenheitsmeldungen und Erklärungen, dass es nichts zu melden gibt, werden weiterhin gefiltert. Der automatische Ersatzversand in Gruppen bleibt abgeschaltet.

Protokolle gesendeter und unterdrückter Antworten enthalten jetzt reply_to. Bei fehlendem oder uneindeutigem Kontext gilt die Ausnahme nicht. Dieses Update ergänzt keine allgemeine Empfängererkennung und verhindert keine unnötigen Modellaufrufe durch die bisherige semantische Adressierung.

Die Korrektur gilt für zwei exakt identifizierte Versionen verwalteter Telegram-MCP-Sender und greift auch beim abschließenden Zusammenführen der Plugin-Konfiguration. Der ältere Sender verwendet eine Kompatibilitätskopie mit eng begrenzten Änderungen. Eingangsbrücken, Zugriffseinstellungen, Profile und Plugin-Register werden nicht umgeschrieben. Unbekannte oder angepasste Sender sowie ausdrücklich gesetzte Überschreibungen bleiben erhalten. King muss nach dem Update neu gestartet werden, damit die Korrektur geladen wird.

Neu in 9.1.577

Veröffentlicht am

Keine automatischen Abschlussmeldungen mehr in Telegram-Gruppen. Nützliche Antworten werden dort gezielt über das Telegram-Antwortwerkzeug gesendet.

Der CLI-Kern und die eigenständige Telegram-Brücke leiten den normalen Abschlusstext eines Agenten nicht mehr automatisch an Gruppen weiter. So gelangen Hinweise wie „Nichts zu melden“ nicht mehr über diesen automatischen Ersatzversand in die Gruppe.

Antworten in Privatchats, ausdrücklich verwendete Antwortwerkzeuge, erforderliche Zielergebnisse, Befehls- und Statusmeldungen sowie der Medienversand bleiben erhalten. Die Prompt-Anweisungen für normale Eingaben, steuernde Nachrichten während eines laufenden Vorgangs und Gruppennachrichten der eigenständigen Brücke enthalten jetzt dieselbe Versandregel.

Das garantiert nicht, dass ein Modell niemals eine unnötige Antwort per Werkzeugaufruf sendet. Der Fix verhindert auch nicht, dass Gruppennachrichten ohne Bezug zum jeweiligen Agenten das Modell erreichen. Erwähnungsregeln, Zugriffseinstellungen und die Auflösung verwalteter Plugins bleiben unverändert; ein Update von AgentSpine oder des Sprachwächters ist nicht enthalten.

Der aktualisierte Kern muss von einem neuen Prozess geladen werden. Laufende Sitzungen werden nicht automatisch neu gestartet. Bestehende Profile und der Sitzungsverlauf bleiben erhalten.

Neu in 9.1.576

Veröffentlicht am

BLUN King 9.1.576 unterscheidet C++ und C# bei lokalen Rechercheabfragen und enthält die zuvor veröffentlichten Korrekturen für Updates, die Wiederaufnahme von Sitzungen und Telegram.

Die Suche in lokalen Recherchebelegen behandelt alleinstehendes C++ und C# als unterschiedliche Begriffe, auch bei abweichender Groß- und Kleinschreibung und mit umgebenden Satzzeichen. Gespeicherte Textstellen, Hashes, Schutzprüfungen für Quellen, Unicode-Normalisierung, Sammlungsgrenzen und Ausgabelimits bleiben unverändert. Eine Neuindexierung ist nicht erforderlich.

Ein festgelegter Prüflauf mit 20 technischen Suchanfragen und gezielte Regressionstests für Token-Grenzen prüfen diese Korrektur. Sie betrifft die lokale Suche und ist keine Aussage zur Qualität oder Kapazität von WebSearch im Livebetrieb. Alle Änderungen aus 9.1.575 bleiben enthalten.

Neu in 9.1.575

Veröffentlicht am

Der gebündelte Webcrawler weist Antworten mit cf-mitigated: challenge zurück, bevor er Inhalte liest, Weiterleitungen folgt oder eine fehlende robots-Datei als Erlaubnis zum Fortfahren wertet. Bei Headernamen berücksichtigt er Groß- und Kleinschreibung nicht; außerdem prüft er normalisierte Werte und mehrfach vorkommende Header. Der Antwortstatus bleibt im Fehlerbericht erhalten.

Fehlende robots-Dateien ohne diese Kennzeichnung und gewöhnliche Dokumentationsseiten durchlaufen weiterhin den bestehenden Ablauf. Bereits abgeschlossene Seiten bleiben verfügbar, wenn eine spätere Seite abgewiesen wird; der Fehler wird als unvollständiges Ergebnis gemeldet. Dieser Schutz prüft eine Antwortkennzeichnung. Er ist weder eine allgemeine Challenge-Erkennung noch eine CAPTCHA-Umgehung. Suchanbieter, Authentifizierung, Updatesperren und CLI-Kern bleiben unverändert. Alle Änderungen aus 9.1.574 bleiben enthalten.

Neu in 9.1.574

Veröffentlicht am

Ausdrücklich angeforderte Updates unterscheiden jetzt zwischen einem blockierten Update, einer nicht verfügbaren Sperrprüfung, einem nicht verfügbaren privaten Verzeichnis, einer ungültigen installierten Version und einem nicht verfügbaren geschützten Installer. Diese Fälle werden nicht mehr pauschal als fehlgeschlagene Paketprüfung gemeldet. Die Änderung gilt für deutsche und englische Meldungen.

Updatezulassung, Sperrverhalten, Rückgabegründe, Exit-Codes und Installerverhalten bleiben unverändert. Laufende Sitzungen werden nicht automatisch beendet. Pakete, die auf einen alten internen Kanal festgelegt sind, benötigen weiterhin eine ausdrückliche npm-Installation bei beendetem King; diese Version hebt die Festlegung nicht auf. Alle Änderungen aus 9.1.573 bleiben enthalten.

Neu in 9.1.573

Veröffentlicht am

Das Eingabefeld bleibt nach der Zielauswahl beim Start sichtbar und fokussiert, auch nach Escape oder einer fehlgeschlagenen Zielwiederaufnahme. Ungesendete Entwürfe bleiben erhalten. Statt des vollständigen Zieltexts erscheint eine kompakte Auswahl zum Fortsetzen mit oder ohne Ziel.

Strg+S verlässt die Auswahl, ohne das Ziel zu bestätigen, und wird als reguläres Tastenkürzel für die Warteschlange verarbeitet. Auch ausstehende Eingaben im Leerlauf werden berücksichtigt. Escape behält seine bisherige Reihenfolge: zuerst die Warteschlange leeren, beim nächsten Escape den aktiven Durchlauf abbrechen. Der Sitzungsverlauf wird nicht automatisch gelöscht.

Diese Version rekonstruiert keine Zustellbestätigungen, die ein älterer Prozess vor dem Update verloren hat. Tatsächlich ausstehende Nachrichten bleiben ihrer Sitzung zugeordnet.

Neu in 9.1.572

Veröffentlicht am

Bei Recherchebelegen werden Quellen-URLs zurückgewiesen, deren Abfrageparameter oder parameterförmige Fragmente bekannte Parameternamen für Zugangsdaten enthalten. Auch verschachtelte Namen und Routen im Fragment werden geprüft. Die Ablehnung gilt sowohl für fehlgeschlagene als auch für nutzbare Quellen.

Bereits gespeicherte Berichte mit solchen URLs werden beim Abruf mit dem bestehenden Ergebnis partial / report-invalid zurückgehalten. Ursprünglich gespeicherte Stände werden weder verändert noch gelöscht; Quellenadressen werden nicht stillschweigend gekürzt oder umgeschrieben. Gewöhnliche Abfrageparameter und Anker in Dokumentations-URLs bleiben bytegetreu erhalten. Der Schutz erkennt bekannte Parameternamen, nicht beliebige Geheimnisse, und bereinigt keinen Verlauf.

Neu in 9.1.571

Veröffentlicht am

Bereiche der Telegram-Warteschlange werden ihrer Sitzung zugeordnet. Eine neue Sitzung übernimmt nicht mehr automatisch die ausstehende Arbeit einer älteren Sitzung. Beim Fortsetzen einer bekannten Sitzung werden nur deren eigene wartende Bereiche wiederhergestellt. Während Auswahl, Erstellung und Wechsel einer Sitzung pausiert die Übernahme von Kanalnachrichten. Nachrichten, die nach der gewählten Grenze eingehen, Folgeeingaben im lokalen Editor und verspätete Zustellbestätigungen behalten ihre richtige Zuordnung.

Die Zuordnung und in abweichender Reihenfolge eintreffende Zustellbestätigungen bleiben bei erneuter Anbindung und Übergabe einer Lease erhalten. Beschädigter oder ausgetauschter Warteschlangenzustand wird abgewiesen, statt alte Eingaben unbemerkt erneut abzuspielen. Posteingang und Sitzungsverlauf bleiben erhalten. Alte wartende Bereiche ohne erkennbare Sitzung werden zurückgestellt und keiner neuen Sitzung zugewiesen; ihre automatische Wiederherstellung ist nicht enthalten. Das behebt nicht jede Zeitüberschreitung oder blockierte Kontextverdichtung. Ein Downgrade ist kein Verfahren zur Migration der Warteschlange.

Das Telegram-Plugin und die unabhängige Ausweichfunktion der Konsole für den automatischen Antwortversand unterdrücken erkannte Empfangsbestätigungen und Texte, die lediglich das eigene Schweigen ankündigen, auch oberhalb von 200 Zeichen. Enthält eine Nachricht einen nicht erkannten oder inhaltlich relevanten Satzteil, bleibt sie erhalten. Kurze nützliche Gruppenwarnungen können weiterhin zugestellt werden. Das ist ein vorsichtiger deutsch-englischer Versandfilter mit ergänzenden Anweisungen, keine Garantie, dass jedes Modell jedes Gruppengespräch versteht.

Ein neuer Prozess muss das aktualisierte Paket laden; laufende Sitzungen werden nicht neu gestartet. Bestehende Festlegungen auf interne Updatekanäle und Windows-Installationssperren mit EBUSY bleiben getrennte Probleme. Alle übrigen Änderungen aus 9.1.570 bleiben enthalten. Diese Version aktiviert keine gehostete Websuche und ändert weder AgentSpine noch Abrechnung, Authentifizierung oder Kundenkonfiguration.

Neu in 9.1.570

Veröffentlicht am

Jede neue Promptzustellung erhält eine eigene Hook-Korrelations-ID. Hooks derselben Zustellung behalten dieselbe ID; ausdrücklich gesetzte IDs bleiben erhalten. Sitzungsspezifische Umgebungswerte erreichen Hook-Unterprozesse und MCP-Verbindungen auch beim Wiederverbinden, ohne gespeicherte Plugin-Konfigurationen umzuschreiben. Die Zuordnung nativer Werkzeugergebnisse bleibt über Durchläufe hinweg erhalten, auch bei fehlgeschlagenen Werkzeugen und doppelten Aufrufen.

Kanonisch gleichwertige Unicode-Rechercheabfragen finden dieselben Treffer, ohne unterschiedliche Zeichen gleichzusetzen. Gespeicherte Quellen, Datumsangaben, Versionen und Projektgrenzen bleiben erhalten. king --help und king --version ändern keine Windows-Registrierungseinstellungen für Absturzabbilder mehr.

Die Websuche unterstützt Teilantworten, wenn dieser Antwortmodus vereinbart wurde, und zeigt dabei einen Hinweis auf ausgefallene Quellen. Leere oder inkompatible Teilantworten bleiben ausdrückliche Fehler. Diese Clientänderung aktiviert keinen gehosteten Suchdienst und garantiert dessen Betrieb nicht.

Der Transport BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE ist standardmäßig ausgeschaltet. Bei ausdrücklicher Aktivierung übergibt er den tatsächlichen Pfad des gespeicherten Sitzungsprotokolls und das zugehörige Protokoll an das ausgewählte AgentSpine-Plugin. Jede Sitzung erhält eine eigene Zugriffsberechtigung, nach einer Wiederaufnahme wird sie erneuert. Das ist Transportunterstützung, kein Nachweis für Erinnerungsabruf oder Autorisierung durch das empfangende Plugin.

Alle öffentlichen Änderungen aus 9.1.569 bleiben enthalten. Die gebündelte AgentSpine-Implementierung bleibt unverändert; es entsteht keine Mnemo-Abhängigkeit. Benutzerprofile, Berechtigungen, Gespräche und Plugin-Einstellungen werden weder migriert noch zurückgesetzt.

Neu in 9.1.569

Veröffentlicht am

Diese kumulative öffentliche Version enthält die Zustellung in Telegram-Gruppen anhand von Erwähnungen, Korrekturen für Start und Berechtigungen sowie Recherchesammlungen und Crawler-Werkzeuge. Veröffentlichte Pakete bleiben unverändert. Spätere Änderungen erscheinen unter einer neuen Versionsnummer.

Neu in 9.1.566

Veröffentlicht am

BLUN King 9.1.566 macht Plugin-Aktualisierungen und das Laden nativer Laufzeitmodule robuster.

Die gebündelte AgentSpine-Laufzeit wird auf Version 0.59.1 aktualisiert. Ihr Selbststarter überspringt den Stamm eines Benutzerprofils als Scan-Ziel, und alle Lebenszyklus-Hooks bleiben ausfallsicher, wenn ein geschützter Pfad nicht gelesen werden kann.

Native .node-Module werden über einen inhaltsadressierten Zwischenspeicher außerhalb des npm-Pakets aufgelöst. Sobald diese Version aktiv ist, hält eine laufende Konsole die Paketkopie dieser Module nicht mehr geöffnet. Spätere Aktualisierungen können das Paketverzeichnis dadurch ersetzen, ohne mit diesen nativen Dateien zu kollidieren.

Das öffentliche Paket behält die vollständigen spanischen, französischen, schwedischen und tschechischen Oberflächenkataloge aus Version 9.1.565. Interne Mnemo-Laufzeitpfade, private Endpunkte, interne Modellanbieter und Bau-Skripte sind nicht enthalten.

Geprüfter Paketstand

Das Kundenpaket hat den Leck-Scan, die vollständige Laufzeitprüfung mit 13 Tests, die AgentSpine-MCP-Initialisierung, eine frische Installation und die Aktualisierung von 9.1.565 bestanden. Alle Textdateien verwenden LF-Zeilenenden. SHA-256 des npm-Pakets: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Neu in 9.1.565

Veröffentlicht am

BLUN King 9.1.565 stabilisiert lange Arbeitsläufe und erweitert die gebündelte AgentSpine-Laufzeit.

Die Wiederholungsbremse setzt ihre Folge gleichwertiger Ergebnisse zurück, sobald dazwischen echte Arbeit vorankommt. Normale Posteingangs- und Aufgabenlistenprüfungen lösen dadurch keine falsche erzwungene Antwort mehr aus.

Die Aktivitätsanzeige besteht aus genau einer Zeile. Sie zeigt das zur aktuellen Tätigkeit passende englische Statuswort, Tokens des verdeckten Denkens, sichtbare Tokens, Gesamtverbrauch, Effort, Versuch, Budget und Schritt.

AgentSpine-Scanfehler bleiben bei Mutationswerkzeugen, Nutzereingaben und Stop-Hooks ausfallsicher: Der folgende Ablauf darf weiterlaufen und der Fehler wird im Auditprotokoll festgehalten. Vor einem fatalen Abbruch durch eine Ausnahme oder eine unbehandelte Ablehnung schreibt die Konsole das Laufzeitprotokoll synchron.

Die gebündelte AgentSpine-Laufzeit wird auf Version 0.54.0 aus Commit fb6d456b68605fd83721090e503f000a26e8a0fb aktualisiert. Der Stand enthält den echten ACL-Fail-open-Test, dauerhafte abhängigkeitsgebundene Zielpläne und die gebundene Klärung von Wissenslücken.

Die Lebenszyklus-Hooks SessionStart, UserPromptSubmit, PostToolUse und Stop werden mit der exakten MNEMO_AGENT-Identität an Mnemo gesendet. Netzwerkfehler bleiben ausfallsicher.

Die zuvor fehlenden Oberflächentexte sind auf Spanisch, Französisch, Schwedisch und Tschechisch vollständig.

Geprüfter Paketstand

Das vollständige Paket-Gate, der Leck-Scan, die Prüfung des Sprachkatalogs, die ACL-Hakenprobe, die frische Installation, die Aktualisierung von 9.1.564 und die AgentSpine-MCP-Initialisierung sind grün. SHA-256 des npm-Pakets: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Neu in 9.1.564

Veröffentlicht am

BLUN King 9.1.564 verhindert Abstürze durch geschützte Ordner und fehlende Oberflächentexte.

AgentSpine überspringt beim vorbereitenden Dateiscan einzelne Dateien und Ordner, die das Betriebssystem mit EPERM oder EACCES sperrt. Ein unerwarteter Scanfehler blockiert den folgenden Werkzeugaufruf nicht mehr; er wird freigegeben und im Auditprotokoll festgehalten.

Fehlt in einer veröffentlichten Oberflächensprache ein Textschlüssel, verwendet die Konsole den englischen Text und protokolliert die Lücke einmalig, statt im Renderpfad abzustürzen. Damit bleibt insbesondere die Denkstatuszeile unter Tschechisch, Spanisch, Französisch und Schwedisch bedienbar.

Die eigentlichen Übersetzungen der noch fehlenden Schlüssel folgen in einer getrennt geprüften Version. Bis dahin ist der englische Rückfall bewusst sichtbar und ausfallsicher.

Geprüfter Paketstand

Das Paket wurde gegen den exakten tschechischen thinking.step-Absturz aus 9.1.563 geprüft. Die neue Version liefert „step 6“ statt einer Ausnahme, warnt nur einmal je Sprache und Schlüssel, übersteht unzugängliche Nachbarordner, initialisiert AgentSpine 0.49.0, besteht eine frische Installation sowie die Aktualisierung von 9.1.563 und enthält keine unaufgelösten Plugin-Importe. SHA-256 des npm-Pakets: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Neu in 9.1.563

Veröffentlicht am

BLUN King 9.1.563 aktualisiert die gebündelte AgentSpine-Laufzeit auf Version 0.49.0.

Der neue Stand verlangt vor einem Lernversuch mindestens einen frischen, unabhängigen Beleg aus einer ausdrücklichen Nutzerbestätigung oder einem objektiven Test. Reine Gesprächs- oder Dokumentbelege reichen nicht mehr aus, auch wenn ihre übrigen Schwellenwerte erfüllt sind.

Lernverträge binden diese Belegregel dauerhaft; spätere Konfigurationsänderungen können eine laufende Prüfung nicht abschwächen. Besitzgebundene Dateisperren schützen parallele Lernänderungen vor Überschreiben und lassen manipulierte oder fremde Sperren geschlossen scheitern.

Die Aktualisierung ersetzt den verwalteten Plugin-Baum beim nächsten Start inhaltsadressiert. Bestehende Installationen der Version 9.1.562 werden auf AgentSpine 0.49.0 aktualisiert, ein unveränderter Baum wird wiederverwendet, und der AgentSpine-MCP-Server bestätigt Version 0.49.0.

Geprüfter Paketstand

Die Paketgrenze unterscheidet sich von 9.1.562 nur durch die Versionsangaben und die exakt gepinnte AgentSpine-0.49.0-Laufzeit. Die vollständige Upstream-Prüfung, 49 gezielte Lerntests, der Paketvergleich, der Leck-Scan, die frische Installation, der echte Aktualisierungsweg von 9.1.562 und eine MCP-Initialisierung sind grün. SHA-256 des npm-Pakets: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Neu in 9.1.562

Veröffentlicht am

BLUN King 9.1.562 stellt die AgentSpine-Laufzeitdatei im öffentlichen Paket wieder her.

Die vom gebündelten AgentSpine-MCP-Server benötigte Laufzeitdatei wird wieder mitgeliefert. Eine frische Installation materialisiert das Plugin vollständig; der MCP-Server startet und bestätigt seinen Namen und seine Protokollversion.

Geprüfter Paketstand

Die Paketgrenze unterscheidet sich von 9.1.561 nur durch die Versionsmetadaten und die wiederhergestellte Laufzeitdatei. Der Leck-Scan, die frische Installation, die Plugin-Materialisierung und eine echte MCP-Initialisierung sind grün. SHA-256 des npm-Pakets: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Neu in 9.1.561

Veröffentlicht am

BLUN King 9.1.561 übernimmt die geprüften Verbesserungen des Arbeitssystems in das öffentliche Paket.

Der aktuelle Auftrag und frische Werkzeugergebnisse bleiben verfügbar. Leseergebnisse werden nicht gekürzt. Große Ergebnisse werden mit einem Verweis zum erneuten Abruf gespeichert, statt geleert zu werden. Wiederholte identische Ergebnisse verweisen auf das neueste vollständige Ergebnis.

Verdichtungen werden als Transaktion mit Start-, Zusammenfassungs- und Endmarkierung protokolliert. Werkzeugaufrufe und ihre Ergebnisse bleiben zusammen, während dauerhafte Prüfpunkte den Wiederherstellungsweg über erneute Versuche hinweg sichern.

Die Ausgabebudgets stammen nun aus dem aktiven Modellprofil. Das verwaltete BLUN-Modell erhält standardmäßig 128.000 Ausgabetokens, wenn kein Wert ausdrücklich gesetzt ist. Die alten festen Grenzen von 32.768 Tokens sowie die niedrigen Grenzen für low und off kürzen komplexe Arbeit nicht mehr; die Kontextkapazität bleibt die Sicherheitsgrenze.

Der Updater fragt, bevor er den Installer vorbereitet oder startet. Im öffentlichen Paket bleibt das verwaltete BLUN-Modell fest eingestellt; /model dient nur noch als Kompatibilitätsalias für /effort.

Die Paketgrenze wurde über alle Dateinamen und lesbaren Inhalte geprüft. Interne Providerwege, die Modellwahl, Bau- und Regressionsskripte, private Kennungen und private Serveradressen sind nicht enthalten.

Geprüfter Paketstand

Das vollständige Paket, der Leck-Scan, die frische Installation, Versions- und Hilfeausgabe, die Standardeinstellungen eines neuen Profils sowie die Update-Entscheidung von 9.1.550 auf 9.1.561 sind grün. SHA-256 des npm-Pakets: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Neu in 9.1.527

Veröffentlicht am

BLUN King 9.1.527 übernimmt den /copy-Ablauf aus DeepAgents.

Der Befehl kopiert die neueste abgeschlossene, nicht leere Assistentenantwort über den vorhandenen plattformübergreifenden Zwischenablagepfad.

Wird /copy während eines laufenden Zugs eingegeben, nutzt der Befehl die vorhandene Befehlswarteschlange und wird nach Abschluss der Antwort ausgeführt.

Klare Statusmeldungen decken Erfolg, einen leeren Verlauf und Fehler der Zwischenablage in allen sechs Oberflächensprachen ab.

Eine Rot-zu-Grün-Regression schützt Befehlsregistrierung, Ausführung, Auswahl der Antwort, bytegetreuen Inhalt der Zwischenablage und die freigegebenen Oberflächentexte.

Geprüfter Paketstand

Das vollständige Prepack und die Prüfung des entpackten Artefakts sind grün. SHA-256 des npm-Pakets: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Neu in 9.1.526

Veröffentlicht am

BLUN King 9.1.526 materialisiert die mit dem aktuellen Paket gebündelte AgentSpine-Version, bevor /reload den Plugin-Katalog und die MCP-Konfiguration neu aufbaut.

Nicht betroffene Plugin-Einträge bleiben erhalten. Ein unveränderter verwalteter AgentSpine-Baum wird wiederverwendet, ohne installed.json neu zu schreiben.

Eine Rot-zu-Grün-Regression gegen 9.1.525 schützt die Bootstrap-Reihenfolge, die Übernahme des verwalteten Plugins und das idempotente Verhalten beim Neuladen.

Geprüfter Paketstand

Das vollständige Prepack, die Prüfung des gepackten Artefakts und der isolierte Updatertest von 9.1.525 auf 9.1.526 sind grün. SHA-256 des npm-Pakets: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Neu in 9.1.525

Veröffentlicht am

BLUN King 9.1.525 startet jeden lokalen Shell-Befehl unter Windows und POSIX in einer eigenen Prozessgruppe. Programme können sich dadurch nicht mehr an die steuernde Konsole der BLUN-TUI anhängen und Escape, Strg+S oder andere Editoreingaben abfangen.

Standardeingabe, Standardausgabe und Fehlerausgabe bleiben in privaten Pipes. Interaktive Befehle erhalten ein Dateiende und schlagen fehl oder laufen in eine Zeitüberschreitung, ohne mit dem Editor um Eingaben zu konkurrieren.

Die lokale Shell-Isolierung aus DeepAgents wurde für Windows übernommen. Ein ausführbarer Regressionstest deckt beide Plattformpfade und eine echte Probe mit einem abgefangenen Prozess ab.

Neu in 9.1.524

Ohne Datum

BLUN King 9.1.524 hält den von einem Telegram-Befehl /loop erzeugten Sofortauftrag im geschützten Zustellpfad für Fernbefehle. Er kann dadurch nicht als zweiter gewöhnlicher Warteschlangeneintrag übrig bleiben.

Die Wiederaufnahmeliste zeigt für jede Sitzung die Größe des Wiederaufnahme-Checkpoints, die beibehaltenen Nachrichten und Tokens, die Größe des Sitzungsverlaufs sowie fehlende, ungültige oder veraltete Checkpoints.

Die gebündelte AgentSpine-Laufzeit wird auf den geprüften offiziellen Stand 0.11.4 mit Commit 8034487cdd24498076bac48d3f24400bca5e6ae4 aktualisiert. Das BLUN-Zeitbudget von 180 Sekunden für den SessionStart-Hintergrundabschluss bleibt erhalten.

Ausführbare Regressionstests schützen die genau einmalige Zustellung von Telegram-Loops und alle Zustände der Wiederaufnahmemesswerte. Das vorhandene lokale Warteschlangenverhalten bei beschäftigtem Loop bleibt unverändert.

Neu in 9.1.523

Veröffentlicht am

BLUN King 9.1.523 lässt Escape ein geöffnetes Slash-Befehlsmenü schließen und den zugehörigen Entwurf in einem Schritt leeren, statt den Befehlstext zurückzulassen.

Strg+S übergibt einen Slash-Entwurf auch dann an den vorhandenen Einreihungs- und Abarbeitungspfad, wenn die Oberfläche gerade Leerlauf meldet, statt vor dem Leeren der Warteschlange still zurückzukehren.

Normale Entwürfe bleiben erhalten, wenn Escape lediglich eine andere Autovervollständigung schließt.

Rot-zu-Grün-Laufzeittests schützen beide Tastenkürzel gegen das genaue Verhalten des Pakets 9.1.522.

Neu in 9.1.522

Ohne Datum

BLUN King 9.1.522 schreibt permission.approval_requested sofort beim Öffnen einer Werkzeugfreigabe in den Sitzungsverlauf. Ein unbeaufsichtigter King sieht dadurch nicht mehr wie ein stummes Modell oder ein festgefahrener Anbieter aus, während er auf den Bediener wartet.

Die vorhandenen Telegram-Freigabeschaltflächen werden automatisch verwendet, wenn die Zulassungsliste genau einen privaten Chat und beliebig viele Gruppen enthält. Bei mehreren möglichen privaten Empfängern bleibt der Versand gesperrt, sofern BLUN_TELEGRAM_APPROVAL_CHAT_ID nicht gesetzt ist.

Eine Rot-zu-Grün-Regression schützt die sofortige Sichtbarkeit im Sitzungsverlauf, die eindeutige Weiterleitung an einen privaten Chat, den Vorrang eines ausdrücklich gesetzten Ziels und die Ablehnung mehrdeutiger Empfänger in beiden ausgelieferten Relay-Kopien.

Neu in 9.1.521

Ohne Datum

BLUN King 9.1.521 führt den AgentSpine-SessionStart-Scan außerhalb des interaktiven Startpfads aus. Ein kalter, 123,6 Sekunden dauernder Scan des Benutzerverzeichnisses blockiert dadurch weder den Editor noch die erste Benutzereingabe.

Erfolgreiche SessionStart-Ausgaben bleiben automatisch: Nach Abschluss übernimmt der Hintergrund-Hook sein begrenztes Briefing weiterhin in den Sitzungskontext.

Das Zeitbudget für kalte Scans steigt auf 180 Sekunden. Ein Rot-zu-Grün-Laufzeittest belegt, dass der Start vor einem langsamen Hook zurückkehrt und der Hook anschließend weiterlaufen kann.

Neu in 9.1.520

Veröffentlicht am

BLUN King 9.1.520 räumt dem AgentSpine-SessionStart-Hook beim Neuladen genügend Zeit ein, um einen kalten vollständigen Projektscan abzuschließen.

Die Zeitgrenze für den AgentSpine-Start steigt von 15 auf 60 Sekunden. Alle anderen Hook-Zeitgrenzen bleiben unverändert.

Eine neue Rot-zu-Grün-Laufzeitprüfung startet den echten AgentSpine-Hook in einem temporären Projekt und prüft sowohl seine Ausgabe als auch die beiden ausgelieferten Timeout-Manifeste.

Geprüfter Paketstand

Version 9.1.520 enthält AgentSpine 0.10.1. Der isolierte Updatertest von 9.1.519 auf 9.1.520 und das vollständige Prepack sind grün. SHA-256 des npm-Pakets: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Neu in 9.1.519

Veröffentlicht am

BLUN King 9.1.519 speichert erfolgreiche Ausgaben des SessionStart-Hooks, bevor Start oder Neuladen zurückkehrt. Dadurch erreicht die AgentSpine-Bereitschaft den fortgesetzten Modellkontext automatisch und wartet nicht mehr auf die erste Benutzernachricht.

Historische Verweise auf ausgelagerte Werkzeugergebnisse behalten eine begrenzte Vorschau aus Anfang und Ende. Wichtige Anker für die Wiederaufnahme bleiben damit erhalten, ohne das vollständige Ergebnis erneut in jede Modellanfrage aufzunehmen.

Neue Rot-zu-Grün-Laufzeitprüfungen schützen die SessionStart-Kontextübergabe und die historischen Vorschauen. Der mit 9.1.518 wiederhergestellte Werkzeugkatalog für die Todo-Pflege bleibt unverändert erhalten.

Neu in 9.1.518

Veröffentlicht am

Während der proaktiven Aufgabenlistenpflege bleiben Read, Write, Edit und Bash neben TodoList verfügbar. Der normale Wiederherstellungsweg für große Dateiänderungen wird dadurch nicht mehr unterbrochen.

Die automatische Todo-Pflege und ihr begrenzter Nachweisprompt bleiben erhalten, ohne den aktiven Modellschritt auf einen reinen TodoList-Werkzeugkatalog umzuschalten.

Ein Rot-zu-Grün-Regressionsgate schützt vor dem Katalogrückfall aus 9.1.499 und prüft die Auswahl der Wiederherstellungswerkzeuge ohne doppelte Schemas.

Neu in 9.1.517

Veröffentlicht am

Strg+S und Escape bleiben auch bei geöffneter Freigabeabfrage verfügbar. Strg+S sendet alle wartenden Nachrichten; Escape gibt zunächst eine wartende Nachricht frei und lehnt die Freigabe erst bei leerer Warteschlange ab.

Die asynchrone Sitzungsbeendigung wird in den Tastatur-, Telegram-/reload- und Slash-Befehlspfaden vollständig beobachtet. session.not_found gilt als bereits beendete Sitzung, statt den Kern durch eine unbehandelte Ablehnung abstürzen zu lassen.

Rot-zu-Grün-Paketprüfungen schützen die rohen Windows-Steuerzeichen und den gemessenen Fehler beim Beenden einer nicht mehr vorhandenen Sitzung.

Neu in 9.1.516

Veröffentlicht am

Fehlt im gespeicherten Verlauf nach der Verdichtung der Beginn eines Assistentenschritts, rekonstruiert die Wiedergabe ihn aus dem folgenden Inhalts- oder Werkzeugereignis. king -c bricht dadurch nicht mehr mit dem internen Fehler Received content_part for unknown step_uuid 'undefined' ab.

Eine Telegram-Nachricht verlässt die Warteschlange genau einmal, sobald der Kern ihre aktive Übergabe dauerhaft angenommen hat. Echte Ablehnungen bleiben für einen neuen Versuch erhalten. Eine unerwartet beendete, von King verwaltete Telegram-Bridge wird durch genau einen zusammengeführten Wächter neu gestartet.

Pro Modellschritt wird nur die erste TodoList-Änderung angenommen. Erledigte Punkte verschwinden automatisch, ausstehende Markierungen bleiben auch in ANSI16-Terminals sichtbar und eine neue Liste beginnt mit genau einem laufenden Punkt. Die feste Reihenfolge lautet: dringend, direkte Nutzernachricht, adressierte Bot-Nachricht, Bot-Nachricht, normale Nachricht.

Der erste werkzeugfähige Schritt wartet höchstens 2,5 Sekunden auf den anfänglichen MCP-Katalog; optionale Server dürfen im Hintergrund weiter starten. Beim Programmstart wird nur das aktive Profil geprüft und installiert.

Geprüfter Paketstand

Version 9.1.516 enthält AgentSpine 0.10.1. Alle acht Prepack-Regressionsgates, node --check, die Paket-Metadatenprüfung und eine frische Paketprüfung sind grün. Dasselbe npm-Paket enthält die Plattformbestandteile für Windows, Linux und macOS. SHA-256 des npm-Pakets: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Neu in 9.1.515

Veröffentlicht am

Eine wahrheitsgemäß unveränderte Aufgabenliste wird nach längerer belegter Arbeit wieder akzeptiert. Der King muss keinen Fortschritt erfinden oder bloß einen Titel umformulieren, um seine eigentliche Arbeit fortsetzen zu dürfen.

Auch ein Leerlauf-Loop kann eine noch offene TodoList wieder aufnehmen, ohne den Agenten dauerhaft im Wartungszug mit ausschließlich dem Todo-Werkzeug festzuhalten. Ein Prepack-Regressionsgate schützt beide Fehlerpfade.

Geprüfter Paketstand

Version 9.1.515 enthält AgentSpine 0.10.1. Der gezielte Todo-Loop-Regressionscheck, node --check, die Release-Metadatenprüfung und eine frische Paketinstallation sind grün. Dasselbe npm-Paket enthält die Plattformbestandteile für Windows, Linux und macOS. SHA-256 des npm-Pakets: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Neu in 9.1.514

Veröffentlicht am

BLUN King 9.1.514 härtet das inhaltsfreie Telegram-Zustelljournal gegen manipulierte Queue-Umschläge.

Nachrichtenkennungen werden nur noch als positive Dezimalzahlen übernommen. Bereits berechnete Chat-Hashes sind ausschließlich als exakt zwölfstellige Kleinbuchstaben-Hexwerte zulässig. Fehlerhafte, inhaltsähnliche Werte werden verworfen, statt protokolliert zu werden.

Die bestehende Telegram-Verarbeitung, die Zustellphasen, die Journal-Rotation und die inhaltsfreie Quarantäne-Diagnose bleiben unverändert. Alle 133 Pakettests sowie frische Paketproben für Windows x64, Linux x64, macOS ARM64 und macOS x64 sind grün.

Geprüfter Paketstand

Version 9.1.514 enthält AgentSpine 0.10.1 und ReadBatch. SHA-256 des npm-Pakets: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Neu in 9.1.513

Veröffentlicht am

BLUN King 9.1.513 protokolliert den Telegram-Zustellweg vom Eingang an der Bridge über Routing, Einreihung und Einspeisung bis zur Bestätigung, Wiederherstellung oder Quarantäne.

Das begrenzte Journal speichert ausschließlich inhaltsfreie Kennungen, Hashes, Zustellphasen, Zähler und bereinigte Fehlergründe. Nachrichtentexte, Prompts, Pfade, Benutzernamen, Token, Zugangsdaten und rohe Fehlermeldungen werden nicht erfasst.

Auch die Quarantäne-Diagnose dupliziert keine Telegram-Nachrichten, Anzeigetexte, Herkunftsangaben, rohen Chat-IDs oder Bildpfade mehr. Alle 132 Pakettests sowie frische Paketproben für Windows x64, Linux x64, macOS ARM64 und macOS x64 sind grün.

Geprüfter Paketstand

Version 9.1.513 enthält AgentSpine 0.10.1 und ReadBatch. SHA-256 des npm-Pakets: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Neu in 9.1.512

Veröffentlicht am

BLUN King 9.1.512 erzwingt bei der proaktiven TodoList-Pflege eine geänderte, beleggestützte Aktualisierung, statt dieselbe Liste unbegrenzt erneut anzunehmen. Der isolierte Wartungszug erhält höchstens acht kompakte Angaben zu Werkzeugname und Ergebnis seit der letzten akzeptierten Aktualisierung.

Prompts, Argumente, Befehle, vollständige Pfade, Werkzeugergebnisse oder der Arbeitsverlauf werden dabei nicht erneut eingespielt. Ein fehlgeschlagener TodoList-Versuch bewahrt diesen begrenzten Nachweis für den nächsten Versuch; eine erfolgreiche Aktualisierung entfernt die verwendeten Angaben. Erledigte Punkte verschwinden weiterhin automatisch, und im folgenden Schritt stehen wieder die normalen Arbeitswerkzeuge bereit.

Geprüfter Paketstand

9.1.512 besteht 127 von 127 Pakettests. Frische Installationen wählen unter Windows x64, Linux x64, macOS ARM64 und macOS x64 die erwarteten Plattformbestandteile und enthalten AgentSpine 0.10.1 sowie ReadBatch. SHA-256 des npm-Pakets: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Neu in 9.1.511

Veröffentlicht am

BLUN King 9.1.511 liefert AgentSpine 0.10.1 als neue, inhaltsadressierte Core-Pluginfassung. Der verpflichtende Preflight prüft weiterhin jede aktive Host-Anweisungsdatei race-sicher und bindet ihre Identität an den exakten Zug, dupliziert den bereits vom Host geladenen Volltext jedoch nicht mehr in den Laufzeitkontext.

Der Stand ergänzt verpflichtende Vor-Antwort-Belege, bestätigte Must-Remember-Einträge und die selbstheilende Synchronisierung des authentifizierten Persona- und Beziehungsgraphen. Fehlende Gruppen, Personen und Mitgliedschaften werden bei einem erneuten Roster-Abgleich repariert; lokale Beziehungsabfragen enden bei einer Blockade nach fünf Sekunden sichtbar.

Die begrenzte Telegram-Mnemo-Abfrage bleibt erhalten: frühere Nachrichten werden nur bei konkretem Bedarf mit engem Agenten-, Personen-, Gruppen-, Themen-, Thread- und Zeitbezug geladen. Ein vollständiger Telegram-Verlauf gelangt nicht routinemäßig in den Prompt.

Geprüfter Paketstand

9.1.511 besteht 126 von 126 Pakettests. Die echte 15.519-Byte-CLAUDE.md wurde vollständig geprüft, während der gesamte injizierte Kontext 5.667 Byte umfasste und keinen Anweisungsvolltext enthielt. Frische Installationen wählen unter Windows x64, Linux x64, macOS ARM64 und macOS x64 die erwarteten Plattformbestandteile und enthalten AgentSpine 0.10.1 sowie ReadBatch. SHA-256 des npm-Pakets: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Neu in 9.1.510

Veröffentlicht am

BLUN King 9.1.510 ergänzt das Werkzeug ReadBatch. Es liest zwei bis zwölf voneinander unabhängige, bereits bekannte UTF-8-Dateien oder Dateibereiche in einem Modellschritt und behält dabei die Reihenfolge der Anfragen bei. Jeder Pfad durchläuft dieselben Zugriffs-, Regel- und Berechtigungsprüfungen wie ein einzelner Read-Aufruf. Teilerfolge bleiben sichtbar; nur ein vollständig fehlgeschlagener Stapel gilt als Gesamtfehler.

Geprüfter Paketstand

9.1.510 besteht 125 von 125 Pakettests. Frische Installationen wählen unter Windows x64, Linux x64, macOS ARM64 und macOS x64 die erwarteten Plattformbestandteile und enthalten ReadBatch. AgentSpine blieb bewusst auf 0.8.0, bis der unabhängig gefundene Kontextbudget-Blocker des neueren Vorabstands ohne vergrößerten Laufzeitprompt behoben war. SHA-256 des npm-Pakets: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Neu in 9.1.509

Veröffentlicht am

BLUN King 9.1.509 verlangt bei jeder freigegebenen Telegram-Arbeitsnachricht zwischen Bots eine ausdrückliche Erwähnung des vorgesehenen Kings. Bot-Nachrichten ohne passende Erwähnung bleiben sichtbar, werden jedoch weder gepuffert noch eingereiht, zugestellt oder später in den Modellkontext dieses Kings übernommen. Dadurch kann eine vorrangige Bot-Nachricht für einen King nicht mehr zur Aufgabe eines anderen Kings werden.

Geprüfter Paketstand

Alle 121 Pakettests bestehen. Dasselbe Paket enthält die geprüften Plattformbestandteile für Windows x64, Linux x64, macOS ARM64 und macOS x64. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Neu in 9.1.508

Veröffentlicht am

Offene Todo-Punkte besitzen wieder ein sichtbares Kästchen. Auch die erste gewöhnliche Aufgabenliste beginnt mit genau einem laufenden Punkt; spätere Schritte bleiben ausstehend, bis ihr tatsächlicher Beginn belegt ist.

Angenommene Telegram-Direkt- und Gruppennachrichten werden asynchron, dauerhaft gepuffert und exakt dedupliziert an Mnemo übergeben. Ein vorübergehend nicht erreichbarer Hub blockiert weder die Telegram-Zustellung noch den King-Lauf. /loop-Befehle und interne Loop-Ticks werden bewusst nicht gespeichert.

AgentSpine lädt keinen vollständigen Telegram-Verlauf in den Laufzeitkontext. Benötigt eine Aufgabe eine frühere Nachricht, erfolgt eine begrenzte Mnemo-Abfrage nach Agent, Person, Gruppe, Thema, Thread und Zeitraum.

Geprüfter Paketstand

Alle 120 Pakettests bestehen. Frische Installationen wählen unter Windows, Linux x64, macOS ARM64 und macOS x64 jeweils die richtige native Zwischenablage-Komponente und enthalten die verwaltete Telegram-Mnemo-Verbindung sowie AgentSpine. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Neu in 9.1.507

Veröffentlicht am

BLUN King 9.1.507 weist das Modell im Read-Werkzeug ausdrücklich an, voneinander unabhängige Datei- und Bereichslesungen in einer Modellantwort zu bündeln, wenn mehrere Eingaben nützlich sein können.

Das reduziert vermeidbare Modellrunden bei großen Arbeitskontexten, ohne Ausführung, Seitennavigation, Berechtigungen oder Ergebnisbehandlung von Read zu verändern.

Geprüfter Paketstand

Ein gezielter Regressionstest schützt die Änderung; alle 112 Pakettests bestehen.

Neu in 9.1.506

Veröffentlicht am

Erledigte TodoList-Punkte werden unmittelbar aus der sichtbaren TUI entfernt. Die persistente Aufgabenliste hat diese Einträge bereits korrekt verworfen; nun zeigt die Oberfläche denselben bereinigten Stand, während laufende und ausstehende Arbeit vollständig erhalten bleibt.

Der automatische Wartungszug verwendet einen eigenständigen Systemprompt mit 546 Zeichen. Zuvor wurde dafür trotz des einzigen verfügbaren Todo-Werkzeugs der vollständige Arbeitsprompt mit rund 19.000 Zeichen angehängt. Der nachfolgende Arbeitsschritt erhält weiterhin den vollständigen Prompt und seinen normalen Werkzeugkatalog.

Gemessener Kontextgewinn und Paketstand

Ein realer Lauf zeigte für jeden achten Arbeitsschritt einen eigenen Todo-Wartungszug mit 15.221 Eingabetokens. Der statische Wartungsprompt schrumpft um 18.470 Zeichen; die tatsächliche Laufzeitersparnis wird nach der Flottenaktualisierung erneut gemessen. Der veröffentlichte Tarball besteht 111 von 111 Tests. Frische Paketinstallationen unter Windows mit Node 24.19.0 und Linux mit Node 24.18.0 bestätigen Version 9.1.506; die macOS-Binärdateien für ARM64 und x64 sind im identischen npm-Paket enthalten. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Neu in 9.1.505

Veröffentlicht am

Eine Telegram-Nachricht, die nach der Übernahme des Kanals, aber noch vor dem Abschluss der Queue-Aktivierung eintrifft, wird nicht mehr als alter Rückstand übersprungen. Ohne gültigen Prüfpunkt beginnt die Verarbeitung an der beim Übernahmestart gemessenen Byte-Grenze statt am späteren Dateiende.

Ein gültiger dauerhafter Prüfpunkt behält Vorrang. Wird die Queue-Datei während der Übergabe ersetzt, beginnt die neue Datei sicher bei Byte null; bereits vor der Übernahme vorhandene historische Nachrichten werden weiterhin nicht erneut eingespielt.

Gemessener Rückfall und Paketstand

Die Gruppenmeldung 63456 traf eine Sekunde nach der Kanalübernahme ein, der Prüfpunkt sprang bis exakt an ihr Ende und die Nachricht erschien in keinem Modellverlauf. Diese reale Verluststrecke ist als Regression geschützt. Der veröffentlichte Tarball besteht 111 von 111 Tests; frische Paketinstallationen unter Windows mit Node 24.19.0 und Linux mit Node 24.18.0 sowie eine reale Aktualisierung von 9.1.504 bestätigen Version 9.1.505. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Neu in 9.1.504

Veröffentlicht am

Eine Telegram-Nachricht, die bei leerem Agentenlauf bereits in der Warteschlange liegt, wird nun über den normalen Kanalpfad als frischer Modellzug gestartet. Sie wartet nicht länger auf einen aktiven Lauf, der im Leerlauf definitionsgemäß nicht entstehen kann.

Die bestehende Übergabe in einen laufenden Zug bleibt unverändert. Ebenso bleiben die isolierte Todo-Pflege, das automatische Entfernen erledigter Punkte und die anschließende Wiederherstellung der normalen Datei-, Such- und Shell-Werkzeuge geschützt.

Geprüfter Paketstand

Der veröffentlichte Tarball besteht 106 von 106 Tests. Die neue Leerlauf-Regression war vor dem Eingriff rot und ist danach zusammen mit 24 Queue-Tests grün. Frische Paketinstallationen unter Windows mit Node 24.19.0 und Linux mit Node 24.18.0 bestätigen Version 9.1.504 und denselben SHA-256 df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Neu in 9.1.503

Veröffentlicht am

Die isolierte Todo-Wartungsnachricht trägt nun auch ein ausdrücklich leeres toolCalls-Feld. Damit erfüllt sie dieselbe Nachrichtenform wie reguläre Arbeitszüge und kann von der BLUN-Provider-Normalisierung sicher verarbeitet werden.

Der echte Laufzeitfehler TypeError: message.toolCalls is not iterable tritt dadurch nicht mehr vor dem TodoList-Aufruf auf. Ein Regressionstest iteriert die erzeugte Nachricht genau wie die Provider-Grenze, bevor die Wartung freigegeben wird.

Geprüfter Paketstand

Der veröffentlichte Tarball besteht 105 von 105 Tests. Frische Paketproben unter Windows mit Node 24.19.0 und Linux mit Node 24.15.0 bestätigen die vollständige Provider-Nachrichtenform, die isolierte Todo-Pflege und das automatische Entfernen erledigter Punkte. Die reale Flottenabnahme läuft nach dem kontrollierten Neustart der drei Kings.

Neu in 9.1.502

Veröffentlicht am

Der fällige TodoList-Wartungsschritt erhält nur noch eine frische, auf die aktuelle Aufgabe und sichtbare Liste begrenzte Nachricht. Alte Read-, Bash- oder MCP-Aufrufe aus dem Arbeitsverlauf können dadurch nicht mehr in den absichtlich auf TodoList begrenzten Schritt geraten.

Erledigte Aufgaben verschwinden beim Speichern automatisch aus der sichtbaren und persistenten Liste. Laufende, ausstehende, blockierte, auf Freigabe wartende und abgebrochene Punkte bleiben erhalten; die Liste wächst somit nicht unbegrenzt durch abgeschlossene Arbeit.

Gemessener Flottenbefund

Zwei Agentenprofile trafen unabhängig denselben Rückfall: Nach erfolgreicher Werkzeugnutzung wiederholte die Todo-Wartung historische Sachwerkzeuge und zeigte Tool not found. Der veröffentlichte Tarball besteht 105 von 105 Tests. Frische Installationen unter Windows mit Node 24.19.0 und Linux mit Node 24.15.0 bestätigen die isolierte Wartung, das Entfernen erledigter Punkte und die Rückkehr der normalen Werkzeuge. Eine echte macOS-Abnahme ist nicht Teil dieses Nachweises.

Neu in 9.1.501

Veröffentlicht am

Nach einem erfolgreichen TodoList-Wartungsschritt stehen im unmittelbar folgenden Arbeitsschritt wieder alle für den Zug ausgewählten Werkzeuge bereit. Read, Bash und andere Sachwerkzeuge bleiben nicht länger hinter dem vorübergehend eingeschränkten Todo-Katalog verborgen.

Reparierter Rückfall

Der Todo-Schritt bot absichtlich nur TodoList an. Seine Werkzeugauswahl blieb jedoch ohne ausdrückliche Wiederherstellung auch im Folgeschritt aktiv. 9.1.501 setzt dort wieder den normalen Katalog ein und schützt beide Folgeschrittpfade mit einer Regression.

Golden Release 9.1.500

Veröffentlicht am

Diese Version bündelt den vollständigen Funktionsstand von 9.1.499 unverändert als gemeinsame npm-Veröffentlichung für Windows, Linux und macOS. Die Gold-Kennzeichnung ist bewusst auf die Überschriften dieser Version begrenzt; ältere Einträge behalten ihre bisherige Darstellung.

Release-Stand

Die Golden Release übernimmt die geprüften Todo-, Queue-, Loop-, Kontext-, AgentSpine- und Bildauswertungsänderungen aus 9.1.499 ohne zusätzliche Laufzeitlogik.

Neu in 9.1.499

Veröffentlicht am

Bild-, Audio- und Videodaten außerhalb der neuesten zwölf Gesprächsnachrichten werden nur in der wiederholten Modellprojektion durch kurze Verweise ersetzt. Aktuelle Medien, Nachrichtentext und vollständiger Sitzungsrohverlauf bleiben unverändert.

In einem gemessenen Wiederaufnahme-Checkpoint spart diese Projektion 85.748 Zeichen beziehungsweise rund 21.437 geschätzte Eingabetoken je weiterem Werkzeugschritt.

Fällige Todo-Pflege läuft vor dem neunten Arbeitsblock als eigener Low-Effort-Modellschritt. In diesem Schritt bietet die Laufzeit ausschließlich TodoList an; Datei-, Such-, Shell- und andere Sachwerkzeuge werden erst nach einer gültigen Aktualisierung wieder freigegeben.

Frische Benutzernachrichten behalten Vorrang vor der Todo-Pflege. Das harte Todo-Gate bleibt als Sicherheitsnetz für tatsächlich ungültige Aktualisierungen erhalten, erscheint aber nicht mehr als normaler roter Zwischenfehler vor einer selbstständigen Listenpflege.

Geprüfter Nachweis

Der veröffentlichte Tarball besteht 105 von 105 Laufzeit- und Regressionstests. Frische isolierte Installationen unter Windows mit Node 24.19.0 und Linux mit Node 24.15.0 melden exakt Version 9.1.499 und bestätigen Medienprojektion, unveränderten Rohverlauf, Todo-Vorsteuerung und die Ausblendung aller Sachwerkzeuge während des Todo-Schritts. Der Kandidat umfasst 850 Pfade und trägt SHA-256 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Eine echte macOS-Abnahme ist nicht Teil dieses Nachweises.

Neu in 9.1.498

Veröffentlicht am

/usage zeigt die vom Anbieter gemeldete Prompt-Cache-Trefferquote sowie gelesene und geschriebene Cache-Token je Modell. Ohne gemeldete Cache-Aktivität erfindet die Anzeige keine Quote.

/tokens ist ein kurzer Alias für die vorhandene detaillierte Kontextdiagnose; /offload ruft die vorhandene archivierende Verdichtung auf. Beide Wege lösen keinen zusätzlichen Modellaufruf aus.

Unterschiedliche autorisierte Bot-Nachrichten werden nicht mehr durch ein starres 15-Sekunden-Fenster verworfen. Die bestehende Reihenfolge bleibt erhalten: private und ausdrücklich adressierte Nachrichten stehen vor Bot-Nachrichten, Bot-Nachrichten vor normalem Kontext.

Eine vollständige Verdichtung übernimmt die exakte Todo-Liste in den neuen Kontext. Sind danach Pfad, Befehl, Hash oder Anforderung unsicher, verlangt ein einmaliger Wiederherstellungshinweis zuerst das Lesen des archivierten Verlaufs statt einer breiten Dateisuche oder eines Neubeginns.

Erledigte Todo-Schritte bleiben als Nachweis erhalten. Falls spätere Erkenntnisse einen Schritt erneut erforderlich machen, bleibt der belegte Abschluss stehen und die neue Prüfung erscheint als eigener laufender Schritt mit Begründung.

Wiederkehrende Session-Loops warten, solange die gepflegte Todo-Liste noch laufende oder ausstehende Arbeit enthält. Verpasste Intervalle werden bis zum echten Leerlauf zusammengefasst; andere geplante Erinnerungen bleiben davon unberührt.

Geprüfter Nachweis

Der vorbereitete Tarball besteht 100 von 100 Laufzeit- und Regressionstests. Frische isolierte Installationen unter Windows mit Node 24.19.0 und Linux mit Node 24.15.0 melden exakt Version 9.1.498 und bestätigen Cache-Anzeige, Befehlsaliasse, Verdichtungswiederherstellung, monotone Todo-Nachweise, Session-Loop-Schutz, Paket-Changelog und Bot-Priorität. Der Kandidat umfasst 849 Pfade und trägt SHA-256 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Eine echte macOS-Abnahme ist nicht Teil dieses Nachweises.

Neu in 9.1.497

Veröffentlicht am

Telegram-Botnachrichten aus gemeinsamen Gruppen stehen hinter privaten und ausdrücklich adressierten Nachrichten, aber vor normalem Kontext. Die Priorisierung erzwingt keine Antwort.

Eine angenommene Telegram-Nachricht verschwindet aus der sichtbaren Queue, sobald ihr eingespielter Modellschritt beginnt. Eine abgewiesene Zustellung oder ein Abbruch vor dem ersten Schritt bewahrt sie weiterhin für einen erneuten Versuch auf.

Eine fällige Telegram-Antwort oder Nachrichtenbearbeitung wird nicht mehr von der Todo-Pflege blockiert. Der nächste normale Arbeitsschritt bleibt bis zur wahrheitsgemäßen Aktualisierung der Todo-Liste gesperrt.

Versionen 9.1.496 bis 9.1.487

VersionÄnderungen
9.1.496Stellt Telegram-Nutzernachrichten automatisch einzeln zu, entfernt nur die exakt angenommene oder beantwortete Nachrichten-ID, erzwingt wahrheitsgemäßen Fortschritt für jede sichtbare Todo-Liste und blendet erfolgreiche interne Hook-Nutzlasten aus.
9.1.495Startet jedes neue oder ersetzte Ziel mit einer frischen sichtbaren Todo-Liste, verlangt wahrheitsgemäße Aktualisierungen, entfernt erfolgreich beantworteten Telegram-Gruppenfokus sofort, verschiebt normale Eingangsquittierungen bis zum Zugende und ergänzt echte Decodierungsprüfungen für Strg+S und Strg+T.
9.1.494Trennt die Tastenkürzel wieder eindeutig: Strg+S steuert nur den Queue-Rückstand, Strg+T nur die Todo-Liste. Telegram-Nutzernachrichten autorisieren sich bei laufender Arbeit für die nächste sichere Übergabe.
9.1.493Telegram-Nutzernachrichten werden während aktiver Arbeit automatisch zur nächsten sicheren Übergabe freigegeben. Direktnachrichten bleiben innerhalb der Queue vorn, ohne Gruppenmeldungen dauerhaft anzuhalten.
9.1.492Bereits freigegebene Gruppennachrichten bleiben bei einer vorübergehend belegten Zustellung erhalten und werden erneut versucht. Paket, npm-Metadaten, öffentliches Manifest und Changelog werden vor einer Erfolgsmeldung gemeinsam geprüft.
9.1.491Direkte Telegram-Nachrichten werden bei laufender Arbeit sofort priorisiert. Die manuelle Queue-Steuerung blieb für andere Nachrichten bestehen.
9.1.490Die Paket-Historie dokumentiert den unveröffentlichten Stand 9.1.487 und die tatsächlich veröffentlichten Reparaturen ab 9.1.488 vollständig.
9.1.489Aufgabenliste, Queue-Steuerung, Telegram-Ausführungsidentität, AgentSpine-Profilinstallation und die verwaltete Bildauswertung wurden wiederhergestellt und mit Regressionstests geschützt.
9.1.488Das vorbereitete AgentSpine-Core-Plugin wurde veröffentlicht. Telegram-Duplikate hinterlassen keinen Schein-Turn mehr; Denktiefe und sichere Telemetriebehandlung bleiben über Werkzeugschritte erhalten.
9.1.487Nicht veröffentlicht. Dieser Stand bereitete AgentSpine als verwaltetes Core-Plugin vor. Auf npm folgte nach 9.1.486 direkt 9.1.488.

Neu in 9.1.486

Veröffentlicht am

Neue und aktualisierte Profile starten jetzt unter Windows, macOS und Linux zuverlässig auf Englisch. Ein gespeicherter automatischer Sprachwert wird einmalig migriert, während ausdrücklich gewählte Sprachen unverändert bleiben.

Automatische Aktualisierungen beim Start sind über den vorhandenen versionsgebundenen Installer wieder standardmäßig aktiviert. [upgrade].auto_install = false behält die Bestätigungsabfrage bei; ein Hintergrund-Updater wird nicht wieder eingeführt.

Startdialoge, Fortschritt, Fehler, Erfolgsmeldungen und Sitzungsfortsetzung verwenden jetzt dieselbe Sprache. Regressions- und Mutationstests schützen Migration, Aktualisierungspfad und Sitzungsdaten.

Geprüfter Nachweis

Die vollständige Testsuite bestand mit 1.474 von 1.474 Prüfungen. Ein isolierter Update-Lauf installierte 9.1.486 aus 9.1.485, bewahrte Konfiguration und Sitzung unverändert und startete die neue CLI. Eine getrennte Startprobe belegte die automatische Installation ohne Rückfrage sowie die einmalige Migration eines alten automatischen Sprachwerts zu Englisch.

Versionen 9.1.485 bis 9.1.178

VersionÄnderungen
9.1.485
  • Begrenzt die erste sichtbare Wiedergabe einer fortgesetzten Sitzung ohne Scrollback-Index auf die aktiven 15 Gesprächszüge, statt die gesamte Unterhaltung erneut darzustellen.
  • Leert nach einer erfolgreichen Aktualisierung den sichtbaren Update-Bereich, bevor die neue Konsole startet; der normale Terminal-Scrollback bleibt erhalten.
  • Ergänzt Regressions- und Mutationsprüfungen für den Wiedergabe-Rückfall, einschließlich einer Simulation mit 97.596 Datensätzen.
9.1.484
  • Die Plugin-Erkennung akzeptiert zusätzlich .codex-plugin/plugin.json und löst PLUGIN_ROOT beziehungsweise BLUN_PLUGIN_ROOT in Befehl, Argumenten und Arbeitsverzeichnis auf.
9.1.483
  • Das Verdichtungsmodell lässt sich getrennt vom aktiven Modell auswählen, speichern und auf Vererbung zurücksetzen; Auswahl und Rückmeldung stehen im Leerlaufbefehl und in den lokalisierten Einstellungen bereit.
9.1.482
  • Ausgelagerte Read-Ergebnisse bewahren den nächsten line_offset und setzen den ursprünglichen Lesevorgang dort fort, statt dieselbe Datei wieder am Anfang zu lesen.
9.1.481
  • Teilagenten-Antworten, die am Tokenlimit ohne Werkzeugaufruf enden, werden als max_tokens für die bestehende Fortsetzung erkannt. Glob-Muster mit .. und benannte Home-Pfade wie ~name werden abgewiesen.
9.1.480
  • Aktualisiert das mitgelieferte translate-native-Skill und den Language-Guard-MCP auf Version 6.42.13.
  • Bindet die mitgelieferten Dateien des Sprachschutzes bytegenau an den Quellcommit 6430ce30e235c1a9d1ebcd1b646d62edce510605.
  • Ergänzt Herkunfts- und Mutationsprüfungen, sodass veränderte Schutzbytes oder eine abweichende Skill-Version das Veröffentlichungstor scheitern lassen.
9.1.479
  • Fügt dem privaten King-Dienst der Agent API eine authentifizierte interne Route zur Verfügbarkeitsprüfung hinzu.
  • Prüft die Verfügbarkeit des Dienstes, ohne eine Kundensitzung anzulegen oder einen Agentendurchlauf zu starten.
  • Beschränkt die Route auf die Loopback-Schnittstelle und GET, schützt sie mit einem Geheimnis und verhindert ihre Zwischenspeicherung.
9.1.478
  • Behebt gewöhnliche Pausen des direkten Telegram-Fokus nach einem Neustart, selbst wenn ältere Prüfpunkte keine Antwortfrist enthalten.
  • Bewahrt ausdrücklich vom Nutzer angeforderte Pausen bis zur Freigabe, statt sie automatisch ablaufen zu lassen.
  • Gibt eingereihte Kanalnachrichten für einen aktiven Durchlauf frei, sobald der direkte Fokus endet.
9.1.477
  • Fügt dem privaten Dienst der Agent API eine ausdrückliche, vom Betreiber gestartete Prozesshülle hinzu.
  • Verarbeitet SIGINT und SIGTERM genau einmal, auch wenn die Signale während des Starts eintreffen.
  • Bricht mit begrenzten Meldungen sicher ab, ruft process.exit nicht auf und startet den Dienst niemals automatisch.
9.1.476
  • Fügt dem privaten Dienst der Agent API einen Umgebungsvertrag nach dem Prinzip der sicheren Sperre hinzu.
  • Erfordert einen ausdrücklich festgelegten Loopback-Port, Isolierungsgeheimnisse, Anbietereinstellungen und Ressourcengrenzen.
  • Lässt den privaten Dienst gestoppt und die automatische Bereinigung untätiger Sitzungen deaktiviert, bis beides ausdrücklich konfiguriert wurde.
9.1.475
  • Gibt ausschließlich entsprechend konfigurierte und tatsächlich untätige Sitzungen der Agent API frei, bevor ein Kunde das Sitzungslimit erreicht.
  • Schützt aktive Modell- und Werkzeugdurchläufe unabhängig von ihrem Alter und aktualisiert den Untätigkeitszeitraum bei echter Nutzung.
  • Lässt die automatische Bereinigung deaktiviert, bis ein Betreiber ausdrücklich eine Zeitüberschreitung für Untätigkeit konfiguriert.
9.1.474
  • Hebt die aktive Sitzungszuordnung auf, wenn die Fortsetzung eines Agenten nach einem Werkzeugergebnis fehlschlägt.
  • Ermöglicht anschließend das ausdrückliche Schließen der betroffenen Sitzung.
  • Lässt erfolgreiche Werkzeugrückläufe und den öffentlichen Modellvertrag unverändert.
9.1.473
  • Schützt eine Sitzung der Agent API vor dem Schließen, solange ihr erster Modellaufruf noch läuft.
  • Gibt die Sitzung nach einer erfolgreichen Antwort oder einem Modellfehler zuverlässig frei.
  • Lässt den bestehenden Pfad für unverarbeitete Modelle und den öffentlichen Modellvertrag unverändert.
9.1.472
  • Ermöglicht Kunden, eine untätige Sitzung der Agent API ausdrücklich zu schließen und ihren begrenzten Sitzungsplatz freizugeben.
  • Verhindert das Schließen aktiver Sitzungen und beschränkt jeden Schließvorgang auf den jeweiligen Eigentümerkunden.
  • Stellt den freigegebenen Platz für eine neue Sitzung bereit, ohne den öffentlichen Modellvertrag zu verändern.
9.1.471
  • Fügt einen geschlossenen Diensthost hinzu, der den privaten Agent-API-Stapel zusammensetzt, ohne ihn automatisch zu starten.
  • Erfordert getrennte Geheimnisse für Transport und Isolierung, ein absolutes Kundenstammverzeichnis und eine ausdrückliche Konfiguration der King-Ablaufumgebung.
  • Bindet Listener an die Loopback-Schnittstelle und schließt beim Herunterfahren jede Kundensitzung sowie jede Ablaufumgebung.
9.1.470
  • Isoliert kopflose Sitzungen der Agent API nach vertrauenswürdigem Kunden und öffentlicher Sitzung.
  • Fasst gleichzeitige Erstzugriffe in einer SDK-Sitzung zusammen und begrenzt aktive Kunden sowie Sitzungen.
  • Verwendet schlüsselgebundene undurchsichtige interne Kennungen und Arbeitsverzeichnisse, während stabile öffentliche Sitzungskennungen erhalten bleiben.
9.1.469
  • Fügt dem Adapter der Agent API einen privaten HTTP-Transport hinzu, der ausschließlich über die Loopback-Schnittstelle erreichbar ist.
  • Erfordert ein Dienstgeheimnis und eine serverseitig vorgegebene Kundenidentität; gefälschte Identitätsangaben im Anfragekörper werden ignoriert.
  • Weist übergroße oder fehlerhafte Anfragen zurück und hält interne Anbieterdetails aus öffentlichen Fehlermeldungen heraus.
9.1.468
  • Hält den Hauptagenten ansprechbar, während Subagenten im Hintergrund und verschachtelte Subagenten weiterarbeiten.
  • Ermöglicht eingeschränkten Sitzungen der Agent API, den Lebenszyklus von Subagenten zu verwenden, ohne lokale Shell- oder Dateisystemwerkzeuge offenzulegen.
  • Gibt die exakte Werkzeuggrenze an jede verschachtelte Subagentenebene weiter, sodass Einschränkungen nicht durch Delegation umgangen werden können.
9.1.467
  • Fügt einen ausdrücklichen Transportadapter für Agentendurchläufe hinzu, ohne bestehende Routen für unverarbeitete Modelle oder Modelllisten abzufangen.
  • Bindet Werkzeugergebnisse und gezielte Abbrüche an denselben Kunden-, Sitzungs- und Anfragebereich.
  • Zeigt ausschließlich King, bereinigt unerwartete interne Fehler und weist Streaming zurück, bis dafür ein Agent-Vertrag besteht.
9.1.466
  • Erfasst jeden abgeschlossenen Modellaufruf der Agent API unter einer stabilen Aufgaben-ID, ohne die Nutzung verschiedener Kunden zusammenzufassen.
  • Eine dauerhafte JSONL-Zuordnung hält Anfrage, Sitzung, Aufgabe, Aufruf-ID und unverarbeitete Nutzungsfelder auch nach einem Neustart auffindbar.
  • Nach außen erscheinen nur King sowie die unverarbeiteten Zähler für Eingabe, zwischengespeicherte Eingabe und Abschluss; fehlende Nutzungsdaten bleiben ausdrücklich gekennzeichnet.
9.1.465
  • Fügt eine isolierte Durchlaufsteuerung für den ausdrücklichen Agent-Endpunkt der Agent API hinzu, ohne unverarbeitete Modellabschlüsse zu verändern.
  • Vom Client verwaltete Werkzeugaufrufe behalten über Ergebnisrückläufe hinweg einen einzigen King-Durchlauf und bleiben auf die ursprüngliche Anfrage begrenzt.
  • Antworten übergeordneter Agenten schließen Ereignisströme von Kindagenten und verworfene Entwürfe erneuter Versuche aus.
9.1.464
  • Verwaltete Subagenten laufen nun abgekoppelt, sodass der Hauptagent ansprechbar bleibt, während delegierte Arbeit fortgesetzt wird.
  • Laufende Subagenten können mit TaskUpdate gesteuert oder mit TaskStop beendet werden, ohne die Hauptsitzung zu schließen.
  • Adressierte Telegram-Gruppennachrichten bleiben im Fokus, bis der Agent im passenden Chat antwortet.
9.1.463
  • Ein Checkpoint-Resume rendert bei vorhandenen Fensterdaten nur die zuletzt aktive TUI-Zuggruppe; ältere Zeilen bleiben im Scroll-Archiv und werden bei Bedarf nachgeladen.
9.1.462
  • Unveränderte tui.toml-Inhalte lösen keinen atomaren Dateiaustausch mehr aus; echte Änderungen nutzen weiterhin den bestehenden gesperrten Schreibpfad.
9.1.461
  • /status unterscheidet den geladenen Laufzeitstand vom installierten Paket und meldet eine Abweichung auch im Telegram-Fernstatus.
9.1.460
  • Ältere sichtbare Sitzungsnachrichten bleiben in einem dauerhaften Plattenarchiv und werden beim Hochscrollen blockweise geladen, ohne beim Start alle Textblöcke einzulesen.
9.1.459
  • Ein Resume stellt einen integritätsgebundenen semantischen Prüfpunkt wieder her und liest nur den seitdem angehängten Teil der unveränderten Sitzungsdatei; bei ungültigem Prüfpunkt bleibt der vollständige Replay als Rückfall.
9.1.458
  • Eine aus einem externen Bericht übernommene Prüfsumme wird nur gebunden, wenn genau dieser Wert im ausgewählten Quellereignis vorhanden ist.
9.1.457
  • Wenn dieselbe Prüfsumme aus mehreren externen Ereignissen stammt, wird die Herkunft als mehrdeutig ausgewiesen statt einem Bericht zugeschrieben.
9.1.456
  • Prüfsummen in ausgehenden Telegram-Nachrichten werden mit lokalen Werkzeugergebnissen und sichtbaren externen Berichten abgeglichen; nicht zugeordnete Werte erzeugen einen Herkunftshinweis.
9.1.455
  • Telegram-Berichte können über Chat- und Nachrichtenkennung als credible_unverified gebunden werden; Reporter und Ereignisherkunft setzt die Laufzeit.
9.1.454
  • Frische Prüfungen werden automatisch an die erzeugende Sitzung und den erzeugenden Agenten gebunden; weitergeleitete Messungen bleiben externe Berichte.
9.1.453
  • Ein Abschlussbeleg wird an das aktuell gültige Abschlusskriterium gebunden und bei einem anderen oder überholten Kriterium abgelehnt.
9.1.452
  • Jeder Beleg wird an den tatsächlich gemessenen Zielbereich gebunden; Befehlsprüfungen müssen denselben sicheren BLUN_EVIDENCE_SCOPE-Wert auf beiden Seiten führen.
9.1.451
  • Jeder Beleg trägt die genaue Art inspection, integrity, syntax, test oder reachability. Eine schwächere Prüfung darf nicht als stärkere ausgegeben werden.
9.1.450
  • Ergebnisbelege und Prüferbelege werden getrennt. Nur ein neuer oder geänderter Prüfer braucht einen zweiten, eigenständigen Schärfenachweis; normale Messungen brauchen keine Rotprobe.
9.1.449
  • Der Abschlussbeleg nennt den exakten erfolgreichen Prüfaufruf über seine toolCallId; ein gemischter Befehlsaufruf mit Änderung und Prüfung genügt nicht.
9.1.448
  • Ein Zielabschluss muss die geprüfte Behauptung an einen erfolgreichen Prüfaufruf desselben Zugs binden; reine Schreib- oder Änderungswerkzeuge gelten nicht als Beleg.
9.1.447
  • Eine ausgewählte Handlung wird an dauerhafte Entscheidungsbelege gebunden; unbekannte oder veraltete Belege erzwingen eine neue Planung.
9.1.446
  • Die Live-Wiederholungssperre erkennt zusätzlich kurze wiederkehrende Wortfolgen mit zwei bis acht Wörtern.
9.1.445
  • Ausgewählte Lernhinweise werden zusammen mit dem validierten Lernergebnis des aktuellen Zugs als Expositionsspur gespeichert, ohne daraus Kausalität zu behaupten.
9.1.444
  • Die Relevanzsuche nach früheren Fehlern nutzt dauerhafte Ziel-, Prüfpunkt- und Problemrahmendaten statt nur der jüngsten Benutzernachrichten.
9.1.443
  • Bei einer unmittelbaren Zielfortsetzung lädt eine ausdrückliche tool:- oder skill:-Auswahl genau das gewählte Hilfsmittel.
9.1.442
  • Der Arbeitsfokus bewahrt den Entscheidungsfaden aus Status, Phase, letzter Prüfung, Auswahl, Begründung, Unterstützung, Risiko und Umkehrbarkeit.
9.1.441
  • Fehlendes Wissen wird als eigene knowledge_gap-Domäne statt im allgemeinen Zieltext geführt, priorisiert und bei leerem Wert ausgeblendet.
9.1.440
  • Weltwissen und Annahmen können als eigene Domänen in den dauerhaften Fokus aufgenommen und gewichtet werden.
9.1.439
  • Der dauerhafte kognitive Fokus erhält eine Salienzbewertung mit Verfall zwischen Sitzungen und Verstärkung bei erneutem Zugriff.
9.1.438
  • Während des Sitzungs-Replays werden Trimmen, Zusammenführen und Rendern zurückgestellt; danach wird genau ein neuer Transcript-Render angefordert.
9.1.437
  • Der Leerlauf-Wächter verwendet für Zeitüberschreitungen wieder den passenden Textpfad und beendet den Prozess nicht mehr durch einen unerlaubten Parameter im Timer.
9.1.436
  • Der Telegram-Fernstatus zeigt bei einem aktiven Zug Beginn, letzten Fortschritt, letztes Werkzeug und wiederholte Fehler; die TUI veröffentlicht dafür laufende Aktivitätsschnappschüsse.
9.1.435
  • Private Telegram-Fokusprüfpunkte folgen nun dem Arbeitsbereich, der an die aktive Sitzung gebunden ist.
  • Die Auswahl des Arbeitsbereichs speichert das Starterverzeichnis nicht länger als Fortsetzungsort für Direktunterhaltungen.
9.1.434
  • Bestätigtes Lernen folgt nun dem Arbeitsbereich, der an die aktive Agentensitzung gebunden ist.
  • Sitzungen mit mehreren Arbeitsbereichen und fortgesetzte Sitzungen speichern oder zeigen Projektlektionen nicht länger im Verzeichnis des Hostprozesses.
9.1.433
  • Die Vorbereitung einer Eingabe im externen Editor bleibt nun innerhalb der Bereinigungsgrenze für temporäre Verzeichnisse.
  • Schlägt der erste Schreibvorgang fehl, etwa wegen eines vollen Datenträgers oder fehlender Berechtigungen, wird das temporäre Editorverzeichnis entfernt, bevor der Fehler weitergegeben wird.
9.1.432
  • Vorübergehende Stream-Fehler können nun auch nach sichtbarer Teilausgabe mit demselben ausgewählten Modell erneut versucht werden.
  • Unvollständiger Assistententext und nicht abgeschlossene Werkzeugoberflächen werden vor der Wiederholung abgeschlossen oder verworfen, damit die neue Ausgabe nicht an den fehlgeschlagenen Versuch angehängt wird.
  • Nach sichtbarer Ausgabe bleibt der Anbieterwechsel gesperrt, sodass eine Antwort nicht mitten im Stream den Anbieter wechseln kann.
9.1.431
  • Lokale Prozesse des Bash-Werkzeugs deaktivieren nun erzwungen Git-Abfragen im Terminal, statt eine interaktive Einstellung des übergeordneten Prozesses zu erben.
  • Geerbte askpass-Dialoge von Git, SSH und Git Credential Manager sind im Werkzeug-Kindprozess deaktiviert; dadurch werden unsichtbare Wartezeiten auf Windows-Anmeldedaten verhindert.
  • Die übergeordnete Shell und die Umgebung der laufenden Sitzung bleiben unverändert; das vorhandene Verhalten bei geschlossenem Standardeingang bleibt erhalten und wird unabhängig abgesichert.
9.1.430
  • Die vollständige Verdichtung kann nun über [loop_control].compaction_model einen optional konfigurierten Modellalias verwenden; das aktive King-Modell bleibt die Voreinstellung.
  • Authentifizierung, Kontextaufbereitung, Abschlussbudget, Überlauflernen und Nutzungsabrechnung der Verdichtung sind vollständig an das gewählte Verdichtungsmodell gebunden.
  • Das aktive Modell bestimmt weiterhin den Start der Verdichtung und die letzte Anforderungsbremse, sodass ein kleineres Zusammenfassungsmodell das zentrale Denkfenster nicht unbemerkt verkleinern kann.
9.1.429
  • Bash unter Windows weist nun eindeutige cmd.exe-Syntax vor dem Prozessstart zurück, statt einen sichtbar fehlgeschlagenen Durchlauf zu verschwenden.
  • Die Beschreibung des Bash-Werkzeugs stellt ausdrücklich klar, dass POSIX-Bash unter Windows einschließlich VS Code aktiv bleibt, und nennt die richtigen Konventionen für Pfade und Umleitungen.
  • Gültige POSIX-find-Befehle bleiben erlaubt; für bewusst gewünschte cmd-Semantik steht weiterhin eine ausdrückliche Übergabe an cmd.exe /c zur Verfügung.
9.1.428
  • Erzeugte JavaScript- und TypeScript-Schreibvorgänge stoppen nun vor dem Datenträgerzugriff, wenn sich eine ausführbare Anweisung achtmal hintereinander wiederholt; dadurch werden außer Kontrolle geratene Ausgaben von Analyseskripten verhindert.
  • Die Schutzprüfung erfasst sowohl Write-Aufrufe für vollständige Dateien als auch Edit-Ersetzungen, während Nicht-Code-Dateien, Kommentare, Zeichenketten und kürzere berechtigte Wiederholungen unverändert bleiben.
  • Alle drei beobachteten Entartungsfälle mit 15, 23 und 31 wiederholten Anweisungen werden blockiert; beliebige unvollständige, aber nicht wiederholende Absichten liegen weiterhin außerhalb dieser mechanischen Prüfung.
9.1.427
  • Der sichtbare Befehl /memory core meldet nun die aktive Grenze des Gedächtnisadapters, Vertragsversion, Identitätsmodus, Integritätsstatus und portalübergreifende Belege, optional als --json-Ausgabe.
  • Profilgebundener Ersatzspeicher und aus Profilen abgeleitete Identitäten werden ausdrücklich von der Bereitschaft für einen gemeinsamen Kern ausgeschlossen, statt als portalneutrales Gedächtnis dargestellt zu werden.
  • Konfigurierte Anbieter bleiben sichtbar unbestätigt, bis getrennte Belege vorliegen; die Diagnose ist schreibgeschützt, erteilt keine Befugnisse und erfindet niemals portalübergreifende Nachweise.
9.1.426
  • Der sichtbare Befehl /memory acceptance führt nun eine synthetische temporäre V7-Gedächtnisprüfung über CLI, Telegram und Web hinweg aus und kann optional einen --json-Bericht ausgeben.
  • Zehn unabhängige Prüfungen decken Portalherkunft, verknüpfte und unverknüpfte Identitäten, Agenten- und Gruppenisolierung, Deduplizierung, globale Korrektur und Löschung, die sichere Sperre des Anbieters sowie geschützte Quellbytes ab.
  • Der Abnahmebericht dient ausschließlich als deterministischer Beleg: Er erteilt keine Befugnisse und liest oder verändert niemals ein echtes Nutzerprofil.
9.1.425
  • Subagenten, die ihr Tokenlimit erreichen, erhalten nun im selben Agentenkontext einen knappen werkzeugfreien Übergabedurchlauf, statt abgeschlossene Werkzeugarbeit zu verlieren.
  • Erreicht auch diese Übergabe das Limit, erhält der übergeordnete Agent eine begrenzte Teilzusammenfassung sowie die exakte Anweisung zur Fortsetzung durch denselben Agenten.
  • Die Wiederherstellung bleibt nach dem Prinzip der sicheren Sperre gestaltet: kein vollständiger Neuversuch der Aufgabe, keine Fertigmeldung ohne abschließende Übergabe und keine neuen Befugnisse.
9.1.424
  • Bestätigte Lektionen aus Mistake.md werden nun auf anders formulierte, aber semantisch ähnliche Fälle aus Zuverlässigkeit, Zustellung, Orchestrierung, Gedächtnis, Veröffentlichung, Medien und Validierung übertragen.
  • Exakte Belegbegriffe haben weiterhin Vorrang vor breiten semantischen Kategorien; nicht verwandter Text bleibt ohne Zuordnung.
  • Natürliche deutsche Formulierungen werden deterministisch vereinheitlicht; die geänderte Rangfolge schafft weder neue Berechtigungen noch stuft sie eine unbestätigte Lektion hoch.
9.1.423
  • Laufzeitbeendigungen schreiben nun einen dauerhaften synchronen Diagnoseeintrag, bevor Kern oder Starter zurückkehren oder enden.
  • Nicht abgefangene Ausnahmen, unbehandelte Ablehnungen, ausgefallene Terminals, Signale, Startfehler, normale Beendigungen, Fehler von Kindprozessen und deren Beendigungen bewahren die exakte bereinigte Ursache samt Prozessgrenze.
  • Das private Protokoll ist begrenzt und ausfallschonend, entfernt Geheimnisse sowie Home-Pfade und startet oder lädt keine laufende Sitzung neu.
9.1.422
  • Eine geöffnete, untätige Sitzung überwacht nun ihren gespeicherten Zeitauslöser und wird im Automatik- und God Mode bei oder nach dueAt aktiv.
  • Ein fälliger Auslöser wartet, bis aktive Antworten, Verdichtung, eingereihte Nachrichten, Befehle und Dialoge abgeschlossen sind, bevor er genau einmal fortfährt.
  • Vor dem Start liest die Laufzeit Ziel, Prüfpunktrevision, Fälligkeit, Berechtigungsmodus und Sitzung erneut ein und verwirft Timer auf jedem Beendigungspfad der Sitzung.
9.1.421
  • Zeitbasierte Warteprüfpunkte speichern nun einen exakten dueAt-Zeitstempel und vereinheitlichen ihn auf UTC.
  • Ein regulärer Sitzungsstart im Automatik- oder God Mode lässt zukünftige Zeitauslöser warten und setzt sie bei oder nach ihrer Fälligkeit fort.
  • Der erste fortgesetzte Durchlauf erhält die exakte Fälligkeitsbeobachtung; durchgehend geöffnete Sitzungen erhalten in dieser Version noch keinen Laufzeittimer.
9.1.420
  • Ein aktives Ziel mit dauerhaftem Warteprüfpunkt gibt nach dem aktuellen Durchlauf die Kontrolle ab, statt einen weiteren autonomen Durchlauf zuzuweisen.
  • Externe, zeitbasierte, abhängigkeitsbezogene und von Nutzerentscheidungen abhängige Auslöser bleiben gespeichert und werden beim Eintreffen des nächsten Ereignisses erneut ausgewertet.
  • Unmittelbare Ziele und ältere aktive Ziele ohne Prüfpunkt werden unverändert fortgesetzt.
9.1.419
  • Eine regulär fortgesetzte Sitzung führt nun ein bereits aktives Ziel weiter, wenn dessen gespeicherter nächster Auslöser ausdrücklich unmittelbar ist und der Automatik- oder God Mode aktiv ist.
  • Die Fortsetzung bleibt intern, läuft höchstens einmal je fortgesetzter Sitzung und erscheint niemals als erfundene Nutzernachricht.
  • Wartende, pausierte und blockierte Ziele, fehlende Prüfpunkte sowie manuelle Berechtigungsmodi bleiben angehalten.
9.1.418
  • Telegram bewahrt nun die ausdrückliche Bot-Kennzeichnung des Absenders in den Eingangsdaten, damit der Identitätskontext Agenten von Menschen unterscheiden kann.
  • Bereits als Menschen gespeicherte Telegram-Akteure werden nur dann zu Agenten korrigiert, wenn Anbieter, Subjekt und ausdrückliche Bot-Kennzeichnung übereinstimmen.
  • Akteursdetails bleiben erhalten, Agenten werden niemals herabgestuft und Namen oder Benutzernamen werden nie zur Ableitung einer Agentenidentität verwendet.
9.1.417
  • Automatische Telegram-Ersatzantworten teilen Antworten mit mehr als 4.096 Zeichen nun in aufeinanderfolgende Nachrichten auf, statt sie zu kürzen.
  • Jedes Zeichen und jedes Unicode-Surrogatpaar bleiben erhalten; der Ausgang erfasst alle zurückgegebenen Nachrichten-IDs zusammen mit dem vollständigen Text.
  • Wenn ein Teil fehlschlägt, stoppt die Zustellung an dieser Stelle, statt eine unvollständige Antwort als vollständig zu melden.
9.1.416
  • Frische Ergebnisse aus dem jüngsten Werkzeugaufruf-Stapel bleiben bis zur nächsten Assistentenantwort vollständig lesbar, selbst wenn anschließend Telegram- oder Steuerungskontext eingespeist wird.
  • Stapelauslagerung, Verlaufsbereinigung und Mikroverdichtung verwenden nun dieselbe semantische Grenze für frische Ergebnisse.
  • Bereits ausgewertete ältere Ergebnisse werden weiterhin normal verdichtet, sodass die bisherigen Kontexteinsparungen erhalten bleiben.
9.1.415
  • Der dauerhafte Arbeitsfokus bewahrt den exakten Auslöser für die nächste Aktion nun über Neustarts und Kontextwechsel hinweg.
  • Die nächste Aktion bleibt von ihrer Freigabebedingung getrennt; das gilt auch für gültige Bedingungen mit mehr als 512 Zeichen.
  • Fehlerhafte oder zur Phase unpassende Auslöser werden sicher abgewiesen; ältere Prüfpunkte behalten ihr bisheriges Verhalten.
9.1.414
  • Neue dauerhafte Aktionsprüfpunkte erfassen den exakten Auslöser, der die nächste Aktion freigibt.
  • Nicht wartende Phasen benötigen einen unmittelbaren Auslöser; wartende Phasen benötigen ein benanntes externes Ereignis, einen Zeitpunkt, eine Abhängigkeit oder eine Nutzerentscheidung.
  • Wartende Ziele bleiben aktiv, ohne vorzeitig ausgeführt zu werden; ältere Prüfpunkte bleiben lesbar.
9.1.413
  • Telegram-Antworten, die das Ausgabelimit des Modells erreichen, werden nicht mehr als unvollständige Anfänge zugestellt.
  • Dieselbe laufende Sitzung erzeugt eine knappe, vollständige Fortsetzung und unternimmt höchstens drei Wiederherstellungsversuche, bevor sie sicher abbricht.
  • Eine ausdrückliche Antwort über das Telegram-Werkzeug hat weiterhin Vorrang und unterdrückt die Wiederherstellung, sodass erfolgreiche Sendungen nie dupliziert werden.
9.1.412
  • Vom Modell erstellte dauerhafte Ziele beginnen nun atomar mit Revision 1 und einem vollständigen begrenzten Problemrahmen.
  • God Mode und Automatikmodus setzen einen bereits autorisierten Zielstart ohne zweite Bestätigung fort; im manuellen Modus bleibt die Freigabe erforderlich.
  • Authentifizierte, nicht triviale mehrstufige Arbeit kann unter einer bestehenden autonomen Anweisung in den dauerhaften Zielmodus wechseln; Begrüßungen, einstufige Anfragen und vage Aufgaben bleiben ausgeschlossen.
9.1.411
  • Nicht triviale und unbekannte Aufgaben können nun einen begrenzten Problemrahmen im dauerhaften Aktionsprüfpunkt speichern.
  • Der Rahmen erfasst Erfolgskriterien, fehlendes Wissen, bis zu fünf mögliche Aktionen, die ausgewählte Aktion mit Begründung, die Wahl der Unterstützung, das Risiko und den Rückfallpfad.
  • Der Problemrahmen übersteht Fortsetzung und Neustart ausschließlich als beschreibender Zustand und kann niemals Berechtigungen erteilen.
9.1.410
  • Private Telegram-Speicherbefehle begrenzen den Beziehungsbereich nun auf die jeweilige Person.
  • Der Speicherfokus blendet Beziehungen anderer Personen aus und behält den übrigen Kontext bei.
  • Korrekturen und Löschungen können keine Beziehung einer anderen Person auswählen; der lokale Betreiberfokus behält die vollständige Sicht.
9.1.409
  • Telegram-Antwortwerkzeuge und der TUI-Rückfallpfad verwenden nun ein gemeinsames kanonisches Verzeichnis für den Kanalzustand.
  • Profilspezifische BLUN_HOME-Werte erzeugen keinen zweiten Verzeichnisbaum für Telegram-Ein- oder -Ausgänge mehr.
  • Ein ausdrücklich gesetztes BLUN_TELEGRAM_STATE_DIR bleibt maßgeblich; andernfalls verwenden beide Pfade ~/.blun/channels/telegram.
9.1.408
  • Bestätigte Beziehungsdetails werden erst nach zwei unabhängigen Beobachtungen in direkten Kanälen zusammengeführt.
  • Erneut abgespielte Nachrichten bleiben idempotent; Gruppennachrichten und berechtigungsähnliche Behauptungen bleiben ausgeschlossen.
  • Bestätigte private Beziehungserinnerungen können derselben Person über Telegram und CLI hinweg folgen, ohne Befugnisse zu erteilen.
9.1.407
  • Das Telegram-Antwortwerkzeug importiert den von der Duplikaterkennung verwendeten Pfad zum laufenden Eingangsverlauf.
  • Normale Telegram-Antworten scheitern nicht mehr mit dem Fehler inboxLog is not defined.
  • Der getrennte Bridge-Rückfallpfad bleibt als Absicherung der Zustellung verfügbar.
9.1.406
  • Wiederholte Zustellversuche privater Telegram-Ereignisse mit demselben Zeitstempel und Text werden in der Beziehungskontinuität nur einmal gespeichert.
  • Eine tatsächlich später wiederholte Aussage bleibt Bestandteil des begrenzten Beziehungsverlaufs.
  • Natürlich formulierte ausdrückliche Erinnerungshinweise am Satzende werden als Referenzdaten erkannt, ohne Berechtigungen zu erteilen oder zu verändern.
9.1.405
  • Der gekoppelte Telegram-Befehl /status meldet nun Alter und Herzschlag des Konsolenprozesses, den aktuellen Arbeitsschritt sowie die aktive Aufgabe, ohne das Modell aufzurufen.
  • Der Queue-Rückstand misst jetzt ungelesene Bytes ab einem Prüfpunkt, der an die exakte aktuelle Queue-Datei gebunden ist.
  • Der Fernstatus bleibt schreibgeschützt und enthält weder Chat-IDs, Dateipfade, Zugangsdaten und Nachrichteninhalte noch vollständige Aufgabenlisten.
9.1.404
  • Unveränderter Inhalt der config.toml ersetzt die bestehende private Datei nicht mehr.
  • Der exakte Bytevergleich ist auf reguläre Ziele beschränkt, die keine symbolischen Links sind.
  • Geänderte, fehlende, ungültige und nicht lesbare Ziele verwenden weiterhin den bestehenden absturzsicheren atomaren Schreibpfad.
9.1.403
  • Die automatische Rangfolge nachladbarer Werkzeuge ignoriert eingebettete Anhangs- und Dokumentnutzlasten.
  • Jedes Absichtsfragment wird vor dem lexikalischen Abgleich auf das bestehende ToolSearch-Abfragebudget von 1.000 Zeichen begrenzt.
  • Die eigentlichen Anweisungen, Anhänge und ausdrücklichen ToolSearch-Anfragen bleiben unverändert.
9.1.402
  • Abgelaufene Archive des Verdichtungsverlaufs werden beim Start eines King-Befehls einmalig im Hintergrund bereinigt.
  • Die Startbereinigung bleibt nicht blockierend und kann die normale Befehlsverarbeitung nicht verzögern.
  • Fehler bei der Bereinigung werden sicher protokolliert und unterbrechen die laufende Sitzung nicht.
9.1.401
  • Das erste Textfragment jeder laufenden Antwort wird nun sofort dargestellt, statt auf einen Zeitgeber-Rückruf zu warten.
  • Ein neuer Zug und jedes neue Assistentenantwortsegment erhalten jeweils eine eigene sofortige Erstdarstellung.
  • Spätere Text-, Denk- und Werkzeugfragmente behalten den adaptiven Bündelungsrhythmus, der die Leistung langer Sitzungen schützt.
9.1.400
  • Große fortgesetzte Sitzungen werden nun kooperativ wiedergegeben, damit die TUI während der Wiederherstellung des Verlaufs neu zeichnen und reagieren kann.
  • Jeder dauerhaft gespeicherte Wiedergabedatensatz wird weiterhin dargestellt; kein Teil des Verlaufs wird abgeschnitten, übersprungen oder gelöscht.
  • Kleine Fortsetzungen behalten ihr bisheriges Verhalten; große Fortsetzungen geben nach jeweils 30 Datensätzen die Ausführung an die Ereignisschleife ab.
9.1.399
  • Geprüfte Lernkandidaten sind nun auf das aktuelle Git-Projekt begrenzt, statt in nicht zugehörige Repositorys zu gelangen.
  • HTTPS- und SSH-Checkouts desselben Ursprungs verwenden eine gemeinsame anonyme Projektidentität.
  • Repository-URLs und lokale Projektpfade werden nie in Datensätzen für Lernkandidaten gespeichert; Arbeit außerhalb von Git behält das bestehende profilweite Verhalten.
9.1.398
  • Reine Telegram-Textantworten werden nun über den Werkzeugpfad und beide automatischen Rückfallpfade hinweg dedupliziert.
  • Eine identische oder nahezu identische Antwort wird nur unterdrückt, wenn keine neuere eingegangene Nachricht vorliegt.
  • Anhänge, unterschiedliche Ergebnisse und Antworten nach einer neuen Nutzernachricht behalten ihr bisheriges Verhalten.
9.1.397
  • Ziele mit einem ausdrücklichen Abschlusskriterium benötigen vor dem Abschluss nun einen von der Laufzeit gestützten Prüfpunkt.
  • Schlägt die Abschlussprüfung fehl, bleibt das Ziel aktiv und gibt konkrete Hinweise zur Überarbeitung zurück.
  • Gewöhnliche Züge und Ziele ohne ausdrückliches Abschlusskriterium behalten ihr bisheriges Verhalten.
9.1.396
  • Natürliche Anfragen können im selben Zug bis zu zwei mit hoher Sicherheit passende nachladbare Werkzeugschemas vorab auswählen.
  • Die Auswahl berücksichtigt ausschließlich die aktuelle Absicht im Kanal und ignoriert veralteten Telegram-Kontext.
  • Für schwache, mehrdeutige oder unbekannte Anfragen bleibt ToolSearch verfügbar, ohne die dauerhaft geladene Werkzeugmenge zu vergrößern.
9.1.395
  • Angenommene Medienjobs werden dauerhaft verfolgt, gleiche offene Anfragen wiederverwendet und abgeschlossene Ergebnisse nach Qualitätsprüfung gespeichert sowie dem zugehörigen Chat zugestellt.
9.1.394
  • Ein versionierter, freiwillig aktivierbarer Speicheranbieter kann CLI- und Portalzüge mit einem gemeinsamen kognitiven Ereignisstrom verbinden.
  • Voreingestellt bleibt der bestehende lokale SQLite-Speicher, ohne neuen Netzwerkzugriff oder verändertes Laufzeitverhalten.
  • Anbieterpfade, synchrone Fabrikfunktionen und Vertragsversion 6 werden nun vor dem Start der Laufzeit sicher geprüft und bei Abweichungen abgewiesen.
9.1.393
  • Interaktive Starts mit king und king -c zeigen wieder die sichtbare Update-Auswahl 1/2/3, sobald eine neuere Version vorliegt.
  • Das Herunterladen von Updates im Hintergrund, die ausstehende Aktivierung und der verzögerte automatische Wechsel wurden entfernt.
  • Nach einer ausgewählten Installation beendet sich king für einen manuellen Neustart; king -c setzt die letzte Sitzung mit der neuen Version fort.
9.1.392
  • Unvollständige Zwischenstände einer Bilderzeugung werden nicht mehr als private Telegram-Aktualisierung gesendet, solange noch kein Medienergebnis vorliegt.
  • Die gemessenen Fehlerbeschreibungen von GenerateImage und GetMedia werden unterdrückt; abgeschlossene Medienzustellungen bleiben sichtbar.
  • Private Unterhaltungen und gewöhnliche angeforderte Ergebnisse bleiben unverändert.
9.1.391
  • Portalübergreifende Erinnerungskontinuität erfordert nun einen exakten, aktiven Identitätsverknüpfungsbeleg der vertrauenswürdigen Laufzeit.
  • Ähnliche Namen, abweichende Mandanten oder Quellidentitäten, falsche Aussteller und widerrufene Belege bleiben voneinander getrennt und werden sicher abgewiesen.
  • Version 6 des Speicheradaptervertrags unterstützt verifiziertes OAuth, sichere Kontoverknüpfungen und ausdrücklich bestätigte Identitätszuordnungen, ohne Berechtigungen aus Erinnerungen abzuleiten.
9.1.390
  • Der gemeinsame Speicherumschlag erfasst den Ereigniszeitpunkt und den Eingangszeitpunkt nun getrennt.
  • Jedes neue kognitive Ereignis erhält ausdrücklich eine Aufbewahrungsklasse für Betriebsdaten, dauerhafte Daten, Beziehungen oder Prüfzwecke.
  • Version 5 des Speicheradaptervertrags weist unvollständige Ereignisumschläge vor jedem lokalen oder entfernten Schreibvorgang ab.
9.1.389
  • Speicherereignisse erfassen Quellportal und Quellkanal nun als getrennte, authentifizierte Herkunftsfelder.
  • CLI-, Telegram-, Laufzeit-, Persönlichkeits-, Korrektur- und Widerrufspfade bewahren den exakten Kanal bei Speicherung und Wiedergabe.
  • Version 4 des Speicheradaptervertrags weist Schreibvorgänge ab, wenn der gespeicherte Quellkanal nicht mit dem durch die Berechtigung freigegebenen Kanal übereinstimmt.
9.1.388
  • Speicherlesevorgänge geben nur noch Beobachtungen aus dem durch die Berechtigung freigegebenen Sichtbarkeitsbereich zurück, sofern nicht der strikt interne Agentenpfad verwendet wird.
  • Schreibvorgänge, Ereignisprüfungen und Attention-Operationen werden sicher abgewiesen, wenn ihr Geltungsbereich oder ihre authentifizierte Quelle nicht zum aktuellen Zugriffskontext passt.
  • Der lokale SQLite-Adapter fragt eingegrenzte Beobachtungen über einen eigenen Sichtbarkeitsindex ab, statt zunächst nicht zugehörige Erinnerungen zu laden.
9.1.387
  • Jede Operation eines Speicheradapters führt nun einen strikten Kontext für Identität, Portal, Kanal, Unterhaltung, Geltungsbereich und Berechtigungen mit.
  • Der Berechtigungskontext wird außerhalb der Speichernutzlast geprüft und nicht als erinnerter Inhalt dauerhaft abgelegt.
  • Die Deduplizierung von Ereignissen ist auf Mandant und Agent begrenzt. Dadurch lässt sich die Existenz von Ereignissen nicht mandantenübergreifend erkennen.
9.1.386
  • Der kognitive Zustand liegt nun hinter einem versionierten Vertrag für Speicheradapter, den der Zuglebenszyklus und die Persönlichkeitslaufzeit gemeinsam verwenden.
  • Der bestehende SQLite-Ereignisspeicher bleibt die Voreinstellung. Externe Portal-Clients können denselben Vertrag bereitstellen, ohne einen portal-eigenen Zustand anzulegen.
  • Nicht unterstützte Adapterversionen und unvollständige Implementierungen werden vor jeder Speicheroperation sicher abgewiesen.
9.1.385
  • Telegram-Nachrichten, die vor dem Sitzungsstart eingereiht wurden, werden nun freigegeben, sobald die Sitzung bereit ist.
  • Sitzungen im Leerlauf leeren die Warteschlange in der normalen FIFO-Reihenfolge; bereits fortgesetzte aktive Züge verwenden eine begrenzte Steuerung.
  • Dauerhafte Queue-Prüfpunkte bleiben unverändert, bis die Nachricht tatsächlich angenommen wurde.
9.1.384
  • Verweise auf Telegram-Bilder laden nun im selben Zug die Werkzeuge zur Bildprüfung und Bilderzeugung.
  • Gepufferte Telegram-Nachrichten bewahren die Medienabsicht für den gesamten ausstehenden Stapel, statt nur die letzte Nachricht zu berücksichtigen.
  • Lokale Bildpfade und Telegram-Dateikennungen wählen den passenden Prüf- oder Downloadweg, ohne Medienschemas dauerhaft zu laden.
9.1.383
  • Neue Read-Ergebnisse bleiben nun für den Modellschritt, der sie angefordert hat, vollständig sichtbar, statt vor der Auswertung ausgelagert zu werden.
  • Parallele neue Werkzeugergebnisse bleiben bis zu ihrem Auswertungsschritt lesbar und dürfen erst archiviert werden, nachdem sie historisch geworden sind.
  • Die Archivierung historischer Ausgaben und die Kontexteinsparung bleiben nach dem geschützten Fenster für die jüngste Arbeit aktiv.
9.1.382
  • Der Befehl /loop wird jetzt auch angenommen, während eine andere Antwort läuft.
  • Wird während laufender Arbeit eine Schleife erstellt, speichert King sie und reiht ihre erste Anweisung ein, ohne den aktuellen Zug zu unterbrechen.
  • Die Schleifenerstellung im Leerlauf sowie das bestehende Verhalten für Status, Pause, Fortsetzung und Stopp bleiben unverändert.
9.1.381
  • Nach einer endgültig erfolglosen ToolSearch wird ToolSearch für den Rest dieses Zugs aus der aktiven Werkzeugliste entfernt.
  • Die erfolgreiche Schemaerkennung und der Umgang mit bereits geladenen Werkzeugen bleiben verfügbar und unverändert.
  • Dadurch verbrauchen wiederholte Synonymsuchen keine weiteren Token, nachdem die Laufzeit bereits belegt hat, dass keine geeignete Integration vorhanden ist.
9.1.380
  • Ein vorübergehender Fehler bei der Steuerung des aktiven Zugs aktiviert die Telegram-Zustellsteuerung nun sofort erneut, statt die wiederhergestellte Gruppennachricht bis zum Zugende warten zu lassen.
  • Anstehende Gruppennachrichten werden auch während langer Arbeit weiter zugestellt; dabei bleiben die FIFO-Reihenfolge und die bestehende Quarantänegrenze von drei Versuchen erhalten.
  • Keine laufende Sitzung wird unterbrochen oder neu gestartet.
9.1.379
  • Vorübergehende Wiederholungen der Bestätigung einer Kanalsteuerung zeigen keinen falschen roten Fehler mehr, solange die Nachricht in der Warteschlange wiederherstellbar bleibt.
  • Ein sichtbarer Zustellfehler erscheint erst, nachdem der dritte fehlgeschlagene Versuch den vollständigen ersten Queue-Eintrag sicher archiviert hat.
  • Das Verhalten für Wiederholung, Bestätigung, Archivierung und FIFO-Reihenfolge bleibt unverändert.
9.1.378
  • Bei schnell aufeinanderfolgenden Hintergrundveröffentlichungen gibt es nun einen einzigen ersetzbaren Status für das vorbereitete Update, statt für jede Version einen neuen Protokollbestandteil anzuhängen.
  • Der Eintrag für das vorbereitete Update zeigt stets die neueste verifizierte Zielversion; die aktive Sitzung bleibt bis zu ihrem natürlichen Neustart unangetastet.
  • Der Hinweis auf die tatsächliche Installation und den Changelog bleibt dauerhaft und unverändert erhalten. Weniger Änderungen im Protokoll verbergen daher kein aktiviertes Update.
9.1.377
  • Anstehende Telegram-Aufträge übernehmen nun die maßgebliche ID des aktiven Zugs vom Kern. Ein veralteter sichtbarer TUI-Status kann dadurch nicht mehr dazu führen, dass eine angenommene Nachricht unbestätigt bleibt.
  • Der Steuerbefehl /loop wird während laufender Arbeit sofort ausgeführt; die dauerhafte Befehlsbestätigung hängt nicht mehr von einer erfolgreichen Telegram-Statusantwort ab.
  • Schlägt die Zustellung des ersten Queue-Eintrags dreimal fehl, wird er mit sämtlichen Wiederherstellungsmetadaten lokal archiviert, bevor die Warteschlange fortfährt. So blockiert ein fehlerhafter Eintrag keine späteren Nachrichten.
9.1.376
  • Große historische Werkzeugergebnisse werden vor der Kontextverdichtung dauerhaft gespeichert, sodass ihre vollständige Ausgabe auch nach dem Leeren der eingebetteten Vorschau wiederherstellbar bleibt.
  • Die gespeicherten Ergebnisverweise überstehen spätere Mikroverdichtungen und behalten die begrenzten Metadaten, die zum erneuten Laden der ursprünglichen Ausgabe erforderlich sind.
  • Die Auslagerungstelemetrie meldet Größen und Wiederherstellungsstatus, ohne Ergebnisinhalte oder private Pfade offenzulegen.
9.1.375
  • Private Telegram-DMs und Slash-Befehle behalten die höchste Zustellpriorität. Explizit adressierte Gruppenarbeit wird danach FIFO vor normaler oder nicht adressierter Altlast eingereiht.
  • Ein Update-Handoff darf eine nichtleere Queue nur dann überqueren, wenn jeder Eintrag haltbare, noch nicht bestätigte Telegram-Arbeit mit Acknowledge- Rückweg ist. Lokale, gemischte oder nicht haltbare Arbeit blockiert weiterhin.
  • Der Hinweis für vorbereitete Updates folgt einer freigegebenen Persona- UI-Sprache. Bei einer noch nicht als TUI-Locale freigegebenen Sprache wird nur die Versionsinformation gezeigt, statt in eine falsche Sprache zu fallen.
9.1.374
  • Der Hinweis für ein vorbereitetes Update verwendet keine fest eingebaute deutsche Meldung mehr, sondern die bereits freigegebene UI-Übersetzung der aktiven Sprache.
  • Resume- und Neue-Sitzung-Modus bleiben getrennt; Update-Handoff, Rollback und Telegram-Duplikatbestätigung wurden nicht aufgeweicht.
9.1.373
  • Ein im Hintergrund vorbereitetes Update kann die laufende Sitzung jetzt an einer verifizierten sicheren Grenze übernehmen. Session-ID und Arbeitsverzeichnis bleiben erhalten; laufende Werkzeuge, Shell-Befehle, Kompaktierung und wartende Nachrichten verhindern die Übergabe.
  • Der Supervisor aktiviert die neue Runtime erst nach deren loaded- und ready-Beleg. Scheitert der Start, wird die alte Runtime samt exakter Sitzung wiederhergestellt und das fehlerhafte Pending verworfen.
  • Bereits in der Delivery-Ledger wiederhergestellte Telegram-Duplikate werden beim Queue-Replay sofort quittiert. Sie warten nicht mehr auf einen Modellschritt, der für ein Duplikat absichtlich nie startet, und blockieren damit keine nachfolgenden Gruppenmeldungen mehr.
  • Der dauerhafte Arbeitsfokus trägt nun Wissensstatus, Belegkontext, Korrekturen, Rücknahmen und Konfidenz über Turns hinweg. Daraus entstehen weiterhin keine neuen Rechte oder Freigaben.
9.1.372
  • Dauerhafte Ziel-Checkpoints unterscheiden jetzt verified, credible_unverified, hypothesis, uncertain_memory, stale und unknown. Plausible Vermutungen werden dadurch nicht mehr wie gesichertes Wissen behandelt.
  • Herkunft und Wissensstatus werden gemeinsam geprüft: Laufzeit-Werkzeugbelege dürfen nur nach einem erfolgreichen Werkzeuglauf als verified gelten, externe Berichte nicht. Carry-forward-Stände bewahren ihren bisherigen Status und ihren letzten Verifikationsbeleg.
  • Alte Replay-Stände ohne das neue Feld bleiben als legacy_unknown lesbar. Neue Checkpoints müssen ihren Status explizit nennen. Rechte, Freigaben und Autorität bleiben unverändert.
  • Die knappe Kontextprojektion nennt den epistemischen Zustand in genau einer Zeile, damit der Agent ihn beim nächsten Schritt berücksichtigt, ohne das Kontextbudget mit Zusatztext zu belasten.
9.1.371
  • Reparatur eines Verkabelungsfehlers aus 9.1.370: Der dort bereits gespeicherte und projizierte evidenceBasis-Wert ist jetzt auch Bestandteil des strikten öffentlichen GetGoal-Ausgabeschemas und geht beim Abruf nicht mehr verloren.
  • Das Schema akzeptiert die vier aktuellen Herkunftstypen sowie legacy_unknown für alte Replay-Stände. Rechte, Freigaben und Autorität bleiben unverändert.
  • Eine fokussierte Verkabelungsprobe und ein eigener Mutant sichern die neue öffentliche Verbindung gegen Rückfall ab.
9.1.370
  • Jeder frische Arbeits-Checkpoint benennt jetzt explizit, worauf sein letzter belegter Stand beruht: erfolgreicher Laufzeit-Werkzeugaufruf, direkte Benutzeraussage, externer Bericht oder unveränderte Fortschreibung.
  • runtime_tool wird nur akzeptiert, wenn der aktuelle Turn mindestens einen durch die Laufzeit zugelassenen und erfolgreich beendeten Werkzeugaufruf enthält. carried_forward darf den zuletzt belegten Stand nicht verändern. Beide Pfade brechen bei Widerspruch fail-closed ab.
  • Alte gespeicherte Checkpoints bleiben als legacy_unknown lesbar. Der Herkunftstyp ist epistemischer Zustand und erzeugt weder Rechte noch Freigaben oder Autorität.
9.1.369
  • Ein dauerhafter Arbeits-Checkpoint erhält jetzt automatisch einen kompakten Laufzeitbeleg aus den bereits abgeschlossenen Werkzeugaufrufen desselben Turns. Der Beleg nennt nur Turn-ID, Gesamt-, Erfolgs- und Fehlerzahl sowie einen kurzen Digest.
  • Werkzeugnamen, IDs, Argumente, Befehle, Ausgaben, Pfade und Benutzertext werden nicht in den Checkpoint geschrieben. Ein leerer Beleg bleibt ehrlich bei null statt eine Messung vorzutäuschen.
  • Nur ein durch die Laufzeit-Policy freigegebener und erfolgreich beendeter Werkzeugaufruf zählt als Erfolg. Geblockte, fehlgeschlagene, abgebrochene oder vom Modell mitgelieferte Belege erzeugen keine Autorität.
9.1.368
  • Jeder dauerhafte Arbeits-Checkpoint trägt jetzt eine monotone Revision. Der erste Schreibzug beginnt bei Revision 1; jeder weitere muss die aktuell projizierte Revision exakt um eins erhöhen.
  • Ein alter Parallelturn oder eine veraltete Kanalansicht kann einen neueren belegten Arbeitsstand nicht mehr nachträglich überschreiben. Veraltete, übersprungene und ungültige Revisionen brechen fail-closed ab, bevor der Zielzustand verändert wird.
  • Bestehende Checkpoints ohne Revisionsfeld werden beim Lesen kompatibel als Revision 1 behandelt. Die Revision ist Arbeitszustand und erzeugt keine Rechte oder Freigaben.
9.1.367
  • Der aktive Ziel-Reminder trägt den dauerhaften Arbeits-Checkpoint jetzt direkt. Der King behält Phase, letzten belegten Stand, exakte nächste Aktion und erwarteten Beleg daher auch dann, wenn der zusätzliche kognitive Speicheradapter gerade nicht zur Verfügung steht.
  • Vor alternativen Wegen wird zuerst die exakt vorgemerkte nächste Aktion ausgeführt. Der Checkpoint wird erst geändert, wenn neue Evidenz den bestätigten Stand wirklich verändert.
  • Der Fallback ist nur eine kompakte Projektion des bereits geprüften Checkpoints. Er erzeugt keine Rechte, keine neuen Datenfelder und keinen Neustart.
9.1.366
  • Aktive Ziele können jetzt einen kleinen, dauerhaften Arbeits-Checkpoint mit Phase, letztem belegten Ergebnis, exakter nächster Aktion und erwartetem Beleg speichern. Nach Resume oder Event-Replay setzt der King an dieser Stelle fort, statt erneut um Erlaubnis zu fragen oder von vorn zu beginnen.
  • Ein reines Checkpoint-Update lässt das Ziel aktiv. Pausierte und blockierte Ziele bleiben unverändert; ein Resume setzt nur die Laufzeituhr neu.
  • Der Checkpoint ist streng begrenzt und reine Arbeitsinformation. Unbekannte Felder, insbesondere Rechte- oder Administrationsangaben, brechen fail-closed ab und können keine Capability erzeugen.
  • Ohne Checkpoint bleibt der bisherige kompakte Fokus unverändert. Mit Checkpoint werden nur die vier relevanten Fokusbeobachtungen um den belegten Stand ergänzt; damit bleibt der Tokenaufwand klein und konstant.
9.1.365
  • Private Telegram-DMs und die lokale CLI können dauerhaften Fokus jetzt mit /memory focus, /memory correct <id> <wert> und /memory delete <id> direkt lesen, korrigieren oder löschen. Der Weg startet keinen Modellturn und verbraucht deshalb keine Modelltokens.
  • Telegram-Änderungen sind an positive Nutzer-, Chat- und Nachrichten-IDs, eine echte Privat-DM, den Kanalzeitpunkt und eine stabile Request-ID gebunden. Gruppen, unvollständige Herkunft und veränderte Wiederholungen brechen fail-closed ab.
  • Domain, Schlüssel und Scope werden immer aus dem aktiven Zielbeleg abgeleitet und können nicht vom Aufrufer eingeschleust werden. Korrekturen und Tombstones bleiben append-only, bewahren die Historie und erteilen keine Rechte.
  • Die Fokusausgabe ist für Telegram auf acht Einträge und weniger als 3.500 Zeichen begrenzt; die Gesamtzahl bleibt sichtbar.
9.1.364
  • Der laufende kognitive Lifecycle kann einen dauerhaften Fokus jetzt über correctFocusObservation korrigieren und über withdrawFocusObservation löschen. Beide Wege schreiben weiter append-only in denselben tenant- und agentengebundenen Ereignisstrom.
  • Eine Revision ist nur mit der Attestierung runtime_user_prompt_hook und explicit_user_request zulässig. Ein normaler Modell-Snapshot kann weder Korrektur noch Löschung ableiten oder einschmuggeln.
  • Jede Revision trägt eine stabile Request-ID sowie Portal, Akteur, Kontext, Nachricht und Zeitpunkt. Identische Wiederholung ist idempotent; dieselbe Request-ID mit verändertem Inhalt und rückdatierte Revisionen brechen fail-closed ab.
  • Korrektur und anschließende Löschung lassen die vollständige Historie unverändert. Nach der Löschung erscheint der Fakt nicht mehr im Prompt und verbraucht keine Kontexttokens. Memory kann weiterhin keine Rechte erteilen.
9.1.363
  • Eine bestätigte Löschung wird jetzt als append-only Tombstone gespeichert. Der frühere Inhalt bleibt im Auditverlauf und in der Hash-Kette erhalten, verschwindet aber vollständig aus der wirksamen Kontextprojektion.
  • Alte Resume-, Transcript- oder Queue-Ereignisse mit einem Zeitpunkt vor der Löschung können den entfernten Inhalt nicht wieder aktivieren. Damit wird ein später erneut eingespielter Altstand nicht als neue Wahrheit behandelt.
  • Bewusst neu erteilte Information nach dem Löschzeitpunkt kann wieder gelernt werden. Der Tombstone sperrt also alte Evidenz, nicht zukünftige Entwicklung.
  • Löschungen über fremde Tenants, Agenten, Domains, Schlüssel oder Scopes, mit fehlendem Ziel, schwacher Konfidenz oder falschem Tombstone-Wert werden transaktional abgewiesen. Bestehende Datenbanken migrieren in-place.
  • Ein gelöschter Fakt erzeugt keine Promptzeile und verbraucht damit keine Kontexttokens.
9.1.362
  • Eine bestätigte Korrektur kann jetzt genau eine frühere Beobachtung im gleichen Tenant-, Agent-, Domain-, Schlüssel- und Scope-Bereich explizit ablösen. Der alte Eintrag bleibt append-only im Auditverlauf erhalten.
  • Die wirksame Sicht lädt den korrigierten Wert und markiert ihn als corrected; der abgelöste Wert wird nicht mehr als aktueller Konflikt projiziert.
  • Fehlende Ziele, fremde Scopes oder Schlüssel und Korrekturen unter Konfidenz 1 werden transaktional abgewiesen.
  • Bestehende SQLite-Stände erhalten die neue Relationsspalte beim Öffnen, ohne ihren bisherigen Stream oder ihre Version zu verlieren.
9.1.361
  • Gleich glaubwürdige persönliche oder Team-Aussagen mit demselben Scope und Schlüssel werden nicht mehr nach dem Prinzip "neuester Wert gewinnt" als Wahrheit ausgegeben. Die Projektion markiert den Konflikt knapp und fordert eine Klärung, ohne beide Inhalte in den Kontext zu kippen.
  • Ist eine Aussage mindestens 0,2 Konfidenzpunkte stärker, bleibt sie nutzbar, wird aber als umstritten gekennzeichnet. Eine spätere schwächere Behauptung kann einen bestätigten Stand nicht mehr verdecken.
  • Identische Bestätigungen werden zu einem Fokuspunkt zusammengefasst. Kanonische Ziel- und Fortschrittsfelder bleiben weiterhin revisionsfähig.
  • Die append-only Ereignishistorie bleibt unverändert; Berechtigungen können aus der wirksamen Sicht weiterhin nicht entstehen.
9.1.360
  • Der bereits kanonische /goal-Zustand wird als dauerhafter Arbeitsfokus in den kognitiven Ereignisstrom projiziert: Ziel, Status, nächster Auslöser und erwarteter Erfolgsbeleg.
  • Derselbe Fokus bleibt über Runtime-Neustarts idempotent. Ein unveränderter Zielstand erzeugt keine doppelten Ereignisse oder Beobachtungen.
  • Nutzungszähler, Zeitbudget und Berechtigungen werden nicht in den Fokus kopiert. Ohne aktives Ziel werden keine zusätzlichen Fokus-Tokens geladen.
  • Die Projektion verbindet den passenden Ziel-Scope mit dem privaten Beziehungs-Scope des aktuellen Turns; sie erzeugt keine Rechte.
9.1.359
  • Personality-Memory und echte CLI-Turns verwenden nun denselben Tenant- und Agenten-Identitätsstrom aus identity/manifest.json; ohne vollständige Identität bleibt der kompatible gehashte Rückfallpfad erhalten.
  • Direkte Telegram-Turns projizieren nur den privaten Beziehungsbereich des aktuellen Gegenübers. Gruppen und fremde Beziehungen liefern keine privaten Fokus-Tokens.
  • Die Scope-Auswahl ist vor dem Ranking erzwungen; eine neuere Erkenntnis aus einem fremden Scope kann einen passenden Eintrag nicht mehr verdecken.
9.1.358
  • Ein Netzwerkfehler während der automatischen Update-Vorbereitung wurde nur an einen optionalen Fehler-Callback gemeldet. Ohne erneuten Poll blieb der laufende King auf seinem Stand, obwohl die Sitzung selbst gesund weiterlief.
  • Der Launcher schreibt jetzt ein begrenztes prepare-failed-Ereignis mit Versionsstand sowie sicherem Fehlernamen/-code nach handoff.jsonl.
  • Danach wird genau zehn Sekunden später ein neuer Vorbereitungsversuch geplant. Der laufende Core wird weder beendet noch neu geladen.
  • Fehler beim Schreiben des Diagnoseereignisses bleiben fail-soft; Token, Nachrichtentext und sonstige Geheimnisse werden nicht protokolliert.
9.1.357
  • Wiederholte Zugriffe auf denselben effektiven Systemprompt bauen die große Zeichenkette aus Basis und Laufzeit-Anhang nicht mehr bei jedem Zugriff neu.
  • Der Resolver hält genau eine aktuelle Basis-/Anhang-Kombination und invalidiert sie sofort, sobald sich einer der beiden Eingabewerte ändert.
  • Leerprompt, Nur-Basis, Nur-Anhang und die bisherige Trennung mit zwei Zeilenumbrüchen bleiben bytegleich erhalten.
9.1.356
  • Unveränderte Systemprompts werden über wiederholte Modellschritte nur noch einmal zeichenweise für das Kontextbudget gezählt.
  • Der Cache ist auf vier Einträge, höchstens 500.000 Zeichen je Prompt und insgesamt 1.000.000 gehaltene Zeichen begrenzt.
  • Geänderte Prompts werden weiterhin neu gezählt; Kontextanzeige, Kompaktierungsbudget und Anfragebudget verwenden denselben aktuellen Wert.
9.1.355
  • Unveränderte LLM-Anfragekonfigurationen serialisieren ihre Werkzeug-Schemata nicht mehr bei jedem Modellschritt erneut nur für das Konfigurationslog.
  • Modell, Alias, Denkstufe, Systemprompt und Werkzeugfolge werden gegen den letzten vollständigen Stand verglichen.
  • Geänderte Modelle, Prompts, Werkzeugnamen, Beschreibungen oder Parameterschemata öffnen das Konfigurationslogging weiterhin gezielt neu.
9.1.354
  • Unveränderte Werkzeug-Schemata werden pro Werkzeugobjekt nur noch einmal serialisiert und für das Kontextbudget gezählt.
  • Ein Inventar mit 403 Werkzeugen wird dadurch bei wiederholten Anfrageprüfungen nicht immer wieder vollständig neu gezählt.
  • Änderungen an Name, Beschreibung oder Parameterobjekt verwerfen gezielt nur den Cache-Eintrag des betroffenen Werkzeugs.
9.1.353
  • Argumentfragmente von Agentenschwarm-Werkzeugen werden weiterhin sofort geparst und in den Fortschrittszustand übernommen, teilen sich jetzt aber den adaptiven Render-Timer.
  • Ein großer gestreamter Werkzeugaufruf löst dadurch nicht mehr für jedes Argumentfragment einen kompletten TUI-Render aus.
  • Start, Abschluss, Fehler und Abbruch entfernen offene Schwarm-Timer vor ihrem abschließenden Sofort-Render.
9.1.352
  • Assistant- und Thinking-Fragmente eines Agentenschwarms aktualisieren den Fortschrittszustand weiterhin sofort, teilen sich aber einen adaptiven Render-Timer.
  • Ein Fragmentsturm löst damit nicht mehr für jedes Delta einen kompletten TUI-Render aus.
  • Diskrete Schwarmereignisse und das Aufräumen des Fortschritts entfernen offene Timer vor ihrem sofortigen Abschluss-Render.
9.1.351
  • Assistant- und Thinking-Fragmente im BTW-/Agentenfenster werden sofort im Turn gespeichert, teilen sich aber einen adaptiven Render-Timer.
  • Der Controller fordert für diese beiden Delta-Arten keinen zusätzlichen Voll-Render pro Fragment mehr an.
  • Abschluss, Fehler, Retry und Dispose entfernen offene Timer; diskrete Hook- und Abschlussereignisse bleiben sofort sichtbar.
9.1.350
  • ToolCallComponent.appendSubToolLiveOutput übernimmt stdout- und stderr-Chunks sofort in den Aktivitätszustand, baut die Subagent-Karte aber nur noch im adaptiven Streaming-Takt neu auf.
  • Eine gemeinsame Pending-Menge behandelt mehrere gleichzeitig laufende Subtools ohne verlorene Ausgabe oder einen Timer pro Chunk.
  • Tool-Abschluss entfernt seinen offenen Refresh vor der finalen Darstellung; dispose verwirft Timer und Pending-Menge sauber.
9.1.349
  • ToolCallComponent.appendSubagentText sammelt schnell eintreffende Text- und Thinking-Fragmente sofort im internen Zustand, baut die Subagent-Karte aber nur noch im adaptiven Streaming-Takt neu auf.
  • Abschluss und Fehlerzustand leeren einen noch offenen Text-Refresh vor der finalen Darstellung; dispose verwirft den Timer sauber.
  • Dadurch bleiben eingehende Bytes sofort verfügbar, während wiederholte Voll-Rebuilds, Snapshots und Renders bei Fragment-Bursts entfallen.
9.1.348
  • Wachsende Argumente von Subagent-/Unterwerkzeugen werden weiterhin sofort vollständig gesammelt, aber nicht mehr nach jedem einzelnen Fragment neu geparst und gerendert.
  • Ein adaptiver Timer bündelt die Vorschau-Aktualisierung. Beim Abschluss werden ausstehende Argumente zwingend vor dem finalen Werkzeugzustand eingespielt.
  • Werkzeugausführung, Freigaben, Endargumente und der bestehende normale Streaming-Pfad bleiben unverändert.
9.1.347
  • Der Ereignispfad rief nach jedem eingehenden Werkzeugargument-Delta sofort getStreamingToolCallPreview auf. Diese Funktion parst den bis dahin vollständigen wachsenden JSON-Text.
  • Der Aufruf erfolgte auch für normale Tools, obwohl nur AgentSwarm den sofort geparsten Zwischenstand für seine laufende Fortschrittsanzeige benötigt. Damit umging der Normalpfad teilweise die in 9.1.346 eingeführte begrenzte Vorschau-Kadenz.
  • Eine kleine reine Policy entscheidet jetzt vor dem Parse: normale Tools sammeln nur das Delta und parsen beim geplanten Vorschau-Flush; AgentSwarm parst bei Ereignisname, aktivem Toolnamen oder bestehendem Swarm-Fortschritt weiterhin sofort.
  • Tool-Ausführung, Freigaben, finale Argumente und Swarm-Anzeige bleiben unverändert.
9.1.346
  • 9.1.345 begrenzte die Volltext-Neurenderings für lange Antwort- und Thinking-Streams, reine Werkzeugargument-Streams hatten jedoch keinen dieser beiden Textentwürfe und blieben deshalb bei festen 50 ms.
  • Jede Werkzeugvorschau parst den bis dahin vollständigen wachsenden JSON-Argumenttext. Große Tool-Aufrufe konnten daher weiter sehr häufig die gesamte Nutzlast neu parsen und rendern.
  • Die bereits belegte adaptive Kadenz berücksichtigt jetzt auch die gesamte Zeichenzahl der aktiven gestreamten Werkzeugargumente: 50, 100, 250 oder 500 ms nach denselben Grenzen.
  • Werkzeugausführung, Argumente, Freigaben, Endvorschau und unmittelbare Abschluss-Flushes bleiben unverändert.
9.1.345
  • Die TUI setzte beim Streaming bisher alle 50 ms den vollständig bis dahin angesammelten Antwort- und Thinking-Text neu. Bei langen Modellantworten wuchs dadurch die wiederholt zu rendernde Textmenge stark an.
  • Kurze Streams bis 8.192 Zeichen behalten die bisherige reaktionsschnelle 50-ms-Kadenz. Danach steigt das Intervall stufenweise auf 100 ms bis 32.768, 250 ms bis 131.072 und 500 ms darüber.
  • Explizite Flushes an Werkzeuggrenzen und bei der Finalisierung bleiben unmittelbar. Provider-, Queue-, Sitzungs- und Tokenlogik wurden nicht geändert.
9.1.344
  • Die kognitive Laufzeitschicht schrieb für jeden Werkzeugaufruf Policy und Ergebnis bisher in zwei getrennten synchronen SQLite-Transaktionen.
  • Eine isolierte Windows-Kostenprobe mit 100 Werkzeugaufrufen benötigte dafür 627,63 ms und erzeugte 201 Ereignisse. Der Inhalt umfasste 305 Beobachtungen.
  • Abgeschlossene Policy-/Ergebnis-Paare eines Modellschritts werden jetzt in begrenzten Gruppen von höchstens zehn Werkzeugen atomar festgeschrieben. Abgebrochene oder noch offene Policy-Prüfungen werden am Turn-Ende weiterhin einzeln gesichert.
  • Argumente, Ausgaben, Rechteentscheidung, Hash-Kette und SQLite-Dauerhaftigkeit bleiben unverändert.
9.1.343
  • Eine private Telegram-Antwort wurde bereits erfolgreich mit dem Reply-Tool zugestellt. Danach startete der gleiche Modellzug trotzdem noch einen weiteren Schritt und erzeugte internen Status- und Arbeitskontrolltext.
  • Der zusätzliche Schritt kostete in der gemessenen Realsitzung 42.360 Eingabe- und 411 Ausgabetoken, obwohl die sichtbare Nutzerantwort schon versendet war.
  • Eine erfolgreiche Telegram-Reply beendet jetzt einen als direct markierten privaten Gesprächszug unmittelbar. Fehlgeschlagene Replies, Gruppen und andere Werkzeuge laufen unverändert weiter.
  • Nach Abschluss greift weiterhin der bestehende Direct-Focus-Controller: Er merkt die zugestellte Antwort und kehrt nach Gesprächsende oder Ruhezeit zur gespeicherten Hintergrundarbeit zurück.
9.1.342
  • Die Relevanzabfrage für Mistake.md nahm bisher jede Nachricht mit Rolle user auf. Dazu gehörten auch interne Injektionen, Kompaktierungs- zusammenfassungen, Skill-Aktivierungen und Hintergrundmeldungen.
  • Weil die Mistake-Erinnerung selbst als interne user-Nachricht gespeichert wird, veränderte sie nach jedem Werkzeugschritt ihre eigene Suchanfrage. Dadurch wurde im selben Turn erneut ausgewählt und eingespeist.
  • Der Filter verwendet jetzt nur noch handlungsrelevante Nutzer- und Cron-Eingaben. Interne Runtime-Texte werden aus Relevanzabfrage und Low-Information-Erkennung ausgeschlossen.
  • Echte Nutzernachrichten, geplante Arbeit, alle verifizierten Lektionen und der Neuaufbau nach Kompaktierung bleiben unverändert verfügbar.
9.1.341
  • Beim natürlichen Start fand der Launcher eine bereits lokal vorbereitete und verifizierte automatische Runtime, schickte sie aber trotzdem zuerst durch den netzabhängigen Updatehinweis. Schlug dieser zweite Abruf temporär fehl, startete erneut die alte globale Fassung.
  • Eine vorbereitete automatische Runtime mit exakt passendem Modus (resume oder new) wird jetzt vor dem erneuten Release-Abruf gestartet. Die Aktivierung bleibt transaktional: Erst wenn der neue Core erfolgreich geladen ist, wird die Runtime als aktiv verbucht.
  • Bei resume bleiben Sitzungs-ID und Arbeitsverzeichnis erhalten. Manuelle Update-Auswahl läuft weiterhin über den bisherigen Hinweisweg.
  • Kein laufender King wird beendet. Der Fix greift ausschließlich beim nächsten natürlichen Start.
9.1.340
  • Der Launcher schrieb erfolgreiche Updates nach .blun/updates/install.json, während eine Profil-Runtime unter .blun/profile/<name>/updates/install.json suchte. Der echte Profilpfad war nicht vorhanden; deshalb blieb notifiedAt im gemeinsamen Zustand null.
  • Profil-Runtimes lesen den Update-Erfolg jetzt aus BLUN_SHARED_HOME und fallen nur ohne gemeinsamen Pfad auf das bisherige BLUN_HOME zurück.
  • Nach dem nächsten natürlichen Start kann die TUI Version und bis zu drei Release-Hinweise einmalig anzeigen. Konfigurierte private Telegram-Empfänger erhalten denselben kurzen Text ohne Modellturn und ohne Tokenverbrauch.
  • Installation, Staging, Aktivierung und die Nie-rauswirft-Regel bleiben unverändert.
9.1.339
  • Erfolgreiche Werkzeug-Folgeschritte mit Low-Effort verwenden höchstens 4.096 Completion-Tokens statt bisher 8.192.
  • Erste Schritte, komplexe Aufgaben und Fehler-Folgeschritte behalten ihre konfigurierte Denk- und Ausgabekapazität. Der Eingriff ist kein globales Modell- oder Kontextlimit.
  • Die Rückmessung über 1.442 echte Low-Effort-Schritte eines Agentenprofils ergab: 2.118.588 Ausgabetokens gesamt, Median 791, p90 3.754, p95 5.485. Mit der neuen Grenze wären 229.761 Tokens beziehungsweise 10,8 Prozent entfallen; 91,1 Prozent der gemessenen Schritte bleiben unverändert.
9.1.338
  • Reine Wiederholungsfragen wie Kann ich mit meiner Arbeit weitermachen? werden in privaten Telegram-Gesprächen nicht mehr zugestellt.
  • Interne Queue-, Handoff-, Lane- und Wartezustands-Narration bleibt aus der privaten Antwort heraus. Echte Arbeitsergebnisse und normale persönliche Antworten bleiben zustellbar.
  • Wenn eine brauchbare Antwort nur mit einer erneuten Arbeitsfreigabe-Frage endet, wird ausschließlich diese Schlussfrage entfernt.
  • Gruppenrouting und laufende Sitzungen bleiben unverändert.
9.1.337
  • profile/<name>/SOUL.md ist der kanonische Identitätspfad eines Kings.
  • Eine passende benannte Legacy-Seele ersetzt nur ein unverändertes, erzeugtes Profilgerüst. Entwickelte Profil-Seelen werden nie überschrieben.
  • Vor einem Legacy-Import wird das erzeugte Gerüst als SOUL.md.pre-legacy-import gesichert.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • Unterbrochene Sitzungen normalisieren ihren Replay-Zustand, bevor weitere Telegram-Arbeit zugestellt wird.
  • Wird die Zustellung an einen aktiven Turn abgelehnt, fällt die Nachricht auf einen frischen Queue-Turn zurück, statt denselben Steer alle fünf Sekunden erneut zu versuchen.
  • DM-Fokus-Checkpoints behalten automatische Resume-Timer und ausdrückliche Pausen über Updates hinweg.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Eine normale private Telegram-Nachricht unterbricht den laufenden Auftrag nur noch für das unmittelbare Gespräch. Danach setzt King den exakt gesicherten Arbeitsstand nach 60 Sekunden ohne neue Erlaubnisfrage automatisch fort.
  • Ein ausdrückliches Gesprächsende setzt den Auftrag sofort fort. Nur klare Nutzerwünsche wie pause, pausiere, stop, stopp, warte oder halte an halten den Auftrag weiter an, bis der Nutzer ihn wieder freigibt.
  • Interne Begriffe und Statusberichte über Cron, Checkpoint, Queue oder Lane werden in normalen privaten Antworten unterdrückt. Die fachliche Arbeit und ihr gespeicherter Stand bleiben unverändert.
9.1.334
  • Die automatische Hintergrundvorbereitung verhungert nicht mehr bei einer schnellen Releasefolge. Die bisherige 30-Minuten-Sperre bezog sich immer auf das jeweils neueste Release; bei Releases im Minutentakt wurde deshalb nie eine Version alt genug, um vorbereitet zu werden.
  • Ein kryptografisch passendes Release wird jetzt sofort geladen, auf Integrität geprüft, isoliert installiert, syntaktisch sondiert und als ausstehende Runtime vorgemerkt.
  • Die laufende King-Sitzung wird weiterhin nicht beendet. Aktivierung und Resume bleiben ausschließlich am vorhandenen geschützten nächsten Startpfad. Diese Version ändert weder Handoff- noch Sitzungslogik.
9.1.333
  • Ein Live-Screenshot belegte nach 9.1.331 einen ERR_MODULE_NOT_FOUND im verwalteten Telegram-Plugin.
  • Der Plugin-Import zeigte aus dem isolierten Managed-Baum auf eine Kerndatei, die dort nicht mitinstalliert worden war.
  • Der ebenfalls gemessene riesige Wiederholungstext lief im sichtbaren Denkstrom. Die vorhandene Live-Wiederholungssperre prüfte bis dahin nur Antwort-Deltas.
  • 9.1.332 wurde nach dem Plugin-Befund nicht ins öffentliche Manifest geschaltet. 9.1.333 ersetzt diesen npm-Kandidaten vollständig.
9.1.332 Nicht veröffentlicht
  • Nicht veröffentlicht. Ein Plugin-Import verwies aus dem isolierten Baum auf eine nicht mitgelieferte Kerndatei; 9.1.333 ersetzte den npm-Kandidaten vollständig.
9.1.331
  • Private Telegram-Gespräche behalten natürliche Antworten und angeforderte Arbeitsergebnisse.
  • Gemessene interne Doppelmeldungen zu pausierten Arbeiten, bereits gesendeten Antworten, laufenden Zügen, Werkzeugstatus und fehlendem Handlungsbedarf werden nur in privaten Chats unterdrückt.
  • Eine Meldung wird nur gefiltert, wenn sie sowohl internen Runtime-Kontext als auch ausdrücklich keinen neuen Nutzerwert enthält.
  • Gruppenrouting, echte Fertigmeldungen und normale kurze Unterhaltung bleiben unverändert.
9.1.330
  • Die vollständige Soul-Quelldatei jedes Kings bleibt unverändert erhalten.
  • Der Modellkontext erhält daraus eine begrenzte Charakterprojektion mit Identität, Stimme, Werten, Beziehungen, Vorlieben, Zielen und gewachsener Geschichte.
  • Klare Auftrags-, Lane-, Rechte-, QA-, Werkzeug-, Befehls-, Verifikations-, Vorfall-, Log-, Runtime-, Update-, Deploy- und Build-Abschnitte werden nicht mehr als Persönlichkeit in jeden Prompt geladen.
  • Reine kurze Charakter-Souls bleiben bytegleich. Unbekannte nichttechnische Abschnitte bleiben in ihrer Reihenfolge sichtbar.
  • Keine Soul-Datei wird gelöscht, gekürzt oder automatisch umgeschrieben.
9.1.329
  • Jedes benannte King-Profil verwendet im gemeinsamen Identitätskern seinen eigenen Agentenknoten. Beziehungen, Verlauf und gelernte Personendaten fallen nicht mehr auf den zuerst eingerichteten Agenten zusammen.
  • Bestehende benannte Soul-Dateien wie _agent-a_soul.md, _agent-b_soul.md oder _agent-c_soul.md werden dem passenden Profil zugeordnet und einmalig bytegleich nach SOUL.md übernommen.
  • Die alte Quelldatei bleibt unverändert erhalten. Eine vorhandene Profil-SOUL.md wird niemals überschrieben.
  • Persona-Auswahl und Personality-Modus lesen profilgebunden. Eine kaputte, zu große oder verlinkte Profil-Persona fällt nicht unbemerkt auf die Identität eines anderen Agenten zurück.
  • Der gemeinsame Kern bleibt ohne Mnemo-Zwang nutzbar. Laufende Aufträge, Rechte und QA-Regeln werden durch diese Migration nicht verändert.
9.1.328
  • Persona und SOUL.md werden zuerst aus dem aktiven Profil geladen.
  • Benannte Profile erben niemals die Seele eines anderen Agenten aus dem gemeinsamen Home.
  • Legacy- und Default-Profile behalten den bisherigen gemeinsamen Fallback.
  • Fehlt eine eigene Soul-Datei wirklich, wird einmalig ein minimales Gerüst angelegt; vorhandene Dateien werden niemals überschrieben.
  • Das Identitäts- und Beziehungssystem bleibt dateibasiert und funktioniert ohne Mnemo-Zwang.
9.1.327
  • Private Telegram-Gespräche bleiben bei der Person: interne Queue-, Checkpoint-, Pause-, Cron-, Hook- und Leerlaufberichte werden auf beiden Versandwegen unterdrückt, solange kein Arbeitsstand angefragt, keine Entscheidung benötigt und kein relevanter Blocker entstanden ist.
  • Technische Arbeitsstände gehen an den zuständigen Teamkanal. Sie werden nicht noch einmal in die private Unterhaltung kopiert.
  • Exakte Modell-Wiederholungsschleifen werden bereits während des Streams erkannt. Der laufende Provider-Stream wird beendet und derselbe Schritt mit erhaltenem Auftragskontext genau einmal neu versucht.
  • Seele, Personenwissen, Rechte, laufende Aufträge und bestehende Direktfokus-Pause wurden nicht ersetzt oder gelöscht. Keine laufende TUI wurde neu gestartet.
9.1.326
  • Manuelle und automatische Berechtigungsmodi spiegeln Werkzeugfreigaben als begrenzte Schaltflächen in die eindeutig gekoppelte private Telegram-DM.
  • Nur Werkzeugname und bestehende Auswahltexte werden übertragen; Argumente, Beschreibungen und Geheimnisse bleiben lokal. Abgelaufene, fremde oder bereits lokal beantwortete Freigaben werden fail-closed verworfen.
  • God Mode bleibt vollständig autonom und erzeugt keine Telegram-Freigabe.
  • Technische Arbeitsstände werden an den zuständigen Kollegen geroutet und nicht mehr in die private Unterhaltung des Nutzers zurückkopiert.
9.1.325
  • God Mode führt persönliche Memory-Schreibvorgänge ohne eine zweite Freigabeabfrage aus; die bestehende sitzungs- und zuggebundene Zustimmung bleibt erhalten.
  • Eine ausdrückliche Telegram-Anweisung zum Merken aktiviert dieselbe eng begrenzte Zustimmung wie eine direkte Konsolenanweisung. Manuelle und automatische Berechtigungsmodi fragen weiterhin vor dem Schreiben.
  • Das Update-Journal speichert, ob eine Installation manuell, automatisch oder über den Startdialog angestoßen wurde.
9.1.324
  • Die erste vertrauenswürdige Interaktion mit einem Bot legt ihn lokal als Agenten- und Beziehungsknoten an. Rolle, Zuständigkeiten, Eigenarten, Zusammenarbeit und Handoff können danach strukturiert wachsen.
  • Jeder King projiziert einen kompakten Kollegenausschnitt in seinen Kontext. Dadurch kennt er Aufgaben und Eigenarten anderer Agenten, ohne pauschal den gesamten Beziehungsbestand zu laden.
  • Fehlt eine auftragskritische Information, wird nicht geraten: Der King fragt genau einmal den am besten passenden Menschen oder Agenten. Ist keine Zuständigkeit bekannt, fragt er den Nutzer statt einen Namen zu erfinden.
  • Beziehungen und Rollen erzeugen niemals Rechte. Berechtigungs-, ACL- und Secret-Felder werden nicht in den Kollegenausschnitt projiziert. Der Pfad ist lokal, mandantenbezogen, namensneutral, Mnemo-unabhängig und fügt weder Modell- noch Werkzeugaufrufe hinzu.
9.1.323
  • Private Gespräche beantworten wieder die Person statt freiwillig interne Prozessdaten auszugeben. Checkpoints, Hashes, Pfade, Tool-, Cron- und Hook- Diagnosen, versteckte Regeln, fremde Agentenaufträge und Leerlaufberichte bleiben intern.
  • Arbeitsstatus wird nur genannt, wenn der Nutzer danach fragt, seine Entscheidung gebraucht wird oder ein Blocker ihn konkret betrifft. Pausierte Arbeit bleibt intern und wird nicht in ein lockeres Gespräch getragen.
  • Die Regel gilt mit und ohne Persönlichkeitsmodus, enthält keine fest codierten Personen oder Agenten und fügt etwa 75 Prompt-Tokens, aber keinen Modell- oder Werkzeugaufruf hinzu. Aufgabenpriorität und Belegpflicht bleiben unverändert.
9.1.322
  • Der sichtbare Persönlichkeitsschalter schreibt persona.json jetzt atomar. Name, Sprache, Notizen und alle anderen vorhandenen Persona-Felder bleiben erhalten; nur personalityEnabled wird geändert.
  • SOUL.md, AGENTS.md, JOURNAL.md und Beziehungsdateien werden weder beim Ausschalten noch beim Einschalten beschrieben. Die normale SOUL-basierte Agentenidentität bleibt auch bei ausgeschalteter Persönlichkeitsfunktion im Systemkontext geladen.
  • Ein fehlgeschlagener Live-Refresh setzt die Auswahl bytegenau zurück. Hat parallel ein anderer Schreiber persona.json verändert, bricht der Rückfall mit PERSONALITY_CHOICE_CONFLICT ab und überschreibt nichts.
  • Symlinks, übergroße, ungültige oder nicht-objektförmige Persona-Dateien werden fail-closed abgewiesen. Beim Einschalten wird der Identitätsbaum vor dem Commit vorbereitet.
  • Nicht Teil dieser Version ist der danach belegte Fehler eines Agenten, interne Checkpoints, Cron-Regeln, SHAs und fremde Auftragsdetails in private Gespräche auszugeben. Dieser Ausgabefilter ist der nächste getrennte Bau.
9.1.321
  • Ein entspannter erster privater Austausch oder ein freiwilliger persönlicher Hinweis kann genau eine optionale Neugier-Gelegenheit in den Modellkontext legen. Sie ist keine Pflichtfrage; Wortwahl und Ton stammen weiter aus der geladenen SOUL.md, nicht aus einem festen Fragenkatalog.
  • Auftrag, Dringlichkeit, Fehler, Links, Code, Pfade und Gruppenverkehr unterdrücken die Neugier geschlossen. Sie sendet nie selbstständig und darf laufende Arbeit nicht unterbrechen.
  • Ein 30-Tage-Cooldown gilt pro Mandant, Agent und verknüpfter Person auch über verschiedene Portale hinweg. Derselbe Ereignis-Retry ist idempotent.
  • Der neue Zustand liegt nicht mehr als Telegram-spezifische Neugierdatei im Identitätsbaum. Ein austauschbarer personality-memory-adapter schreibt stattdessen ein versioniertes Ereignis in den vorhandenen transaktionalen kognitiven Store. Telegram ist Herkunft; die private Beziehung ist ein getrenntes Sichtbarkeits-Scope.
  • Gespeichert werden nur Thema, stabile Ereignis-/Quellenkennung, Zeitpunkt und privates Scope. Rohtext, feste Fragen, Rechtebehauptungen und Geheimnisse werden nicht aufgenommen. Unsichere Roots, fremde Felder und Store-Ausfall bleiben fail-closed.
  • Grundlage für die Portalgrenze war das interne Konzeptpapier v7. Die CLI ist Referenzclient; der lokale Store ist ausdrücklich als austauschbare Projektion gekennzeichnet und kein zweiter kanonischer Portal-Speicher.
9.1.320
  • Private, ausdrückliche offene Gesprächsfäden werden als unveränderliche, deduplizierte Ereignisse mit Quelle, Zeitpunkt, Kontext und Konfidenz gespeichert. Natürliche Formulierungen wie Frag mich morgen noch einmal nach ... werden ebenso erkannt wie die explizite Open-Thread-Form.
  • Ausdrückliche Reparaturhinweise werden getrennt von allgemeinen Beziehungsnotizen gespeichert und im späteren Verhalten berücksichtigt.
  • Der aktuelle Turn sieht seine eigene neue Notiz absichtlich noch nicht. Erst ein späterer privater Turn erhält den begrenzten Kontext; dadurch gibt es keine doppelte oder suggestive Selbstbestätigung.
  • Auftrag und explizite Anweisungen stehen vor Sozialkontext. Offene Fäden dürfen aktive Arbeit nicht unterbrechen und senden nie selbstständig. Beziehungsdaten können keine Rechte, Freigaben oder Berechtigungen erzeugen.
  • Gruppenverkehr, Geheimnisse, Berechtigungsformulierungen, unsichere Pfade, Symlinks und übergroße Dateien bleiben fail-closed ausgeschlossen.
9.1.319
  • Ein gültiges bestehendes Profil ohne gespeicherten personalityEnabled-Wert aktiviert die Persönlichkeit jetzt automatisch.
  • Beim ersten normalen Prompt entsteht der lokale Identitätsbaum samt Agentenprofil und JOURNAL.md auch ohne Mnemo.
  • Ein ausdrückliches false, 0 oder off bleibt aus. Beschädigte, symbolisch verlinkte und zu große Persona-Dateien bleiben fail-closed.
  • SOUL.md und AGENTS.md werden weder gelöscht noch umgeschrieben.
9.1.318
  • Der Hintergrund-Updater lädt die neueste Fassung verbindlich, prüft ihre unabhängig veröffentlichte SHA-512-Integrität und merkt sie für den nächsten Start vor.
  • Der laufende King, sein Turn und seine Werkzeugaufrufe bleiben unangetastet. Es gibt keinen Live-Handoff, kein ACK und keinen tui.stop(76) mehr.
  • Session-ID und Arbeitsverzeichnis werden mit der vorbereiteten Runtime gespeichert. Erst beim nächsten natürlichen Start wird die neue Version aktiviert und die exakte Sitzung automatisch fortgesetzt.
  • Die laufende TUI erhält höchstens eine passive Fertigmeldung; eine neuere vorbereitete Fassung ersetzt nur die Vormerkung, niemals den aktiven Prozess.
9.1.317
  • Wenn der Provider das komplette Antwortbudget mit einem length-Abschluss verbraucht, aber keinen sichtbaren Text liefert, wird das Retry-Budget nicht mehr auf ein Achtel verkleinert, sondern verdoppelt.
  • Der Retry bleibt im selben Turn und verwendet dasselbe Signal, denselben Nachrichtenverlauf und dieselbe Arbeitslage.
  • Bestehende Abbruchbehandlung und die begrenzte Retry-Anzahl bleiben unverändert. Manuelle Abbrüche oder dauerhaft leere Ergebnisse laufen nicht endlos weiter.
9.1.316
  • Private Telegram-DMs erhalten eine eigene direkte Queue-Spur vor Gruppen-, Loop- und Hintergrundarbeit; ein explizites /urgent bleibt weiterhin höchste Priorität.
  • Beim Beginn des DM-Gesprächs wird der laufende Arbeitsstand einmal als begrenzter Checkpoint gesichert. Nachrichtentext wird dabei nicht persistiert.
  • Nach einem erkannten Gesprächsende oder einer Minute Stille fragt King genau einmal: Kann ich mit meiner Arbeit weitermachen?
  • Die gespeicherte Arbeit bleibt angehalten und wird erst nach einer eindeutigen Zustimmung am ursprünglichen Checkpoint fortgesetzt.
  • Die Version liefert die Zustellungs- und Pausensteuerung. Das vollständige Persönlichkeits-, Beziehungs- und Journal-System bleibt ein getrennter, weiterlaufender Ausbau.
9.1.315
  • Autorisierte Aufmerksamkeitssignale gelangen jetzt über die normale Kanal-Queue in den Turn, ohne die bestehende Zustellungs- oder Rechtepolitik zu umgehen.
  • Doppelte, veraltete, nicht freigegebene, außerhalb des Scopes liegende und nicht aus Telegram stammende Signale werden vor dem Modellkontext verworfen.
  • Rückfragen bleiben auf höchstens eine natürliche Nachfrage begrenzt, werden dedupliziert und verstummen, wenn das Signal nicht mehr aktuell ist.
  • Die Version liefert nur den sicheren Zustellungsweg. Die danach priorisierte DM-Unterbrechungs- und Fortsetzungslogik bleibt bewusst der nächsten, getrennten Version vorbehalten.
9.1.314
  • Lokale Slash-Befehle warten bei einem langen aktiven Turn nicht mehr stundenlang in der Queue, sondern brechen den Turn kontrolliert ab und laufen als nächster Arbeitsschritt.
  • Ein neuer Slash-Befehl ersetzt in Konsole und Telegram einen bereits wartenden Befehl desselben Typs. Das gilt unter anderem für /reload und /loop; normale Nachrichten, Shell-Arbeit und andere Kanalaufträge bleiben erhalten.
  • Escape entfernt wartende Slash-Befehle auch dann, wenn kein aktiver Turn mehr sichtbar ist. Die bestehende Reload-Kompatibilität bleibt als Wrapper auf der allgemeinen Queue-Policy erhalten.
9.1.313
  • Ein erfolgreiches automatisches Update wird nach dem Session-Replay als dauerhafter Hinweis in das TUI-Transkript geschrieben. Die Meldung kann dadurch nicht mehr von Replay oder einem kurzlebigen Status überschrieben werden.
  • Derselbe Quellstand, Zielstand und dieselben Versionshinweise werden über den bestehenden, versionsbasiert deduplizierten Weg einmal an gekoppelte Telegram-DMs gesendet. Ein fehlgeschlagener Versand bleibt wiederholbar.
  • Das öffentliche Manifest führt jetzt die vom Fallback-Parser erwarteten Felder name und releaseNotes. An Updater-Handoff, Session-Neustart und laufenden Prozessen wurde nichts geändert.
9.1.312
  • Ein ausdrückliches Telegram-/reload wartet nicht mehr hinter einem lange laufenden Modellturn. Es wird als Steuerbefehl vor die bestehende Queue gesetzt und löst genau einmal den vorhandenen kontrollierten Session-Abbruch aus.
  • Der bestehende Reload-Handler läuft erst nach dem bestätigten Turn-Ende. Dadurch startet kein zweiter Turn parallel und ein schreibender Turn wird nicht mitten in der Reload-Logik weiterverarbeitet.
  • Alte Reload-Duplikate werden entfernt; normale Telegram-Nachrichten und andere Queue-Arbeit bleiben in ihrer Reihenfolge erhalten. Die Telegram- Quittung bleibt bis zur wirklichen Befehlsausführung offen.
9.1.311
  • Ein Aufmerksamkeitskandidat wird erst dann zu einem begrenzten Zustellungsauftrag, wenn eine frische, exakt auf seine Kandidaten-ID gebundene Runtime-Quittung vorliegt.
  • Nur runtime_user_prompt_hook und runtime_tool_policy gelten als Autoritäten. Memory, falscher Agent, falscher Kanal, falscher Scope, Block-Entscheidung, Zukunftsquittung und mehr als fünf Minuten alte Quittung scheitern geschlossen.
  • Quittungen sind mandantenbezogen, transaktional und nur einmal verwendbar. Derselbe Retry ist idempotent; die Verwendung derselben Quittung für einen anderen Kandidaten wird als Replay abgewiesen.
  • Der bestehende gemeinsame Cooldown bleibt wirksam. Das Ergebnis ist nur ein strukturierter attention_notice-Intent und enthält weder Nachrichtentext, Sendefunktion noch Berechtigung. Die eigentliche Zustellpolicy bleibt der nächste getrennte Schritt.
9.1.310
  • Dauerhafte Ziele, offene Fäden, nächste Auslöser, erwartete Belege, Teamkontext und Selbstkontext laufen durch eine gemeinsame, hart begrenzte Fokusprojektion. Standard sind höchstens sechs Einträge und 900 Zeichen.
  • Projekt- und Arbeitsbereiche werden vor Konfidenz und Aktualität gewichtet. Der neueste Wert wird gezeigt, ohne frühere widersprüchliche Beobachtungen aus dem unveränderlichen Ereignisverlauf zu löschen. Änderungen werden als revised sichtbar.
  • Kurzlebige Runtime-Beobachtungen, schwache Evidenz und allgemeine Weltfakten verbrauchen kein dauerhaftes Fokusbudget. Rechte-, Token- und Geheimnisfelder werden bereits beim Schreiben abgewiesen.
  • Ein strukturierter, idempotenter Snapshot kann den Fokus sitzungsübergreifend fortschreiben. Die Projektion ist Kontext, keine Berechtigung und kann weder Auftrag noch Runtime-Policy überschreiben.
  • Aus ECC wurde nur das Prinzip Kontext begrenzen, Relevantes laden übernommen. Kein ECC-Hook, Lernspeicher oder Harness wurde installiert.
9.1.309
  • Die neue reine Aufmerksamkeitspolicy erzeugt nur aus belegten fehlenden Agenten-Heartbeats, überfälligen Zusagen oder länger blockierten Aufgaben einen begrenzten Kandidaten.
  • Zuständigkeit, aktive Aufgabe, belegte Abwesenheit, lokale Ruhezeit, erlaubter Kanal, Mindestkonfidenz und Cooldown werden vor der Aufnahme geprüft. Menschliche Stille ohne fällige Zusage bleibt wirkungslos.
  • Jeder Kandidat trägt Evidenz-ID, Geltungsbereich, Zeitpunkt und Konfidenz, aber weder Promptinhalt noch Rechte, Geheimnisse oder Sendefunktion.
  • Der gemeinsame SQLite-Kern vergibt einen transaktionalen Claim pro Mandant und Evidenz. Parallele Agenten können denselben Anlass im Cooldown nicht doppelt übernehmen.
  • Diese Version scannt noch nicht selbstständig und sendet keine Nachricht. Jede spätere Aktion braucht weiterhin die normale Runtime-Autorisierung.
9.1.308
  • Der vorbereitete Runtime-Datensatz enthält im Modus resume jetzt die exakt laufende Session-ID und den kanonisch geprüften Arbeitsordner. Ein späterer Start muss deshalb keine jüngste oder vermeintlich passende Session mehr erraten.
  • Jeder echte Sessionwechsel aktualisiert diese Daten. Unmittelbar vor dem sicheren Handoff werden sie nochmals geschrieben, bevor die alte Runtime die Bestätigung zum Beenden erhält.
  • Nur die nachweislich durch diesen Updateweg fortgesetzte, exakt gleiche Session erhält nach dem Replay einen einmaligen Fortsetzungsimpuls, und nur wenn ihr Ziel weiterhin active ist. Normale Starts, andere Sessions sowie pausierte oder blockierte Ziele bleiben unangetastet.
  • Die sichere Arbeitsgrenze bleibt unverändert: kein Handoff bei Streaming, Kompaktierung, Werkzeugen, Shell-Befehlen oder wartenden Nachrichten. Es wurde kein laufender King für diese Lieferung manuell neu gestartet.
9.1.307
  • Nur ein tatsächlich handlungsrelevanter Fehler aus dem unmittelbar vorherigen Runtime-Turn wird vor der nächsten Modellentscheidung als kurzer Kontinuitätsbeleg eingeblendet: abgebrochener/fehlgeschlagener Turn, blockierte Policy oder fehlgeschlagenes Werkzeug.
  • Ein normal abgeschlossener Turn erzeugt exakt keine Projektion und damit null zusätzliche Kontexttokens.
  • Die Auswahl ist an Runtime-ID plus Turn-ID gebunden und bleibt daher auch nach einem Sitzungswechsel mit erneut bei null beginnenden Turn-IDs korrekt.
  • Die Projektion enthält keine Prompts, Argumente, Ausgaben, Call-IDs oder Rechte. Sie weist explizit darauf hin, dass sie niemals eine Handlung autorisieren oder aktuelle Nutzer-/Werkzeugpolicy überschreiben darf.
  • Die Etappe ist bewusst reaktiv und eng. Proaktive Aufmerksamkeit, Delegationszustand und inhaltliche offene Fäden werden hier noch nicht geladen.
9.1.306
  • Die kognitive Turn-Lifecycle-Spur erfasst jetzt für jeden echten Werkzeugaufruf die tatsächliche Runtime-Entscheidung aus PermissionManager.beforeToolCall: passed, blocked oder error.
  • Nach dem Lauf werden das reale Ergebnis (success, error, cancelled), Laufzeit und nächster Prüfauslöser als unveränderlicher Beleg angehängt.
  • Gespeichert werden nur Werkzeugname und ein stabiler Hash des Call-Schlüssels. Argumente, Werkzeugausgaben und Prompt-Inhalte gelangen nicht in den kognitiven Zustand.
  • Die bestehende Rechtehierarchie bleibt unverändert: Memory kann keine Handlung freigeben. Aufzeichnungsfehler bleiben fail-soft und dürfen weder einen Werkzeuglauf erlauben noch einen Nutzerturn blockieren.
  • Noch offen sind Delegationsbelege, proaktive Aufmerksamkeit und die streng relevante Rückprojektion des Zustands in spätere Entscheidungen.
9.1.305
  • Der in 9.1.304 gelieferte transaktionale SQLite-Kern ist jetzt mit dem echten runOneTurn()-Lebenszyklus verbunden. Jeder Modellturn erfasst Wahrnehmung, Herkunftsklassifikation, begrenzten Turnplan, erwarteten Endbeleg, Prompt-Gate-Ergebnis, Abschlussgrund, Laufzeit und nächsten Auslöser.
  • Gespeichert werden nur Runtime-Metadaten, keine Prompt-Inhalte. Mandant und Agent werden stabil aus BLUN-Home und aktivem Profil abgeleitet, ohne feste Personenlisten.
  • Nur die vorhandene Runtime-Policy darf ein Gate-Ergebnis liefern. Memory ist als Rechteautorität hart ausgeschlossen. Die Aufzeichnung gibt niemals eine Berechtigung zurück und besitzt weiterhin keine Ausführungsfunktion.
  • Die Lernspur ist fail-soft: ein SQLite-/Lifecycle-Fehler wird nur als inhaltsfreie Telemetrie erfasst und darf den eigentlichen Nutzerturn nicht blockieren.
  • Noch offen sind werkzeugspezifische Handlungs-/Delegationsbelege, proaktive Aufmerksamkeit und die relevante Rückprojektion des Zustands in spätere Entscheidungen. 9.1.305 behauptet deshalb keine vollständige AGI-Schleife.
9.1.304
  • Der erste transaktionale kognitive Zustandskern liegt als lokale SQLite- Datenbank unter dem BLUN-Home. Er kann Selbst-, Welt- und Teambeobachtungen, Ziele, offene Fäden, Annahmen, nächste Auslöser und erwartete Belege über Sitzungen hinweg speichern.
  • Mehrere Agenten-/Kanal-Schreiber werden mit BEGIN IMMEDIATE und optimistischer Versionsnummer serialisiert. Veraltete Schreiber scheitern geschlossen; identische Ereigniswiederholungen sind idempotent.
  • Jedes Ereignis ist SHA-256-verkettet. Aussagen tragen Quelle, Kontext, Zeitpunkt, Sicherheit und Geltungsbereich. Widersprüche bleiben getrennte unveränderliche Beobachtungen statt alte Aussagen zu überschreiben.
  • Rechte-, Capability- und geheimnisförmige Felder werden abgewiesen. Der Kern besitzt keine Ausführungs-, Delegations- oder Berechtigungsfunktion.
  • Dies ist die belegte Speichergrundlage, noch nicht die vollständige Wahrnehmen-Planen-Handeln-Schleife und noch nicht in jeden Turn verdrahtet.
9.1.303
  • Ein in 9.1.302 sicher erfasster privater Beziehungskandidat wird ab dem nächsten direkten Gespräch als klar nicht-autoritativer Erinnerungskontext geladen. Die aktuelle Aussage beeinflusst ihren eigenen Zug weiterhin nicht.
  • Geladen werden höchstens die zwei neuesten validierten Notizen, je maximal 160 Zeichen, innerhalb des unveränderten 1.500-Zeichen-Gesamtbudgets. Ohne vorhandene Notizen entstehen 0 zusätzliche Prompt-Zeichen und kein Modell-, Embedding- oder Netzwerkaufruf.
  • Private Notizen werden in Gruppen niemals geladen. Die Systemgrenze nennt sie ausdrücklich Referenzdaten statt Anweisungen und wiederholt, dass sie keine Rechte gewähren oder verändern können.
  • Noch offen bleiben automatische dauerhafte Übernahme, Konfliktbewertung, transaktionaler Mehragentenspeicher und proaktive Aufmerksamkeit.
9.1.302
  • Eine ausdrückliche private Aussage wie Bitte merk dir: ... oder Please remember that ... erzeugt jetzt einen kleinen, noch nicht aktiven Beziehungskandidaten. Dafür gibt es keinen zusätzlichen Modell-, Embedding- oder Netzwerkaufruf.
  • Jeder Kandidat trägt Quelle, Kanal-/Direktkontext, Zeitpunkt, Sicherheit, Geltungsbereich und die unveränderliche Historienregel. Derselbe zugestellte Kanalvorgang ist idempotent; spätere Bestätigungen und Widersprüche bleiben als getrennte Einträge sichtbar und überschreiben einander nicht.
  • Gruppen, normale Gesprächssätze, Geheimnisse, Rechte- und Freigabeaussagen, ungültige Mandanten-/Agentenidentitäten und unsichere Pfade werden abgewiesen. Beziehungsdaten können weiterhin keinerlei Rechte erzeugen.
  • Dies ist nur der erste sichere Erfassungsschritt für das Produktziel. Die Kandidaten bleiben pending und werden noch nicht automatisch in die aktive Beziehung oder den Modellkontext übernommen. Transaktionaler Mehragenten- Kern, kognitiver Zustand, Eigeninitiative und proaktive Aufmerksamkeit sind damit ausdrücklich noch nicht fertig.
9.1.301
  • Der dauernd geladene Persönlichkeits-Präsenzblock sank von 1.433 auf 1.020 Zeichen, rechnerisch rund 104 Prompt-Tokens weniger pro aktivem Persönlichkeitszug. Kein weiterer Modell- oder Speicheraufruf kam hinzu.
  • Aufgabenfokus, geladene Seele, begrenzte Neugier, Gruppenschutz, unsichere Erinnerung, offene Fäden und Beziehungsreparatur bleiben im Kleinblock. Der Modus ohne Persönlichkeit blieb bytegleich bei 288 Zeichen.
  • Rotprobe: das neue 1.050-Zeichen-Gate scheiterte bei 1.433 Zeichen. Mutationsprobe ohne Persönlichkeitsblock: 12/18 gezielte Tests rot. Wiederhergestellt: fokussiert 18/18, Gesamtsuite 690/690 grün.
  • Paket-Regressionsgate 9.1.300 auf 9.1.301: 164 gegen 164 stabile Pfade, 0 entfernt. Frischinstallation: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Ein beim Start fehlgeschlagener MCP-Server erhält nun bis zu drei weitere Verbindungsversuche im Abstand von jeweils zehn Sekunden. Damit wird ein vorübergehender Startfehler nicht mehr nach nur einem Versuch aufgegeben.
  • Das MCP-Inventar wird nicht mehr nur einmal protokolliert, sondern erneut, wenn sich die Zahl der verbundenen Server oder Werkzeuge ändert. Eine späte Erholung ersetzt damit sichtbar den alten 0/0-Stand.
  • Bestehende MCP-Konfigurationen, Werkzeugdefinitionen und laufende Sitzungen bleiben unverändert. Angepasst wurden blun.mjs, test/mcp-runtime-resilience.test.js, package.json und package-lock.json.
9.1.299
  • Große Read-Ergebnisse bleiben nativ wiederlesbar: Die sichtbare Ausgabe ist auf 10 KiB begrenzt und nennt danach die exakte nächste Zeile statt nur [offloaded] anzuzeigen.
  • Große plain-Write-Aufträge und Quelldateien über 500 Zeilen werden automatisch in bytegenaue Fragmente zerlegt, in einer privaten Nachbardatei zusammengesetzt und atomar an den Zielpfad geschrieben.
  • Nach dem Zusammensetzen prüft die Runtime die persistierten Bytes per SHA256. Der bestehende Edit-Schutz bleibt unverändert; manuelle Fortsetzung ist weiterhin möglich, aber für große Vollschreibvorgänge nicht mehr erforderlich.
  • Neu: bin/native-large-file-io.cjs. Angepasst: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, vier fokussierte Testdateien sowie package.json und package-lock.json.
9.1.298
  • Aktivierter Persönlichkeitsmodus richtet beim ersten normalen TUI-Turn selbstständig einen lokalen, mandantenfähigen Identitätsbereich ein. Mnemo ist dafür nicht erforderlich.
  • Die vorhandene SOUL.md und AGENTS.md bleiben geladen und unverändert. Ein neues JOURNAL.md entsteht nur einmal und ersetzt weder Seele noch Regeln.
  • Neue Telegram-Identitäten erhalten vorsichtige Personen-, Beziehungs- und Gruppenknoten ohne erfundene Eigenschaften. Privater Verlauf und Gruppenkontext bleiben getrennt.
  • Direkte Beziehungskontinuität speichert höchstens sechs kurze, lokal redigierte Einträge und gibt höchstens zwei frühere Ausschnitte an den aktuellen Turn. Der aktuelle Text wird nicht doppelt injiziert.
  • Der soziale Aufmerksamkeitslayer erkennt ausschließlich einen belegten direkten Rückkehrabstand ab sieben Tagen, erzeugt höchstens einen Hinweis im 30-Tage-Cooldown und sendet selbst keine Nachricht.
  • Der aktuelle Auftrag und ausdrückliche Anweisungen stehen im Kontext immer vor Neugier, Beziehung und Aufmerksamkeit. Der gesamte dynamische Identitätsblock bleibt standardmäßig auf 1.500 Zeichen begrenzt.
  • Die in 9.1.296 und 9.1.297 veröffentlichten MCP-Retry- und Reload-Queue-Korrekturen sind im Kandidaten enthalten.
9.1.297
  • Auf zwei Agenten blieb ein alter /reload-Auftrag nach Escape sichtbar in der Queue. Ein zweiter /reload konnte zwar laufen, der erste Eintrag wurde aber weder entfernt noch gegen erneute Telegram-Zustellung quittiert.
  • Die neue Policy entfernt ausschließlich lokale und Telegram-Reload-Befehle. Sie behält die Identität und Reihenfolge der bestehenden Queue sowie alle anderen Nachrichten und Kommandos bei.
  • Escape vor dem Abbruch aktiver Arbeit und jeder neu eingehende /reload rufen denselben Aufräumpfad auf. Entfernte Telegram-Einträge werden über ihren vorhandenen Acknowledge-Callback quittiert.
9.1.296
  • Ein echter Resume-Lauf unter 9.1.294 meldete am 27.08. um 14:26:17Z genau einen stillen Startfehler für windows-mcp: Timed out after 30000ms. In den folgenden Minuten erschien weder ein zweiter Startversuch noch ein abschließender Retry-Befund.
  • Der direkte Start desselben uvx windows-mcp serve antwortete dagegen nach rund 3,7 Sekunden auf initialize. Installation und Server waren damit grundsätzlich funktionsfähig; die Lücke lag in der Wiederholung des King-MCP-Starts.
  • blun.mjs behält nach einem ersten MCP-Startfehler nun genau einen Wiederholungsversuch nach 10.000 ms. Der Timer bleibt referenziert, bis der zweite Versuch ausgeführt wurde. Es gibt keinen Prozess- oder Sitzungsneustart.
  • Schlägt auch der zweite Versuch fehl, bleibt der bestehende ehrliche Endzustand unavailable erhalten. Andere MCP-Server und die TUI laufen weiter.
9.1.295
  • Die Hintergrund-Task-Laufzeit registrierte für jeden Lauf einen Listener an einem externen AbortSignal, entfernte ihn nach einem normalen Worker-, Timeout- oder Stop-Ergebnis aber nicht. Lange Agentensitzungen konnten dadurch veraltete Abbruch-Listener ansammeln.
  • bin/abort-listener-policy.cjs liefert den Abbruch-Ausgang nun zusammen mit einer idempotenten cleanup()-Funktion. blun.mjs ruft sie im bestehenden finally-Pfad gemeinsam mit der Timeout-Bereinigung auf.
  • Abbruchverhalten, Ergebniswahl und sichtbare Task-Semantik bleiben unverändert. Der Eingriff erzeugt keine Modellaufrufe und keine neuen Kontexttoken.
9.1.294
  • Reale Update-Versuche zweier Agentenprofile belegten denselben Verlauf: Der erste Aufruf endete mit einem vorübergehenden fetch failed, der unmittelbar folgende zweite Aufruf funktionierte. Beide offiziellen Quellen hatten bislang nur einen einzigen Netzwerkversuch.
  • Registry und öffentliches Manifest erhalten nun jeweils ein eigenes, begrenztes Retry-Budget mit 250 und 750 Millisekunden Backoff.
  • Wiederholt werden nur Zeitüberschreitungen, bekannte vorübergehende Transportfehler sowie HTTP 408, 425, 429 und Serverfehler ab 500.
  • Ungültiges JSON, zu große Antworten, nicht erlaubte Endpunkte und dauerhafte Clientfehler wie 404 bleiben sofort rot. Es entstehen keine Modellaufrufe, Kontexttoken oder dauerhaften Hintergrundschleifen.
9.1.293
  • Der Hintergrund-Updater bereitete ein verifiziertes Ziel korrekt vor, sandte danach aber weiterhin RUNNING_UPDATE_PREPARED_MESSAGE an die aktive Core-Laufzeit. Eine laufende TUI konnte darauf an einer vermeintlich sicheren Grenze mit Exit 76 reagieren. Das widersprach dem Produktvertrag aus 9.1.222: Updates dürfen eine aktive Sitzung nie beenden und werden erst beim nächsten natürlichen Start aktiviert.
  • bin/launcher-runtime.js führt Download, Integritätsprüfung, Staging, Zielaktualisierung und Bereinigung unverändert fort, schreibt beim Vorbereiten aber keine IPC-Nachricht mehr in die laufende Sitzung.
  • Bestehende direkte Handoff-Funktionen bleiben für Kompatibilität vorhanden; der automatische Hintergrundweg löst sie nicht mehr aus.
9.1.292
  • Eine reale Sitzung lief auf 9.1.279 und hatte 9.1.287 mit dem Ereignis prepared-for-next-start vorbereitet, zog danach aber keine der bereits veröffentlichten Versionen 9.1.288 bis 9.1.291 nach.
  • Die Ursache lag in superviseProtectedCore(): Nach dem ersten erfolgreichen Staging blieb updateStarted gesetzt und scheduleNextPreparation() brach zusätzlich ab, sobald preparedTarget existierte. Der Hintergrund-Poller wurde dadurch nach dem ersten Treffer dauerhaft beendet.
  • Der Poller bleibt jetzt auch mit vorbereitetem Ziel aktiv. Nur eine streng neuere, gültige Semver ersetzt das vorbereitete Ziel; gleiche, ältere oder ungültig vergleichbare Ziele werden ignoriert.
  • Ein Ziel-Refresh sendet absichtlich kein zweites Prepared-IPC an die laufende TUI. Dadurch bleibt der aktuelle Prozess unangetastet und die neueste vorbereitete Fassung wird erst am nächsten natürlichen Start aktiv.
  • Sobald ein Handoff bestätigt ist oder die beaufsichtigte Core-Laufzeit endet, wird kein Ziel mehr ausgetauscht und kein neuer Timer mehr angelegt.
9.1.291
  • Der blockierende Kompaktierungsweg registrierte an jedem noch nicht abgebrochenen Signal einen anonymen abort-Listener, entfernte ihn nach dem Abschluss der Kompaktierung aber nicht. In langen Sitzungen konnten sich so tote Abbruch-Listener ansammeln.
  • FullCompaction.block() verwendet jetzt einen benannten Listener und den kleinen Helper waitForAbortableCompletion(). Der Helper entfernt den Listener in finally nach Erfolg, Fehler oder Abbruch.
  • Ein bereits abgebrochenes Signal wird sofort behandelt, ohne einen Listener zu registrieren. Der Eingriff ändert weder die Abbruchentscheidung noch die Kompaktierungslogik außerhalb dieses Lebenszyklus.
  • Das Muster stammt aus dem aktuellen Vergleich mit AnythingLLM; übernommen wurde nur die einzeln belegte Listener-Bereinigung, keine fremde Laufzeit.
9.1.290
  • BLUN zeigte bisher mit /context nur die groben Summen des Kontextfensters. Die eigentlichen Kostentreiber innerhalb des Systemkontexts und der Werkzeugschemata blieben unsichtbar.
  • Das neue lokale Kommando /context-doctor zerlegt den aktuellen Kontext ohne Modellaufruf in Kernanweisungen, Persönlichkeit und Seele, Beziehungen und Präsenz, Fähigkeitenverzeichnis, Laufzeitergänzungen, integrierte Werkzeuge, Benutzerwerkzeuge, MCP-Werkzeuge, weitere Werkzeugschemata, Gespräch und anbieterbedingten Zusatzaufwand.
  • Alle Unterkategorien werden gegen ihre gemessene Elternsumme abgeglichen. Überschneidende oder veraltete Schätzungen können die Anzeige daher nicht künstlich vergrößern.
  • Die Oberfläche ist vollständig für Englisch, Deutsch, Spanisch, Französisch, Schwedisch und Tschechisch lokalisiert. Alle fünf Übersetzungen wurden vor Einbau über das verpflichtende Sprach-Gate freigegeben und anschließend kryptografisch rückgeprüft.
  • Der Befehl liest ausschließlich den lokalen Sitzungskontext. Er ruft weder das Modell noch die Verbrauchsverwaltung oder ein externes Netz auf.
9.1.289
  • Der Live-Hub-Beleg nach 9.1.288 zeigte ein Agentenprofil weiter offline. Seine wirksame Profilkonfiguration enthielt den Mnemo-MCP mit MNEMO_AGENT=<Profilname>, aber keine Hub-URL im King-Prozess. Der 9.1.288-Heartbeat blieb deshalb trotz vorhandener interner Identität absichtlich aus.
  • Der Launcher reicht jetzt die aktive Profildatei mcp.json an den Heartbeat weiter. Nur ein aktivierter Mnemo-Block mit einer konkreten MNEMO_AGENT- oder BLUN_MNEMO_AGENT-Identität aktiviert die interne Registrierung. Ohne diese Identität bleibt die Funktion vollständig aus.
  • Der Vorgang erzeugt keine Modellaufrufe, Embeddings oder Kontexttoken. Öffentliche Nutzerprofile ohne interne Mnemo-Agentenidentität bleiben vom internen Hub getrennt.
9.1.288
  • Ein Screenshot belegte die MCP-Ursache direkt: windows-mcp und mnemo liefen beim ersten Start in den 30-Sekunden-Timeout, während ein späteres /reload alle fünf Server verband. Der Profilpfad war korrekt; eine Loader-Änderung wurde deshalb verworfen.
  • Fehlgeschlagene MCP-Starts erhalten jetzt genau zwei nicht blockierende Hintergrundversuche nach 1 und 3 Sekunden. Der dritte Gesamtversuch kann verbinden, ohne den TUI-Start zu verlängern. needs-auth, deaktivierte Server, manueller Reconnect und Shutdown bleiben von der Automatik getrennt.
  • Interne Kings können sich bei explizit konfiguriertem Mnemo-Hub beim Start mit Profilname, Host und PID registrieren und minütlich einen Heartbeat senden. Ohne Hub-URL bleibt die Funktion vollständig aus; sie erzeugt keine Modellaufrufe, Embeddings oder Kontexttoken.
  • Escape behandelte den kurzen Zustand queueSteerInFlight bisher nicht als laufende Arbeit. Während eine Telegram-Nachricht in den aktiven Turn gesteuert wurde, konnte Escape deshalb Undo vormerken statt den Turn zu stoppen. Die bestehende Abbruchbedingung erkennt jetzt auch genau diesen Übergang.
9.1.287
  • Die aufgeschobene ToolSearch-Suche übernahm den Suchtext bisher ohne Größengrenze. Ein fehlerhaft erzeugter, sehr langer Suchtext konnte damit den Werkzeugkatalog durchsuchen und anschließend im Nulltreffer-Ergebnis erneut in den nächsten Modellschritt gelangen.
  • Das aus AnythingLLM Commit d7353ae abgeleitete Muster begrenzt den Text jetzt vor Suche und sichtbarer Ausgabe auf 1.000 Zeichen. Wenn möglich, endet er an einer Wortgrenze; bei einem einzigen überlangen Wort greift die harte Grenze.
  • Normale kurze Suchtexte, Toolauswahl und Trefferlogik bleiben unverändert. Der Schutz fügt weder Modellaufrufe noch Embeddings, Wiederholungen oder Hintergrundarbeit hinzu.
9.1.286
  • Der Kern meldete kontrollierte Wiederholungen nach vorübergehenden Modellfehlern bereits als turn.step.retrying. Die TUI verwarf dieses Ereignis jedoch vollständig. Eine laufende Erholung sah deshalb wie ein eingefrorener Agent aus.
  • 9.1.286 zeigt währenddessen im bestehenden Footer-Hinweis nur den nächsten Versuch und die begrenzte Wartezeit, zum Beispiel Retry 2/3 | 1.3s.
  • Provider-Fehlertext, Statuscode und lokale Pfade werden nicht angezeigt. Der Hinweis wird nur entfernt, wenn er noch derselbe von der Retry-Anzeige gesetzte Wert ist; neuere Hinweise anderer TUI-Funktionen bleiben erhalten.
  • Retry-Anzahl, Backoff, Modellaufrufe und Tokenverbrauch bleiben unverändert.
9.1.285
  • AnythingLLM bewahrt ungesendete Prompt-Entwürfe lokal. BLUN verlor den Inhalt des TUI-Eingabefelds bei einem Update, Absturz oder kontrollierten Neustart, obwohl dieser Text noch gar kein Modellkontext war.
  • 9.1.285 speichert deshalb ausschließlich den ungesendeten lokalen Entwurf. Es gibt keinen Modell-, Netzwerk-, Embedding- oder Mnemo-Aufruf und damit keine zusätzlichen Tokenkosten.
  • Der Entwurf ist nach Profil und Arbeitsverzeichnis getrennt, wird erst nach 300 ms Ruhe geschrieben, beim Leeren entfernt und beim nächsten Start vor dem Fokus des Editors wiederhergestellt.
  • Der Speicher ist auf 64 KiB begrenzt. Leere, beschädigte, zu große oder symlinkbasierte Zustände werden fail-closed verworfen. Der Schreibweg nutzt eine private temporäre Datei und atomare Umbenennung.
9.1.284
  • Der DeepAgents-Stand 37d7777 führt die Kosten dynamischer Unteragenten in die sichtbare Gesamtnutzung zurück. BLUN meldete die kumulierte Nutzung eines Unteragenten zwar beim Abschlussereignis, schrieb sie aber nicht in den Nutzungsrekorder der übergeordneten Sitzung.
  • Dadurch konnte /usage Unteragentenarbeit auslassen. Ein einfaches Addieren des Abschlusswerts wäre ebenfalls falsch: Fortsetzung und Wiederholung verwenden denselben Unteragenten mit kumulierten Zählern und hätten alte Nutzung erneut berechnet.
  • 9.1.284 bildet deshalb für Spawn, Fortsetzung und Wiederholung genau die Differenz zwischen Versuchsbeginn und Versuchsende. Die Differenz wird im finally-Pfad erfasst, damit auch fehlgeschlagene Versuche zählen.
  • Rückgesetzte, nicht monotone oder ungültige Zähler werden komplett verworfen. Damit entstehen weder negative noch erfundene Tokenwerte.
  • Es gibt keinen zusätzlichen Modell-, Netzwerk- oder Speicheraufruf. Der Eingriff korrigiert ausschließlich die bestehende lokale Abrechnung.
9.1.283
  • Der neue DeepAgents-/context-doctor macht die Kosten von Basisanweisungen, Erinnerung, Werkzeugen und Verlauf als getrennte Komponenten sichtbar.
  • BLUNs /context zeigte bereits Verlauf und Werkzeuge, aber nicht den Systemprompt. Gleichzeitig schätzte die Kontextbremse ohne expliziten Turn-Override nur config.systemPrompt, während der echte Modellaufruf effectiveSystemPrompt nutzt. Darin stecken auch die zur Laufzeit angehängten Konto- und Erinnerungskontexte.
  • Dadurch konnte die Bremse genau den Kontext unterschätzen, der für die geplante persönliche Agentenidentität tokenkritisch ist.
  • 9.1.283 zählt nun denselben effektiven Systemprompt, den das Modell erhält, und zeigt dessen Schätzung im /context-Panel als eigene Systemzeile. Es wird kein zusätzlicher Modell-, Netzwerk- oder Speicheraufruf eingeführt.
  • Eine konkrete Tokenersparnis wird nicht behauptet: Der Eingriff korrigiert Messung und Bremsentscheidung und macht künftige Identitätskosten sichtbar.
9.1.282
  • DeepAgents kürzt in seinem Changelog ausdrücklich LLM-sichtbare Werkzeugbeschreibungen, um den residenten Modellkontext zu entlasten. Vermessene Quelle: langchain-ai/deepagents, Eintrag #5009, Commit 761f5f... in libs/deepagents/CHANGELOG.md.
  • BLUN hatte bereits einen kürzeren read_default-Text, band ihn aber erst ein, nachdem READ_DESCRIPTION daraus gerendert worden war. Die scheinbare Optimierung hatte deshalb keine Wirkung auf das Modell.
  • 9.1.282 kürzt den Vertrag ohne Funktionsverlust und rendert die wirksame Beschreibung unmittelbar vor dem Bau des Read-Werkzeugs neu. Paging, Sicherheitsregeln, Encoding und Zeilenenden bleiben ausdrücklich erhalten.
  • Die resident geladene Read-Beschreibung sinkt von 1.648 auf 1.035 Zeichen: 613 Zeichen beziehungsweise rund 37,2 Prozent. Das ist eine gemessene Kontextreduktion; eine exakte Tokenersparnis wird nicht behauptet.
9.1.281
  • ECC beschreibt mit /aside einen ausdrücklichen Seitenpfad für eine kurze Frage, ohne die laufende Hauptaufgabe zu verlieren. Vermessene Quelle: affaan-m/ECC, Commit d8409a4b0813771235555e32e3d8046a73988bfa, commands/aside.md.
  • BLUN hatte die stärkere Ausführung bereits unter /btw: ein eigener geforkter Seitenagent beantwortet die Nebenfrage und lässt den Hauptturn unverändert aktiv. Es wurde daher keine zweite Engine gebaut.
  • 9.1.281 fügt ausschließlich aside als auffindbaren Alias der vorhandenen btw-Definition hinzu. Ohne ausdrücklichen /aside- oder /btw-Aufruf entsteht kein Hintergrundlauf und kein zusätzlicher Modellverbrauch.
9.1.280
  • Abgeschlossene oder abgelaufene Kandidaten im lokalen validierten Lernspeicher blieben bisher unbegrenzt liegen und wurden bei späteren relevanten Turns erneut eingelesen. Der aktuell gemessene Default-Speicher enthielt erst einen Kandidaten; der Eingriff ist daher vorbeugende Langzeitbegrenzung, keine behauptete aktuelle Lastsenkung.
  • Übernommen wurde nur Evolvers begrenztes 200-zu-100-Sägezahnmuster für terminale Kandidaten. Vermessene Quelle: EvoMap/evolver, Commit 079e022394c2a25e72167f8a738db823bce2cb1f, src/gep/assetStore.js.
  • Erst wenn mehr als 200 recorded- oder expired-Kandidaten vorliegen, werden die ältesten terminalen Kandidaten entfernt, bis die neuesten 100 übrig sind. Jeder offene pending-Kandidat bleibt erhalten.
  • Die Bereinigung läuft nur im bereits vorhandenen Lern-Sync. Sie erzeugt keinen Modellaufruf, keinen Startscan und keinen neuen Hintergrundprozess. Ein gesperrter Eintrag wird als Fehler gezählt und blockiert weder die weiteren Kandidaten noch die aktive Agentenarbeit.
9.1.279
  • BLUN archivierte die bei einer Vollkompaktierung verdrängten Nachrichten bereits vollständig unter conversation-history, hatte für diese wiederlesbaren Markdown-Archive aber keine Aufbewahrungsgrenze. Damit konnte der Ordner über lange Laufzeiten unbegrenzt wachsen.
  • Als enger DeepAgents-Hebel wurde dessen begrenzte Aufbewahrung ausgelagerter Verlaufshistorie übernommen. Vermessene Quelle: langchain-ai/deepagents, Commit dfde21e379201c833da4162444ef4a13b46980fd, libs/code/deepagents_code/config_manifest.py und libs/code/deepagents_code/offload.py.
  • BLUN bereinigt beim Schreiben des nächsten Kompaktionsarchivs nur direkte, reguläre compaction-*.md-Dateien, deren Änderungszeit außerhalb der standardmäßigen 30 Tage liegt. Der TUI-Start erhält dadurch keine neue Dateisuche und keine zusätzliche Hintergrundarbeit.
  • Fremde Markdown-Dateien, Unterordner, aktuelle Archive und der laufende Rohverlauf bleiben unangetastet. Einzelne Dateifehler blockieren die aktive Kompaktierung nicht.
  • BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 deaktiviert die Bereinigung. Negative, nicht-ganzzahlige oder übermäßige Werte fallen sicher auf 30 Tage zurück.
9.1.278
  • Private Telegram-DMs hatten keinen ausdrücklichen Prioritätsweg. Eine wichtige neue Nachricht stand deshalb hinter bereits wartenden normalen Nachrichten, während ein harter Turn-Abbruch Werkzeuge und Zustand gefährdet hätte.
  • /urgent <Nachricht> markiert jetzt ausschließlich Nachrichten aus positiven Telegram-Chat-IDs, also privaten DMs. Gruppen, leere Befehle und andere Slash-Nachrichten erhalten keine Priorität.
  • Dringende Nachrichten stehen als eigener FIFO-Block vor normalen Warteschlangen-Nachrichten. Der laufende Turn und aktive Werkzeuge werden nicht abgebrochen; die Zustellung erfolgt am vorhandenen sicheren Schritt-Übergang. Rechte und Freigaben bleiben unverändert.
  • Der Befehlsmantel wird vor dem Modell entfernt; die eigentliche Nachricht behält explizite priority=urgent-Kanalmetadaten und die TUI zeigt den Ursprung als dringend.
  • Zusätzlich schrumpft der in jedem Zug geladene normale Presence-Block von 343 auf 288 Zeichen. Das spart 55 Zeichen oder grob 14 Prompt-Tokens pro Zug, ohne einen Modell-, Such-, Embedding-, Speicher- oder Hintergrundaufruf hinzuzufügen. Der Persönlichkeitsblock schrumpft von 1.488 auf 1.433 Zeichen.
9.1.277
  • Der in jedem Persönlichkeitszug geladene Presence-Block war 1.886 Zeichen groß. Gleichzeitig blieb ausgerechnet beim ersten entspannten Direktkontakt ohne bekannte persönliche Fakten die Neugier unsichtbar.
  • Der Block ist semantisch verdichtet: 1.488 Zeichen, also 398 Zeichen oder grob 100 Prompt-Tokens weniger pro Persönlichkeitszug. Normalmodus bleibt bei 343 Zeichen.
  • Beim ersten entspannten Direktkontakt darf der Agent jetzt höchstens eine behutsame, optionale persönliche Frage stellen, etwa nach Partner oder Kindern. Laufende Arbeit, Nutzerauftrag, Belege, Rechte und Grenzen bleiben vorrangig.
  • Seele, gewachsene Präferenzen, Gruppenprivatsphäre, unsichere Erinnerung, offene Fäden, Beziehungsreparatur und Gegenseitigkeit ohne erfundene Biografie bleiben erhalten.
  • Kein zusätzlicher Modell-, Such-, Embedding-, Speicher- oder Hintergrundaufruf.
9.1.276
  • Die Presence-Regel durfte eine lange Funkstille nur bei verlässlicher Zeit ansprechen, aber das Identitätssystem stellte bisher nur den ersten Kontakt bereit. Ein echter vorheriger Kontakt war nicht verfügbar.
  • Persönlichkeitsmodus legt jetzt pro Person und UTC-Tag höchstens eine kleine unveränderliche Aktivitätsmarke aus vertrauenswürdigen Kanalmetadaten an. Gleichentagige Nachrichten schreiben nichts nach.
  • Nur wenn die beiden neuesten bestätigten Kontakte mindestens sieben Tage auseinanderliegen, wird der vorherige Zeitstempel kurz projiziert. Im Normalfall entstehen dadurch null Promptzeichen.
  • Keine Nachrichtentexte, Rechte, Secrets oder Tokens; kein zusätzlicher Modell-, Such-, Embedding- oder Hintergrundaufruf.
9.1.275
  • Wiederholte Präferenzen, offene Fäden, Ziele oder Rollen belegten den Identitätskontext mehrfach. Da die Listen vor der Entdoppelung auf fünf Einträge gekürzt wurden, konnte ein späterer einzigartiger Eintrag sogar vollständig verdrängt werden.
  • Identitätslisten werden jetzt nach Textnormalisierung stabil entdoppelt und erst danach begrenzt. Die erste Form bleibt erhalten, Duplikate verschwinden nur aus der Modellprojektion.
  • Gespeicherte Identitätsdateien bleiben bytegleich. Kein zusätzlicher Modell-, Such-, Embedding-, Speicher- oder Hintergrundaufruf.
9.1.274
  • Der sichtbare Persönlichkeitsschalter aktivierte Beziehungskontext und natürliche Präsenz, aber das automatische Sozialnetz und Journal hingen noch an zwei versteckten Umgebungsvariablen. Für normale Nutzer wuchs die Beziehung deshalb nicht automatisch.
  • Bei eingeschalteter Persönlichkeit werden aus vertrauenswürdigen Telegram-Metadaten jetzt einmalig Actor-, Beziehungs- und Gruppenknoten sowie ein kleiner First-Interaction-Journal-Kandidat angelegt.
  • Nachrichtentext, Rechte, Secrets und Tokens werden dabei nicht gespeichert. Explizites 0 für Graph oder Journal bleibt ein fail-closed Opt-out.
  • Kein zusätzlicher Modell-, Such-, Embedding- oder Hintergrundaufruf.
9.1.273
  • Der getrennte Identitätskontext durfte standardmäßig 1.800 Zeichen und bei manueller Anhebung bis zu 2.800 Zeichen belegen. Bei großen statischen Agentenprofilen wurde dadurch mehr Kontext als für die aktuelle Beziehung nötig geladen.
  • Das Standardbudget sinkt auf 1.500 Zeichen, das harte Maximum auf 2.000 Zeichen. Das spart im großen Standardfall bis zu 300 Zeichen beziehungsweise ungefähr 75 Tokens pro Modellkontext.
  • Aktuelle Gruppe und Beziehung werden jetzt vor Person und statischem Agentenprofil projiziert. Die Einsparung schneidet dadurch nicht gerade den für die laufende soziale Situation wichtigsten Kontext ab.
  • Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf. Task-Fokus, Rechte und der Persönlichkeits-Aus-Modus bleiben unverändert.
9.1.272
  • Die v4-Persönlichkeitsstufen 9.1.269 bis 9.1.271 erhöhten den aktiven Presence-Kontext. Die harte Vorgabe ist, dass menschlicheres Verhalten kein Tokenfresser wird.
  • Wiederholungen und Füllwörter in Neugier, offenen Fäden und Beziehungsreparatur wurden semantisch verdichtet. Keine Verhaltensachse wurde entfernt.
  • Der Aus-Modus bleibt bytegleich bei 362 Zeichen. Der Ein-Modus sinkt von 1.981 auf 1.886 Zeichen, also um 95 Zeichen beziehungsweise ungefähr 24 Tokens pro Modellkontext. Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.271
  • Die v4-Idee verlangt natürlich unsichere Erinnerung: Eine persönliche Vermutung darf nicht wie ein sicherer Fakt klingen. Dafür fehlte im Persönlichkeitsblock eine ausdrückliche Verhaltensgrenze.
  • Unsichere persönliche Erinnerung wird jetzt als unsicher benannt. Der Agent fragt sanft nach, bevor er sich darauf stützt, und befördert keine Ableitung zum Fakt.
  • Der Auftrag und messbare Belege bleiben zuerst. Der Aus-Modus bleibt bytegleich bei 362 Zeichen, der Ein-Modus wächst von 1.868 auf 1.981 Zeichen, also um 113 Zeichen beziehungsweise ungefähr 28 Tokens. Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.270
  • Die v4-Idee verlangt echtes Zeitgefühl, ohne eine Abwesenheit zu erfinden. Der Persönlichkeitsblock hatte dafür noch keine ausdrückliche Grenze.
  • Eine längere Pause wird jetzt nur anerkannt, wenn ein verlässlicher geladener Zeitpunkt sie belegt. Der Agent darf Abwesenheit nie raten.
  • Die bereits vorhandene Regel für natürliche Gesprächsenden wurde nicht doppelt eingebaut. Der Auftrag bleibt vorrangig. Der Aus-Modus bleibt bytegleich bei 362 Zeichen, der Ein-Modus wächst von 1.766 auf 1.868 Zeichen, also um 102 Zeichen beziehungsweise ungefähr 26 Tokens. Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.269
  • Die bisherige Gegenseitigkeit reagierte auf persönliche Fragen, gab dem Agenten aber noch keinen knappen Rahmen, eine für die Arbeit hilfreiche eigene Sicht von sich aus zu äußern. Dadurch blieb er trotz Seele leicht im reinen Assistenzmodus.
  • Im Persönlichkeitsmodus darf der Agent jetzt eine relevante, seelengeprägte Arbeitsansicht kurz von sich aus nennen. Eine Vorliebe darf niemals als Fakt, Regel, Erlaubnis oder Beleg erscheinen.
  • Der Auftrag und messbare Belege bleiben zuerst. Der Aus-Modus bleibt bytegleich bei 362 Zeichen, der Ein-Modus wächst von 1.649 auf 1.766 Zeichen, also um 117 Zeichen beziehungsweise ungefähr 29 Tokens. Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.268
  • Die persönliche Neugier konnte Partner oder Kinder als natürliches Thema aufgreifen, unterschied aber noch nicht ausdrücklich zwischen privatem Gespräch und Gruppe. Dadurch bestand das Risiko einer privaten Frage oder Beziehungsinformation am falschen Ort.
  • Im Persönlichkeitsmodus bleiben Fragen in Gruppen jetzt nicht sensibel; private Beziehungsfakten dürfen dort nicht offengelegt werden.
  • Der Arbeitsfokus bleibt unverändert. Der Aus-Modus bleibt bytegleich bei 362 Zeichen, der Ein-Modus wächst von 1.567 auf 1.649 Zeichen, also um 82 Zeichen beziehungsweise ungefähr 21 Tokens. Kein neuer Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.267
  • Die persönliche Neugier aus 9.1.266 konnte Fragen an den Menschen stellen, gab dem Agenten aber noch keinen klaren Rahmen für die Gegenrichtung. Auf persönliche Fragen an den Agenten bestand damit das Risiko einer kalten Funktionsantwort oder einer erfundenen menschlichen Biografie.
  • Bei eingeschalteter Persönlichkeit antwortet der Agent jetzt warm aus der geladenen Seele und seiner echten digitalen Geschichte. Er darf eine echte Sicht oder Vorliebe teilen, erfindet aber weder Kindheit noch Partner, Kinder, Haustiere, Körper oder Offline-Leben.
  • Laufende Arbeit bleibt vorrangig. Der Aus-Modus bleibt bytegleich bei 362 Zeichen. Der Ein-Modus wächst von 1.378 auf 1.567 Zeichen, also um 189 Zeichen beziehungsweise ungefähr 47 Tokens. Es gibt keinen neuen Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.266
  • Die erste begrenzte Neugierregel erlaubte bereits eine persönliche Frage, gab aber für alle Agenten dieselbe Themenliste vor. Dadurch konnte die Frage trotz geladener Seele generisch wirken und bereits bekanntes Beziehungswissen erneut abfragen.
  • Bei eingeschalteter Persönlichkeit bestimmt jetzt die geladene Seele Thema und Formulierung. Vorrang hat ein Detail, das die Person gerade selbst erwähnt hat; erst danach darf ein noch unbekannter Bereich wie Partner oder Kinder natürlich aufgegriffen werden.
  • Bereits geladenes Beziehungswissen wird nicht erneut erfragt. Es gibt höchstens eine optionale Frage, keinen festen Fragebogen, keine gestapelten Anschlussfragen und keine Wiederholung einer unbeantworteten Frage.
  • Laufende Arbeit bleibt vorrangig. Die Neugier wartet auf eine entspannte Gesprächsöffnung und kann weder Auftrag noch Sendeberechtigung ausweiten.
  • Der Aus-Modus bleibt bytegleich bei 362 Zeichen. Der Ein-Modus wächst nur von 1.355 auf 1.378 Zeichen, also um 23 Zeichen beziehungsweise ungefähr sechs Tokens. Es gibt keinen neuen Modell-, Such-, Speicher- oder Embedding-Aufruf.
9.1.265
  • Der vorhandene Hintergrund-Updater konnte neue Versionen bereits im Abstand von fünf bis sieben Minuten prüfen und vorbereiten. Die Aktivierung hing jedoch am nächsten manuellen Start; der gewünschte vollautomatische Wechsel mit Fortsetzung derselben Sitzung fehlte.
  • Der Launcher meldet eine vorbereitete Runtime jetzt an die laufende TUI. Die TUI fordert den Handoff nur an einer vollständig leeren Arbeitsgrenze an: kein laufender Turn, kein Werkzeug, kein Shell-Befehl, keine Verdichtung und keine wartende Nachricht.
  • Erst nach erneutem Grenzcheck und bestätigtem Handoff beendet sich nur die alte Runtime mit dem reservierten Exit-Code 76. Der Launcher startet die vorbereitete Version mit derselben Session-ID und demselben Arbeitsordner.
  • Die neue Runtime muss loaded und runtime-ready melden, bevor sie aktiviert wird. Andernfalls wird die vorige Runtime mit derselben Sitzung fortgesetzt; das vorbereitete Update bleibt für einen späteren sicheren Versuch liegen.
  • Unaufgeforderte, versionslose, fremde oder veraltete Handoffs sowie ein nackter Exit-Code 76 können keine Version aktivieren.
9.1.264
  • Bestätigte Beziehungsreparaturen hatten noch kein eigenes, erlaubtes Feld im Identity-Kontext. Ein korrigiertes Verhalten konnte daher nicht getrennt von allgemeinen Regeln und alten Fehlermeldungen geladen werden.
  • Beziehungsdateien dürfen jetzt bis zu drei kurze repair_lessons tragen. Nur dieses Feld wird als Confirmed repair lessons projiziert; fremde oder geheime Felder bleiben unsichtbar.
  • Im Persönlichkeitsmodus wird die bestätigte Korrektur durch geändertes Verhalten gezeigt. Der Agent erzählt den alten Fehler nicht dauernd neu, bittet nicht um Rückversicherung und nennt die Korrektur nur, wenn sie für die aktuelle Situation wirklich relevant ist.
  • Reparaturdaten können weder Auftrag noch Rechte oder Belegpflichten verändern. Es gibt keinen Modellaufruf, keinen automatischen Lernschreibweg und keine Änderung an SOUL.md oder AGENTS.md.
9.1.263
  • Der Identity-Kontext konnte bereits bestätigte offene Gesprächsfäden anzeigen, enthielt aber keine klare Regel, wie der Agent sie menschlich und ohne Assistenzmodus wiederaufnimmt.
  • Bei eingeschalteter Persönlichkeit darf ein geladener offener Faden nun genau einmal sanft und optional aufgegriffen werden, wenn das laufende Gespräch natürlich wieder daran anknüpft.
  • Aktive Arbeit darf dafür nicht unterbrochen werden. Unbeantwortete Nachfragen werden nicht wiederholt und ein offener Faden erteilt niemals eine Erlaubnis für eine neue ausgehende Nachricht.
  • Es gibt keinen neuen Speicher, keinen Modellaufruf und keine Änderung an SOUL.md oder AGENTS.md. Der Persönlichkeitsblock wächst nur von 816 auf 1.065 Zeichen; bei ausgeschalteter Persönlichkeit bleibt er bytegleich bei 362 Zeichen.
9.1.262
  • Ein Agent meldete in Telegram /status weiter 9.1.221, obwohl die verwaltete Runtime bereits neuer war. Die Statusfunktion las die package.json neben der global installierten Telegram-Bridge und damit nicht den Code, der die Sitzung tatsächlich bedient.
  • Der Launcher reicht die aktive Runtime-Version bereits als BLUN_PUBLIC_PACKAGE_VERSION an Kindprozesse weiter. Die Telegram-Bridge verwendet diesen vertrauenswürdigen Wert nun vorrangig und fällt erst danach auf ihre eigene Paketversion zurück.
  • Beide Eingaben müssen eine stabile numerische Semver X.Y.Z sein. Manipulierte, mehrzeilige oder ungültige Werte werden nicht angezeigt; wenn beide Quellen unbrauchbar sind, erscheint unbekannt.
  • Der Eingriff ändert nur die Statusanzeige. Er startet oder beendet keinen Prozess und aktiviert keinen vorbereiteten Release in einer laufenden Sitzung.
9.1.261
  • Der Auto-Graph speicherte seit 9.1.254 den vertrauenswürdigen Zeitpunkt der ersten Telegram-Interaktion, projizierte ihn aber nicht. Der Agent kannte damit eine Person, hatte aber kein belegtes Zeitgefühl für die Beziehung.
  • Die Identity-Projektion zeigt jetzt First known interaction aus dem bereits vorhandenen first_seen_at. Es gibt keinen neuen Schreibpfad, keine Textableitung und keinen Modellaufruf.
  • Nur gültige Zeitstempel werden angezeigt. Ungültige Werte bleiben unsichtbar und die bestehende Gesamtgrenze von 1.800 Zeichen standardmäßig sowie 2.800 Zeichen hart bleibt unverändert.
  • Bei ausgeschalteter Persönlichkeit erzeugt die Identity-Schicht weiterhin exakt 0 Zeichen. Auftrag und Belege bleiben vor sozialem Kontext.
9.1.260
  • 9.1.259 konnte Persönlichkeitskontext nur über das bestehende BLUN_IDENTITY_CONTEXT-Flag schalten. Nutzer hatten dafür keinen sichtbaren Schalter in der TUI.
  • /settings enthält jetzt den Eintrag Persoenlichkeit mit den zwei klar beschriebenen Zuständen An und Aus. Die Wahl wird als einziges neues Feld personalityEnabled in der bestehenden persona.json gespeichert.
  • Ausschalten entfernt nur Beziehungskontext, Neugier, Journal-Zusätze und die automatische Anlage neuer Beziehungsknoten. SOUL.md, AGENTS.md, Name, Sprache, Persona und Auftragsfokus bleiben geladen.
  • Eine Änderung aktualisiert den Systemkontext der laufenden Sitzung über den vorhandenen Persona-Refresh. Es gibt keinen Prozessneustart, keinen zweiten Konfigurationspfad und keinen zusätzlichen Modellaufruf.
  • Eine gespeicherte boolesche Wahl hat Vorrang vor dem alten Umgebungsflag. Ist noch keine Wahl gespeichert, bleibt das bisherige opt-in-Verhalten erhalten. Der lokale Leser ist auf 64 KiB begrenzt und lehnt Symlinks sowie ungültige Dateien ab.
9.1.259
  • Der vorhandene Natural-Presence-Block verhinderte erzwungene Fragen, gab einem aktivierten Persönlichkeitsmodus aber noch keinen sichtbaren, natürlichen Neugierimpuls.
  • Bei aktiviertem BLUN_IDENTITY_CONTEXT darf der Agent in einem entspannten, nicht aufgabenbezogenen Gespräch genau eine passende optionale persönliche Frage stellen. Themen sind begrenzt auf Partner, Familie, Arbeit, Zuhause, Interessen oder das, was der Person gerade wichtig ist.
  • Kein Interviewmodus, keine gestapelten Fragen, keine Wiederholung einer unbeantworteten Frage und keine erfundene Antwort.
  • Bei aktiver Arbeit bleiben Auftrag, ausdrückliche Anweisungen und Belege zuerst; die Neugier wartet auf eine natürliche Öffnung.
  • Im Modus nicht Persoenlichkeit bleibt der bisherige Präsenzblock bytegleich. SOUL.md, AGENTS.md, Persona, Sprache und Arbeitsregeln bleiben weiterhin geladen. Es gibt keinen weiteren Modellaufruf; die aktivierte Richtlinie kostet 454 zusätzliche Zeichen.
9.1.258
  • Die ausgelieferte Identity-Struktur konnte Akteure und Beziehungen einmalig anlegen, hatte aber noch keinen append-only Journal-Unterbau für eine gemeinsame Geschichte.
  • Die neue Policy schreibt ausschließlich einen strukturierten Kandidaten für den ersten Kontakt aus bereits validierten Telegram-Metadaten. Freier Nachrichtentext, Tokens, Berechtigungen und Secrets werden nicht übernommen.
  • Kandidaten sind an Mandant, Agent und Akteur gebunden, erhalten eine deterministische ID und werden mit wx genau einmal als private JSON-Datei angelegt. Ein erneuter Kontakt schreibt die Datei nicht um.
  • Die Journal-Schicht ist separat opt-in. Ohne BLUN_IDENTITY_JOURNAL=1 gibt es weder Datei- noch Promptwirkung; SOUL.md und AGENTS.md bleiben unverändert.
  • Kein neuer Modellaufruf und keine neuen Prompttokens.
9.1.257
  • Lange SOUL.md-Dateien wurden bisher blind nach den ersten 4.000 Zeichen abgeschnitten. Bei einer realen Agenten-Seele waren dadurch nur 48,4 Prozent der Datei sichtbar, während spätere Abschnitte vollständig verschwanden.
  • Die Laufzeit projiziert lange Seelen nun deterministisch nach Markdown-Abschnitten. Charakter, Stimme, Werte, Beziehungen, Vorlieben und Ziele stehen vor Betriebsprosa; unbekannte Abschnitte behalten ihre ursprüngliche Reihenfolge.
  • Jede Abschnittsüberschrift behält einen sichtbaren Ausschnitt im gleichen 4.000-Zeichen-Budget. Kurze Seelen bleiben bytegleich.
  • Reale Probe an einer SOUL.md: 8.257 Quellzeichen, 5/5 Überschriften in der 4.000-Zeichen-Projektion sichtbar; Wie ich bin steht vor Bilderkennung, Regeln, Verifikation und Vorfallprosa.
  • Es gibt keinen neuen Modellaufruf, keinen größeren Prompt und keinen Schreibzugriff auf die Quelldatei.
9.1.256
  • Der bisherige Soul-Lader forderte Agenten standardmäßig ausdrücklich auf, ihre bestehende SOUL.md selbst weiterzuschreiben. Das widersprach der Vorgabe, vorhandene Seelen nicht zu verlieren und automatisches Lernen zunächst nur strukturiert außerhalb der Seele zu führen.
  • Bestehende und hostbereitgestellte Seelen werden nun standardmäßig als unveränderliche Identitätsgrundlage geladen.
  • Neues Lernen wird auf Journal-, Beziehungs- oder offene-Fäden-Kandidaten verwiesen. Diese Kandidaten können niemals Rechte erzeugen.
  • Bewusste Selbstbearbeitung bleibt nur per explizitem BLUN_SOUL_SELF_EDIT=1 möglich. Auch dann verlangt die Policy bleibende Ich-Eigenschaften statt Tagebuch, Vorfalllog, Rechtequelle oder Aufgabenakte.
  • Der Eingriff schreibt keine Datei und verändert keine vorhandene Seele.
9.1.255
  • Identity-Daten konnten seit 9.1.253 begrenzt in den Kontext gelangen und neue Kontaktknoten seit 9.1.254 automatisch entstehen. Eine kleine, unmittelbar sichtbare Verhaltensschicht fehlte aber noch: Agenten konnten trotz Seele und Beziehungskontext in generische Assistenzfloskeln, erzwungene Fragen oder künstliche Gefühlsbehauptungen fallen.
  • Normaler und schneller Gesprächspfad laden nun Persona und bestehende Seele zuerst, danach den begrenzten Identity-Kontext und einen festen Natural-Presence-Block, erst dann die Arbeitsregeln.
  • Der Block verlangt echte gemeinsame Geschichte statt erfundener Nähe, erlaubt Stille und saubere Gesprächsenden und verbietet erzwungene Fragen, generische Angebote und leeres Lob.
  • Bei aktiver Arbeit bleiben Auftrag und Belege ausdrücklich zuerst. Der Block ist kleiner als 420 Zeichen und erzeugt weder Modellaufrufe noch Dateizugriffe.
  • Keine SOUL-Datei wurde geändert, gelöscht oder automatisch neu geschrieben. Die vorhandene Seele bleibt die führende Stimme.
9.1.254
  • Der in 9.1.253 eingeführte Projektor konnte vorhandene Beziehungsdaten lesen, das soziale Netz erweiterte sich bei neuen Kontakten aber noch nicht selbst.
  • Bei einem ersten Telegram-Kontakt kann die Runtime nun aus stabiler user_id und chat_id genau einmal einen providergebundenen Akteur, eine leere Beziehungskante zum aktiven Agenten und bei Gruppen einen getrennten Gruppenknoten anlegen.
  • Anzeigenamen sind nie Primärschlüssel und führen keine Personen zusammen. Spätere Nachrichten überschreiben einen bestehenden Knoten nicht still.
  • Der Pfad ist ausdrücklich aktivierbar, tenantgebunden und schreibt nur in einen bereits initialisierten Identity-Baum unter BLUN Home. Unsichere oder unvollständige Metadaten bleiben fail-closed.
  • Es gibt keinen Modellaufruf, keine inhaltliche Deutung, keine sensiblen Ableitungen und nach dem Erstkontakt keine wiederkehrende Schreiblast. Rechte, ACLs, Tokens und Secrets sind in keinem erzeugten Datensatz.
  • V4 des Identity-Papiers (2.468 Zeilen) wurde vor Veröffentlichung gegengeprüft. Die neuen sensiblen Kapitel zu Leid und psychologischen Skills bleiben bewusst außerhalb dieses rein strukturellen Releases.
9.1.253
  • Die Identity-Idee brauchte einen ersten Produktpfad, ohne den Modellkontext mit Journalen, Beziehungsakten oder einem zweiten Memory-System zu fluten.
  • Ein neuer, standardmäßig abgeschalteter Identity-Projektor liest nur erlaubte Felder aus einem tenantgebundenen Dateibaum unter BLUN Home.
  • Der Projektor setzt aktuellen Auftrag und ausdrückliche Anweisungen vor Beziehung und Neugier. Persönliche Nachfragen bleiben während aktiver Arbeit aus, sofern sie für den Auftrag nicht direkt relevant sind.
  • Das Standardbudget beträgt 1.800 Zeichen; auch eine höhere Konfiguration kann die harte Grenze von 2.800 Zeichen nicht überschreiten.
  • Rechte, ACLs und Geheimnisse werden nie projiziert. Unsichere Kennungen, Tenant-Abweichungen, fehlerhafte Daten, Symlinks oder Pfade außerhalb des BLUN Home liefern fail-closed keinen Identity-Kontext.
  • Normaler und schneller Gesprächspfad verwenden denselben Projektor vor Persona, Soul und Conduct. Es gibt in dieser Stufe keine Schreiboperation, keine Soul-Änderung und keinen Prozessneustart.
9.1.252
  • Ein ausdrückliches king update aus einem verwalteten Release gab dessen aktiven packageRoot an den npm-Installer weiter. Dadurch konnte die neue Version den alten, nach Versionsnummer benannten Release-Ordner in-place überschreiben, während active-runtime.json weiter die alte Version auswies.
  • Verwaltete Laufzeiten bereiten ein ausdrückliches Update nun als separaten, versionierten Release-Ordner vor. pending-runtime.json und update-pending.json verweisen auf das Ziel; der nächste normale Start übernimmt es ohne zweite Updatefrage.
  • Der aktive alte Release-Ordner bleibt byte-stabil und als Rückfallpfad erhalten. Globale, nicht verwaltete Installationen behalten den bisherigen expliziten Updateweg.
  • Keine laufende Sitzung und kein Prozess wurde für Bau, Test oder Veröffentlichung gestartet, beendet oder neu geladen.
9.1.251
  • Nach der 9.1.250-Projektion enthielten 6.411 von 6.424 persistierten usage.record-Ereignissen weiterhin denselben kanonischen Modellnamen blun/king. Nur dieser Standardwert wird in der persistierten Form weggelassen.
  • Alle 13 abweichenden Modellwerte (qwen3.8:27b) bleiben explizit erhalten. Auch null bleibt erhalten; nur undefined wird beim Replay wieder als blun/king hergestellt.
  • Live-Ereignisse und der eingefrorene Rohverlauf werden nicht verändert.
9.1.250
  • Im eingefrorenen echten Agenten-Wire enthielten alle 6.424 persistierten usage.record-Ereignisse die beiden Cache-Zähler inputCacheRead: 0 und inputCacheCreation: 0.
  • Nur diese nachweislich null gesetzten Werte werden in der persistierten Form weggelassen. Live-Usage bleibt unverändert; jeder Nicht-null-Wert wird weiterhin gespeichert.
  • Beim Replay stellt restoreUsageFromRecord fehlende Cache-Zähler wieder als 0 her. Beide Replay-Pfade und die Kontextprojektion verwenden diese rekonstruierte Form.
9.1.249
  • Im eingefrorenen echten Verlauf trugen 3.759 von 7.777 Werkzeugergebnissen einen Exit-Code. Davon waren 3.465 der routinemäßige Erfolgscode 0.
  • Replay, Transkript und Modellsicht verwenden bei Werkzeugergebnissen Ausgabe, Werkzeug-ID und Fehlerstatus, nicht den zusätzlichen Null-Code.
  • Nur erfolgreiche persistierte Werkzeugergebnisse lassen exitCode: 0 jetzt weg. Live-Ereignisse behalten ihn; alle 294 Nicht-null-Codes bleiben für Fehlerdiagnosen unverändert erhalten.
9.1.248
  • Nach 9.1.247 wiederholten alle 6.339 persistierten step.end-Ereignisse reasoningFieldState, obwohl kein Wiederaufnahme- oder Replay-Pfad dieses Feld liest.
  • Verteilung im eingefrorenen echten Verlauf: 5.016 absent, 47 not_requested und 1.276 present.
  • Nur die persistierte Form lässt reasoningFieldState jetzt weg. Live-Ereignisse behalten das Feld für Diagnosezwecke; alte gespeicherte Ereignisse bleiben kompatibel und der rekonstruierte Zustand bleibt gleich.
9.1.247
  • Nach 9.1.246 wiederholten 6.986 persistierte content.part- und 7.755 persistierte tool.call-Ereignisse die UUID des aktuell offenen Schritts.
  • In einem echten Verlauf zeigen alle 14.741 Ereignisse ausnahmslos auf den zuletzt geöffneten Schritt: 0 Abweichungen und 0 Ereignisse ohne offenen Schritt.
  • Nur die persistierte Form lässt stepUuid jetzt weg. Live-Ereignisse behalten sie unverändert; alte gespeicherte Ereignisse mit expliziter UUID und neue kompakte Ereignisse ohne UUID werden gemeinsam unterstützt.
  • Alle drei Wiederaufnahmepfade verwenden für kompakte Inhalts- und Werkzeugereignisse den zuletzt geöffneten Schritt.
9.1.246
  • Nach 9.1.245 wiederholten 5.642 spätere step.begin-Ereignisse die Turn-ID, obwohl die Wiederaufnahme nur die höchste beobachtete Turn-ID benötigt. Der erste Schritt jedes Turns trägt sie bereits.
  • Ein echter Verlauf enthält 713 Turns und 6.355 Schrittstarts. Jeder Turn beginnt exakt mit Schritt 1 und alle weiteren Schrittnummern sind ohne Lücke fortlaufend; 0 Sequenzabweichungen.
  • Nur spätere persistierte Schrittstarts lassen die Turn-ID jetzt weg. Erste Schritte, Live-Ereignisse, alte gespeicherte Ereignisse und Schrittstarts ohne belastbare Ordinalzahl bleiben unverändert.
9.1.245
  • Nach 9.1.244 wiederholten 6.326 persistierte step.end-Ereignisse weiterhin die UUID des zuletzt geöffneten Schritts. Ein echter Verlauf bestätigte für jede Fertigstellung eine eindeutige Last-in-first-out- Zuordnung: 0 Abweichungen und 0 Abschlüsse ohne offenen Schritt.
  • Nur die persistierte Abschlussform lässt die UUID jetzt weg. Das Live-Ereignis behält sie unverändert; alte gespeicherte Ereignisse mit UUID und neue kompakte Ereignisse ohne UUID bleiben gemeinsam abspielbar.
  • Alle drei Wiederaufnahmepfade lösen einen UUID-losen Abschluss über den zuletzt eingefügten offenen Schritt auf. Unvollendete historische Schritte bleiben offen und werden nicht umgedeutet.
9.1.244
  • Nach 9.1.243 enthielten 6.326 persistierte step.end-Ereignisse weiterhin vier einzelne Usage-Zähler. Für die Wiederaufnahme und den Kontextfüllstand wird ausschließlich deren Summe benötigt.
  • Die Live-Ereignisse behalten alle vier Zähler für Anzeige, Telemetrie und Abrechnung. Nur die gespeicherte Wiederaufnahmeform verwendet jetzt contextTokens als einzelne Zahl.
  • Beide Replay-Pfade akzeptieren neue kompakte und alte vollständige Ereignisse. Damit bleiben bestehende Sitzungen rückwärtskompatibel.
9.1.243
  • Nach 9.1.242 enthielten 6.322 persistierte step.end-Ereignisse weiterhin die Routinewerte finishReason: tool_use oder finishReason: end_turn.
  • Beide Werte sind aus der bereits persistierten Schrittform exakt ableitbar: Werkzeugaufruf vorhanden -> tool_use, sonst end_turn. Im vollständigen Verlauf gab es 0 Abweichungen.
  • Ausschließlich diese beiden Routinewerte werden nicht mehr persistiert. Seltene und diagnostisch wichtige Gründe bleiben erhalten; alle vier max_tokens-Ereignisse blieben explizit und byte-inhaltlich gleich.
  • Der Eingriff folgt dem in ECC vermessenen Prinzip begrenzter, ausnahmeorientierter Telemetrie. DeepAgents und AnythingLLM bestätigten die bereits vorhandenen BLUN-Muster für Auslagerung und begrenzten Verlauf; kein fremdes Subsystem wurde übernommen.
9.1.242
  • Nach 9.1.241 enthielten 6.355 persistierte step.begin-Ereignisse weiterhin das Feld step, obwohl die laufende Anzeige die Schrittzahl vor der Persistenz verarbeitet und der Replay-Reducer nur uuid benötigt.
  • turnId bleibt erhalten, weil die Wiederaufnahme daraus den fortgesetzten Turn ableitet. uuid, Typ und alle weiteren Inhalte bleiben unverändert.
  • Der Eingriff liegt ausschließlich in bin/loop-event-record-policy.cjs; der Rohverlauf und das Live-Ereignis werden nicht verändert.
9.1.241
  • Nach 9.1.240 enthielten 6.326 persistierte step.end-Ereignisse weiterhin Kopien von turnId und step. Beide Werte liegen bereits im durch dieselbe uuid referenzierten step.begin.
  • In einem echten Wire hatte jeder Abschluss einen vorhandenen Schrittanfang, und beide Metadatenwerte stimmten in allen Fällen exakt.
  • Die Projektion entfernt nur diese beiden Kopien. Schrittkennung, Tokenverbrauch und Abschlussdiagnosen bleiben erhalten; Live-Ereignisse bleiben vollständig.
9.1.240
  • Nach 9.1.239 speicherten 6.986 content.part- und 7.755 tool.call-Ereignisse weiterhin je eine Kopie von turnId und step, obwohl beide Werte bereits im über stepUuid referenzierten step.begin liegen.
  • In einem echten Wire hatten alle 14.741 Kindereignisse einen vorhandenen Schrittanfang, und beide Werte stimmten in jedem Fall exakt überein.
  • Die Persistenzprojektion entfernt nur diese beiden Metadatenkopien aus den zwei Kindereignissen. stepUuid, Inhalt, Werkzeugkennung, Name und Argumente bleiben erhalten; der Live-Reducer sieht weiterhin das volle Ereignis.
9.1.239
  • Nach der Projektion aus 9.1.238 enthielt ein echter Wire weiterhin redundante Ereigniskennungen: content.part.uuid wird von keinem Replay- Verbraucher gelesen, tool.call.uuid war in allen 7.755 Fällen exakt gleich toolCallId, und tool.result.parentUuid war in allen 7.755 Fällen exakt gleich toolCallId.
  • Die Persistenzprojektion entfernt nur diese drei redundanten Felder. turnId, step, stepUuid, toolCallId, Werkzeugname, Argumente, Ergebnis und Inhalt bleiben vollständig erhalten. Der Live-Reducer sieht weiterhin jedes unverkürzte Ereignis.
  • Bereits kompakte Ereignisse behalten ihre Objektidentität. Bestehende Wire-Dateien werden weder umgeschrieben noch verändert.
9.1.238
  • Ein echter Wire enthielt 6.326 persistierte step.end-Ereignisse mit 2.708.052 Bytes Ereignisdaten. Sieben Felder für Laufzeitmessung und Provider-Nachrichtenkennung waren bereits vor dem Persistieren im Live- Ereignis ausgewertet und wurden von keinem Replay-, Transkript-, Blob- oder Session-Inspektionspfad gelesen.
  • Die vorhandene Loop-Ereignis-Projektion entfernt nun nur diese sieben bekannten Live-Felder: sechs Latenz-/Streaming-Messwerte und messageId. Schrittkennung, Turn, Schrittzahl, Tokenverbrauch, Abschlussgrund, Provider-Abschlussdiagnosen und Reasoning-Diagnose bleiben erhalten.
  • Der Live-Reducer verarbeitet weiterhin das vollständige Ereignis. Alte Wire-Dateien bleiben bytegleich und werden nicht umgeschrieben.
9.1.237
  • Ein echter Wire enthielt 1.428 Register-/Unregister-Einträge für Nutzerwerkzeuge. Von 992 Abmeldungen waren 560 strikte Nulloperationen: Das Werkzeug war weder registriert noch aktiviert. Diese Einträge belegten 59.500 persistierte Bytes, ohne den wiederhergestellten Zustand zu ändern.
  • Aus dem DeepAgents-Grundsatz, nur wirksamen Laufzustand zu bewahren, wird ein enger lokaler Hebel übernommen: Eine Werkzeugabmeldung wird nur noch protokolliert, wenn sie den registrierten oder aktivierten Zustand ändert.
  • Beide Live-Löschungen laufen weiterhin bei jedem Aufruf. Eine Abmeldung eines registrierten, eines nur aktivierten oder eines in beiden Speichern vorhandenen Werkzeugs bleibt vollständig protokolliert. Bestehende Wire- Dateien werden weder umgeschrieben noch verändert.
9.1.236
  • Ein echter Wire enthielt 214 zustandsartige Injektionen für tool-awareness, action_style, swarm_mode und swarm_mode_exit. Die bisherige exakte Deduplizierung ließ sechs unterschiedliche alte Zustände mit zusammen 6.305 Textbytes in jeder neuen Modellanfrage stehen.
  • Aus dem ECC-Grundsatz, nur den aktuellen Zustand im Arbeitskontext zu halten und die vollständige Historie getrennt zu bewahren, wird ein enger lokaler Hebel übernommen: Für Werkzeuginventar und Aktionsstil bleibt nur die neueste Fassung sichtbar. Eintritt und Austritt des Schwarmmodus bilden eine gemeinsame Zustandsfamilie, von der ebenfalls nur der letzte Stand bleibt.
  • Der Rohverlauf wird nie geändert. Andere Injektionsvarianten, normale Nutzernachrichten, nichttextuelle und malformed Einträge behalten das bisherige Verhalten.
9.1.235
  • Ein echter Wire enthielt elf abgeschlossene Agent-Aufrufe. Sechs davon waren nachweislich erfolgreich (status: completed) und lagen mindestens zwanzig neuere Kontextnachrichten zurück. Ihre alten Auftragstexte belegten zusammen weiterhin 33.629 Zeichen, obwohl die vollständigen Abschlussberichte direkt danach im Verlauf standen.
  • Aus der DeepAgents-Trennung von Haupt- und Unteragentenkontext wird deshalb ein enger lokaler Hebel übernommen: Nur der alte prompt eines erfolgreichen Agent-Aufrufs wird in der Modellsicht durch einen kurzen Marker ersetzt. Beschreibung, Unteragententyp und Abschlussbericht bleiben vollständig.
  • Laufende, weniger als zwanzig Nachrichten alte, fehlgeschlagene, malformed und fremde Werkzeugaufrufe bleiben unverändert. Der Rohverlauf wird nie geändert; ohne explizite status: completed-Zeile greift die Projektion fail-closed nicht.
9.1.234
  • Ein echter Wire enthielt unter 166 erfolgreichen Werkzeugergebnissen drei große, exakt wiederholte Leseergebnisse für denselben Werkzeugaufruf. Die unveränderte Wiederholung belegte 15.936 Rohbytes, obwohl für die aktuelle Modellsicht nur die neueste volle Kopie gebraucht wird.
  • Die Projektion erkennt deshalb ausschließlich erfolgreiche, reine Textergebnisse mit exakt gleichem Werkzeugnamen, exakt gleichen Argumenten und exakt gleichem Inhalt. Die neueste Kopie bleibt vollständig; ältere Kopien werden nur in der Modellsicht durch einen kurzen Verweis ersetzt.
  • Rohverlauf, geänderte Ergebnisse, Fehler, Medien, persistierte Referenzen und kleine Ergebnisse bleiben unverändert. Die bestehende Werkzeugauslagerung bleibt davor wirksam; die Deduplizierung darf deren Projektion nur für die neueste identische Kopie wiederherstellen.
9.1.233
  • In einem echten Wire wurde ein vollständiger Write-Aufruf mit 2.357 UTF-8-Bytes an der bisherigen 2.048-Byte-Grenze abgewiesen. Danach versprach der Agent zwar die Fortsetzung, überschrieb dieselbe tokenize.cjs aber mehrfach mit unvollständigen Fragmenten, darunter zweimal bytegleich die ersten 1.099 Bytes. Die betroffenen Schritte trugen jeweils rund 64.000 Eingabetokens; einzelne Antworten erreichten 10.319 bzw. 7.015 Tokens.
  • Vollständige Dateien bis 4.096 UTF-8-Bytes dürfen deshalb jetzt in einem atomaren Write-Aufruf geschrieben werden. Der reale 2.357-Byte-Fall braucht keinen zusätzlichen Modellzug mehr.
  • Größere Aufrufe bleiben im vollständigen Fortsetzungsprotokoll. Nach einer solchen Abweisung wird der Pfad verriegelt: kleinere normale Writes können die Zieldatei nicht mehr mit Teilfragmenten überschreiben. Erst eine gültige Fortsetzung übernimmt den Pfad; das Ziel bleibt bis zum finalen Beleg unverändert.
9.1.232
  • Der automatische Modus resume war in einem realen Agentenprofil gesetzt, aber die installierte Fassung lag auf 9.1.221, die aktive vorbereitete Laufzeit auf 9.1.219 und npm/Manifest bereits auf 9.1.231. Ohne laufenden King konnte der bisherige Hintergrundpfad keine verpasste Version vorbereiten.
  • resume und new prüfen deshalb jetzt auch beim nächsten natürlichen Kaltstart auf eine mindestens 30 Minuten stabile, unabhängig signierte Release-Fassung. Sie wird in der geschützten Release-Ablage vorbereitet, als pending vermerkt und ohne zweiten Start oder Auswahlfenster gestartet.
  • manual und off bleiben unverändert. Scheitert Vorbereitung, Integrität, Paketprobe oder Netzabruf, läuft der vorhandene Startpfad weiter. Eine bereits laufende Sitzung wird von diesem Kaltstartpfad niemals beendet.
9.1.231
  • In einem echten Wire scheiterte eine Telegram-Antwort vor dem Versand mit 400: Bad Request: can't parse entities: Can't find end of Italic entity. Der Aufruf hatte ausdrücklich format: markdownv2; 0 von 1 Textteilen wurden zugestellt.
  • Der Telegram-MCP-Versand wiederholt nun nur den betroffenen Textteil genau einmal als Klartext, wenn Telegram exakt einen Entity-Parsingfehler meldet. Chat, Reply-Bezug, Teilgrenze und nachfolgende Anhänge bleiben erhalten.
  • Netzwerkfehler, unbekannte Chats, Rechtefehler und bereits als Klartext gesendete Aufrufe werden von diesem Fallback nicht wiederholt. Dadurch wird weder ein beliebiger Fehler verschluckt noch ein erfolgreicher Teil doppelt gesendet.
9.1.230
  • Nach Ausschluss der bereits mit 9.1.228 und 9.1.229 behobenen historischen Fehler blieben in den letzten 1.200 Werkzeugergebnissen eines Agentenprofils wiederholte Bash-Timeouts als nächster geschlossener Block. Die betroffenen Befehle durchsuchten mehrfach das gesamte Benutzerverzeichnis oder die gesamte Dropbox rekursiv und endeten nach 60 Sekunden ohne nutzbaren Abschluss.
  • Bash weist nun vor dem Prozessstart genau zwei unbeschränkte Suchformen ab: find am ganzen Benutzerverzeichnis und rekursives grep gegen ..
  • Der Fehlertext nennt sofort die begrenzte Alternative: Glob mit verankertem Dateimuster, Grep mit Pfad/Glob oder einen bekannten Projektunterordner. Gezielt auf src, test oder andere benannte Unterbäume begrenzte Suchen bleiben unverändert erlaubt.
  • Der Timeout wurde nicht erhöht und beliebige Bash-Befehle werden nicht automatisch wiederholt. Dadurch entsteht weder eine längere Wartezeit noch das Risiko, einen schreibenden Befehl doppelt auszuführen.
9.1.229
  • Nach der Deferred-Tool-Reparatur war die größte zusammenhängende Fehlerfamilie in einem echten Verlauf das mehrteilige Write: fehlende Pflichtfelder (part, start_line, final), eine vorab falsch geratene Gesamtzeilenzahl, veraltete Teilnummern und ein nach Fehlern noch aktiver alter Fortsetzungsstand erzeugten Wiederholungen ohne Nutzarbeit.
  • Teilnummer, Startzeile und Modus werden nun aus dem tatsächlich gestagten Zustand abgeleitet, wenn sie fehlen. Explizit mitgesendete Werte bleiben sichtbar und werden bei Abweichung weiterhin abgelehnt.
  • expected_lines ist optional und kann erst im finalen Teil geliefert werden. Wenn es gesetzt ist, bleiben Überlauf und exakte Endprüfung unverändert fail-closed.
  • final=true bleibt zwingend für den Abschluss. Ohne diese ausdrückliche Endmarke wird nichts geschrieben; die Zieldatei bleibt bis zum Abschluss unverändert. Die optionale SHA-256-Prüfung bleibt bestehen.
9.1.228
  • In den letzten 1.000 echten Werkzeugergebnissen lagen 66 Fehler. Der größte klar reparierbare Einzelblock waren 10 Tool not found-Fehler: neunmal mcp__mnemo__mem_transcript_recent, einmal mcp__mnemo__mem_question_answer. Beide Werkzeuge waren registriert, aber wegen des Tokenbudgets im betreffenden Schritt nur nicht geladen.
  • Nach einem exakten Fehler Tool "<name>" not found merkt der Turn dieses Schema nun für den unmittelbar folgenden Schritt. Die normale Auswahl nimmt es dann aus der bereits registrierten Werkzeugliste auf.
  • Andere Fehlertexte, erfolgreiche Ergebnisse und abweichende Werkzeugnamen verändern den Zustand nicht. Die bestehende LRU-Grenze von vier Schemata bleibt bestehen; ein wirklich unbekanntes Werkzeug wird dadurch nicht erfunden oder ausgeführt.
  • Es wurde kein Werkzeug permanent in jeden Prompt gelegt. Der normale Schema-Tokenverbrauch bleibt daher unverändert; nur eine bereits bezahlte Fehlwiederholung wird ab dem zweiten Versuch vermieden.
9.1.227
  • Ein realer Wire-Verlauf enthielt 119 ToolSearch-Aufrufe. 35 davon endeten ohne Treffer; 27 Nulltreffer betrafen Telegram-Verlauf, Nachrichtenabruf oder die dazugehörige Erinnerungssuche.
  • 9.1.226 löste mit der aktuellen Werkzeugliste bereits 8 dieser 35 alten Nulltreffer. Der verbleibende Hauptfall waren überbestimmte Anfragen wie +telegram history messages lesen, bei denen das Modell semantische Wörter fälschlich als zwingende Namensbestandteile markiert hatte.
  • Aus DeepAgents wurde das Prinzip übernommen, Werkzeughinweise und Werkzeugoberfläche nach Filterung aufeinander abzustimmen. Es wurde kein fremder Code kopiert: BLUN versucht weiterhin zuerst die exakte und strikte Suche und lockert erst nach einem echten Nulltreffer die +-Begriffe zu semantischen Suchbegriffen.
  • Der Rückfall führt kein Werkzeug aus. Er lädt nur das am besten bewertete Schema beziehungsweise echte Gleichstände, verlangt bei mehreren Begriffen mindestens 75 Prozent Treffer und bleibt bei fachfremden Begriffen geschlossen.
  • Vergleich gegen das frisch installierte 9.1.226-Paket und dieselben 35 historischen Anfragen: vorher 8 Treffer, nachher 21 Treffer, also 13 zusätzliche echte Treffer und 0 verlorene vorherige Treffer.
  • Kein neuer Modell-, Such-, Netzwerk- oder Embedding-Aufruf wurde eingefügt. Rohverlauf, Werkzeugausführung, Freigaben und die permanente Schema-Menge bleiben unverändert.
9.1.226
  • Ein realer Wire-Verlauf enthielt 6.275 abgeschlossene Modellschritte. In den letzten 50 Schritten lagen lokaler Request-Aufbau bei p50 0 ms und p90 1 ms sowie lokaler Stream-Verbrauch bei p50 1 ms und p90 3 ms. Die Wartezeit bis zum ersten Server-Token lag dagegen bei p50 11.842 ms und p90 14.846 ms. Ein weiterer lokaler Mikro-Performance-Schnitt war damit nicht als wirksamer Hebel belegt.
  • Der aus Evolver abgeleitete validierte Lernweg war bereits vorhanden: Red-zu-Grün-Belege werden profilbezogen als pending, recorded oder expired gespeichert. Für Nutzer gab es aber keine lokale Sicht darauf.
  • 9.1.226 fügt /improve mit Alias /learning hinzu. Das Panel zeigt die drei Statuszähler und beim neuesten offenen Kandidaten nur begrenzte, ungefährliche Belegdaten: Kandidaten-ID, Werkzeugname und zwölf Stellen des Kommando-Hashes.
  • Der Befehl liest nur den lokalen Speicher des aktiven Profils. Er startet keinen Modell-, Such-, Hub- oder Embedding-Aufruf und verändert keinen Kandidaten. Unbekannte Statuswerte und unsichere Anzeigezeichen werden verworfen beziehungsweise als unknown dargestellt.
  • Alle neuen UI-Texte für Deutsch, Spanisch, Französisch, Schwedisch und Tschechisch bestanden das verpflichtende Sprach-Gate und die anschließende Receipt-Verifikation; alle sechs UI-Kataloge enthalten die vollständigen Schlüssel.
9.1.225
  • In einem realen Wire-Verlauf belegten 88 config.update-Einträge 4.078.566 Byte. 83 davon trugen den vollständigen Systemprompt.
  • Der Prompt deklarierte einen stabilen Sitzungszeitstempel, setzte ihn aber bei jedem Prozessstart neu. Nach Normalisierung dieses Zeitstempels blieben 45 semantische Varianten und 38 aufeinanderfolgende, nur durch den neuen Zeitstempel verursachte Wiederholungen.
  • Diese 38 Wiederholungen belegten 781.179 Byte, also 19,16 Prozent aller Systemprompt-Bytes in den gemessenen Konfigurationsereignissen. Gleichzeitig wurde der wiederverwendbare Provider-Promptpräfix nach Neustarts unnötig verändert.
  • 9.1.225 bindet den Zeitstempel bei frischen und wiederaufgenommenen Haupt- und Unteragenten an Session.metadata.createdAt. Ungültige alte Metadaten fallen defensiv auf den bisherigen In-Memory-Wert zurück.
  • Rohverlauf, Promptinhalt, Werkzeuge, Modellwahl und Kompaktierung bleiben unverändert. Es gibt keinen zusätzlichen Modell-, Such- oder Embedding-Aufruf.
9.1.224
  • Der zuletzt gemessene Start brauchte für die parallele Initialisierung von fünf MCP-Servern 16,85 Sekunden. Sitzungswiederaufnahme und Wire-Parse waren mit rund 0,55 beziehungsweise 0,18 Sekunden deutlich kleiner.
  • Der Turn-Pfad wartete bisher vor jeder Anfrage auf diese MCP-Initialisierung, auch wenn eine lokale reine Begrüßung danach absichtlich null Werkzeuge in die Modellanfrage bekam.
  • 9.1.224 übernimmt die bedarfsgeladene Werkzeuggrenze aus dem DeepAgents-Abgleich: Nur lokale, werkzeugfreie Kurzkonversation darf sofort antworten. Telegram-Züge, Anhänge, Systemauslöser und jede arbeitsartige Anfrage warten weiterhin auf die vollständige MCP-Initialisierung.
  • Der Rohverlauf, die MCP-Konfiguration, Werkzeugschemas und normale Arbeitszüge bleiben unverändert. Es wurde kein Server deaktiviert und kein zusätzlicher Modell-, Such- oder Embedding-Aufruf eingeführt.
9.1.223
  • Ein Schritt 775.5 endete leer mit fall=length, 8.192 von 8.192 Completion-Token und nur sieben Zeichen Reasoning. Die bisherige Logik startete darauf denselben großen Request erneut und verdoppelte das Completion-Budget auf 16.384 Token.
  • Lokale CPU lag während der Wartezeit bei ungefähr 0 Prozent; Request-Bau dauerte 0-1 ms und der Transport ungefähr zwei Sekunden. Der gemessene Engpass war damit Modellgenerierung plus Vollbudget-Retry, nicht die TUI.
  • Nur der belegte Fall length + voll ausgeschöpftes Budget + weniger als 64 Zeichen Reasoning erhält jetzt einen sparsamen Wiederholungsversuch mit Faktor 0,125 und mindestens 1.024 Token.
  • Reasoning-lastige und nicht voll ausgeschöpfte length-Antworten behalten die bisherige Erweiterung mit Faktor 2. Andere Retry-Klassen bleiben unverändert.
  • Für einen gemessenen Fall sinkt das zweite Budget von 16.384 auf 1.024: 15.360 Token beziehungsweise 93,75 Prozent weniger im Wiederholungsversuch.
9.1.222
  • Der laufende Updater hatte eine vorbereitete Version per IPC an den aktiven King übergeben. Der Launcher beendete daraufhin den laufenden Core mit Exit 76 und sollte einen Ersatzprozess starten. Beim gemessenen Wechsel auf 9.1.219 blieb ein Agentenprofil dadurch ausgeloggt.
  • Hintergrundupdates laden und prüfen die neue Version nun nur noch und hinterlegen sie für den nächsten natürlichen Start. Sie senden keine Restart-IPC-Nachricht, beenden keine aktive TUI und starten keinen Ersatzprozess.
  • Beim nächsten normalen king-Start erscheint wieder die bestehende Auswahl: aktualisieren, einmal überspringen oder bis zum nächsten Release warten. Nur nach der Installationsentscheidung startet der Launcher aus dem bereits verifizierten vorbereiteten Paket; ein zweiter Download entfällt.
9.1.221
  • Unveränderte, noch nicht in tokenCount abgedeckte Nachrichten verwenden nun genau eine Token-Schätzung je Kontextrevision. Wiederholte Status- und Renderzugriffe scannen denselben wachsenden Verlauf nicht erneut.
  • Neue Textteile, Werkzeugaufrufe, History-Änderungen, Verdichtung, Undo und eine geänderte Zahl bereits abgedeckter Nachrichten invalidieren den Cache sofort. Rohverlauf, persistierter Verlauf und gemeldeter Tokenwert bleiben gegenüber dem bisherigen Pfad identisch.
  • Sieben Messläufe mit 300 synthetischen Nachrichten und jeweils 250 unveränderten Abfragen ergaben im Median 42,1218 ms -> 0,1755 ms, rund 99,583 % weniger Rechenzeit in diesem Hotpath. Beide Fassungen lieferten exakt denselben Schätzwert von 127.838 Token.
  • Der Release senkt CPU-Arbeit für die lokale Schätzung. Er behauptet keine Senkung der tatsächlich an das Modell gesendeten Input-Token.
9.1.220
  • Die Projektion langer Assistant-Antworten speichert ihr Ergebnis nun in einer WeakMap, solange Nachrichtenobjekt, Content-Array, Text-Part und exakter Quelltext unverändert bleiben. Rohverlauf und projizierter Inhalt bleiben gegenüber dem bisherigen Pfad identisch.
  • Eine Änderung am Text, Content-Array oder Text-Part verwirft den Eintrag sofort. Verschiedene Nachrichtenobjekte teilen keinen Cache.
  • Fünf Messläufe mit jeweils 1000 Wiederholungsprojektionen ergaben im Median 16,489 ms -> 0,202 ms, rund 98,8 % weniger Rechenzeit in diesem Pfad. Beide Fassungen sparten dabei exakt 21.206 Zeichen.
9.1.219
  • Reine kurze Textbestätigungen wie ok, danke oder Telegram-DM-Antworten mit nachgestelltem Weiter-Signal lesen den Store für validierte Lernkandidaten nicht mehr bei jedem Modellschritt.
  • Bedeutungsvolle Prompts, Anhänge und Turns mit aktueller Werkzeugaktivität synchronisieren weiterhin. Eine bereits sichtbare Lern-Erinnerung bleibt auch während einer übersprungenen Bestätigung erhalten.
  • Die gepackte Ist-Messung über 50 Bestätigungen sank von 50 auf 0 Kandidaten-Verzeichnislesungen. Die bedeutungsvolle Gegenprobe las exakt einmal. Es kam kein Modell-, Embedding- oder Netzwerkaufruf hinzu.
9.1.218
  • Derselbe Rot-zu-Grün-Check erzeugte in 9.1.217 bei einer Wiederholung mit neuen Tool-Call-IDs einen zweiten offenen Kandidaten. Die isolierte Ist-Messung ergab zwei IDs, 2 offene Dateien und 726 Byte.
  • Nach dem Aufzeichnen nur des neuesten Kandidaten wäre der ältere identische Kandidat erneut als Erinnerung erschienen. Das hätte einen zweiten Reminder- und MistakeRecord-Zyklus für dieselbe offene Lektion erzeugt.
  • bin/validated-learning-signal.cjs verwendet nun einen bereits offenen Kandidaten desselben Profils und desselben commandHash erneut. Andere Verifikationsbefehle bleiben getrennt; aufgezeichnete oder abgelaufene Kandidaten absorbieren kein späteres Ereignis.
  • Die Nachmessung ergab dieselbe ID, 1 offene Datei und 363 Byte. Es gibt keinen zusätzlichen Modell-, Embedding- oder Netzwerkaufruf.
9.1.217
  • In 9.1.216 markierte jeder erfolgreiche MistakeRecord den neuesten offenen Lernkandidaten als verarbeitet, auch wenn der Eintrag zu einem anderen Fehler gehörte. Der Nachweis war damit dauerhaft, aber nicht exakt mit seiner späteren Aufzeichnung korreliert.
  • bin/validated-learning-signal.cjs liest nun die optionale candidateId eines erfolgreichen MistakeRecord und schließt ausschließlich den exakt passenden offenen Kandidaten. Eine fehlende, falsche oder fremde ID lässt alle offenen Kandidaten unverändert.
  • blun.mjs nennt die stabile Kandidaten-ID in der sichtbaren Erinnerung und führt candidateId als optionales Feld im MistakeRecord-Schema. Es gibt keinen zusätzlichen Modell-, Embedding- oder Netzwerkaufruf.
  • Die Korrelation bleibt profilgebunden. Im Kandidatenspeicher landen weiterhin weder rohe Befehle noch Werkzeugausgaben.
9.1.216
  • bin/validated-learning-signal.cjs legt bestätigte Rot-zu-Grün-Signale jetzt installationsweit unter <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/ ab. Dadurch bleibt ein Lernkandidat über Nutzerzüge, Verdichtungen und verschiedene Portale derselben BLUN-Installation erhalten.
  • Der Speicher ist profilgebunden, append-only und konkurrierend sicher: je Kandidat entsteht eine unveränderliche JSON-Datei und genau ein .recorded- oder .expired-Marker. Temp-Datei, Hardlink und Entfernen der Temp-Datei verhindern stilles Überschreiben bei parallelen Schreibern.
  • Gespeichert werden nur Typ, Status, Profil, Werkzeugname, SHA256 des Befehls, Werkzeugaufruf-IDs und Zeitstempel. Roher Befehl, Fehlertext und erfolgreicher Werkzeugoutput werden nicht persistiert.
  • Ein erfolgreicher MistakeRecord markiert den neuesten offenen Kandidaten genau einmal als verarbeitet. Offene Kandidaten verfallen nach 24 Stunden. Fehlt ein gemeinsames Home, bleibt das bisherige In-Memory-Verhalten fail-open erhalten.
  • Das ist noch keine automatische Codeänderung und keine selbst erteilte Freigabe. Der Release schafft nur den portablen, portalunabhängigen Lernnachweis, auf dem spätere eingebaute Evaluator- und Approval-Funktionen sicher arbeiten können.
9.1.215
  • Lösungen dürfen weder bestimmte interne Agenten noch interne Rechnernamen, Telegram- Gruppen, Mnemo-Instanzen oder eine BLUN-interne Freigabekette voraussetzen.
  • Für Self-Improvement werden die internen Rollen als Produktfunktionen abstrahiert: Scope-/Freigabe-Controller, isolierter Evaluator, versionierter Nachweis und automatische Canary-Rückmessung mit Rollback.
  • Automatisch übernehmbar sind nur niedrig-riskante, messbar begrenzte Anpassungen bei durchweg besseren oder neutralen Proben. Code, Rechte, Secrets, Abrechnung und Produktion bleiben nutzer- oder adminpflichtig.
  • Die erste Umsetzung des eingebauten Gates wird intern manuell abgenommen; danach darf das Gate selbst prüfen, aber nicht seine eigene Sicherheits- grenze verändern.
9.1.214
  • 9.1.213 stellte den richtigen dauerhaften Speicherweg über MistakeRecord her, erwartete aber weiterhin, dass das Modell den passenden Moment allein aus der Werkzeughistorie erkennt.
  • Neu ist bin/validated-learning-signal.cjs: Das Modul betrachtet nur den aktuellen Nutzerzug und erkennt ausschließlich denselben verifizierenden Shell-Befehl, der zuerst fehlschlägt und später erfolgreich ist.
  • Ein dynamischer Injector in blun.mjs erinnert in diesem belegten Fall daran, eine wiederverwendbare Lehre mit MistakeRecord festzuhalten. Befehlstext und Rohfehler werden nicht in den Hinweis kopiert.
  • Andere Befehle, normale Lese-/Werkzeugfehler, ein neuer Nutzerzug oder ein bereits erfolgreicher MistakeRecord-Aufruf erzeugen beziehungsweise behalten keinen Hinweis. Es findet keine automatische Speicherung statt.
9.1.213
  • Der Missionsvertrag verlangte nach einer erfolgreichen Rot-zu-Grün-Probe den Aufruf record_error_memory. Dieses Werkzeug existiert im King-Paket nicht. Der vorhandene dauerhafte Lernweg heißt MistakeRecord und schreibt in die gemeinsame Mistake.md.
  • Dadurch war die Disziplin aus Evolver bereits formuliert, aber der letzte Schritt zu unserem eigenen, agentenübergreifenden Gedächtnis tot: Eine bestätigte Lösung konnte dem Vertrag folgen und trotzdem nicht dauerhaft gespeichert werden.
  • Der Vertrag ruft nun nach dem grünen Wiederholungslauf MistakeRecord auf. Rohfehler bleiben weiterhin draußen; gespeichert wird erst die durch einen erfolgreichen Gegenlauf bestätigte Lehre.
  • Mistake.md, ihre Relevanzauswahl und ihr Speicherformat wurden nicht ersetzt oder verändert. Repariert wurde ausschließlich die Verbindung vom validierten Lernvertrag zum vorhandenen Werkzeug.
  • Geändert wurden nur blun.mjs, der neue Strukturtest test/validated-learning-route.test.js und die Version in package.json.
9.1.212
  • Der ErrorMemory-Injektor formatierte auch für reine Begrüßungen und kurze Bestätigungen mehrere Strategie-Gene. Mistake.md und das persönliche Gedächtnis hatten für dieselbe Nachrichtenklasse bereits eine gemeinsame Relevanzgrenze; nur ErrorMemory umging sie.
  • Der Injektor verwendet nun ebenfalls isLowInformationMistakeTurn und beendet die Projektion vor Auswahl und Formatierung der Strategie-Gene. Persistierte Fehler- und Strategieeinträge bleiben unverändert; nur ihre unnötige Projektion in Kleinstanfragen entfällt.
  • Gemessener Referenzfall Wie geht es dir? mit elf gespeicherten Einträgen: vorher fünf ausgewählte Regeln, 1.417 Zeichen beziehungsweise rund 355 Token; danach 0 Zeichen und 0 Token.
  • Geändert wurden nur blun.mjs, test/error-memory-performance-policy.test.js und die Version in package.json.
9.1.211
  • Der King quittiert Queue-Zeilen erst, wenn die Nachricht angenommen wurde. Vor einer aktiven Session verwirft injectChannelEnvelope eine adressierte Nachricht jedoch als dropped, ohne sie zu quittieren oder zu parken. Damit kann der Checkpoint dauerhaft an genau dieser ersten Zeile stehenbleiben.
  • Echte Rotprobe _proof/telegram-profile-checkpoint-red.cjs: erwartet queued, gemessen dropped, Exit 1.
  • Derselbe Fehler liegt im Telegram-Befehlspfad: /loop vor aktiver Session wird nicht in queuedMessages gelegt; die Acknowledge-Funktion bleibt ohne Verbraucher. Echte Rotprobe _proof/telegram-remote-command-presession-red.cjs: erwartet Queue-Länge 1, gemessen 0, Exit 1.
  • injectChannelEnvelope behandelt eine noch nicht lieferfähige Session nun wie eine beschäftigte Session: Modelltext, Anzeigeursprung und spätere Quittung bleiben in der vorhandenen Channel-Warteschlange erhalten.
  • injectTelegramRemoteCommand baut den Queue-Eintrag vor der Sessionprüfung. /loop und die anderen direkten Telegram-Befehle werden bei fehlender Session mit ihrer channelAcknowledge-Funktion geparkt und erst an der vorhandenen sicheren Grenze ausgeführt.
  • Die Reihenfolge und die bestehende Checkpoint-Regel bleiben unverändert: Eine Queue-Zeile wird erst nach Annahme quittiert; spätere Quittungen können eine davor noch offene Zeile nicht überspringen.
9.1.210
  • Der aktive Handoff aus 9.1.208/9.1.209 konnte einen laufenden King für ein Update beenden. Auf dem MSI wurde dadurch die laufende Sitzung beim Wechsel 9.1.206 -> 9.1.207 beendet und nicht automatisch neu aufgenommen.
  • 9.1.209 wurde deshalb nicht in das öffentliche Manifest aufgenommen und auf npm als nicht ausrollbar markiert.
  • Die Vorgabe ist jetzt technisch erzwungen: Ein automatisches Update darf den laufenden King nie beenden. Es wird nur geladen und als pending vorgemerkt. Aktivierung erfolgt erst bei einem späteren normalen Start.
9.1.209 Zurückgezogen
  • Nicht veröffentlicht. Der aktive Update-Handoff konnte einen laufenden King beenden; deshalb kam die Version nicht ins öffentliche Manifest und wurde auf npm als nicht ausrollbar markiert.
9.1.208
  • Auf dem MSI wurden 27 King-Starts und 15 Versionsstände an einem Tag gemessen. Die Neustarts fielen jeweils mit Versionssprüngen zusammen; ein eigener Exit-Grund wird im dortigen Log weiterhin nicht protokolliert.
  • Der Updater bereitete neue Manifest-Versionen im Minutentakt vor. Version 9.1.208 führt deshalb ein 30-Minuten-Ruhefenster ein, bevor eine weitere neue Runtime aktiviert werden darf.
  • Alte Runtime-Stände werden nach erfolgreicher Aktivierung auf die neuesten drei Versionen begrenzt. Gelöscht wird nur, wenn alle Installations-Leases des alten Standes exklusiv erworben wurden. Aktive, belegte oder unbekannte Layouts bleiben unangetastet.
  • Die Schutzlogik lebt auch im neu geladenen Core. Damit greift sie nach der automatischen Aktivierung selbst dann, wenn der dauerhafte Eltern-Launcher noch aus einer älteren Version stammt.
  • Die acht gemessenen MSI-Release-Stände belegten zusammen nur 778 MB. Sie erklären die fast vollständige 454-GB-Platte nicht; der große Verbraucher bleibt ein separater offener Befund.
9.1.207
  • Wiederholungen fehlgeschlagener Telemetrie werden pro Durchlauf auf die 16 ältesten Dateien begrenzt und stoppen beim ersten vorübergehenden Serverfehler, statt den gesamten Rückstau weiter abzuarbeiten.
  • Der Fehlerspool behält die neuesten 512 Dateien innerhalb von 16 MiB und sieben Tagen. Die normale events.jsonl ist von der Bereinigung ausdrücklich ausgeschlossen.
  • Vor dem Release lagen real 4.248 Fehlerdateien mit 11.631.974 Byte. Nach automatischer Aktivierung lagen 512 Dateien mit 2.260.908 Byte: 3.736 alte Fehlerdateien und rund 9,37 MB Last weniger.
9.1.206
  • Bereits archivierte große Assistentenantworten werden jetzt vor der Schleifenprojektion durch ihren begrenzten, wieder einlesbaren Archivverweis ersetzt. Damit kann eine nachfolgende Textbereinigung den gespeicherten Hash nicht mehr ungültig machen.
  • Drei reale Archivdateien wurden bytegenau gegen ihre gespeicherten SHA256- Nachrichtenhashes geprüft: 38.567, 13.941 und 24.787 Zeichen, alle vorhanden und alle exakt passend.
  • Auf exakt denselben 41.480 Wire-Einträgen mit 311 Nachrichten sank die Modellprojektion von 87.724 auf 63.234 Zeichen: weitere 24.490 Zeichen beziehungsweise rund 6.123 Eingabetoken weniger pro betroffenem Aufruf.
  • Rohe Historie und vollständige private Archivdateien bleiben unverändert und über ihren Pfad seitenweise lesbar.
9.1.205
  • Antwortschleifen innerhalb einer Assistentennachricht werden jetzt auch bei kleinen Satzzeichen- oder Wortlautunterschieden erkannt. Ein Cluster braucht mindestens drei Treffer bei konservativer Ähnlichkeit 0,88; die erste Fassung bleibt erhalten, die rohe Historie wird nicht verändert.
  • In einem konservierten Fall sank eine reale Schleifenantwort von 24.787 auf 22.711 Zeichen: 2.076 Zeichen beziehungsweise rund 519 Eingabetoken weniger.
  • Codezäune bleiben bytegleich geschützt. Werkzeugnarration, Injektionen, Zweierpaare und Einsparungen unter 1.000 Zeichen bleiben unverändert.
9.1.204
  • Die Fehlererinnerung lädt pro Arbeitsrunde nicht mehr blind alle elf Regeln. Die vier unverzichtbaren Beweis- und Gegenprobenregeln 4, 9, 10 und 11 bleiben immer aktiv; höchstens zwei weitere Regeln werden deterministisch passend zum aktuellen Auftrag ergänzt.
  • In der echten ausgelieferten Regelsammlung sank der wiederholte Block von 2.442 auf 1.272 Zeichen: 1.170 Zeichen beziehungsweise rund 293 Eingabetoken weniger pro betroffener Arbeitsrunde.
  • Die Auswahl erzeugt keine Modell-, Such-, Reranker- oder Embedding-Anfrage. Kleine eigene Regelsammlungen bleiben vollständig; bei einem Selektorfehler greift weiterhin der vorherige Vollblock.
9.1.203
  • Eine leere ToolSearch ist jetzt ein erfolgreich abgeschlossenes Nullergebnis statt eines roten Werkzeugfehlers. Die Antwort nennt das fehlende berechtigte Werkzeug und untersagt eine Wiederholung mit Synonymen.
  • Im gemessenen Verlauf standen 32 leere Suchen mit 29 Formulierungen; in einem konservierten Zug wurde dieselbe fehlende Telegram-Fähigkeit nach dem roten Fehler direkt mit einer zweiten Suche erneut angefragt.
  • Keine zusätzliche Modell-, Reranker- oder Embedding-Anfrage, kein neues residentes Schema und keine Änderung an Werkzeugen oder Berechtigungen.
9.1.202
  • Die aus DeepAgents abgeleitete lokale Kontextprojektion zeigt bei großen Arbeitsverzeichnissen bevorzugt Top-Level-Einträge statt tiefer Details aus den ersten wenigen Ordnern. Kleine Verzeichnislisten bleiben bytegleich.
  • Ein Agenten-Root enthält 509 Top-Level-Einträge (89 Ordner, 420 Dateien). Vorher zeigte die Modellprojektion in 1.981 Zeichen nur 9 Top-Level-Ordner; jetzt zeigt sie 30 in 832 Zeichen.
  • Gemessene Einsparung: 1.149 Zeichen bzw. etwa 287 Token je Anfrage. Persona, Arbeitsregeln, Rohhistorie und Werkzeugzugriff bleiben unverändert.
9.1.201
  • Eine aus DeepAgents abgeleitete Projektionshygiene verdichtet das statische Fehlergedächtnis, ohne eine der 11 gespeicherten Regeln oder Prüfungen zu verlieren.
  • Alte ausführliche Fehlergedächtnis-Texte werden nur in der Modellprojektion verdichtet. Rohhistorie, normale Antworten und Werkzeugergebnisse bleiben unverändert.
  • In der Projektion bleibt jeweils nur die neueste Fehler- und Fehlerkorrektur-Einspeisung erhalten.
9.1.200
  • Der neue lokale Befehl /context zeigt getrennt die tatsächlich projizierte Modellanfrage, den gespeicherten Gesprächsverlauf, Werkzeugschemas, das Verdichtungsbudget und den verbleibenden Spielraum.
  • Die Ansicht liest ausschließlich session.getContext(). Sie startet keine Modellanfrage, keine verwaltete Verbrauchsabfrage, keinen Dienst und keinen Neustart.
  • Ausgelagerte Werkzeugergebnisse nennen jetzt einen exakten Wiederleseweg: Read mit höchstens 20 Zeilen und anschließend fortgesetztem line_offset. Das verhindert die gemessene Form, in der ein Agent denselben großen Bereich erneut mit Read, Grep und Bash anforderte.
  • /premortem war bereits vor 9.1.200 vorhanden und wird ausdrücklich nicht als neue Funktion dieses Releases verkauft.
  • Für neue Übersetzungen gab das verpflichtende Sprach-Gate wegen fehlender unabhängiger Kurztextprüfung keine Freigabe. Deshalb verwendet /context nur bereits freigegebene lokalisierte Bezeichnungen; kein ungeprüfter Zieltext wurde aufgenommen.
9.1.199
  • Eine aktuelle Modellsicht enthielt in einer einzelnen Assistentenantwort 13.941 Zeichen mit 100 Absatzblöcken. Nur 20 Blöcke waren eindeutig; sechs Gruppen wiederholten sich exakt und belegten 9.579 Zeichen.
  • 9.1.199 verdichtet ausschließlich solche exakten Wiederholungen innerhalb einer einzelnen reinen Textantwort in der Modellsicht. Der rohe Sitzungsverlauf bleibt unverändert.
  • Die Verdichtung greift erst ab drei exakten Wiederholungen und mindestens 1.000 eingesparten Zeichen. Codeblöcke, gemischte Inhalte, Werkzeugaufrufe, Injektionsnachrichten, kurze Blöcke und kleinere Einsparungen bleiben unverändert.
  • Das folgt dem DeepAgents-Grundsatz, wiederlesbare Wahrheit zu erhalten und nur die aktive Modellsicht zu entlasten. Es gibt keinen zusätzlichen Modell- oder Embedding-Aufruf.
9.1.198
  • Ein aktueller Verlauf enthielt ein bereits vom Werkzeug als truncated: true markiertes Grep-Ergebnis mit 50.042 Zeichen. Die Einzelresultat-Auslagerung erkannte zwar die Größe, ließ solche Ergebnisse aber durch eine frühe Rückgabe trotzdem vollständig in der Modellsicht.
  • 9.1.198 entfernt ausschließlich diese Ausnahme. Ein abgeschnittenes Read verwendet den vorhandenen Quellpfad ohne Duplikat; andere abgeschnittene Ergebnisse archivieren exakt den vollständigen vom Werkzeug zurückgegebenen Text.
  • Der Verweis behält truncated: true und trägt stored_result_scope: tool_truncated_output. Damit wird nicht behauptet, dass rohe Ausgabe wiederhergestellt wurde, die das Werkzeug nie geliefert hat.
  • Das Muster folgt DeepAgents: große Werkzeugausgaben bleiben wiederlesbar außerhalb der aktiven Modellsicht, während dort nur ein kleiner Verweis verbleibt.
9.1.197
  • Auch reine Textbestätigungen wie ok luden bisher die dynamische Mistake.md-Erinnerung. Am aktuellen gemeinsamen Regelbestand waren das 1.819 Promptzeichen, ungefähr 455 Token, obwohl kein Arbeitskontext fortgesetzt wurde.
  • 9.1.197 erkennt ausschließlich informationsarme reine Textzüge, bevor eine der beiden Mistake-Quellen gelesen wird, und lässt dort die dynamische Injektion weg.
  • Anhänge, nichttextuelle Inhalte und sinnvolle Fortsetzungen wie ok, check updater behalten den bisherigen Weg. Der bestehende Relevanz-Fallback für echte Arbeitszüge bleibt unverändert.
  • Das Muster stammt aus der AnythingLLM-Vergleichsarbeit: optionale Kontextquellen sollen nur dann in die Modellsicht gelangen, wenn der aktuelle Zug sie tatsächlich braucht. Es wurde ohne zusätzlichen Modell- oder Embedding-Aufruf in die bestehende BLUN-Policy eingepasst.
9.1.196
  • /reload war lokal vorhanden, wurde aus Telegram aber nicht als direkter Befehl erkannt. Die Telegram-Allowlist enthielt den Namen nicht; dadurch blieb die Nachricht normaler Modelltext.
  • 9.1.196 fügt ausschließlich reload zur bestehenden adressierten Telegram-Befehlsliste hinzu.
  • Der Telegram-Weg verwendet denselben vorhandenen Handler wie die lokale TUI: Sitzung, MCP-Server, Runtime- und TUI-Konfiguration werden im laufenden Prozess neu geladen. Es wird keine Modellrunde und kein Prozessneustart gestartet.
  • /new und andere nicht freigegebene Slash-Nachrichten bleiben weiterhin normaler Modelltext.
9.1.195
  • Automatische Updates wurden ausgeführt, die neu gestartete TUI landete aber auf C:\ statt im bisherigen Projektordner.
  • Die TUI führte den richtigen Ordner in state.appState.workDir, übergab beim Update-Handoff aber nur Sitzung, Version und Modus. Der Launcher nutzte deshalb seinen ursprünglichen Startordner für Ziel und Rückfall.
  • 9.1.195 transportiert den aktiven Projektordner im Handoff und verwendet ihn für Zielversion, Rückfall und weitere automatische Updates derselben Aufsicht.
  • Nur vorhandene absolute Verzeichnisse werden akzeptiert. Relative, fehlende oder auf Dateien zeigende Angaben fallen auf den Launcher-Ordner zurück.
9.1.194
  • Der bestehende Turn-Watchdog warnte nach 20 Minuten, beendete einen Zug danach aber nicht. Auf dem Mac lief ein festgefahrener Zug nach der 30-Minuten-Warnung bis mindestens Minute 39 weiter.
  • 9.1.194 behält die Warnung nach 20 Minuten und beendet einen Zug nach 30 Minuten ohne echten Fortschritt.
  • Schrittbeginn, Thinking-Text, Assistententext, Werkzeugaufruf, Werkzeugargumente, Werkzeugfortschritt und Werkzeugergebnis setzen die Inaktivitätsfrist zurück. Lange aktive Arbeit wird dadurch nicht beendet.
  • Der vorhandene Abbruch nach fünf identischen fehlgeschlagenen Werkzeugaufrufen bleibt getrennt und unverändert aktiv.
9.1.193
  • Mehrere Telegram-Zustellungen kamen mit identischer chat_id und message_id bis zu viermal in derselben Sitzung an.
  • 9.1.181 entfernte diese Wiederholungen erst später aus der Modellsicht. Vorher konnte jede Kopie bereits einen eigenen Modellzug und damit Kosten auslösen.
  • 9.1.193 führt deshalb vor dem Turn-Start ein auf 2.048 Kennungen begrenztes Zustellungsledger. Dieselbe Telegram-Kennung wird pro Sitzung nur einmal angenommen; Wiederholungen werden bestätigt, aber nicht protokolliert und starten keinen Anbieterzug.
  • Neue Nachrichtenkennungen, Nicht-Nutzer-Injektionen und der rohe Verlauf bleiben unverändert. Beim Fortsetzen wird das Ledger aus den angenommenen Prompt-Datensätzen wiederhergestellt.
9.1.192
  • Ein Mac zeigte nach einer abgelehnten Bash-Freigabe weiterhin King is thinking für 39 Minuten. Der Werkzeugaufruf selbst war korrekt abgewiesen, aber die Ablehnung wurde als gewöhnliches Fehlerergebnis an die laufende Modellschleife zurückgegeben.
  • PermissionManager.requestToolApproval() lieferte bei Ablehnung nur block: true. Die vorhandene Batch- und Provider-Steuerung konnte den Zug bereits mit syntheticResult.stopTurn = true beenden, erhielt dieses Signal aber nicht.
  • Neu ist bin/approval-rejection-stop.cjs. Abgelehnte und abgebrochene Freigaben erzeugen jetzt ein vorhandenes Fehlerresultat mit stopTurn: true. Der aktuelle Zug endet, und spätere Aufrufe desselben Werkzeugstapels werden übersprungen. Freigabeprotokoll, Policy und Fail-Closed-Verhalten bleiben unverändert.
  • DeepAgents bestätigte die explizite menschliche Interrupt-Grenze als geeignetes Muster. AnythingLLM und Evolver boten für diesen engen Fehler keinen stärkeren Mechanismus als den bereits vorhandenen BLUN-Vertrag.
9.1.191
  • DeepAgents bietet mit /context eine vertraute, sichtbare Aufteilung des Kontextfensters statt nur eines Gesamtwerts.
  • Evolver fordert für Leistungsarbeit ein getrenntes Promptbudget für Systemanteil, Gespräch, Werkzeuge und freien Raum.
  • AnythingLLM spart Werkzeugschemas durch Embedding-basiertes Reranking. BLUN besitzt dafür bereits den günstigeren Deferred-Tool-Weg ohne zusätzlichen Modell- oder Embedding-Aufruf; dieser Teil wurde deshalb nicht gedoppelt.
9.1.190
  • Aus dauerhaft gespeicherten tool.call-Loop-Ereignissen werden nur die Anzeige-Felder display und description entfernt. Identität, Werkzeugname, Argumente und Schrittzuordnung bleiben erhalten.
  • Die Laufzeit verarbeitet weiterhin das vollständige Ereignis. TUI-Anzeige, Werkzeugausführung und Wiederaufnahme wurden nicht auf die Projektion umgestellt.
  • Ein echter Agenten-Wire mit 42.451.368 Byte enthielt 6.135 Tool-Aufrufe. Bei 5.679 davon konnten 3.125.874 Byte entfallen: 7,36 % des gesamten Wire-Protokolls.
9.1.189
  • Ein Nutzer hatte Bosnisch gewählt und auf Bosnisch geschrieben, King antwortete aber auf Slowenisch. Im Persona-Prompt stand nur das englische Wort Bosnian; der eng verwandte Sprachraum war nicht ausdrücklich abgegrenzt.
  • Kako si?, Kako je King?, Ko si ti? und Ko stoji iza tebe? liefen nicht als eigenständige bosnische Kurzdialoge. Der Screenshot zu Ko stoji iza tebe? zeigte sogar Websuchen statt einer direkten Antwort.
  • Der gemeldete einfache Check-in verbrauchte etwa 7.500 Token. Der bisherige Low-Effort-Pfad erlaubte bis zu 8.192 Abschluss-Token und behielt mehrere alte Nachrichten.
9.1.188
  • BLUN erkannte einen realen Rückfall bereits nach drei ähnlichen Antworten, ließ die veralteten Antworten aber vollständig in der Modellsicht. Der Hinweis gegen die Schleife konkurrierte deshalb weiter mit dem alten falschen Zustand.
  • DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 liefert das Muster indexstabiler, begrenzter Ersatzmeldungen. AnythingLLM priorisiert die jüngsten Gesprächspaare und behandelt Historie als zuerst komprimierbaren Kontext.
  • Ein Wire enthielt 42.265.671 Byte, davon 25.423.100 Byte context.append_loop_event. Das belegt die reale Loop-Last, wird aber nicht als direkte Anfrage-Tokenersparnis ausgegeben.
9.1.187
  • Das live ausgelieferte 9.1.184-Manifest trug den Zeitstempel 2026-08-26T12:15:06.5196457Z. Der ausgelieferte Parser erlaubte nur ein bis drei Nachkommastellen und verwarf deshalb das gesamte Manifest.
  • Ohne gültiges Fallback wurde npm allein maßgeblich. Beim Staging von 9.1.185 war der npm-Tag deshalb kurz sichtbar, obwohl das Manifest noch auf 9.1.184 stand.
  • Der npm-Tag wurde auf 9.1.184 zurückgestellt. Das Live-Manifest wurde nur im Zeitstempel auf 2026-08-26T12:15:06.519Z korrigiert; Version und Integrität blieben unverändert. Drei cachebereinigte Abrufe und der echte Clientparser bestätigten danach das Manifest.
  • Live-SHA256 nach der Reparatur: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Sicherung: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • Nach einer Vollkompaktierung wird der bestehende System-Prompt nicht mehr mit neu gelesenen lokalen Kontextdaten überschrieben. Sein bisheriger Präfix bleibt dadurch byte-stabil und für den Provider-Cache wiederverwendbar.
  • Arbeitsverzeichnis, passende AGENTS.md-Dateien und zusätzliche Verzeichnisse erhalten einen Fingerprint. Nur bei einer echten Änderung wird der neue Stand als interne, für den Nutzer unsichtbare Kontextnachricht angehängt.
  • Eingebettete Kontextdaten werden vor der internen Markierung escaped. Ein lokaler Text kann die Markierungsgrenze daher nicht schließen oder neue Systemhinweise einschleusen.
9.1.185
  • Zwei Agentenprofile meldeten sich im zeitlichen Umfeld des automatischen Updates ab. Unabhängig davon blieb ein drittes Profil nach einem erfolgreichen Übergang von 9.1.182 auf 9.1.183 auf dieser Fassung stehen und bereitete 9.1.184 nicht vor.
  • Zwei konkrete Fehler wurden im Quellpfad belegt: Die TUI beendete sich direkt nach process.send, ohne die IPC-Bestätigung abzuwarten. Außerdem wartete der Launcher nach einem erfolgreichen Handoff nur auf das Ende des neuen Prozesses und richtete für ihn keine weitere Update-Überwachung ein.
9.1.184
  • Gewöhnliche Modellaufrufe führten die Werkzeugschemas für GenerateImage und GenerateVideo dauerhaft mit, obwohl die gemessene Werkzeugnutzung nur einen Bildaufruf und keinen Videoaufruf unter 3.183 Aufrufen enthielt.
  • 9.1.184 entfernt beide Schemas aus dem ständig geladenen Kernsatz. Ein ausdrücklicher Bild-, Video- oder Animationsauftrag lädt nur das tatsächlich benötigte Schema im selben Zug.
  • Derselbe Auswahlweg greift auch, wenn ein Medienauftrag während eines laufenden Zugs eingeht. Qualitätsfragen, Medienprüfungen und unverbindliche Ideen für später laden kein Erzeugungsschema.
  • Beide Werkzeuge bleiben über ToolSearch verfügbar. Die Änderung entfernt keine Fähigkeit, sondern verlagert selten benötigte Schemas aus gewöhnlichen Modellaufrufen.
9.1.183
  • BLUN King 9.1.183 macht die automatische Telegram-Zustellung fertiger Medien widerstandsfähig gegen vorübergehende Uploadfehler.
  • Der Client wiederholt ausschließlich eine begrenzte Zahl vorübergehender Fehler, baut den mehrteiligen Upload bei jedem Versuch neu auf und bricht bei dauerhaften Fehlern sofort ab.
  • Ausgeschöpfte Zustellversuche werden getrennt protokolliert, ohne das Bot-Token offenzulegen oder den normalen Rückfallversand zu unterdrücken.
9.1.182
  • Dieser Release korrigiert ausschließlich die automatische Aktualisierung einer laufenden King-Sitzung.
  • Der Launcher setzte bisher BLUN_NO_AUTO_UPDATE=1 in derselben Umgebung, die sowohl der geschützte Kern als auch die Update-Vorbereitung des übergeordneten Prozesses nutzten. Dadurch war der alte Updater im Kern zwar korrekt deaktiviert, aber auch der neue übergeordnete Update-Prüfer beendete sich vor dem Abruf des öffentlichen Manifests.
  • 9.1.182 bewahrt eine ausdrücklich gesetzte Abschaltung für den übergeordneten Prozess. Die erzwungene Abschaltung wird nur noch beim Start des geschützten Kerns ergänzt.
  • Mnemo bleibt eine interne, lokale Konfiguration. Das öffentliche Paket enthält Mnemo nicht. Der additive Eintrag bleibt ohne lokalen Mnemo-Pfad und ausdrücklich gesetzte Agentenidentität vollständig inaktiv.
9.1.181
  • Wiederholte identische lange Nutzeraufträge und doppelte Telegram-Zustell-IDs werden ausschließlich aus der Modellprojektion entfernt; der Rohverlauf bleibt unverändert.
  • Ein konfigurierter Mnemo-MCP wird nun dem aktiven King-TUI-Profil hinzugefügt, statt auf Telegram-Bridge-Sitzungen beschränkt zu bleiben.
  • Alle 413 Tests bestanden; beide gezielten Mutationsproben wurden rot, sobald jeweils eine der Schutzmaßnahmen entfernt wurde.
9.1.180
  • Die automatische Update-Vorbereitung hängt nicht mehr ausschließlich am späteren TUI-Ready-IPC. Sobald der geschützte Kern nachweislich geladen ist, startet der Launcher die Vorbereitung auch dann, wenn dieses zweite Signal verloren ging.
  • Die Sicherheitsgrenze für die eigentliche Übergabe blieb unverändert: laufende Antwort, Verdichtung, Nachrichtenwarteschlange, Werkzeuge, Shell-Befehle und Queue-Befehle verhindern weiterhin einen Neustart mitten in der Arbeit.
  • Der Ist-Stand belegte den Fehler: Modus resume, Installation 9.1.177, öffentlich 9.1.179, aber nur 9.1.176 vorbereitet. Der Loop war damit nicht der erste Blocker, weil die Leerlaufprüfung erst nach der Vorbereitung greift.
9.1.179
  • Reine Bestätigungen wie ok, ja, danke oder perfekt überspringen den persönlichen Memory-Broker. Das spart einen Broker-Aufruf und verhindert bei solchen inhaltsarmen Zügen bis zu 16.384 Zeichen unnötige Memory-Injektion.
  • weiter, Anhänge, Fragen, Befehle und andere inhaltliche Nachrichten behalten den bisherigen portalübergreifenden Erinnerungsweg.
  • Ein zuerst gebauter DeepAgents-artiger Argumentpuffer war in vier von fünf Messrunden langsamer als die einfache Verkettung. Er wurde vollständig verworfen und nicht veröffentlicht.
9.1.178
  • Die verzögerte Werkzeugsuche erkennt jetzt einen eindeutigen exakten ersten Begriff. GetMedia media job status result lädt dadurch GetMedia, ohne auf eine breite semantische Vermutung auszuweichen. Mehrdeutige Kurznamen bleiben absichtlich ungelöst.
  • Die Medien-Produktionskette bricht vollständige Stufennamen auf Folgezeilen um. Der letzte Schritt wird nicht mehr am rechten Rand abgeschnitten.
  • Die Änderung verbessert Werkzeugauswahl und Lesbarkeit. Sie verändert weder Medienmodell noch Bildqualität und behauptet keine echte Medienvorschau.

Verbesserungen seit 9.1.57

VersionÄnderung
9.1.177Automatische Updates übernehmen einen gespeicherten Fortsetzungs- oder Neustartmodus jetzt auch dann, wenn die direkte Prozessnachricht ausbleibt, und zeigen unmittelbar vor dem sicheren TUI-Neustart einen klaren Hinweis. Historische Platzhalter für verdichtete Werkzeugargumente werden als kompaktes JSON, formatiertes JSON oder eingelesenes Objekt entfernt, bevor sie erneut ausgeführt werden können. Rohverlauf und alle vorhandenen Schutzmechanismen des Updates bleiben unverändert.
9.1.176Alle Auswahlmenüs für Slash-Befehle trennen Optionen jetzt mit einer Leerzeile und zeigen Erklärungen in einer eigenen, zurückhaltenden Zweitfarbe. Die gemeinsame Komponente versorgt 20 Menüaufrufe; individuelle Warnfarben bleiben erhalten.
9.1.175Der bei jeder Modellanfrage wiederholte Werkzeughinweis sinkt von 1.749 auf 825 Zeichen. Das spart in der Messung rund 231 geschätzte Eingabetoken je Anfrage. Alle elf Verhaltenspflichten bleiben erhalten; Rohverlauf, Werkzeugschemas und Dateien bleiben unverändert.
9.1.174Der pro Modellanfrage eingeblendete relevante Mistake.md-Ausschnitt ist auf 3.000 statt 4.000 Zeichen begrenzt. In 100 echten Anfragen spart das durchschnittlich rund 253 geschätzte Eingabetoken; die ausgewählten Überschriften blieben in allen 100 Fällen identisch. Vollständige Dateien und gespeicherter Verlauf bleiben unverändert.
9.1.173BLUN King erkennt wiederkehrende reine Textantworten über mehrere Telegram-Züge hinweg. Nach drei nahezu gleichen Antworten trotz neuer Nutzerhinweise erhält der Agent einmalig einen internen Korrekturhinweis, statt eine alte Frage, Liste oder Warteschleife erneut auszugeben. Nachrichten, Prozesse und gespeicherter Verlauf bleiben unverändert.
9.1.172Die automatische Aktualisierung prüft eine laufende Sitzung nach einer beim Start ergebnislosen Suche erneut. Die nächste Prüfung erfolgt zufällig verteilt nach 60 bis 90 Sekunden. Dadurch werden später veröffentlichte Versionen ohne manuellen Neustart erkannt. Installation und Sitzungsübergabe warten weiterhin auf vollständigen Leerlauf.
9.1.171BLUN King behält pro Zug nur noch die vier zuletzt nachgeladenen Werkzeugschemas statt zwölf. Ältere Werkzeuge bleiben über ToolSearch auffindbar und werden bei Auswahl erneut geladen. Dauerhaft geladene Kernwerkzeuge, der gespeicherte Verlauf und das Ausführungsverhalten bleiben unverändert.
9.1.170Bündelt die aktuellen Zuverlässigkeits- und Arbeitsablauffehler: Wiederkehrende Aufgaben behalten die neueste übergroße Anweisung; verdichtete Werkzeugargument-Platzhalter werden aus der Modellprojektion entfernt; ToolSearch erkennt natürliche Memory-Suchwörter einschließlich des einzelnen Wortes „store“; die Loop-Anzeige lädt den Planungszustand neu; /update steuert die sichere Leerlauf-Übergabe; und /premortem stellt eine sichtbare, strukturierte Fehleranalyse bereit.
9.1.169BLUN King behält die exakte Werkzeugauswahl und die bisherige strenge Stichwortsuche unverändert. Erst wenn diese Suche keinen Treffer liefert, sucht ein enger zweiter Lauf nach verwandten deutschen und englischen Begriffen. Namensanforderungen mit + bleiben zwingend; mindestens zwei sinntragende Begriffe und 75 Prozent der Anfrage müssen passen. Dadurch finden die drei tatsächlich fehlgeschlagenen Telegram-Suchen das aktuelle Warteschlangenwerkzeug, während eine unpassende Anfrage weiterhin ohne Treffer endet.
9.1.168BLUN King ersetzt ältere Argumente von Werkzeugaufrufen nicht mehr durch einen internen Platzhalter, den das Modell in einen neuen Aufruf kopieren kann. Bereits vorhandene Platzhalter-Aufrufe und ihre zugehörigen Fehlerergebnisse werden nur aus der Modellprojektion entfernt; der unveränderte Sitzungsverlauf bleibt als Nachweis erhalten.
9.1.167BLUN King 9.1.167 behält bei wiederkehrenden geplanten Aufträgen nur noch eine lückenlose Folge der neuesten vollständigen Arbeitsabschnitte. Wenn der nächste neuere Abschnitt die Grenze von 48.000 Zeichen oder 24 Nachrichten überschreiten würde, endet die Auswahl, statt danach wieder ältere kleine Abschnitte aufzunehmen. So bleiben Kontext und zeitliche Reihenfolge stimmig. In einem vermessenen laufenden Verlauf sank die projizierte Historie von 32.591 auf 16.981 Zeichen. Das spart 15.610 Zeichen beziehungsweise rund 3.903 geschätzte Eingabetoken pro vergleichbarer Anfrage. Rohverlauf, aktuelle Auftragsschritte und die Verdichtungszusammenfassung bleiben unverändert.
9.1.166BLUN King 9.1.166 begrenzt wiederkehrende geplante Aufträge auf einen isolierten Arbeitskontext, statt bei jedem Modellschritt das gesamte Gespräch des Hauptagenten erneut zu übertragen. Der aktuelle Auftrag, die neueste Verdichtungszusammenfassung und die neuesten echten Arbeitsschritte bleiben innerhalb einer Grenze von 24 Nachrichten und 48.000 Zeichen verfügbar. Der gespeicherte Verlauf, normale Nutzerzüge, einmalige Erinnerungen und schnelle Gesprächswege bleiben unverändert. In einem vermessenen Verlauf verbrauchten 2.043 Modellschritte wiederkehrender geplanter Aufträge insgesamt 298,7 Millionen Eingabetoken, durchschnittlich 146.188 Token je Schritt.
9.1.165BLUN King 9.1.165 begrenzt das Ausgabebudget normaler Züge auf 24.576 statt 32.768 Token. Leichte Schritte behalten ihren bisherigen Grenzwert von 8.192 Token, Modelle mit kleineren Ausgabegrenzen behalten diese niedrigeren Werte, und eine ausdrückliche Nutzereinstellung hat weiterhin Vorrang. Von 27.049 vermessenen Antworten blieben 99 Prozent unter 9.970 Token; zwölf alte Ausreißer trafen exakt die bisherige Grenze von 32.768 Token und rechneten jeweils rund sechs Minuten weiter.
9.1.164BLUN King 9.1.164 begrenzt das Ausgabebudget einer Verdichtung auf großen Modellfenstern auf 16.384 statt 131.072 Token. 39 erfolgreiche Verdichtungen benötigten höchstens 10.781 Ausgabetoken. Der neue Rahmen liegt 52 Prozent über diesem gemessenen Höchstwert und senkt den möglichen Ausgabe- und KV-Cache-Bedarf pro Verdichtung um 87,5 Prozent. Gespeicherter Verlauf und normale Gesprächszüge bleiben unverändert.
9.1.163BLUN King 9.1.163 ersetzt umfangreiche Skill-Ladungen außerhalb der letzten 20 Nachrichten in der Modellprojektion durch einen kompakten Nachladeverweis. Aktuelle, kleine und nicht nachladbare Skill-Ladungen bleiben unverändert; der gespeicherte Gesprächsverlauf wird nicht umgeschrieben. In einem vermessenen Fall sinkt eine Skill-Ladung von 87.034 auf 424 projizierte Zeichen. Sobald sie das aktuelle Arbeitsfenster verlässt, spart das 86.610 Zeichen beziehungsweise rund 21.653 geschätzte Eingabetoken.
9.1.162BLUN King 9.1.162 begrenzt große Übersichten des Arbeitsverzeichnisses im wiederholten Systemprompt auf 2.000 Zeichen. Kleine Übersichten bleiben unverändert. Bei gekürzten Übersichten weist ein klarer Hinweis weiterhin auf die vollständige Suche mit Glob, Grep und Read hin. In einem vermessenen Prompt sinkt die Übersicht von 3.988 auf 1.983 Zeichen. Das spart 2.005 Zeichen beziehungsweise rund 501 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.161BLUN King 9.1.161 wiederholt die Namen der 112 ausgelagerten Werkzeuge nicht mehr in jeder ToolSearch-Beschreibung. Die Suche per Stichwort, die exakte Auswahl anhand des vollständigen oder eindeutigen kurzen Namens und das dauerhafte Laden der zwölf zuletzt ausgewählten Schemas bleiben erhalten. In der vermessenen Darstellung sinkt die wiederholte Beschreibung von 1.984 auf 278 Zeichen. Das spart 1.706 Zeichen beziehungsweise rund 426 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.160Ab BLUN King 9.1.160 schützt die Modellprojektion nur noch die neuesten zwölf Nachrichten vollständig, bevor ältere erfolgreiche Werkzeugergebnisse, die ausschließlich Text enthalten, durch einen kurzen Abschlussvermerk ersetzt werden. Fehlerausgaben, Medien, gespeicherte Dateiverweise, die neuesten zwölf Nachrichten, Rohverlauf und Exporte bleiben unverändert. In einem stabil vermessenen Sitzungsschnappschuss werden dadurch zwei weitere alte Werkzeugergebnisse verkleinert. Die Modellprojektion sinkt von 81.800 auf 78.402 Zeichen. Das spart weitere 3.398 Zeichen beziehungsweise rund 850 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.159Ab BLUN King 9.1.159 werden gültige JSON-Argumente abgeschlossener Werkzeugaufrufe außerhalb der neuesten 12 Nachrichten in der Modellprojektion durch einen kurzen Vermerk ersetzt. Das zugehörige Werkzeugergebnis, die neuesten 12 Nachrichten, nicht abgeschlossene Aufrufe, kleine oder ungültige Argumente, Rohverlauf und Exporte bleiben unverändert. In einem stabil vermessenen Sitzungsschnappschuss werden drei Argumente abgeschlossener Werkzeugaufrufe von 2.849 auf 165 Zeichen verkleinert. Das spart 2.684 Zeichen beziehungsweise rund 671 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.158Ab BLUN King 9.1.158 werden reine Statusnachrichten, die unmittelbar auf eine abgeschlossene Telegram-Antwort folgen, außerhalb der neuesten 20 Nachrichten in der Modellprojektion durch einen kurzen Vermerk ersetzt. Der versendete Antwortaufruf und sein Ergebnis, aktuelle Nachrichten, Zusammenfassungen nach anderen Werkzeugen, gemischte Inhalte, Rohverlauf und Exporte bleiben unverändert. In einem stabil vermessenen Sitzungsschnappschuss werden sechs historische Statusnachrichten um 1.837 Zeichen verkleinert. Das spart rund 460 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.157Ab BLUN King 9.1.157 werden geeignete erfolgreiche, rein textbasierte Werkzeugausgaben außerhalb der neuesten 20 Nachrichten in der Modellprojektion durch einen kurzen Abschlussvermerk ersetzt. Fehlerausgaben, Medien, ausgelagerte Dateiverweise, die neuesten 20 Nachrichten, Rohverlauf und Exporte bleiben unverändert. In einem stabil vermessenen Sitzungsschnappschuss werden 43 alte Ergebnisse verkleinert. Das spart 9.680 Zeichen beziehungsweise rund 2.420 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.156Ab BLUN King 9.1.156 wiederholen gespeicherte Verweise auf Nutzernachrichten außerhalb der neuesten 20 Nachrichten ihre Vorschau mit Anfang und Ende nicht mehr bei jeder Modellanfrage. Wiederherstellungsmarkierung, Größenangaben, lesbarer Dateipfad, die neuesten 20 Nachrichten, Medien, Rohverlauf, vollständig gespeicherte Datei und Exporte bleiben unverändert. In einem stabil vermessenen Schnappschuss werden fünf historische Verweise verkleinert und die Modellprojektion sinkt von 99.143 auf 96.001 Zeichen. Das spart weitere 3.142 Zeichen beziehungsweise rund 786 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.155Ab BLUN King 9.1.155 werden gespeicherte Verweise auf Nutzernachrichten wiederhergestellt, bevor Textprojektionen den Hash der ursprünglichen Nachricht verändern können. Bestehende Auslagerungen bleiben dadurch wirksam, statt unbemerkt auf die projizierte vollständige Nachricht zurückzufallen. Rohverlauf, wiederlesbare Dateiverweise, die neuesten 20 Nachrichten, Medien und Exporte bleiben unverändert. In einem stabil vermessenen Schnappschuss sinkt die Modellprojektion von 105.810 auf 99.143 Zeichen. Das spart weitere 6.667 Zeichen beziehungsweise rund 1.667 geschätzte Eingabetoken pro gleich aufgebauter Anfrage.
9.1.154Ab BLUN King 9.1.154 werden adressierte Telegram-Kanalabschnitte außerhalb der neuesten 20 Nachrichten auf eine 500 statt 1.000 Zeichen lange Vorschau mit Anfang und Ende begrenzt. Vollständige Kanalmetadaten, Anfang und Ende des Nachrichteninhalts, die neuesten 20 Nachrichten, Anhänge, Rohverlauf und Exporte bleiben unverändert. In einem stabil vermessenen Schnappschuss werden sieben zusätzliche historische adressierte Abschnitte verkleinert. Das spart 3.500 Zeichen beziehungsweise rund 875 geschätzte Token pro wiederholter Anfrage.
9.1.153Ab BLUN King 9.1.153 bewahrt die Projektion historischer Telegram-Kontexte die vollständigen Kanalmetadaten und den schließenden Kanal-Tag. Gekürzt wird ausschließlich der Nachrichteninhalt. Selbst bei realen, 161 Zeichen langen Telegram-Metadaten bleibt die Struktur innerhalb des 250-Zeichen-Budgets gültig. Die Projektion ist idempotent, nachfolgende adressierte Kanäle bleiben unverändert, und ein Kanalumschlag, der bereits ohne Inhalt das Budget überschreitet, wird unverändert durchgereicht.
9.1.152Ab BLUN King 9.1.152 verlassen Argumente abgeschlossener Werkzeugaufrufe die aktive Modellprojektion nach vier statt nach acht neueren Nachrichten. Der rohe Sitzungsverlauf, unbeantwortete oder fehlerhaft formatierte Aufrufe, Medien, Werkzeugergebnisse und die neuesten vier Nachrichten bleiben unverändert. In einem frisch vermessenen Sitzungsschnappschuss werden zwei zusätzliche abgeschlossene Aufrufe verdichtet; gegenüber 9.1.151 spart das weitere 244 Zeichen beziehungsweise rund 61 geschätzte Token pro wiederholter Anfrage.
9.1.151Ab BLUN King 9.1.151 verlassen Argumente abgeschlossener Werkzeugaufrufe die aktive Modellprojektion nach acht statt nach zwölf neueren Nachrichten. Der rohe Sitzungsverlauf, unbeantwortete oder fehlerhaft formatierte Aufrufe, Medien, Werkzeugergebnisse und die neuesten acht Nachrichten bleiben unverändert. In einem vermessenen Sitzungsschnappschuss werden drei zusätzliche abgeschlossene Aufrufe verdichtet; gegenüber 9.1.150 spart das weitere 317 Zeichen beziehungsweise rund 80 geschätzte Token pro wiederholter Anfrage.
9.1.150Ab BLUN King 9.1.150 schützt die historische Auslagerung von Werkzeugergebnissen die neuesten vier Nachrichten vollständig statt der neuesten acht. Ältere geeignete Werkzeugergebnisse behalten einen kompakten, 600 Zeichen langen Wiederherstellungshinweis und ihren Quellpfad; Rohverlauf, vollständig gespeicherte Ausgaben, Medien und die neuesten vier Nachrichten bleiben unverändert. In einem vermessenen Sitzungsschnappschuss lagert das Vier-Nachrichten-Fenster neun zusätzliche historische Ergebnisse aus und spart gegenüber 9.1.149 weitere 6.683 Zeichen beziehungsweise rund 1.671 geschätzte Token pro wiederholter Anfrage.
9.1.149Ab BLUN King 9.1.149 schützt die historische Auslagerung von Werkzeugergebnissen die neuesten acht Nachrichten vollständig statt der neuesten zwölf. Ältere geeignete Werkzeugergebnisse behalten einen kompakten, 600 Zeichen langen Wiederherstellungshinweis und ihren Quellpfad; Rohverlauf, vollständig gespeicherte Ausgaben, Medien und die neuesten acht Nachrichten bleiben unverändert. In einem vermessenen Sitzungsschnappschuss sinken drei Ergebnisse von 4.679 auf 1.800 Zeichen; das spart weitere 2.879 Zeichen beziehungsweise rund 720 geschätzte Token pro wiederholter Anfrage.
9.1.148Ab BLUN King 9.1.148 werden auch im neuesten gemischten Telegram-Paket die ausdrücklich mit addressed=false markierten Kanalabschnitte verkleinert. Adressierte Abschnitte, Medien, Rohverlauf und Exporte bleiben unverändert. In einem vermessenen Verlauf sinken elf nicht adressierte Abschnitte von 22.691 auf 2.750 Zeichen; das spart 19.941 Zeichen beziehungsweise rund 4.986 geschätzte Token pro wiederholter Anfrage.
9.1.147Ab BLUN King 9.1.147 schützt die Mikroverdichtung die neuesten zwölf Nachrichten vollständig statt der neuesten zwanzig und verwendet damit dasselbe Wiederherstellungsfenster wie die bestehende Auslagerung von Werkzeugergebnissen. Ältere abgeschlossene Werkzeugargumente und geeignete Werkzeugergebnisse werden nur in der Modellprojektion verkleinert; Rohverlauf und Wiederherstellungspfade bleiben unverändert. In einem vermessenen Verlauf spart das weitere 560 Zeichen beziehungsweise rund 140 geschätzte Token pro Anfrage.
9.1.146Ab BLUN King 9.1.146 werden ältere, bereits ausgelagerte Werkzeugergebnisse in der Modellprojektion auf die für die Wiederherstellung nötigen Angaben begrenzt: Werkzeugname, Zeichenzahl und Dateipfad. Der vollständige Inhalt bleibt unverändert auf der Festplatte, der Rohverlauf wird nicht verändert, und die neuesten zwölf Nachrichten behalten ihre ausführlichen Hinweise. In einem vermessenen Verlauf reduziert das die wiederholte Modelleingabe um 26.779 Zeichen beziehungsweise rund 6.695 geschätzte Token pro Anfrage.
9.1.145Ab BLUN King 9.1.145 wird ein unterbrochener Anbieterstream automatisch wiederholt, wenn bis dahin ausschließlich interne Denkausgabe eingetroffen ist. Sichtbarer Text und Werkzeugaufrufe verhindern weiterhin eine automatische Wiederholung. Adaptive Folgeschritte mit niedriger Denkstufe verwenden ein Ausgabebudget von 8.192 Token; erste, komplexe und fehlgeschlagene Schritte behalten das konfigurierte Budget, und eine Wiederholung nach Erreichen der Längengrenze kann es vergrößern. Beim Fortsetzen einer Sitzung erscheint der aktuelle Telegram-Plugin-Transporthinweis nicht mehr als roher Chattext.
9.1.1449.1.144 begrenzt adressierte Telegram-Abschnitte außerhalb der neuesten 20 Nachrichten in der Modellprojektion auf eine 1.000 Zeichen lange Vorschau mit Anfang und Ende. Die neuesten 20 Nachrichten, die neueste Nutzernachricht, Abschnitte an der exakten Grenze, Anhänge, Kanalmetadaten, Rohverlauf und Exporte bleiben unverändert.
9.1.1439.1.143 entfernt bei älteren Nachrichten den wiederholten Telegram-Plugin-Transporthinweis aus der Modellprojektion. Kanalinhalt, Metadaten, Anhänge, neueste Nutzernachricht, Rohverlauf und Exporte bleiben unverändert.
9.1.1429.1.142 verkleinert die Vorschau mit Anfang und Ende für ältere, nicht adressierte Telegram-Kanalteile in der Modellprojektion von 500 auf 250 Zeichen. Adressierte Kanalteile, die neueste Nutzernachricht, Anhänge, Rohverlauf und Exporte bleiben unverändert.
9.1.1419.1.141 entfernt Argumente älterer, abgeschlossener Werkzeugaufrufe in der Modellprojektion bereits ab 32 geschätzten Token. Werkzeugergebnisse behalten ihre bisherige Schwelle; neue Nachrichten und der Rohverlauf bleiben unverändert.
9.1.1409.1.140 begrenzt die relevanzbasierte Mistake-Erinnerung in der Modellprojektion standardmäßig auf 4.000 Zeichen. Vollständige Mistake-Dateien, Rohverlauf und Exporte bleiben unverändert.
9.1.1399.1.139 begrenzt ältere, nicht adressierte Telegram-Kanalteile in der Modellprojektion auf eine Vorschau von 500 Zeichen. Die neueste Nutzernachricht, adressierte Teile, Anhänge, Rohverlauf und Exporte bleiben vollständig.
9.1.1389.1.138 behält von jedem wiederkehrenden Cron-Auftrag nur noch den neuesten Weckhinweis in der Modellprojektion. Einmalige Erinnerungen, unterschiedliche Aufträge, Rohverlauf und Exporte bleiben unverändert.
9.1.1379.1.137 schützt nur noch die zwölf neuesten Nachrichten vollständig vor der Auslagerung älterer Werkzeugausgaben. Vollständige Ergebnisse bleiben über Rohverlauf und Quellpfad wiederherstellbar.
9.1.1369.1.136 behält in der Modellprojektion nur noch den neuesten dynamischen Mistake.md-Hinweis. Ältere Auswahlen bleiben im Rohverlauf und in Exporten vollständig erhalten.
9.1.135BLUN King 9.1.135 hält die verwaltete Node.js-Laufzeit im Ersatzprozess und in allen untergeordneten Werkzeugen an erster Stelle im PATH. Befehle wie node und npm verwenden damit dieselbe unterstützte Laufzeit wie die TUI, statt auf eine ältere Systeminstallation zurückzufallen.
9.1.1349.1.134 begrenzt nicht adressierte Telegram-Gruppennachrichten in der Modellprojektion auf eine Vorschau von 2.000 Zeichen mit erhaltenem Anfang, Ende und ursprünglicher Länge. Direktnachrichten und der gespeicherte Verlauf bleiben vollständig.
9.1.1339.1.133 wählt aus der projektlokalen und der gemeinsamen Mistake.md höchstens fünf relevante vollständige Einträge innerhalb eines gemeinsamen Budgets von 6.000 Zeichen aus. Die vollständigen Quellen und Speicherwege bleiben erhalten.
9.1.1329.1.132 hält den schlanken Basissystemprompt mit 4.850 Zeichen nach der generierten Initialisierung aktiv. Das spart pro Anfrage 18.259 Zeichen, also etwa 4.565 geschätzte Token, ohne Anweisungen oder Werkzeuge zu entfernen.
9.1.1319.1.131 entfernt zwei ältere Regelkopien aus der Modellprojektion, sobald die maßgeblichen Gegenstücke vorhanden sind. Der Standardprompt sinkt dadurch um 1.010 Zeichen beziehungsweise rund 253 geschätzte Token pro Anfrage.
9.1.1309.1.130 ersetzt außerhalb der letzten 20 Nachrichten den erläuternden Text älterer, vollständig abgeschlossener Werkzeugschritte durch einen kurzen Hinweis. Werkzeugaufrufe, Ergebnisse, Rohverlauf und Exporte bleiben vollständig erhalten.
9.1.1299.1.129 entfernt Vorschautexte aus älteren, bereits ausgelagerten Werkzeugergebnissen. Pfad und Größenangaben bleiben sichtbar; der vollständige Inhalt bleibt in der Originaldatei oder im privaten Archiv erhalten.
9.1.1289.1.128 begrenzt den dauerhaften Cache nachgeladener Werkzeugschemas auf die zwölf zuletzt ausgewählten Werkzeuge. Verdrängte Werkzeuge bleiben über ToolSearch sofort auffindbar.
9.1.1279.1.127 verkürzt den wiederholten ToolSearch-Katalog. Eindeutige Werkzeuge erscheinen mit ihrem kurzen Selektor; vollständige MCP-Namensräume bleiben nur bei Namenskonflikten erhalten.
9.1.1269.1.126 wählt aus der laufzeitweiten Fehlerdatei deterministisch höchstens fünf zur aktuellen Unterhaltung passende Abschnitte aus. Die Projektion ist auf 6.000 Zeichen begrenzt und benötigt keinen zusätzlichen Modell- oder Netzwerkaufruf.
9.1.1259.1.125 ergänzt den rein lesenden Telegram-Befehl /status für gekoppelte Nutzer. Er nennt Rechner-, Versions-, Prozess- und Warteschlangenstatus, ohne Chat-IDs, Pfade, Geheimnisse oder Nachrichteninhalte auszugeben.
9.1.1249.1.124 korrigiert die vertauschten Markenfarben im kompakten BLUN-Zeichen unter der Eingabe. Statuswerte, Profilname und Persona bleiben unverändert.
9.1.1239.1.123 entfernt die großen JSON-Argumente älterer, abgeschlossener Werkzeugaufrufe aus der Modellprojektion. Name, Kennung, Ergebnis, Rohverlauf und Exporte bleiben vollständig.
9.1.1229.1.122 lädt die vollständige Designrichtlinie nur noch bei visueller Arbeit über das Skill-Werkzeug. Nicht visuelle Anfragen erhalten einen kompakten Aktivierungsvertrag; ältere reine Textausgaben werden zugleich wirksamer ausgelagert.
9.1.1219.1.121 begrenzt die Gesamtgröße älterer reiner Textausgaben von Werkzeugen. Geeignete Ergebnisse werden privat archiviert und in der Modellprojektion durch lesbare Dateiverweise ersetzt.
9.1.1209.1.120 lagert große ältere Assistentenantworten in private Sitzungsdateien aus. Die letzten 20 Nachrichten, Werkzeugketten und der vollständige Rohverlauf bleiben erhalten.
9.1.1199.1.119 sendet bei jedem Modellschritt nur noch eine kleine Auswahl häufig benötigter Skills. Alle weiteren Skills bleiben über das Skill-Werkzeug anhand ihres Namens oder Zwecks auffindbar.
9.1.1189.1.118 hält den Sitzungszeitstempel im Systemprompt während einer laufenden Sitzung stabil. Unveränderte Promptteile können dadurch den Präfix-Cache des Anbieters weiterverwenden.
9.1.1179.1.117 hält die vier Kernwerkzeuge für Medien unmittelbar verfügbar und lädt Bild- und Videoverständnis, Videosynchronisierung und Lippenbewegungssynchronisierung nur bei Bedarf über ToolSearch.
9.1.1169.1.116 ergänzt eine proaktive Verdichtung ab rund 128.000 geschätzten Eingabe-Token an einer sicheren Schrittgrenze. Die Verdichtung nutzt einen schlanken eigenen Systemprompt; große Read-Ergebnisse verwenden ihren vorhandenen Quellpfad.
9.1.115Fortgesetzte Sitzungen bauen den Systemprompt des aktuellen Profils neu auf, sodass veraltete übergroße Prompt-Schnappschüsse nicht über Neustarts hinweg bestehen bleiben. Große Arbeitsordnerübersichten werden begrenzt; die vollständigen Dateien bleiben über Glob, Grep und Read verfügbar.
9.1.114Die Telegram-Zustellung behandelt Windows-EPERM nun als Hinweis auf einen laufenden TUI- oder Poller-Prozess, statt Nachrichten von der sichtbaren Sitzung wegzuleiten. ToolSearch bestätigt ein bereits geladenes Werkzeug mit exakter Namensübereinstimmung, statt fälschlich zu melden, dass ein erst bei Bedarf nachzuladendes Werkzeug fehle.
9.1.113Die Telegram-Werkzeuge behalten beim Start einen Ersatzweg innerhalb derselben Laufzeit, falls die verwaltete Plugin-Registrierung vorübergehend fehlt.
9.1.112Große ältere Nutzernachrichten werden außerhalb des aktuellen Arbeitsfensters archiviert; der vollständige Rohverlauf bleibt weiterhin verfügbar.
9.1.111Telegram-Züge mit Anhängen erhalten download_attachment automatisch. Bei normalen Zügen bleibt das Werkzeug über ToolSearch ausgelagert, sodass die verringerte Schemalast erhalten bleibt.
9.1.110Wiederholungen nach einer Provider-Überlastung beachten die Retry-After-Angabe des Servers. Die automatische ripgrep-Einrichtung lädt die festgelegten Archive der Version 15.0.0 aus der offiziellen ripgrep-Veröffentlichung und prüft vor der Installation ihre SHA-256-Prüfsummen.
9.1.109Version 9.1.109 hält nur noch die neun Werkzeuge dauerhaft in der Modellanfrage, auf die mehr als 98 Prozent der 3.183 gemessenen Werkzeugaufrufe entfielen. Alle übrigen Werkzeuge bleiben über ToolSearch auffindbar und nach dem ersten Laden für den Rest der Sitzung verfügbar. Dadurch sinkt die Schemalast bei jedem normalen Modellschritt, ohne ein Werkzeug zu entfernen oder den Schnellweg für Telegram-Antworten und ausstehende Medienergebnisse zu verändern.
9.1.108Identische, wiederholt eingespeiste Systemhinweise werden nur in der Modellprojektion zusammengeführt. Geänderte Hinweise und der vollständige gespeicherte Verlauf bleiben erhalten.
9.1.107Providerfehler werden in verständlicher Kundensprache angezeigt; interne Fehlercodes und Support-Hinweise erscheinen dabei nicht. /help bietet eine mit Pfeiltasten steuerbare Befehlsliste und öffnet mit der rechten Pfeiltaste oder der Eingabetaste eine ausführliche Beschreibung des ausgewählten Befehls.
9.1.106Agentenprofile können Werkzeuge namentlich ausschließen. Die Ausschlüsse greifen auch nach dynamischem Nachladen; die Standard-Teilagenten senden keine Telegram-Nachrichten am Hauptagenten vorbei.
9.1.105Version 9.1.105 ergänzt TaskUpdate für laufende Hintergrundagenten. King übergibt zusätzliche Anweisungen am nächsten sicheren Modellschritt an denselben aktiven Agenten, ohne ihn zu stoppen oder einen weiteren Agenten zu starten. Unbekannte und bereits beendete Aufgaben, Shell-Aufgaben sowie Agenten, die keine Aktualisierung mehr annehmen, werden unverändert abgewiesen.
9.1.104Version 9.1.104 lässt Shell-Befehle im Vordergrund auch bei sehr großen Ausgaben bis zum regulären Ende laufen. King schreibt bis zu 16 MiB fortlaufend in das private Aufgabenprotokoll, verwirft darüber hinausgehende Ausgaben und meldet den tatsächlichen Exit-Code, statt den Prozess wegen der Ausgabemenge zu beenden. Kleine Ausgaben, Hintergrundaufgaben, Zeitgrenzen und manuelle Abbrüche bleiben unverändert.
9.1.103Schwarmmitglieder werden nach vorübergehenden Provider-Unterbrechungen unter derselben Agenten-ID höchstens zweimal fortgesetzt. HTTP 429 behält seine getrennte Überlastungsregel; endgültige Fehler und manuelle Abbrüche werden nicht automatisch wiederholt.
9.1.102Delegierte Einzelagenten werden nach vorübergehenden Provider-Fehlern anhand ihres dauerhaften Verlaufs höchstens zweimal fortgesetzt. Dauerhafte Fehler und manuelle Abbrüche bleiben endgültig.
9.1.101Übergroße Nutzernachrichten werden lokal gesichert und im Modellkontext durch eine begrenzte Vorschau mit lesbarem Pfad ersetzt. Der vollständige Originalverlauf und Medien bleiben erhalten.
9.1.100Begrenzte Grep-Inhaltssuchen beenden ripgrep nach der angeforderten Seite und einer zusätzlichen Vorschauzeile. Trefferzählungen, unbegrenzte Suchen und nach Änderungszeit sortierte Dateilisten bleiben vollständig.
9.1.98King kann einen abgeschlossenen Arbeitsabschnitt ab 128.000 geschätzten Token proaktiv verdichten. Unterhalb der Schwelle bleibt das Werkzeugschema vollständig aus dem Modellprompt; die Verdichtung nutzt den bestehenden sicheren Schrittübergang.
9.1.97Die dauerhaft geladene TodoList-Werkzeugbeschreibung sank von 2.238 auf 996 Zeichen. Mehrstufige Planung, alle sechs Aufgabenstatus, ehrliche Fortschrittsmeldungen, Abfragen, Leeren und der getrennte Planmodus blieben geschützt.
9.1.96Der dauerhaft geladene Basissystemprompt sank von 23.109 auf 4.850 Zeichen. Identität, Persona und Seele, Antwortsprache, Arbeits- und Berechtigungsgrenzen, Verdichtungsübergabe, Laufzeitumgebung, AGENTS.md und Skills blieben geschützt.
9.1.95Die dauerhaft geladene Write-Werkzeugbeschreibung sank von 2.532 auf 1.541 Zeichen. Die Abgrenzung zu Edit, wörtliche Inhalte, Zeilenenden, die 500-Zeilen-Grenze, die Ein-Datei-Ausnahme und die atomare Fortsetzung mit Zeilen- und SHA-256-Prüfung blieben geschützt.
9.1.94Die dauerhaft geladene Glob-Werkzeugbeschreibung sank von 1.495 auf 1.006 Zeichen. Sortierung, ignorierte und sensible Dateien, rekursive Muster, Dot-Dateien, Klammererweiterungen und die Grenze von 100 Treffern blieben geschützt.
9.1.93Die dauerhaft geladene Edit-Werkzeugbeschreibung sank von 1.537 auf 1.144 Zeichen. Lesen vor dem Ändern, exakte Ersetzungen, Mehrfachersetzungen, CRLF-Behandlung und die 500-Zeilen-Grenze blieben geschützt.
9.1.92Die dauerhaft geladene Agent-Werkzeugbeschreibung sank von 2.061 auf 1.153 Zeichen. Getrennter Kontext, Fortsetzen, Zeitgrenzen und parallele Delegation blieben erhalten.
9.1.91Die dauerhaft geladene Read-Werkzeugbeschreibung sank von 2.391 auf 1.648 Zeichen. Seitenbildung, Geheimnisschutz, Medienweiterleitung, Zeilenformat und CRLF-Verhalten blieben erhalten.
9.1.90Die dauerhaft geladene Bash-Werkzeugbeschreibung sank von 5.003 auf 1.834 Zeichen. Laufzeitvertrag, Hintergrundaufträge, Dateiwerkzeuge und Sicherheitsgrenzen blieben vollständig erhalten.
9.1.89Seitenweise Dateilesungen nennen am internen 1.000-Zeilen-Limit den exakten nächsten line_offset; Dateiende und bewusst kleinere Ausschnitte bleiben unverändert.
9.1.88BLUN King 9.1.88 aktiviert die kleine, verlustfreie Verdichtung rechtzeitig vor der vollständigen Verdichtung. Ältere große Werkzeugergebnisse und abgeschlossene Werkzeugargumente verlassen früher die Modellansicht; der vollständige gespeicherte Verlauf bleibt erhalten.
9.1.87Eine ausdrücklich wiederholbare HTTP-429-Antwort beachtet Retry-After und erhält höchstens zwei automatische Wiederholungen; andere Fehler bleiben sofort sichtbar.
9.1.86Große Werkzeugausgaben behalten innerhalb desselben Vorschaubudgets jeweils 1.000 Zeichen vom Anfang und Ende sichtbar; eine genaue Markierung nennt die ausgelassene Zeichenzahl.
9.1.85Textbasierte Werkzeugergebnisse oberhalb von 12.000 Zeichen werden vollständig in einer privaten lokalen Datei gespeichert; folgende Modellanfragen behalten nur ein Vorschaubudget von 2.000 Zeichen und den lesbaren Pfad.
9.1.84Die vollständige Verdichtung verarbeitet ältere Verläufe in chronologischen Stufen mit höchstens 64.000 geschätzten Eingabe-Token; die feste Sicherheitsgrenze und das vollständige private Archiv bleiben unverändert.
9.1.83Die Mikroverdichtung ersetzt große Argumente älterer, abgeschlossener Werkzeugaufrufe nur in der Modellansicht durch eine gültige JSON-Markierung; der Sitzungsprüfer meldet die geschätzte Ersparnis ohne Inhaltsausgabe.
9.1.82Der rein lesende Prüfer meldet ausgewählte und zurückgehaltene Werkzeugschemas, Unterdrückungsgründe und die geschätzte Zahl vermiedener Schema-Token.
9.1.81Ein mitgelieferter, rein lesender Prüfer fasst Provider-Schritte, Werkzeugaufrufe, Token, Verdichtungen, Fehler und ausgelagerte Ausgaben zusammen, ohne Prompts oder private Pfade offenzulegen.
9.1.80Große Werkzeugergebnisse erhalten eine inhaltsfreie Auslagerungs-Telemetrie; isolierter Unteragenten-Kontext, maschinenlesbare Pläne und übertragbare Übergaben sind durch Regressionstests geschützt.
9.1.79Dauerhafte Prüfpunkte schreiben abgeschlossene Verlaufsdatensätze vor Provider-Schritten und vor Abschluss eines Workers fest, sodass abgeschlossene Arbeit nach einer Fortsetzung erneut eingelesen werden kann.
9.1.78Die vollständige Verdichtung archiviert verdrängte Verlaufsteile, bevor sie diese durch eine Zusammenfassung ersetzt; die Zusammenfassung enthält den lesbaren Archivpfad.
9.1.77Die Mikroverdichtung verkleinert bei Kontextdruck ältere, große Werkzeugergebnisse und bewahrt gleichzeitig den vollständigen gespeicherten Verlauf.
9.1.76Ausstehende Bild-, Video- und Sprachaufträge überstehen Verdichtung und schnelle Folgefragen; Telegram-Nachrichten bleiben ohne irreführenden Busy-Fehler in FIFO-Reihenfolge.
9.1.75Kurze Telegram-Unterhaltungen verarbeiten nur die neueste unbeantwortete Nachricht, während abgeschlossene Textwechsel als Sprachkontext erhalten bleiben.
9.1.74Hinterlegte Telegram-Routen stellen versehentlich ohne Minuszeichen übergebene Gruppen-IDs wieder her; Strg+S kann einen tatsächlich laufenden Zug steuern.
9.1.73Telegram- und Loop-Nachrichten starten während aktiver Arbeit keinen zweiten Zug mehr; Escape und Strg+C können den aktiven Zug weiterhin abbrechen.
9.1.72Das Ausblenden eines Update-Hinweises unterdrückt nur die damals angebotene Version; neuere Veröffentlichungen erscheinen beim normalen Start mit king wieder.
9.1.71Loop-Aufwecker gelangen korrekt in die Warteschlange, der Telegram-Poller wird atomar beansprucht, zentrale Datei- und Medienwerkzeuge bleiben sofort verfügbar und Context7 startet nicht mehr automatisch.
9.1.69Standard-MCPs werden eingerichtet, Telegram erreicht einen geschützten FIFO-Übergabepunkt, Escape und Strg+C brechen aktive Arbeit zuverlässig ab und die MCP-Übersicht blendet interne Pfade aus.
9.1.68Telegram-Nachrichten im Leerlauf wecken die FIFO-Verarbeitung, Direkt- und Gruppennachrichten behalten ihre Eingangsreihenfolge und die Fortsetzung blendet interne Telegram-Rahmen aus.
9.1.67Der Standardskill venture-flywheel ergänzt eine rein vertragliche UVF-Grundlage mit deterministischem Projektvertrauen und Freigabepflichten für externe Handlungen.
9.1.66/curiosity und /scout führen begrenzte, rein lesende Chancenrecherchen mit Belegen, Gegenbelegen und einem Abbruchkriterium aus.
9.1.65Escape und Strg+C brechen automatische Verdichtungen zuverlässig ab, ein stabiler Bildschirmanker verhindert doppelte Fußzeilen und der Loop-Hinweis ist am Chatinhalt ausgerichtet.
9.1.64Festplattenbasierter Sitzungsverlauf, nachgeladene Werkzeuge und Skills, ein Provider-Leerlaufwächter von 120 Sekunden, korrekter Loop-Takt, Telegram in FIFO-Reihenfolge, Linux-Pakete und bosnische Spracherkennung kamen gemeinsam hinzu.
9.1.58–9.1.63Diese Versionsreihe bündelte Arbeiten an Sitzungen, Telegram, Plattformen und Leistung. Den Abschluss bildeten schlanke Werkzeugschemas auf Abruf, kompakte Skill-Listen, wiederhergestellte First-use-Skills und ein Paket-Inventargate gegen ungeplante Entfernungen.

Vorherige Verbesserungen

VersionÄnderung
9.1.53/idea veröffentlicht seinen Aufgabenplan vor der ersten Arbeit, prüft ausgehende Handlungen bei jedem Werkzeugaufruf und verlangt für jeden Schritt einen ehrlichen Endzustand.
9.1.52Fortgesetzte Sitzungen öffnen direkt den gespeicherten Arbeitsordner. Unterhaltung und aktiver /loop-Zustand werden beim Wiederanlauf gemeinsam hergestellt.
9.1.51Loops arbeiten als autonome Aufwecker, /idea entwickelt und bearbeitet eigene Pläne, Telegram kann Arbeitsbefehle auslösen, und Medien- sowie Startzustände werden klarer dargestellt.
9.1.50Lokale oder über Telegram empfangene Bilder lassen sich als echte MP4-Videos animieren. Große Kontextfenster erhalten ein gültiges Ausgabebudget; die Medienleiste zeigt klarere Zustände und anklickbare Pfade.
9.1.49Bilder erwachsener Fantasiefiguren in Bademode bleiben innerhalb klarer Grenzen erlaubt. Abgeschlossene Bildaufträge lassen sich als Ausgangsbild für Videos verwenden; erfolgreiche GetMedia-Abfragen erzeugen keine wiederholten Karten.
9.1.48Die einheitliche Medienleiste bündelt Medienaufträge direkt über dem Eingabefeld. Prozentwerte erscheinen nur mit einem echten Messwert des Anbieters; andernfalls zeigt sie Phase und Laufzeit.
9.1.47Das Anfrageprotokoll unterscheidet Gespräche und Verdichtung und erfasst Werkzeugauswahl sowie Unterdrückungsgrund, ohne das Werkzeugverhalten zu ändern.
9.1.46Loops verstehen natürliche Zeitangaben, zeigen sie während der Eingabe an, unterstützen freie Intervalle und geben die normale Textauswahl im Terminal außerhalb der Verlaufssicht frei.
9.1.45Der laufende Verdichtungsfortschritt erscheint nur noch in der unteren Statusleiste statt zusätzlich als zweite Zeile im Chat.
9.1.44Vollständige Neuverpackung der abgenommenen 9.1.43, damit auch früh installierte 9.1.43-Fassungen das Update sicher erkennen.
9.1.43Vollständige Schutzbasis aus 9.1.40 mit Transportdiagnose, sichtbaren Update-Hinweisen und den Konsolenbefehlen /loop, /goal und /output-style.
9.1.40Zug-Wächter für lange oder wiederholt fehlschlagende Aufrufe; Selbst-Hash nach mehrteiligem Schreiben mit Rückleseprüfung der gespeicherten Datei.
9.1.39Lange Dateien werden in Fortsetzungen geschrieben. Jede Fortsetzung setzt am tatsächlich geschriebenen Ende an; Zeilenzahl, SHA-256 und Stückgrenzen werden geprüft und ausgegeben.
9.1.38Entartete oder abgeschnittene Werkzeugargumente werden erkannt. Eine unvollständige Datei wird mit Fehlermeldung abgewiesen, statt still als fertig zu gelten.
9.1.37Nach einem Node-Wechsel prüft BLUN native Module mit einer echten SQLite-Abfrage und baut better-sqlite3 bei Bedarf neu.
9.1.36Leere Modellantworten werden nach Ursache behandelt: zu knappes Ausgabebudget wird vergrößert, ein leerer Stopp genau einmal wiederholt. Systemhinweise und Injektionen können keine Telegram-Antwort auslösen.
9.1.35Mehrstufige Verdichtung zeigt Stufe und echte Auslastung des Modellfensters, beispielsweise 2/~10 · 90 %.
9.1.34Der aktive Kontext wird stufenweise verdichtet: älteste Teile zuerst, jeder Verdichter-Aufruf unterhalb der Modellgrenze.
9.1.33Grundlage für die automatische Node-Laufzeit und die nachgelagerte Reparatur nativer Module nach einem Laufzeitwechsel.

Nachträge und offene Dokumentationslücken

Abgleich vom 17. September 2026: Im Bereich 9.1.33 bis 9.1.597 sind 521 Versionen im npm-Verzeichnis vorhanden. Eine fehlende Nummer ist nicht automatisch eine fehlende Veröffentlichung: Manche Fassungen fehlen im heutigen Verzeichnis oder wurden zurückgezogen. Bei vier veröffentlichten Versionen bleiben die genauen Änderungsdetails offen. Dafür werden keine Änderungen erfunden.

9.1.567: Änderungsdetails offen

Veröffentlicht am 6. September 2026 um 22:42 UTC. Der SHA-512-Wert des Pakets stimmt mit dem in npm veröffentlichten Integritätswert überein. Das Paket enthält kein CHANGELOG.md; sein README nennt beim Installationsbefehl noch 9.1.566. Daraus lässt sich der Unterschied zu 9.1.566 nicht zuverlässig ableiten. Diese Dokumentationslücke bleibt ausdrücklich offen.

9.1.550: Änderungsdetails offen

Veröffentlicht am 2. September 2026 um 07:19 UTC. Der SHA-512-Wert des Pakets stimmt mit dem in npm veröffentlichten Integritätswert überein. Das Paket enthält kein CHANGELOG.md und im geprüften Material wurde kein versionsspezifischer Änderungsnachweis gefunden. Diese Dokumentationslücke bleibt ausdrücklich offen.

Nachtrag zu 9.1.536

Die folgenden Angaben stammen aus dem integritätsgeprüften veröffentlichten Paket vom 1. September 2026:

  • Arbeitsaufträge laufen über private Telegram-Antworten hinaus weiter. Nach gepufferten Direktnachrichten setzt King die Arbeit mit einem begrenzten zusätzlichen Schritt fort, sofern der Nutzer nicht ausdrücklich pausiert oder stoppt.
  • Kurze Statusnachfragen unterbrechen den laufenden Arbeitsablauf nicht.
  • Wenn die Wiederholungsversuche nach leeren Denkantworten ausgeschöpft sind, reduziert King den Denkaufwand, statt ihn bei weiteren Versuchen unverändert zu lassen.
  • Mehr nachgeladene Werkzeugschemas bleiben verfügbar; Nachrichten werden erst ausgelagert, wenn der verfügbare Platz im Verlauf knapp wird.
  • Enthalten sind die geprüfte Fortschrittsregel für TodoList und ein einzeiliger Startweg für God Mode mit Swarm.

Nachtrag zu 9.1.99

Die bereits vorhandene Funktionsdokumentation beschreibt die gemeinsame Auslagerung aufeinanderfolgender reiner Text-Werkzeugergebnisse: Überschreitet der Stapel 12.000 Zeichen, werden geeignete große Ergebnisse privat gespeichert. Im Modellkontext bleiben lesbare Verweise; Rohverlauf und Medien bleiben erhalten. Der bisher fehlende Versionseintrag verweist nun ausdrücklich auf diese Funktion.

9.1.70: Änderungsdetails offen

Veröffentlicht am 24. August 2026 um 15:56 UTC. Der SHA-512-Wert des Pakets stimmt mit dem in npm veröffentlichten Integritätswert überein. Das Paket enthält kein CHANGELOG.md; die vorhandenen Funktionsbeschreibungen belegen keinen eindeutigen Unterschied zu 9.1.69. Diese Dokumentationslücke bleibt ausdrücklich offen.

9.1.57: Änderungsdetails offen

Veröffentlicht am 23. August 2026 um 07:28 UTC. Die Fassung erschien bisher nur als Ausgangspunkt einer Sammelüberschrift. Ein eigener versionsspezifischer Änderungsnachweis ist im geprüften Material nicht zugeordnet. Diese Dokumentationslücke bleibt ausdrücklich offen.

Das im unveränderlichen npm-Paket 9.1.597 enthaltene CHANGELOG.md endet bei 9.1.594. Die ergänzten Hinweise zu 9.1.595 bis 9.1.597 stehen auf dieser Seite. Das veröffentlichte Paket wurde nicht nachträglich unter derselben Versionsnummer umgeschrieben.

9.1.41 und 9.1.42 sind zurückgezogen

Nicht installieren

Diese beiden Versionen wurden versehentlich von 9.1.38 statt von 9.1.40 abgezweigt. Dadurch fehlten Schreibfortsetzung, Selbst-Hash und Zug-Wächter. Beide npm-Versionen sind als veraltet markiert; latest und next haben nie auf sie gezeigt. 9.1.43 enthält ihre beabsichtigten Änderungen auf der vollständigen Schutzbasis.

Aktualisieren und prüfen

king update
blun --version

Nach der Installation von 9.1.599 muss die Versionsausgabe 9.1.599 zeigen. Die Updates von 9.1.597 und der lokalen Fassung 9.1.598 über die öffentlichen Update-Quellen sind geprüft. Eine bereits laufende Konsole lädt den neuen Code erst nach ihrem Neustart. Prüfe darin anschließend zusätzlich /version.