blun-king-cli 9.1.516 → 9.1.518

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 CHANGED
@@ -1,5 +1,17 @@
1
1
  # Changelog
2
2
 
3
+ ## 9.1.518 - 2026-08-31
4
+
5
+ - Keeps `Read`, `Write`, `Edit`, and `Bash` available alongside `TodoList` during proactive task-list maintenance, preserving the normal recovery path for large file changes.
6
+ - Retains automatic Todo maintenance and its bounded evidence prompt without switching the active model step to a TodoList-only tool catalogue.
7
+ - Adds a red-to-green regression gate against the 9.1.499 catalogue change and verifies recovery-tool selection without duplicate schemas.
8
+
9
+ ## 9.1.517 - 2026-08-31
10
+
11
+ - Keeps `Ctrl+S` and `Escape` queue controls available while an approval panel is open: `Ctrl+S` flushes all waiting messages, while `Escape` releases one waiting message before rejecting the approval when the queue is empty.
12
+ - Observes asynchronous session cancellation in the keyboard, Telegram `/reload`, and slash-command paths, treating `session.not_found` as an already-stopped session instead of crashing the core with an unhandled rejection.
13
+ - Adds red-to-green package gates for the raw Windows control bytes and the measured stale-session cancellation failure.
14
+
3
15
  ## 9.1.516 - 2026-08-31
4
16
 
5
17
  - Caps the first tool-capable turn's wait for the initial MCP catalogue at 2.5 seconds, so a cold optional desktop server can finish in the background instead of blocking Read, Bash, Grep, TodoList, Telegram, and AgentSpine.
package/LIESMICH.txt CHANGED
@@ -9,11 +9,11 @@ Installation
9
9
  ------------
10
10
  Die geprüfte Version exakt global installieren:
11
11
 
12
- npm install -g blun-king-cli@9.1.516
12
+ npm install -g blun-king-cli@9.1.518
13
13
 
14
14
  AgentSpine 0.10.1
15
15
  -----------------
16
- Version 9.1.516 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.
16
+ Version 9.1.518 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.
17
17
 
18
18
  Start
19
19
  -----
package/README.md CHANGED
@@ -9,12 +9,12 @@ Voraussetzung ist Node.js 24.15 oder neuer. Die geprüfte Version wird exakt
9
9
  installiert:
10
10
 
11
11
  ```powershell
12
- npm install -g blun-king-cli@9.1.516
12
+ npm install -g blun-king-cli@9.1.518
13
13
  ```
14
14
 
15
15
  ## AgentSpine 0.10.1
16
16
 
17
- Version 9.1.516 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.
17
+ Version 9.1.518 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
18
 
19
19
  ## Reproduzierbares Staging und Packen
20
20
 
