blun-king-cli 9.1.514 → 9.1.516
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +17 -0
- package/LIESMICH.txt +2 -2
- package/README.md +2 -2
- package/README.md.vor-91515-20260831-064010 +821 -0
- package/bin/launcher-runtime.js +7 -30
- package/bin/plugin-bootstrap.js +13 -2
- package/bin/todo-list-turn-policy.cjs +21 -0
- package/blun.mjs +67 -38
- package/package.json +9 -2
- package/scripts/check-active-profile-plugin-startup.js +36 -0
- package/scripts/check-mcp-startup-wait-budget.js +48 -0
- package/scripts/check-plugin-startup-regression.js +53 -0
- package/scripts/check-queue-controls-regression.js +189 -0
- package/scripts/check-resume-replay-regression.js +100 -0
- package/scripts/check-telegram-bridge-watchdog.js +60 -0
- package/scripts/check-todo-loop-regression.js +78 -0
|
@@ -0,0 +1,821 @@
|
|
|
1
|
+
# blun-king-cli — npm-Distribution
|
|
2
|
+
|
|
3
|
+
Dieses Verzeichnis ist das Gerüst des öffentlichen npm-Pakets `blun-king-cli`
|
|
4
|
+
(Erstveröffentlichung 8.0.0, 06.07.2026, Account `blunking`).
|
|
5
|
+
|
|
6
|
+
## Installation
|
|
7
|
+
|
|
8
|
+
Voraussetzung ist Node.js 24.15 oder neuer. Die geprüfte Version wird exakt
|
|
9
|
+
installiert:
|
|
10
|
+
|
|
11
|
+
```powershell
|
|
12
|
+
npm install -g blun-king-cli@9.1.514
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## AgentSpine 0.10.1
|
|
16
|
+
|
|
17
|
+
Version 9.1.514 enthält weiterhin AgentSpine 0.10.1 als inhaltsadressierte Pluginfassung. Der Preflight prüft jede aktive Host-Anweisungsdatei weiterhin race-sicher und bindet SHA-256 sowie Dateiidentität an den Zug, dupliziert den bereits vom Host geladenen Volltext aber nicht im Laufzeitkontext. Die reale Probe mit einer 15.519 Byte großen `CLAUDE.md` blieb dadurch bei 5.667 injizierten Byte. Der Stand enthält außerdem den selbstheilenden Persona- und Beziehungsgraphen, die begrenzte Telegram-Mnemo-Abfrage und eine sichtbare Fünf-Sekunden-Grenze für lokale Beziehungsabfragen.
|
|
18
|
+
|
|
19
|
+
## Reproduzierbares Staging und Packen
|
|
20
|
+
|
|
21
|
+
Der Schritt baut nichts, installiert nichts und veröffentlicht nichts. Vorher müssen
|
|
22
|
+
`apps/blun-king/dist/main.mjs`, `dist-web`, die Darwin- und Windows-Natives sowie
|
|
23
|
+
`plugins/telegram/dist` bereits frisch gebaut sein.
|
|
24
|
+
|
|
25
|
+
Das Staging landet standardmäßig
|
|
26
|
+
unter `.stage/package`, das Tarball unter `.stage/artifacts`.
|
|
27
|
+
`BLUN_NPM_STAGE_DIR` und `BLUN_NPM_ARTIFACT_DIR` können beide Ziele überschreiben;
|
|
28
|
+
beim direkten Skriptaufruf stehen zusätzlich `--output` und `--artifacts` bereit.
|
|
29
|
+
|
|
30
|
+
Der Schritt validiert alle Pflichtartefakte vor dem Leeren des alten Stagings. Er
|
|
31
|
+
kopiert nur die Paket-Hülle, `blun.mjs`, `dist-web`, `native`, Telegrams
|
|
32
|
+
`dist`/Manifest/Commands und die Repo-Skills.
|
|
33
|
+
|
|
34
|
+
## Startmodi
|
|
35
|
+
|
|
36
|
+
`blun` startet die lokale Konsole, ohne Telegram automatisch anzubinden. `king`
|
|
37
|
+
startet dieselbe Konsole und bindet den eingerichteten Telegram-Kanal automatisch
|
|
38
|
+
an. Version, Konto, Modell und Befehle sind ansonsten identisch. Der Unterschied
|
|
39
|
+
gilt nur für den laufenden Prozess; die gespeicherte
|
|
40
|
+
Plugin-Konfiguration wird nicht umgeschrieben.
|
|
41
|
+
|
|
42
|
+
`king` und `king -c` prüfen beim interaktiven Start, ob eine neuere Version
|
|
43
|
+
vorliegt. Automatische Updates sind standardmäßig aktiv und installieren den
|
|
44
|
+
geprüften Zielstand ohne zusätzliche Bestätigung. Danach endet `king`; `king -c`
|
|
45
|
+
setzt die letzte Sitzung mit der neuen Version fort. Mit
|
|
46
|
+
`[upgrade].auto_install = false` in `tui.toml` erscheint stattdessen der sichtbare
|
|
47
|
+
Auswahldialog. Start- und Update-Meldungen sind bei einer neuen Installation
|
|
48
|
+
standardmäßig Englisch; eine ausdrücklich gewählte Sprache bleibt erhalten.
|
|
49
|
+
|
|
50
|
+
Telegram-Chats werden ohne manuell eingegebene IDs verbunden. In der Konsole
|
|
51
|
+
erzeugt `/telegram:access connect` einen einmaligen Code. `/connect CODE` im
|
|
52
|
+
gewünschten privaten Chat oder in einer Gruppe speichert Chat und Absender
|
|
53
|
+
intern; der Code verfällt nach zehn Minuten und ist nur einmal verwendbar.
|
|
54
|
+
|
|
55
|
+
## Standard-MCPs und Eingabesteuerung
|
|
56
|
+
|
|
57
|
+
Beim Start richtet BLUN King `agent-browser`, `blun-language-guard` und unter
|
|
58
|
+
Windows `windows-mcp` automatisch ein und aktiviert erkannte
|
|
59
|
+
Standardkonfigurationen. Context7 wird eingerichtet, bleibt aber standardmäßig
|
|
60
|
+
deaktiviert, weil sein Start hängen bleiben kann. Mit
|
|
61
|
+
`blun tools enable context7` lässt es sich ausdrücklich aktivieren. Eigene,
|
|
62
|
+
abweichende MCP-Befehle bleiben unverändert. `/mcp` zeigt den Betriebszustand
|
|
63
|
+
ohne internen Konfigurationspfad; in der Detailansicht bleibt der Pfad für die
|
|
64
|
+
Fehlersuche verfügbar.
|
|
65
|
+
|
|
66
|
+
Beispiele:
|
|
67
|
+
|
|
68
|
+
```text
|
|
69
|
+
/mcp
|
|
70
|
+
blun tools list
|
|
71
|
+
blun tools enable context7
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Telegram-Nachrichten werden in Eingangsreihenfolge verarbeitet. Trifft eine
|
|
75
|
+
Nachricht im Leerlauf oder während eines aktiven Laufs ein, merkt die
|
|
76
|
+
Warteschlange sie selbstständig für den nächsten sicheren Übergabepunkt vor.
|
|
77
|
+
Eine User-Nachricht wartet nicht auf einen Tastendruck. Private Nachrichten
|
|
78
|
+
bleiben vor Gruppenverkehr priorisiert. Strg+S gibt einen vorhandenen Rückstand
|
|
79
|
+
sofort vollständig und genau einmal frei. Jeder Druck auf Esc gibt genau eine
|
|
80
|
+
weitere wartende Nachricht frei; erst bei leerer Warteschlange bricht Esc den
|
|
81
|
+
aktuellen Lauf ab. Die Warteschlange wird dabei nicht gelöscht. Strg+C bricht
|
|
82
|
+
den aktiven Zug direkt ab, ohne den geschriebenen Entwurf zu löschen.
|
|
83
|
+
Telegram-Nachrichten, die bei bereits aktivem Kernzug eintreffen, werden ohne
|
|
84
|
+
konkurrierenden Start zurückgewiesen und bleiben an der Spitze der
|
|
85
|
+
FIFO-Warteschlange. Für diesen normalen Wartestatus erscheint kein
|
|
86
|
+
`turn.agent_busy`-Fehler.
|
|
87
|
+
|
|
88
|
+
Version 9.1.508 hält TodoList-Marker auch in Terminals mit reduziertem
|
|
89
|
+
Farbumfang sichtbar und verlangt schon bei der ersten mehrstufigen Liste genau
|
|
90
|
+
einen aktiven Punkt. Freigegebene Telegram-Nachrichten aus Gruppe und DM werden
|
|
91
|
+
asynchron, dedupliziert und wiederholbar in Mnemos begrenzten Transcript-Speicher
|
|
92
|
+
übernommen; Loop-Ticks und `/loop`-Steuerbefehle bleiben ausgeschlossen.
|
|
93
|
+
AgentSpine verbindet die Abfrage nur bei Bedarf mit dem engsten Chat-, Themen-
|
|
94
|
+
und Zeitbezug, statt den gesamten Telegram-Verlauf in den Prompt zu laden.
|
|
95
|
+
|
|
96
|
+
Version 9.1.507 fordert das Modell im Read-Werkzeug ausdrücklich dazu auf,
|
|
97
|
+
voneinander unabhängige Datei- und Bereichslesungen in einer Modellantwort zu
|
|
98
|
+
bündeln. Dadurch entfallen vermeidbare Modellrunden, ohne Ausführung,
|
|
99
|
+
Seitennavigation, Berechtigungen oder Ergebnisbehandlung des Werkzeugs zu ändern.
|
|
100
|
+
|
|
101
|
+
Version 9.1.506 entfernt erledigte TodoList-Punkte sofort aus der sichtbaren
|
|
102
|
+
TUI und verwendet fuer den automatischen Wartungszug einen eigenstaendigen,
|
|
103
|
+
546 Zeichen langen Systemprompt statt des rund 19.000 Zeichen langen
|
|
104
|
+
Arbeits-Systemprompts. Der nachfolgende Arbeitsschritt behaelt weiterhin den
|
|
105
|
+
vollstaendigen Prompt und Werkzeugkatalog.
|
|
106
|
+
|
|
107
|
+
Version 9.1.504 startet eine automatisch eingereihte Telegram-Nachricht im
|
|
108
|
+
Leerlauf als neuen Modellzug. Sie wartet damit nicht mehr auf einen bereits
|
|
109
|
+
laufenden Zug, der im Leerlauf definitionsgemäß nie entstehen kann.
|
|
110
|
+
|
|
111
|
+
Version 9.1.503 ergänzt die isolierte Wartungsnachricht um das vom Anbieterpfad
|
|
112
|
+
erwartete leere `toolCalls`-Feld. Dadurch erreicht der Wartungsschritt das Modell,
|
|
113
|
+
statt in der Nachrichten-Normalisierung mit einem TypeError abzubrechen.
|
|
114
|
+
|
|
115
|
+
Version 9.1.502 führt die automatische Todo-Pflege in einem isolierten
|
|
116
|
+
TodoList-Schritt ohne alte Datei-, Shell- oder MCP-Aufrufe aus. Erledigte Punkte
|
|
117
|
+
werden unmittelbar aus der sichtbaren und gespeicherten Liste entfernt; offene,
|
|
118
|
+
blockierte und wartende Arbeit bleibt erhalten. Dadurch wächst die Liste nicht
|
|
119
|
+
endlos und die Pflege erzeugt keinen roten `Tool not found`-Umweg.
|
|
120
|
+
|
|
121
|
+
Version 9.1.501 stellt nach der automatischen Todo-Pflege den normalen
|
|
122
|
+
Werkzeugkatalog wieder her. Dadurch bleiben Read, Bash und die weiteren fuer den
|
|
123
|
+
Arbeitszug ausgewaehlten Werkzeuge nach dem TodoList-Schritt verfuegbar.
|
|
124
|
+
|
|
125
|
+
Version 9.1.500 ist die Golden Release fuer Windows, Linux und macOS. Sie traegt
|
|
126
|
+
den vollstaendigen Funktionsstand von 9.1.499 unveraendert und wird im
|
|
127
|
+
oeffentlichen Changelog mit einer eigenen goldenen Ueberschrift gekennzeichnet.
|
|
128
|
+
|
|
129
|
+
Version 9.1.499 ersetzt Bild-, Audio- und Videodaten außerhalb der neuesten zwölf
|
|
130
|
+
Gesprächsnachrichten ausschließlich in der wiederholten Modellprojektion durch
|
|
131
|
+
kurze Verweise. Aktuelle Medien, Nachrichtentext und vollständiger Sitzungsrohverlauf
|
|
132
|
+
bleiben unverändert. In Fredriks gemessenem Wiederaufnahme-Checkpoint spart der
|
|
133
|
+
Schnitt 85.748 Zeichen beziehungsweise rund 21.437 geschätzte Eingabetoken je
|
|
134
|
+
weiterem Werkzeugschritt.
|
|
135
|
+
|
|
136
|
+
Faellige Todo-Pflege laeuft in 9.1.499 vor dem naechsten Sachwerkzeug als eigener
|
|
137
|
+
kleiner Modellschritt. In diesem Schritt bietet die Laufzeit ausschliesslich
|
|
138
|
+
`TodoList` an; erst nach einer gueltigen Aktualisierung werden Datei-, Such- und
|
|
139
|
+
Shell-Werkzeuge wieder freigegeben. Dadurch entsteht im normalen Ablauf kein
|
|
140
|
+
roter Zwischenfehler. Frische Benutzernachrichten behalten Vorrang.
|
|
141
|
+
|
|
142
|
+
Version 9.1.498 zeigt in `/usage` die gemessene Prompt-Cache-Trefferquote sowie
|
|
143
|
+
gelesene und geschriebene Cache-Token je Modell. `/tokens` ist ein kurzer Alias
|
|
144
|
+
fuer die bereits vorhandene detaillierte Kontextdiagnose; `/offload` ruft die
|
|
145
|
+
vorhandene archivierende Kontextverdichtung auf. Unterschiedliche autorisierte
|
|
146
|
+
Botnachrichten werden nicht mehr durch ein starres 15-Sekunden-Fenster verworfen.
|
|
147
|
+
Nach einer vollständigen Verdichtung bleibt die exakte Todo-Liste erhalten. Ein
|
|
148
|
+
einmaliger Wiederherstellungshinweis verlangt bei unsicheren Pfaden, Befehlen,
|
|
149
|
+
Hashes oder Anforderungen zuerst das Lesen des archivierten Verlaufs, bevor eine
|
|
150
|
+
breite Dateisuche oder ein Neubeginn zulässig ist.
|
|
151
|
+
Erledigte Todo-Schritte bleiben als Nachweis erhalten. Neue widersprüchliche
|
|
152
|
+
Erkenntnisse werden als eigener laufender Schritt mit Begründung ergänzt, statt
|
|
153
|
+
einen bereits belegten Abschluss still zurückzustufen oder zu entfernen.
|
|
154
|
+
Wiederkehrende Session-Loops warten außerdem, solange die gepflegte Todo-Liste
|
|
155
|
+
noch laufende oder ausstehende Arbeit enthält. Verpasste Intervalle werden bis
|
|
156
|
+
zum echten Leerlauf zusammengefasst; andere geplante Erinnerungen bleiben davon
|
|
157
|
+
unberührt.
|
|
158
|
+
|
|
159
|
+
Version 9.1.497 priorisiert Telegram-Botnachrichten aus gemeinsamen Gruppen
|
|
160
|
+
hinter privaten und ausdrücklich adressierten Nachrichten, aber vor normalem
|
|
161
|
+
Kontext. Die Priorisierung erzwingt keine Antwort. Eine angenommene
|
|
162
|
+
Telegram-Nachricht verschwindet jetzt aus der sichtbaren Queue, sobald ihr
|
|
163
|
+
eingespielter Modellschritt wirklich beginnt. Fällige Telegram-Antworten und
|
|
164
|
+
Nachrichtenbearbeitungen dürfen außerdem die Todo-Pflege passieren; der nächste
|
|
165
|
+
normale Arbeitsschritt bleibt bis zur wahrheitsgemäßen Aktualisierung blockiert.
|
|
166
|
+
|
|
167
|
+
Version 9.1.496 stellt Telegram-Nutzernachrichten automatisch einzeln zu, ohne
|
|
168
|
+
die automatische Zustellung an den manuellen Strg+S-/Escape-Zähler zu koppeln.
|
|
169
|
+
Nach Annahme oder Antwort wird nur die exakt verarbeitete Nachrichten-ID aus der
|
|
170
|
+
sichtbaren Queue entfernt; spätere Meldungen desselben Chats bleiben erhalten.
|
|
171
|
+
Vorhandene Todo-Listen bleiben auch ohne aktives Ziel verbindlich und müssen nach
|
|
172
|
+
längerer Arbeit belegbaren Fortschritt zeigen. Erfolgreiche interne Hook-Ausgaben
|
|
173
|
+
bleiben unsichtbar, blockierende Hook-Fehler werden weiterhin angezeigt.
|
|
174
|
+
|
|
175
|
+
Version 9.1.495 startet jedes neue Ziel mit einer frischen sichtbaren Todo-Liste,
|
|
176
|
+
erzwingt regelmäßige wahrheitsgemäße Fortschrittsstände und quittiert normale
|
|
177
|
+
Telegram-Nachrichten erst am Zugende. Dadurch bleiben sie nach einem Neustart
|
|
178
|
+
wiederholbar, bis ihre Verarbeitung wirklich abgeschlossen ist. Erfolgreich
|
|
179
|
+
beantwortete Gruppenmeldungen verschwinden sofort aus der sichtbaren Queue.
|
|
180
|
+
Zusätzliche Regressionstests prüfen Strg+S und Strg+T als echte Terminalsequenzen,
|
|
181
|
+
auch bei aktiver Feststelltaste.
|
|
182
|
+
|
|
183
|
+
Version 9.1.494 trennt die Tastenkürzel wieder eindeutig: Strg+S steuert nur
|
|
184
|
+
den Queue-Rückstand, Strg+T nur die Todo-Liste. Version 9.1.493 stellt die
|
|
185
|
+
automatische Zustellung von User-Nachrichten auch
|
|
186
|
+
für Telegram-Gruppen wieder her. Version 9.1.492 schützt Veröffentlichungen
|
|
187
|
+
zusätzlich mit einer verpflichtenden
|
|
188
|
+
Metadatenprüfung. Packen und Veröffentlichen brechen ab, wenn Paketversion,
|
|
189
|
+
erster Changelog-Eintrag oder Installationshinweise auseinanderlaufen. Die
|
|
190
|
+
abschließende externe Prüfung vergleicht npm, Paketintegrität, öffentliches
|
|
191
|
+
Update-Manifest und öffentliche Changelog-Seite.
|
|
192
|
+
|
|
193
|
+
Version 9.1.491 stellt außerdem die interne Todo-Liste wieder her. Deutsche
|
|
194
|
+
Aufgabenlisten-Befehle wählen wieder TodoList statt der getrennten TaskList für
|
|
195
|
+
Hintergrundprozesse. Lesen, Ersetzen, Aktualisieren und Leeren funktionieren in
|
|
196
|
+
derselben Sitzung; eine vollständig erledigte Liste wird aus der Anzeige
|
|
197
|
+
entfernt. AgentSpine wird beim Start in allen vorhandenen lokalen Profilen
|
|
198
|
+
installiert und aktiviert. Bilder laufen vorrangig über den verwalteten
|
|
199
|
+
BLUN-Bildlesedienst auf der RTX-Infrastruktur; ein lokaler experimenteller
|
|
200
|
+
Leser ist nur noch ein Fallback, wenn kein verwalteter Mediadienst existiert.
|
|
201
|
+
|
|
202
|
+
Ab BLUN King 9.1.416 bleiben alle Ergebnisse des jüngsten Werkzeugaufrufs bis
|
|
203
|
+
zur nächsten Assistentenantwort vollständig im Modellkontext. Das gilt auch für
|
|
204
|
+
große parallele Read-, Grep- und Bash-Aufrufe sowie für nachträglich
|
|
205
|
+
eingespielte Telegram- oder Steuerungsnachrichten. Offloader, historische
|
|
206
|
+
Bereinigung und Mikrokompaktierung verwenden dafür dieselbe semantische Grenze.
|
|
207
|
+
Erst nach der nachweislichen Auswertung darf ein Ergebnis archiviert oder
|
|
208
|
+
gekürzt werden.
|
|
209
|
+
|
|
210
|
+
Ab BLUN King 9.1.417 schneiden automatische Telegram-Rückfallantworten Texte
|
|
211
|
+
nicht mehr bei 4.096 Zeichen ab. Längere Antworten werden in
|
|
212
|
+
aufeinanderfolgenden Nachrichten vollständig zugestellt; dabei bleiben jedes
|
|
213
|
+
Zeichen und jedes Unicode-Surrogatpaar erhalten. Im Ausgangsprotokoll stehen
|
|
214
|
+
sämtliche zurückgegebenen Nachrichten-IDs zusammen mit dem vollständigen Text.
|
|
215
|
+
Schlägt ein Teil fehl, endet die Zustellung an dieser Stelle, statt die Antwort
|
|
216
|
+
fälschlich als vollständig zu melden.
|
|
217
|
+
|
|
218
|
+
Ab BLUN King 9.1.418 übernimmt der Identitätsgraph die von Telegram bestätigte
|
|
219
|
+
Unterscheidung zwischen Menschen und Bots. Bereits vorhandene
|
|
220
|
+
Telegram-Kontakte, die mangels dieses Merkmals als Menschen angelegt wurden,
|
|
221
|
+
werden bei der nächsten eindeutig als Bot bestätigten Nachricht einmalig als
|
|
222
|
+
Agent korrigiert. Alle Rollen, Zuständigkeiten, Beziehungsnotizen und sonstigen
|
|
223
|
+
Felder bleiben unverändert. Ein Agent wird niemals zu einer Person
|
|
224
|
+
zurückgestuft; Namen oder Benutzernamen dienen nicht als Beweis.
|
|
225
|
+
|
|
226
|
+
`Strg+C` und `Esc` brechen einen aktiven Zug zuverlässig ab, ohne den bereits
|
|
227
|
+
geschriebenen Entwurf zu löschen. Das gilt auch bei Autovervollständigung,
|
|
228
|
+
Geistervorschlägen, Bash-Eingabe und einer noch offenen Mehrzeileneingabe.
|
|
229
|
+
|
|
230
|
+
Ab BLUN King 9.1.419 setzt eine natürlich fortgesetzte Sitzung ein bereits
|
|
231
|
+
aktives Ziel selbstständig fort, wenn dessen gespeicherter nächster Auslöser
|
|
232
|
+
ausdrücklich sofort gilt und Auto- oder God-Modus aktiv ist. Die Fortsetzung
|
|
233
|
+
erscheint nicht als erfundene Benutzernachricht und wird pro Sitzung nur einmal
|
|
234
|
+
angestoßen. Wartende, pausierte und blockierte Ziele sowie manuelle
|
|
235
|
+
Berechtigungsmodi starten weiterhin nicht selbstständig.
|
|
236
|
+
|
|
237
|
+
Ab BLUN King 9.1.420 beendet ein aktives Ziel mit dauerhaftem
|
|
238
|
+
Warte-Checkpoint die autonome Fortsetzung nach dem aktuellen Zug, ohne das Ziel
|
|
239
|
+
zu verwerfen. Externe, zeitliche, abhängige und nutzerabhängige Auslöser
|
|
240
|
+
erzeugen dadurch keine leeren Folgezüge. Beim nächsten Ereignis wird der
|
|
241
|
+
gespeicherte Auslöser erneut eingeordnet. Sofortige Ziele und ältere Ziele ohne
|
|
242
|
+
Checkpoint laufen unverändert weiter.
|
|
243
|
+
|
|
244
|
+
Ab BLUN King 9.1.421 muss ein wartendes Ziel mit Zeit-Trigger einen genauen
|
|
245
|
+
`dueAt`-Zeitpunkt speichern. Der Zeitpunkt wird auf UTC normalisiert. Bei einem
|
|
246
|
+
natürlichen Sitzungsstart im Auto- oder God-Modus wartet das Ziel vor diesem
|
|
247
|
+
Zeitpunkt weiter und startet, sobald der Zeitpunkt erreicht oder überschritten
|
|
248
|
+
ist. Der erste Fortsetzungszug erhält die gespeicherte Fälligkeit als
|
|
249
|
+
ausdrücklichen Trigger-Beleg. Andere Trigger-Arten dürfen kein `dueAt`
|
|
250
|
+
enthalten. Ein Laufzeit-Wecker für eine durchgehend geöffnete Sitzung ist in
|
|
251
|
+
diesem Release noch nicht enthalten.
|
|
252
|
+
|
|
253
|
+
Ab BLUN King 9.1.422 überwacht auch eine durchgehend geöffnete, untätige Sitzung ihren gespeicherten Zeit-Trigger. Sobald `dueAt` erreicht oder überschritten ist, fügt der Auto- oder God-Modus genau eine verborgene Fortsetzung in dieselbe Sitzung ein. Wird der Zeitpunkt während einer laufenden Antwort, Verdichtung, wartenden Nachricht, eines Befehls oder Dialogs fällig, wartet die Fortsetzung bis zum Leerlauf. Unmittelbar vor dem Start liest King Ziel, Checkpoint-Revision, Fälligkeit, Berechtigungsmodus und Sitzung erneut; ein geänderter oder veralteter Trigger kann deshalb nicht auslösen. Stoppen, Notausgang, Entladen und Wechseln der Sitzung entsorgen den Timer. Im manuellen Modus erfolgt kein selbstständiger Start.
|
|
254
|
+
|
|
255
|
+
## Zuverlässiger King-Start
|
|
256
|
+
|
|
257
|
+
Bei einer vom Server ausdrücklich als wiederholbar gekennzeichneten
|
|
258
|
+
Überlastung (`HTTP 429`, `x-should-retry: true`) wartet BLUN King entsprechend
|
|
259
|
+
`Retry-After` und sendet dieselbe Anfrage höchstens zweimal erneut. Andere
|
|
260
|
+
Fehler und dauerhaft überlastete Server bleiben klar begrenzt und sichtbar.
|
|
261
|
+
|
|
262
|
+
Der Windows-Hilfsprozess für private Pfade übernimmt `TEMP` und `TMP` aus der
|
|
263
|
+
Benutzersitzung. Dadurch kann der C#-Compiler für die ACL-Prüfung auch unter
|
|
264
|
+
einem normalen Benutzerkonto arbeiten. Scheitert der Unterprozess, nennt die
|
|
265
|
+
Fehlermeldung jetzt dessen tatsächliche Ursache.
|
|
266
|
+
|
|
267
|
+
Ein bereits laufender Telegram-Prozess blockiert Aktualisierungen nicht mehr.
|
|
268
|
+
Unveränderte Plugin-Dateien werden wiederverwendet; geänderte Dateien werden in
|
|
269
|
+
einem inhaltsadressierten Verzeichnis daneben installiert. Der neue Prozess
|
|
270
|
+
verwendet den neuen Pfad, während der bisherige Prozess seinen geladenen Stand
|
|
271
|
+
geordnet beenden kann.
|
|
272
|
+
|
|
273
|
+
Beim Fortsetzen mit `--continue` oder `--session` wird der Arbeitsbereich der
|
|
274
|
+
bestehenden Sitzung direkt verwendet. Die Ordnerauswahl bleibt neuen Starts
|
|
275
|
+
vorbehalten und kann eine Fortsetzung daher nicht mehr vorzeitig beenden.
|
|
276
|
+
|
|
277
|
+
## Schnellstart
|
|
278
|
+
|
|
279
|
+
Beim Starten oder Fortsetzen einer Sitzung werden die Skill-Verzeichnisse
|
|
280
|
+
parallel geprüft und eingelesen. Die Skills werden weiterhin in der
|
|
281
|
+
ursprünglichen, festen Reihenfolge registriert; Priorität und Verhalten bei
|
|
282
|
+
doppelten Namen bleiben unverändert.
|
|
283
|
+
|
|
284
|
+
## Kontextentlastung bei langen Sitzungen
|
|
285
|
+
|
|
286
|
+
King bewahrt den vollständigen Verlauf weiterhin im Sitzungs-Wire auf. Bei 75 Prozent der wirksamen Verdichtungsgrenze ersetzt die Modellprojektion ältere große Werkzeugergebnisse sowie große Argumente abgeschlossener Werkzeugaufrufe durch kurze Platzhalter. Die Druckmessung verwendet die frühere Grenze aus Modellfenster und Vollverdichtungsbudget; bei einem Modellfenster von 1.048.576 Token und einer Vollverdichtung bei 256.000 Token liegt der Mikrodruckpunkt daher bei 192.000 Token. Werkzeugargumente werden nur entlastet, wenn ein zugehöriges Werkzeugergebnis vorliegt und die gespeicherten Argumente gültiges JSON sind. Die letzten 20 Nachrichten bleiben unverändert. Solange der Prefix-Cache warm ist, wird der Schnitt höchstens nach jeweils 20 weiteren Nachrichten verschoben. Nach einer Stunde ohne Modellantwort darf er sofort nachziehen.
|
|
287
|
+
|
|
288
|
+
Dabei werden keine gespeicherten Nachrichten geändert oder gelöscht. Fortsetzen, Exportieren und die sichtbare Historie behalten die ursprünglichen Werkzeugergebnisse und Werkzeugargumente. Das Telemetrieereignis `micro_compaction_finished` nennt den Auslöser, den Schnitt, die verwendete Druckgrenze, das Modellfenster und die geschätzte Tokenzahl vor und nach der Entlastung. Außerdem zählt es getrennt, wie viele Werkzeugergebnisse und Werkzeugargumente entlastet wurden. Der Sitzungsinspektor summiert zusätzlich die eingesparten Argument-Token, ohne Inhalte offenzulegen. Beispiel: Ein früherer `Write`-Aufruf mit einem vollständigen Dateiinhalt bleibt im Wire erhalten; die Modellprojektion trägt nur noch einen Platzhalter, sobald für diesen `Write`-Aufruf ein zugehöriges Ergebnis vorliegt.
|
|
289
|
+
|
|
290
|
+
Ab BLUN King 9.1.98 kann King einen abgeschlossenen Arbeitsabschnitt verdichten, bevor die harte automatische Grenze erreicht ist. Unterhalb der halben Vollverdichtungsgrenze bleibt `CompactConversation` vollständig aus dem Modellprompt. Ab 128.000 geschätzten Token im Standardmodellfenster wird es für den nächsten Modellschritt verfügbar. Die Verdichtung beginnt erst nach Abschluss des aktuellen Werkzeugschritts, öffnet keinen konkurrierenden Zug und lässt den ursprünglichen Verlauf bei einem Fehlschlag unverändert.
|
|
291
|
+
|
|
292
|
+
## Große Werkzeugausgaben und isolierte Teilagenten
|
|
293
|
+
|
|
294
|
+
Große textbasierte Werkzeugergebnisse bleiben nicht mehr vollständig im Modellkontext. Ab 12.001 Zeichen speichert BLUN King das vollständige Ergebnis in einer privaten Datei im Sitzungsordner `tool-results`. Im Modellkontext verbleiben die ersten 1.000 und die letzten 1.000 Zeichen, die genaue Zahl der ausgelassenen Zeichen und der `output_path`. Der Agent kann das vollständige Ergebnis anschließend mit `Read` seitenweise über diesen Pfad lesen. Ergebnisse bis einschließlich 12.000 Zeichen, gemischte Medienergebnisse und bereits gekürzte Ergebnisse bleiben unverändert. Auch eine spätere Mikroverdichtung bewahrt den Dateiverweis. Beispiel: Bei einem Suchergebnis mit 30.000 Zeichen sehen folgende Modellanfragen den Anfang und das abschließende Ergebnis oder den Fehler; der vollständige Text bleibt lokal verfügbar.
|
|
295
|
+
|
|
296
|
+
Version 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.
|
|
297
|
+
|
|
298
|
+
Version 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.
|
|
299
|
+
|
|
300
|
+
Version 9.1.106 erlaubt Agentenprofilen, Werkzeuge namentlich auszuschließen. King wendet diese Ausschlüsse erst an, nachdem dauerhaft geladene, dynamisch nachgeladene und MCP-Werkzeuge zusammengestellt wurden. Die Standardprofile `coder`, `explore` und `plan` können über Telegram weder antworten noch reagieren, Nachrichten bearbeiten oder Anhänge herunterladen; der Hauptagent bleibt unverändert. So senden delegierte Agenten keine Nachrichten am Hauptagenten vorbei, und ihre Modellanfragen enthalten weniger Werkzeugschemas. Nicht gefundene, namentlich angegebene Werkzeuge werden sichtbar gemeldet.
|
|
301
|
+
|
|
302
|
+
Version 9.1.109 hält nur noch die neun Werkzeuge dauerhaft in der Modellanfrage, auf die mehr als 98 Prozent von Fredriks 3.183 gemessenen Werkzeugaufrufen 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.
|
|
303
|
+
|
|
304
|
+
Version 9.1.127 verkürzt zusätzlich den wiederholten `ToolSearch`-Katalog. Eindeutige zurückgestellte Werkzeuge erscheinen dort nur noch mit ihrem kurzen Selektor; nur bei gleichnamigen Werkzeugen bleibt der vollständige Name stehen. Suche, exakte Auswahl, Telegram-Anhänge und bereits geladene Werkzeuge funktionieren unverändert. Dadurch kennt King weiterhin alle verfügbaren Werkzeuge, sendet aber die langen MCP-Namensräume nicht mehr bei jedem Modellschritt erneut.
|
|
305
|
+
|
|
306
|
+
Version 9.1.128 begrenzt außerdem den dauerhaften Cache nachgeladener Werkzeug-Schemas auf die zwölf zuletzt ausgewählten Werkzeuge. Ein erneut ausgewähltes Werkzeug rückt ans Ende und bleibt erhalten; nur die ältesten, lange nicht verwendeten Schemas fallen aus der nächsten Modellanfrage und sind weiterhin sofort über `ToolSearch` auffindbar. Werkzeuge des laufenden Schritts bleiben vollständig verfügbar. Dadurch kann die Schemalast auch in sehr langen Sitzungen nicht ungebremst anwachsen.
|
|
307
|
+
|
|
308
|
+
Version 9.1.129 entfernt in langen Sitzungen außerdem die Vorschautexte aus älteren, bereits ausgelagerten Werkzeugergebnissen. Im aktuellen Arbeitsfenster bleiben die letzten 20 Nachrichten vollständig lesbar; ältere Verweise behalten Pfad und Größenangaben, während der vollständige Inhalt unverändert in der Originaldatei oder im privaten Archiv liegt. In Fredriks aktuellem Verlauf spart das pro Anfrage zusätzlich 8.258 Zeichen, also rund 2.065 Token.
|
|
309
|
+
|
|
310
|
+
Ab BLUN King 9.1.130 verdichtet die Modellprojektion zusätzlich die erläuternden Texte älterer, abgeschlossener Werkzeugschritte. Werkzeugnamen, Kennungen, Argumente, Ergebnisse, nicht textbasierte Inhalte und die letzten 20 Nachrichten bleiben unverändert; ausstehende Werkzeugaufrufe werden niemals verdichtet. Auch der gespeicherte Rohverlauf und Exporte bleiben vollständig. In Fredriks aktueller Sitzung verkleinert dies jede weitere Modellanfrage um zusätzliche 15.011 Zeichen, also um etwa 3.753 geschätzte Token.
|
|
311
|
+
|
|
312
|
+
Ab BLUN King 9.1.132 wird der schlanke Basissystemprompt nach der generierten Initialisierung des Standardprofils wiederhergestellt. Zuvor überschrieb der Initialisierer den vorhandenen Prompt mit 4.850 Zeichen durch einen eingebetteten älteren Prompt mit 23.109 Zeichen. Der zur Laufzeit verwendete Prompt bleibt nun tatsächlich bei 4.850 Zeichen. Das spart pro Modellanfrage 18.259 Zeichen, also etwa 4.565 geschätzte Token. Anweisungen oder Werkzeuge werden nicht entfernt; die Änderung korrigiert ausschließlich die Initialisierungsreihenfolge.
|
|
313
|
+
|
|
314
|
+
Ab BLUN King 9.1.133 werden die projektlokale und die gemeinsame `Mistake.md` nicht mehr als zwei getrennte Promptblöcke gesendet. King wählt aus beiden Quellen höchstens fünf relevante vollständige Einträge innerhalb eines gemeinsamen Budgets von 6.000 Zeichen aus. Die vollständigen Dateien, Writer, Archive, Register, der Rohverlauf und Exporte bleiben unverändert. Die Auswahl erfolgt lokal und deterministisch und benötigt keinen zusätzlichen Modell-, Embedding- oder Netzwerkaufruf. Mit Fredriks aktuellen Dateien sinkt die wiederholte Modellsicht um 12.917 bis 16.811 Zeichen, also um etwa 3.230 bis 4.203 geschätzte Token pro Anfrage.
|
|
315
|
+
|
|
316
|
+
Ab BLUN King 9.1.134 begrenzt die Modellprojektion nicht adressierte Telegram-Gruppennachrichten auf eine nachvollziehbare Vorschau von 2.000 Zeichen. Anfang und Ende bleiben erhalten, eine Markierung nennt die ursprüngliche Länge. Direkt an den Agenten gerichtete Nachrichten, die sichtbare Telegram-Historie, der Rohverlauf und Exporte bleiben vollständig. In Fredriks realem Verlauf betraf die Grenze 211 von 517 verschiedenen mitgelesenen Gruppenmeldungen und hätte 102.466 wiederholt übertragene Zeichen eingespart, also rund 25.617 geschätzte Token über die gemessenen Modellanfragen.
|
|
317
|
+
|
|
318
|
+
Ab BLUN King 9.1.137 schützt die Modellprojektion nur noch die zwölf neuesten Nachrichten vollständig vor der Auslagerung älterer Werkzeugausgaben. Große Ergebnisse bleiben im Rohverlauf und in der ursprünglichen Datei oder im privaten Archiv vollständig erhalten; die Modellprojektion behält einen lesbaren Verweis. In Fredriks gemessenem Verlauf werden dadurch mindestens 9.289 weitere Zeichen, also etwa 2.322 geschätzte Token, pro Modellanfrage vermieden.
|
|
319
|
+
|
|
320
|
+
Ab BLUN King 9.1.138 enthält die Modellprojektion von jedem wiederkehrenden Cron-Auftrag nur noch den neuesten ausstehenden Weckhinweis. Einmalige Erinnerungen, unterschiedliche Aufträge sowie fehlerhafte oder nicht eindeutig zugeordnete Nachrichten bleiben unverändert. Der vollständige Sitzungs-Wire bleibt erhalten. In Fredriks aktueller Sitzung entfallen dadurch bei jeder Anfrage 12.012 Zeichen, also rund 3.003 geschätzte Token.
|
|
321
|
+
|
|
322
|
+
Ab BLUN King 9.1.139 begrenzt die Modellprojektion ältere, nicht adressierte Telegram-Kanalteile auf 500 Zeichen pro Nachricht. Die neueste Nutzernachricht, adressierte Kanalteile, Anhänge und der vollständige Sitzungs-Wire bleiben unverändert. In Fredriks aktueller Sitzung entfallen dadurch bei jeder Anfrage 9.389 Zeichen, also rund 2.348 geschätzte Token.
|
|
323
|
+
|
|
324
|
+
Ab BLUN King 9.1.140 begrenzt die relevanzbasierte Mistake-Erinnerung den zusätzlich eingeblendeten Regelkontext standardmäßig auf 4.000 Zeichen. Die vollständigen Mistake-Dateien und der Sitzungs-Wire bleiben unverändert; nur die Modellprojektion erhält die engere Auswahl. In Fredriks gemessenem Lauf sinkt der Hinweis dadurch von 6.037 auf höchstens 4.000 Zeichen. Das spart mindestens 2.037 Zeichen beziehungsweise rund 509 geschätzte Token pro Anfrage.
|
|
325
|
+
|
|
326
|
+
Ab BLUN King 9.1.141 entfernt die Modellprojektion die Argumente älterer, abgeschlossener Werkzeugaufrufe bereits ab 32 geschätzten Token. Für Werkzeugergebnisse gilt weiterhin die bisherige Schwelle. Die 20 neuesten Nachrichten, noch nicht abgeschlossene Aufrufe, fehlerhaftes JSON und der Sitzungsrohverlauf bleiben unverändert. In Fredriks aktueller Sitzung sinkt die Projektion dadurch pro Modellanfrage um weitere 10.544 Zeichen beziehungsweise rund 2.636 geschätzte Token.
|
|
327
|
+
|
|
328
|
+
Ab BLUN King 9.1.142 behält die Modellprojektion von älteren, nicht adressierten Telegram-Kanalteilen statt 500 nur noch eine 250 Zeichen lange Vorschau mit Anfang und Ende. Adressierte Kanalteile, die neueste Nutzernachricht, Anhänge, fehlerhaftes Kanal-Markup, Rohverlauf und Exporte bleiben unverändert. In Fredriks aktueller Sitzung spart das pro Modellanfrage weitere 9.221 Zeichen beziehungsweise rund 2.305 geschätzte Token.
|
|
329
|
+
|
|
330
|
+
Ab BLUN King 9.1.143 entfernt die Modellprojektion bei älteren Nachrichten den wiederholten Telegram-Plugin-Transporthinweis, nachdem die Nachricht in den Verlauf übernommen wurde. Der Kanalinhalt sowie sämtliche Angaben zu Absender, Chat, Nachricht, Zeitstempel, Anhängen und Adressierung bleiben vollständig erhalten. Die neueste Nutzernachricht und der fortlaufend ergänzte Sitzungs-Wire bleiben unverändert. In Fredriks aktueller Sitzung entfallen dadurch bei jeder Modellanfrage 2.890 Zeichen beziehungsweise rund 723 geschätzte Token.
|
|
331
|
+
|
|
332
|
+
Ab BLUN King 9.1.144 begrenzt die Modellprojektion adressierte Telegram-Abschnitte außerhalb der neuesten 20 Nachrichten 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. In Fredriks vermessener Sitzung entfallen dadurch bei jeder Modellanfrage 34.435 Zeichen beziehungsweise rund 8.609 geschätzte Token.
|
|
333
|
+
|
|
334
|
+
Ab 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.
|
|
335
|
+
|
|
336
|
+
Ab 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 Fredriks vermessenem Verlauf reduziert das die wiederholte Modelleingabe um 26.779 Zeichen beziehungsweise rund 6.695 geschätzte Token pro Anfrage.
|
|
337
|
+
|
|
338
|
+
Ab 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 Fredriks vermessenem Verlauf spart das weitere 560 Zeichen beziehungsweise rund 140 geschätzte Token pro Anfrage.
|
|
339
|
+
|
|
340
|
+
Ab 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 Fredriks vermessenem 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.
|
|
341
|
+
|
|
342
|
+
Ab 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 Fredriks stabil vermessenem 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.
|
|
343
|
+
|
|
344
|
+
Ab 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 Fredriks stabil vermessenem 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.
|
|
345
|
+
|
|
346
|
+
Ab 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 Fredriks stabil vermessenem Schnappschuss werden sieben zusätzliche historische adressierte Abschnitte verkleinert. Das spart 3.500 Zeichen beziehungsweise rund 875 geschätzte Token pro wiederholter Anfrage.
|
|
347
|
+
|
|
348
|
+
Ab 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.
|
|
349
|
+
|
|
350
|
+
Ab 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 Fredriks frisch vermessenem 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.
|
|
351
|
+
|
|
352
|
+
Ab 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 Fredriks vermessenem 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.
|
|
353
|
+
|
|
354
|
+
Ab 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 Fredriks vermessenem 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.
|
|
355
|
+
|
|
356
|
+
Ab 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 Fredriks vermessenem 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.
|
|
357
|
+
|
|
358
|
+
Ab BLUN King 9.1.136 behält die Modellprojektion nur noch den neuesten dynamischen `Mistake.md`-Hinweis. Ältere, zugbezogene Auswahlen bleiben im Sitzungsrohverlauf und in Exporten erhalten, werden nach einer neueren Auswahl aber nicht mehr erneut an das Modell gesendet. Andere geänderte Hinweise bleiben unberührt. In Fredriks aktueller Sitzung lagen fünf `Mistake.md`-Auswahlen vor; das Entfernen der vier überholten Kopien spart pro Modellanfrage 24.143 Zeichen, also etwa 6.036 geschätzte Token.
|
|
359
|
+
|
|
360
|
+
Ab BLUN King 9.1.131 entfernt die Modellprojektion zwei ältere Regelkopien aus dem Systemprompt, sobald gleichwertige Regeln im Conduct-Abschnitt vorhanden sind. Betroffen sind ausschließlich die doppelten Hinweise zu Ehrlichkeit und Zugangsdaten; die vollständigen Conduct-Regeln und alle übrigen Prompt-Abschnitte bleiben unverändert. In der ausgelieferten Standardvorlage sinkt der wiederholt gesendete Prompt dadurch um 1.010 Zeichen, also um etwa 253 geschätzte Token pro Modellanfrage. Fehlt eines der Conduct-Gegenstücke, bleibt die entsprechende ältere Regel unverändert erhalten.
|
|
361
|
+
|
|
362
|
+
Ab BLUN King 9.1.118 bleibt der Sitzungszeitstempel im Systemprompt während einer laufenden Sitzung unverändert. Das erneute Einlesen von Verzeichnisübersicht, AGENTS.md-Dateien, Zusatzverzeichnissen und Skillinformationen kann den Prompt weiterhin ändern, wenn sich die jeweiligen Quellen tatsächlich verändert haben. Bleiben diese Quellen gleich, entwertet die Aktualisierung nach einer Verdichtung den Präfix-Cache des Anbieters nicht mehr allein durch einen neuen Zeitstempel. In Fredriks gemessener Sitzung unterschieden sich die beiden letzten Systemprompts mit jeweils 68.631 Zeichen nur in der Zeitangabe, und zwar erst nach einem gemeinsamen Präfix von 27.111 Zeichen. Der geänderte Zeitstempel verhinderte damit die Wiederverwendung der übrigen 41.512 unveränderten Zeichen aus dem Präfix-Cache.
|
|
363
|
+
|
|
364
|
+
Ab BLUN King 9.1.119 enthält der bei jedem Modellschritt erneut gesendete Prompt nur noch eine kleine Auswahl häufig benötigter Skills. Alle übrigen registrierten Skills bleiben verfügbar und lassen sich über das Skill-Werkzeug anhand ihres Namens oder Zwecks suchen; der ausgewählte Skill wird anschließend bei Bedarf geladen. Dadurch sinkt die wiederholt übertragene Promptlast, ohne Skills zu löschen oder die vollständige Ansicht unter `/skills` einzuschränken.
|
|
365
|
+
|
|
366
|
+
Ab BLUN King 9.1.120 lagert die Konsole auch große ältere Assistentenantworten aus dem aktiven Modellkontext in private Sitzungsdateien aus. Der vollständige Gesprächsverlauf bleibt erhalten; im Modellkontext verbleiben eine begrenzte Vorschau und der Dateipfad. Die 20 neuesten Nachrichten sowie Assistentenantworten mit Werkzeugaufrufen bleiben unverändert, damit laufende Arbeit und Aufrufketten vollständig verfügbar sind.
|
|
367
|
+
|
|
368
|
+
Ab BLUN King 9.1.121 begrenzt die Modellprojektion auch die Gesamtgröße älterer, mittelgroßer Werkzeugergebnisse, die ausschließlich Text enthalten. Überschreiten Werkzeugergebnisse außerhalb der letzten 20 Nachrichten zusammen 12.000 Zeichen, archiviert King so viele der größten geeigneten Ergebnisse wie nötig und behält nur kompakte, lesbare Dateiverweise im Modellkontext. Der nur ergänzte Rohverlauf und die vollständigen Ergebnisse bleiben unverändert. Gemischte Medienergebnisse und die letzten 20 Nachrichten werden nicht angetastet. In einer gemessenen Sitzung von Fredrik wählte dieser Schnitt 12 ältere Ergebnisse aus und verringerte die projizierte alte Werkzeugausgabe um mindestens 63.444 Zeichen, also um etwa 15.861 geschätzte Token.
|
|
369
|
+
|
|
370
|
+
Ab BLUN King 9.1.122 wird die vollständige integrierte Designrichtlinie nicht mehr bei jeder Modellanfrage mitgesendet. Nicht visuelle Arbeit erhält nur noch einen kompakten Aktivierungsvertrag. Vor Arbeiten an Benutzeroberflächen, Frontends, visueller Gestaltung, Interaktionen, Design oder Barrierefreiheit lädt King die vollständige Richtlinie über das Skill-Werkzeug; vom Nutzer ausgewählte Design-Skills bleiben zusätzlich verfügbar. Auch bestehende Sitzungen profitieren davon, ohne dass ihr nur ergänzter Rohverlauf umgeschrieben wird, denn verkürzt wird ausschließlich die Modellprojektion. Die Auslagerung älterer reiner Textausgaben von Werkzeugen erzielt nun außerdem die bestmögliche Entlastung, wenn allein die ausgenommenen kleinen Ergebnisse bereits über dem Ziel von 12.000 Zeichen liegen, statt in diesem Fall die gesamte Entlastung abzubrechen. In Fredriks aktuell vermessener Sitzung wurden 14 ältere Werkzeugergebnisse ausgewählt; die projizierte alte Werkzeugausgabe sank dadurch von 77.342 auf 12.418 Zeichen. Zusammen mit der bedarfsgeladenen Designrichtlinie sowie den bestehenden Auslagerungen von Nutzer- und Assistentennachrichten sank die gemessene Projektion von 322.780 Rohzeichen auf 109.656 Zeichen, also auf etwa 27.414 geschätzte Token. Die neuesten 20 Nachrichten, gemischte Medien, der Rohverlauf, Exporte und die vollständige bedarfsgeladene Designrichtlinie bleiben unverändert.
|
|
371
|
+
|
|
372
|
+
Ab BLUN King 9.1.123 entlastet die Modellprojektion zusätzlich die Argumente älterer, bereits abgeschlossener Werkzeugaufrufe. Name, Kennung und Ergebnis bleiben erhalten; nur die wiederholte Übertragung großer alter JSON-Argumente entfällt. Unbeantwortete Werkzeugaufrufe, ungültige JSON-Argumente und die neuesten 20 Nachrichten bleiben vollständig. Der gespeicherte Rohverlauf und Exporte werden nicht verändert. In Fredriks gemessener Projektion sank der Anfrageumfang dadurch von 101.459 auf 94.026 Zeichen, also um etwa 1.859 geschätzte Token je Anfrage.
|
|
373
|
+
|
|
374
|
+
Ab BLUN King 9.1.126 wird die laufzeitweite `Mistake.md` nicht mehr bei jedem Zug vollständig mitgesendet. King wählt deterministisch bis zu fünf Abschnitte aus, die zu den letzten vier Nutzernachrichten passen, und bevorzugt dabei wiederverwendbare Regeln, Bedingungen und Gegenproben. Die Auswahl ist auf 6.000 Zeichen begrenzt und ersetzt den vorherigen Hinweis, statt weitere Kopien anzusammeln. Die vollständige Datei, ihr Register, ihr Archiv und ihr Schreibweg bleiben unverändert. Dafür ist kein zusätzlicher Modell-, Einbettungs- oder Netzwerkaufruf nötig. In der aktuell gemessenen laufzeitweiten Datei sank die Modellsicht abhängig von der Anfrage von 13.470 Zeichen auf 2.921 bis 4.819 Zeichen.
|
|
375
|
+
|
|
376
|
+
Ab BLUN King 9.1.99 werden auch direkt aufeinanderfolgende reine Textergebnisse als Stapel betrachtet. Enthalten sie zusammen mehr als 12.000 Zeichen, obwohl kein einzelnes Ergebnis diese Grenze überschreitet, speichert King so viele der größten geeigneten Ergebnisse wie nötig in privaten Dateien. In der Modellprojektion verbleiben lesbare Verweise. Der unveränderte Sitzungsrohverlauf bleibt vollständig erhalten. Gemischte Medienergebnisse, einzelne Ergebnisse unter 3.000 Zeichen und Stapel bis einschließlich 12.000 Zeichen bleiben unverändert. Beispiel: Bei zwei Suchergebnissen mit 7.000 und 6.000 Zeichen wird das größere Ergebnis privat gespeichert; Anfang, Ende, ausgelassene Zeichenzahl und `output_path` bleiben für den Agenten sichtbar.
|
|
377
|
+
|
|
378
|
+
Ab BLUN King 9.1.100 beendet eine begrenzte Grep-Inhaltssuche ripgrep, sobald der Versatz, die angeforderten Zeilen und eine zusätzliche Vorschauzeile vollständig vorliegen. Die Vorschauzeile belegt, ob eine weitere Seite existiert, ohne vorher bis zu 10 MB einzulesen. Unbegrenzte Suchen, Trefferzählungen und nach Änderungszeit sortierte Dateilisten laufen weiterhin vollständig durch.
|
|
379
|
+
|
|
380
|
+
Große Dateien werden weiterhin seitenweise gelesen. Erreicht `Read` seine interne Grenze von 1.000 Zeilen und enthält die Datei weitere Zeilen, nennt das Ergebnis jetzt den exakten nächsten `line_offset`. Beispiel: Ein Lesevorgang ab Zeile 2001 wird mit `line_offset=3001` fortgesetzt. Am Dateiende und bei einem bewusst kleineren Leseausschnitt erscheint kein Fortsetzungshinweis. Dadurch zieht der Agent keine Schlüsse aus einem unvollständigen Ausschnitt und liest die Datei nicht erneut ab der ersten Zeile.
|
|
381
|
+
|
|
382
|
+
Das Telemetrieereignis `tool_result_offloaded` enthält ausschließlich `tool_name`, `output_size_chars`, `output_size_bytes` und `preview_size_chars`. Es enthält weder den Inhalt noch den Speicherpfad. Beispiel: Eine Ausgabe mit 80.000 Zeichen erzeugt eine Vorschau mit 2.000 Zeichen; die Telemetrie zeigt die Größenersparnis, ohne Nutzdaten zu protokollieren.
|
|
383
|
+
|
|
384
|
+
Das Telemetrieereignis `tool_result_batch_offloaded` meldet ausschließlich die Zahl der Ergebnisse sowie die Zeichenzahlen vor und nach der Entlastung und die eingesparte Zeichenzahl. Es enthält weder Ergebnisinhalte noch Speicherpfade.
|
|
385
|
+
|
|
386
|
+
Reguläre `Agent`-Teilaufgaben verwenden eine eigene `ContextMemory` und eine eigene `wire.jsonl` in einem getrennten Agentenverzeichnis. Der Hauptagent erhält nur die Ergebniszusammenfassung, sodass lange Teilaufgaben nicht den Hauptverlauf füllen. `TodoList` speichert Pläne weiterhin maschinenlesbar im Sitzungs-Wire; `blun handoff` übergibt sie zusammen mit prüfbaren Hashes zwischen CLI, Desktop und Web.
|
|
387
|
+
|
|
388
|
+
## Rein lesende Sitzungsdiagnose
|
|
389
|
+
|
|
390
|
+
Der mitgelieferte Standardskill `blun-session-inspector` untersucht den nur ergänzten Sitzungs-Wire und die zugehörigen Telemetriedateien, ohne eine Sitzung zu verändern. Er meldet Modellschritte, Werkzeugaufrufe, Zähler zum Tokenverbrauch, Voll- und Mikroverdichtungen, fehlgeschlagene Verdichtungen sowie ausgelagerte Werkzeugergebnisse. Prompts, Systemanweisungen, Werkzeugargumente, Werkzeugergebnisse, private Pfade und verborgenes Denken erscheinen nicht in der Standardausgabe.
|
|
391
|
+
|
|
392
|
+
Zusätzlich liest der Inspektor das sitzungseigene BLUN-Protokoll und meldet, wie viele Werkzeugschemata verfügbar, ausgewählt und zurückgestellt waren, wie viele geschätzte Schema-Token vermieden wurden und warum die Werkzeugmenge reduziert wurde. Andere Protokollinhalte werden weder ausgegeben noch ausgewertet.
|
|
393
|
+
|
|
394
|
+
Beispiele:
|
|
395
|
+
|
|
396
|
+
```text
|
|
397
|
+
node "$SKILL_DIR/scripts/inspect-session.cjs" --list 20
|
|
398
|
+
node "$SKILL_DIR/scripts/inspect-session.cjs" SESSION_ID
|
|
399
|
+
```
|
|
400
|
+
|
|
401
|
+
Ein eindeutiger Präfix der Sitzungs-ID genügt. `--profile NAME` wählt ein anderes Profil. `--include-metadata` zeigt zusätzlich Arbeits- und Sitzungsverzeichnis und sollte nur verwendet werden, wenn diese Pfade wirklich gebraucht werden. Der Inspektor setzt eine Sitzung niemals fort, lädt sie nicht neu, verdichtet sie nicht und löscht sie nicht.
|
|
402
|
+
|
|
403
|
+
## Zug-Wächter
|
|
404
|
+
|
|
405
|
+
Läuft ein Zug 20 Minuten ohne neues Werkzeugergebnis, meldet die Konsole den
|
|
406
|
+
Stand auch im verbundenen Telegram-Kanal. Fünf aufeinanderfolgende identische
|
|
407
|
+
fehlgeschlagene Werkzeugaufrufe beenden den Zug mit einer Fehlermeldung.
|
|
408
|
+
|
|
409
|
+
Die Grenzwerte lassen sich vor dem Start mit
|
|
410
|
+
`BLUN_TURN_WATCHDOG_IDLE_MINUTES` und
|
|
411
|
+
`BLUN_TURN_WATCHDOG_MAX_FAILED_REPETITIONS` ändern.
|
|
412
|
+
|
|
413
|
+
## Befehle und Loops während eines laufenden Zugs
|
|
414
|
+
|
|
415
|
+
Slash-Befehle, die einen freien Agenten benötigen, werden während eines
|
|
416
|
+
laufenden Zugs in ihrer Eingabereihenfolge vorgemerkt und danach ausgeführt.
|
|
417
|
+
Status-, Stopp- und andere sichere Steuerbefehle bleiben sofort verfügbar.
|
|
418
|
+
|
|
419
|
+
Ein neuer `/loop` ersetzt den bisherigen Loop derselben Sitzung. Dabei bleibt
|
|
420
|
+
genau ein gespeicherter Loop aktiv; der neue Auftrag, das neue Intervall und
|
|
421
|
+
der neue Startzeitpunkt gelten vollständig. `/loop stop`, `/loop pause` und
|
|
422
|
+
`/loop status` wirken auch dann sofort, wenn der Agent gerade arbeitet.
|
|
423
|
+
|
|
424
|
+
Wird ein neuer `/loop` während eines laufenden Zugs aktiviert, wird sein erster
|
|
425
|
+
Auftrag hinter dem aktuellen Zug eingereiht. Er startet danach automatisch; es
|
|
426
|
+
entsteht weder ein zweiter paralleler Zug noch der Fehler `turn.agent_busy`.
|
|
427
|
+
|
|
428
|
+
Beispiel: `/loop 5min Prüfe den Teststand und arbeite am nächsten offenen Punkt
|
|
429
|
+
weiter.` führt den ersten Lauf direkt nach dem aktuellen Zug aus und danach alle
|
|
430
|
+
fünf Minuten.
|
|
431
|
+
|
|
432
|
+
Eine fällige Wiederholung wird als autonomer Aufwecker eingespeist und nicht
|
|
433
|
+
als neue Nutzernachricht behandelt. Die Statuszeile zeigt den nächsten
|
|
434
|
+
Aufweckzeitpunkt laufend an. Beim Fortsetzen derselben Sitzung wird der
|
|
435
|
+
gespeicherte Loop samt Zeitplan wieder geladen; `/new` beginnt dagegen bewusst
|
|
436
|
+
ohne den Loop der vorherigen Sitzung.
|
|
437
|
+
|
|
438
|
+
## Eigenständige Ideenarbeit und Telegram-Befehle
|
|
439
|
+
|
|
440
|
+
`/idea <Ziel>` startet einen eigenständigen Arbeitsmodus. Der Agent zeigt zuerst
|
|
441
|
+
einen auftragsspezifischen Aufgabenplan, recherchiert selbstständig, setzt sichere
|
|
442
|
+
lokale Schritte um und fragt gezielt nach, wenn eine Entscheidung oder ein Zugang
|
|
443
|
+
fehlt. Blockierte, auf Freigabe wartende und abgebrochene Schritte bleiben mit
|
|
444
|
+
ihrem tatsächlichen Zustand sichtbar.
|
|
445
|
+
|
|
446
|
+
Der erste Werkzeugaufruf muss den sichtbaren Plan setzen. Ausgehende Aktionen
|
|
447
|
+
werden zusätzlich pro Werkzeugaufruf geprüft und bei fehlender Kanal- oder
|
|
448
|
+
Zugangsfreigabe angehalten.
|
|
449
|
+
|
|
450
|
+
`/chancenradar <Ziel>` startet einen eigenen Modus zur Chancensuche. Der Agent
|
|
451
|
+
durchsucht aktuelle öffentliche Quellen, Foren und Communitys nach echten
|
|
452
|
+
Problemen und bestehenden Lösungsansätzen, trennt Belege von Schlussfolgerungen,
|
|
453
|
+
bewertet Chancen nach Wirkung, Passung, Aufwand und Verlässlichkeit und setzt den
|
|
454
|
+
besten sicheren lokalen nächsten Schritt um. Der sichtbare Aufgabenplan und alle
|
|
455
|
+
Freigabegrenzen von `/idea` gelten weiterhin. Der Befehl funktioniert auch über
|
|
456
|
+
Telegram.
|
|
457
|
+
|
|
458
|
+
`/curiosity <Nische>` startet eine begrenzte, rein lesende Marktrecherche;
|
|
459
|
+
`/scout` ist ein Alias. Der Agent prüft höchstens zwölf Quellseiten, trennt
|
|
460
|
+
Belege, Schlussfolgerungen und Unbekanntes und liefert bis zu drei belegte
|
|
461
|
+
Chancen mit Gegenbeleg, Abbruchkriterium und einem direkt nutzbaren
|
|
462
|
+
`/idea`-Auftrag. Ohne Nische fragt er zuerst genau einmal nach. Schwache Belege
|
|
463
|
+
ergeben weniger Treffer oder `no_action`, niemals aufgefüllte Vorschläge.
|
|
464
|
+
|
|
465
|
+
Der sichtbare Verlauf behält standardmäßig die vollständige laufende und
|
|
466
|
+
wiederhergestellte Sitzung. Das Mausrad kann den Verlauf direkt beim ersten Zug
|
|
467
|
+
öffnen; Editor und Fußzeile bleiben dabei fest sichtbar.
|
|
468
|
+
|
|
469
|
+
## Venture Flywheel: geprüfte Phase-0-Verträge
|
|
470
|
+
|
|
471
|
+
Der mitgelieferte Standardskill `venture-flywheel` stellt reine, deterministische
|
|
472
|
+
Verträge für Projektidentität, Repository-Trust, Capability-Entscheidungen,
|
|
473
|
+
versionierte Laufzustände und hash-verkettete Prüfereignisse bereit. Phase 0
|
|
474
|
+
führt selbst keine Befehle, Netzwerkzugriffe oder Deployments aus.
|
|
475
|
+
|
|
476
|
+
Ein vollständiges CommonJS-Beispiel für alle sieben öffentlichen Funktionen
|
|
477
|
+
liegt unter
|
|
478
|
+
`standard-skills/venture-flywheel/references/BEISPIELE-phase0.md`. Es zeigt
|
|
479
|
+
unter anderem, warum `sandbox.execute` im Repository abgewiesen, in einem
|
|
480
|
+
isolierten Worktree aber erlaubt wird und wie eine Ereigniskette geprüft wird.
|
|
481
|
+
|
|
482
|
+
Im automatisch angebundenen Telegram-Kanal werden ausschließlich `/loop`,
|
|
483
|
+
`/goal`, `/idea`, `/chancenradar`, `/curiosity`, `/scout` und `/befehle` als Befehle ausgeführt. Ist der Agent
|
|
484
|
+
beschäftigt, bleiben sie in der Warteschlange. Andere Slash-Eingaben werden aus
|
|
485
|
+
Sicherheitsgründen als normale Chatnachrichten behandelt.
|
|
486
|
+
|
|
487
|
+
### Rechner aus Telegram prüfen
|
|
488
|
+
|
|
489
|
+
Der Telegram-Befehl `/status` prüft die lokale Verbindung ohne Modellaufruf.
|
|
490
|
+
Er zeigt den Rechnernamen, die installierte BLUN-Version, die Laufzeit der
|
|
491
|
+
Telegram-Brücke, die Verbindung und Laufzeit der Konsole, den aktuellen
|
|
492
|
+
Zustellweg, den Konsolen-Herzschlag, den letzten Warteschlangen-Fortschritt sowie
|
|
493
|
+
den aktuellen Arbeitsschritt. Die Warteschlange wird als tatsächlich ungelesener
|
|
494
|
+
Anteil und Gesamtgröße gemessen; ein Prüfpunkt wird nur für exakt dieselbe
|
|
495
|
+
Warteschlangendatei akzeptiert. Damit bleibt der Zustand auch dann abfragbar,
|
|
496
|
+
wenn die Konsole hängt oder der Modellanbieter ausgelastet ist. Die Ausgabe
|
|
497
|
+
enthält keine Chat-IDs, Dateipfade, Zugangsdaten, Nachrichteninhalte oder
|
|
498
|
+
vollständigen Aufgabenlisten. Nicht verbundene Absender erhalten weiterhin nur
|
|
499
|
+
die Kopplungsanweisung.
|
|
500
|
+
|
|
501
|
+
Beim ersten Start werden das Telegram-Plugin und die mitgelieferten Skills
|
|
502
|
+
eingerichtet. Die Anmeldung erfolgt anschließend in der
|
|
503
|
+
Konsole mit `/login` über den BLUN-OAuth-Server. Das Paket erzeugt keine
|
|
504
|
+
statische Anbieter- oder API-Key-Konfiguration.
|
|
505
|
+
|
|
506
|
+
## Nachweisbare Arbeitsabläufe
|
|
507
|
+
|
|
508
|
+
Version 9.1.0 enthält sieben zusätzliche, getrennt nutzbare Befehlsgruppen:
|
|
509
|
+
|
|
510
|
+
- `proof` belegt Prüfungen und Artefakte mit SHA-256.
|
|
511
|
+
- `brief` erstellt einen versionierten Projektauftrag.
|
|
512
|
+
- `handoff` übergibt eine Sitzung zwischen CLI, Desktop und Web.
|
|
513
|
+
- `replay` erzeugt einen bereinigten Arbeitsverlauf.
|
|
514
|
+
- `guard` prüft Belegintegrität und aktuelle Artefakte.
|
|
515
|
+
- `demo` erzeugt eine bereinigte statische Projektdemo.
|
|
516
|
+
- `workspace` verwaltet isolierte Git-Arbeitsbereiche.
|
|
517
|
+
|
|
518
|
+
Sie stehen unter `blun` und `king` identisch zur Verfügung.
|
|
519
|
+
|
|
520
|
+
## Gemeinsamer kognitiver Speicherkern (optional)
|
|
521
|
+
|
|
522
|
+
Ohne zusätzliche Konfiguration bleibt der bisherige lokale SQLite-Speicher
|
|
523
|
+
aktiv. Betreiber können einen gemeinsamen, portalneutralen Speicherkern
|
|
524
|
+
ausdrücklich über `BLUN_COGNITIVE_MEMORY_ADAPTER_MODULE` wählen. Der Wert muss
|
|
525
|
+
auf eine absolute, kanonische CommonJS-Datei zeigen.
|
|
526
|
+
|
|
527
|
+
Das Modul exportiert synchron `createCognitiveMemoryAdapter(context)` und
|
|
528
|
+
liefert einen Adapter mit Vertragsversion 6. Relative Pfade, symbolische
|
|
529
|
+
Verknüpfungen, asynchrone Fabriken und abweichende Vertragsversionen werden
|
|
530
|
+
geschlossen abgewiesen. Der Adapter erhält nur die Vertragsversion, das
|
|
531
|
+
Profilverzeichnis sowie Mandanten-, Agenten- und Anzeigenamen. Zugangsdaten
|
|
532
|
+
werden nicht übergeben.
|
|
533
|
+
|
|
534
|
+
Damit kann derselbe geprüfte Ereignisstrom über CLI und Portale hinweg gelesen,
|
|
535
|
+
korrigiert und zurückgezogen werden. Ohne den optionalen Anbieter entstehen
|
|
536
|
+
keine neuen Netzwerkzugriffe und keine Verhaltensänderung.
|
|
537
|
+
|
|
538
|
+
## Medienerzeugung
|
|
539
|
+
|
|
540
|
+
Für Medienaufträge bleiben `GenerateImage`, `GenerateVideo`, `GenerateSpeech` und
|
|
541
|
+
`GetMedia` unmittelbar verfügbar. Die erweiterten Medienwerkzeuge
|
|
542
|
+
`UnderstandImage`, `UnderstandVideo`, `DubVideo` und `LipSyncMedia` sind zusätzlich
|
|
543
|
+
über `ToolSearch` auffindbar und werden nur bei Bedarf geladen. Dadurch kann King
|
|
544
|
+
Bilder und Videos verstehen, Videos vertonen oder Lippenbewegungen synchronisieren,
|
|
545
|
+
ohne diese Werkzeugschemata bei jeder normalen Textanfrage mitzuschicken. Nutzer
|
|
546
|
+
müssen weder Werkzeugnamen noch Modell-Prompts kennen. Eine normale Anweisung wie
|
|
547
|
+
„Erzeuge ein realistisches Produktbild einer schwarzen Armbanduhr auf weißem
|
|
548
|
+
Marmor“ oder „Animiere das letzte Bild als ruhige Kamerafahrt von sechs Sekunden“
|
|
549
|
+
genügt. King wählt den passenden Medienweg und kann das asynchrone Ergebnis mit
|
|
550
|
+
`GetMedia` abrufen.
|
|
551
|
+
|
|
552
|
+
Ein angenommener Medienauftrag bleibt über Verdichtungen und schnelle
|
|
553
|
+
Folgeturns hinweg gespeichert. Solange er offen ist, bleibt `GetMedia`
|
|
554
|
+
verfügbar; King prüft den tatsächlichen Status, statt fälschlich zu behaupten,
|
|
555
|
+
die Medienerzeugung sei nicht verfügbar.
|
|
556
|
+
|
|
557
|
+
## Passende Werkzeuge ohne Such-Zwischenschritt
|
|
558
|
+
|
|
559
|
+
Ab BLUN King 9.1.396 vergleicht King die aktuelle Anfrage mit den bereits
|
|
560
|
+
registrierten Werkzeugbeschreibungen. Bei eindeutiger Übereinstimmung lädt er
|
|
561
|
+
für diesen Zug höchstens zwei passende, sonst zurückgestellte Schemata direkt.
|
|
562
|
+
Name, Beschreibung, Parameterhinweise und Beispiele dürfen zur Auswahl
|
|
563
|
+
beitragen; frühere Nachrichten außerhalb des aktuellen Telegram-Kanalblocks
|
|
564
|
+
zählen nicht als neue Absicht.
|
|
565
|
+
|
|
566
|
+
`ToolSearch` bleibt für unklare, unbekannte und mehrdeutige Anfragen vollständig
|
|
567
|
+
verfügbar. Eine automatische Auswahl wird nicht dauerhaft gespeichert und
|
|
568
|
+
vergrößert den residenten Werkzeugsatz nicht. Dadurch kann eine natürliche
|
|
569
|
+
Anweisung wie „Zeig mir den letzten Telegram-Verlauf“ das passende Werkzeug im
|
|
570
|
+
selben Modellschritt erhalten, während Begrüßungen und fachfremde Anfragen keine
|
|
571
|
+
zusätzlichen Schemata laden.
|
|
572
|
+
|
|
573
|
+
## Begrenztes Ranking bei großen Eingaben
|
|
574
|
+
|
|
575
|
+
Ab BLUN King 9.1.403 bewertet die automatische Werkzeugauswahl pro aktueller
|
|
576
|
+
Anfrage höchstens 1.000 Zeichen. Eingebettete Inhalte aus
|
|
577
|
+
`<attached_documents>`, `<attachment_content>`, `<document_content>` und
|
|
578
|
+
`<file_content>` werden vor dem Ranking vollständig entfernt. Damit können
|
|
579
|
+
große Anhänge weder die Auswahl unnötig verteuern noch anhand ihres Inhalts ein
|
|
580
|
+
fachfremdes Werkzeug vorladen.
|
|
581
|
+
|
|
582
|
+
## Ruhige Konfigurationsaktualisierung
|
|
583
|
+
|
|
584
|
+
Ab BLUN King 9.1.404 ersetzt eine Konfigurationsaktualisierung die private
|
|
585
|
+
`config.toml` nur noch, wenn sich ihre serialisierten Bytes tatsächlich ändern.
|
|
586
|
+
Bei identischem Inhalt bleiben Dateidentität und Änderungszeit erhalten; die
|
|
587
|
+
Prüfung und Härtung der privaten Dateirechte läuft trotzdem weiter. Echte
|
|
588
|
+
Änderungen verwenden unverändert den crash-sicheren atomaren Schreibweg.
|
|
589
|
+
|
|
590
|
+
## Verlässliche Beziehungskontinuität
|
|
591
|
+
|
|
592
|
+
Ab BLUN King 9.1.406 wird ein erneut zugestelltes privates Telegram-Ereignis
|
|
593
|
+
mit demselben Zeitstempel und Text nur einmal gespeichert. Eine tatsächlich
|
|
594
|
+
später wiederholte Aussage bleibt dagegen Teil des Verlaufs.
|
|
595
|
+
|
|
596
|
+
Natürliche ausdrückliche Hinweise wie „Dieter ist dein Boss, bitte merken“
|
|
597
|
+
werden auch dann erkannt, wenn die Bitte um Erinnerung am Ende steht. Sie
|
|
598
|
+
gelangen als Referenzdaten in einen begrenzten, nur ergänzbaren
|
|
599
|
+
Beziehungskontext. Sie erteilen oder ändern niemals Berechtigungen;
|
|
600
|
+
Gruppeninhalte, Geheimnisse und Zugriffsaussagen bleiben ausgeschlossen.
|
|
601
|
+
|
|
602
|
+
Ab BLUN King 9.1.408 speichert ein ausdrücklich zu merkendes privates
|
|
603
|
+
Beziehungsdetail zunächst als unsichere Beobachtung im versionierten
|
|
604
|
+
Cognitive-Memory-Adapter. Erst eine zweite, unabhängige identische Aussage
|
|
605
|
+
bestätigt es; der nächste private Turn lädt den bestätigten Eintrag. Wiederholte
|
|
606
|
+
Ereignisse bleiben idempotent, Gruppen sehen ihn nie, und gespeicherte Aussagen
|
|
607
|
+
können keine Berechtigungen erteilen. Ist ein konfigurierter Memory-Anbieter
|
|
608
|
+
nicht verfügbar, wird keine lokale Schatten-Memory angelegt.
|
|
609
|
+
|
|
610
|
+
## Stabiler Telegram-Reply-Weg
|
|
611
|
+
|
|
612
|
+
Ab BLUN King 9.1.407 kann der Duplikatschutz des Telegram-Reply-Werkzeugs das
|
|
613
|
+
aktuelle Eingangsprotokoll wieder direkt lesen. Normale Antworten scheitern
|
|
614
|
+
dadurch nicht mehr an einem fehlenden Laufzeitimport; der getrennte
|
|
615
|
+
Bridge-Fallback bleibt nur die Absicherung und nicht der unbeabsichtigte
|
|
616
|
+
Hauptweg.
|
|
617
|
+
|
|
618
|
+
Ab BLUN King 9.1.409 verwenden Reply-Werkzeug und TUI-Fallback dasselbe
|
|
619
|
+
Telegram-Kanalverzeichnis. Ein profilspezifisches `BLUN_HOME` erzeugt dadurch
|
|
620
|
+
keinen zweiten Eingangs- oder Ausgangsverlauf mehr. Ein ausdrücklich gesetztes
|
|
621
|
+
`BLUN_TELEGRAM_STATE_DIR` bleibt maßgeblich; ohne diese Einstellung verwenden
|
|
622
|
+
beide Wege `~/.blun/channels/telegram`.
|
|
623
|
+
|
|
624
|
+
Ab BLUN King 9.1.410 begrenzen private Telegram-Gedächtnisbefehle
|
|
625
|
+
Beziehungsdaten auf die jeweilige Person. `/memory focus` blendet Beziehungen
|
|
626
|
+
anderer Personen aus, lässt aber nicht personenbezogenen Kontext sichtbar.
|
|
627
|
+
Korrekturen und Löschungen können keine Beziehung einer anderen Person mehr
|
|
628
|
+
treffen; die lokale Operator-Ansicht bleibt vollständig.
|
|
629
|
+
|
|
630
|
+
Ab BLUN King 9.1.411 können nicht triviale oder unbekannte Aufgaben einen
|
|
631
|
+
begrenzten Problemrahmen im dauerhaften Aktions-Checkpoint speichern. Er hält
|
|
632
|
+
das Erfolgskriterium, Wissenslücken, bis zu fünf Handlungsoptionen, die gewählte
|
|
633
|
+
Aktion samt Begründung, die vorgesehene Unterstützung, das Risiko und den
|
|
634
|
+
Rückweg fest. Die gewählte Aktion muss einer der gespeicherten Optionen
|
|
635
|
+
entsprechen. Der Rahmen bleibt beim Fortsetzen und nach einem Neustart erhalten,
|
|
636
|
+
beschreibt aber ausschließlich den Arbeitsstand und kann niemals Berechtigungen
|
|
637
|
+
erteilen.
|
|
638
|
+
|
|
639
|
+
Ab BLUN King 9.1.412 beginnt jedes vom Modell angelegte dauerhafte Ziel atomar
|
|
640
|
+
mit Revision 1 und einem vollständigen, begrenzten Problemrahmen im
|
|
641
|
+
Aktions-Checkpoint. Der Rahmen bleibt dadurch sofort erhalten und hängt nicht
|
|
642
|
+
mehr von einem späteren `UpdateGoal`-Aufruf ab. Im God Mode und im automatischen
|
|
643
|
+
Modus läuft ein bereits autorisierter Zielstart ohne zweite Bestätigung weiter;
|
|
644
|
+
im manuellen Modus bleibt die bestehende Freigabe erhalten. Authentifizierte,
|
|
645
|
+
nicht triviale Mehrschrittaufgaben mit überprüfbarem Endzustand dürfen das
|
|
646
|
+
dauerhafte Ziel auch unter einer bereits geltenden Anweisung zum autonomen
|
|
647
|
+
Weiterarbeiten nutzen. Begrüßungen, gewöhnliche Einzelschrittanfragen und vage
|
|
648
|
+
Aufgaben erzeugen weiterhin kein Ziel. Der Problemrahmen bleibt beschreibender
|
|
649
|
+
Arbeitsstand und erteilt niemals Berechtigungen.
|
|
650
|
+
|
|
651
|
+
Ab BLUN King 9.1.413 werden Antworten aus Telegram-Zügen nicht mehr als fertig
|
|
652
|
+
versendet, wenn der letzte Modellschritt am Ausgabelimit `max_tokens` endete.
|
|
653
|
+
Der unvollständige Entwurf bleibt ausschließlich im Sitzungskontext. King
|
|
654
|
+
erstellt daraus automatisch eine kurze, vollständige Antwort und sendet erst
|
|
655
|
+
diese. Bereits über das Reply-Werkzeug zugestellte Antworten werden dabei nicht
|
|
656
|
+
wiederholt. Die Fortsetzung ist auf drei Versuche begrenzt; danach wird niemals
|
|
657
|
+
ein abgeschnittener Text als Ergebnis ausgegeben.
|
|
658
|
+
|
|
659
|
+
Ab BLUN King 9.1.414 trägt jeder neue dauerhafte Aktions-Checkpoint zusätzlich
|
|
660
|
+
den genauen Auslöser für seinen nächsten Schritt. Außerhalb einer Wartephase
|
|
661
|
+
muss dieser Auslöser „sofort“ sein. Eine Wartephase benennt stattdessen ein
|
|
662
|
+
äußeres Ereignis, einen Zeitpunkt, eine Abhängigkeit oder eine ausstehende
|
|
663
|
+
Nutzerentscheidung. Auslöser und Bedingung bleiben bei Fortsetzung und Neustart
|
|
664
|
+
erhalten, ohne Berechtigungen zu erteilen. Bereits gespeicherte ältere
|
|
665
|
+
Checkpoints bleiben lesbar.
|
|
666
|
+
|
|
667
|
+
Ab BLUN King 9.1.415 übernimmt der sitzungsübergreifende Arbeitsfokus den
|
|
668
|
+
gespeicherten Auslöser vollständig. Die nächste Aktion und die Bedingung, unter
|
|
669
|
+
der sie ausgeführt werden darf, bleiben getrennt sichtbar. Dadurch erscheint
|
|
670
|
+
eine Wartephase nach einem Neustart oder Kontextwechsel nicht mehr als sofortiger
|
|
671
|
+
Arbeitsauftrag. Art und Bedingung des Auslösers verändern außerdem die Identität
|
|
672
|
+
des dauerhaften Fokuszustands; fehlerhafte oder zur Phase widersprüchliche
|
|
673
|
+
Auslöser werden verworfen. Ältere Checkpoints ohne ausdrücklichen Auslöser
|
|
674
|
+
behalten ihr bisheriges Verhalten.
|
|
675
|
+
|
|
676
|
+
Der eigentliche Anhang und die vollständige Nutzernachricht bleiben für den Zug
|
|
677
|
+
unverändert verfügbar. Die Begrenzung betrifft ausschließlich die kleine
|
|
678
|
+
lexikalische Vorauswahl von höchstens zwei Werkzeugschemas; ToolSearch und alle
|
|
679
|
+
explizit benötigten Medien- und Anhangswerkzeuge bleiben erhalten.
|
|
680
|
+
|
|
681
|
+
## Abschlussbedingungen mit Laufzeitbeleg
|
|
682
|
+
|
|
683
|
+
Ab BLUN King 9.1.397 kann ein autonomes Ziel mit ausdrücklich gesetzter
|
|
684
|
+
Abschlussbedingung nicht mehr allein aufgrund einer Textbehauptung als fertig
|
|
685
|
+
markiert werden. Vor dem Abschluss muss ein aktueller Prüf-Checkpoint vorliegen,
|
|
686
|
+
der auf mindestens einem erfolgreichen Laufzeitwerkzeug beruht und als verifiziert
|
|
687
|
+
eingestuft ist. Fehlt dieser Beleg, bleibt das Ziel aktiv und King erhält eine
|
|
688
|
+
konkrete Nachbesserung statt einer falschen Fertigmeldung. Ziele ohne ausdrücklich
|
|
689
|
+
gesetzte Abschlussbedingung behalten ihr bisheriges Verhalten.
|
|
690
|
+
|
|
691
|
+
## Projektbezogenes Lernen ohne Übersprechen
|
|
692
|
+
|
|
693
|
+
Ab BLUN King 9.1.399 bleiben bestätigte Rot-zu-Grün-Lernkandidaten innerhalb
|
|
694
|
+
des Git-Projekts, in dem sie entstanden sind. Zwei Arbeitskopien desselben
|
|
695
|
+
Remote-Repositories teilen denselben anonymisierten Projekt-Schlüssel; andere
|
|
696
|
+
Repositories erhalten getrennte Lernspeicher. Lokale Git-Projekte ohne Remote
|
|
697
|
+
werden anhand ihres Repository-Wurzelpfads getrennt.
|
|
698
|
+
|
|
699
|
+
Weder Remote-Adresse noch lokaler Projektpfad werden im Lernkandidaten
|
|
700
|
+
gespeichert. Außerhalb eines Git-Projekts bleibt der bisherige globale
|
|
701
|
+
Profilspeicher erhalten. Damit kann eine gemessene Projektregel später wieder
|
|
702
|
+
aufgerufen werden, ohne als vermeintlich allgemeine Regel in fachfremde Projekte
|
|
703
|
+
zu gelangen.
|
|
704
|
+
|
|
705
|
+
## Sofort sichtbarer Antwortbeginn
|
|
706
|
+
|
|
707
|
+
Ab BLUN King 9.1.401 rendert die TUI das erste Textfragment eines neuen Zuges
|
|
708
|
+
oder eines neuen Antwortabschnitts sofort. Es wartet nicht mehr auf den ersten
|
|
709
|
+
Intervall-Timer und übernimmt auch keinen Render-Zeitstempel aus dem vorherigen
|
|
710
|
+
Zug. Dadurch erscheint der Antwortbeginn ohne vermeidbare Pause in der Konsole.
|
|
711
|
+
|
|
712
|
+
Weitere Text-, Denk- und Werkzeugfragmente bleiben adaptiv gebündelt. Kurze
|
|
713
|
+
Ausgaben behalten ihren schnellen Takt; bei langen Ausgaben wächst das Intervall
|
|
714
|
+
weiterhin stufenweise, damit vollständige Neurenderings die TUI nicht ausbremsen.
|
|
715
|
+
|
|
716
|
+
## Bereinigung alter Verdichtungsarchive beim Start
|
|
717
|
+
|
|
718
|
+
Ab BLUN King 9.1.402 beginnt beim Start einmalig eine Hintergrundbereinigung
|
|
719
|
+
für private Verdichtungsarchive unter `~/.blun/conversation-history/`. Dateien,
|
|
720
|
+
deren Aufbewahrungsfrist abgelaufen ist, werden damit auch dann entfernt, wenn
|
|
721
|
+
anschließend keine neue Vollverdichtung stattfindet.
|
|
722
|
+
|
|
723
|
+
Die Bereinigung wird nicht abgewartet und kann den Start weder verzögern noch
|
|
724
|
+
verhindern. Sie bleibt auf reguläre `compaction-*.md`-Dateien direkt im
|
|
725
|
+
Archivverzeichnis begrenzt. Fehler werden protokolliert und fallen weich
|
|
726
|
+
zurück; Sitzungs-Wire, andere Dateien und laufende Antworten bleiben
|
|
727
|
+
unverändert. `BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0` schaltet die
|
|
728
|
+
Bereinigung weiterhin vollständig ab.
|
|
729
|
+
|
|
730
|
+
## Reaktionsfähige Wiederaufnahme großer Sitzungen
|
|
731
|
+
|
|
732
|
+
Ab BLUN King 9.1.400 spielt die TUI gespeicherte Sitzungsverläufe weiterhin
|
|
733
|
+
vollständig ab, gibt bei großen Wiederaufnahmen aber nach jeweils 30 Datensätzen
|
|
734
|
+
kurz an die Node-Ereignisschleife ab. Dadurch können Anzeige, Eingabe und
|
|
735
|
+
Zustandsleiste während des Wiederaufbaus reagieren, statt bis zum letzten
|
|
736
|
+
Verlaufseintrag zu warten.
|
|
737
|
+
|
|
738
|
+
Es werden keine Datensätze gekürzt, übersprungen oder aus dem gespeicherten
|
|
739
|
+
Verlauf entfernt. Nach dem letzten Datensatz erfolgt keine unnötige zusätzliche
|
|
740
|
+
Unterbrechung; kleine Sitzungen behalten damit praktisch ihr bisheriges
|
|
741
|
+
Startverhalten.
|
|
742
|
+
|
|
743
|
+
## Keine doppelte Telegram-Antwort ohne neue Nachricht
|
|
744
|
+
|
|
745
|
+
Ab BLUN King 9.1.398 prüft jeder Text-Ausgangspfad vor dem Senden die jüngste
|
|
746
|
+
erfolgreiche Telegram-Antwort und den jüngsten Eingang desselben Chats. Solange
|
|
747
|
+
danach keine neue Nutzernachricht eingetroffen ist, wird eine wortgleiche oder
|
|
748
|
+
nahezu gleiche Wiederholung nicht erneut gesendet. Das gilt gleichermaßen für
|
|
749
|
+
den Telegram-Werkzeugpfad und beide automatischen Rückfallpfade.
|
|
750
|
+
|
|
751
|
+
Nach einer neuen Nutzernachricht ist dieselbe Antwort wieder zulässig. Andere
|
|
752
|
+
Ergebnisse und Datei-Anhänge bleiben unverändert. Die Prüfung liest nur begrenzte
|
|
753
|
+
Endbereiche der Ein- und Ausgangsprotokolle und fällt bei fehlendem Beleg offen
|
|
754
|
+
zurück, damit Telegram nicht wegen einer beschädigten Protokollzeile blockiert.
|
|
755
|
+
|
|
756
|
+
Angehängte Bilder werden weiterhin mit `ReadMediaFile` gelesen. Bild-, Video-
|
|
757
|
+
und Spracherzeugung laufen asynchron, sodass die Konsole während der Verarbeitung
|
|
758
|
+
nutzbar bleibt. `GenerateVideo` kann außerdem einen abgeschlossenen Bildauftrag
|
|
759
|
+
oder eine lokale PNG- beziehungsweise JPEG-Datei animieren.
|
|
760
|
+
|
|
761
|
+
Die Medienleiste erscheint nur bei aktiven Medienaufträgen. Sie zeigt
|
|
762
|
+
Warteschlangenplatz, Produktionsphase und Laufzeit sowie nur tatsächlich vom
|
|
763
|
+
Anbieter gemeldete Prozentwerte, Schritte, Frames, FPS, Audiolänge, Restzeit,
|
|
764
|
+
Auflösung, Wellenform und Vorschauen. Bei Bild-zu-Video erscheint das lokale
|
|
765
|
+
Ausgangsbild sofort als Vorschau. Tatsächlich gemeldete Phasen bleiben erhalten,
|
|
766
|
+
sodass auch kurze Schritte wie Rendern und Speichern in der Produktionskette
|
|
767
|
+
sichtbar sind. Aktualisierte Vorschaubilder werden erneuert; Medienpfade und
|
|
768
|
+
Webadressen sind als Terminalverweise anklickbar.
|
|
769
|
+
|
|
770
|
+
## Gestufte Verdichtung für große Sitzungen
|
|
771
|
+
|
|
772
|
+
Eine Vollverdichtung verwendet jetzt pro Zusammenfassungsstufe höchstens 64.000 geschätzte Eingabe-Token als Zielwert. Die feste Sicherheitsgrenze des aktiven Modells bleibt unverändert. King teilt den älteren Verlauf an gültigen Nachrichtengrenzen, fasst jeden chronologischen Abschnitt zusammen und übernimmt diese Zusammenfassung in die nächste Stufe. Dabei wird kein noch nicht zusammengefasster Verlauf verworfen. Ist eine einzelne unteilbare Nachricht größer als der Stufenzielwert, bleibt die bestehende feste Sicherheitsgrenze der Rückfallweg.
|
|
773
|
+
|
|
774
|
+
Beispiel: Ein auf 256.000 Token geschätzter Verdichtungsauftrag wird in mehreren kleineren Stufen verarbeitet, statt als eine einzige große Anbieteranfrage. Die genaue Stufenzahl hängt von den Nachrichtengrenzen und den erzeugten Zwischenzusammenfassungen ab. Der Protokolleintrag `compaction stage request` nennt `targetInputTokens`; das Telemetrieereignis `compaction_finished` nennt `stage_count`. Das private Verlaufsarchiv und der ursprüngliche Sitzungs-Wire bleiben vollständig.
|
|
775
|
+
|
|
776
|
+
## Wiederauffindbarer Verdichtungsverlauf
|
|
777
|
+
|
|
778
|
+
Bevor eine erfolgreiche Vollverdichtung ältere Nachrichten ersetzt, schreibt King den verdrängten Verlauf in ein privates Markdown-Archiv unter `~/.blun/conversation-history/`. Die Verdichtungszusammenfassung enthält den genauen `history_path`, sodass der Agent mit `Read` Einzelheiten wiederfinden kann, die nicht in der Zusammenfassung stehen.
|
|
779
|
+
|
|
780
|
+
Eingebettete Bild-, Audio- und Videodaten werden im Archiv nicht doppelt gespeichert. Der ursprüngliche Sitzungs-Wire bleibt maßgeblich. Kann das Archiv nicht geschrieben werden, protokolliert King `compaction_history_archive_failed` und lässt den normalen Verdichtungsweg verfügbar; ein Archivfehler löscht niemals den gespeicherten Sitzungsverlauf.
|
|
781
|
+
|
|
782
|
+
## Dauerhafte Checkpoints zwischen Arbeitsschritten
|
|
783
|
+
|
|
784
|
+
Bevor King den nächsten Modellschritt beginnt, schreibt er alle vorangegangenen Wire-Einträge dauerhaft auf den Datenträger. Nach dem Ende eines Zuges erfolgt eine weitere vollständige Sicherung, bevor der zugehörige Worker abgeschlossen wird. Das schließt beendete Modell- und Werkzeugschritte ein. Eine fortgesetzte Sitzung beginnt dadurch beim letzten abgeschlossenen Schritt und ist nicht auf noch ungesicherte Einträge im Arbeitsspeicher angewiesen.
|
|
785
|
+
|
|
786
|
+
Beispiel: Wenn der Anbieter oder das Terminal nach einem abgeschlossenen Werkzeugaufruf, aber vor der nächsten Modellantwort ausfällt, kann die Sitzung neu gestartet oder fortgesetzt werden. Der vorangegangene Werkzeugeintrag wurde vor der nächsten Anfrage an den Anbieter in `wire.jsonl` synchronisiert und wird beim Fortsetzen wieder eingelesen. Der Checkpoint verkürzt keine Prompts und ersetzt nicht die wiederauffindbaren Verdichtungsarchive; er schützt die Übergabe zwischen zwei Arbeitsschritten.
|
|
787
|
+
|
|
788
|
+
## Schlanker Basissystemprompt
|
|
789
|
+
|
|
790
|
+
Der dauerhaft geladene Basissystemprompt umfasst jetzt 4.850 statt 23.109
|
|
791
|
+
Zeichen. Identität, Persona und Seele, Antwortsprache, Arbeits- und
|
|
792
|
+
Berechtigungsgrenzen, Verdichtungsübergabe, Betriebssystem und Shell,
|
|
793
|
+
Arbeitsordner, `AGENTS.md` sowie das schrittweise Nachladen von Skills bleiben
|
|
794
|
+
erhalten. Wiederholte Regeln, die bereits in diesen eingespeisten Blöcken oder
|
|
795
|
+
in den einzelnen Werkzeugschemas stehen, werden nicht erneut mitgesendet.
|
|
796
|
+
|
|
797
|
+
Beispiel: Beim Sitzungsstart erhält King weiterhin die ausgewählte Persona und
|
|
798
|
+
Seele, die Sprache des Nutzers, den aktuellen Arbeitsordner, geltende
|
|
799
|
+
`AGENTS.md`-Anweisungen und die kompakte Skill-Liste. Lediglich doppelte
|
|
800
|
+
Dauerhinweise entfallen. Das spart rund 4.565 geschätzte Prompt-Token je
|
|
801
|
+
vollständiger Anfrage, ohne Gesprächsverlauf oder Werkzeugergebnisse zu kürzen.
|
|
802
|
+
|
|
803
|
+
## Korrigierte Markenfarben in der Fußzeile
|
|
804
|
+
|
|
805
|
+
Das kompakte BLUN-Zeichen unter der Eingabe zeigt die Markenfarben wieder in
|
|
806
|
+
der richtigen Reihenfolge: Der Statuspunkt und `UN` verwenden die Primärfarbe,
|
|
807
|
+
`BL` bleibt weiß. Die Korrektur betrifft nur die Darstellung; Statuswerte,
|
|
808
|
+
Profilname und Persona bleiben unverändert.
|
|
809
|
+
|
|
810
|
+
## Einheitliche verwaltete Node-Laufzeit
|
|
811
|
+
|
|
812
|
+
Startet BLUN unter Windows oder macOS mit einer Node.js-Version vor 24.15.0,
|
|
813
|
+
richtet es eine private unterstützte Laufzeit ein und startet damit neu. Ab
|
|
814
|
+
BLUN King 9.1.135 steht das Verzeichnis dieser verwalteten Laufzeit auch im
|
|
815
|
+
`PATH` des Ersatzprozesses und aller untergeordneten Werkzeuge an erster Stelle.
|
|
816
|
+
|
|
817
|
+
Dadurch verwenden vom Agenten gestartete Befehle wie `node` und `npm` dieselbe
|
|
818
|
+
unterstützte Laufzeit wie die TUI, statt auf eine ältere Systeminstallation
|
|
819
|
+
zurückzufallen. Die globale Node-Installation des Systems wird nicht verändert.
|
|
820
|
+
OAuth, gespeicherte Anmeldedaten, Sitzungen und der Updatestatus bleiben
|
|
821
|
+
unverändert.
|