# blun-king-cli — npm-Distribution Dieses Verzeichnis ist das Gerüst des öffentlichen npm-Pakets `blun-king-cli` (Erstveröffentlichung 8.0.0, 06.07.2026, Account `blunking`). ## Installation Voraussetzung ist Node.js 24.15 oder neuer. Die geprüfte Version wird exakt installiert: ```powershell npm install -g blun-king-cli@9.1.605 ``` ### Windows: Node.js, npm und Git Bash Node.js ab Version 24.15 ist erforderlich; npm wird mit Node.js installiert. Unter Windows benötigt die Konsole außerdem Git Bash aus Git for Windows. Nach der Installation ein neues Terminal öffnen und prüfen: ```powershell node --version npm --version git --version ``` Wird `npm` nicht gefunden, zuerst die Node.js-Installation und den Suchpfad prüfen. Meldet die Konsole `Git Bash not found`, Git for Windows installieren oder `BLUN_SHELL_PATH` auf die vorhandene `bash.exe` setzen. Die Variable muss auf die Datei zeigen, nicht nur auf ihren Ordner. Beim Start lässt sich ein anderer Arbeitsordner über den Windows-Ordnerdialog auswählen. Ist kein Desktopdialog verfügbar, bleibt die manuelle Pfadeingabe möglich. Ein geerbter Windows-Systemordner wie `C:\Windows\System32` wird nicht als vorgeschlagener Arbeitsordner übernommen. ## Kontext, Werkzeuge und Sitzungssteuerung ab 9.1.604 Die folgenden Befehle ergänzen die vorhandene Konsole. Sie ändern weder das Modell noch dessen Kontextfenster. | Befehl | Wirkung | | --- | --- | | `/context doctor`, `/context-doctor`, `/tokens` | Zeigt die ausführliche Kontextdiagnose der aktiven Sitzung. | | `/queue` | Zeigt die aktuelle Warteschlangenregel. | | `/queue steer` | Übergibt neue Eingaben am nächsten geeigneten Übergabepunkt; ist das nicht möglich, warten sie auf den nächsten Zug. | | `/queue followup` | Verarbeitet neue Eingaben nach dem laufenden Zug. | | `/queue collect debounce:500ms batch:10` | Bündelt zusammengehörige Eingaben; weitere Eingaben bleiben in der Warteschlange. | | `/queue interrupt` | Unterbricht für neue Eingaben den laufenden Zug. | | `/queue reset`, `/queue default` | Entfernt die sitzungsspezifische Warteschlangenregel. | | `/session ` | Wählt eine Sitzung im aktuellen Arbeitsbereich. Eindeutige ID-Präfixe werden ebenfalls erkannt; bei Mehrdeutigkeit öffnet sich die Auswahl. | | `/question` | Öffnet noch ausstehende Rückfragen erneut. Das Einklappen beantwortet oder verwirft sie nicht. | | `/usage off`, `/usage tokens`, `/usage full` | Speichert den Anzeigemodus für den Verbrauch in dieser Sitzung. | | `/usage reset` | Entfernt den sitzungsspezifischen Anzeigemodus. `inherit`, `clear` und `default` sind gleichwertig. | | `/settings` | Öffnet die Einstellungen einschließlich der lokalen Anzeigeoptionen. | Bei `/queue` sind `debounce:0ms` bis `debounce:60s` und `batch:1` bis `batch:100` zulässig. `batch` begrenzt die Bündelgröße und löscht keine überschüssigen Nachrichten. Es gibt keine `cap:`- oder `drop:`-Option. Die Warteschlangenregel und der Verbrauchsmodus bleiben beim Fortsetzen derselben Sitzung erhalten. Gewöhnliche neue Kanalnachrichten lösen nicht mehr automatisch nach 30 Sekunden einen Abbruch aus; ausdrücklich angeforderte Unterbrechungen bleiben möglich. Die Kontextdiagnose unterscheidet den gespeicherten Verlauf, geschätzte Tokenzahlen und die tatsächlich serialisierten Anfrage-Bytes. Für die letzte erfasste Anfrage weist sie bekannte Beiträge von AGENTS-Regeln, Mistake-Dateien, eingebundenem Gedächtnis, Skills und Werkzeugdefinitionen getrennt aus. Fehlende Herkunftsdaten bedeuten nicht null Byte. Anfrage-Bytes sind weder Tokenzahlen noch eine Rechnung. Größere Werkzeugkataloge werden über die vorhandene Werkzeugsuche nach Bedarf eingeblendet. Die Schwelle liegt bei 8.000 geschätzten Schema-Token; notwendige Werkzeuge können darüber liegen. Werkzeuge werden dadurch nicht entfernt, und das Modellfenster wird nicht verkleinert. Das Transportprotokoll erhält für jeden HTTP-Versuch eine eigene `x-request-id`. Bereits vorgegebene Kennungen bleiben unverändert und werden nicht als beliebiger Fremdtext protokolliert. Damit lassen sich Client- und Servermessungen zuordnen; die Kennung ist kein Abrechnungsschlüssel. Die Verbrauchsanzeige berücksichtigt auch die Antwortprüfung. `/usage cost` mit Tages- oder Monatskosten gehört nicht zu dieser Fassung. Eine geringere Rechnung oder kürzere Antwortzeit im Live-Betrieb ist durch die lokalen Prüfungen nicht belegt. ## Reproduzierbares Staging und Packen Der Schritt baut nichts, installiert nichts und veröffentlicht nichts. Vorher müssen `apps/blun-king/dist/main.mjs`, `dist-web`, die Darwin- und Windows-Natives sowie `plugins/telegram/dist` bereits frisch gebaut sein. Das Staging landet standardmäßig unter `.stage/package`, das Tarball unter `.stage/artifacts`. `BLUN_NPM_STAGE_DIR` und `BLUN_NPM_ARTIFACT_DIR` können beide Ziele überschreiben; beim direkten Skriptaufruf stehen zusätzlich `--output` und `--artifacts` bereit. Der Schritt validiert alle Pflichtartefakte vor dem Leeren des alten Stagings. Er kopiert nur die Paket-Hülle, `blun.mjs`, `dist-web`, `native`, Telegrams `dist`/Manifest/Commands und die Repo-Skills. ## Startmodi `blun` startet die lokale Konsole, ohne Telegram automatisch anzubinden. `king` startet dieselbe Konsole und bindet den eingerichteten Telegram-Kanal automatisch an. Version, Konto, Modell und Befehle sind ansonsten identisch. Der Unterschied gilt nur für den laufenden Prozess; die gespeicherte Plugin-Konfiguration wird nicht umgeschrieben. Beim ersten Start werden das Telegram-Plugin und die mitgelieferten Skills eingerichtet. Die Anmeldung erfolgt anschließend in der Konsole mit `/login` über den BLUN-OAuth-Server. Das Paket erzeugt keine statische Anbieter- oder API-Key-Konfiguration. ## Persönliches Gedächtnis Seit Version 9.1.599 zeigt BLUN King Freigaben für das persönliche Gedächtnis mit übersetzten Aktionstiteln und vollständigen Vorschauen der tatsächlichen Einstellungsänderungen oder des zu speichernden Textes. Gültige Änderungen lassen sich nur einmalig freigeben, ungültige Eingaben nur ablehnen. Eine Sitzungsfreigabe genehmigt solche wartenden Anfragen nicht automatisch. Steuerzeichen werden sichtbar maskiert; der Originalinhalt bleibt unverändert. ## Zeitgrenzen für die Antwortprüfung Version 9.1.600 begrenzt die Antwortprüfung pro äußerem Prüfversuch auf insgesamt 120 Sekunden. Allgemeine Prüfer behalten die bisherige Frist von 30 Sekunden. Bei der nativen Sprachprüfung stehen nach dem bestätigten Start einmalig bis zu 90 Sekunden für den ersten inhaltlichen Text bereit; auch dabei gilt die Gesamtgrenze. Inhaltlicher Text innerhalb der zulässigen Ausgabelänge sowie die geordneten Übergänge zur Freigabe und zur Belegprüfung setzen die Wartefrist jeweils auf 30 Sekunden zurück, ohne die Gesamtgrenze zu verlängern. Es bleibt bei höchstens zwei äußeren Prüfversuchen. Abbruch, exakte Bindung an den Antworttext, Belegablauf und Autorisierung bleiben unverändert. Damit ist keine Behebung von HTTP-502-Fehlern im Live-Betrieb nachgewiesen. ## Festgelegte Komponentenstände - AgentSpine 0.73.0, Commit `38cb94760b19e3a82e7efdf12538a1adf5324964`. - Translate Native 6.155.0, Commit `21efc66da8f77992c8c63ac0f145a106c31e7eb2`. - Guard-Protokoll unverändert auf 6.20.0. ## Nachweisbare Arbeitsabläufe Version 9.1.0 enthält sieben zusätzliche, getrennt nutzbare Befehlsgruppen: - `proof` belegt Prüfungen und Artefakte mit SHA-256. - `brief` erstellt einen versionierten Projektauftrag. - `handoff` übergibt eine Sitzung zwischen CLI, Desktop und Web. - `replay` erzeugt einen bereinigten Arbeitsverlauf. - `guard` prüft Belegintegrität und aktuelle Artefakte. - `demo` erzeugt eine bereinigte statische Projektdemo. - `workspace` verwaltet isolierte Git-Arbeitsbereiche. Sie stehen unter `blun` und `king` identisch zur Verfügung. ## Aktualisieren `blun update`, `king update` und die jeweilige Variante `upgrade` verwenden denselben abgesicherten Updater. Er bleibt im installierten Stable- oder Next-Kanal, verhindert Rückstufungen und übergibt npm ausschließlich eine zuvor aufgelöste exakte Paketversion. ## Absturzdiagnose unter Windows Startfehler und unbehandelte Ausnahmen werden im begrenzten, bereinigten Protokoll `BLUN_HOME/diagnostics/runtime-exits.jsonl` erfasst. Die Diagnose startet keinen neuen Prozess und ändert beim Start keine Windows-Registrywerte. Ausführliche Node-Berichte sind optional. Nur `BLUN_NODE_CRASH_REPORTS=1` aktiviert sie für den gestarteten Prozess. Die Berichte liegen unter `BLUN_HOME/diagnostics/crash-dumps`. Umgebungsvariablen und Netzwerkinformationen werden ausgeschlossen; Programmargumente, Dateipfade und weitere sensible Prozessdaten können trotzdem enthalten sein. Berichte vor einer Weitergabe prüfen. Drei gemeinsam reservierte Plätze begrenzen die Anzahl dieser Node-Berichte, nicht deren Dateigröße. Ein ordentlich beendeter Prozess gibt seine Reservierung frei; ein späterer Prozess kann den Bericht dieses Platzes ersetzen. Aktive oder unklar verwaiste Reservierungen werden nicht automatisch entfernt. Sind alle Plätze belegt oder liegen alte Berichte mit Zufallskennung vor, bleiben neue Detailberichte aus, bis der Betreiber diese Dateien ausdrücklich geprüft und bereinigt hat. Der normale Start und das kleine Fehlerprotokoll bleiben davon unabhängig. Sitzungen und fremde Dateien werden nicht entfernt. Native Windows-Dumps sind davon getrennt. Der mitgelieferte Helfer `bin/windows-node-crash-dump.cjs` bietet `--query-wer` für eine reine Abfrage. Eine Änderung erfordert ausdrücklich `--configure-wer --confirm-system-wide`, ein gesetztes `BLUN_HOME` und ausreichende Windows-Rechte. Sie betrifft alle Prozesse namens `node.exe`, nicht nur BLUN: drei Minidumps im angegebenen Diagnoseordner. Bei einem Teilfehler nennt die JSON-Ausgabe die bereits gesetzten Werte. Der normale Start ruft diesen Befehl niemals auf. Node-Berichte erfassen unterstützte Node-Fehler; sie sind kein Beleg dafür, dass jeder native Windows-Abbruch erfasst wird. Die Funktion lässt den ursprünglichen Fehler und den vorgesehenen Prozessabbruch bestehen.