package/blun.mjs CHANGED
@@ -262877,11 +262877,12 @@ var init_turn = __esmMin((() => {
262877
262877
  mode: todoMaintenanceMode,
262878
262878
  workCallsSinceRefresh: this.agent.goalTodoPolicyState?.workCallsSinceRefresh ?? 0
262879
262879
  });
262880
+ const todoMaintenanceTools = goalTodoMaintenanceTools(eligibleTools, selectedTools);
262880
262881
  const todoSystemPrompt = buildGoalTodoMaintenanceSystemPrompt(this.agent, todoMaintenanceMode);
262881
262882
  const todoMessages = buildGoalTodoMaintenanceMessages(this.agent, todoMaintenanceMode);
262882
262883
  return {
262883
262884
  llm: this.agent.llmForTurn("low", todoSystemPrompt),
262884
- tools: [todoTool],
262885
+ tools: todoMaintenanceTools,
262885
262886
  buildMessages: () => todoMessages,
262886
262887
  buildMessagesStrict: () => todoMessages
262887
262888
  };
@@ -423347,6 +423348,13 @@ const IDEA_CONTRACT_MARKER = "Work as a self-directing employee:";
423347
423348
  const IDEA_ALLOWED_CHANNELS = Object.freeze([]);
423348
423349
  const GOAL_TODO_REFRESH_WORK_CALL_LIMIT = 8;
423349
423350
  const GOAL_TODO_EVIDENCE_LIMIT = 8;
423351
+ const TODO_MAINTENANCE_RECOVERY_TOOL_NAMES = new Set([
423352
+ "TodoList",
423353
+ "Read",
423354
+ "Write",
423355
+ "Edit",
423356
+ "Bash"
423357
+ ]);
423350
423358
  const IDEA_TERMINAL_TODO_STATUSES = Object.freeze([
423351
423359
  "done",
423352
423360
  "blocked",
@@ -423425,6 +423433,14 @@ function goalTodoMaintenanceMode(agent) {
423425
423433
  progress.refreshRequired = true;
423426
423434
  return "refresh";
423427
423435
  }
423436
+ function goalTodoMaintenanceTools(eligibleTools, selectedTools) {
423437
+ const seen = new Set();
423438
+ return [...selectedTools, ...eligibleTools.filter((tool) => TODO_MAINTENANCE_RECOVERY_TOOL_NAMES.has(tool.name))].filter((tool) => {
423439
+ if (seen.has(tool.name)) return false;
423440
+ seen.add(tool.name);
423441
+ return true;
423442
+ });
423443
+ }
423428
423444
  function buildGoalTodoMaintenanceSystemPrompt(agent, mode) {
423429
423445
  const todos = ideaTodos(agent);
423430
423446
  const visibleTodoList = todos.length === 0 ? "The visible TodoList is empty." : ["Current visible TodoList:", ...todos.map((todo) => `- [${String(todo?.status ?? "pending")}] ${String(todo?.title ?? "").trim()}`)].join("\n");
@@ -499199,12 +499215,16 @@ var ApprovalPanelComponent = class extends Container {
499199
499215
  request;
499200
499216
  onToggleToolOutput;
499201
499217
  onOpenPreview;
499202
- constructor(request, onResponse, onToggleToolOutput, onOpenPreview) {
499218
+ onCtrlS;
499219
+ onEscape;
499220
+ constructor(request, onResponse, onToggleToolOutput, onOpenPreview, onCtrlS, onEscape) {
499203
499221
  super();
499204
499222
  this.request = request;
499205
499223
  this.onResponse = onResponse;
499206
499224
  this.onToggleToolOutput = onToggleToolOutput;
499207
499225
  this.onOpenPreview = onOpenPreview;
499226
+ this.onCtrlS = onCtrlS;
499227
+ this.onEscape = onEscape;
499208
499228
  this.feedbackInput.onSubmit = (value) => {
499209
499229
  this.submit(this.selectedIndex, value);
499210
499230
  };
@@ -499231,7 +499251,16 @@ var ApprovalPanelComponent = class extends Container {
499231
499251
  } else this.submit(index);
499232
499252
  }
499233
499253
  handleInput(data) {
499234
- if (matchesKey(data, Key.escape) || matchesKey(data, Key.ctrl("c")) || matchesKey(data, Key.ctrl("d"))) {
499254
+ if (matchesKey(data, Key.escape)) {
499255
+ if (this.onEscape?.() === true) return;
499256
+ this.onResponse({ response: "rejected" });
499257
+ return;
499258
+ }
499259
+ if (matchesKey(data, Key.ctrl("s"))) {
499260
+ this.onCtrlS?.();
499261
+ return;
499262
+ }
499263
+ if (matchesKey(data, Key.ctrl("c")) || matchesKey(data, Key.ctrl("d"))) {
499235
499264
  this.onResponse({ response: "rejected" });
499236
499265
  return;
499237
499266
  }
@@ -505987,7 +506016,10 @@ var EditorKeyboardController = class {
505987
506016
  }
505988
506017
  cancelCurrentStream() {
505989
506018
  this.host.cancelRunningShellCommand();
505990
- this.host.session?.cancel();
506019
+ this.host.session?.cancel().catch((error) => {
506020
+ if (error instanceof BlunError && error.code === ErrorCodes.SESSION_NOT_FOUND) return;
506021
+ this.host.showError(formatErrorMessage$2(error));
506022
+ });
505991
506023
  }
505992
506024
  cancelCurrentCompaction() {
505993
506025
  const session = this.host.session;
@@ -518883,7 +518915,10 @@ var BlunTUI = class {
518883
518915
  const activeTurn = this.streamingUI?.hasActiveTurn?.() === true || typeof phase === "string" && phase !== "idle" || this.state.appState.isCompacting === true;
518884
518916
  if (command.name === "reload" && activeTurn && !this.queueCommandRunning) {
518885
518917
  this.state.queuedMessages.unshift(item);
518886
- this.session?.cancel();
518918
+ this.session?.cancel().catch((error) => {
518919
+ if (error instanceof BlunError && error.code === ErrorCodes.SESSION_NOT_FOUND) return;
518920
+ this.showError(formatErrorMessage$2(error));
518921
+ });
518887
518922
  this.traceTelegramDelivery?.({ stage: "queued", ...deliveryTrace, route: "channel_command", priority: "preemptive", queueDepth: this.state.queuedMessages.length });
518888
518923
  this.track("input_queue", { kind: "channel-command-preemptive" });
518889
518924
  this.updateQueueDisplay();
@@ -519396,7 +519431,10 @@ var BlunTUI = class {
519396
519431
  if (activeTurn) {
519397
519432
  this.state.queuedMessages.unshift(item);
519398
519433
  this.preserveQueueAcrossSessionReset = true;
519399
- this.session?.cancel();
519434
+ this.session?.cancel().catch((error) => {
519435
+ if (error instanceof BlunError && error.code === ErrorCodes.SESSION_NOT_FOUND) return;
519436
+ this.showError(formatErrorMessage$2(error));
519437
+ });
519400
519438
  this.track("input_queue", { kind: "command-preemptive" });
519401
519439
  this.updateQueueDisplay();
519402
519440
  this.state.ui.requestRender();
@@ -520896,6 +520934,12 @@ var BlunTUI = class {
520896
520934
  this.toggleToolOutputExpansion();
520897
520935
  }, (block) => {
520898
520936
  this.openApprovalPreview(panel, block);
520937
+ }, () => {
520938
+ this.flushQueuedMessages(this.state.editor.getText().trim(), this.state.editor.inputMode);
520939
+ this.updateQueueDisplay();
520940
+ this.state.ui.requestRender();
520941
+ }, () => {
520942
+ return this.releaseNextQueuedMessage();
520899
520943
  });
520900
520944
  this.activeApprovalPanel = panel;
520901
520945
  this.mountEditorReplacement(panel);
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "blun-king-cli",
3
- "version": "9.1.516",
3
+ "version": "9.1.518",
4
4
  "description": "BLUN CLI - your own AI agent with a Telegram channel. Get it done. With BLUN.",
5
5
  "license": "MIT",
6
6
  "bin": {
@@ -9,7 +9,7 @@
9
9
  },
10
10
  "scripts": {
11
11
  "test": "node --test test/*.test.js",
12
- "prepack": "node scripts/check-release-metadata.js && node scripts/check-todo-loop-regression.js && node scripts/check-queue-controls-regression.js && node scripts/check-telegram-bridge-watchdog.js && node scripts/check-resume-replay-regression.js && node scripts/check-plugin-startup-regression.js && node scripts/check-active-profile-plugin-startup.js && node scripts/check-mcp-startup-wait-budget.js",
12
+ "prepack": "node scripts/check-release-metadata.js && node scripts/check-todo-loop-regression.js && node scripts/check-todo-recovery-catalog-regression.js && node scripts/check-queue-controls-regression.js && node scripts/check-approval-queue-shortcuts-regression.js && node scripts/check-telegram-bridge-watchdog.js && node scripts/check-resume-replay-regression.js && node scripts/check-session-cancel-regression.js && node scripts/check-plugin-startup-regression.js && node scripts/check-active-profile-plugin-startup.js && node scripts/check-mcp-startup-wait-budget.js",
13
13
  "release:verify": "node scripts/check-release-metadata.js --external",
14
14
  "postinstall": "node scripts/fix-node-pty-perms.js"
15
15
  },
@@ -37,12 +37,15 @@
37
37
  "release-planned-removals.json",
38
38
  "scripts/check-package-regression.js",
39
39
  "scripts/check-active-profile-plugin-startup.js",
40
+ "scripts/check-approval-queue-shortcuts-regression.js",
40
41
  "scripts/check-mcp-startup-wait-budget.js",
41
42
  "scripts/check-plugin-startup-regression.js",
42
43
  "scripts/check-queue-controls-regression.js",
43
44
  "scripts/check-telegram-bridge-watchdog.js",
44
45
  "scripts/check-resume-replay-regression.js",
46
+ "scripts/check-session-cancel-regression.js",
45
47
  "scripts/check-release-metadata.js",
48
+ "scripts/check-todo-recovery-catalog-regression.js",
46
49
  "scripts/check-todo-loop-regression.js",
47
50
  "scripts/fix-node-pty-perms.js",
48
51
  "standard-skills/",
@@ -0,0 +1,65 @@
1
+ const assert = require('node:assert/strict');
2
+ const fs = require('node:fs');
3
+ const path = require('node:path');
4
+
5
+ const bundlePath = process.env.BLUN_BUNDLE_UNDER_TEST
6
+ || path.join(__dirname, '..', 'blun.mjs');
7
+ const bundle = fs.readFileSync(bundlePath, 'utf8');
8
+
9
+ function between(start, end, from = 0) {
10
+ const startIndex = bundle.indexOf(start, from);
11
+ assert.notEqual(startIndex, -1, `missing bundle marker: ${start}`);
12
+ const endIndex = bundle.indexOf(end, startIndex + start.length);
13
+ assert.notEqual(endIndex, -1, `missing bundle marker: ${end}`);
14
+ return bundle.slice(startIndex, endIndex);
15
+ }
16
+
17
+ const panelStart = bundle.indexOf('var ApprovalPanelComponent = class extends Container {');
18
+ assert.notEqual(panelStart, -1, 'ApprovalPanelComponent must exist');
19
+ const handleSource = between('\n\thandleInput(data) {', '\n\trender(width) {', panelStart).trim();
20
+
21
+ const Key = {
22
+ escape: 'escape',
23
+ ctrl(key) { return `ctrl+${key}`; },
24
+ };
25
+ const matchesKey = (data, expected) => {
26
+ if (expected === 'escape') return data === '\x1b';
27
+ if (expected === 'ctrl+s') return data === '\x13';
28
+ return data === expected;
29
+ };
30
+ const handleInput = Function(
31
+ 'matchesKey',
32
+ 'Key',
33
+ `"use strict"; return ({${handleSource}}).handleInput;`,
34
+ )(matchesKey, Key);
35
+
36
+ let responses = 0;
37
+ let flushed = 0;
38
+ let released = 0;
39
+ const panel = {
40
+ choiceCount() { return 0; },
41
+ onResponse(response) {
42
+ responses += 1;
43
+ assert.equal(response.response, 'rejected');
44
+ },
45
+ onCtrlS() { flushed += 1; },
46
+ onEscape() { released += 1; return true; },
47
+ };
48
+
49
+ handleInput.call(panel, '\x13');
50
+ assert.equal(flushed, 1, 'Ctrl+S must reach the global queue flush while approval is open');
51
+ assert.equal(responses, 0);
52
+
53
+ handleInput.call(panel, '\x1b');
54
+ assert.equal(released, 1, 'Escape must first release one queued message while approval is open');
55
+ assert.equal(responses, 0, 'a released queued message must not reject the approval');
56
+
57
+ panel.onEscape = () => false;
58
+ handleInput.call(panel, '\x1b');
59
+ assert.equal(responses, 1, 'Escape must reject the approval when no queued message waits');
60
+
61
+ const showApprovalPanel = between('\n\tshowApprovalPanel(payload) {', '\n\thideApprovalPanel() {');
62
+ assert.match(showApprovalPanel, /this\.flushQueuedMessages\(this\.state\.editor\.getText\(\)\.trim\(\), this\.state\.editor\.inputMode\)/);
63
+ assert.match(showApprovalPanel, /return this\.releaseNextQueuedMessage\(\)/);
64
+
65
+ console.log('approval queue shortcuts regression: PASS');
@@ -0,0 +1,43 @@
1
+ #!/usr/bin/env node
2
+ 'use strict';
3
+
4
+ const assert = require('node:assert/strict');
5
+ const fs = require('node:fs');
6
+ const path = require('node:path');
7
+
8
+ const bundlePath = process.env.BLUN_BUNDLE_UNDER_TEST
9
+ ? path.resolve(process.env.BLUN_BUNDLE_UNDER_TEST)
10
+ : path.join(__dirname, '..', 'blun.mjs');
11
+ const bundle = fs.readFileSync(bundlePath, 'utf8');
12
+
13
+ function between(start, end) {
14
+ const startIndex = bundle.indexOf(start);
15
+ assert.notEqual(startIndex, -1, `missing bundle marker: ${start}`);
16
+ const endIndex = bundle.indexOf(end, startIndex + start.length);
17
+ assert.notEqual(endIndex, -1, `missing bundle marker: ${end}`);
18
+ return bundle.slice(startIndex, endIndex);
19
+ }
20
+
21
+ function assertSafeCancel(source, label) {
22
+ assert.match(source, /\.cancel\(\)\.catch\(\(error\)\s*=>/,
23
+ `${label} must observe the cancellation promise`);
24
+ assert.match(source, /error instanceof BlunError && error\.code === ErrorCodes\.SESSION_NOT_FOUND/,
25
+ `${label} must treat an already-missing session as cancelled`);
26
+ assert.match(source, /showError\(formatErrorMessage\$2\(error\)\)/,
27
+ `${label} must still surface non-session errors`);
28
+ }
29
+
30
+ assertSafeCancel(
31
+ between('\n\tcancelCurrentStream() {', '\n\tcancelCurrentCompaction() {'),
32
+ 'keyboard stream cancellation',
33
+ );
34
+ assertSafeCancel(
35
+ between('\n\tinjectTelegramRemoteCommand(', '\n\trunTelegramRemoteCommand('),
36
+ 'preemptive Telegram reload cancellation',
37
+ );
38
+ assertSafeCancel(
39
+ between('\n\tenqueueSlashCommand(', '\n\tenqueueNormalUserInput('),
40
+ 'preemptive slash-command cancellation',
41
+ );
42
+
43
+ process.stdout.write('session-cancel-regression PASS\n');
@@ -0,0 +1,50 @@
1
+ #!/usr/bin/env node
2
+ 'use strict';
3
+
4
+ const fs = require('node:fs');
5
+ const path = require('node:path');
6
+
7
+ const bundlePath = process.env.BLUN_BUNDLE_UNDER_TEST
8
+ ? path.resolve(process.env.BLUN_BUNDLE_UNDER_TEST)
9
+ : path.resolve(__dirname, '..', 'blun.mjs');
10
+ const bundle = fs.readFileSync(bundlePath, 'utf8');
11
+
12
+ function assert(condition, message) {
13
+ if (!condition) throw new Error(message);
14
+ }
15
+
16
+ const namesMatch = bundle.match(
17
+ /const TODO_MAINTENANCE_RECOVERY_TOOL_NAMES = new Set\(\[([\s\S]*?)\]\);/,
18
+ );
19
+ const functionMatch = bundle.match(
20
+ /function goalTodoMaintenanceTools\(eligibleTools, selectedTools\) \{[\s\S]*?\n\}/,
21
+ );
22
+
23
+ assert(
24
+ !/proactive TodoList maintenance step[\s\S]{0,900}tools:\s*\[todoTool\]/.test(bundle),
25
+ 'TODO_RECOVERY_CATALOG_REGRESSION: proactive maintenance still switches to TodoList-only',
26
+ );
27
+ assert(namesMatch, 'TODO_RECOVERY_CATALOG_REGRESSION: recovery tool names are missing');
28
+ assert(functionMatch, 'TODO_RECOVERY_CATALOG_REGRESSION: recovery catalogue selector is missing');
29
+ assert(
30
+ /proactive TodoList maintenance step[\s\S]{0,1100}tools:\s*todoMaintenanceTools/.test(bundle),
31
+ 'TODO_RECOVERY_CATALOG_REGRESSION: proactive maintenance is not wired to the recovery catalogue',
32
+ );
33
+
34
+ const selectMaintenanceTools = Function(
35
+ `const TODO_MAINTENANCE_RECOVERY_TOOL_NAMES = new Set([${namesMatch[1]}]); return (${functionMatch[0]});`,
36
+ )();
37
+ const tools = ['TodoList', 'Read', 'Write', 'Edit', 'Bash', 'WebSearch'].map((name) => ({ name }));
38
+ const selected = [tools[5], tools[1]];
39
+ const actual = selectMaintenanceTools(tools, selected).map((tool) => tool.name);
40
+
41
+ assert(
42
+ actual.join(',') === 'WebSearch,Read,TodoList,Write,Edit,Bash',
43
+ `TODO_RECOVERY_CATALOG_REGRESSION: unexpected catalogue ${actual.join(',')}`,
44
+ );
45
+ assert(
46
+ new Set(actual).size === actual.length,
47
+ 'TODO_RECOVERY_CATALOG_REGRESSION: recovery catalogue contains duplicates',
48
+ );
49
+
50
+ process.stdout.write('todo-recovery-catalog-regression PASS\n');
@@ -1,821 +0,0 @@
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.