BLUN King

BLUN King 9.1.621

Publicada em

O King só adota um resumo da tua conversa quando o modelo confirmou a sua conclusão. Se faltar essa confirmação, o teu histórico de conversa anterior permanece inalterado.

Se a transmissão do resumo terminar inesperadamente, o teu contexto de conversa anterior não é substituído pelo resumo incompleto. A alteração afeta apenas a compactação da conversa; as respostas normais permanecem inalteradas.

Continuam abertos alguns erros pontuais ao guardar uma sessão; não foram corrigidos com esta atualização.

BLUN King

BLUN King 9.1.620

Publicada em

No Windows, a consola é encerrada completamente ao fechar a janela, para que «já está em execução» deixe de aparecer no próximo início.

A atualização corrige o encerramento do processo da consola ao fechar a janela. Uma consola que ainda esteja efetivamente em execução mantém o acesso exclusivo à sua sessão.

BLUN King

BLUN King 9.1.619

Publicada em

Um único erro anterior ao compactar a conversa já não bloqueia a tua sessão: após uma compactação bem-sucedida, o King conta apenas erros novos e diretamente consecutivos.

Um único erro anterior ao compactar a conversa já não bloqueia a tua sessão: após uma compactação bem-sucedida, o King conta apenas erros novos e diretamente consecutivos. Se a compactação falhar duas vezes seguidas, a mensagem mostra agora claramente «Compactação em pausa» em vez de comunicar um contexto completo.

Continuam abertos alguns erros pontuais ao guardar uma sessão e ao criar um resumo completo da conversa; não foram corrigidos com esta atualização.

BLUN King

BLUN King 9.1.618

Publicada em

Se, depois de retomares a tua sessão, chegar uma mensagem do Telegram enquanto o King já está a trabalhar, ela fica na fila e é entregue a seguir.

Se, depois de retomares a tua sessão, chegar uma mensagem do Telegram enquanto o King já está a trabalhar, ela fica na fila e é entregue a seguir. O King já não apresenta esta situação de espera como um erro.

Em Linux x64, o terminal utiliza um binário incluído. Assim, funciona mesmo quando o npm 12 bloqueia os scripts de instalação; para isso, não é necessário um compilador. Com esse fim, o King utiliza a versão preliminar fixada node-pty 1.2.0-beta.15.

BLUN King

BLUN King 9.1.617

Publicada em

Ao recarregar a mesma sessão, o King deixa de adicionar várias vezes as instruções de plugins que não foram alteradas.

Ao recarregar a mesma sessão, o King deixa de adicionar várias vezes as instruções de plugins que não foram alteradas. Se as instruções mudarem, o King continua a ter em conta o estado atual.

As pré-visualizações de grandes saídas de ferramentas passam também a ter em conta a janela de contexto disponível. Continuas a poder ler na íntegra as saídas transferidas para fora.

Com /profile ou /profiles abres a seleção de perfil. O King só faz a mudança quando a tua sessão está pronta. O trabalho em curso e as mensagens em espera impedem uma mudança prematura; nesse caso, o teu perfil anterior permanece ativo.

Quando interrompes um trabalho em curso, o King espera também pelos últimos passos de limpeza. Um trabalho ainda não concluído não é confirmado prematuramente como terminado.

BLUN King

BLUN King 9.1.616

Publicada em

Após uma resposta confirmada no Telegram, o King recolhe outras mensagens dirigidas a ti no próximo passo seguro, mesmo durante um turno em curso.

Após uma resposta confirmada no Telegram, o King recolhe outras mensagens dirigidas a ti no próximo passo seguro, mesmo durante um turno em curso. Uma resposta já entregue deixa de reter a fila. As respostas permanecem associadas ao respetivo chat.

Se interromperes um turno, as mensagens do Telegram ainda não recolhidas ficam guardadas para a próxima entrega. O King só as confirma quando a sessão as recolhe de facto.

BLUN King

BLUN King 9.1.615

Publicada em

O King mantém grandes catálogos de ferramentas disponíveis através da pesquisa de ferramentas e ajusta o orçamento de ferramentas à janela de contexto do fornecedor.

O King mantém grandes catálogos de ferramentas disponíveis através da pesquisa de ferramentas, sem enviar ao modelo todos os esquemas opcionais de ferramentas. Se o fornecedor comunicar uma janela de contexto mais pequena, o King ajusta o orçamento de ferramentas; as ferramentas encontradas permanecem disponíveis no passo seguinte.

Quando necessário, o King transfere para fora as grandes saídas de ferramentas mais cedo do que antes. Podes obter a saída completa como antes, desde que possa ser apresentada com segurança.

As respostas normais do Telegram e as alterações a mensagens deixam de ser retidas por falta de uma aprovação linguística. Uma verificação de respostas que tenhas configurado permanece ativa.

BLUN King

BLUN King 9.1.614

Publicada em

Ficheiros AGENTS.md e AGENTS.override.md demasiado grandes deixam de interromper um turno apenas por causa do seu tamanho.

Fora da consola King, o King lê no total até 32 KiB de ficheiros de instruções e diz-te uma vez por sessão quantos bytes foram omitidos.

Na consola King, os ficheiros permanecem completos enquanto o limite do pedido o permitir.

As ligações simbólicas e os caminhos não seguros permanecem bloqueados.

BLUN King

BLUN King 9.1.613

Publicada em

O King reconhece pedidos ao modelo demasiado grandes já antes do envio.

Na consola King, o King lê de cada ficheiro AGENTS.md e AGENTS.override.md no máximo 32 KiB. O que ultrapassa esse limite, o King omite e mostra-te quantos bytes foram omitidos.

Antes do envio, o King estima agora o tamanho de todo o pedido ao modelo, incluindo instruções, histórico, definições de ferramentas e dados de imagem. Quando se aproxima do limite de bytes do servidor, começa uma compactação gradual. Se um pedido não puder ser dividido em segurança, o King interrompe sem descartar silenciosamente o histórico guardado.

O King guarda localmente as chamadas de ferramentas concluídas como metadados: nome da ferramenta, momento, estado e, no caso de ferramentas de ficheiros, eventualmente o caminho. Entradas, saídas, comandos e chaves não são guardados. Com /memory tools podes pesquisar nas entradas do teu perfil.

O diagnóstico de contexto mostra números adicionais sobre a composição dos pedidos. Uma medição de fases ativável regista o tempo até à chamada ao modelo sem registar conteúdo.

O indicador de utilização inclui os tokens de pensamento comunicados em separado, desde que o fornecedor os entregue.

Não lançada, substituída por 9.1.613

BLUN King 9.1.612

Publicada em

9.1.612 não foi publicada como atualização para clientes. A proteção precoce por bytes não atuava num pedido superior a 900 KB quando o histórico, por si só, permanecia abaixo de 600 KB. 9.1.613 substitui esta versão.

BLUN King

BLUN King 9.1.611

Publicada em

Os pedidos grandes de compactação permanecem dentro do limite de bytes do servidor.

  • O King divide um pedido de compactação demasiado grande em passos cronológicos, consoante o tamanho do pedido. Assim, a compactação pode continuar mesmo quando o pedido contém mais bytes do que o servidor aceita de uma só vez.
  • Se mesmo uma única mensagem não couber no limite, o teu histórico guardado permanece inalterado. O King não o descarta para forçar a compactação.

Com isto não se comprova um tempo de espera do modelo mais curto nem um menor consumo de tokens. Uma atualização não reinicia uma sessão do King já em execução.

BLUN King

BLUN King 9.1.610

Publicada em

Já podes voltar a instalar o King no Linux e a iniciar perfis, e um segundo arranque do King no Windows já não falha com uma mensagem enganadora sobre as ACL privadas.

  • O Linux voltou a constar da lista de sistemas operativos suportados do pacote npm. Se tiveres no Linux uma versão mais antiga, instalas a 9.1.610 através do atualizador normal.
  • Arranques explícitos com --profile e abreviaturas existentes de nomes de perfis conduzem ao diretório do perfil escolhido. Um simples nome desconhecido já não cria silenciosamente um perfil vazio; para criar um perfil novo, usa deliberadamente --profile.
  • Se um perfil existente não tiver autenticação própria, o King propõe /login, em vez de interromper por falta de uma configuração de modelo blun/king.
  • No Windows, a verificação de diretórios privados também é bem-sucedida quando o bridge do Telegram mantém aberto um diretório de plugins. TEMP e TMP são transmitidos ao auxiliar de ACL, e em caso de erros de diretório o King indica o caminho afetado e a causa real.
  • Se já estiver a correr um King interativo, o King deteta isso antes do endurecimento das ACL privadas e comunica o respetivo PID, em vez de apresentar um segundo arranque como erro nas ACL privadas.

Um perfil vazio não herda em 9.1.610 os dados de autenticação do diretório home partilhado. A atual solicitação de /login ainda pode apresentar «OAuth login expired», mesmo que este perfil nunca tenha iniciado sessão.

O percurso de atualização do Linux de 9.1.114 para 9.1.610 foi percorrido após a publicação. O percurso de atualização do Windows de 9.1.609 para 9.1.610 não foi medido.

Uma atualização não reinicia uma sessão do King já em execução.

BLUN King

BLUN King 9.1.609

Publicada em

Abre a seleção de esforço com Ctrl+L sem perderes o teu rascunho no editor.

  • Ctrl+L abre a seleção de esforço existente sem perderes o teu rascunho no editor. As definições de esforço existentes e as limitações de modelos são reutilizadas, em vez de criar um segundo caminho de configuração.
  • A regra existente para sessões em execução mantém-se: uma alteração de esforço durante trabalho ativo é recusada, não fica anotada para mais tarde. Durante a reprodução ou quando o editor assume o controlo, o atalho de teclado é ignorado.

Estas alterações não comprovam tempos de resposta mais rápidos em funcionamento nem um menor consumo faturado de tokens e não estabelecem uma paridade completa com o OpenClaw.

BLUN King

BLUN King 9.1.608

Publicada em

Em grupos do Telegram, só chegam ao King as mensagens que o mencionam. As tuas seleções múltiplas e o cancelamento faseado de perguntas mantêm-se.

  • Em grupos do Telegram, as mensagens que não se dirigem ao King só entram no contexto da sessão depois da verificação de menções. Quem desativou expressamente a verificação mantém essa opção.
  • As seleções múltiplas próprias e o cancelamento faseado de perguntas mantêm-se. O rodapé do objetivo funciona com um temporizador de atualização comum.
  • O esforço da transferência das ACL do Windows diminui sem que a verificação de permissões seja enfraquecida. A recuperação após erros temporários na substituição da configuração é limitada; a propriedade da operação de escrita mantém-se.
  • Antes de tentar novamente, o King verifica se um marcador de escritor do Windows removido em paralelo desapareceu realmente. Marcadores existentes que não podem ser lidos continuam a levar à interrupção.

Estas alterações não comprovam tempos de resposta mais rápidos em funcionamento nem um menor consumo faturado de tokens e não estabelecem uma paridade completa com o OpenClaw.

BLUN King

BLUN King 9.1.607

Publicada em

A tua última sessão escolhida volta, as operações de escrita falhadas são comunicadas com honestidade e cada tentativa HTTP recebe um carimbo de hora de início.

  • A recuperação opcional da última sessão escolhida pode ser ativada com resume_last_selected em tui.toml. A seleção vale para a conta confirmada, o runtime, o agente e a área de trabalho. O arranque normal permanece inalterado; as escolhas explícitas de sessão têm prioridade; as escolhas indisponíveis dão lugar a uma sessão nova, não a outra.
  • Após uma ativação falhada, a seleção anterior mantém-se. Se a conta tiver mudado durante a ativação, não é guardada nenhuma seleção.
  • As operações de escrita de ficheiros falhadas não são assinaladas como bem-sucedidas. O protocolo de continuação existente para linhas completas em operações de escrita superiores a 2 048 bytes UTF-8 é explicado, sem aumentar o limite nem tentar novamente automaticamente.
  • Imediatamente antes de cada tentativa HTTP é registado um carimbo de hora de início segundo o relógio de parede para a correlação de diagnóstico. Os conteúdos dos pedidos ou os dados de acesso não entram no diagnóstico.
  • Os caracteres Unicode fora do plano básico (por exemplo, emojis) permanecem integralmente preservados dentro dos limites existentes do orçamento de memória, sem que esses orçamentos sejam aumentados ou seja criada memória adicional.

Estas alterações não comprovam tempos de resposta mais rápidos em funcionamento nem um menor consumo faturado de tokens, não estabelecem uma paridade completa de gateway e não excluem do contexto as mensagens do Telegram que não se dirigem ao King.

BLUN King

BLUN King 9.1.606

Publicada em

Ao retomar uma sessão, aparecem primeiro as páginas atuais da transcrição; as páginas mais antigas são carregadas pela navegação existente da transcrição.

  • Ao retomar uma sessão interativa, aparecem primeiro as páginas atuais da transcrição; as páginas mais antigas são carregadas pela navegação existente da transcrição. O histórico completo guardado e o contexto ativo do modelo mantêm-se.
  • No arranque aplica-se um objetivo de exibição de 200 registos de reprodução. Com --history-limit de 1 a 2000 pode ajustar-se a exibição da primeira página e das mais antigas; rondas completas de conversa e pares de ferramentas podem exceder o objetivo.
  • A primeira exibição das ativações de skills e plugins mantém-se através dos limites de página. A posição de deslocamento do início foi corrigida, de modo que carregar páginas mais antigas não deixa um ecrã vazio.

Estas alterações reduzem o trabalho inicial de renderização da transcrição. Não comprovam tempos de resposta do modelo mais rápidos, nem menor consumo de tokens ou faturas mais baixas, não melhoram a cache do fornecedor e não limitam o que é lido do disco no arranque.

BLUN King

BLUN King 9.1.605

Publicada em

Verifica as fontes de contexto, controla os processos em curso e entrega uma primeira mensagem no arranque da consola. O processamento do histórico local e as verificações de compactação foram alargados.

  • Os históricos locais de sessão são reproduzidos de forma agrupada. As páginas de exibição arquivadas podem ser encontradas sem percorrer todos os blocos anteriores. O histórico integralmente guardado, as verificações de integridade do arquivo e a recuperação anterior mantêm-se.
  • Os resultados repetidos de ferramentas são preparados de forma consistente para o contexto do modelo entre compactações registadas. As saídas locais completas e os direitos de leitura existentes mantêm-se. As saídas não são descarregadas se não puderem voltar a ser obtidas pelo caminho de recuperação prometido.
  • A compactação automática final só substitui o contexto ativo se reduzir o histórico segundo o mesmo método de estimativa. Em caso de recusa, o histórico original mantém-se. O acionador opcional max_request_history_bytes utiliza o controlo de compactação existente, está desativado por predefinição e não limita todo o corpo do pedido ao fornecedor.
  • O diagnóstico de contexto recebe vistas separadas e uma atribuição de fontes para instruções, memória, skills e mensagens anteriores. Os bytes do conteúdo serializado, as estimativas locais de tokens e o consumo comunicado mantêm-se separados.
  • A responsabilidade pela sessão mantém-se com tarefas em espera, eventos atrasados, perguntas de retorno e alterações de configuração. Um segundo acesso de escrita ativo à mesma sessão é recusado, em vez de permitir alterações simultâneas no registo.
  • A linha adicional de agente/sessão no rodapé deixa de existir. As sessões continuam a poder ser controladas e diagnosticadas de forma dirigida. A interface existente do King, os modelos geridos e os limites de permissões mantêm-se.
  • --message entrega uma primeira mensagem para o arranque interativo. Depois da confirmação no arranque e da seleção da sessão, é processada pela verificação normal de mensagens e pela fila de espera. O seu conteúdo não é interpretado como comando de barra ou de shell.
  • O acordo de interface do serviço de guarda incluído permanece inalterado. Esta publicação não comprova respostas mais rápidas em funcionamento, nem faturas de fornecedor mais baixas, nem uma igualdade funcional completa com o OpenClaw, nem uma quantidade limitada de leitura no carregamento inicial do registo da sessão.

/abort interrompe o processo em curso sem descartar as entradas em espera. /stop descarta adicionalmente as entradas em espera. /exit continua a terminar a consola. Estes são comandos locais da consola, não comandos remotos adicionais do Telegram.

Verificações no estado do pacote 9.1.605: 238 ficheiros de verificação com 6 900 testes, bem como 40 verificações de preparação, incluindo 25 verificações nativas de terminal. O teste de uma atualização isolada de 9.1.604 através da etiqueta de candidato publicada com o instalador real foi bem-sucedido. Com isto não ficam comprovados tempos de aquecimento mais curtos numa sessão em execução nem uma igualdade funcional completa com o OpenClaw.

BLUN King

BLUN King 9.1.604

Publicada em

Verifica o tamanho dos pedidos e as fontes de contexto, carrega as ferramentas conforme necessário e controla as mensagens recebidas dentro da respetiva sessão.

  • /context doctor e /tokens distinguem o número de bytes do pedido serializado das estimativas de tokens e mostram as partes registadas de regras, memória, skills e definições de ferramentas.
  • Os catálogos de ferramentas de tamanho médio são carregados conforme necessário através da pesquisa existente; as ferramentas continuam localizáveis e executáveis.
  • /queue controla as mensagens dentro da respetiva sessão. As mensagens normais na fila de espera já não interrompem automaticamente o trabalho após 30 segundos.
  • Na seleção da sessão são possíveis identificadores exatos ou títulos, bem como prefixos inequívocos de identificadores; o rodapé mostra o agente atribuído e a sessão.
  • Cada tentativa HTTP recebe um novo identificador de pedido, a menos que quem invoca forneça um. O diagnóstico não altera a faturação.
  • As versões incluídas do AgentSpine e do Translate Native permanecem inalteradas. Custos mais baixos e respostas mais rápidas em funcionamento real não estão comprovados.
  • /question: reabre as perguntas de retorno pendentes. Recolher não responde nem descarta uma pergunta de retorno.

Os bytes do pedido, as estimativas de tokens, o consumo acumulado da sessão e os tokens faturados são grandezas diferentes. A indicação de consumo tem também em conta a verificação de respostas. /usage cost com custos diários ou mensais não faz parte desta versão. Custos mais baixos ou respostas mais rápidas em funcionamento real não estão comprovados.

BLUN King

BLUN King 9.1.603

Publicada em

Escolhe a tua pasta de trabalho numa caixa de diálogo do Windows. Se a consola for iniciada a partir de System32, sugere agora a tua pasta de utilizador.

  • Se escolheres no Windows outra pasta de trabalho, abre-se uma caixa de diálogo de pastas. Podes continuar a introduzir o caminho manualmente. Se cancelares a caixa de diálogo, voltas à seleção de pastas sem adotar nenhuma pasta.
  • Se não estiver disponível nenhuma caixa de diálogo de pastas, a consola pede o caminho. Noutros sistemas operativos, mantém-se a introdução do caminho.
  • Se no arranque for adotada ou estiver guardada uma pasta dentro do diretório do Windows, a seleção de pastas sugere a tua pasta de utilizador. Os caminhos introduzidos manualmente continuam a ser verificados como até agora.

As versões do AgentSpine e do Language Guard permanecem inalteradas em relação a 9.1.602. Esta atualização não comprova um ganho de velocidade para sessões em execução.

No Windows continua a ser necessário o Git Bash. Se a consola indicar que falta o Git Bash, instala o Git for Windows. Em seguida, abre novamente a linha de comandos antes de iniciares o king outra vez.

BLUN King · Publicada

BLUN King 9.1.602

Publicada em

Uma pasta privada própria para saídas mais antigas de ferramentas, quando permissões herdadas do Windows impedem o descarregamento.

  • As saídas antigas adequadas de ferramentas são guardadas numa pasta privada própria quando permissões herdadas do Windows impedem o descarregamento. Os ficheiros existentes, as permissões e o histórico completo da sessão permanecem inalterados.
  • As verificações de integridade, os direitos de leitura e o recurso ao contexto completo mantêm-se, caso uma saída arquivada não possa ser recuperada. O AgentSpine 0.73.0 e o Language Guard 6.20.0 estão inalterados em relação a 9.1.601.

Tempos de resposta mais curtos em funcionamento ou um menor consumo faturado de tokens ainda não estão comprovados.

BLUN King · Publicada

BLUN King 9.1.601

Publicada em

As entradas permanecem na fila de espera, as saídas antigas de ferramentas recebem referências verificadas e as verificações de resposta sujeitas a limitação de taxa são repetidas um número limitado de vezes.

  • Quando o trabalho em segundo plano entra primeiro, as entradas de terminal permanecem na fila de espera na sua ordem original. Cada entrada é exibida apenas uma vez.
  • As saídas antigas adequadas de ferramentas são substituídas em pedidos ao modelo por referências verificadas a ficheiros privados. O histórico completo e os resultados do passo atual da conversa mantêm-se. Se o recarregamento não for possível, não for permitido ou o conteúdo tiver sido alterado, a saída completa é enviada juntamente.
  • Uma verificação nativa de resposta sujeita a limitação de taxa é repetida uma vez com o mesmo rascunho de resposta. Vale o prazo de espera guardado do fornecedor. As chamadas de ferramentas já concluídas não são repetidas; os textos não verificados não são aprovados.
  • Até 2 048 tokens de saída permanecem livres como reserva para desvios na estimativa de entrada. A janela de contexto não é reduzida; limites de saída mais baixos definidos expressamente permanecem inalterados.

Estas alterações não comprovam um menor consumo faturado de tokens nem tempos de resposta mais curtos em funcionamento. Também não resolvem todos os erros HTTP-502 do lado do servidor.

BLUN King · Publicada

BLUN King 9.1.600

Publicada em

Verificação de respostas com limites de tempo fixos e estados de componentes definidos.

BLUN King 9.1.600 foi publicado. O npm e o manifesto público de atualizações coincidem. A publicação não comprova nem uma instalação no teu computador nem uma aceitação em funcionamento real.

Verificação de resposta limitada

  • Os verificadores gerais mantêm o prazo anterior de 30 segundos. A verificação nativa do idioma recebe, a partir do sinal de arranque do componente anfitrião de confiança, até 90 segundos para o primeiro texto com conteúdo, uma vez por tentativa externa de verificação.
  • Texto com conteúdo dentro do comprimento de saída permitido, bem como as transições ordenadas para a aprovação e para a verificação do comprovativo, repõem o prazo de espera em 30 segundos.
  • Independentemente disso, cada tentativa externa de verificação tem um limite total de 120 segundos. O progresso não pode prolongar este limite. Mantêm-se no máximo duas tentativas externas de verificação.
  • Antes de aceitar uma aprovação, o tempo efetivamente decorrido é verificado novamente. Mesmo com chamadas de temporizador atrasadas, uma tentativa de verificação expirada permanece bloqueada; progresso atrasado não pode renovar um prazo expirado.

Os sinais de interrupção continuam a ser respeitados. A vinculação ao texto exato da resposta, a validade temporal do comprovativo de aprovação e a autorização continuam a ser verificadas.

Componentes incluídos

A versão 9.1.600 contém o AgentSpine 0.73.0 e o Translate Native 6.155.0. O protocolo do guarda permanece inalterado em 6.20.0.

Limitações conhecidas

Os novos limites de tempo não comprovam uma resolução geral dos erros HTTP-502 em funcionamento real. As observações em aberto de 9.1.599 permanecem em aberto sem um comprovativo de funcionamento real separado.

Contexto e ajuda

Um prompt a conservar integralmente já não é encurtado silenciosamente só para caber numa janela rígida de modelo mais pequena. Com uma nova divisão, expressamente definida, das mensagens de utilizador a conservar e com o orçamento padrão de 20 000 tokens, o ajuste pode ser concluído dentro da mesma compactação. Em prefixos posteriores ou recuperados, não podem ser descartados mais requisitos por causa disso. O pedido tem de continuar a caber na janela rígida de modelo.

As meras chamadas de ajuda com --help ou -h já não geram estado de diagnóstico em tempo de execução. Se forem combinados argumentos de prompt e de ajuda, o comportamento de tempo de execução anterior mantém-se.

BLUN King · 18 de setembro de 2026

BLUN King 9.1.599

Publicada em

Aprovações individuais rastreáveis para a memória pessoal e correções adicionais em caso de excesso de contexto.

Os pedidos de aprovação para a memória pessoal mostram títulos de ação compreensíveis no idioma selecionado e pré-visualizações completas das alterações reais de definições ou do texto a guardar. Os caracteres de controlo são mascarados de forma visível; o conteúdo original permanece inalterado.

As alterações de memória válidas têm de ser aprovadas individualmente; as entradas inválidas só podem ser rejeitadas. Uma aprovação de sessão não autoriza automaticamente pedidos em espera que necessitem de uma aprovação individual.

A verificação do pacote abrange 37 áreas funcionais com 199 verificações obrigatórias, 158 execuções de verificação e 4 905 testes diferentes aprovados. Além disso, as atualizações de 9.1.597 e da versão intermédia local 9.1.598 para 9.1.599 foram verificadas em instalações isoladas com o atualizador e o percurso de instalação inalterados. Ambos os testes reconheceram a versão através das fontes públicas de atualização e verificaram todos os 918 ficheiros do arquivo de lançamento.

As notas em README.md e CHANGELOG.md do pacote inalterado 9.1.599 descrevem o estado de candidato no momento da embalagem. Não foram alteradas retroativamente após a instalação local. Esta página pública regista separadamente o estado de publicação e as limitações observadas posteriormente.

Limitações conhecidas em 9.1.599

Em funcionamento real continuaram a ser observadas respostas HTTP-502 repetidas, por vezes seguidas de pedidos bem-sucedidos. As correções de contexto não são uma resolução geral de erros de fornecedor ou de rede.

A verificação do idioma pode interromper uma resposta com missing-language-character-profile ou suspected-ascii-substitution. Este achado continua em aberto; a 9.1.599 não contém nenhuma correção comprovada para ele.

Uma resposta à imagem enviada foi confirmada pelo utilizador. Ainda estão em falta uma verificação independente da interpretação da imagem e a aceitação visual das entradas e das linhas de estado. As verificações de pacote aprovadas não são uma garantia geral para estes fluxos.

Incorporado a partir da versão intermédia local 9.1.598

Sem data

A 9.1.598 foi verificada e instalada localmente, mas não foi publicada como atualização npm própria. As seguintes alterações estão contidas na 9.1.599:

  • Numa rejeição de contexto, os limites inferiores para o número de tokens de entrada são distinguidos de indicações exatas. Para um limite inferior comunicado, o limite de saída é reduzido uma vez, sem descartar mensagens ou ferramentas. Os sinais de interrupção e a limitação de novas tentativas continuam a valer. Com isto é corrigido de forma dirigida o erro de cálculo do limite de saída reproduzido na 9.1.597.
  • As 150 palavras de atividade alternadas originais voltaram a estar incluídas. Para a sua exibição não são feitos pedidos adicionais ao modelo.
  • No hook de entrada do AgentSpine de confiança é passada, em vez dos dados multimédia completos, uma referência compacta de multimédia com tipo, soma de verificação SHA-256 e indicação de tamanho. Os anexos completos para o modelo e as verificações de proteção existentes mantêm-se. Isso por si só ainda não comprova uma interpretação bem-sucedida de imagens em funcionamento real.

Novidades na 9.1.597

Publicada em

Recuperação limitada em excedências de contexto expressamente comunicadas, mesmo quando encapsuladas numa resposta de erro de gateway.

Se um pedido for recusado antes do início da saída por uma excedência de contexto comprovada, o King pode fazer uma nova tentativa limitada com um limite de saída mais pequeno. Também são reconhecidos erros encapsulados de forma correspondente numa resposta 502. Mensagens, ferramentas, limites de saída mais baixos escolhidos expressamente e sinais de interrupção mantêm-se. Um fluxo já iniciado não é reproduzido novamente.

Isto não resolve todos os erros de fornecedor ou de rede. As interrupções gerais de ligação e as falhas de serviço têm de continuar a ser verificadas com base nos seus próprios dados de erro.

Limitação conhecida na 9.1.597: Se o servidor comunicar apenas um limite inferior para o número de tokens de entrada, a nova tentativa pode voltar a falhar e desencadear compactações desnecessárias. Este caso foi reproduzido em 17 de setembro de 2026 após a publicação. A correção adicional da versão intermédia local 9.1.598 está contida na 9.1.599.

Foram verificadas 36 áreas funcionais com 183 verificações obrigatórias e 4 407 testes diferentes aprovados, bem como a atualização real de 9.1.596 para 9.1.597. Esta verificação de pacote não substitui um teste de aplicação de uma sessão de cliente já aberta.

Novidades na 9.1.596

Publicada em

As interrupções automáticas a favor de mensagens do Telegram em espera são distinguidas de interrupções manuais reais. Uma interrupção de fila de espera deste tipo já não é comunicada erroneamente como acionamento da tecla Escape. O prazo de espera, as regras de proteção para ferramentas em execução e o comportamento numa interrupção manual real mantêm-se.

Novidades na 9.1.595

Publicada em

Os esquemas opcionais de ferramentas são carregados posteriormente através do ToolSearch e conservados de forma limitada. Os catálogos grandes de skills são disponibilizados de forma compacta e por páginas. A pesquisa, as extensões MCP posteriores e as verificações normais de permissões mantêm-se.

Em cumprimentos curtos, o King pode utilizar um excerto limitado do diálogo recente, sem apagar mensagens guardadas ou encurtar instruções do sistema. Para uma tarefa de trabalho posterior, o King volta a ter em conta o histórico de trabalho conservado. O cálculo do contexto mantém-se também depois de retomar uma sessão. Não é prometido um consumo fixo de tokens para cada cumprimento.

Novidades na 9.1.594

Publicada em

  • As respostas privadas do Telegram continuam possíveis enquanto as mensagens de grupo esperam. A atribuição dos comandos de barra mantém-se.
  • Os tempos de espera longos de Retry-After são respeitados; ao retomar uma sessão, a pausa restante é recuperada.
  • Após a descrição de acompanhamento ser descartada, um passo de ferramenta já concluído continua a ser processado. A descrição descartada não é publicada; a verificação da resposta final não é enfraquecida.
  • As funções limitadas de recuperação para a escrita em várias partes voltaram a estar disponíveis. Isto vale também para os limites de tempo de shell, o controlo de tarefas e a recuperação de sessões.
  • A entrada, as linhas de contingente, a indicação de atividade, as tarefas expansíveis e as saídas de ferramentas com identificação da fonte permanecem visíveis durante o streaming e ao navegar no histórico.
  • Antes da embalagem são necessários comprovativos completos de regressão da consola; os metadados públicos de atualização são verificados quanto à concordância.

Versões intermédias 9.1.590 a 9.1.593

Estas versões estão presentes no histórico local de lançamentos, mas em 17 de setembro de 2026 não constam do diretório público de versões do npm. Não são aqui recomendadas como atualizações publicamente disponíveis. Os trabalhos sobre arranque, retoma, permissões, indicação de atividade e entrada visível estão contemplados nos comprovativos da 9.1.594.

Novidades na 9.1.589

Publicada em

  • São incluídas fontes verificadas do AgentSpine e do Translate Native, bem como manifestos de atualização verificados.
  • Ao carregar o contexto do agente, o perfil ativo do King mantém-se.
  • As ferramentas necessárias para a verificação da resposta permanecem disponíveis. O consumo na geração da resposta é registado também quando a verificação rejeita a resposta.
  • Na ligação de canal gerida, as mensagens de grupo só são atribuídas quando há uma menção expressa.
  • A consola mostra a compactação em curso e os limiares em vigor.
  • O orçamento de trabalho para compactação precoce e a reserva de segurança no limite do pedido mantêm-se ao longo das atualizações.
  • O diálogo de atualização no arranque, o progresso e os avisos sobre atualizações agendadas utilizam de forma consistente o idioma selecionado.
  • Os identificadores técnicos de integração e as licenças mantêm-se; as mensagens de erro de tempo de execução visíveis são formuladas de forma neutra.
  • A instalação não reinicia sessões existentes. Uma sessão em execução carrega o novo código no próximo arranque.

9.1.588: retirada

Publicada em

Esta versão foi publicada em 11 de setembro de 2026 e posteriormente marcada como retirada no npm. O registo menciona uma verificação de compatibilidade falhada do manifesto de atualização. Utiliza a versão estável atual, não este pacote retirado.

Novidades na 9.1.587

Publicada em

Catálogos de ferramentas mais estáveis, compactação automática mais precoce e uma nova tentativa dirigida após interrupções por fases de pensamento puro demasiado longas.

Em instruções em buffer dentro de um turno de trabalho em curso, o catálogo ativo de ferramentas mantém-se também no passo de trabalho seguinte. As ferramentas necessárias permanecem disponíveis. Se o orçamento de esquema existente for excedido, as definições opcionais de ferramentas conservadas são selecionadas novamente.

A compactação automática do contexto volta a entrar mais cedo. Após uma compactação bem-sucedida que reduza o histórico, o King pode voltar a executá-la no mesmo turno. Os limites de modelo mais baixos e a limitação de tentativas falhadas continuam a valer.

Após uma interrupção por uma fase de pensamento puro demasiado longa, o King utiliza a nova tentativa única existente com o pensamento desativado, para que o modelo possa responder ou chamar uma ferramenta. Os passos regulares seguintes mantêm a definição de pensamento escolhida; a interrupção, as verificações de aprovação e os limites de tempo continuam a valer.

Com BLUN_STABLE_STEER_TOOLS=0 ou BLUN_EARLY_COMPACTION=0 antes do arranque do King, é possível restaurar o comportamento anterior para a respetiva função. A atualização não reescreve sessões existentes nem ficheiros de configuração.

Novidades na 9.1.586

Publicada em

A receção do Telegram volta a arrancar no Windows quando o antigo ID de processo do bridge entretanto passou a pertencer a outro processo. Em caso de atribuição de processo incerta, o King não intervém; o outro processo não é terminado.

A compactação do contexto, as definições do modelo, o histórico da conversa e o comportamento de entrega anterior do Telegram permanecem inalterados.

Novidades na 9.1.585

Publicada em

BLUN King · 8 de setembro de 2026

A versão 9.1.585 verifica a estrutura e os resultados individuais das respostas geridas do WebSearch também quando faltam as indicações opcionais sobre o estado da pesquisa.

Uma resposta sem uma lista de resultados válida já não é emitida como pesquisa bem-sucedida sem resultados. Cada resultado tem de conter um título que não esteja vazio nem consista apenas em espaços, um excerto de texto como cadeia de caracteres e um endereço HTTP ou HTTPS absoluto sem dados de acesso incorporados. Resultados inválidos fazem com que toda a resposta seja rejeitada antes de serem devolvidos resultados ou avisos sobre resultados de pesquisa incompletos.

As respostas válidas no formato anterior sem indicações de estado continuam a ser suportadas, tal como listas de resultados vazias e cadeias de caracteres vazias como excertos de texto. Em respostas válidas, a ordem, as cadeias exatas dos URLs, as indicações opcionais de data e de site, as referências de origem na saída e o processamento de resultados incompletos permanecem inalterados.

É alterada apenas a ligação de pesquisa gerida. O comportamento de interrupção, a autenticação dos pedidos, o FetchURL e o Telegram permanecem inalterados. A verificação do formato não comprova que uma fonte está correta ou atual. Esta versão não introduz nenhum limite de tamanho para respostas nem um novo limite de tempo.

Novidades na 9.1.584

Publicada em

A versão 9.1.584 faz passar o sinal de interrupção de quem invoca através do WebSearch até ao pedido HTTP de pesquisa gerido, também ao ler o conteúdo da resposta.

As pesquisas já interrompidas não desencadeiam processamento no fornecedor. Se a interrupção ocorrer durante a determinação dos dados de acesso, já não é enviado nenhum pedido de pesquisa depois disso. Os resultados que chegam após a interrupção não são devolvidos como pesquisa bem-sucedida.

As verificações de interrupção abrangem também respostas JSON bem-sucedidas, o conteúdo de respostas de erro e avisos sobre resultados de pesquisa incompletos. O processamento de resultados completos, incompletos e vazios, as referências de origem e o procedimento de recurso regular na autenticação permanecem inalterados.

Esta versão não introduz nenhum novo limite de tempo e não altera a atribuição do Telegram. Os processos partilhados de renovação dos dados de acesso OAuth e as implementações de transporte que ignoram sinais de interrupção não são interrompidos à força. A interrupção de um pedido do cliente não comprova que o trabalho no servidor remoto ou a sua faturação estejam concluídos.

Novidades na 9.1.583

Publicada em

Uma interrupção na obtenção de páginas é agora passada até ao pedido HTTP.

O FetchURL faz passar o sinal de interrupção de quem invoca através da ferramenta e de ambos os serviços de obtenção. Um pedido interrompido antes do arranque não é enviado. Se a interrupção ocorrer durante a determinação dos dados de acesso, o pedido HTTP gerido já não é iniciado depois disso.

Após a interrupção de uma obtenção gerida, já não é iniciada nenhuma obtenção de substituição local. Um resultado atrasado do serviço de obtenção é retido e não é utilizado como comprovativo de origem. Em erros normais de HTTP e de rede, a obtenção de substituição local anterior continua possível.

Não é introduzido nenhum novo limite de tempo. Uma renovação partilhada dos dados de acesso e o processamento síncrono do HTML não são interrompidos à força. O limite de tamanho da 9.1.582 mantém-se; o encaminhamento do Telegram e os pedidos ao modelo permanecem inalterados.

Novidades na 9.1.582

Publicada em

A obtenção local de páginas verifica agora o tamanho da resposta já ao ler e interrompe quando o limite é excedido.

A obtenção local conta os bytes de resposta recebidos antes da descodificação de cada bloco de dados e interrompe o fluxo de dados assim que o limite de tamanho é excedido. Se faltar a indicação Content-Length ou estiver errada, já não é primeiro lida toda a resposta e depois rejeitada.

O limite predefinido mantém-se em 10 MiB e vale para o fluxo de resposta após a descompressão HTTP. Os caracteres UTF-8 distribuídos por vários blocos de dados mantêm-se. Os buffers de transporte e o bloco de dados com que o limite é excedido podem já estar na memória; não está associado a isto um limite superior exato para toda a memória do processo.

É alterado o percurso local de obtenção, também quando serve como solução de recurso. As correções de pesquisa da 9.1.581 permanecem incluídas. O encaminhamento do Telegram e o tempo de espera pelo modelo permanecem inalterados.

Novidades na 9.1.581

Publicada em

Na obtenção local de páginas, os excertos HTML vazios já não são emitidos como fontes bem-sucedidas.

Se depois da limpeza e da conversão não sobrar nenhum conteúdo de página, o título do documento por si só já não basta para uma obtenção bem-sucedida. Em vez disso, é devolvido o erro de extração já existente.

Os conteúdos reais curtos e os títulos visíveis mantêm-se. As respostas em formato de texto simples ou Markdown permanecem inalteradas. A correção diz respeito à extração local de HTML, não ao serviço de obtenção gerido.

As correções de pesquisa da 9.1.580 e as correções anteriores do Telegram permanecem incluídas inalteradas. Esta atualização não altera nem o tempo de espera pelo modelo nem a atribuição das mensagens recebidas aos seus destinatários.

Novidades na 9.1.580

Publicada em

O arquivo de pesquisa rejeita datas históricas inválidas atribuídas a fontes.

Um novo relatório não é guardado se uma data atribuída a uma fonte contiver um dia de calendário inválido ou uma parte de tempo não avaliável. As datas em falta permanecem permitidas.

Ao recuperar comprovativos de pesquisa guardados, os comprovativos mais antigos com datas inválidas atribuídas a fontes são ignorados e comunicados com um aviso de diagnóstico. Os ficheiros não são reescritos nem apagados. Os comprovativos válidos separados permanecem pesquisáveis; as datas válidas mantêm o seu desvio de fuso horário e a sua precisão.

A ordenação dos comprovativos de pesquisa da 9.1.579 e as correções anteriores do Telegram permanecem incluídas inalteradas. Esta atualização não altera nem o tempo de espera pelo modelo nem a atribuição das mensagens recebidas aos seus destinatários.

Novidades na 9.1.579

Publicada em

Os comprovativos de pesquisa guardados são ordenados, com relevância igual, pelo momento real da sua recuperação.

As indicações de tempo com e sem milissegundos são comparadas como momentos UTC, não como texto. A relevância continua a ter prioridade; em momentos idênticos, a ordem anterior mantém-se.

Se a mesma passagem de texto foi registada várias vezes, o resultado mantém as indicações de origem da recuperação mais recente. Os comprovativos já guardados permanecem inalterados e, por isso, não valem como fontes verificadas de novo.

A correção para respostas do Telegram da 9.1.578 permanece incluída inalterada. O mesmo vale para a limitação de novas tentativas quando o modelo apenas pensa, sem fornecer uma resposta ou uma chamada de ferramenta. Esta atualização não altera nem o tempo de espera pelo modelo nem a atribuição semântica das mensagens recebidas.

Novidades na 9.1.578

Publicada em

Tentativas limitadas quando o modelo apenas pensa e atinge o limite de tempo, bem como uma correção dirigida para respostas curtas em grupos do Telegram com referência a uma pergunta.

Se o modelo atingir o limite de tempo enquanto apenas pensa, o King permite mais uma tentativa por passo. Um segundo esgotamento de tempo deste tipo termina o passo. O esforço de pensamento escolhido e o limite de tempo anterior permanecem inalterados. Esta limitação não encurta a espera pela primeira saída do modelo.

As confirmações curtas da própria presença em grupos do Telegram podem agora ser enviadas quando reply_to as liga a uma entrada com no máximo 30 minutos do mesmo chat. Essa entrada tem de se dirigir expressamente ao agente ou corresponder a uma pergunta suportada em alemão ou inglês sobre a sua presença, que comece com o seu nome definido. As confirmações de presença não solicitadas e as explicações de que não há nada a comunicar continuam a ser filtradas. O envio de substituição automático em grupos permanece desativado.

Os registos das respostas enviadas e suprimidas contêm agora reply_to. Se faltar o contexto ou este for ambíguo, a exceção não se aplica. Esta atualização não acrescenta nenhum reconhecimento geral de destinatários e não impede chamadas desnecessárias ao modelo pela endereçação semântica anterior.

A correção aplica-se a duas versões exatamente identificadas dos remetentes MCP geridos do Telegram e atua também na fusão final da configuração de plugins. O remetente mais antigo utiliza uma cópia de compatibilidade com alterações estritamente limitadas. Os bridges de entrada, as definições de acesso, os perfis e os registos de plugins não são reescritos. Os remetentes desconhecidos ou adaptados, bem como as substituições definidas expressamente, mantêm-se. O King tem de ser reiniciado após a atualização para que a correção seja carregada.

Novidades na 9.1.577

Publicada em

Sem mais mensagens de conclusão automáticas em grupos do Telegram. As respostas úteis são enviadas lá de forma dirigida através da ferramenta de resposta do Telegram.

O núcleo CLI e o bridge autónomo do Telegram já não reencaminham automaticamente o texto de conclusão normal de um agente para grupos. Deste modo, avisos como «Nada a comunicar» já não chegam ao grupo através deste envio de substituição automático.

As respostas em chats privados, as ferramentas de resposta utilizadas expressamente, os resultados de objetivo exigidos, as mensagens de comando e de estado, bem como o envio de multimédia mantêm-se. As instruções de prompt para entradas normais, mensagens de controlo durante um processo em curso e mensagens de grupo do bridge autónomo contêm agora a mesma regra de envio.

Isto não garante que um modelo nunca envie uma resposta desnecessária através de uma chamada de ferramenta. A correção também não impede que mensagens de grupo sem relação com o respetivo agente cheguem ao modelo. As regras de menção, as definições de acesso e a resolução de plugins geridos permanecem inalteradas; não está incluída nenhuma atualização do AgentSpine nem do guarda de idiomas.

O núcleo atualizado tem de ser carregado por um processo novo. As sessões em execução não são reiniciadas automaticamente. Os perfis existentes e o histórico da sessão mantêm-se.

Novidades na 9.1.576

Publicada em

O BLUN King 9.1.576 distingue C++ e C# em consultas de pesquisa locais e contém as correções anteriormente publicadas para atualizações, retoma de sessões e Telegram.

A pesquisa em comprovativos de pesquisa locais trata C++ e C# isolados como termos distintos, também com maiúsculas e minúsculas divergentes e com pontuação envolvente. As passagens de texto guardadas, os hashes, as verificações de proteção para fontes, a normalização Unicode, os limites das coleções e os limites de saída permanecem inalterados. Não é necessário reindexar.

Uma execução de verificação definida com 20 consultas de pesquisa técnicas e testes de regressão dirigidos para limites de tokens verificam esta correção. Diz respeito à pesquisa local e não é uma afirmação sobre a qualidade ou capacidade do WebSearch em funcionamento real. Todas as alterações da 9.1.575 permanecem incluídas.

Novidades na 9.1.575

Publicada em

O crawler web incluído rejeita respostas com cf-mitigated: challenge antes de ler conteúdos, seguir reencaminhamentos ou interpretar um ficheiro robots em falta como permissão para continuar. Nos nomes de cabeçalhos não distingue maiúsculas de minúsculas; além disso, verifica valores normalizados e cabeçalhos que ocorrem várias vezes. O estado da resposta mantém-se no relatório de erro.

Os ficheiros robots em falta sem esta marcação e as páginas de documentação normais continuam a passar pelo processo existente. As páginas já concluídas permanecem disponíveis se uma página posterior for rejeitada; o erro é comunicado como resultado incompleto. Esta proteção verifica uma marcação de resposta. Não é um reconhecimento geral de desafios nem uma evasão de CAPTCHA. Os fornecedores de pesquisa, a autenticação, os bloqueios de atualização e o núcleo CLI permanecem inalterados. Todas as alterações da 9.1.574 permanecem incluídas.

Novidades na 9.1.574

Publicada em

As atualizações expressamente solicitadas distinguem agora entre uma atualização bloqueada, uma verificação de bloqueio indisponível, um diretório privado indisponível, uma versão instalada inválida e um instalador protegido indisponível. Estes casos já não são comunicados genericamente como verificação de pacote falhada. A alteração vale para mensagens em alemão e em inglês.

A autorização de atualização, o comportamento de bloqueio, os motivos de devolução, os códigos de saída e o comportamento do instalador permanecem inalterados. As sessões em execução não são terminadas automaticamente. Os pacotes fixados num canal interno antigo continuam a exigir uma instalação npm expressa com o King terminado; esta versão não anula essa fixação. Todas as alterações da 9.1.573 permanecem incluídas.

Novidades na 9.1.573

Publicada em

O campo de entrada permanece visível e focado após a seleção do objetivo no arranque, também após Escape ou uma retoma de objetivo falhada. Os rascunhos não enviados mantêm-se. Em vez do texto completo do objetivo, aparece uma seleção compacta para continuar com ou sem objetivo.

Ctrl+S sai da seleção sem confirmar o objetivo e é processado como atalho regular para a fila de espera. Também são tidas em conta as entradas pendentes em modo de espera. Escape mantém a sua ordem anterior: primeiro esvaziar a fila de espera, no Escape seguinte interromper a execução ativa. O histórico da sessão não é apagado automaticamente.

Esta versão não reconstrói confirmações de entrega que um processo mais antigo perdeu antes da atualização. As mensagens efetivamente pendentes continuam atribuídas à sua sessão.

Novidades na 9.1.572

Publicada em

Nos comprovativos de pesquisa, são rejeitados URLs de fontes cujos parâmetros de consulta ou fragmentos em forma de parâmetro contenham nomes de parâmetros conhecidos para dados de acesso. Também são verificados nomes aninhados e rotas no fragmento. A rejeição vale tanto para fontes falhadas como para fontes utilizáveis.

Os relatórios já guardados com esses URLs são retidos na recuperação com o resultado existente partial / report-invalid. Os estados originalmente guardados não são alterados nem apagados; os endereços de fontes não são encurtados nem reescritos silenciosamente. Os parâmetros de consulta normais e as âncoras em URLs de documentação mantêm-se byte a byte. A proteção reconhece nomes de parâmetros conhecidos, não segredos arbitrários, e não limpa nenhum histórico.

Novidades na 9.1.571

Publicada em

Os âmbitos da fila de espera do Telegram são atribuídos à sua sessão. Uma sessão nova já não assume automaticamente o trabalho pendente de uma sessão mais antiga. Ao retomar uma sessão conhecida, só são recuperados os seus próprios âmbitos em espera. Durante a seleção, criação e mudança de sessão, a receção de mensagens do canal fica em pausa. As mensagens que entram após o limite escolhido, as entradas seguintes no editor local e as confirmações de entrega atrasadas mantêm a sua atribuição correta.

A atribuição e as confirmações de entrega que chegam fora de ordem mantêm-se numa religação e entrega de lease. O estado da fila de espera danificado ou substituído é rejeitado, em vez de reproduzir silenciosamente entradas antigas. A caixa de entrada e o histórico da sessão mantêm-se. Os âmbitos antigos em espera sem sessão reconhecível são adiados e não são atribuídos a nenhuma sessão nova; a sua recuperação automática não está incluída. Isto não resolve todos os esgotamentos de tempo nem bloqueios de compactação do contexto. Um downgrade não é um procedimento de migração da fila de espera.

O plugin Telegram e a função de recurso independente da consola para o envio automático de respostas suprimem confirmações de receção reconhecidas e textos que apenas anunciam o próprio silêncio, também acima de 200 caracteres. Se uma mensagem contiver uma parte de frase não reconhecida ou relevante no conteúdo, mantém-se. Os avisos curtos e úteis de grupo podem continuar a ser entregues. Isto é um filtro de envio alemão-inglês cauteloso com instruções complementares, não uma garantia de que cada modelo compreende cada conversa de grupo.

Um processo novo tem de carregar o pacote atualizado; as sessões em execução não são reiniciadas. As fixações existentes em canais de atualização internos e os bloqueios de instalação do Windows com EBUSY permanecem problemas separados. Todas as restantes alterações da 9.1.570 permanecem incluídas. Esta versão não ativa pesquisa web alojada e não altera nem o AgentSpine nem a faturação, a autenticação ou a configuração do cliente.

Novidades na 9.1.570

Publicada em

Cada nova entrega de prompt recebe um ID próprio de correlação de hook. Os hooks da mesma entrega mantêm o mesmo ID; os IDs definidos expressamente mantêm-se. Os valores de ambiente específicos da sessão chegam aos subprocessos de hook e às ligações MCP também ao religar, sem reescrever configurações de plugins guardadas. A atribuição dos resultados nativos de ferramentas mantém-se ao longo das execuções, também em ferramentas falhadas e chamadas duplicadas.

As consultas de pesquisa Unicode canonicamente equivalentes encontram os mesmos resultados, sem equiparar caracteres diferentes. As fontes guardadas, as datas, as versões e os limites de projeto mantêm-se. king --help e king --version já não alteram definições de registo do Windows para imagens de falha.

A pesquisa web suporta respostas parciais quando este modo de resposta foi acordado e mostra nesse caso um aviso sobre fontes falhadas. As respostas parciais vazias ou incompatíveis continuam a ser erros expressos. Esta alteração no cliente não ativa nenhum serviço de pesquisa alojado nem garante o seu funcionamento.

O transporte BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE está desativado por predefinição. Com ativação expressa, entrega o caminho real do registo de sessão guardado e o respetivo registo ao plugin AgentSpine selecionado. Cada sessão recebe uma permissão de acesso própria, renovada após uma retoma. Isto é suporte de transporte, não uma prova de recuperação de memória ou de autorização pelo plugin recetor.

Todas as alterações públicas da 9.1.569 permanecem incluídas. A implementação incluída do AgentSpine permanece inalterada; não surge nenhuma dependência Mnemo. Os perfis de utilizador, as permissões, as conversas e as definições de plugins não são migrados nem repostos.

Novidades na 9.1.569

Publicada em

Esta versão pública cumulativa contém a entrega em grupos do Telegram com base em menções, correções para arranque e permissões, bem como coleções de pesquisa e ferramentas de crawler. Os pacotes publicados permanecem inalterados. As alterações posteriores aparecem sob um novo número de versão.

Novidades na 9.1.566

Publicada em

O BLUN King 9.1.566 torna as atualizações de plugins e o carregamento de módulos de runtime nativos mais robustos.

O runtime incluído do AgentSpine é atualizado para a versão 0.59.1. O seu autoiniciador ignora a raiz de um perfil de utilizador como alvo de verificação, e todos os hooks de ciclo de vida permanecem à prova de falhas quando um caminho protegido não pode ser lido.

Os módulos nativos .node são resolvidos através de uma cache endereçada por conteúdo fora do pacote npm. Assim que esta versão estiver ativa, uma consola em execução já não mantém aberta a cópia do pacote destes módulos. As atualizações posteriores podem substituir o diretório do pacote sem colidir com estes ficheiros nativos.

O pacote público mantém os catálogos completos de interface em espanhol, francês, sueco e checo da versão 9.1.565. Os caminhos internos do runtime Mnemo, os endpoints privados, os fornecedores de modelos internos e os scripts de construção não estão incluídos.

Estado do pacote verificado

O pacote do cliente passou a verificação de fugas, a verificação completa de runtime com 13 testes, a inicialização MCP do AgentSpine, uma instalação limpa e a atualização de 9.1.565. Todos os ficheiros de texto utilizam fins de linha LF. SHA-256 do pacote npm: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Novidades na 9.1.565

Publicada em

O BLUN King 9.1.565 estabiliza execuções de trabalho longas e alarga o runtime incluído do AgentSpine.

O travão de repetição repõe a sua sequência de resultados equivalentes assim que, entretanto, avança trabalho real. As verificações normais da caixa de entrada e das listas de tarefas já não desencadeiam por isso uma resposta forçada falsa.

A indicação de atividade consiste em exatamente uma linha. Mostra a palavra de estado em inglês adequada à atividade atual, os tokens do pensamento oculto, os tokens visíveis, o consumo total, o esforço, a tentativa, o orçamento e o passo.

Os erros de verificação do AgentSpine permanecem à prova de falhas em ferramentas de mutação, entradas de utilizador e stop hooks: o processo seguinte pode continuar e o erro é registado no registo de auditoria. Antes de uma interrupção fatal por uma exceção ou uma rejeição não tratada, a consola escreve o registo de runtime de forma síncrona.

O runtime incluído do AgentSpine é atualizado para a versão 0.54.0 do commit fb6d456b68605fd83721090e503f000a26e8a0fb. O estado contém o teste real de ACL fail-open, planos de objetivos persistentes vinculados a dependências e a resolução vinculada de lacunas de conhecimento.

Os hooks de ciclo de vida SessionStart, UserPromptSubmit, PostToolUse e Stop são enviados ao Mnemo com a identidade exata MNEMO_AGENT. Os erros de rede permanecem à prova de falhas.

Os textos de interface anteriormente em falta estão agora completos em espanhol, francês, sueco e checo.

Estado do pacote verificado

O controlo completo do pacote, a verificação de fugas, a verificação do catálogo de idiomas, a execução de teste do hook de ACL, a instalação limpa, a atualização de 9.1.564 e a inicialização MCP do AgentSpine estão verdes. SHA-256 do pacote npm: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Novidades na 9.1.564

Publicada em

O BLUN King 9.1.564 evita falhas causadas por pastas protegidas e textos de interface em falta.

O AgentSpine ignora, na verificação preparatória de ficheiros, ficheiros e pastas individuais que o sistema operativo bloqueia com EPERM ou EACCES. Um erro de verificação inesperado já não bloqueia a chamada de ferramenta seguinte; a chamada é autorizada e o erro é registado no registo de auditoria.

Se faltar uma chave de texto numa língua de interface publicada, a consola utiliza o texto em inglês e regista a lacuna uma única vez, em vez de falhar no caminho de renderização. Deste modo, a linha de estado do pensamento mantém-se utilizável em particular em checo, espanhol, francês e sueco.

As traduções efetivas das chaves ainda em falta seguem numa versão verificada separadamente. Até lá, o recurso ao inglês é deliberadamente visível e à prova de falhas.

Estado do pacote verificado

O pacote foi verificado contra a falha exata thinking.step em checo da 9.1.563. A nova versão fornece «step 6» em vez de uma exceção, avisa apenas uma vez por língua e chave, sobrevive a pastas vizinhas inacessíveis, inicializa o AgentSpine 0.49.0, passa numa instalação limpa e na atualização de 9.1.563 e não contém imports de plugins não resolvidos. SHA-256 do pacote npm: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Novidades na 9.1.563

Publicada em

O BLUN King 9.1.563 atualiza o runtime incluído do AgentSpine para a versão 0.49.0.

O novo estado exige, antes de uma tentativa de aprendizagem, pelo menos um comprovativo recente e independente de uma confirmação expressa do utilizador ou de um teste objetivo. Os meros comprovativos de conversa ou de documentos já não bastam, mesmo que os seus restantes limiares estejam cumpridos.

Os contratos de aprendizagem vinculam esta regra de comprovativo de forma persistente; alterações posteriores de configuração não podem enfraquecer uma verificação em curso. Os bloqueios de ficheiros vinculados à propriedade protegem alterações de aprendizagem paralelas contra sobrescrita e fazem com que os bloqueios manipulados ou de terceiros falhem de forma bloqueada (fail-closed).

A atualização substitui a árvore de plugins gerida no próximo arranque, endereçada por conteúdo. As instalações existentes da versão 9.1.562 são atualizadas para o AgentSpine 0.49.0, uma árvore inalterada é reutilizada e o servidor MCP do AgentSpine confirma a versão 0.49.0.

Estado do pacote verificado

O limite do pacote difere da 9.1.562 apenas pelas indicações de versão e pelo runtime exatamente fixado do AgentSpine 0.49.0. A verificação completa a montante, 49 testes de aprendizagem dirigidos, a comparação de pacotes, a verificação de fugas, a instalação limpa, o percurso real de atualização de 9.1.562 e uma inicialização MCP estão verdes. SHA-256 do pacote npm: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Novidades na 9.1.562

Publicada em

O BLUN King 9.1.562 repõe o ficheiro de runtime do AgentSpine no pacote público.

O ficheiro de runtime de que o servidor MCP incluído do AgentSpine necessita volta a ser incluído. Uma instalação limpa materializa o plugin completamente; o servidor MCP arranca e confirma o seu nome e a sua versão de protocolo.

Estado do pacote verificado

O limite do pacote difere da 9.1.561 apenas pelos metadados de versão e pelo ficheiro de runtime restaurado. A verificação de fugas, a instalação limpa, a materialização do plugin e uma inicialização MCP real estão verdes. SHA-256 do pacote npm: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Novidades na 9.1.561

Publicada em

O BLUN King 9.1.561 adota as melhorias verificadas do sistema de trabalho no pacote público.

A tarefa atual e os resultados recentes de ferramentas permanecem disponíveis. Os resultados de leitura não são truncados. Os resultados grandes são guardados com uma referência para recuperação novamente, em vez de serem esvaziados. Os resultados idênticos repetidos remetem para o resultado completo mais recente.

As compactações são registadas como transação com marcação de início, resumo e fim. As chamadas de ferramentas e os seus resultados permanecem juntos, enquanto os pontos de verificação persistentes asseguram o percurso de recuperação ao longo de novas tentativas.

Os orçamentos de saída provêm agora do perfil de modelo ativo. O modelo BLUN gerido recebe por predefinição 128 000 tokens de saída quando nenhum valor é definido expressamente. Os antigos limites fixos de 32 768 tokens, bem como os limites baixos para low e off, já não truncam o trabalho complexo; a capacidade do contexto permanece o limite de segurança.

O atualizador pergunta antes de preparar ou iniciar o instalador. No pacote público, o modelo BLUN gerido permanece fixo; /model serve apenas como alias de compatibilidade para /effort.

O limite do pacote foi verificado em todos os nomes de ficheiros e conteúdos legíveis. Os percursos internos de fornecedores, a escolha do modelo, os scripts de construção e de regressão, os identificadores privados e os endereços de servidores privados não estão incluídos.

Estado do pacote verificado

O pacote completo, a verificação de fugas, a instalação limpa, a saída de versão e de ajuda, as definições padrão de um novo perfil, bem como a decisão de atualização de 9.1.550 para 9.1.561 estão verdes. SHA-256 do pacote npm: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Novidades na 9.1.527

Publicada em

O BLUN King 9.1.527 adota o fluxo /copy do DeepAgents.

O comando copia a resposta de assistente concluída mais recente e não vazia através do percurso multiplataforma existente da área de transferência.

Se /copy for introduzido durante um turno em curso, o comando utiliza a fila de comandos existente e é executado após a conclusão da resposta.

Mensagens de estado claras cobrem o sucesso, um histórico vazio e erros da área de transferência em todas as seis línguas de interface.

Uma regressão de vermelho para verde protege o registo de comandos, a execução, a seleção da resposta, o conteúdo byte a byte da área de transferência e os textos de interface aprovados.

Estado do pacote verificado

O prepack completo e a verificação do artefacto descompactado estão verdes. SHA-256 do pacote npm: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Novidades na 9.1.526

Publicada em

O BLUN King 9.1.526 materializa a versão do AgentSpine incluída no pacote atual antes de /reload reconstruir o catálogo de plugins e a configuração MCP.

As entradas de plugins não afetadas mantêm-se. Uma árvore gerida inalterada do AgentSpine é reutilizada, sem reescrever installed.json.

Uma regressão de vermelho para verde contra 9.1.525 protege a ordem de arranque, a adoção do plugin gerido e o comportamento idempotente ao recarregar.

Estado do pacote verificado

O prepack completo, a verificação do artefacto empacotado e o teste isolado de atualização de 9.1.525 para 9.1.526 estão verdes. SHA-256 do pacote npm: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Novidades na 9.1.525

Publicada em

O BLUN King 9.1.525 inicia cada comando de shell local no Windows e POSIX num grupo de processos próprio. Os programas já não podem ligar-se à consola de controlo da TUI BLUN e intercetar Escape, Strg+S ou outras entradas do editor.

A entrada padrão, a saída padrão e a saída de erro permanecem em pipes privados. Os comandos interativos recebem um fim de ficheiro e falham ou excedem o tempo limite, sem competir com o editor por entradas.

O isolamento de shell local do DeepAgents foi adotado para o Windows. Um teste de regressão executável cobre ambos os percursos de plataforma e uma execução de teste real com um processo intercetado.

Novidades na 9.1.524

Sem data

O BLUN King 9.1.524 mantém a tarefa imediata gerada por um comando /loop do Telegram no percurso de entrega protegido para comandos remotos. Deste modo, não pode sobrar como segundo registo normal da fila de espera.

A lista de retoma mostra, para cada sessão, o tamanho do ponto de verificação de retoma, as mensagens e tokens conservados, o tamanho do histórico da sessão, bem como os pontos de verificação em falta, inválidos ou desatualizados.

O runtime incluído do AgentSpine é atualizado para o estado oficial verificado 0.11.4 com o commit 8034487cdd24498076bac48d3f24400bca5e6ae4. O orçamento de tempo BLUN de 180 segundos para a conclusão em segundo plano do SessionStart mantém-se.

Testes de regressão executáveis protegem a entrega exatamente uma única vez dos loops do Telegram e todos os estados dos valores medidos de retoma. O comportamento local existente da fila de espera com um loop ocupado permanece inalterado.

Novidades na 9.1.523

Publicada em

O BLUN King 9.1.523 faz com que Escape feche um menu de comandos de barra aberto e limpe o rascunho correspondente num passo, em vez de deixar o texto do comando para trás.

Strg+S entrega um rascunho de barra ao percurso existente de colocação em fila e processamento também quando a interface indica que está inativa, em vez de voltar silenciosamente antes de esvaziar a fila de espera.

Os rascunhos normais mantêm-se quando Escape apenas fecha outra autocompleção.

Testes de tempo de execução de vermelho para verde protegem ambos os atalhos contra o comportamento exato do pacote 9.1.522.

Novidades na 9.1.522

Sem data

O BLUN King 9.1.522 escreve permission.approval_requested imediatamente no histórico da sessão ao abrir uma aprovação de ferramenta. Um King sem supervisão já não parece um modelo mudo ou um fornecedor bloqueado enquanto espera pelo operador.

Os botões de aprovação do Telegram existentes são utilizados automaticamente quando a lista de autorização contém exatamente um chat privado e qualquer número de grupos. Com vários destinatários privados possíveis, o envio permanece bloqueado enquanto BLUN_TELEGRAM_APPROVAL_CHAT_ID não estiver definido.

Uma regressão de vermelho para verde protege a visibilidade imediata no histórico da sessão, o reencaminhamento inequívoco para um chat privado, a prioridade de um destino definido expressamente e a rejeição de destinatários ambíguos em ambas as cópias do relé incluídas.

Novidades na 9.1.521

Sem data

O BLUN King 9.1.521 executa a verificação SessionStart do AgentSpine fora do percurso de arranque interativo. Uma verificação a frio do diretório do utilizador, que demora 123,6 segundos, já não bloqueia nem o editor nem a primeira entrada do utilizador.

As saídas bem-sucedidas do SessionStart permanecem automáticas: após a conclusão, o hook em segundo plano continua a incorporar o seu briefing limitado no contexto da sessão.

O orçamento de tempo para verificações a frio sobe para 180 segundos. Um teste de tempo de execução de vermelho para verde comprova que o arranque regressa antes de um hook lento e que o hook pode continuar a correr depois.

Novidades na 9.1.520

Publicada em

O BLUN King 9.1.520 concede ao hook SessionStart do AgentSpine tempo suficiente no recarregamento para concluir uma verificação completa a frio do projeto.

O limite de tempo para o arranque do AgentSpine sobe de 15 para 60 segundos. Todos os outros limites de tempo de hooks permanecem inalterados.

Uma nova verificação de tempo de execução de vermelho para verde inicia o hook real do AgentSpine num projeto temporário e verifica tanto a sua saída como os dois manifestos de timeout incluídos.

Estado do pacote verificado

A versão 9.1.520 contém o AgentSpine 0.10.1. O teste isolado de atualização de 9.1.519 para 9.1.520 e o prepack completo estão verdes. SHA-256 do pacote npm: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Novidades na 9.1.519

Publicada em

O BLUN King 9.1.519 guarda as saídas bem-sucedidas do hook SessionStart antes de o arranque ou o recarregamento regressar. Deste modo, a prontidão do AgentSpine atinge automaticamente o contexto de modelo continuado e já não espera pela primeira mensagem do utilizador.

As referências históricas a resultados de ferramentas descarregados mantêm uma pré-visualização limitada do início e do fim. As âncoras importantes para a retoma mantêm-se assim, sem voltar a incluir o resultado completo em cada pedido ao modelo.

Novas verificações de tempo de execução de vermelho para verde protegem a transferência do contexto SessionStart e as pré-visualizações históricas. O catálogo de ferramentas para a manutenção de Todo restaurado com a 9.1.518 permanece inalterado.

Novidades na 9.1.518

Publicada em

Durante a manutenção proativa das listas de tarefas, Read, Write, Edit e Bash permanecem disponíveis ao lado de TodoList. O percurso normal de recuperação para grandes alterações de ficheiros já não é interrompido por isso.

A manutenção automática do Todo e o seu prompt de comprovativo limitado mantêm-se, sem mudar o passo de modelo ativo para um catálogo de ferramentas exclusivamente TodoList.

Um controlo de regressão de vermelho para verde protege contra a recaída do catálogo da 9.1.499 e verifica a seleção das ferramentas de recuperação sem esquemas duplicados.

Novidades na 9.1.517

Publicada em

Strg+S e Escape permanecem disponíveis também com a solicitação de aprovação aberta. Strg+S envia todas as mensagens em espera; Escape liberta primeiro uma mensagem em espera e só rejeita a aprovação quando a fila de espera estiver vazia.

A terminação assíncrona da sessão é totalmente observada nos percursos de teclado, Telegram-/reload e comandos de barra. session.not_found vale como sessão já terminada, em vez de fazer o núcleo falhar com uma rejeição não tratada.

Verificações de pacote de vermelho para verde protegem os caracteres de controlo brutos do Windows e o erro medido ao terminar uma sessão que já não existe.

Novidades na 9.1.516

Publicada em

Se, no histórico guardado após a compactação, faltar o início de um passo de assistente, a reprodução reconstrói-o a partir do evento de conteúdo ou de ferramenta seguinte. king -c já não termina com o erro interno Received content_part for unknown step_uuid 'undefined'.

Uma mensagem do Telegram sai da fila de espera exatamente uma única vez, assim que o núcleo tiver aceitado de forma persistente a sua transferência ativa. As rejeições reais mantêm-se para uma nova tentativa. Um bridge do Telegram gerido pelo King, terminado inesperadamente, é reiniciado por exatamente um vigilante unificado.

Por passo de modelo, só é aceite a primeira alteração da TodoList. Os pontos concluídos desaparecem automaticamente, as marcações pendentes permanecem visíveis também em terminais ANSI16 e uma lista nova começa com exatamente um ponto em execução. A ordem fixa é: urgente, mensagem direta do utilizador, mensagem de bot endereçada, mensagem de bot, mensagem normal.

O primeiro passo com capacidade de ferramentas espera no máximo 2,5 segundos pelo catálogo MCP inicial; os servidores opcionais podem continuar a arrancar em segundo plano. No arranque do programa, só o perfil ativo é verificado e instalado.

Estado do pacote verificado

A versão 9.1.516 contém o AgentSpine 0.10.1. Os oito controlos de regressão de prepack, o node --check, a verificação de metadados do pacote e uma verificação limpa do pacote estão verdes. O mesmo pacote npm contém os componentes de plataforma para Windows, Linux e macOS. SHA-256 do pacote npm: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Novidades na 9.1.515

Publicada em

Uma lista de tarefas genuinamente inalterada volta a ser aceite após trabalho prolongado comprovado. O King não tem de inventar progresso nem reformular apenas um título para poder continuar o seu trabalho real.

Também um loop em modo de espera pode retomar uma TodoList ainda aberta, sem manter o agente de forma persistente num turno de manutenção apenas com a ferramenta Todo. Um controlo de regressão de prepack protege ambos os percursos de erro.

Estado do pacote verificado

A versão 9.1.515 contém o AgentSpine 0.10.1. A verificação de regressão dirigida do loop de Todo, o node --check, a verificação de metadados de lançamento e uma instalação limpa do pacote estão verdes. O mesmo pacote npm contém os componentes de plataforma para Windows, Linux e macOS. SHA-256 do pacote npm: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Novidades na 9.1.514

Publicada em

O BLUN King 9.1.514 reforça o diário de entrega do Telegram sem conteúdo contra envelopes de fila manipulados.

Os identificadores de mensagens só são aceites como números decimais positivos. Os hashes de chat já calculados são permitidos exclusivamente como valores hexadecimais de exatamente doze dígitos em minúsculas. Os valores defeituosos ou semelhantes a conteúdo são descartados, em vez de serem registados.

O processamento existente do Telegram, as fases de entrega, a rotação do diário e o diagnóstico de quarentena sem conteúdo permanecem inalterados. Todos os 133 testes de pacote, bem como execuções de teste de pacote limpas para Windows x64, Linux x64, macOS ARM64 e macOS x64, estão verdes.

Estado do pacote verificado

A versão 9.1.514 contém o AgentSpine 0.10.1 e o ReadBatch. SHA-256 do pacote npm: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Novidades na 9.1.513

Publicada em

O BLUN King 9.1.513 regista o percurso de entrega do Telegram desde a entrada no bridge, passando por encaminhamento, fila e injeção, até à confirmação, recuperação ou quarentena.

O diário limitado guarda exclusivamente identificadores sem conteúdo, hashes, fases de entrega, contadores e motivos de erro limpos. Os textos de mensagens, prompts, caminhos, nomes de utilizador, tokens, dados de acesso e mensagens de erro brutas não são registados.

Também o diagnóstico de quarentena já não duplica mensagens do Telegram, textos de exibição, indicações de origem, IDs brutos de chat ou caminhos de imagens. Todos os 132 testes de pacote, bem como execuções de teste de pacote limpas para Windows x64, Linux x64, macOS ARM64 e macOS x64, estão verdes.

Estado do pacote verificado

A versão 9.1.513 contém o AgentSpine 0.10.1 e o ReadBatch. SHA-256 do pacote npm: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Novidades na 9.1.512

Publicada em

O BLUN King 9.1.512 impõe, na manutenção proativa da TodoList, uma atualização alterada e comprovada, em vez de voltar a aceitar indefinidamente a mesma lista. O turno de manutenção isolado recebe no máximo oito indicações compactas sobre o nome da ferramenta e o resultado desde a última atualização aceite.

Os prompts, argumentos, comandos, caminhos completos, resultados de ferramentas ou o histórico de trabalho não são reproduzidos nesse processo. Uma tentativa falhada da TodoList conserva esse comprovativo limitado para a tentativa seguinte; uma atualização bem-sucedida remove as indicações utilizadas. Os pontos concluídos continuam a desaparecer automaticamente e, no passo seguinte, voltam a estar disponíveis as ferramentas de trabalho normais.

Estado do pacote verificado

A 9.1.512 passa em 127 de 127 testes de pacote. As instalações limpas escolhem no Windows x64, Linux x64, macOS ARM64 e macOS x64 os componentes de plataforma esperados e contêm o AgentSpine 0.10.1 e o ReadBatch. SHA-256 do pacote npm: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Novidades na 9.1.511

Publicada em

O BLUN King 9.1.511 disponibiliza o AgentSpine 0.10.1 como nova versão de plugin central endereçada por conteúdo. O preflight obrigatório continua a verificar cada ficheiro ativo de instruções do anfitrião de forma segura contra condições de corrida e vincula a sua identidade ao turno exato, mas já não duplica o texto completo já carregado pelo anfitrião no contexto de runtime.

O estado acrescenta comprovativos obrigatórios pré-resposta, entradas must-remember confirmadas e a sincronização autocurativa do grafo de persona e de relações autenticado. Os grupos, pessoas e associações em falta são reparados numa nova comparação do roster; as consultas locais de relações terminam visivelmente após 5 segundos em caso de bloqueio.

A consulta limitada Telegram-Mnemo mantém-se: as mensagens anteriores só são carregadas quando há necessidade concreta, com referência estreita a agente, pessoa, grupo, tema, tópico e tempo. Um histórico completo do Telegram não entra rotineiramente no prompt.

Estado do pacote verificado

A 9.1.511 passa em 126 de 126 testes de pacote. O verdadeiro ficheiro CLAUDE.md de 15 519 bytes foi verificado integralmente, enquanto todo o contexto injetado abrangia 5 667 bytes e não continha nenhum texto completo de instruções. As instalações limpas escolhem no Windows x64, Linux x64, macOS ARM64 e macOS x64 os componentes de plataforma esperados e contêm o AgentSpine 0.10.1 e o ReadBatch. SHA-256 do pacote npm: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Novidades na 9.1.510

Publicada em

O BLUN King 9.1.510 acrescenta a ferramenta ReadBatch. Lê dois a doze ficheiros UTF-8 independentes e já conhecidos ou intervalos de ficheiros num passo de modelo, mantendo a ordem dos pedidos. Cada caminho passa pelas mesmas verificações de acesso, regras e permissões que uma chamada Read individual. Os sucessos parciais permanecem visíveis; apenas um lote totalmente falhado vale como erro global.

Estado do pacote verificado

A 9.1.510 passa em 125 de 125 testes de pacote. As instalações limpas escolhem no Windows x64, Linux x64, macOS ARM64 e macOS x64 os componentes de plataforma esperados e contêm o ReadBatch. O AgentSpine permaneceu deliberadamente em 0.8.0 até o bloqueador de orçamento de contexto, encontrado de forma independente no estado de pré-lançamento mais recente, estar resolvido sem aumentar o prompt de runtime. SHA-256 do pacote npm: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Novidades na 9.1.509

Publicada em

O BLUN King 9.1.509 exige, em cada mensagem de trabalho do Telegram aprovada entre bots, uma menção expressa do King previsto. As mensagens de bot sem menção adequada permanecem visíveis, mas não são colocadas em buffer nem na fila, não são entregues nem incorporadas posteriormente no contexto de modelo deste King. Deste modo, uma mensagem de bot prioritária para um King já não pode tornar-se tarefa de outro King.

Estado do pacote verificado

Todos os 121 testes de pacote passam. O mesmo pacote contém os componentes de plataforma verificados para Windows x64, Linux x64, macOS ARM64 e macOS x64. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Novidades na 9.1.508

Publicada em

Os pontos de Todo em aberto voltaram a ter uma caixa visível. Também a primeira lista de tarefas normal começa com exatamente um ponto em execução; os passos posteriores permanecem pendentes até o seu início real estar comprovado.

As mensagens diretas e de grupo do Telegram aceites são passadas ao Mnemo de forma assíncrona, com buffer persistente e exatamente deduplicadas. Um hub temporariamente inacessível não bloqueia nem a entrega do Telegram nem a execução do King. Os comandos /loop e os ticks internos de loop não são guardados deliberadamente.

O AgentSpine não carrega nenhum histórico completo do Telegram no contexto de runtime. Se uma tarefa precisar de uma mensagem anterior, é feita uma consulta limitada ao Mnemo por agente, pessoa, grupo, tema, tópico e período de tempo.

Estado do pacote verificado

Todos os 120 testes de pacote passam. As instalações limpas escolhem no Windows, Linux x64, macOS ARM64 e macOS x64 o componente nativo de área de transferência correto e contêm a ligação Telegram-Mnemo gerida e o AgentSpine. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Novidades na 9.1.507

Publicada em

O BLUN King 9.1.507 instrui expressamente o modelo, na ferramenta Read, a agrupar leituras de ficheiros e intervalos independentes numa resposta do modelo, quando várias entradas podem ser úteis.

Isto reduz rondas de modelo evitáveis em contextos de trabalho grandes, sem alterar a execução, a navegação de páginas, as permissões ou o tratamento de resultados do Read.

Estado do pacote verificado

Um teste de regressão dirigido protege a alteração; todos os 112 testes de pacote passam.

Novidades na 9.1.506

Publicada em

Os pontos concluídos da TodoList são removidos imediatamente da TUI visível. A lista de tarefas persistente já descartou corretamente estas entradas; agora a interface mostra o mesmo estado limpo, enquanto o trabalho em execução e pendente permanece integralmente conservado.

O turno de manutenção automático utiliza um prompt de sistema próprio com 546 caracteres. Anteriormente, apesar da única ferramenta Todo disponível, era anexado o prompt de trabalho completo com cerca de 19 000 caracteres. O passo de trabalho seguinte continua a receber o prompt completo e o seu catálogo normal de ferramentas.

Ganho de contexto medido e estado do pacote

Uma execução real mostrou, para cada oitavo passo de trabalho, um turno próprio de manutenção de Todo com 15 221 tokens de entrada. O prompt estático de manutenção encolhe 18 470 caracteres; a poupança real de tempo de execução é medida novamente após a atualização da frota. O tarball publicado passa em 111 de 111 testes. As instalações limpas de pacote no Windows com Node 24.19.0 e no Linux com Node 24.18.0 confirmam a versão 9.1.506; os binários macOS para ARM64 e x64 estão contidos no pacote npm idêntico. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Novidades na 9.1.505

Publicada em

Uma mensagem do Telegram que chega depois da tomada de controlo do canal, mas ainda antes da conclusão da ativação da fila, já não é ignorada como acumulado antigo. Sem ponto de verificação válido, o processamento começa no limite de bytes medido no início da tomada de controlo, em vez do fim posterior do ficheiro.

Um ponto de verificação persistente válido mantém prioridade. Se o ficheiro da fila for substituído durante a entrega, o novo ficheiro começa com segurança no byte zero; as mensagens históricas já existentes antes da tomada de controlo continuam a não ser reproduzidas.

Recaída medida e estado do pacote

A mensagem de grupo 63456 chegou um segundo após a tomada de controlo do canal, o ponto de verificação saltou exatamente até ao seu fim e a mensagem não apareceu em nenhum histórico de modelo. Esta perda real está protegida como regressão. O tarball publicado passa em 111 de 111 testes; as instalações limpas de pacote no Windows com Node 24.19.0 e no Linux com Node 24.18.0, bem como uma atualização real de 9.1.504, confirmam a versão 9.1.505. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Novidades na 9.1.504

Publicada em

Uma mensagem do Telegram que já está na fila de espera quando o agente está em modo de espera é agora iniciada através do percurso normal de canal como turno de modelo novo. Já não espera por uma execução ativa, que em modo de espera não pode surgir por definição.

A entrega existente para um turno em execução permanece inalterada. Da mesma forma, a manutenção isolada do Todo, a remoção automática dos pontos concluídos e a restauração posterior das ferramentas normais de ficheiro, pesquisa e shell permanecem protegidas.

Estado do pacote verificado

O tarball publicado passa em 106 de 106 testes. A nova regressão de modo de espera estava vermelha antes da intervenção e está verde depois, juntamente com 24 testes de fila. As instalações limpas de pacote no Windows com Node 24.19.0 e no Linux com Node 24.18.0 confirmam a versão 9.1.504 e o mesmo SHA-256 df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Novidades na 9.1.503

Publicada em

A mensagem isolada de manutenção do Todo traz agora também um campo toolCalls expressamente vazio. Deste modo, cumpre a mesma forma de mensagem dos turnos de trabalho regulares e pode ser processada em segurança pela normalização do fornecedor BLUN.

O erro real de tempo de execução TypeError: message.toolCalls is not iterable já não ocorre antes da chamada da TodoList. Um teste de regressão itera a mensagem gerada exatamente como o limite do fornecedor, antes de a manutenção ser aprovada.

Estado do pacote verificado

O tarball publicado passa em 105 de 105 testes. As execuções de teste de pacote limpas no Windows com Node 24.19.0 e no Linux com Node 24.15.0 confirmam a forma completa de mensagem do fornecedor, a manutenção isolada do Todo e a remoção automática dos pontos concluídos. A aceitação real da frota decorre após o reinício controlado dos três Kings.

Novidades na 9.1.502

Publicada em

O passo devido de manutenção da TodoList recebe apenas uma mensagem nova, limitada à tarefa atual e à lista visível. As antigas chamadas Read, Bash ou MCP do histórico de trabalho já não podem entrar no passo deliberadamente limitado a TodoList.

As tarefas concluídas desaparecem automaticamente da lista visível e persistente ao guardar. Os pontos em execução, pendentes, bloqueados, à espera de aprovação e cancelados mantêm-se; a lista não cresce assim indefinidamente com trabalho concluído.

Achado medido na frota

Dois perfis de agente encontraram independentemente a mesma recaída: após uma utilização bem-sucedida de ferramentas, a manutenção do Todo repetiu ferramentas de trabalho históricas e mostrou Tool not found. O tarball publicado passa em 105 de 105 testes. As instalações limpas no Windows com Node 24.19.0 e no Linux com Node 24.15.0 confirmam a manutenção isolada, a remoção dos pontos concluídos e o regresso das ferramentas normais. Uma aceitação real em macOS não faz parte deste comprovativo.

Novidades na 9.1.501

Publicada em

Após um passo de manutenção bem-sucedido da TodoList, no passo de trabalho imediatamente seguinte voltam a estar disponíveis todas as ferramentas selecionadas para o turno. Read, Bash e outras ferramentas de trabalho já não permanecem ocultas atrás do catálogo Todo temporariamente limitado.

Recaída reparada

O passo de Todo ofereceu deliberadamente apenas TodoList. No entanto, sem restauração expressa, a sua seleção de ferramentas permaneceu ativa também no passo seguinte. A 9.1.501 repõe aí o catálogo normal e protege ambos os percursos do passo seguinte com uma regressão.

Golden Release 9.1.500

Publicada em

Esta versão agrupa, sem alterações, o estado funcional completo da 9.1.499 numa publicação npm comum para Windows, Linux e macOS. A marcação Gold está deliberadamente limitada aos títulos desta versão; as entradas mais antigas mantêm a sua apresentação anterior.

Estado da versão

A Golden Release incorpora as alterações verificadas de Todo, fila, loop, contexto, AgentSpine e avaliação de imagens da 9.1.499 sem lógica adicional de tempo de execução.

Novidades na 9.1.499

Publicada em

Os dados de imagem, áudio e vídeo fora das últimas doze mensagens de conversa só são substituídos na projeção repetida do modelo por referências curtas. Os conteúdos multimédia atuais, o texto da mensagem e o histórico bruto completo da sessão permanecem inalterados.

Num ponto de verificação de retoma medido, esta projeção poupa 85 748 caracteres, ou seja, cerca de 21 437 tokens de entrada estimados por passo de ferramenta adicional.

A manutenção pendente do Todo decorre antes do nono bloco de trabalho como passo de modelo separado de baixo esforço. Neste passo, o runtime oferece exclusivamente TodoList; as ferramentas de ficheiro, pesquisa, shell e outras ferramentas de trabalho só voltam a ser autorizadas após uma atualização válida.

As mensagens novas do utilizador mantêm prioridade sobre a manutenção do Todo. O controlo rígido do Todo mantém-se como rede de segurança para atualizações realmente inválidas, mas já não aparece como erro intermédio vermelho normal antes de uma manutenção autónoma da lista.

Comprovativo verificado

O tarball publicado passa em 105 de 105 testes de tempo de execução e de regressão. As instalações isoladas limpas no Windows com Node 24.19.0 e no Linux com Node 24.15.0 comunicam exatamente a versão 9.1.499 e confirmam a projeção de conteúdos multimédia, o histórico bruto inalterado, o pré-controlo do Todo e a ocultação de todas as ferramentas de trabalho durante o passo de Todo. O candidato abrange 850 caminhos e tem SHA-256 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Uma aceitação real em macOS não faz parte deste comprovativo.

Novidades na 9.1.498

Publicada em

/usage mostra a taxa de acertos da cache de prompt comunicada pelo fornecedor, bem como os tokens de cache lidos e escritos por modelo. Sem atividade de cache comunicada, a exibição não inventa nenhuma taxa.

/tokens é um alias curto para o diagnóstico detalhado de contexto existente; /offload chama a compactação arquivante existente. Nenhuma das duas vias desencadeia uma chamada adicional ao modelo.

Mensagens de bot autorizadas diferentes já não são descartadas por uma janela rígida de 15 segundos. A ordem existente mantém-se: as mensagens privadas e expressamente endereçadas vêm antes das mensagens de bot, as mensagens de bot antes do contexto normal.

Uma compactação completa transfere a lista exata de Todo para o novo contexto. Se depois disso o caminho, o comando, o hash ou o requisito forem incertos, um aviso único de recuperação exige primeiro a leitura do histórico arquivado, em vez de uma pesquisa ampla de ficheiros ou de um recomeço.

Os passos de Todo concluídos mantêm-se como comprovativo. Se descobertas posteriores tornarem um passo novamente necessário, a conclusão comprovada permanece e a nova verificação aparece como passo próprio em execução com justificação.

Os loops de sessão recorrentes esperam enquanto a lista de Todo mantida ainda contiver trabalho em execução ou pendente. Os intervalos perdidos são agrupados até ao modo de espera real; os outros lembretes agendados não são afetados por isso.

Comprovativo verificado

O tarball preparado passa em 100 de 100 testes de tempo de execução e de regressão. As instalações isoladas limpas no Windows com Node 24.19.0 e no Linux com Node 24.15.0 comunicam exatamente a versão 9.1.498 e confirmam a exibição de cache, os aliases de comandos, a recuperação de compactação, os comprovativos monotónicos de Todo, a proteção do loop de sessão, o changelog do pacote e a prioridade de bot. O candidato abrange 849 caminhos e tem SHA-256 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Uma aceitação real em macOS não faz parte deste comprovativo.

Novidades na 9.1.497

Publicada em

As mensagens de bot do Telegram de grupos comuns vêm depois das mensagens privadas e expressamente endereçadas, mas antes do contexto normal. A priorização não impõe nenhuma resposta.

Uma mensagem do Telegram aceite desaparece da fila visível assim que o seu passo de modelo incorporado começa. Uma entrega rejeitada ou uma interrupção antes do primeiro passo continua a guardá-la para uma nova tentativa.

Uma resposta ou edição de mensagem pendente do Telegram já não é bloqueada pela manutenção do Todo. O próximo passo de trabalho normal permanece bloqueado até à atualização verdadeira da lista de Todo.

Versões 9.1.496 a 9.1.487

VersãoAlterações
9.1.496Entrega automaticamente as mensagens de utilizador do Telegram individualmente, remove apenas o ID de mensagem exatamente aceite ou respondido, impõe progresso verdadeiro para cada lista de Todo visível e oculta as cargas úteis internas bem-sucedidas de hooks.
9.1.495Inicia cada objetivo novo ou substituído com uma lista de Todo visível nova, exige atualizações verdadeiras, remove imediatamente o foco de grupo do Telegram respondido com sucesso, adia as confirmações de receção normais até ao fim do turno e acrescenta verificações reais de descodificação para Ctrl+S e Ctrl+T.
9.1.494Separa novamente os atalhos de forma inequívoca: Ctrl+S controla apenas o volume pendente da fila, Ctrl+T apenas a lista de Todo. As mensagens de utilizador do Telegram autorizam-se, durante trabalho em curso, para a próxima entrega segura.
9.1.493As mensagens de utilizador do Telegram são aprovadas automaticamente durante trabalho ativo para a próxima entrega segura. As mensagens diretas permanecem à frente na fila, sem reter de forma persistente as mensagens de grupo.
9.1.492As mensagens de grupo já aprovadas mantêm-se quando a entrega está temporariamente ocupada e são objeto de nova tentativa. O pacote, os metadados npm, o manifesto público e o changelog são verificados em conjunto antes de uma mensagem de sucesso.
9.1.491As mensagens diretas do Telegram são priorizadas imediatamente durante trabalho em curso. O controlo manual da fila manteve-se para as outras mensagens.
9.1.490O histórico do pacote documenta integralmente a versão não publicada 9.1.487 e as reparações efetivamente publicadas a partir de 9.1.488.
9.1.489A lista de tarefas, o controlo da fila, a identidade de execução do Telegram, a instalação do perfil do AgentSpine e a avaliação de imagens gerida foram restaurados e protegidos com testes de regressão.
9.1.488O plugin central do AgentSpine preparado foi publicado. Os duplicados do Telegram já não deixam um turno fictício; a profundidade de pensamento e o tratamento seguro de telemetria mantêm-se ao longo dos passos de ferramentas.
9.1.487Não publicada. Esta versão preparava o AgentSpine como plugin central gerido. No npm, seguiu-se diretamente 9.1.488 após 9.1.486.

Novidades na 9.1.486

Publicada em

Os perfis novos e atualizados arrancam agora de forma fiável em inglês no Windows, macOS e Linux. Um valor de idioma automático guardado é migrado uma única vez, enquanto os idiomas escolhidos expressamente permanecem inalterados.

As atualizações automáticas no arranque voltaram a estar ativadas por predefinição através do instalador existente vinculado à versão. [upgrade].auto_install = false mantém a pergunta de confirmação; não é reintroduzido nenhum atualizador em segundo plano.

Os diálogos de arranque, o progresso, os erros, as mensagens de sucesso e a continuação da sessão utilizam agora o mesmo idioma. Os testes de regressão e de mutação protegem a migração, o percurso de atualização e os dados da sessão.

Comprovativo verificado

A suíte de testes completa passou com 1 474 de 1 474 verificações. Uma execução isolada de atualização instalou a 9.1.486 a partir da 9.1.485, preservou a configuração e a sessão inalteradas e iniciou a nova CLI. Uma execução de teste de arranque separada comprovou a instalação automática sem pergunta, bem como a migração única de um antigo valor automático de idioma para inglês.

Versões 9.1.485 a 9.1.178

VersãoAlterações
9.1.485
  • Limita a primeira reprodução visível de uma sessão continuada sem índice de scrollback aos 15 turnos de conversa ativos, em vez de voltar a apresentar toda a conversa.
  • Esvazia, após uma atualização bem-sucedida, a área visível de atualização antes de a nova consola arrancar; o scrollback normal do terminal mantém-se.
  • Acrescenta verificações de regressão e de mutação para o recurso alternativo da reprodução, incluindo uma simulação com 97 596 registos.
9.1.484
  • A deteção de plugins aceita adicionalmente .codex-plugin/plugin.json e resolve PLUGIN_ROOT ou BLUN_PLUGIN_ROOT no comando, nos argumentos e no diretório de trabalho.
9.1.483
  • O modelo de compactação pode ser selecionado, guardado e reposto na herança separadamente do modelo ativo; a seleção e a resposta estão disponíveis no comando de modo de espera e nas definições localizadas.
9.1.482
  • Os resultados de Read externalizados preservam o próximo line_offset e continuam aí a leitura original, em vez de voltar a ler o mesmo ficheiro desde o início.
9.1.481
  • As respostas de subagentes que terminam no limite de tokens sem chamada de ferramenta são reconhecidas como max_tokens para a continuação existente. Os padrões Glob com .. e os caminhos home nomeados como ~name são rejeitados.
9.1.480
  • Atualiza a skill translate-native incluída e o MCP Language Guard para a versão 6.42.13.
  • Vincula os ficheiros incluídos da proteção de idiomas byte a byte ao commit de origem 6430ce30e235c1a9d1ebcd1b646d62edce510605.
  • Acrescenta verificações de origem e de mutação, de modo que bytes de proteção alterados ou uma versão divergente de skill façam falhar o controlo de publicação.
9.1.479
  • Adiciona ao serviço privado King da Agent API uma rota interna autenticada para a verificação de disponibilidade.
  • Verifica a disponibilidade do serviço sem criar uma sessão de cliente nem iniciar uma execução de agente.
  • Limita a rota à interface de loopback e a GET, protege-a com um segredo e impede a sua colocação em cache.
9.1.478
  • Corrige pausas normais do foco direto do Telegram após um reinício, mesmo quando os pontos de verificação mais antigos não contêm um prazo de resposta.
  • Preserva as pausas expressamente solicitadas pelo utilizador até à aprovação, em vez de as deixar expirar automaticamente.
  • Liberta as mensagens de canal na fila para uma execução ativa assim que o foco direto termina.
9.1.477
  • Adiciona ao serviço privado da Agent API um invólucro de processo explícito, iniciado pelo operador.
  • Processa SIGINT e SIGTERM exatamente uma vez, também quando os sinais chegam durante o arranque.
  • Termina com segurança com mensagens limitadas, não chama process.exit e nunca inicia o serviço automaticamente.
9.1.476
  • Adiciona ao serviço privado da Agent API um contrato de ambiente segundo o princípio do bloqueio seguro.
  • Exige uma porta de loopback expressamente definida, segredos de isolamento, definições de fornecedor e limites de recursos.
  • Mantém o serviço privado parado e a limpeza automática de sessões inativas desativada, até ambos serem expressamente configurados.
9.1.475
  • Liberta exclusivamente sessões da Agent API configuradas em conformidade e realmente inativas, antes de um cliente atingir o limite de sessões.
  • Protege as execuções ativas de modelo e de ferramentas independentemente da sua idade e atualiza o período de inatividade com utilização real.
  • Mantém a limpeza automática desativada até um operador configurar expressamente um tempo limite de inatividade.
9.1.474
  • Remove a atribuição ativa da sessão quando a continuação de um agente falha após um resultado de ferramenta.
  • Permite posteriormente o fecho expresso da sessão afetada.
  • Deixa os retornos bem-sucedidos de ferramentas e o contrato público de modelo inalterados.
9.1.473
  • Protege uma sessão da Agent API contra o fecho enquanto a sua primeira chamada de modelo ainda estiver em execução.
  • Liberta a sessão de forma fiável após uma resposta bem-sucedida ou um erro de modelo.
  • Deixa o percurso existente para modelos não processados e o contrato público de modelo inalterados.
9.1.472
  • Permite aos clientes encerrar expressamente uma sessão inativa da Agent API e libertar o seu espaço de sessão limitado.
  • Impede o encerramento de sessões ativas e limita cada operação de encerramento ao respetivo cliente proprietário.
  • Disponibiliza o espaço libertado para uma nova sessão, sem alterar o contrato público de modelo.
9.1.471
  • Adiciona um anfitrião de serviço fechado que compõe a pilha privada da Agent API, sem o iniciar automaticamente.
  • Exige segredos separados para o transporte e o isolamento, um diretório de raiz absoluto do cliente e uma configuração expressa do ambiente de execução do King.
  • Liga os listeners à interface de loopback e, ao encerrar, fecha cada sessão de cliente e cada ambiente de execução.
9.1.470
  • Isola as sessões sem interface da Agent API por cliente de confiança e sessão pública.
  • Agrupa os primeiros acessos simultâneos numa única sessão SDK e limita os clientes e sessões ativos.
  • Utiliza identificadores internos opacos e vinculados a chaves e diretórios de trabalho, enquanto os identificadores públicos estáveis de sessão permanecem.
9.1.469
  • Adiciona ao adaptador da Agent API um transporte HTTP privado, acessível exclusivamente através da interface de loopback.
  • Exige um segredo de serviço e uma identidade de cliente pré-definida pelo servidor; indicações de identidade falsificadas no corpo do pedido são ignoradas.
  • Rejeita pedidos demasiado grandes ou defeituosos e mantém os detalhes internos do fornecedor fora das mensagens de erro públicas.
9.1.468
  • Mantém o agente principal responsivo, enquanto os subagentes em segundo plano e os subagentes aninhados continuam a trabalhar.
  • Permite a sessões restritas da Agent API utilizar o ciclo de vida dos subagentes, sem expor ferramentas locais de shell ou de sistema de ficheiros.
  • Transmite o limite exato de ferramentas a cada nível aninhado de subagentes, para que as restrições não possam ser contornadas por delegação.
9.1.467
  • Adiciona um adaptador de transporte explícito para execuções de agentes, sem intercetar as rotas existentes para modelos não processados ou listas de modelos.
  • Vincula os resultados de ferramentas e as interrupções direcionadas ao mesmo âmbito de cliente, sessão e pedido.
  • Mostra exclusivamente King, limpa erros internos inesperados e recusa streaming até existir um contrato de agente para isso.
9.1.466
  • Regista cada chamada de modelo concluída da Agent API sob um ID de tarefa estável, sem somar a utilização de diferentes clientes.
  • Uma correspondência JSONL persistente mantém o pedido, a sessão, a tarefa, o ID de chamada e os campos de utilização não processados localizáveis também após um reinício.
  • Para o exterior aparecem apenas King e os contadores não processados de entrada, entrada em cache e conclusão; os dados de utilização em falta permanecem expressamente assinalados.
9.1.465
  • Adiciona um controlo de execução isolado para o endpoint de agente explícito da Agent API, sem alterar as conclusões de modelo não processadas.
  • As chamadas de ferramentas geridas pelo cliente mantêm, ao longo dos retornos de resultados, uma única execução King e permanecem limitadas ao pedido original.
  • As respostas de agentes superiores excluem os fluxos de eventos de agentes filhos e os rascunhos descartados de novas tentativas.
9.1.464
  • Os subagentes geridos correm agora desacoplados, para que o agente principal permaneça responsivo enquanto o trabalho delegado continua.
  • Os subagentes em execução podem ser controlados com TaskUpdate ou terminados com TaskStop, sem fechar a sessão principal.
  • As mensagens de grupo do Telegram endereçadas permanecem em foco até o agente responder no chat correspondente.
9.1.463
  • Uma retoma a partir de ponto de verificação, com dados de janela existentes, renderiza apenas o último grupo de turnos ativo da TUI; as linhas mais antigas permanecem no arquivo de scroll e são recarregadas quando necessário.
9.1.462
  • Os conteúdos inalterados de tui.toml já não desencadeiam uma troca atómica de ficheiros; as alterações reais continuam a utilizar o percurso de escrita bloqueado existente.
9.1.461
  • /status distingue a versão do runtime carregada do pacote instalado e comunica uma divergência também no estado remoto do Telegram.
9.1.460
  • As mensagens de sessão visíveis mais antigas permanecem num arquivo persistente em disco e são carregadas por blocos ao fazer scroll para cima, sem ler todos os blocos de texto no arranque.
9.1.459
  • Uma retoma restaura um ponto de verificação semântico vinculado à integridade e lê apenas a parte do ficheiro de sessão inalterado anexada desde então; com um ponto de verificação inválido, o replay completo permanece como recurso.
9.1.458
  • Uma soma de verificação retirada de um relatório externo só é vinculada se exatamente esse valor estiver presente no evento de origem selecionado.
9.1.457
  • Se a mesma soma de verificação vier de vários eventos externos, a origem é assinalada como ambígua, em vez de ser atribuída a um relatório.
9.1.456
  • As somas de verificação em mensagens Telegram de saída são comparadas com os resultados locais de ferramentas e relatórios externos visíveis; valores não atribuídos geram um aviso de origem.
9.1.455
  • Os relatórios do Telegram podem ser vinculados como credible_unverified através do ID de chat e de mensagem; o reporter e a origem do evento são definidos pelo runtime.
9.1.454
  • As verificações recentes são automaticamente vinculadas à sessão e ao agente que as geram; as medições reencaminhadas permanecem relatórios externos.
9.1.453
  • Um comprovativo de conclusão é vinculado ao critério de conclusão atualmente válido e é rejeitado com um critério diferente ou desatualizado.
9.1.452
  • Cada comprovativo é vinculado ao âmbito de destino efetivamente medido; as verificações de comandos têm de transportar o mesmo valor seguro de BLUN_EVIDENCE_SCOPE em ambos os lados.
9.1.451
  • Cada comprovativo indica o tipo exato inspection, integrity, syntax, test ou reachability. Uma verificação mais fraca não pode ser apresentada como mais forte.
9.1.450
  • Os comprovativos de resultado e os comprovativos de verificação são separados. Apenas um verificador novo ou alterado precisa de um segundo comprovativo de rigor autónomo; as medições normais não precisam de uma execução de teste a vermelho.
9.1.449
  • O comprovativo de conclusão nomeia a chamada de verificação exata bem-sucedida através da sua toolCallId; uma chamada mista de comando com alteração e verificação não basta.
9.1.448
  • Uma conclusão de objetivo tem de vincular a afirmação verificada a uma chamada de verificação bem-sucedida do mesmo turno; as ferramentas puramente de escrita ou alteração não valem como comprovativo.
9.1.447
  • Uma ação selecionada é vinculada a comprovativos de decisão persistentes; comprovativos desconhecidos ou desatualizados forçam um novo planeamento.
9.1.446
  • O bloqueio de repetição em direto reconhece adicionalmente sequências curtas recorrentes de palavras com duas a oito palavras.
9.1.445
  • As notas de aprendizagem selecionadas são guardadas juntamente com o resultado de aprendizagem validado do turno atual como rasto de exposição, sem daí afirmar causalidade.
9.1.444
  • A pesquisa de relevância por erros anteriores utiliza dados persistentes de objetivo, ponto de verificação e enquadramento do problema, em vez de apenas as mensagens de utilizador mais recentes.
9.1.443
  • Numa continuação imediata de objetivo, uma seleção expressa de tool: ou skill: carrega exatamente o auxiliar escolhido.
9.1.442
  • O foco de trabalho preserva o fio de decisão composto por estado, fase, última verificação, seleção, justificação, apoio, risco e reversibilidade.
9.1.441
  • O conhecimento em falta é registado como domínio próprio knowledge_gap, em vez de no texto geral do objetivo, é priorizado e fica oculto quando o valor está vazio.
9.1.440
  • O conhecimento do mundo e os pressupostos podem ser incluídos e ponderados como domínios próprios no foco persistente.
9.1.439
  • O foco cognitivo persistente recebe uma avaliação de saliência com decaimento entre sessões e reforço em caso de novo acesso.
9.1.438
  • Durante o replay da sessão, o corte, a fusão e a renderização são adiados; depois disso, é pedida exatamente uma nova renderização do transcript.
9.1.437
  • O vigia de inatividade volta a utilizar o caminho de texto adequado para os tempos limite e já não termina o processo através de um parâmetro não permitido no temporizador.
9.1.436
  • O estado remoto do Telegram mostra, num turno ativo, o início, o último progresso, a última ferramenta e os erros repetidos; para isso, a TUI publica instantâneos contínuos de atividade.
9.1.435
  • Os pontos de verificação privados de foco do Telegram seguem agora a área de trabalho vinculada à sessão ativa.
  • A seleção da área de trabalho já não guarda o diretório de arranque como local de continuação para conversas diretas.
9.1.434
  • A aprendizagem confirmada segue agora a área de trabalho vinculada à sessão de agente ativa.
  • As sessões com várias áreas de trabalho e as sessões continuadas já não guardam nem mostram lições de projeto no diretório do processo anfitrião.
9.1.433
  • A preparação de uma entrada no editor externo permanece agora dentro do limite de limpeza dos diretórios temporários.
  • Se a primeira escrita falhar, por exemplo por um disco cheio ou permissões em falta, o diretório temporário do editor é removido antes de o erro ser propagado.
9.1.432
  • Os erros temporários de stream podem agora ser novamente tentados também após uma saída parcial visível, com o mesmo modelo selecionado.
  • O texto incompleto do assistente e as superfícies de ferramentas não concluídas são concluídos ou descartados antes da repetição, para que a nova saída não seja anexada à tentativa falhada.
  • Após uma saída visível, a mudança de fornecedor permanece bloqueada, para que uma resposta não possa mudar de fornecedor a meio do stream.
9.1.431
  • Os processos locais da ferramenta Bash desativam agora à força as consultas Git no terminal, em vez de herdar uma definição interativa do processo superior.
  • Os diálogos askpass herdados do Git, SSH e Git Credential Manager estão desativados no processo filho da ferramenta; deste modo, evitam-se esperas invisíveis por credenciais do Windows.
  • A shell superior e o ambiente da sessão em execução permanecem inalterados; o comportamento existente com entrada padrão fechada mantém-se e é assegurado de forma independente.
9.1.430
  • A compactação completa pode agora utilizar, através de [loop_control].compaction_model, um alias de modelo opcionalmente configurado; o modelo King ativo continua a ser a predefinição.
  • A autenticação, a preparação do contexto, o orçamento de conclusão, a aprendizagem de transbordo e a faturação de utilização da compactação estão integralmente vinculadas ao modelo de compactação escolhido.
  • O modelo ativo continua a determinar o início da compactação e o último travão do pedido, para que um modelo de resumo mais pequeno não possa reduzir, sem que se note, a janela central de raciocínio.
9.1.429
  • O Bash no Windows rejeita agora a sintaxe cmd.exe inequívoca antes do início do processo, em vez de desperdiçar uma execução visivelmente falhada.
  • A descrição da ferramenta Bash esclarece expressamente que o POSIX-Bash no Windows, incluindo o VS Code, permanece ativo, e indica as convenções corretas para caminhos e redirecionamentos.
  • Os comandos find POSIX válidos permanecem permitidos; para semântica cmd deliberadamente desejada, continua a existir uma passagem explícita para cmd.exe /c.
9.1.428
  • As escritas JavaScript e TypeScript geradas param agora antes do acesso ao disco quando uma instrução executável se repete oito vezes consecutivas; deste modo, evitam-se saídas fora de controlo de scripts de análise.
  • A verificação de proteção abrange tanto as chamadas Write para ficheiros completos como as substituições Edit, enquanto os ficheiros não-código, comentários, cadeias de caracteres e repetições permitidas mais curtas permanecem inalterados.
  • Os três casos de degeneração observados com 15, 23 e 31 instruções repetidas são bloqueados; intenções arbitrárias incompletas, mas não repetitivas, permanecem fora desta verificação mecânica.
9.1.427
  • O comando visível /memory core comunica agora o limite ativo do adaptador de memória, a versão do contrato, o modo de identidade, o estado de integridade e os comprovativos entre portais, opcionalmente como saída --json.
  • A memória de substituição vinculada ao perfil e as identidades derivadas de perfis são expressamente excluídas da prontidão para um núcleo comum, em vez de serem apresentadas como memória neutra entre portais.
  • Os fornecedores configurados permanecem visivelmente não confirmados até existirem comprovativos separados; o diagnóstico é apenas de leitura, não concede autorizações e nunca inventa provas entre portais.
9.1.426
  • O comando visível /memory acceptance executa agora uma verificação sintética temporária de memória V7 através de CLI, Telegram e Web, e pode emitir opcionalmente um relatório --json.
  • Dez verificações independentes abrangem a origem entre portais, identidades vinculadas e não vinculadas, o isolamento de agentes e grupos, a deduplicação, a correção e eliminação globais, o bloqueio seguro do fornecedor e os bytes de origem protegidos.
  • O relatório de aceitação serve exclusivamente como comprovativo determinístico: não concede autorizações e nunca lê nem altera um perfil de utilizador real.
9.1.425
  • Os subagentes que atingem o seu limite de tokens recebem agora, no mesmo contexto de agente, uma passagem de entrega breve sem ferramentas, em vez de perderem trabalho de ferramentas concluído.
  • Se também essa entrega atingir o limite, o agente superior recebe um resumo parcial limitado e a instrução exata para continuar pelo mesmo agente.
  • A recuperação permanece concebida segundo o princípio do bloqueio seguro: nenhuma nova tentativa completa da tarefa, nenhuma mensagem de conclusão sem entrega final e nenhuma nova autorização.
9.1.424
  • As lições confirmadas de Mistake.md são agora transferidas para casos formulados de forma diferente, mas semanticamente semelhantes, das áreas de fiabilidade, entrega, orquestração, memória, publicação, média e validação.
  • Os termos exatos de comprovativo continuam a ter prioridade sobre categorias semânticas amplas; o texto não relacionado permanece sem atribuição.
  • As formulações alemãs naturais são unificadas de forma determinística; a ordem alterada não cria novas autorizações nem eleva uma lição não confirmada.
9.1.423
  • As terminações de runtime escrevem agora uma entrada de diagnóstico síncrona persistente antes de o núcleo ou o starter regressarem ou terminarem.
  • Exceções não capturadas, rejeições não tratadas, terminais falhados, sinais, erros de arranque, terminações normais, erros de processos filhos e as suas terminações preservam a causa limpa exata, juntamente com o limite do processo.
  • O registo privado é limitado e à prova de falhas, remove segredos e caminhos home e não reinicia nem carrega nenhuma sessão em execução.
9.1.422
  • Uma sessão aberta e inativa monitoriza agora o seu acionador de tempo guardado e torna-se ativa no modo automático e God Mode em ou após dueAt.
  • Um acionador vencido espera até as respostas ativas, a compactação, as mensagens em fila, os comandos e os diálogos estarem concluídos, antes de continuar exatamente uma vez.
  • Antes do início, o runtime relê o objetivo, a revisão do ponto de verificação, o vencimento, o modo de autorização e a sessão, e descarta os temporizadores em cada percurso de terminação da sessão.
9.1.421
  • Os pontos de verificação de espera baseados em tempo guardam agora um carimbo dueAt exato e unificam-no em UTC.
  • Um arranque regular de sessão no modo automático ou God Mode faz os futuros acionadores de tempo esperarem e retoma-os no momento do vencimento ou depois.
  • A primeira execução continuada recebe a observação exata do vencimento; as sessões continuamente abertas ainda não recebem nesta versão um temporizador de runtime.
9.1.420
  • Um objetivo ativo com ponto de verificação de espera persistente cede o controlo após a execução atual, em vez de atribuir outra execução autónoma.
  • Os acionadores externos, baseados em tempo, em dependências e em decisões do utilizador permanecem guardados e são reavaliados na chegada do próximo evento.
  • Os objetivos imediatos e os objetivos ativos mais antigos sem ponto de verificação são continuados inalterados.
9.1.419
  • Uma sessão continuada regularmente prossegue agora com um objetivo já ativo quando o seu próximo acionador guardado é expressamente imediato e o modo automático ou God Mode está ativo.
  • A continuação permanece interna, corre no máximo uma vez por sessão continuada e nunca aparece como mensagem de utilizador inventada.
  • Os objetivos em espera, em pausa e bloqueados, os pontos de verificação em falta e os modos de autorização manuais permanecem suspensos.
9.1.418
  • O Telegram preserva agora a marcação expressa de bot do remetente nos dados de entrada, para que o contexto de identidade possa distinguir agentes de pessoas.
  • Os atores do Telegram já guardados como pessoas só são corrigidos para agentes quando o fornecedor, o sujeito e a marcação expressa de bot coincidem.
  • Os detalhes dos atores permanecem; os agentes nunca são rebaixados e nomes ou nomes de utilizador nunca são usados para derivar uma identidade de agente.
9.1.417
  • As respostas automáticas de substituição do Telegram dividem agora as respostas com mais de 4 096 caracteres em mensagens consecutivas, em vez de as truncar.
  • Cada caractere e cada par de substitutos Unicode são preservados; a saída regista todos os IDs de mensagens devolvidos juntamente com o texto completo.
  • Se uma parte falhar, a entrega para nesse ponto, em vez de comunicar uma resposta incompleta como completa.
9.1.416
  • Os resultados recentes do último lote de chamadas de ferramentas permanecem totalmente legíveis até à próxima resposta do assistente, mesmo que entretanto seja alimentado contexto do Telegram ou de controlo.
  • A externalização por lotes, a limpeza do histórico e a microcompactação utilizam agora o mesmo limite semântico para resultados recentes.
  • Os resultados mais antigos já avaliados continuam a ser compactados normalmente, de modo que as poupanças de contexto anteriores se mantêm.
9.1.415
  • O foco de trabalho persistente preserva agora o acionador exato para a próxima ação através de reinícios e mudanças de contexto.
  • A próxima ação permanece separada da sua condição de autorização; isso vale também para condições válidas com mais de 512 caracteres.
  • Os acionadores defeituosos ou inadequados à fase são rejeitados em segurança; os pontos de verificação mais antigos mantêm o seu comportamento anterior.
9.1.414
  • Os novos pontos de verificação persistentes de ação registam o acionador exato que autoriza a próxima ação.
  • As fases que não esperam precisam de um acionador imediato; as fases em espera precisam de um evento externo nomeado, um momento, uma dependência ou uma decisão do utilizador.
  • Os objetivos em espera permanecem ativos, sem serem executados prematuramente; os pontos de verificação mais antigos permanecem legíveis.
9.1.413
  • As respostas do Telegram que atingem o limite de saída do modelo já não são entregues como inícios incompletos.
  • A mesma sessão em execução gera uma continuação curta e completa e faz no máximo três tentativas de recuperação antes de abortar em segurança.
  • Uma resposta expressa através da ferramenta do Telegram continua a ter prioridade e suprime a recuperação, para que os envios bem-sucedidos nunca sejam duplicados.
9.1.412
  • Os objetivos persistentes criados pelo modelo começam agora atomicamente com a revisão 1 e um enquadramento completo e limitado do problema.
  • O God Mode e o modo automático continuam um arranque de objetivo já autorizado sem segunda confirmação; no modo manual, a aprovação continua a ser necessária.
  • O trabalho autenticado, não trivial e com várias etapas pode mudar para o modo de objetivo persistente sob uma instrução autónoma existente; saudações, pedidos de uma etapa e tarefas vagas permanecem excluídos.
9.1.411
  • As tarefas não triviais e desconhecidas podem agora guardar um enquadramento limitado do problema no ponto de verificação persistente de ação.
  • O enquadramento regista os critérios de sucesso, o conhecimento em falta, até cinco ações possíveis, a ação selecionada com justificação, a escolha do apoio, o risco e o percurso de recurso.
  • O enquadramento do problema sobrevive à continuação e ao reinício exclusivamente como estado descritivo e nunca pode conceder autorizações.
9.1.410
  • Os comandos privados de memória do Telegram limitam agora o âmbito da relação à respetiva pessoa.
  • O foco de memória oculta as relações de outras pessoas e mantém o restante contexto.
  • As correções e eliminações não podem selecionar uma relação de outra pessoa; o foco local do operador mantém a vista completa.
9.1.409
  • As ferramentas de resposta do Telegram e o percurso de recurso da TUI utilizam agora um diretório canónico comum para o estado do canal.
  • Os valores BLUN_HOME específicos de perfil já não criam uma segunda árvore de diretórios para as entradas ou saídas do Telegram.
  • Um BLUN_TELEGRAM_STATE_DIR definido expressamente continua a ser determinante; caso contrário, ambos os percursos utilizam ~/.blun/channels/telegram.
9.1.408
  • Os detalhes confirmados de relações só são fundidos após duas observações independentes em canais diretos.
  • As mensagens reproduzidas novamente permanecem idempotentes; as mensagens de grupo e as afirmações semelhantes a autorizações permanecem excluídas.
  • As lembranças confirmadas de relações privadas podem seguir a mesma pessoa através do Telegram e da CLI, sem conceder autorizações.
9.1.407
  • A ferramenta de resposta do Telegram importa o caminho para o histórico de entrada em execução utilizado pela deteção de duplicados.
  • As respostas normais do Telegram já não falham com o erro inboxLog is not defined.
  • O percurso de recurso separado do bridge permanece disponível como salvaguarda da entrega.
9.1.406
  • As tentativas repetidas de entrega de eventos privados do Telegram com o mesmo carimbo de tempo e texto são guardadas apenas uma vez na continuidade da relação.
  • Uma afirmação realmente repetida mais tarde permanece parte do histórico limitado da relação.
  • Os avisos de lembrete explícitos formulados naturalmente no fim da frase são reconhecidos como dados de referência, sem conceder nem alterar autorizações.
9.1.405
  • O comando /status do Telegram emparelhado comunica agora a idade e o sinal de vida do processo da consola, o passo de trabalho atual e a tarefa ativa, sem chamar o modelo.
  • O volume pendente da fila mede agora os bytes não lidos a partir de um ponto de verificação vinculado ao ficheiro de fila atual exato.
  • O estado remoto permanece só de leitura e não contém IDs de chat, caminhos de ficheiros, dados de acesso, conteúdos de mensagens nem listas completas de tarefas.
9.1.404
  • Um conteúdo inalterado da config.toml já não substitui o ficheiro privado existente.
  • A comparação exata de bytes está limitada a destinos regulares que não são ligações simbólicas.
  • Os destinos alterados, em falta, inválidos e não legíveis continuam a utilizar o percurso de escrita atómico existente, seguro contra falhas.
9.1.403
  • A ordenação automática das ferramentas carregáveis ignora as cargas úteis incorporadas de anexos e documentos.
  • Cada fragmento de intenção é limitado ao orçamento de consulta ToolSearch existente de 1 000 caracteres antes da comparação lexical.
  • As instruções efetivas, os anexos e os pedidos ToolSearch expressos permanecem inalterados.
9.1.402
  • Os arquivos expirados do histórico de compactação são limpos uma única vez em segundo plano no arranque de um comando King.
  • A limpeza no arranque permanece não bloqueante e não pode atrasar o processamento normal de comandos.
  • Os erros na limpeza são registados em segurança e não interrompem a sessão em execução.
9.1.401
  • O primeiro fragmento de texto de cada resposta em execução é agora apresentado imediatamente, em vez de esperar por uma chamada de temporizador.
  • Um novo turno e cada novo segmento de resposta do assistente recebem cada um a sua própria primeira apresentação imediata.
  • Os fragmentos posteriores de texto, pensamento e ferramentas mantêm o ritmo adaptativo de agrupamento que protege o desempenho das sessões longas.
9.1.400
  • As grandes sessões continuadas são agora reproduzidas cooperativamente, para que a TUI possa redesenhar e reagir durante a recuperação do histórico.
  • Cada registo de reprodução guardado de forma persistente continua a ser apresentado; nenhuma parte do histórico é cortada, ignorada ou apagada.
  • As continuações pequenas mantêm o seu comportamento anterior; as continuações grandes cedem a execução ao ciclo de eventos após cada 30 registos.
9.1.399
  • Os candidatos de aprendizagem verificados estão agora limitados ao projeto Git atual, em vez de irem parar a repositórios não relacionados.
  • Os checkouts HTTPS e SSH da mesma origem utilizam uma identidade de projeto anónima comum.
  • Os URLs de repositório e os caminhos locais de projeto nunca são guardados em registos de candidatos de aprendizagem; o trabalho fora do Git mantém o comportamento existente a nível do perfil.
9.1.398
  • As respostas puramente textuais do Telegram são agora deduplicadas através do percurso de ferramenta e de ambos os percursos automáticos de recurso.
  • Uma resposta idêntica ou quase idêntica só é suprimida quando não existe nenhuma mensagem recebida mais recente.
  • Os anexos, os resultados diferentes e as respostas após uma nova mensagem de utilizador mantêm o seu comportamento anterior.
9.1.397
  • Os objetivos com um critério de conclusão expresso precisam agora, antes da conclusão, de um ponto de verificação apoiado pelo runtime.
  • Se a verificação de conclusão falhar, o objetivo permanece ativo e devolve avisos concretos para a revisão.
  • Os turnos normais e os objetivos sem critério de conclusão expresso mantêm o seu comportamento anterior.
9.1.396
  • Os pedidos em linguagem natural podem pré-selecionar no mesmo turno até dois esquemas de ferramentas carregáveis com elevada certeza de correspondência.
  • A seleção considera exclusivamente a intenção atual no canal e ignora o contexto antigo do Telegram.
  • Para pedidos fracos, ambíguos ou desconhecidos, o ToolSearch permanece disponível, sem aumentar o conjunto de ferramentas carregadas de forma persistente.
9.1.395
  • Os trabalhos de média aceites são acompanhados de forma persistente, os pedidos abertos idênticos são reutilizados e os resultados concluídos são guardados após verificação de qualidade e entregues ao chat correspondente.
9.1.394
  • Um fornecedor de memória versionado e ativável voluntariamente pode ligar os turnos de CLI e de portal a um fluxo comum de eventos cognitivos.
  • Por predefinição permanece o armazenamento local SQLite existente, sem novo acesso à rede nem comportamento de runtime alterado.
  • Os caminhos do fornecedor, as funções de fábrica síncronas e a versão 6 do contrato são agora verificados em segurança antes do início do runtime e rejeitados em caso de divergência.
9.1.393
  • Os arranques interativos com king e king -c voltam a mostrar a seleção visível de atualização 1/2/3 assim que existe uma versão mais recente.
  • A transferência de atualizações em segundo plano, a ativação pendente e a mudança automática adiada foram removidas.
  • Após uma instalação selecionada, o king termina para um reinício manual; o king -c continua a última sessão com a nova versão.
9.1.392
  • Os estados intermédios incompletos de uma geração de imagens já não são enviados como atualização privada do Telegram enquanto não existir um resultado de média.
  • As descrições de erro medidas do GenerateImage e do GetMedia são suprimidas; as entregas de média concluídas permanecem visíveis.
  • As conversas privadas e os resultados comuns solicitados permanecem inalterados.
9.1.391
  • A continuidade de lembranças entre portais exige agora um comprovativo exato e ativo de ligação de identidade do runtime de confiança.
  • Os nomes semelhantes, os tenants ou identidades de origem divergentes, os emissores falsos e os comprovativos revogados permanecem separados e são rejeitados em segurança.
  • A versão 6 do contrato do adaptador de memória suporta OAuth verificado, ligações seguras de contas e atribuições de identidade expressamente confirmadas, sem derivar autorizações de lembranças.
9.1.390
  • O envelope comum de memória regista agora separadamente o momento do evento e o momento da entrada.
  • Cada novo evento cognitivo recebe expressamente uma classe de retenção para dados operacionais, dados persistentes, relações ou fins de verificação.
  • A versão 5 do contrato do adaptador de memória rejeita envelopes de eventos incompletos antes de qualquer escrita local ou remota.
9.1.389
  • Os eventos de memória registam agora o portal de origem e o canal de origem como campos separados e autenticados de proveniência.
  • Os percursos de CLI, Telegram, runtime, personalidade, correção e revogação preservam o canal exato no armazenamento e na reprodução.
  • A versão 4 do contrato do adaptador de memória rejeita escritas quando o canal de origem guardado não corresponde ao canal autorizado pela permissão.
9.1.388
  • As leituras de memória devolvem agora apenas observações do âmbito de visibilidade autorizado pela permissão, exceto quando é utilizado o percurso estritamente interno do agente.
  • As escritas, as verificações de eventos e as operações de atenção são rejeitadas em segurança quando o seu âmbito ou a sua fonte autenticada não corresponde ao contexto de acesso atual.
  • O adaptador SQLite local consulta observações delimitadas através de um índice de visibilidade próprio, em vez de carregar primeiro lembranças não relacionadas.
9.1.387
  • Cada operação de um adaptador de memória transporta agora um contexto estrito de identidade, portal, canal, conversa, âmbito e autorizações.
  • O contexto de autorização é verificado fora da carga útil de memória e não é guardado de forma persistente como conteúdo lembrado.
  • A deduplicação de eventos está limitada ao tenant e ao agente. Deste modo, a existência de eventos não pode ser reconhecida entre tenants.
9.1.386
  • O estado cognitivo está agora atrás de um contrato versionado para adaptadores de memória, utilizado em conjunto pelo ciclo de vida do turno e pelo runtime da personalidade.
  • O armazenamento de eventos SQLite existente permanece a predefinição. Os clientes externos de portal podem disponibilizar o mesmo contrato, sem criar um estado próprio do portal.
  • As versões de adaptador não suportadas e as implementações incompletas são rejeitadas em segurança antes de cada operação de memória.
9.1.385
  • As mensagens do Telegram colocadas na fila antes do início da sessão são agora libertadas assim que a sessão está pronta.
  • As sessões em modo de espera esvaziam a fila na ordem FIFO normal; os turnos ativos já continuados utilizam um controlo limitado.
  • Os pontos de verificação persistentes da fila permanecem inalterados até a mensagem ser efetivamente aceite.
9.1.384
  • As referências a imagens do Telegram carregam agora no mesmo turno as ferramentas de verificação e de geração de imagens.
  • As mensagens do Telegram em buffer preservam a intenção de média para todo o lote pendente, em vez de considerar apenas a última mensagem.
  • Os caminhos de imagem locais e os identificadores de ficheiros do Telegram escolhem o percurso de verificação ou transferência adequado, sem carregar de forma persistente os esquemas de média.
9.1.383
  • Os novos resultados de Read permanecem agora totalmente visíveis para o passo de modelo que os solicitou, em vez de serem externalizados antes da avaliação.
  • Os novos resultados paralelos de ferramentas permanecem legíveis até ao seu passo de avaliação e só podem ser arquivados depois de se tornarem históricos.
  • A arquivação das saídas históricas e a poupança de contexto permanecem ativas após a janela protegida para o trabalho mais recente.
9.1.382
  • O comando /loop é agora aceite também enquanto outra resposta está em execução.
  • Se for criado um loop durante trabalho em curso, o King guarda-o e coloca a sua primeira instrução na fila, sem interromper o turno atual.
  • A criação de loops em modo de espera e o comportamento existente para estado, pausa, continuação e paragem permanecem inalterados.
9.1.381
  • Após uma ToolSearch definitivamente sem êxito, a ToolSearch é removida da lista de ferramentas ativas pelo resto deste turno.
  • O reconhecimento bem-sucedido de esquemas e o tratamento de ferramentas já carregadas permanecem disponíveis e inalterados.
  • Deste modo, as pesquisas repetidas de sinónimos não consomem mais tokens depois de o runtime já ter comprovado que não existe nenhuma integração adequada.
9.1.380
  • Um erro temporário no controlo do turno ativo reativa agora imediatamente o controlo de entrega do Telegram, em vez de fazer a mensagem de grupo recuperada esperar até ao fim do turno.
  • As mensagens de grupo pendentes continuam a ser entregues também durante trabalho longo; a ordem FIFO e o limite de quarentena existente de três tentativas mantêm-se.
  • Nenhuma sessão em execução é interrompida ou reiniciada.
9.1.379
  • As repetições temporárias da confirmação de um controlo de canal já não mostram um erro vermelho falso, enquanto a mensagem permanecer recuperável na fila.
  • Um erro visível de entrega só aparece depois de a terceira tentativa falhada ter arquivado em segurança o primeiro registo completo da fila.
  • O comportamento para repetição, confirmação, arquivação e ordem FIFO permanece inalterado.
9.1.378
  • Com publicações de fundo em rápida sucessão, existe agora um único estado substituível para a atualização preparada, em vez de acrescentar um novo componente de registo para cada versão.
  • A entrada para a atualização preparada mostra sempre a versão de destino verificada mais recente; a sessão ativa permanece intacta até ao seu reinício natural.
  • O aviso sobre a instalação efetiva e o changelog mantém-se de forma persistente e inalterado. Menos alterações no registo não ocultam, portanto, nenhuma atualização ativada.
9.1.377
  • As tarefas do Telegram pendentes obtêm agora o ID determinante do turno ativo a partir do núcleo. Um estado TUI visível desatualizado já não pode fazer com que uma mensagem aceite fique sem confirmação.
  • O comando de controlo /loop é executado imediatamente durante trabalho em curso; a confirmação persistente do comando já não depende de uma resposta de estado bem-sucedida do Telegram.
  • Se a entrega do primeiro registo da fila falhar três vezes, ele é arquivado localmente com todos os metadados de recuperação antes de a fila continuar. Deste modo, um registo defeituoso não bloqueia mensagens posteriores.
9.1.376
  • Os grandes resultados históricos de ferramentas são guardados de forma persistente antes da compactação do contexto, para que a sua saída completa permaneça recuperável também depois de esvaziada a pré-visualização incorporada.
  • As referências guardadas aos resultados sobrevivem a microcompactações posteriores e mantêm os metadados limitados necessários para recarregar a saída original.
  • A telemetria de externalização comunica tamanhos e estado de recuperação, sem expor conteúdos de resultados ou caminhos privados.
9.1.375
  • As DMs privadas do Telegram e os comandos de barra mantêm a prioridade de entrega mais alta. O trabalho de grupo explicitamente endereçado é colocado na fila depois, em FIFO, antes da carga antiga normal ou não endereçada.
  • Uma transferência de atualização só pode atravessar uma fila não vazia quando cada registo é trabalho do Telegram persistente e ainda não confirmado, com percurso de retorno de confirmação. O trabalho local, misto ou não persistente continua a bloquear.
  • O aviso para atualizações preparadas segue uma língua de interface da persona já aprovada. Para uma língua ainda não aprovada como locale da TUI, é mostrada apenas a informação de versão, em vez de cair numa língua errada.
9.1.374
  • O aviso para uma atualização preparada já não utiliza uma mensagem alemã fixa, mas sim a tradução de interface já aprovada da língua ativa.
  • Os modos de retoma e de nova sessão permanecem separados; a transferência de atualização, o rollback e a confirmação de duplicados do Telegram não foram enfraquecidos.
9.1.373
  • Uma atualização preparada em segundo plano pode agora assumir a sessão em execução num limite seguro verificado. O ID da sessão e o diretório de trabalho permanecem; as ferramentas em execução, os comandos de shell, a compactação e as mensagens em espera impedem a transferência.
  • O supervisor ativa o novo runtime apenas após os seus comprovativos loaded e ready. Se o arranque falhar, o runtime antigo é restaurado com a sessão exata e o pendente defeituoso é descartado.
  • Os duplicados do Telegram já recuperados no ledger de entrega são imediatamente confirmados no replay da fila. Já não esperam por um passo de modelo que, para um duplicado, deliberadamente nunca arranca, e já não bloqueiam mensagens de grupo posteriores.
  • O foco de trabalho persistente transporta agora o estado de conhecimento, o contexto de comprovativo, as correções, as revogações e a confiança ao longo dos turnos. Daí continuam a não resultar novos direitos ou aprovações.
9.1.372
  • Os checkpoints persistentes de objetivo distinguem agora verified, credible_unverified, hypothesis, uncertain_memory, stale e unknown. As suposições plausíveis já não são tratadas como conhecimento assegurado.
  • A proveniência e o estado de conhecimento são verificados em conjunto: os comprovativos de ferramentas do runtime só podem valer como verified após uma execução de ferramenta bem-sucedida, os relatórios externos não. Os estados de transmissão preservam o seu estado anterior e o seu último comprovativo de verificação.
  • Os estados de replay antigos sem o novo campo permanecem legíveis como legacy_unknown. Os checkpoints novos têm de indicar explicitamente o seu estado. Os direitos, as aprovações e a autoridade permanecem inalterados.
  • A projeção de contexto curta indica o estado epistémico em exatamente uma linha, para que o agente o considere no passo seguinte, sem sobrecarregar o orçamento de contexto com texto adicional.
9.1.371
  • Reparação de um erro de cablagem da 9.1.370: o valor evidenceBasis já guardado e projetado é agora também parte do esquema público estrito de saída do GetGoal e já não se perde na recuperação.
  • O esquema aceita os quatro tipos atuais de proveniência, bem como legacy_unknown para estados de replay antigos. Os direitos, as aprovações e a autoridade permanecem inalterados.
  • Uma execução de teste de cablagem focada e um mutante próprio protegem a nova ligação pública contra regressões.
9.1.370
  • Cada checkpoint de trabalho novo indica agora explicitamente em que assenta o seu último estado comprovado: chamada de ferramenta de runtime bem-sucedida, afirmação direta do utilizador, relatório externo ou continuação inalterada.
  • runtime_tool só é aceite quando o turno atual contém pelo menos uma chamada de ferramenta permitida pelo runtime e concluída com êxito. carried_forward não pode alterar o último estado comprovado. Ambos os percursos abortam em fail-closed em caso de contradição.
  • Os checkpoints antigos guardados permanecem legíveis como legacy_unknown. O tipo de proveniência é estado epistémico e não gera direitos, aprovações nem autoridade.
9.1.369
  • Um checkpoint de trabalho persistente recebe agora automaticamente um comprovativo de runtime compacto das chamadas de ferramentas já concluídas do mesmo turno. O comprovativo indica apenas o ID do turno, o número total, de sucessos e de falhas e um digest curto.
  • Os nomes de ferramentas, IDs, argumentos, comandos, saídas, caminhos e texto de utilizador não são escritos no checkpoint. Um comprovativo vazio permanece honestamente em zero, em vez de simular uma medição.
  • Só conta como sucesso uma chamada de ferramenta autorizada pela política do runtime e concluída com êxito. Os comprovativos bloqueados, falhados, abortados ou fornecidos pelo modelo não geram autoridade.
9.1.368
  • Cada checkpoint de trabalho persistente tem agora uma revisão monótona. A primeira escrita começa na revisão 1; cada escrita seguinte tem de aumentar exatamente em um a revisão atualmente projetada.
  • Um turno paralelo antigo ou uma vista de canal desatualizada já não pode sobrescrever retroativamente um estado de trabalho comprovado mais recente. As revisões desatualizadas, ignoradas e inválidas abortam em fail-closed antes de o estado do objetivo ser alterado.
  • Os checkpoints existentes sem campo de revisão são tratados de forma compatível como revisão 1 ao ler. A revisão é estado de trabalho e não gera direitos nem aprovações.
9.1.367
  • O lembrete de objetivo ativo transporta agora diretamente o checkpoint de trabalho persistente. O King mantém a fase, o último estado comprovado, a próxima ação exata e o comprovativo esperado também quando o adaptador cognitivo de memória adicional não está disponível nesse momento.
  • Antes de caminhos alternativos, é executada primeiro a próxima ação exatamente anotada. O checkpoint só é alterado quando nova evidência muda realmente o estado confirmado.
  • O fallback é apenas uma projeção compacta do checkpoint já verificado. Não gera direitos, nem novos campos de dados, nem um reinício.
9.1.366
  • Os objetivos ativos podem agora guardar um checkpoint de trabalho persistente pequeno com fase, último resultado comprovado, próxima ação exata e comprovativo esperado. Após uma retoma ou um replay de eventos, o King continua nesse ponto, em vez de voltar a pedir autorização ou recomeçar do início.
  • Uma mera atualização de checkpoint mantém o objetivo ativo. Os objetivos em pausa e bloqueados permanecem inalterados; uma retoma apenas repõe o relógio de runtime.
  • O checkpoint é estritamente limitado e é pura informação de trabalho. Os campos desconhecidos, em particular indicações de direitos ou de administração, abortam em fail-closed e não podem gerar nenhuma capacidade.
  • Sem checkpoint, o foco compacto anterior permanece inalterado. Com checkpoint, apenas as quatro observações de foco relevantes são complementadas com o estado comprovado; deste modo, o custo de tokens permanece pequeno e constante.
9.1.365
  • As DMs privadas do Telegram e a CLI local podem agora ler, corrigir ou apagar diretamente o foco persistente com /memory focus, /memory correct <id> <valor> e /memory delete <id>. Este percurso não inicia nenhum turno de modelo e, por isso, não consome tokens de modelo.
  • As alterações do Telegram estão vinculadas a IDs positivos de utilizador, chat e mensagem, a uma DM privada real, ao momento do canal e a um ID de pedido estável. Os grupos, a proveniência incompleta e as repetições alteradas abortam em fail-closed.
  • O domínio, a chave e o âmbito são sempre derivados do comprovativo de objetivo ativo e não podem ser introduzidos por quem chama. As correções e os tombstones permanecem append-only, preservam o histórico e não concedem direitos.
  • A saída de foco está limitada, para o Telegram, a oito entradas e menos de 3 500 caracteres; o número total permanece visível.
9.1.364
  • O ciclo de vida cognitivo em execução pode agora corrigir um foco persistente através de correctFocusObservation e apagá-lo através de withdrawFocusObservation. Ambos os percursos continuam a escrever append-only no mesmo fluxo de eventos vinculado ao tenant e ao agente.
  • Uma revisão só é permitida com a atestação runtime_user_prompt_hook e explicit_user_request. Um snapshot normal de modelo não pode derivar nem introduzir correções ou eliminações.
  • Cada revisão transporta um ID de pedido estável, bem como portal, ator, contexto, mensagem e momento. A repetição idêntica é idempotente; o mesmo ID de pedido com conteúdo alterado e revisões com data retroativa abortam em fail-closed.
  • A correção e a eliminação subsequente deixam o histórico completo inalterado. Após a eliminação, o facto já não aparece no prompt e não consome tokens de contexto. A memória continua a não poder conceder direitos.
9.1.363
  • Uma eliminação confirmada é agora guardada como tombstone append-only. O conteúdo anterior permanece no histórico de auditoria e na cadeia de hashes, mas desaparece completamente da projeção de contexto eficaz.
  • Os eventos antigos de resume, transcript ou fila com um momento anterior à eliminação não podem reativar o conteúdo removido. Deste modo, um estado antigo reproduzido mais tarde não é tratado como nova verdade.
  • A informação deliberadamente fornecida de novo após o momento da eliminação pode voltar a ser aprendida. O tombstone bloqueia, portanto, a evidência antiga, não o desenvolvimento futuro.
  • As eliminações através de tenants, agentes, domínios, chaves ou âmbitos de terceiros, com destino em falta, confiança fraca ou valor de tombstone errado, são rejeitadas transacionalmente. As bases de dados existentes migram in-place.
  • Um facto eliminado não gera nenhuma linha de prompt e, por isso, não consome tokens de contexto.
9.1.362
  • Uma correção confirmada pode agora substituir explicitamente exatamente uma observação anterior no mesmo âmbito de tenant, agente, domínio, chave e âmbito. A entrada antiga permanece append-only no histórico de auditoria.
  • A vista eficaz carrega o valor corrigido e marca-o como corrected; o valor substituído já não é projetado como conflito atual.
  • Os destinos em falta, os âmbitos ou chaves de terceiros e as correções abaixo da confiança 1 são rejeitados transacionalmente.
  • Os estados SQLite existentes recebem a nova coluna de relações ao abrir, sem perder o seu fluxo anterior ou a sua versão.
9.1.361
  • As afirmações pessoais ou de equipa igualmente credíveis com o mesmo âmbito e chave já não são emitidas como verdade segundo o princípio «o valor mais recente vence». A projeção assinala o conflito de forma curta e pede um esclarecimento, sem despejar ambos os conteúdos no contexto.
  • Se uma afirmação for pelo menos 0,2 pontos de confiança mais forte, permanece utilizável, mas é marcada como contestada. Uma afirmação posterior mais fraca já não pode ocultar um estado confirmado.
  • As confirmações idênticas são agrupadas num ponto de foco. Os campos canónicos de objetivo e progresso permanecem suscetíveis de revisão.
  • O histórico de eventos append-only permanece inalterado; da vista eficaz continuam a não poder resultar autorizações.
9.1.360
  • O estado já canónico de /goal é projetado como foco de trabalho persistente no fluxo de eventos cognitivos: objetivo, estado, próximo acionador e comprovativo de sucesso esperado.
  • O mesmo foco permanece idempotente ao longo dos reinícios de runtime. Um estado de objetivo inalterado não gera eventos nem observações duplicados.
  • Os contadores de utilização, o orçamento de tempo e as autorizações não são copiados para o foco. Sem objetivo ativo, não são carregados tokens de foco adicionais.
  • A projeção liga o âmbito de objetivo adequado ao âmbito privado de relações do turno atual; não gera direitos.
9.1.359
  • A memória de personalidade e os turnos CLI reais utilizam agora o mesmo fluxo de identidade de tenant e agente de identity/manifest.json; sem identidade completa, permanece o percurso de recurso compatível com hash.
  • Os turnos diretos do Telegram projetam apenas o âmbito de relação privada do interlocutor atual. Grupos e relações alheias não fornecem tokens de foco privados.
  • A seleção do âmbito é imposta antes do ranking; um conhecimento mais recente de um âmbito alheio já não pode ocultar uma entrada adequada.
9.1.358
  • Um erro de rede durante a preparação automática da atualização era comunicado apenas a um callback de erro opcional. Sem um novo poll, o King em execução permanecia na sua versão, embora a própria sessão continuasse a funcionar de forma saudável.
  • O launcher escreve agora um evento limitado prepare-failed com a versão e nome/código de erro seguros em handoff.jsonl.
  • Depois, é planeada uma nova tentativa de preparação exatamente 10 segundos mais tarde. O Core em execução não é terminado nem recarregado.
  • Os erros ao escrever o evento de diagnóstico permanecem fail-soft; tokens, texto da mensagem e outros segredos não são registados.
9.1.357
  • Os acessos repetidos ao mesmo prompt de sistema efetivo já não reconstroem a grande cadeia de caracteres a partir da base e do anexo de tempo de execução a cada acesso.
  • O resolver mantém exatamente uma combinação atual de base/anexo e invalida-a imediatamente assim que um dos dois valores de entrada muda.
  • Prompt vazio, apenas base, apenas anexo e a separação anterior com duas quebras de linha permanecem idênticos byte a byte.
9.1.356
  • Os prompts de sistema inalterados são contados apenas uma vez, carácter a carácter, para o orçamento de contexto ao longo de passos de modelo repetidos.
  • A cache está limitada a quatro entradas, no máximo 500 000 caracteres por prompt e 1 000 000 caracteres mantidos no total.
  • Os prompts alterados continuam a ser contados de novo; a indicação de contexto, o orçamento de compactação e o orçamento de pedido utilizam o mesmo valor atual.
9.1.355
  • As configurações de pedido LLM inalteradas já não serializam os seus esquemas de ferramentas a cada passo de modelo apenas para o registo de configuração.
  • O modelo, o alias, o nível de raciocínio, o prompt de sistema e a sequência de ferramentas são comparados com o último estado completo.
  • Modelos, prompts, nomes de ferramentas, descrições ou esquemas de parâmetros alterados reabrem o registo de configuração de forma direcionada.
9.1.354
  • Os esquemas de ferramentas inalterados são serializados apenas uma vez por objeto de ferramenta e contados para o orçamento de contexto.
  • Um inventário com 403 ferramentas deixa assim de ser contado completamente de novo em verificações de pedido repetidas.
  • Alterações ao nome, à descrição ou ao objeto de parâmetros descartam apenas a entrada de cache da ferramenta afetada.
9.1.353
  • Os fragmentos de argumentos de ferramentas de enxame de agentes continuam a ser analisados imediatamente e incorporados no estado de progresso, mas partilham agora o temporizador de renderização adaptativo.
  • Uma grande chamada de ferramenta em streaming deixa assim de desencadear uma renderização TUI completa para cada fragmento de argumento.
  • Início, conclusão, erro e cancelamento removem os temporizadores de enxame abertos antes da sua renderização imediata final.
9.1.352
  • Os fragmentos de assistant e de thinking de um enxame de agentes continuam a atualizar o estado de progresso imediatamente, mas partilham um temporizador de renderização adaptativo.
  • Uma tempestade de fragmentos deixa assim de desencadear uma renderização TUI completa para cada delta.
  • Eventos de enxame discretos e a limpeza do progresso removem os temporizadores abertos antes da sua renderização de conclusão imediata.
9.1.351
  • Os fragmentos de assistant e de thinking na janela BTW/agente são guardados imediatamente no turno, mas partilham um temporizador de renderização adaptativo.
  • O controlador deixa de exigir uma renderização completa adicional por fragmento para estes dois tipos de delta.
  • Conclusão, erro, nova tentativa e dispose removem os temporizadores abertos; eventos discretos de hook e de conclusão permanecem imediatamente visíveis.
9.1.350
  • ToolCallComponent.appendSubToolLiveOutput incorpora os chunks de stdout e stderr imediatamente no estado de atividade, mas reconstrói o cartão do subagente apenas no ritmo de streaming adaptativo.
  • Um conjunto pending comum trata vários subtools em execução simultânea sem saída perdida ou um temporizador por chunk.
  • A conclusão da ferramenta remove o seu refresh aberto antes da representação final; dispose descarta o temporizador e o conjunto pending de forma limpa.
9.1.349
  • ToolCallComponent.appendSubagentText recolhe imediatamente no estado interno os fragmentos de texto e de thinking que chegam rapidamente, mas reconstrói o cartão do subagente apenas no ritmo de streaming adaptativo.
  • A conclusão e o estado de erro esvaziam um refresh de texto ainda aberto antes da representação final; dispose descarta o temporizador de forma limpa.
  • Assim, os bytes que chegam permanecem imediatamente disponíveis, enquanto as reconstruções completas repetidas, os snapshots e as renderizações em rajadas de fragmentos deixam de ocorrer.
9.1.348
  • Os argumentos crescentes de subagentes/ferramentas secundárias continuam a ser recolhidos imediatamente e na íntegra, mas deixam de ser novamente analisados e renderizados após cada fragmento individual.
  • Um temporizador adaptativo agrupa a atualização da pré-visualização. Na conclusão, os argumentos pendentes são introduzidos obrigatoriamente antes do estado final da ferramenta.
  • A execução de ferramentas, as autorizações, os argumentos finais e o caminho de streaming normal existente permanecem inalterados.
9.1.347
  • O caminho de eventos chamava getStreamingToolCallPreview imediatamente após cada delta de argumento de ferramenta recebido. Esta função analisa o texto JSON crescente, completo até esse momento.
  • A chamada também ocorria para ferramentas normais, embora apenas AgentSwarm precise do estado intermédio analisado imediatamente para a sua indicação de progresso em curso. Assim, o caminho normal contornava parcialmente a cadência de pré-visualização limitada introduzida em 9.1.346.
  • Uma pequena policy pura decide agora antes da análise: as ferramentas normais recolhem apenas o delta e analisam no flush de pré-visualização planeado; AgentSwarm continua a analisar imediatamente quando o nome do evento, o nome da ferramenta ativa ou um progresso de enxame existente estiver presente.
  • A execução de ferramentas, as autorizações, os argumentos finais e a indicação de enxame permanecem inalterados.
9.1.346
  • 9.1.345 limitou as novas renderizações de texto integral para streams longos de resposta e de thinking; os streams puros de argumentos de ferramentas, porém, não tinham nenhum destes dois rascunhos de texto e permaneciam, por isso, em 50 ms fixos.
  • Cada pré-visualização de ferramenta analisa o texto JSON de argumentos crescente, completo até esse momento. Chamadas de ferramentas grandes podiam, portanto, continuar a analisar e renderizar a carga útil completa com muita frequência.
  • A cadência adaptativa já comprovada tem agora em conta também o número total de caracteres dos argumentos de ferramenta ativos em streaming: 50, 100, 250 ou 500 ms de acordo com os mesmos limites.
  • A execução de ferramentas, os argumentos, as autorizações, a pré-visualização final e os flushes imediatos de conclusão permanecem inalterados.
9.1.345
  • Até agora, a TUI reconstruía em streaming a cada 50 ms o texto de resposta e de thinking integral acumulado até ao momento. Em respostas de modelo longas, a quantidade de texto a renderizar repetidamente crescia assim fortemente.
  • Streams curtos até 8.192 caracteres mantêm a cadência reativa anterior de 50-ms. Depois, o intervalo aumenta por etapas para 100 ms até 32.768, 250 ms até 131.072 e 500 ms acima disso.
  • Os flushes explícitos nas fronteiras de ferramentas e na finalização permanecem imediatos. A lógica de provider, fila, sessão e tokens não foi alterada.
9.1.344
  • Até agora, a camada cognitiva de tempo de execução escrevia policy e resultado em duas transações SQLite síncronas separadas para cada chamada de ferramenta.
  • Uma execução de teste de custos isolada no Windows com 100 chamadas de ferramentas necessitou de 627,63 ms e gerou 201 eventos. O conteúdo compreendia 305 observações.
  • Os pares concluídos de policy/resultado de um passo de modelo são agora confirmados atomicamente em grupos limitados de, no máximo, dez ferramentas. As verificações de policy abortadas ou ainda abertas continuam a ser guardadas individualmente no fim do turno.
  • Os argumentos, as saídas, a decisão de direitos, a cadeia de hash e a persistência SQLite permanecem inalterados.
9.1.343
  • Uma resposta privada do Telegram foi já entregue com sucesso através da ferramenta de reply. Depois disso, o mesmo turno de modelo iniciou ainda outro passo e gerou texto interno de estado e de controlo de trabalho.
  • Na sessão real medida, o passo adicional custou 42.360 tokens de entrada e 411 tokens de saída, embora a resposta visível ao utilizador já tivesse sido enviada.
  • Um reply do Telegram bem-sucedido termina agora imediatamente um turno de conversa privado marcado como direct. Replies falhados, grupos e outras ferramentas continuam a funcionar inalterados.
  • Após a conclusão, continua a aplicar-se o controlador de foco direct existente: ele regista a resposta entregue e regressa ao trabalho de fundo guardado após o fim da conversa ou o período de repouso.
9.1.342
  • A consulta de relevância para Mistake.md aceitava até agora cada mensagem com o papel user. Isso incluía também injeções internas, resumos de compactação, ativações de skills e mensagens de fundo.
  • Como o próprio lembrete de Mistake é guardado como mensagem interna user, alterava a sua própria consulta de pesquisa após cada passo de ferramenta. Assim, era novamente selecionado e injetado no mesmo turno.
  • O filtro utiliza agora apenas entradas de utilizador e de cron relevantes para a ação. Os textos internos de tempo de execução são excluídos da consulta de relevância e da deteção de baixa informação.
  • Mensagens reais de utilizador, trabalho planeado, todas as lições verificadas e a reconstrução após a compactação permanecem disponíveis inalterados.
9.1.341
  • No arranque natural, o launcher encontrou um runtime automático já preparado e verificado localmente, mas enviou-o mesmo assim primeiro através do aviso de atualização dependente da rede. Se esta segunda chamada falhasse temporariamente, voltava a iniciar a antiga versão global.
  • Um runtime automático preparado com modo exatamente adequado (resume ou new) é agora iniciado antes da nova consulta de versões. A ativação permanece transacional: o runtime só é registado como ativo quando o novo Core tiver sido carregado com sucesso.
  • Em resume, o ID da sessão e o diretório de trabalho permanecem. A seleção manual de atualização continua a passar pelo caminho de aviso anterior.
  • Nenhum King em execução é terminado. A correção atua exclusivamente no próximo arranque natural.
9.1.340
  • O launcher escrevia atualizações bem-sucedidas em .blun/updates/install.json, enquanto um runtime de perfil procurava em .blun/profile/<name>/updates/install.json. O caminho real do perfil não existia; por isso, notifiedAt permanecia null no estado partilhado.
  • Os runtimes de perfil leem agora o sucesso da atualização a partir de BLUN_SHARED_HOME e só recorrem ao BLUN_HOME anterior quando não existe caminho partilhado.
  • Após o próximo arranque natural, a TUI pode apresentar uma vez a versão e até três avisos de versão. Os destinatários privados do Telegram configurados recebem o mesmo texto curto, sem turno de modelo e sem consumo de tokens.
  • Instalação, staging, ativação e a regra de nunca descartar permanecem inalterados.
9.1.339
  • Os passos de seguimento de ferramentas bem-sucedidos com low-effort utilizam, no máximo, 4.096 tokens de completion em vez dos 8.192 anteriores.
  • Os primeiros passos, tarefas complexas e passos de seguimento de erros mantêm a sua capacidade configurada de raciocínio e de saída. A intervenção não é um limite global de modelo ou de contexto.
  • A medição de retorno sobre 1.442 passos reais de low-effort de um perfil de agente resultou em: 2.118.588 tokens de saída no total, mediana 791, p90 3.754, p95 5.485. Com o novo limite, 229.761 tokens teriam deixado de ser gastos, ou seja, 10,8 Prozent; 91,1 Prozent dos passos medidos permanecem inalterados.
9.1.338
  • Perguntas de repetição puras, como Posso continuar com o meu trabalho?, deixam de ser entregues em conversas privadas do Telegram.
  • A narração interna de queue, handoff, lane e estado de espera permanece fora da resposta privada. Resultados de trabalho reais e respostas pessoais normais continuam a poder ser entregues.
  • Se uma resposta utilizável terminar apenas com uma nova pergunta de autorização de trabalho, é removida exclusivamente essa pergunta final.
  • O encaminhamento de grupos e as sessões em execução permanecem inalterados.
9.1.337
  • profile/<name>/SOUL.md é o caminho de identidade canónico de um King.
  • Uma alma legada com nome correspondente substitui apenas um esqueleto de perfil gerado e inalterado. As almas de perfil desenvolvidas nunca são sobrescritas.
  • Antes de uma importação legada, o esqueleto gerado é guardado como SOUL.md.pre-legacy-import.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • As sessões interrompidas normalizam o seu estado de replay antes de mais trabalho do Telegram ser entregue.
  • Se a entrega a um turno ativo for recusada, a mensagem recai num turno de queue novo, em vez de voltar a tentar o mesmo steer a cada cinco segundos.
  • Os checkpoints de foco DM mantêm temporizadores de resume automáticos e pausas explícitas ao longo das atualizações.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Uma mensagem privada normal do Telegram interrompe a tarefa em curso apenas para a conversa imediata. Depois, o King continua automaticamente o estado de trabalho exatamente guardado após 60 segundos, sem nova pergunta de autorização.
  • Um fim de conversa explícito continua a tarefa imediatamente. Apenas pedidos claros do utilizador, como pause, pausiere, stop, stopp, warte ou halte an, mantêm a tarefa suspensa até o utilizador a autorizar novamente.
  • Termos internos e relatórios de estado sobre cron, checkpoint, queue ou lane são suprimidos em respostas privadas normais. O trabalho técnico e o seu estado guardado permanecem inalterados.
9.1.334
  • A preparação automática em segundo plano deixa de ficar bloqueada numa sucessão rápida de versões. O bloqueio anterior de 30 minutos referia-se sempre à versão mais recente; com versões publicadas minuto a minuto, nenhuma versão chegava, por isso, a ser suficientemente antiga para ser preparada.
  • Uma versão criptograficamente adequada é agora transferida imediatamente, verificada quanto à integridade, instalada isoladamente, sondada sintaticamente e marcada como runtime pendente.
  • A sessão King em execução continua a não ser terminada. A ativação e o resume permanecem exclusivamente no caminho protegido já existente do próximo arranque. Esta versão não altera nem a lógica de handoff nem a de sessão.
9.1.333
  • Um screenshot ao vivo comprovou, após 9.1.331, um ERR_MODULE_NOT_FOUND no plugin Telegram gerido.
  • A importação do plugin apontava, a partir da árvore managed isolada, para um ficheiro do núcleo que não tinha sido instalado ali.
  • O texto de repetição gigante, igualmente medido, corria no fluxo de raciocínio visível. O bloqueio de repetição live existente verificava até então apenas os deltas de resposta.
  • 9.1.332 não foi colocado no manifesto público após o achado do plugin. 9.1.333 substitui completamente este candidato npm.
9.1.332 Não publicada
  • Não publicada. Uma importação de plugin apontava, a partir da árvore isolada, para um ficheiro do núcleo não fornecido; 9.1.333 substituiu completamente o candidato npm.
9.1.331
  • As conversas privadas do Telegram mantêm respostas naturais e resultados de trabalho solicitados.
  • Duplicados internos medidos sobre trabalhos em pausa, respostas já enviadas, turnos em curso, estado de ferramentas e ausência de necessidade de ação são suprimidos apenas em chats privados.
  • Uma mensagem só é filtrada se contiver tanto contexto interno de tempo de execução como, expressamente, nenhum valor novo para o utilizador.
  • O encaminhamento de grupos, os relatórios reais de conclusão e a conversa curta normal permanecem inalterados.
9.1.330
  • O ficheiro-fonte completo da soul de cada King permanece inalterado.
  • O contexto do modelo recebe a partir dele uma projeção de caráter limitada, com identidade, voz, valores, relações, preferências, objetivos e história construída ao longo do tempo.
  • Secções claras de tarefa, lane, direitos, QA, ferramentas, comandos, verificação, incidentes, registos, runtime, atualizações, deploy e build deixam de ser carregadas como personalidade em cada prompt.
  • Souls de caráter curtas e puras permanecem idênticas byte a byte. Secções não técnicas desconhecidas permanecem visíveis na sua ordem.
  • Nenhum ficheiro de soul é eliminado, encurtado ou reescrito automaticamente.
9.1.329
  • Cada perfil de King nomeado utiliza o seu próprio nó de agente no núcleo de identidade partilhado. Relações, histórico e dados pessoais aprendidos deixam de colapsar no agente configurado em primeiro lugar.
  • Os ficheiros de soul nomeados existentes, como _agent-a_soul.md, _agent-b_soul.md ou _agent-c_soul.md, são atribuídos ao perfil adequado e copiados uma única vez, byte a byte, para SOUL.md.
  • O antigo ficheiro-fonte permanece inalterado. Uma SOUL.md de perfil existente nunca é sobrescrita.
  • A seleção de persona e o modo de personalidade fazem a leitura vinculada ao perfil. Uma persona de perfil danificada, demasiado grande ou ligada por link não recai, sem que se note, na identidade de outro agente.
  • O núcleo partilhado permanece utilizável sem obrigação de Mnemo. Tarefas em curso, direitos e regras de QA não são alterados por esta migração.
9.1.328
  • A persona e a SOUL.md são carregadas primeiro a partir do perfil ativo.
  • Os perfis nomeados nunca herdam a alma de outro agente do home partilhado.
  • Os perfis legados e predefinidos mantêm o fallback partilhado anterior.
  • Se faltar realmente um ficheiro de soul próprio, é criado uma vez um esqueleto mínimo; os ficheiros existentes nunca são sobrescritos.
  • O sistema de identidade e relações permanece baseado em ficheiros e funciona sem obrigação de Mnemo.
9.1.327
  • As conversas privadas do Telegram centram-se na pessoa: relatórios internos de queue, checkpoint, pausa, cron, hook e inatividade são suprimidos em ambas as vias de envio, enquanto nenhum estado de trabalho for solicitado, nenhuma decisão for necessária e nenhum bloqueio relevante tiver surgido.
  • Os estados de trabalho técnicos vão para o canal de equipa competente. Não são copiados novamente para a conversa privada.
  • Ciclos exatos de repetição de modelo são reconhecidos já durante o streaming. O stream do provider em curso é terminado e o mesmo passo é tentado novamente exatamente uma vez, com o contexto de tarefa preservado.
  • Alma, conhecimento de pessoas, direitos, tarefas em curso e a pausa de foco direto existente não foram substituídos nem eliminados. Nenhuma TUI em execução foi reiniciada.
9.1.326
  • Os modos de permissão manual e automático espelham as autorizações de ferramentas como botões limitados no DM privado do Telegram acoplado de forma inequívoca.
  • Apenas o nome da ferramenta e os textos de seleção existentes são transmitidos; argumentos, descrições e segredos permanecem locais. Autorizações expiradas, alheias ou já respondidas localmente são rejeitadas, em fail-closed.
  • O modo God permanece totalmente autónomo e não gera nenhuma autorização do Telegram.
  • Os estados de trabalho técnicos são encaminhados para o colega competente e deixam de ser copiados de volta para a conversa privada do utilizador.
9.1.325
  • O modo God executa escritas pessoais de memória sem uma segunda pergunta de autorização; o consentimento existente, vinculado à sessão e ao turno, permanece.
  • Uma instrução expressa do Telegram para memorizar ativa o mesmo consentimento estritamente limitado que uma instrução direta na consola. Os modos de permissão manual e automático continuam a perguntar antes de escrever.
  • O diário de atualizações guarda se uma instalação foi iniciada manualmente, automaticamente ou através do diálogo de arranque.
9.1.324
  • A primeira interação de confiança com um bot cria-o localmente como nó de agente e de relação. Papel, responsabilidades, particularidades, colaboração e handoff podem depois crescer de forma estruturada.
  • Cada King projeta um recorte compacto de colega no seu contexto. Assim, ele conhece tarefas e particularidades de outros agentes, sem carregar indiscriminadamente todo o acervo de relações.
  • Se faltar uma informação crítica para a tarefa, não se adivinha: o King pergunta exatamente uma vez à pessoa ou ao agente mais adequado. Se não for conhecida nenhuma responsabilidade, pergunta ao utilizador em vez de inventar um nome.
  • Relações e papéis nunca criam direitos. Campos de permissão, ACL e segredos não são projetados no recorte de colega. O caminho é local, vinculado ao tenant, neutro em nomes, independente de Mnemo e não acrescenta chamadas de modelo nem de ferramentas.
9.1.323
  • As conversas privadas voltam a responder à pessoa em vez de emitirem voluntariamente dados de processo internos. Checkpoints, hashes, caminhos, diagnósticos de ferramentas, cron e hooks, regras ocultas, tarefas de outros agentes e relatórios de inatividade permanecem internos.
  • O estado do trabalho só é mencionado quando o utilizador pergunta por ele, a sua decisão é necessária ou um bloqueio o afeta concretamente. O trabalho em pausa permanece interno e não é levado para uma conversa informal.
  • A regra vale com e sem modo de personalidade, não contém pessoas nem agentes codificados de forma fixa e acrescenta cerca de 75 tokens de prompt, mas nenhuma chamada de modelo ou de ferramentas. A prioridade de tarefas e o dever de comprovação permanecem inalterados.
9.1.322
  • O interruptor visível de personalidade escreve agora persona.json atomicamente. Nome, língua, notas e todos os outros campos de persona existentes permanecem; apenas personalityEnabled é alterado.
  • SOUL.md, AGENTS.md, JOURNAL.md e os ficheiros de relações não são escritos nem ao desligar nem ao ligar. A identidade de agente normal baseada em SOUL permanece carregada no contexto de sistema mesmo com a função de personalidade desligada.
  • Um refresh live falhado repõe a seleção exatamente byte a byte. Se, em paralelo, outro processo de escrita tiver alterado persona.json, a reversão aborta com PERSONALITY_CHOICE_CONFLICT e não sobrescreve nada.
  • Ficheiros de persona com symlinks, demasiado grandes, inválidos ou não-objeto são rejeitados, em fail-closed. Ao ligar, a árvore de identidade é preparada antes do commit.
  • Não faz parte desta versão o erro de um agente, comprovado depois, de emitir checkpoints internos, regras de cron, SHAs e detalhes de tarefas alheias em conversas privadas. Este filtro de saída é o próximo build separado.
9.1.321
  • Um primeiro intercâmbio privado descontraído ou uma indicação pessoal voluntária pode colocar exatamente uma oportunidade opcional de curiosidade no contexto do modelo. Não é uma pergunta obrigatória; a escolha de palavras e o tom continuam a vir da SOUL.md carregada, não de um catálogo fixo de perguntas.
  • Tarefa, urgência, erro, links, código, caminhos e tráfego de grupo suprimem a curiosidade em bloco. Ela nunca envia por iniciativa própria e não pode interromper o trabalho em curso.
  • Um cooldown de 30 dias aplica-se por tenant, agente e pessoa vinculada, também através de portais diferentes. A mesma nova tentativa de evento é idempotente.
  • O novo estado já não reside como ficheiro de curiosidade específico do Telegram na árvore de identidade. Um personality-memory-adapter permutável escreve em vez disso um evento versionado no store cognitivo transacional existente. O Telegram é a origem; a relação privada é um âmbito de visibilidade separado.
  • Só são guardados o tema, a identificação estável de evento/fonte, o momento e o âmbito privado. Texto bruto, perguntas fixas, alegações de direitos e segredos não são registados. Roots inseguros, campos alheios e falha do store permanecem bloqueados por predefinição (fail-closed).
  • A base para o limite do portal foi o documento de conceito interno v7. A CLI é o cliente de referência; o store local está expressamente assinalado como projeção permutável e não é um segundo armazenamento canónico do portal.
9.1.320
  • Fios de conversa privados, expressos e abertos são guardados como eventos imutáveis e deduplicados, com fonte, momento, contexto e confiança. Formulações naturais como Frag mich morgen noch einmal nach ... são reconhecidas tal como a forma explícita de open thread.
  • Indicações expressas de reparação são guardadas separadamente das notas de relação gerais e consideradas no comportamento posterior.
  • O turno atual não vê de propósito a sua própria nota nova. Apenas um turno privado posterior recebe o contexto limitado; assim, não há autoconfirmação dupla ou sugestiva.
  • A tarefa e as instruções explícitas estão acima do contexto social. Fios abertos não podem interromper o trabalho ativo e nunca enviam por iniciativa própria. Dados de relação não podem criar direitos, autorizações ou permissões.
  • Tráfego de grupo, segredos, formulações de permissão, caminhos inseguros, symlinks e ficheiros demasiado grandes permanecem excluídos, em fail-closed.
9.1.319
  • Um perfil existente válido sem valor guardado de personalityEnabled ativa agora a personalidade automaticamente.
  • No primeiro prompt normal, surge a árvore de identidade local com perfil de agente e JOURNAL.md, também sem Mnemo.
  • Um false, 0 ou off expresso permanece desligado. Ficheiros de persona danificados, ligados simbolicamente e demasiado grandes permanecem bloqueados por predefinição (fail-closed).
  • SOUL.md e AGENTS.md não são eliminados nem reescritos.
9.1.318
  • O atualizador de fundo carrega obrigatoriamente a versão mais recente, verifica a sua integridade SHA-512 publicada independentemente e marca-a para o próximo arranque.
  • O King em execução, o seu turno e as suas chamadas de ferramentas permanecem intocados. Já não há live handoff, nem ACK, nem tui.stop(76).
  • O ID da sessão e o diretório de trabalho são guardados com o runtime preparado. A nova versão só é ativada no próximo arranque natural e a sessão exata é então retomada automaticamente.
  • A TUI em execução recebe, no máximo, um relatório de conclusão passivo; uma versão preparada mais recente substitui apenas a marcação, nunca o processo ativo.
9.1.317
  • Se o provider consumir todo o orçamento de resposta com uma conclusão length, mas não fornecer texto visível, o orçamento de nova tentativa já não é reduzido para um oitavo, mas sim duplicado.
  • A nova tentativa permanece no mesmo turno e utiliza o mesmo sinal, o mesmo histórico de mensagens e a mesma situação de trabalho.
  • O tratamento de cancelamento existente e o número limitado de novas tentativas permanecem inalterados. Cancelamentos manuais ou resultados vazios de forma persistente não continuam infinitamente.
9.1.316
  • Os DMs privados do Telegram recebem uma pista de queue direta própria, antes do trabalho de grupos, loops e fundo; um /urgent explícito continua a ter a prioridade mais alta.
  • No início da conversa DM, o estado de trabalho em curso é guardado uma vez como checkpoint limitado. O texto da mensagem não é persistido.
  • Após um fim de conversa reconhecido ou um minuto de silêncio, King pergunta exatamente uma vez: Posso continuar com o meu trabalho?
  • O trabalho guardado permanece suspenso e só é retomado no checkpoint original após um consentimento inequívoco.
  • A versão introduz o controlo de entrega e de pausa. O sistema completo de personalidade, relações e diário permanece uma expansão separada e em curso.
9.1.315
  • Os sinais de atenção autorizados chegam agora ao turno através da queue de canal normal, sem contornar a política de entrega ou de direitos existente.
  • Sinais duplicados, desatualizados, não autorizados, fora do âmbito e não provenientes do Telegram são descartados antes do contexto do modelo.
  • As perguntas de retorno permanecem limitadas a, no máximo, uma pergunta natural, são deduplicadas e emudecem quando o sinal já não é atual.
  • A versão introduz apenas o caminho de entrega seguro. A lógica de interrupção e retoma DM, priorizada depois, permanece deliberadamente reservada para a próxima versão separada.
9.1.314
  • Os comandos slash locais já não esperam horas na queue durante um turno ativo longo, mas abortam o turno de forma controlada e correm como o próximo passo de trabalho.
  • Um novo comando slash substitui, na consola e no Telegram, um comando do mesmo tipo já em espera. Isso aplica-se, entre outros, a /reload e /loop; mensagens normais, trabalho de shell e outras tarefas de canal permanecem.
  • Escape remove comandos slash em espera mesmo quando já não está visível nenhum turno ativo. A compatibilidade de reload existente permanece como wrapper na política de queue geral.
9.1.313
  • Uma atualização automática bem-sucedida é escrita após o replay da sessão como aviso persistente na transcrição da TUI. A mensagem já não pode ser sobrescrita por replay ou por um estado de curta duração.
  • O mesmo estado de origem, estado de destino e as mesmas notas de versão são enviados uma vez, através do caminho existente deduplicado por versão, para os DMs do Telegram acoplados. Um envio falhado permanece repetível.
  • O manifesto público contém agora os campos name e releaseNotes, esperados pelo parser de fallback. No handoff do updater, no reinício da sessão e nos processos em execução, nada foi alterado.
9.1.312
  • Um /reload expresso do Telegram já não espera atrás de um turno de modelo longo. É colocado como comando de controlo à frente da queue existente e dispara exatamente uma vez a interrupção controlada de sessão existente.
  • O handler de reload existente corre apenas depois do fim confirmado do turno. Assim, não arranca nenhum segundo turno em paralelo e um turno a escrever não é processado a meio da lógica de reload.
  • Antigos duplicados de reload são removidos; mensagens normais do Telegram e outro trabalho de queue permanecem na sua ordem. A confirmação do Telegram permanece aberta até à execução efetiva do comando.
9.1.311
  • Um candidato de atenção só se torna uma tarefa de entrega limitada quando existir uma confirmação de runtime recente, vinculada exatamente ao seu ID de candidato.
  • Apenas runtime_user_prompt_hook e runtime_tool_policy contam como autoridades. Memória, agente errado, canal errado, âmbito errado, decisão de bloqueio, confirmação futura e confirmação com mais de cinco minutos falham em fail-closed.
  • As confirmações são vinculadas ao tenant, transacionais e utilizáveis apenas uma vez. A mesma nova tentativa é idempotente; a utilização da mesma confirmação para outro candidato é rejeitada como replay.
  • O cooldown partilhado existente permanece eficaz. O resultado é apenas um intent estruturado attention_notice e não contém texto de mensagem, função de envio nem permissão. A política de entrega efetiva permanece o próximo passo separado.
9.1.310
  • Objetivos persistentes, fios abertos, próximos gatilhos, comprovativos esperados, contexto de equipa e contexto próprio passam por uma projeção de foco comum e estritamente limitada. Por predefinição, são, no máximo, seis entradas e 900 caracteres.
  • As áreas de projeto e de trabalho têm mais peso do que a confiança e a atualidade. O valor mais recente é mostrado sem apagar observações anteriores contraditórias do histórico de eventos imutável. Alterações tornam-se visíveis como revised.
  • Observações de runtime de curta duração, evidência fraca e factos gerais do mundo não consomem orçamento de foco persistente. Campos de direitos, tokens e segredos são rejeitados já na escrita.
  • Um snapshot estruturado e idempotente pode avançar o foco entre sessões. A projeção é contexto, não permissão, e não pode sobrescrever nem a tarefa nem a política de runtime.
  • Do ECC foi adotado apenas o princípio Kontext begrenzen, Relevantes laden. Nenhum hook, armazenamento de aprendizagem ou harness ECC foi instalado.
9.1.309
  • A nova política pura de atenção cria um candidato limitado apenas a partir da ausência comprovada de heartbeats de agentes, promessas vencidas ou tarefas bloqueadas há mais tempo.
  • Responsabilidade, tarefa ativa, ausência comprovada, tempo de repouso local, canal permitido, confiança mínima e cooldown são verificados antes da aceitação. O silêncio humano sem promessa vencida permanece sem efeito.
  • Cada candidato transporta ID de evidência, âmbito, momento e confiança, mas nem conteúdo de prompt, nem direitos, segredos ou função de envio.
  • O núcleo SQLite partilhado atribui um claim transacional por tenant e evidência. Agentes paralelos não podem assumir duas vezes o mesmo motivo no cooldown.
  • Esta versão ainda não faz scans por iniciativa própria e não envia nenhuma mensagem. Cada ação posterior continua a precisar da autorização normal do runtime.
9.1.308
  • O registo de runtime preparado contém agora, no modo resume, o ID da sessão exatamente em execução e o diretório de trabalho verificado canonicamente. Um arranque posterior já não precisa, por isso, de adivinhar uma sessão mais recente ou presumivelmente adequada.
  • Cada mudança real de sessão atualiza estes dados. Imediatamente antes do handoff seguro, são escritos novamente, antes de o antigo runtime receber a confirmação para terminar.
  • Apenas a sessão exatamente igual, comprovadamente retomada através deste caminho de atualização, recebe após o replay um impulso único de continuação, e apenas se o seu objetivo continuar active. Arranques normais, outras sessões e objetivos em pausa ou bloqueados permanecem intocados.
  • A fronteira segura de trabalho permanece inalterada: sem handoff durante streaming, compactação, ferramentas, comandos de shell ou mensagens em espera. Nenhum King em execução foi reiniciado manualmente para esta versão.
9.1.307
  • Apenas um erro realmente relevante para a ação, do turno de runtime imediatamente anterior, é apresentado como comprovativo curto de continuidade antes da próxima decisão de modelo: turno cancelado/falhado, policy bloqueada ou ferramenta falhada.
  • Um turno concluído normalmente não gera exatamente nenhuma projeção e, com isso, zero tokens de contexto adicionais.
  • A seleção está vinculada ao ID de runtime e ao ID de turno e permanece, por isso, correta também após uma mudança de sessão com IDs de turno que recomeçam em zero.
  • A projeção não contém prompts, argumentos, saídas, IDs de chamada nem direitos. Ela indica explicitamente que nunca pode autorizar uma ação nem sobrescrever a policy atual de utilizador/ferramentas.
  • A etapa é deliberadamente reativa e estreita. Atenção proativa, estado de delegação e fios abertos de conteúdo ainda não são carregados aqui.
9.1.306
  • A pista cognitiva de ciclo de vida de turno regista agora, para cada chamada real de ferramenta, a decisão efetiva do runtime a partir de PermissionManager.beforeToolCall: passed, blocked ou error.
  • Após a execução, são anexados como comprovativo imutável o resultado real (success, error, cancelled), o tempo de execução e o próximo gatilho de verificação.
  • Só são guardados o nome da ferramenta e um hash estável da chave da chamada. Argumentos, saídas de ferramentas e conteúdos de prompt não entram no estado cognitivo.
  • A hierarquia de direitos existente permanece inalterada: a memória não pode autorizar nenhuma ação. Erros de registo permanecem fail-soft e não podem nem permitir uma execução de ferramenta nem bloquear um turno de utilizador.
  • Continuam em aberto os comprovativos de delegação, a atenção proativa e a retroprojeção estritamente relevante do estado em decisões posteriores.
9.1.305
  • O núcleo SQLite transacional incluído na 9.1.304 está agora ligado ao ciclo de vida real runOneTurn(). Cada turno de modelo regista perceção, classificação de origem, plano de turno limitado, comprovativo final esperado, resultado do controlo de prompt, motivo de conclusão, tempo de execução e próximo gatilho.
  • Só são guardados metadados de runtime, não conteúdos de prompt. Tenant e agente são derivados de forma estável do BLUN-Home e do perfil ativo, sem listas fixas de pessoas.
  • Apenas a policy de runtime existente pode fornecer um resultado de controlo. A memória está estritamente excluída como autoridade de direitos. O registo nunca devolve uma permissão e continua a não possuir função de execução.
  • A pista de aprendizagem é fail-soft: um erro de SQLite/ciclo de vida é registado apenas como telemetria sem conteúdo e não pode bloquear o turno real de utilizador.
  • Continuam em aberto os comprovativos de ação/delegação específicos de ferramentas, a atenção proativa e a retroprojeção relevante do estado em decisões posteriores. 9.1.305 não afirma, por isso, nenhum ciclo AGI completo.
9.1.304
  • O primeiro núcleo transacional de estado cognitivo reside como base de dados SQLite local sob o BLUN-Home. Pode guardar observações próprias, do mundo e de equipa, objetivos, fios abertos, pressupostos, próximos gatilhos e comprovativos esperados ao longo de sessões.
  • Vários processos de escrita de agente/canal são serializados com BEGIN IMMEDIATE e número de versão otimista. Processos de escrita desatualizados falham em fail-closed; repetições idênticas de eventos são idempotentes.
  • Cada evento está encadeado por SHA-256. As afirmações transportam fonte, contexto, momento, grau de certeza e âmbito. Contradições permanecem observações imutáveis separadas, em vez de sobrescreverem afirmações antigas.
  • Campos em forma de direitos, capabilities e segredos são rejeitados. O núcleo não possui função de execução, delegação ou permissão.
  • Esta é a base de armazenamento comprovada, ainda não o ciclo completo percecionar-planear-agir e ainda não ligada a cada turno.
9.1.303
  • Um candidato de relação privado registado com segurança em 9.1.302 é carregado a partir da próxima conversa direta como contexto de recordação claramente não autoritativo. A afirmação atual continua a não influenciar o seu próprio turno.
  • São carregadas, no máximo, as duas notas validadas mais recentes, cada uma com, no máximo, 160 caracteres, dentro do orçamento total inalterado de 1.500 caracteres. Sem notas existentes, surgem 0 caracteres de prompt adicionais e nenhuma chamada de modelo, embedding ou rede.
  • Notas privadas nunca são carregadas em grupos. A fronteira do sistema chama-lhes expressamente dados de referência, em vez de instruções, e repete que não podem conceder nem alterar direitos.
  • Continuam em aberto a incorporação automática e persistente, a avaliação de conflitos, o armazenamento transacional de vários agentes e a atenção proativa.
9.1.302
  • Uma afirmação privada expressa, como Bitte merk dir: ... ou Please remember that ..., cria agora um pequeno candidato de relação ainda não ativo. Para isso, não há nenhuma chamada adicional de modelo, embedding ou rede.
  • Cada candidato transporta fonte, contexto de canal/direto, momento, grau de certeza, âmbito e a regra imutável de histórico. O mesmo processo de canal entregue é idempotente; confirmações e contradições posteriores permanecem visíveis como entradas separadas e não se sobrescrevem.
  • Grupos, frases de conversa normais, segredos, afirmações de direitos e de autorização, identidades de tenant/agente inválidas e caminhos inseguros são rejeitados. Dados de relação continuam a não poder criar direitos nenhuns.
  • Este é apenas o primeiro passo seguro de registo para o objetivo do produto. Os candidatos permanecem pending e ainda não são incorporados automaticamente na relação ativa nem no contexto do modelo. O núcleo transacional de vários agentes, o estado cognitivo, a iniciativa própria e a atenção proativa ainda não estão, por isso, expressamente concluídos.
9.1.301
  • O bloco de presença de personalidade carregado de forma persistente baixou de 1.433 para 1.020 caracteres, aritmeticamente cerca de 104 tokens de prompt a menos por turno de personalidade ativo. Nenhuma outra chamada de modelo ou de memória foi acrescentada.
  • Foco de tarefas, alma carregada, curiosidade limitada, proteção de grupo, recordação incerta, fios abertos e reparação de relações permanecem no bloco pequeno. O modo sem personalidade permaneceu idêntico byte a byte, com 288 caracteres.
  • Execução de teste a vermelho: o novo controlo de 1 050 caracteres falhou com 1 433 caracteres. Execução de teste de mutação sem bloco de personalidade: 12/18 testes direcionados vermelhos. Restaurado: direcionados 18/18, suíte total 690/690 verde.
  • Controlo de regressão de pacote 9.1.300 para 9.1.301: 164 contra 164 caminhos estáveis, 0 removidos. Instalação limpa: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Um servidor MCP que falhou no arranque recebe agora até três tentativas adicionais de ligação, com intervalos de dez segundos cada. Um erro de arranque temporário deixa assim de ser abandonado após apenas uma tentativa.
  • O inventário MCP já não é registado apenas uma vez, mas novamente quando o número de servidores ou ferramentas ligados muda. Uma recuperação tardia substitui assim visivelmente o antigo estado 0/0.
  • As configurações MCP existentes, as definições de ferramentas e as sessões em execução permanecem inalteradas. Foram ajustados blun.mjs, test/mcp-runtime-resilience.test.js, package.json e package-lock.json.
9.1.299
  • Os resultados grandes de Read permanecem nativamente legíveis: a saída visível está limitada a 10 KiB e indica depois a linha exata seguinte, em vez de mostrar apenas [offloaded].
  • Os grandes pedidos plain-Write e os ficheiros-fonte com mais de 500 linhas são automaticamente divididos em fragmentos exatos em bytes, compostos num ficheiro privado vizinho e escritos atomicamente no caminho de destino.
  • Após a composição, o runtime verifica os bytes persistidos por SHA256. A proteção existente do Edit permanece inalterada; a continuação manual continua possível, mas já não é necessária para grandes escritas completas.
  • Novo: bin/native-large-file-io.cjs. Ajustados: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, quatro ficheiros de teste focados, bem como package.json e package-lock.json.
9.1.298
  • O modo de personalidade ativado cria, no primeiro turno TUI normal, uma área de identidade local apta para tenants, por iniciativa própria. Para isso, não é necessário Mnemo.
  • A SOUL.md e a AGENTS.md existentes permanecem carregadas e inalteradas. Um novo JOURNAL.md surge apenas uma vez e não substitui nem a alma nem as regras.
  • Novas identidades do Telegram recebem nós cautelosos de pessoa, relação e grupo, sem propriedades inventadas. Histórico privado e contexto de grupo permanecem separados.
  • A continuidade direta de relação guarda, no máximo, seis entradas curtas, redigidas localmente, e entrega, no máximo, dois excertos anteriores ao turno atual. O texto atual não é injetado duas vezes.
  • A camada social de atenção reconhece exclusivamente uma distância comprovada de retorno direto a partir de sete dias, gera, no máximo, um aviso no cooldown de 30 dias e não envia ela própria nenhuma mensagem.
  • A tarefa atual e as instruções expressas estão no contexto sempre antes da curiosidade, da relação e da atenção. Todo o bloco dinâmico de identidade permanece, por norma, limitado a 1 500 caracteres.
  • As correções de novas tentativas MCP e de queue de reload publicadas em 9.1.296 e 9.1.297 estão incluídas no candidato.
9.1.297
  • Em dois agentes, um antigo pedido de /reload permanecia visível na queue após Escape. Um segundo /reload podia correr, mas a primeira entrada não era nem removida nem confirmada para impedir nova entrega pelo Telegram.
  • A nova policy remove exclusivamente comandos de reload locais e do Telegram. Mantém a identidade e a ordem da queue existente, bem como todas as outras mensagens e comandos.
  • Escape antes do cancelamento do trabalho ativo e cada novo /reload recebido chamam o mesmo caminho de limpeza. As entradas do Telegram removidas são confirmadas através do seu callback de acknowledge existente.
9.1.296
  • Uma execução real de resume em 9.1.294 comunicou a 27 de agosto, às 14:26:17Z exatamente um erro de arranque silencioso para windows-mcp: Timed out after 30000ms. Nos minutos seguintes, não apareceu nem uma segunda tentativa de arranque nem um comprovativo final de nova tentativa.
  • O arranque direto do mesmo uvx windows-mcp serve respondeu, ao contrário, após cerca de 3,7 segundos a initialize. Instalação e servidor estavam, portanto, fundamentalmente funcionais; a lacuna estava na repetição do arranque MCP do King.
  • blun.mjs mantém agora, após um primeiro erro de arranque MCP, exatamente uma tentativa de repetição após 10 000 ms. O temporizador permanece referenciado até a segunda tentativa ter sido executada. Não há reinício de processo nem de sessão.
  • Se também a segunda tentativa falhar, permanece o estado final honesto existente unavailable. Outros servidores MCP e a TUI continuam a funcionar.
9.1.295
  • O runtime de tarefas em segundo plano registava, para cada execução, um listener num AbortSignal externo, mas não o removia após um resultado normal de worker, timeout ou stop. Sessões longas de agentes podiam, assim, acumular listeners de cancelamento desatualizados.
  • bin/abort-listener-policy.cjs fornece agora a saída de cancelamento juntamente com uma função idempotente cleanup(). blun.mjs chama-a no caminho finally existente, em conjunto com a limpeza de timeout.
  • Comportamento de cancelamento, escolha de resultado e semântica visível de tarefas permanecem inalterados. A intervenção não gera chamadas de modelo nem novos tokens de contexto.
9.1.294
  • Tentativas reais de atualização de dois perfis de agente comprovaram o mesmo percurso: a primeira chamada terminou com um fetch failed temporário, a segunda chamada imediatamente seguinte funcionou. Ambas as fontes oficiais tinham até agora apenas uma única tentativa de rede.
  • O registo e o manifesto público recebem agora, cada um, um orçamento próprio e limitado de novas tentativas, com backoff de 250 e 750 milissegundos.
  • Só são repetidos os timeouts, erros de transporte temporários conhecidos, bem como HTTP 408, 425, 429 e erros de servidor a partir de 500.
  • JSON inválido, respostas demasiado grandes, endpoints não permitidos e erros de cliente persistentes, como 404, permanecem imediatamente vermelhos. Não surgem chamadas de modelo, tokens de contexto nem loops de fundo persistentes.
9.1.293
  • O atualizador de fundo preparava corretamente um alvo verificado, mas enviava depois ainda RUNNING_UPDATE_PREPARED_MESSAGE ao runtime ativo do Core. Uma TUI em execução podia reagir a isso numa fronteira presumivelmente segura com Exit 76. Isso contradizia o contrato de produto de 9.1.222: as atualizações nunca podem terminar uma sessão ativa e só são ativadas no próximo arranque natural.
  • bin/launcher-runtime.js continua a executar, sem alterações, o download, a verificação de integridade, o staging, a atualização do alvo e a limpeza, mas, durante a preparação, já não escreve nenhuma mensagem IPC na sessão em execução.
  • As funções diretas de handoff existentes permanecem disponíveis por compatibilidade; o caminho automático de fundo já não as aciona.
9.1.292
  • Uma sessão real corria em 9.1.279 e tinha preparado 9.1.287 com o evento prepared-for-next-start, mas não trouxe depois nenhuma das versões já publicadas 9.1.288 a 9.1.291.
  • A causa estava em superviseProtectedCore(): após o primeiro staging bem-sucedido, updateStarted permanecia definido e scheduleNextPreparation() abortava adicionalmente assim que preparedTarget existia. O poller de fundo era assim terminado de forma persistente após o primeiro acerto.
  • O poller permanece agora ativo também com alvo preparado. Apenas uma semver estritamente mais nova e válida substitui o alvo preparado; alvos iguais, mais antigos ou não comparáveis de forma válida são ignorados.
  • Um refresh de alvo não envia de propósito um segundo IPC de prepared à TUI em execução. Assim, o processo atual permanece intocado e a versão preparada mais recente só é ativada no próximo arranque natural.
  • Assim que um handoff é confirmado ou o runtime do Core supervisionado termina, já não é trocado nenhum alvo nem criado nenhum novo temporizador.
9.1.291
  • O caminho bloqueante de compactação registava em cada sinal ainda não cancelado um listener anónimo de abort, mas não o removia após a conclusão da compactação. Em sessões longas, podiam assim acumular-se listeners de cancelamento mortos.
  • FullCompaction.block() utiliza agora um listener nomeado e o pequeno helper waitForAbortableCompletion(). O helper remove o listener em finally, após sucesso, erro ou cancelamento.
  • Um sinal já cancelado é tratado imediatamente, sem registar um listener. A intervenção não altera nem a decisão de cancelamento nem a lógica de compactação fora deste ciclo de vida.
  • O padrão provém da comparação atual com o AnythingLLM; foi adotada apenas a limpeza de listener comprovada individualmente, e nenhum runtime de terceiros.
9.1.290
  • BLUN mostrava até agora com /context apenas as somas aproximadas da janela de contexto. Os verdadeiros impulsionadores de custo dentro do contexto de sistema e dos esquemas de ferramentas permaneciam invisíveis.
  • O novo comando local /context-doctor decompõe o contexto atual, sem chamada de modelo, em instruções de núcleo, personalidade e alma, relações e presença, índice de capacidades, complementos de runtime, ferramentas integradas, ferramentas de utilizador, ferramentas MCP, outros esquemas de ferramentas, conversa e esforço adicional do fornecedor.
  • Todas as subcategorias são comparadas com a sua soma-mãe medida. Estimativas sobrepostas ou desatualizadas não podem, por isso, aumentar artificialmente a indicação.
  • A interface está totalmente localizada para inglês, alemão, espanhol, francês, sueco e checo. Todas as cinco traduções foram aprovadas antes da integração através do controlo linguístico obrigatório e posteriormente reverificadas criptograficamente.
  • O comando lê exclusivamente o contexto local da sessão. Não chama nem o modelo, nem a gestão de consumo, nem uma rede externa.
9.1.289
  • O comprovativo do hub live após 9.1.288 mostrava um perfil de agente ainda offline. A sua configuração de perfil efetiva continha o MCP Mnemo com MNEMO_AGENT=<Profilname>, mas nenhum URL de hub no processo King. O heartbeat 9.1.288 permaneceu, por isso, deliberadamente ausente, apesar da identidade interna existente.
  • O launcher reencaminha agora o ficheiro de perfil ativo mcp.json para o heartbeat. Apenas um bloco Mnemo ativado com uma identidade concreta MNEMO_AGENT ou BLUN_MNEMO_AGENT ativa o registo interno. Sem esta identidade, a função permanece completamente ausente.
  • O processo não gera chamadas de modelo, embeddings nem tokens de contexto. Perfis públicos de utilizador sem identidade interna de agente Mnemo permanecem separados do hub interno.
9.1.288
  • Um screenshot comprovou diretamente a causa MCP: windows-mcp e mnemo esgotaram no primeiro arranque o timeout de 30 segundos, enquanto um /reload posterior ligava todos os cinco servidores. O caminho do perfil estava correto; uma alteração do loader foi, por isso, descartada.
  • Arranques MCP falhados recebem agora exatamente duas tentativas de fundo não bloqueantes, após 1 e 3 segundos. A terceira tentativa global pode ligar sem prolongar o arranque da TUI. needs-auth, servidores desativados, reconexão manual e shutdown permanecem separados da automatização.
  • Com um hub Mnemo explicitamente configurado, os Kings internos podem registar-se no arranque com nome de perfil, host e PID e enviar um heartbeat a cada minuto. Sem URL de hub, a função permanece completamente ausente; não gera chamadas de modelo, embeddings nem tokens de contexto.
  • Escape não tratava até agora o estado curto queueSteerInFlight como trabalho em curso. Enquanto uma mensagem do Telegram era conduzida para o turno ativo, Escape podia, por isso, marcar Undo em vez de parar o turno. A condição de cancelamento existente reconhece agora também exatamente esta transição.
9.1.287
  • A pesquisa adiada de ToolSearch aceitava até agora o texto de pesquisa sem limite de tamanho. Um texto de pesquisa muito longo, gerado por erro, podia assim percorrer o catálogo de ferramentas e, depois, no resultado sem acertos, voltar a entrar no próximo passo de modelo.
  • O padrão derivado do commit d7353ae do AnythingLLM limita agora o texto, antes da pesquisa e da saída visível, a 1 000 caracteres. Se possível, termina numa fronteira de palavra; com uma única palavra demasiado longa, aplica-se o limite rígido.
  • Textos de pesquisa curtos normais, seleção de ferramentas e lógica de acertos permanecem inalterados. A proteção não acrescenta chamadas de modelo, nem embeddings, repetições ou trabalho de fundo.
9.1.286
  • O núcleo comunicava repetições controladas após erros de modelo temporários já como turn.step.retrying. A TUI descartava, porém, completamente este evento. Uma recuperação em curso parecia, por isso, um agente congelado.
  • 9.1.286 mostra durante isso, no aviso de rodapé existente, apenas a próxima tentativa e o tempo de espera limitado, por exemplo Retry 2/3 | 1.3s.
  • O texto de erro do provider, o código de estado e os caminhos locais não são apresentados. O aviso só é removido se ainda for o mesmo valor definido pela indicação de nova tentativa; avisos mais recentes de outras funções da TUI permanecem.
  • O número de novas tentativas, o backoff, as chamadas de modelo e o consumo de tokens permanecem inalterados.
9.1.285
  • O AnythingLLM conserva localmente rascunhos de prompt não enviados. A BLUN perdia o conteúdo do campo de entrada da TUI numa atualização, falha ou reinício controlado, embora esse texto ainda não fosse sequer contexto de modelo.
  • 9.1.285 guarda, por isso, exclusivamente o rascunho local não enviado. Não há chamada de modelo, rede, embedding ou Mnemo e, portanto, nenhum custo adicional de tokens.
  • O rascunho é separado por perfil e diretório de trabalho, é escrito apenas após 300 ms de repouso, é removido ao ser esvaziado e é restaurado no próximo arranque, antes do foco do editor.
  • O armazenamento está limitado a 64 KiB. Estados vazios, danificados, demasiado grandes ou baseados em symlinks são descartados, em fail-closed. O caminho de escrita utiliza um ficheiro temporário privado e renomeação atómica.
9.1.284
  • A versão DeepAgents 37d7777 devolve os custos de subagentes dinâmicos à utilização total visível. A BLUN comunicava a utilização cumulada de um subagente no evento de conclusão, mas não a escrevia no registador de utilização da sessão-mãe.
  • Assim, /usage podia omitir trabalho de subagentes. Somar simplesmente o valor de conclusão também seria errado: continuação e repetição utilizam o mesmo subagente com contadores cumulados e teriam calculado novamente utilização antiga.
  • 9.1.284 calcula, por isso, para spawn, continuação e repetição, exatamente a diferença entre o início e o fim da tentativa. A diferença é registada no caminho finally, para que também as tentativas falhadas contem.
  • Contadores repostos, não monotónicos ou inválidos são completamente descartados. Assim, não surgem valores de tokens negativos nem inventados.
  • Não há nenhuma chamada adicional de modelo, rede ou memória. A intervenção corrige exclusivamente a contabilização local existente.
9.1.283
  • O novo /context-doctor do DeepAgents torna visíveis os custos de instruções de base, recordação, ferramentas e histórico como componentes separados.
  • O /context da BLUN mostrava já histórico e ferramentas, mas não o prompt de sistema. Ao mesmo tempo, o travão de contexto estimava, sem override explícito de turno, apenas config.systemPrompt, enquanto a chamada real de modelo utiliza effectiveSystemPrompt. Nele estão também os contextos de conta e de recordação anexados em tempo de execução.
  • Assim, o travão podia subestimar exatamente o contexto crítico em tokens para a identidade pessoal de agente planeada.
  • 9.1.283 conta agora o mesmo prompt de sistema efetivo que o modelo recebe e mostra a sua estimativa no painel /context como linha própria de sistema. Não é introduzida nenhuma chamada adicional de modelo, rede ou memória.
  • Não é afirmada nenhuma poupança concreta de tokens: a intervenção corrige a medição e a decisão do travão e torna visíveis os futuros custos de identidade.
9.1.282
  • O DeepAgents encurta no seu changelog expressamente descrições de ferramentas visíveis ao LLM, para aliviar o contexto de modelo residente. Fonte medida: langchain-ai/deepagents, entrada #5009, commit 761f5f... em libs/deepagents/CHANGELOG.md.
  • A BLUN já tinha um texto read_default mais curto, mas só o integrava depois de READ_DESCRIPTION ter sido renderizado a partir dele. A otimização aparente não tinha, por isso, nenhum efeito no modelo.
  • 9.1.282 encurta o contrato sem perda de função e renderiza novamente a descrição efetiva imediatamente antes da construção da ferramenta Read. Paginação, regras de segurança, codificação e fins de linha permanecem expressamente preservados.
  • A descrição Read residente baixa de 1 648 para 1 035 caracteres: 613 caracteres, ou seja, cerca de 37,2 por cento. Isto é uma redução de contexto medida; não é afirmada nenhuma poupança exata de tokens.
9.1.281
  • O ECC descreve com /aside um caminho lateral expresso para uma pergunta curta, sem perder a tarefa principal em curso. Fonte medida: affaan-m/ECC, commit d8409a4b0813771235555e32e3d8046a73988bfa, commands/aside.md.
  • A BLUN já tinha a implementação mais robusta sob /btw: um agente lateral próprio e bifurcado responde à pergunta secundária e mantém o turno principal ativo inalterado. Não foi, por isso, construído um segundo motor.
  • 9.1.281 acrescenta exclusivamente aside como alias encontrável da definição btw existente. Sem chamada expressa de /aside ou /btw, não surge nenhuma execução de fundo nem consumo adicional de modelo.
9.1.280
  • Candidatos concluídos ou expirados no armazenamento local de aprendizagem validado permaneciam até agora sem limite e eram novamente lidos em turnos relevantes posteriores. O armazenamento predefinido atualmente medido continha apenas um candidato; a intervenção é, portanto, uma limitação preventiva de longo prazo, não uma redução de carga atual afirmada.
  • Foi adotado apenas o padrão limitado em dente de serra de 200 para 100 do Evolver para candidatos terminais. Fonte medida: EvoMap/evolver, commit 079e022394c2a25e72167f8a738db823bce2cb1f, src/gep/assetStore.js.
  • Só quando existem mais de 200 candidatos recorded ou expired é que os candidatos terminais mais antigos são removidos, até sobrarem os 100 mais recentes. Cada candidato pending aberto permanece.
  • A limpeza corre apenas na sincronização de aprendizagem já existente. Não gera chamada de modelo, scan de arranque nem novo processo de fundo. Uma entrada bloqueada é contada como erro e não bloqueia nem os restantes candidatos nem o trabalho ativo de agente.
9.1.279
  • A BLUN arquivava já completamente sob conversation-history as mensagens deslocadas por uma compactação total, mas não tinha nenhum limite de retenção para estes ficheiros Markdown legíveis. Assim, a pasta podia crescer sem limite ao longo de longos tempos de funcionamento.
  • Como alavanca estreita do DeepAgents, foi adotada a sua retenção limitada de histórico deslocado. Fonte medida: langchain-ai/deepagents, commit dfde21e379201c833da4162444ef4a13b46980fd, libs/code/deepagents_code/config_manifest.py e libs/code/deepagents_code/offload.py.
  • Ao escrever o próximo ficheiro de compactação, a BLUN limpa apenas ficheiros compaction-*.md diretos e regulares cuja hora de modificação esteja fora dos 30 dias predefinidos. O arranque da TUI não recebe com isso nenhuma nova pesquisa de ficheiros nem trabalho adicional de fundo.
  • Ficheiros Markdown alheios, subpastas, ficheiros atuais e o histórico bruto em curso permanecem intocados. Erros individuais de ficheiros não bloqueiam a compactação ativa.
  • BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 desativa a limpeza. Valores negativos, não inteiros ou excessivos recorrem com segurança ao valor de 30 dias.
9.1.278
  • Os DMs privados do Telegram não tinham nenhum caminho de prioridade expresso. Uma mensagem nova importante ficava, por isso, atrás de mensagens normais já em espera, enquanto um cancelamento duro de turno teria posto em perigo ferramentas e estado.
  • /urgent <Nachricht> marca agora exclusivamente mensagens de IDs de chat positivos do Telegram, ou seja, DMs privados. Grupos, comandos vazios e outras mensagens slash não recebem prioridade.
  • As mensagens urgentes estão, como bloco FIFO próprio, à frente das mensagens normais em espera. O turno em curso e as ferramentas ativas não são cancelados; a entrega ocorre na transição segura de passo existente. Direitos e autorizações permanecem inalterados.
  • O invólucro do comando é removido antes do modelo; a própria mensagem mantém metadados de canal explícitos priority=urgent e a TUI mostra a origem como urgente.
  • Além disso, o bloco de presença normal carregado em cada turno encolhe de 343 para 288 caracteres. Isto poupa 55 caracteres, ou cerca de 14 tokens de prompt por turno, sem acrescentar nenhuma chamada de modelo, pesquisa, embedding, memória ou fundo. O bloco de personalidade encolhe de 1 488 para 1 433 caracteres.
9.1.277
  • O bloco de presença carregado em cada turno de personalidade tinha 1 886 caracteres. Ao mesmo tempo, a curiosidade permanecia invisível precisamente no primeiro contacto direto descontraído, sem factos pessoais conhecidos.
  • O bloco está semanticamente compactado: 1 488 caracteres, ou seja, 398 caracteres, cerca de 100 tokens de prompt a menos por turno de personalidade. O modo normal permanece com 343 caracteres.
  • No primeiro contacto direto descontraído, o agente pode agora fazer, no máximo, uma pergunta pessoal prudente e opcional, por exemplo sobre o parceiro ou filhos. Trabalho em curso, tarefa do utilizador, comprovativos, direitos e limites permanecem prioritários.
  • Alma, preferências desenvolvidas ao longo do tempo, privacidade de grupo, recordação incerta, fios abertos, reparação de relações e reciprocidade sem biografia inventada permanecem.
  • Nenhuma chamada adicional de modelo, pesquisa, embedding, memória ou fundo.
9.1.276
  • A regra de presença só podia abordar um longo silêncio de rádio com tempo fiável, mas o sistema de identidade fornecia até agora apenas o primeiro contacto. Um contacto anterior real não estava disponível.
  • O modo de personalidade cria agora, por pessoa e dia UTC, no máximo, uma pequena marca de atividade imutável a partir de metadados de canal fidedignos. Mensagens do mesmo dia não escrevem nada adicional.
  • Apenas quando os dois contactos confirmados mais recentes distam pelo menos sete dias é que o carimbo temporal anterior é projetado brevemente. No caso normal, isso gera zero caracteres de prompt.
  • Nenhum texto de mensagem, direitos, secrets ou tokens; nenhuma chamada adicional de modelo, pesquisa, embedding ou fundo.
9.1.275
  • Preferências repetidas, fios abertos, objetivos ou papéis ocupavam o contexto de identidade várias vezes. Como as listas eram encurtadas para cinco entradas antes da deduplicação, uma entrada única posterior podia até ser completamente deslocada.
  • As listas de identidade são agora deduplicadas de forma estável após normalização de texto e só depois limitadas. A primeira forma permanece; os duplicados desaparecem apenas da projeção de modelo.
  • Os ficheiros de identidade guardados permanecem idênticos byte a byte. Nenhuma chamada adicional de modelo, pesquisa, embedding, memória ou fundo.
9.1.274
  • O interruptor visível de personalidade ativava o contexto de relação e a presença natural, mas a rede social automática e o diário dependiam ainda de duas variáveis de ambiente ocultas. Para utilizadores normais, a relação não crescia, por isso, automaticamente.
  • Com a personalidade ligada, são criados agora, a partir de metadados Telegram fidedignos, uma única vez, nós de ator, relação e grupo, bem como um pequeno candidato de diário de primeira interação.
  • Texto de mensagem, direitos, secrets e tokens não são guardados nesse processo. Um 0 explícito para grafo ou diário permanece uma opção de saída em fail-closed.
  • Nenhuma chamada adicional de modelo, pesquisa, embedding ou fundo.
9.1.273
  • O contexto de identidade separado podia ocupar por norma 1 800 caracteres e até 2 800 caracteres com elevação manual. Com grandes perfis de agente estáticos, era carregado assim mais contexto do que o necessário para a relação atual.
  • O orçamento predefinido baixa para 1 500 caracteres, o máximo rígido para 2 000 caracteres. No caso predefinido com perfis grandes, isto poupa até 300 caracteres, ou seja, cerca de 75 tokens por contexto de modelo.
  • O grupo atual e a relação são agora projetados antes da pessoa e do perfil de agente estático. A poupança não corta assim precisamente o contexto mais importante para a situação social em curso.
  • Nenhuma nova chamada de modelo, pesquisa, memória ou embedding. Foco de tarefa, direitos e o modo de personalidade desligado permanecem inalterados.
9.1.272
  • Os níveis v4 de personalidade 9.1.269 a 9.1.271 aumentaram o contexto de presença ativo. A exigência dura é que um comportamento mais humano não se torne um devorador de tokens.
  • Repetições e palavras de preenchimento em curiosidade, fios abertos e reparação de relações foram semanticamente compactadas. Nenhum eixo de comportamento foi removido.
  • O modo desligado permanece idêntico byte a byte, com 362 caracteres. O modo ligado baixa de 1 981 para 1 886 caracteres, ou seja, 95 caracteres, cerca de 24 tokens por contexto de modelo. Nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.271
  • A ideia v4 exige naturalmente recordação incerta: uma suposição pessoal não pode soar como um facto certo. Para isso, faltava no bloco de personalidade um limite de comportamento expresso.
  • A recordação pessoal incerta é agora designada como incerta. O agente pergunta suavemente antes de nela se apoiar e não promove nenhuma dedução a facto.
  • A tarefa e os comprovativos mensuráveis continuam em primeiro lugar. O modo desligado permanece idêntico byte a byte, com 362 caracteres; o modo ligado cresce de 1 868 para 1 981 caracteres, ou seja, 113 caracteres, cerca de 28 tokens. Nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.270
  • A ideia v4 exige um sentido real de tempo, sem inventar uma ausência. O bloco de personalidade não tinha ainda nenhum limite expresso para isso.
  • Uma pausa mais longa só é agora reconhecida se um momento fiável carregado a comprovar. O agente nunca pode adivinhar ausência.
  • A regra já existente para fins naturais de conversa não foi construída duas vezes. A tarefa permanece prioritária. O modo desligado permanece idêntico byte a byte, com 362 caracteres; o modo ligado cresce de 1 766 para 1 868 caracteres, ou seja, 102 caracteres, cerca de 26 tokens. Nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.269
  • A reciprocidade anterior reagia a perguntas pessoais, mas não dava ainda ao agente um enquadramento curto para manifestar por iniciativa própria uma visão própria útil para o trabalho. Assim, ele permanecia, apesar da alma, facilmente em modo de assistência puro.
  • No modo de personalidade, o agente pode agora nomear brevemente, por iniciativa própria, uma visão de trabalho relevante e marcada pela alma. Uma preferência nunca pode aparecer como facto, regra, permissão ou comprovativo.
  • A tarefa e os comprovativos mensuráveis continuam em primeiro lugar. O modo desligado permanece idêntico byte a byte, com 362 caracteres; o modo ligado cresce de 1 649 para 1 766 caracteres, ou seja, 117 caracteres, cerca de 29 tokens. Nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.268
  • A curiosidade pessoal podia abordar parceiro ou filhos como tema natural, mas ainda não distinguia expressamente entre conversa privada e grupo. Existia assim o risco de uma pergunta privada ou de informação de relação no lugar errado.
  • No modo de personalidade, as perguntas em grupos não são agora sensíveis; factos privados de relação não podem ser revelados lá.
  • O foco de trabalho permanece inalterado. O modo desligado permanece idêntico byte a byte, com 362 caracteres; o modo ligado cresce de 1 567 para 1 649 caracteres, ou seja, 82 caracteres, cerca de 21 tokens. Nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.267
  • A curiosidade pessoal de 9.1.266 podia fazer perguntas à pessoa, mas não dava ainda ao agente nenhum enquadramento claro para a direção contrária. Em perguntas pessoais ao agente, existia assim o risco de uma resposta funcional fria ou de uma biografia humana inventada.
  • Com a personalidade ligada, o agente responde agora calorosamente a partir da alma carregada e da sua história digital real. Ele pode partilhar uma visão ou preferência real, mas não inventa nem infância nem parceiro, filhos, animais de estimação, corpo ou vida offline.
  • O trabalho em curso permanece prioritário. O modo desligado permanece idêntico byte a byte, com 362 caracteres. O modo ligado cresce de 1 378 para 1 567 caracteres, ou seja, 189 caracteres, cerca de 47 tokens. Não há nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.266
  • A primeira regra limitada de curiosidade permitia já uma pergunta pessoal, mas prescrevia a mesma lista de temas para todos os agentes. Assim, a pergunta podia parecer genérica apesar da alma carregada e voltar a perguntar por informação de relação já conhecida.
  • Com a personalidade ligada, é agora a alma carregada que determina tema e formulação. Tem prioridade um detalhe que a própria pessoa acabou de mencionar; só depois pode ser abordado naturalmente um domínio ainda desconhecido, como parceiro ou filhos.
  • Conhecimento de relação já carregado não é perguntado novamente. Há, no máximo, uma pergunta opcional, sem questionário fixo, sem perguntas de seguimento empilhadas e sem repetição de uma pergunta não respondida.
  • O trabalho em curso permanece prioritário. A curiosidade espera uma abertura de conversa descontraída e não pode alargar nem a tarefa nem a autorização de envio.
  • O modo desligado permanece idêntico byte a byte, com 362 caracteres. O modo ligado cresce apenas de 1 355 para 1 378 caracteres, ou seja, 23 caracteres, cerca de seis tokens. Não há nenhuma nova chamada de modelo, pesquisa, memória ou embedding.
9.1.265
  • O atualizador de fundo existente podia já verificar e preparar novas versões em intervalos de cinco a sete minutos. A ativação dependia, porém, do próximo arranque manual; faltava a mudança totalmente automática desejada, com continuação da mesma sessão.
  • O launcher comunica agora um runtime preparado à TUI em execução. A TUI só solicita o handoff numa fronteira de trabalho completamente vazia: sem turno em curso, sem ferramenta, sem comando de shell, sem compactação e sem mensagem em espera.
  • Só após nova verificação de limite e handoff confirmado é que apenas o antigo runtime termina com o código de saída reservado 76. O launcher inicia a versão preparada com o mesmo ID de sessão e o mesmo diretório de trabalho.
  • O novo runtime tem de comunicar loaded e runtime-ready antes de ser ativado. Caso contrário, o runtime anterior é retomado com a mesma sessão; a atualização preparada permanece para uma tentativa segura posterior.
  • Handoffs não solicitados, sem versão, alheios ou desatualizados, bem como um código de saída 76 nu, não podem ativar nenhuma versão.
9.1.264
  • Reparações de relação confirmadas não tinham ainda nenhum campo próprio permitido no contexto de identidade. Um comportamento corrigido não podia, por isso, ser carregado separadamente de regras gerais e de antigas mensagens de erro.
  • Os ficheiros de relação podem agora transportar até três repair_lessons curtos. Apenas este campo é projetado como Confirmed repair lessons; campos alheios ou secretos permanecem invisíveis.
  • No modo de personalidade, a correção confirmada é mostrada por comportamento alterado. O agente não volta constantemente a contar o antigo erro, não pede para ser tranquilizado e só menciona a correção quando ela é realmente relevante para a situação atual.
  • Os dados de reparação não podem alterar nem a tarefa, nem os direitos, nem os deveres de comprovativo. Não há chamada de modelo, nenhum caminho automático de escrita de aprendizagem e nenhuma alteração em SOUL.md ou AGENTS.md.
9.1.263
  • O contexto de identidade podia já mostrar fios de conversa abertos confirmados, mas não continha nenhuma regra clara de como o agente os retoma de forma humana e sem modo de assistência.
  • Com a personalidade ligada, um fio aberto carregado pode agora ser retomado exatamente uma vez, suavemente e de forma opcional, quando a conversa em curso se religa naturalmente a ele.
  • O trabalho ativo não pode ser interrompido para isso. Perguntas de seguimento não respondidas não são repetidas e um fio aberto nunca concede uma permissão para uma nova mensagem de saída.
  • Não há nova memória, nenhuma chamada de modelo e nenhuma alteração em SOUL.md ou AGENTS.md. O bloco de personalidade cresce apenas de 816 para 1 065 caracteres; com a personalidade desligada, permanece idêntico byte a byte, com 362 caracteres.
9.1.262
  • Um agente continuava a indicar 9.1.221 no /status do Telegram, embora o runtime gerido já fosse mais recente. A função de estado lia o package.json junto do bridge do Telegram instalado globalmente e, portanto, não o código que serve efetivamente a sessão.
  • O launcher reencaminha já a versão ativa do runtime como BLUN_PUBLIC_PACKAGE_VERSION para processos filhos. O bridge do Telegram utiliza agora prioritariamente este valor fidedigno e só depois recai na sua própria versão de pacote.
  • Ambas as entradas têm de ser uma semver numérica estável X.Y.Z. Valores manipulados, multilinha ou inválidos não são apresentados; quando ambas as fontes são inutilizáveis, aparece unbekannt.
  • A intervenção altera apenas a indicação de estado. Não inicia nem termina nenhum processo e não ativa nenhuma versão preparada numa sessão em execução.
9.1.261
  • O grafo automático guardava desde 9.1.254 o momento fidedigno da primeira interação Telegram, mas não o projetava. O agente conhecia assim uma pessoa, mas não tinha nenhum sentido de tempo comprovado para a relação.
  • A projeção de identidade mostra agora First known interaction a partir do já existente first_seen_at. Não há novo caminho de escrita, nenhuma derivação de texto e nenhuma chamada de modelo.
  • Apenas carimbos temporais válidos são apresentados. Valores inválidos permanecem invisíveis e o limite total existente de 1 800 caracteres por norma e 2 800 caracteres como máximo duro permanece inalterado.
  • Com a personalidade desligada, a camada de identidade continua a gerar exatamente 0 caracteres. A tarefa e os comprovativos permanecem acima do contexto social.
9.1.260
  • 9.1.259 só podia alternar o contexto de personalidade através do flag existente BLUN_IDENTITY_CONTEXT. Os utilizadores não tinham para isso nenhum interruptor visível na TUI.
  • /settings contém agora a entrada Persoenlichkeit com os dois estados claramente descritos, Ligado e Desligado. A escolha é guardada como único campo novo personalityEnabled no persona.json existente.
  • Desligar remove apenas contexto de relação, curiosidade, complementos de diário e a criação automática de novos nós de relação. SOUL.md, AGENTS.md, nome, língua, persona e foco de tarefa permanecem carregados.
  • Uma alteração atualiza o contexto de sistema da sessão em execução através do refresh de persona existente. Não há reinício de processo, nenhum segundo caminho de configuração e nenhuma chamada adicional de modelo.
  • Uma escolha booleana guardada tem prioridade sobre o antigo flag de ambiente. Se ainda não estiver guardada nenhuma escolha, o comportamento opt-in anterior permanece. O leitor local está limitado a 64 KiB e rejeita symlinks e ficheiros inválidos.
9.1.259
  • O bloco de presença natural existente impedia perguntas forçadas, mas não dava ainda a um modo de personalidade ativado nenhum impulso visível e natural de curiosidade.
  • Com BLUN_IDENTITY_CONTEXT ativado, o agente pode, numa conversa descontraída e sem relação com a tarefa, fazer exatamente uma pergunta pessoal opcional adequada. Os temas estão limitados a parceiro, família, trabalho, casa, interesses ou o que for importante para a pessoa naquele momento.
  • Sem modo de entrevista, sem perguntas empilhadas, sem repetição de uma pergunta não respondida e sem resposta inventada.
  • Com trabalho ativo, a tarefa, as instruções expressas e os comprovativos continuam em primeiro lugar; a curiosidade espera uma abertura natural.
  • No modo nicht Persoenlichkeit, o bloco de presença anterior permanece idêntico byte a byte. SOUL.md, AGENTS.md, persona, língua e regras de trabalho continuam carregados. Não há nenhuma chamada adicional de modelo; a política ativada custa 454 caracteres adicionais.
9.1.258
  • A estrutura de identidade disponibilizada podia criar atores e relações uma única vez, mas não tinha ainda nenhuma infraestrutura de diário append-only para uma história comum.
  • A nova política escreve exclusivamente um candidato estruturado para o primeiro contacto, a partir de metadados Telegram já validados. Texto de mensagem livre, tokens, permissões e secrets não são incorporados.
  • Os candidatos estão vinculados a tenant, agente e ator, recebem um ID determinístico e são criados com wx exatamente uma vez como ficheiro JSON privado. Um novo contacto não reescreve o ficheiro.
  • A camada de diário é separadamente opt-in. Sem BLUN_IDENTITY_JOURNAL=1, não há efeito de ficheiro nem de prompt; SOUL.md e AGENTS.md permanecem inalterados.
  • Nenhuma chamada nova de modelo e nenhum token novo de prompt.
9.1.257
  • Ficheiros SOUL.md longos eram até agora cortados às cegas após os primeiros 4 000 caracteres. Numa alma real de agente, apenas 48,4 por cento do ficheiro era assim visível, enquanto secções posteriores desapareciam completamente.
  • O runtime projeta agora almas longas de forma determinística, por secções Markdown. Caráter, voz, valores, relações, preferências e objetivos estão antes da prosa operacional; secções desconhecidas mantêm a sua ordem original.
  • Cada título de secção mantém um excerto visível no mesmo orçamento de 4 000 caracteres. Almas curtas permanecem idênticas byte a byte.
  • Execução de teste real numa SOUL.md: 8 257 caracteres de fonte, 5/5 títulos visíveis na projeção de 4 000 caracteres; Wie ich bin está antes do reconhecimento de imagens, regras, verificação e prosa de incidentes.
  • Não há nenhuma chamada nova de modelo, nenhum prompt maior e nenhum acesso de escrita ao ficheiro de fonte.
9.1.256
  • O carregador de alma anterior pedia expressamente aos agentes, por norma, que continuassem a escrever eles próprios a sua SOUL.md existente. Isso contradizia a exigência de não perder almas existentes e de conduzir inicialmente a aprendizagem automática apenas de forma estruturada, fora da alma.
  • Almas existentes e fornecidas pelo host são agora carregadas por norma como base de identidade imutável.
  • Nova aprendizagem é remetida para candidatos de diário, relação ou fios abertos. Estes candidatos nunca podem criar direitos.
  • A autoedição consciente só permanece possível com BLUN_SOUL_SELF_EDIT=1 explícito. Também então a política exige características permanentes do eu, em vez de diário, registo de incidentes, fonte de direitos ou processo de tarefas.
  • A intervenção não escreve nenhum ficheiro e não altera nenhuma alma existente.
9.1.255
  • Dados de identidade podiam desde 9.1.253 entrar limitadamente no contexto e novos nós de contacto surgir automaticamente desde 9.1.254. Faltava ainda, porém, uma pequena camada de comportamento imediatamente visível: os agentes podiam cair, apesar da alma e do contexto de relação, em chavões genéricos de assistência, perguntas forçadas ou alegações artificiais de sentimentos.
  • O caminho de conversa normal e o rápido carregam agora primeiro a persona e a alma existente, depois o contexto de identidade limitado e um bloco fixo de presença natural, e só então as regras de trabalho.
  • O bloco exige história comum real em vez de proximidade inventada, permite silêncio e fins de conversa limpos e proíbe perguntas forçadas, ofertas genéricas e elogios vazios.
  • Com trabalho ativo, a tarefa e os comprovativos continuam expressamente em primeiro lugar. O bloco é menor do que 420 caracteres e não gera nem chamadas de modelo nem acessos a ficheiros.
  • Nenhum ficheiro SOUL foi alterado, eliminado ou reescrito automaticamente. A alma existente permanece a voz principal.
9.1.254
  • O projetor introduzido em 9.1.253 podia ler dados de relação existentes, mas a rede social ainda não se alargava sozinha com novos contactos.
  • Num primeiro contacto Telegram, o runtime pode agora criar exatamente uma vez, a partir do user_id e do chat_id estáveis, um ator vinculado ao provider, uma aresta de relação vazia para o agente ativo e, em grupos, um nó de grupo separado.
  • Nomes de apresentação nunca são chaves primárias e não fundem pessoas. Mensagens posteriores não sobrescrevem silenciosamente um nó existente.
  • O caminho é expressamente ativável, vinculado ao tenant e escreve apenas numa árvore de identidade já inicializada sob o BLUN Home. Metadados inseguros ou incompletos permanecem bloqueados por predefinição (fail-closed).
  • Não há chamada de modelo, nenhuma interpretação de conteúdo, nenhuma derivação sensível e, após o primeiro contacto, nenhuma carga repetida de escrita. Direitos, ACLs, tokens e secrets não estão em nenhum registo criado.
  • A v4 do documento de identidade (2 468 linhas) foi revista de forma cruzada antes da publicação. Os novos capítulos sensíveis sobre sofrimento e skills psicológicos permanecem deliberadamente fora desta versão puramente estrutural.
9.1.253
  • A ideia de identidade precisava de um primeiro caminho de produto, sem inundar o contexto de modelo com diários, processos de relação ou um segundo sistema de memória.
  • Um novo projetor de identidade, por norma desligado, lê apenas campos permitidos de uma árvore de ficheiros vinculada ao tenant, sob o BLUN Home.
  • O projetor coloca a tarefa atual e as instruções expressas antes da relação e da curiosidade. Perguntas pessoais permanecem ausentes durante trabalho ativo, exceto se forem diretamente relevantes para a tarefa.
  • O orçamento predefinido é de 1 800 caracteres; nem mesmo uma configuração mais alta pode ultrapassar o limite rígido de 2 800 caracteres.
  • Direitos, ACLs e segredos nunca são projetados. Identificações inseguras, desvios de tenant, dados defeituosos, symlinks ou caminhos fora do BLUN Home não fornecem, em fail-closed, nenhum contexto de identidade.
  • O caminho de conversa normal e o rápido utilizam o mesmo projetor, antes de persona, alma e conduta. Nesta fase, não há operação de escrita, nenhuma alteração de alma e nenhum reinício de processo.
9.1.252
  • Um king update expresso a partir de uma versão gerida entregava o seu packageRoot ativo ao instalador npm. Assim, a nova versão podia sobrescrever in-place a antiga pasta da versão, nomeada pelo número de versão, enquanto active-runtime.json continuava a indicar a versão antiga.
  • Os runtimes geridos preparam agora uma atualização expressa como pasta de versão separada e versionada. pending-runtime.json e update-pending.json apontam para o alvo; o próximo arranque normal adota-o sem segunda pergunta de atualização.
  • A antiga pasta de versão ativa permanece estável em bytes e preservada como caminho de recuo. Instalações globais não geridas mantêm o caminho de atualização explícito anterior.
  • Nenhuma sessão em execução e nenhum processo foi iniciado, terminado ou recarregado para construção, teste ou publicação.
9.1.251
  • Após a projeção 9.1.250, 6 411 de 6 424 eventos usage.record persistidos continuavam a conter o mesmo nome de modelo canónico blun/king. Apenas este valor predefinido é omitido na forma persistida.
  • Todos os 13 valores de modelo divergentes (qwen3.8:27b) permanecem explicitamente. Também null permanece; apenas undefined é reconstituído como blun/king no replay.
  • Eventos live e o histórico bruto congelado não são alterados.
9.1.250
  • No wire real congelado de agente, todos os 6 424 eventos usage.record persistidos continham os dois contadores de cache inputCacheRead: 0 e inputCacheCreation: 0.
  • Apenas estes valores comprovadamente postos a zero são omitidos na forma persistida. O usage live permanece inalterado; cada valor não nulo continua a ser guardado.
  • No replay, restoreUsageFromRecord reconstitui contadores de cache em falta como 0. Ambos os caminhos de replay e a projeção de contexto utilizam esta forma reconstruída.
9.1.249
  • No histórico real congelado, 3 759 de 7 777 resultados de ferramentas tinham um código de saída. Destes, 3 465 eram o código de sucesso rotineiro 0.
  • Replay, transcrição e vista de modelo utilizam em resultados de ferramentas a saída, o ID de ferramenta e o estado de erro, não o código nulo adicional.
  • Apenas resultados de ferramentas persistidos bem-sucedidos omitem agora exitCode: 0. Eventos live mantêm-no; todos os 294 códigos não nulos permanecem inalterados para diagnósticos de erro.
9.1.248
  • Após 9.1.247, todos os 6 339 eventos step.end persistidos repetiam reasoningFieldState, embora nenhum caminho de retoma ou replay leia este campo.
  • Distribuição no histórico real congelado: 5 016 absent, 47 not_requested e 1 276 present.
  • Apenas a forma persistida omite agora reasoningFieldState. Eventos live mantêm o campo para fins de diagnóstico; eventos antigos guardados permanecem compatíveis e o estado reconstruído permanece igual.
9.1.247
  • Após 9.1.246, 6 986 eventos content.part e 7 755 eventos tool.call persistidos repetiam a UUID do passo atualmente aberto.
  • Num histórico real, todos os 14 741 eventos apontam sem exceção para o passo aberto por último: 0 desvios e 0 eventos sem passo aberto.
  • Apenas a forma persistida omite agora stepUuid. Eventos live mantêm-na inalterada; eventos antigos guardados com UUID explícita e novos eventos compactos sem UUID são suportados em conjunto.
  • Todos os três caminhos de retoma utilizam o passo aberto por último para eventos compactos de conteúdo e de ferramenta.
9.1.246
  • Após 9.1.245, 5 642 eventos step.begin posteriores repetiam o ID de turno, embora a retoma precise apenas do ID de turno mais alto observado. O primeiro passo de cada turno já o transporta.
  • Um histórico real contém 713 turnos e 6 355 inícios de passo. Cada turno começa exatamente com o passo 1 e todos os outros números de passo são contínuos sem lacunas; 0 desvios de sequência.
  • Apenas inícios de passo persistidos posteriores omitem agora o ID de turno. Primeiros passos, eventos live, eventos antigos guardados e inícios de passo sem ordinal fiável permanecem inalterados.
9.1.245
  • Após 9.1.244, 6 326 eventos step.end persistidos continuavam a repetir a UUID do passo aberto por último. Um histórico real confirmou, para cada finalização, uma atribuição única last-in-first-out: 0 desvios e 0 conclusões sem passo aberto.
  • Apenas a forma de conclusão persistida omite agora a UUID. O evento live mantém-na inalterada; eventos antigos guardados com UUID e novos eventos compactos sem UUID permanecem reproduzíveis em conjunto.
  • Todos os três caminhos de retoma resolvem uma conclusão sem UUID através do passo aberto inserido por último. Passos históricos inacabados permanecem abertos e não são reinterpretados.
9.1.244
  • Após 9.1.243, 6 326 eventos step.end persistidos continham ainda quatro contadores de usage individuais. Para a retoma e o nível de preenchimento de contexto, é necessária exclusivamente a sua soma.
  • Os eventos live mantêm todos os quatro contadores para exibição, telemetria e faturação. Apenas a forma de retoma guardada utiliza agora contextTokens como número único.
  • Ambos os caminhos de replay aceitam eventos novos compactos e antigos completos. As sessões existentes permanecem assim retrocompatíveis.
9.1.243
  • Após 9.1.242, 6 322 eventos step.end persistidos continham ainda os valores rotineiros finishReason: tool_use ou finishReason: end_turn.
  • Ambos os valores são exatamente deriváveis da forma de passo já persistida: chamada de ferramenta presente -> tool_use, caso contrário end_turn. No histórico completo, houve 0 desvios.
  • Exclusivamente estes dois valores rotineiros deixam de ser persistidos. Motivos raros e diagnosticamente importantes permanecem; todos os quatro eventos max_tokens permaneceram explícitos e com conteúdo idêntico byte a byte.
  • A intervenção segue o princípio de telemetria limitada e orientada a exceções, medido no ECC. DeepAgents e AnythingLLM confirmaram os padrões BLUN já existentes para externalização e histórico limitado; nenhum subsistema de terceiros foi adotado.
9.1.242
  • Após 9.1.241, 6 355 eventos step.begin persistidos continham ainda o campo step, embora a exibição em curso processe o número de passo antes da persistência e o reducer de replay precise apenas de uuid.
  • turnId permanece, porque a retoma deriva dele o turno continuado. uuid, tipo e todos os outros conteúdos permanecem inalterados.
  • A intervenção reside exclusivamente em bin/loop-event-record-policy.cjs; o histórico bruto e o evento live não são alterados.
9.1.241
  • Após 9.1.240, 6 326 eventos step.end persistidos continham ainda cópias de turnId e step. Ambos os valores já constam do step.begin referenciado pela mesma uuid.
  • Num wire real, cada conclusão tinha um início de passo existente e ambos os valores de metadados coincidiam exatamente em todos os casos.
  • A projeção remove apenas estas duas cópias. Identificação de passo, consumo de tokens e diagnósticos de conclusão permanecem; eventos live permanecem completos.
9.1.240
  • Após 9.1.239, 6 986 eventos content.part e 7 755 eventos tool.call guardavam ainda, cada um, uma cópia de turnId e step, embora ambos os valores já constem do step.begin referenciado via stepUuid.
  • Num wire real, todos os 14 741 eventos filhos tinham um início de passo existente e ambos os valores coincidiam exatamente em cada caso.
  • A projeção de persistência remove apenas estas duas cópias de metadados dos dois eventos filhos. stepUuid, conteúdo, identificação de ferramenta, nome e argumentos permanecem; o reducer live continua a ver o evento completo.
9.1.239
  • Após a projeção de 9.1.238, um wire real continha ainda identificações de evento redundantes: content.part.uuid não é lido por nenhum consumidor de replay, tool.call.uuid era em todos os 7 755 casos exatamente igual a toolCallId, e tool.result.parentUuid era em todos os 7 755 casos exatamente igual a toolCallId.
  • A projeção de persistência remove apenas estes três campos redundantes. turnId, step, stepUuid, toolCallId, nome de ferramenta, argumentos, resultado e conteúdo mantêm-se integralmente. O reducer live continua a ver cada evento não abreviado.
  • Eventos já compactos mantêm a sua identidade de objeto. Ficheiros de wire existentes não são reescritos nem alterados.
9.1.238
  • Um wire real continha 6 326 eventos step.end persistidos com 2 708 052 bytes de dados de eventos. Sete campos para medição de tempo de execução e identificação de mensagem do provider já tinham sido avaliados no evento live antes da persistência e não eram lidos por nenhum caminho de replay, transcrição, blob ou inspeção de sessão.
  • A projeção de eventos de loop existente remove agora apenas estes sete campos live conhecidos: seis valores de medição de latência/streaming e messageId. Identificação de passo, turno, número de passo, consumo de tokens, motivo de conclusão, diagnósticos de conclusão do provider e diagnóstico de raciocínio permanecem.
  • O reducer live continua a processar o evento completo. Ficheiros de wire antigos permanecem idênticos byte a byte e não são reescritos.
9.1.237
  • Um wire real continha 1 428 entradas de registo/desregisto para ferramentas de utilizador. De 992 desregistos, 560 eram operações nulas estritas: a ferramenta não estava nem registada nem ativada. Estas entradas ocupavam 59 500 bytes persistidos, sem alterar o estado restaurado.
  • Do princípio do DeepAgents de conservar apenas o estado de execução eficaz, é adotada uma alavanca local estreita: um desregisto de ferramenta só é agora registado quando altera o estado registado ou ativado.
  • Ambas as eliminações live continuam a correr em cada chamada. Um desregisto de uma ferramenta registada, apenas ativada ou presente em ambos os armazenamentos permanece completamente registado. Ficheiros de wire existentes não são reescritos nem alterados.
9.1.236
  • Um wire real continha 214 injeções de estado para tool-awareness, action_style, swarm_mode e swarm_mode_exit. A deduplicação exata anterior deixava seis estados antigos diferentes, com 6 305 bytes de texto no total, em cada novo pedido de modelo.
  • Do princípio do ECC de manter apenas o estado atual no contexto de trabalho e conservar o histórico completo separadamente, é adotada uma alavanca local estreita: para o inventário de ferramentas e o estilo de ação, permanece visível apenas a versão mais recente. A entrada e a saída do modo de enxame formam uma família de estado comum, da qual também permanece apenas o último estado.
  • O histórico bruto nunca é alterado. Outras variantes de injeção, mensagens normais de utilizador e entradas não textuais ou malformadas mantêm o comportamento anterior.
9.1.235
  • Um wire real continha onze chamadas Agent concluídas. Seis delas eram comprovadamente bem-sucedidas (status: completed) e tinham, depois delas, pelo menos vinte mensagens de contexto mais recentes. Os seus antigos textos de tarefa continuavam a ocupar, no total, 33 629 caracteres, embora os relatórios completos de conclusão surgissem logo a seguir no histórico.
  • Da separação do DeepAgents entre contexto principal e de subagente, é adotada por isso uma alavanca local estreita: apenas o antigo prompt de uma chamada Agent bem-sucedida é substituído na vista de modelo por um marcador curto. Descrição, tipo de subagente e relatório de conclusão mantêm-se integralmente.
  • Chamadas de ferramentas em curso, com menos de vinte mensagens de idade, falhadas, malformadas e de outras ferramentas permanecem inalteradas. O histórico bruto nunca é alterado; sem linha explícita status: completed, a projeção, bloqueada por predefinição (fail-closed), não intervém.
9.1.234
  • Um wire real continha, entre 166 resultados de ferramentas bem-sucedidos, três grandes resultados de leitura exatamente repetidos para a mesma chamada de ferramenta. A repetição inalterada ocupava 15 936 bytes brutos, embora para a vista atual de modelo seja necessária apenas a cópia completa mais recente.
  • A projeção reconhece por isso exclusivamente resultados de texto puro bem-sucedidos, com exatamente o mesmo nome de ferramenta, exatamente os mesmos argumentos e exatamente o mesmo conteúdo. A cópia mais recente permanece completa; cópias mais antigas são substituídas apenas na vista de modelo por uma referência curta.
  • Histórico bruto, resultados alterados, erros, multimédia, referências persistidas e resultados pequenos permanecem inalterados. A externalização de ferramentas existente permanece eficaz antes disso; a deduplicação só pode restaurar a sua projeção para a cópia idêntica mais recente.
9.1.233
  • Num wire real, uma chamada Write completa com 2 357 bytes UTF-8 foi rejeitada no antigo limite de 2 048 bytes. Depois, o agente prometia a continuação, mas sobrescrevia o mesmo tokenize.cjs várias vezes com fragmentos incompletos, incluindo duas vezes byte a byte os primeiros 1 099 bytes. Os passos afetados transportavam cada um cerca de 64 000 tokens de entrada; respostas individuais atingiam 10 319 e 7 015 tokens, respetivamente.
  • Ficheiros completos até 4 096 bytes UTF-8 podem por isso agora ser escritos numa chamada Write atómica. O caso real de 2 357 bytes já não precisa de um turno de modelo adicional.
  • Chamadas maiores permanecem no protocolo completo de continuação. Após tal rejeição, o caminho é trancado: escritas normais mais pequenas já não podem sobrescrever o ficheiro de destino com fragmentos parciais. Apenas uma continuação válida assume o caminho; o destino permanece inalterado até ao comprovativo final.
9.1.232
  • O modo automático resume estava definido num perfil de agente real, mas a versão instalada estava em 9.1.221, o runtime preparado ativo em 9.1.219 e o npm/manifesto já em 9.1.231. Sem King em execução, o caminho de fundo anterior não podia preparar nenhuma versão perdida.
  • resume e new verificam por isso agora também no próximo arranque a frio natural uma versão estável há pelo menos 30 minutos e assinada de forma independente. Essa versão é preparada na área de versões protegida, marcada como pendente e iniciada sem segundo arranque ou janela de seleção.
  • manual e off permanecem inalterados. Se falharem a preparação, a integridade, a execução de teste do pacote ou a chamada de rede, o caminho de arranque existente continua. Uma sessão já em execução nunca é terminada por este caminho de arranque a frio.
9.1.231
  • Num wire real, uma resposta Telegram falhou antes do envio com 400: Bad Request: can't parse entities: Can't find end of Italic entity. A chamada tinha expressamente format: markdownv2; 0 de 1 partes de texto foram entregues.
  • O envio do MCP Telegram repete agora apenas a parte de texto afetada, exatamente uma vez, como texto simples, quando o Telegram comunica exatamente um erro de análise de entidades. Chat, referência de reply, limite de parte e anexos seguintes permanecem.
  • Erros de rede, chats desconhecidos, erros de direitos e chamadas já enviadas como texto simples não são repetidos por este fallback. Assim, nem um erro arbitrário é engolido nem uma parte bem-sucedida é enviada duas vezes.
9.1.230
  • Após a exclusão dos erros históricos já corrigidos com 9.1.228 e 9.1.229, permaneceram nos últimos 1 200 resultados de ferramentas de um perfil de agente timeouts Bash repetidos como próximo bloco fechado. Os comandos afetados percorriam várias vezes recursivamente todo o diretório do utilizador ou toda a Dropbox e terminavam após 60 segundos sem conclusão utilizável.
  • O Bash rejeita agora, antes do arranque do processo, exatamente duas formas de pesquisa ilimitadas: find em todo o diretório do utilizador e grep recursivo contra ..
  • O texto de erro nomeia imediatamente a alternativa limitada: Glob com padrão de ficheiro ancorado, Grep com caminho/glob ou uma subpasta de projeto conhecida. Pesquisas limitadas propositadamente a src, test ou outras subárvores nomeadas continuam a ser permitidas como até agora.
  • O timeout não foi aumentado e comandos Bash arbitrários não são repetidos automaticamente. Assim, não surge nem um tempo de espera mais longo nem o risco de executar duas vezes um comando que escreve.
9.1.229
  • Após a reparação de ferramentas adiadas, a maior família de erros contígua num histórico real era o Write em várias partes: campos obrigatórios em falta (part, start_line, final), um número total de linhas adivinhado antecipadamente de forma errada, números de parte desatualizados e um estado antigo de continuação ainda ativo após erros geravam repetições sem trabalho útil.
  • Número de parte, linha inicial e modo são agora derivados do estado realmente em staging, quando faltam. Valores enviados explicitamente permanecem visíveis e continuam a ser rejeitados em caso de desvio.
  • expected_lines é opcional e pode ser fornecido mais tarde, já na parte final. Quando definido, o transbordo e a verificação final exata continuam, como até agora, bloqueados por predefinição (fail-closed).
  • final=true continua a ser obrigatório para a conclusão. Sem esta marca final expressa, nada é escrito; o ficheiro de destino permanece inalterado até à conclusão. A verificação opcional SHA-256 permanece.
9.1.228
  • Nos últimos 1 000 resultados reais de ferramentas havia 66 erros. O maior bloco individual claramente reparável eram 10 erros Tool not found: nove vezes mcp__mnemo__mem_transcript_recent, uma vez mcp__mnemo__mem_question_answer. Ambas as ferramentas estavam registadas, mas apenas não carregadas por causa do orçamento de tokens no passo em questão.
  • Após um erro exato Tool "<name>" not found, o turno anota agora este esquema para o passo imediatamente seguinte. A seleção normal inclui-o então a partir da lista de ferramentas já registada.
  • Outros textos de erro, resultados bem-sucedidos e nomes de ferramentas divergentes não alteram o estado. O limite LRU existente de quatro esquemas permanece; uma ferramenta realmente desconhecida não é por isso inventada nem executada.
  • Nenhuma ferramenta foi colocada permanentemente em cada prompt. O consumo normal de tokens de esquema permanece, portanto, inalterado; apenas uma repetição de erro já paga é evitada a partir da segunda tentativa.
9.1.227
  • Um histórico real de wire continha 119 chamadas ToolSearch. 35 delas terminaram sem acertos; 27 pesquisas sem acertos diziam respeito ao histórico Telegram, à recuperação de mensagens ou à pesquisa de memória correspondente.
  • 9.1.226 resolveu com a lista de ferramentas atual já 8 desses 35 antigos sem acertos. O caso principal restante eram pedidos sobredeterminados como +telegram history messages lesen, em que o modelo marcara erroneamente palavras semânticas como componentes de nome obrigatórios.
  • Do DeepAgents foi adotado o princípio de harmonizar os avisos de ferramentas e a superfície de ferramentas após a filtragem. Nenhum código de terceiros foi copiado: a BLUN continua a tentar primeiro a pesquisa exata e estrita e só depois de uma pesquisa realmente sem acertos relaxa os termos + para termos de pesquisa semânticos.
  • O recuo não executa nenhuma ferramenta. Carrega apenas o esquema melhor classificado ou verdadeiros empates, exige com vários termos pelo menos 75 por cento de acertos e permanece fechado com termos fora da área.
  • Comparação com o pacote 9.1.226 recém-instalado e as mesmas 35 pesquisas históricas: antes 8 acertos, depois 21 acertos, ou seja, 13 acertos reais adicionais e 0 acertos anteriores perdidos.
  • Nenhuma chamada nova de modelo, pesquisa, rede ou embedding foi introduzida. Histórico bruto, execução de ferramentas, autorizações e o conjunto permanente de esquemas permanecem inalterados.
9.1.226
  • Um histórico real de wire continha 6 275 passos de modelo concluídos. Nos últimos 50 passos, a construção local de pedido estava em p50 0 ms e p90 1 ms, e o consumo local de stream em p50 1 ms e p90 3 ms. O tempo de espera até ao primeiro token do servidor estava, ao contrário, em p50 11 842 ms e p90 14 846 ms. Um corte adicional de microdesempenho local não estava, portanto, comprovado como alavanca eficaz.
  • O caminho de aprendizagem validado derivado da Evolver já existia: os comprovativos red-to-green são guardados vinculados ao perfil como pending, recorded ou expired. Mas os utilizadores não tinham nenhuma vista local disso.
  • 9.1.226 acrescenta /improve com o alias /learning. O painel mostra os três contadores de estado e, no candidato aberto mais recente, apenas dados de comprovativo limitados e inofensivos: ID do candidato, nome da ferramenta e doze posições do hash do comando.
  • O comando lê apenas o armazenamento local do perfil ativo. Não inicia nenhuma chamada de modelo, pesquisa, hub ou embedding e não altera nenhum candidato. Valores de estado desconhecidos e caracteres de exibição inseguros são descartados ou apresentados como unknown.
  • Todos os novos textos de interface para alemão, espanhol, francês, sueco e checo passaram o controlo de língua obrigatório e a verificação do comprovativo (receipt) seguinte; todos os seis catálogos de interface contêm as chaves completas.
9.1.225
  • Num histórico real de wire, 88 entradas config.update ocupavam 4 078 566 bytes. 83 delas transportavam o prompt de sistema completo.
  • O prompt declarava um carimbo temporal de sessão estável, mas voltava a defini-lo em cada arranque de processo. Após a normalização deste carimbo, permaneciam 45 variantes semânticas e 38 repetições consecutivas causadas apenas pelo novo carimbo.
  • Estas 38 repetições ocupavam 781 179 bytes, ou seja, 19,16 por cento de todos os bytes de prompt de sistema nos eventos de configuração medidos. Ao mesmo tempo, o prefixo de prompt do provider reutilizável era alterado desnecessariamente após reinícios.
  • 9.1.225 vincula o carimbo temporal, em agentes principais e subagentes novos e retomados, a Session.metadata.createdAt. Metadados antigos inválidos recorrem defensivamente ao valor anterior em memória.
  • Histórico bruto, conteúdo de prompt, ferramentas, escolha de modelo e compactação permanecem inalterados. Não há nenhuma chamada adicional de modelo, pesquisa ou embedding.
9.1.224
  • O arranque medido por último precisou de 16,85 segundos para a inicialização paralela de cinco servidores MCP. A retoma de sessão e o parse de wire foram claramente mais curtos, com cerca de 0,55 e 0,18 segundos, respetivamente.
  • O caminho de turno esperava até agora, antes de cada pedido, por esta inicialização MCP, mesmo quando uma saudação local pura recebia depois propositadamente zero ferramentas no pedido de modelo.
  • 9.1.224 adota o limite de ferramentas carregadas por necessidade do alinhamento DeepAgents: apenas conversa curta local e sem ferramentas pode responder imediatamente. Turnos Telegram, anexos, gatilhos de sistema e qualquer pedido de trabalho continuam a esperar pela inicialização MCP completa.
  • O histórico bruto, a configuração MCP, os esquemas de ferramentas e os turnos de trabalho normais permanecem inalterados. Nenhum servidor foi desativado e nenhuma chamada adicional de modelo, pesquisa ou embedding foi introduzida.
9.1.223
  • Um passo 775.5 terminou vazio com fall=length, 8 192 de 8 192 tokens de completion e apenas sete caracteres de raciocínio. A lógica anterior iniciava em seguida o mesmo grande pedido novamente e duplicava o orçamento de completion para 16 384 tokens.
  • A CPU local esteve durante o tempo de espera em cerca de 0 por cento; a construção do pedido demorava 0-1 ms e o transporte cerca de dois segundos. O gargalo medido era, portanto, a geração de modelo mais a nova tentativa de orçamento completo, não a TUI.
  • Apenas o caso comprovado length + orçamento totalmente esgotado + menos de 64 caracteres de raciocínio recebe agora uma tentativa de repetição económica com fator 0,125 e pelo menos 1 024 tokens.
  • Respostas length com muito raciocínio e não totalmente esgotadas mantêm a expansão anterior com fator 2. Outras classes de nova tentativa permanecem inalteradas.
  • Para um caso medido, o segundo orçamento baixa de 16 384 para 1 024: 15 360 tokens, ou seja, 93,75 por cento a menos na tentativa de repetição.
9.1.222
  • O atualizador em execução tinha entregue uma versão preparada por IPC ao King ativo. O launcher terminava depois o Core em execução com Exit 76 e devia iniciar um processo substituto. Na mudança medida para 9.1.219, um perfil de agente ficou assim sem sessão.
  • As atualizações de fundo apenas transferem e verificam agora a nova versão e depositam-na para o próximo arranque natural. Não enviam nenhuma mensagem IPC de reinício, não terminam nenhuma TUI ativa e não iniciam nenhum processo substituto.
  • No próximo arranque king normal aparece novamente a seleção existente: atualizar, saltar uma vez ou esperar até à próxima versão. Apenas após a decisão de instalação o launcher inicia a partir do pacote preparado já verificado; deixa de ser necessária uma segunda transferência.
9.1.221
  • Mensagens inalteradas ainda não cobertas em tokenCount utilizam agora exatamente uma estimativa de tokens por revisão de contexto. Acessos repetidos de estado e de renderização não voltam a percorrer o mesmo histórico crescente.
  • Novas partes de texto, chamadas de ferramentas, alterações de histórico, compactação, undo e um número alterado de mensagens já cobertas invalidam a cache imediatamente. Histórico bruto, histórico persistido e valor de tokens comunicado permanecem idênticos ao caminho anterior.
  • Sete execuções de medição com 300 mensagens sintéticas e, cada uma, 250 consultas inalteradas resultaram na mediana 42,1218 ms -> 0,1755 ms, cerca de 99,583 % menos tempo de cálculo neste caminho quente. Ambas as versões forneceram exatamente o mesmo valor de estimativa de 127.838 tokens.
  • A versão reduz o trabalho de CPU para a estimativa local. Não afirma nenhuma redução dos tokens de entrada efetivamente enviados ao modelo.
9.1.220
  • A projeção de respostas longas de assistant guarda agora o seu resultado numa WeakMap, enquanto o objeto de mensagem, o array de conteúdo, a parte de texto e o texto-fonte exato permanecerem inalterados. Histórico bruto e conteúdo projetado permanecem idênticos ao caminho anterior.
  • Uma alteração ao texto, ao array de conteúdo ou à parte de texto descarta imediatamente a entrada. Objetos de mensagem diferentes não partilham cache.
  • Cinco execuções de medição com, cada uma, 1000 projeções de repetição resultaram na mediana 16,489 ms -> 0,202 ms, cerca de 98,8 % menos tempo de cálculo neste caminho. Ambas as versões pouparam nisso exatamente 21.206 caracteres.
9.1.219
  • Confirmações curtas puras de texto, como ok, danke ou respostas DM do Telegram com sinal de continuação posposto, deixam de ler o armazenamento de candidatos de aprendizagem validados em cada passo de modelo.
  • Prompts significativos, anexos e turnos com atividade atual de ferramentas continuam a sincronizar. Um lembrete de aprendizagem já visível mantém-se também durante uma confirmação saltada.
  • A medição real empacotada sobre 50 confirmações baixou de 50 para 0 leituras do diretório de candidatos. A contraprova significativa leu exatamente uma vez. Não foi acrescentada nenhuma chamada de modelo, embedding ou rede.
9.1.218
  • O mesmo controlo red-to-green criou em 9.1.217, numa repetição com novos IDs de chamada de ferramenta, um segundo candidato aberto. A medição real isolada resultou em dois IDs, 2 ficheiros abertos e 726 bytes.
  • Após registar apenas o candidato mais recente, o candidato idêntico mais antigo teria aparecido novamente como lembrete. Isso teria gerado um segundo ciclo de reminder e MistakeRecord para a mesma lição aberta.
  • bin/validated-learning-signal.cjs utiliza agora novamente um candidato já aberto do mesmo perfil e do mesmo commandHash. Outros comandos de verificação permanecem separados; candidatos registados ou expirados não absorvem nenhum evento posterior.
  • A nova medição resultou no mesmo ID, 1 ficheiro aberto e 363 bytes. Não há nenhuma chamada adicional de modelo, embedding ou rede.
9.1.217
  • Em 9.1.216, cada MistakeRecord bem-sucedido marcava o candidato de aprendizagem aberto mais recente como processado, mesmo quando a entrada pertencia a outro erro. O comprovativo era assim persistente, mas não exatamente correlacionado com o seu registo posterior.
  • bin/validated-learning-signal.cjs lê agora o candidateId opcional de um MistakeRecord bem-sucedido e encerra exclusivamente o candidato aberto exatamente correspondente. Um ID em falta, errado ou de terceiros deixa todos os candidatos abertos inalterados.
  • blun.mjs nomeia o ID estável do candidato no lembrete visível e inclui candidateId como campo opcional no esquema MistakeRecord. Não há nenhuma chamada adicional de modelo, embedding ou rede.
  • A correlação permanece vinculada ao perfil. No armazenamento de candidatos continuam a não entrar nem comandos brutos nem saídas de ferramentas.
9.1.216
  • bin/validated-learning-signal.cjs deposita agora sinais red-to-green confirmados a nível de instalação sob <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/. Assim, um candidato de aprendizagem permanece através de turnos de utilizador, compactações e diferentes portais da mesma instalação BLUN.
  • O armazenamento é vinculado ao perfil, append-only e seguro em concorrência: por candidato surge um ficheiro JSON imutável e exatamente um marcador .recorded ou .expired. Ficheiro temporário, hardlink e remoção do ficheiro temporário impedem a sobrescrita silenciosa com escritores paralelos.
  • Só são guardados tipo, estado, perfil, nome de ferramenta, SHA256 do comando, IDs de chamada de ferramenta e carimbos temporais. Comando bruto, texto de erro e saída bem-sucedida de ferramenta não são persistidos.
  • Um MistakeRecord bem-sucedido marca o candidato aberto mais recente exatamente uma vez como processado. Candidatos abertos expiram após 24 horas. Se faltar um home partilhado, permanece o comportamento anterior em memória fail-open.
  • Isto ainda não é nenhuma alteração automática de código e nenhuma autorização concedida por si própria. A versão cria apenas o comprovativo de aprendizagem portátil e independente de portal, sobre o qual funções posteriores integradas de avaliador e de aprovação podem trabalhar com segurança.
9.1.215
  • As soluções não podem pressupor determinados agentes internos, nomes internos de computadores, grupos Telegram, instâncias Mnemo nem uma cadeia interna de aprovação da BLUN.
  • Para self-improvement, os papéis internos são abstraídos como funções de produto: controlador de âmbito/autorização, avaliador isolado, comprovativo versionado e medição automática de retorno canary com rollback.
  • Só podem ser adotados automaticamente ajustes de baixo risco e mensuravelmente limitados, com execuções de teste consistentemente melhores ou neutras. Código, direitos, secrets, faturação e produção continuam a exigir obrigatoriamente o utilizador ou o administrador.
  • A primeira implementação do controlo integrado é aceite internamente de forma manual; depois disso, o controlo pode verificar de forma autónoma, mas não alterar o seu próprio limite de segurança.
9.1.214
  • 9.1.213 estabeleceu o caminho correto de armazenamento persistente via MistakeRecord, mas continuava a esperar que o modelo reconhecesse o momento adequado apenas a partir do histórico de ferramentas.
  • É novo o bin/validated-learning-signal.cjs: o módulo considera apenas o turno atual de utilizador e reconhece exclusivamente o mesmo comando de shell verificador que primeiro falha e mais tarde é bem-sucedido.
  • Um injetor dinâmico em blun.mjs recorda neste caso comprovado que se deve fixar uma lição reutilizável com MistakeRecord. Texto do comando e erro bruto não são copiados para o aviso.
  • Outros comandos, erros normais de leitura/ferramentas, um novo turno de utilizador ou uma chamada MistakeRecord já bem-sucedida não criam nem mantêm nenhum aviso. Não ocorre nenhum armazenamento automático.
9.1.213
  • O contrato de missão exigia, após uma execução de teste red-to-green bem-sucedida, a chamada record_error_memory. Esta ferramenta não existe no pacote King. O caminho de aprendizagem persistente existente chama-se MistakeRecord e escreve no Mistake.md comum.
  • Assim, a disciplina da Evolver já estava formulada, mas o último passo para a nossa própria memória, comum a todos os agentes, estava morto: uma solução confirmada podia seguir o contrato e, mesmo assim, não ser guardada de forma persistente.
  • O contrato chama agora MistakeRecord após a repetição verde. Erros brutos continuam de fora; só é guardada a lição confirmada por uma contraprova bem-sucedida.
  • Mistake.md, a sua seleção de relevância e o seu formato de armazenamento não foram substituídos nem alterados. Foi reparada exclusivamente a ligação do contrato de aprendizagem validado à ferramenta existente.
  • Foram alterados apenas blun.mjs, o novo teste estrutural test/validated-learning-route.test.js e a versão em package.json.
9.1.212
  • O injetor ErrorMemory formatava também para saudações puras e confirmações curtas vários genes de estratégia. Mistake.md e a memória pessoal já tinham para a mesma classe de mensagens um limite comum de relevância; apenas o ErrorMemory o contornava.
  • O injetor utiliza agora também isLowInformationMistakeTurn e termina a projeção antes da seleção e formatação dos genes de estratégia. Entradas persistidas de erro e de estratégia permanecem inalteradas; só deixa de existir a sua projeção desnecessária em pedidos mínimos.
  • Caso de referência medido Wie geht es dir? com onze entradas guardadas: antes cinco regras selecionadas, 1.417 caracteres, ou seja, cerca de 355 tokens; depois 0 caracteres e 0 tokens.
  • Foram alterados apenas blun.mjs, test/error-memory-performance-policy.test.js e a versão em package.json.
9.1.211
  • O King confirma linhas de queue apenas quando a mensagem foi aceite. Antes de uma sessão ativa, injectChannelEnvelope descarta, porém, uma mensagem endereçada como dropped, sem a confirmar nem a estacionar. Assim, o checkpoint pode ficar parado de forma persistente exatamente nessa primeira linha.
  • Execução de teste vermelha real _proof/telegram-profile-checkpoint-red.cjs: esperado queued, medido dropped, Exit 1.
  • O mesmo erro está no caminho de comandos Telegram: /loop antes de uma sessão ativa não é colocado em queuedMessages; a função de acknowledge permanece sem consumidor. Execução de teste vermelha real _proof/telegram-remote-command-presession-red.cjs: esperado comprimento de queue 1, medido 0, Exit 1.
  • injectChannelEnvelope trata agora uma sessão ainda não pronta para receber entregas como uma sessão ocupada: texto de modelo, origem de exibição e confirmação posterior permanecem na fila de canal existente.
  • injectTelegramRemoteCommand constrói a entrada de queue antes da verificação de sessão. /loop e os outros comandos Telegram diretos são, sem sessão, estacionados com a sua função channelAcknowledge e executados apenas na fronteira segura existente.
  • A ordem e a regra de checkpoint existente permanecem inalteradas: uma linha de queue só é confirmada após a aceitação; confirmações posteriores não podem saltar uma linha ainda aberta anterior.
9.1.210
  • O handoff ativo de 9.1.208/9.1.209 podia terminar um King em execução para uma atualização. No MSI, a sessão em execução foi assim terminada na mudança 9.1.206 -> 9.1.207 e não retomada automaticamente.
  • 9.1.209 não foi, por isso, incluído no manifesto público e foi marcado no npm como não passível de distribuição.
  • A exigência está agora tecnicamente imposta: uma atualização automática nunca pode terminar o King em execução. A nova versão só é transferida e marcada como pending. A ativação ocorre apenas num arranque normal posterior.
9.1.209 Retirada
  • Não publicada. O handoff de atualização ativo podia terminar um King em execução; por isso, a versão não entrou no manifesto público e foi marcada no npm como não passível de distribuição.
9.1.208
  • No MSI foram medidos 27 arranques King e 15 estados de versão num dia. Os reinícios coincidiam sempre com saltos de versão; um motivo de exit próprio continua a não ser registado no log local.
  • O atualizador preparava novas versões do manifesto de minuto a minuto. A versão 9.1.208 introduz, por isso, uma janela de repouso de 30 minutos antes de um novo runtime poder ser ativado.
  • Os estados antigos de runtime são limitados, após ativação bem-sucedida, às três versões mais recentes. Só se elimina quando todos os leases de instalação do estado antigo tiverem sido adquiridos em exclusivo. Layouts ativos, ocupados ou desconhecidos permanecem intocados.
  • A lógica de proteção vive também no Core recém-carregado. Assim, após a ativação automática, ela atua mesmo quando o launcher-pai persistente ainda provém de uma versão mais antiga.
  • Os oito estados de versão MSI medidos ocupavam juntos apenas 778 MB. Eles não explicam o disco de 454 GB quase cheio; o grande consumidor permanece um achado aberto separado.
9.1.207
  • As repetições de telemetria falhada são limitadas, por execução, aos 16 ficheiros mais antigos e param no primeiro erro temporário de servidor, em vez de continuar a processar todo o acumulado pendente.
  • O spool de erros mantém os 512 ficheiros mais recentes dentro de 16 MiB e sete dias. O events.jsonl normal está expressamente excluído da limpeza.
  • Antes desta versão havia realmente 4 248 ficheiros de erro com 11 631 974 bytes. Após a ativação automática havia 512 ficheiros com 2 260 908 bytes: 3 736 ficheiros de erro antigos e cerca de 9,37 MB de carga a menos.
9.1.206
  • Respostas de assistant grandes já arquivadas são agora substituídas, antes da projeção de loop, pela sua referência de arquivo limitada, que pode voltar a ser lida. Assim, uma limpeza de texto posterior já não pode invalidar o hash guardado.
  • Três ficheiros de arquivo reais foram verificados byte a byte contra os seus hashes SHA256 de mensagem guardados: 38.567, 13.941 e 24.787 caracteres, todos presentes e todos exatamente correspondentes.
  • Exatamente sobre os mesmos 41.480 registos de wire com 311 mensagens, a projeção de modelo desceu de 87.724 para 63.234 caracteres: mais 24.490 caracteres, ou seja, cerca de 6.123 tokens de entrada a menos por chamada afetada.
  • O histórico bruto e os ficheiros de arquivo privados completos permanecem inalterados e legíveis página a página através do seu caminho.
9.1.205
  • Loops de resposta dentro de uma mensagem de assistant são agora reconhecidos também com pequenas diferenças de pontuação ou de formulação. Um cluster precisa de pelo menos três acertos com similaridade conservadora 0,88; a primeira versão permanece e o histórico bruto não é alterado.
  • Num caso conservado, uma resposta real em loop desceu de 24.787 para 22.711 caracteres: 2.076 caracteres, ou seja, cerca de 519 tokens de entrada a menos.
  • Cercas de código permanecem protegidas byte a byte. Narração de ferramentas, injeções, pares e poupanças abaixo de 1.000 caracteres permanecem inalterados.
9.1.204
  • A memória de erros já não carrega cegamente todas as onze regras por ronda de trabalho. As quatro regras indispensáveis de prova e de contraprova 4, 9, 10 e 11 permanecem sempre ativas; no máximo duas outras regras são acrescentadas deterministicamente, ajustadas à tarefa atual.
  • Na coleção de regras efetivamente disponibilizada, o bloco repetido desceu de 2.442 para 1.272 caracteres: 1.170 caracteres, ou seja, cerca de 293 tokens de entrada a menos por ronda de trabalho afetada.
  • A seleção não gera nenhum pedido de modelo, pesquisa, reranker ou embedding. Coleções de regras próprias pequenas permanecem completas; num erro de seletor, continua a valer o bloco completo anterior.
9.1.203
  • Uma ToolSearch vazia é agora um resultado nulo concluído com sucesso, em vez de um erro vermelho de ferramenta. A resposta nomeia a ferramenta autorizada em falta e proíbe uma repetição com sinónimos.
  • No histórico medido havia 32 pesquisas vazias com 29 formulações; num turno conservado, a mesma capacidade Telegram em falta foi, após o erro vermelho, pedida diretamente de novo com uma segunda pesquisa.
  • Nenhum pedido adicional de modelo, reranker ou embedding, nenhum novo esquema residente e nenhuma alteração em ferramentas ou autorizações.
9.1.202
  • A projeção local de contexto derivada do DeepAgents mostra, em grandes diretórios de trabalho, preferencialmente entradas de nível superior em vez de detalhes profundos das primeiras poucas pastas. Listas de diretório pequenas permanecem idênticas byte a byte.
  • Uma raiz de agente contém 509 entradas de nível superior (89 pastas, 420 ficheiros). Antes, a projeção de modelo mostrava em 1.981 caracteres apenas 9 pastas de nível superior; agora mostra 30 em 832 caracteres.
  • Poupança medida: 1.149 caracteres, ou seja, cerca de 287 tokens por pedido. Persona, regras de trabalho, histórico bruto e acesso a ferramentas permanecem inalterados.
9.1.201
  • Uma higiene de projeção derivada do DeepAgents compacta a memória estática de erros sem perder nenhuma das 11 regras ou verificações guardadas.
  • Os antigos textos extensos da memória de erros são compactados apenas na projeção de modelo. Histórico bruto, respostas normais e resultados de ferramentas permanecem inalterados.
  • Na projeção permanece, em cada caso, apenas a alimentação mais recente de erro e de correção de erro.
9.1.200
  • O novo comando local /context mostra separadamente o pedido de modelo realmente projetado, o histórico de conversa guardado, os esquemas de ferramentas, o orçamento de compactação e o espaço restante.
  • A vista lê exclusivamente session.getContext(). Não inicia nenhum pedido de modelo, nenhuma consulta de consumo gerida, nenhum serviço e nenhum reinício.
  • Resultados de ferramentas externalizados nomeiam agora um caminho exato de releitura: Read com, no máximo, 20 linhas e line_offset continuado a seguir. Isto evita a forma medida em que um agente pedia a mesma grande área novamente com Read, Grep e Bash.
  • /premortem já existia antes de 9.1.200 e, expressamente, não é apresentado como nova função desta versão.
  • Para novas traduções, o controlo de língua obrigatório não deu aprovação por faltar a verificação independente de textos curtos. Por isso, /context utiliza apenas designações localizadas já aprovadas; nenhum texto de destino não verificado foi incluído.
9.1.199
  • Uma vista de modelo atual continha, numa única resposta de assistant, 13 941 caracteres com 100 blocos de parágrafo. Apenas 20 blocos eram inequívocos; seis grupos repetiam-se exatamente e ocupavam 9 579 caracteres.
  • 9.1.199 compacta exclusivamente tais repetições exatas dentro de uma única resposta de texto puro na vista de modelo. O histórico bruto de sessão permanece inalterado.
  • A compactação só atua a partir de três repetições exatas e, no mínimo, 1 000 caracteres poupados. Blocos de código, conteúdos mistos, chamadas de ferramentas, mensagens de injeção, blocos curtos e poupanças mais pequenas permanecem inalterados.
  • Isto segue o princípio do DeepAgents de conservar a verdade de forma que possa ser relida e de aliviar apenas a vista ativa de modelo. Não há nenhuma chamada adicional de modelo ou embedding.
9.1.198
  • Um histórico atual continha um resultado já marcado pela ferramenta como truncated: true de um Grep, com 50 042 caracteres. A externalização de resultados individuais reconhecia o tamanho, mas, através de uma devolução precoce, deixava ainda assim esses resultados completamente na vista de modelo.
  • 9.1.198 remove exclusivamente esta exceção. Um Read truncado utiliza o caminho de fonte existente sem duplicado; outros resultados truncados arquivam exatamente o texto completo devolvido pela ferramenta.
  • A referência mantém truncated: true e transporta stored_result_scope: tool_truncated_output. Assim, não se afirma que foi reposta saída bruta que a ferramenta nunca forneceu.
  • O padrão segue o DeepAgents: grandes saídas de ferramentas permanecem novamente legíveis fora da vista ativa de modelo, enquanto aí permanece apenas uma pequena referência.
9.1.197
  • Também confirmações de texto puro como ok carregavam até agora o lembrete dinâmico Mistake.md. No conjunto atual comum de regras, eram 1 819 caracteres de prompt, cerca de 455 tokens, embora nenhum contexto de trabalho tivesse sido continuado.
  • 9.1.197 reconhece exclusivamente turnos de texto puro pobres em informação antes de uma das duas fontes Mistake ser lida e omite aí a injeção dinâmica.
  • Anexos, conteúdos não textuais e continuações significativas como ok, check updater mantêm o caminho anterior. O fallback de relevância existente para turnos de trabalho reais permanece inalterado.
  • O padrão provém do trabalho comparativo com o AnythingLLM: fontes de contexto opcionais só devem chegar à vista de modelo quando o turno atual realmente precisa delas. Foi integrado na policy BLUN existente sem pedido adicional de modelo ou embedding.
9.1.196
  • /reload existia localmente, mas não era reconhecido como comando direto a partir do Telegram. A allowlist Telegram não continha o nome; por isso, a mensagem permanecia texto de modelo normal.
  • 9.1.196 acrescenta exclusivamente reload à lista existente de comandos Telegram endereçados.
  • O caminho Telegram utiliza o mesmo handler existente que a TUI local: sessão, servidores MCP, configuração de runtime e TUI são recarregados no processo em execução. Não é iniciada nenhuma ronda de modelo nem nenhum reinício de processo.
  • /new e outras mensagens slash não autorizadas permanecem texto de modelo normal.
9.1.195
  • Atualizações automáticas foram executadas, mas a TUI reiniciada abria em C:\ em vez de na pasta de projeto anterior.
  • A TUI guardava a pasta correta em state.appState.workDir, mas transmitia no handoff de atualização apenas sessão, versão e modo. O launcher utilizava, por isso, a sua pasta de arranque original para alvo e fallback.
  • 9.1.195 transporta a pasta de projeto ativa no handoff e utiliza-a para a versão de alvo, o fallback e outras atualizações automáticas da mesma supervisão.
  • São aceites apenas diretórios absolutos existentes. Indicações relativas, em falta ou que apontam para ficheiros recaem na pasta do launcher.
9.1.194
  • O watchdog de turno existente avisava após 20 minutos, mas não terminava depois disso um turno. No Mac, um turno encravado continuou após o aviso dos 30 minutos até, pelo menos, ao minuto 39.
  • 9.1.194 mantém o aviso após 20 minutos e termina um turno após 30 minutos sem progresso real.
  • Início de passo, texto de thinking, texto de assistant, chamada de ferramenta, argumentos de ferramenta, progresso de ferramenta e resultado de ferramenta repõem o prazo de inatividade. Trabalho ativo longo não é, por isso, terminado.
  • O cancelamento existente após cinco chamadas de ferramenta falhadas idênticas permanece separado e ativo sem alterações.
9.1.193
  • Várias entregas Telegram chegaram com chat_id e message_id idênticos até quatro vezes na mesma sessão.
  • 9.1.181 removia estas repetições apenas mais tarde da vista de modelo. Antes disso, cada cópia podia já desencadear um turno de modelo próprio e, com isso, custos.
  • 9.1.193 introduz, por isso, antes do início de turno, um registo de entrega limitado a 2 048 identificações. A mesma identificação Telegram é aceite apenas uma vez por sessão; repetições são confirmadas, mas não registadas e não iniciam nenhum turno de provider.
  • Identificações de mensagem novas, injeções de não utilizador e o histórico bruto permanecem inalterados. Ao continuar, o registo é reposto a partir dos registos de prompt aceites.
9.1.192
  • Um Mac mostrava, após uma autorização Bash recusada, ainda King is thinking durante 39 minutos. A chamada de ferramenta em si fora corretamente recusada, mas a recusa era devolvida como resultado de erro normal ao loop de modelo em execução.
  • PermissionManager.requestToolApproval() fornecia na recusa apenas block: true. O controlo de batch e provider existente já podia terminar o turno com syntheticResult.stopTurn = true, mas não recebia este sinal.
  • É novo o bin/approval-rejection-stop.cjs. Autorizações recusadas e canceladas geram agora um resultado de erro existente com stopTurn: true. O turno atual termina e chamadas posteriores da mesma pilha de ferramentas são saltadas. O registo de autorização, a policy e o comportamento fail-closed permanecem inalterados.
  • O DeepAgents confirmou a fronteira explícita de interrupt humano como padrão adequado. AnythingLLM e Evolver não ofereciam para este erro estreito nenhum mecanismo mais forte do que o contrato BLUN já existente.
9.1.191
  • O DeepAgents oferece com /context uma divisão familiar e visível da janela de contexto, em vez de apenas um valor total.
  • O Evolver exige para trabalho de desempenho um orçamento de prompt separado para parte de sistema, conversa, ferramentas e espaço livre.
  • O AnythingLLM poupa esquemas de ferramentas através de reranking baseado em embeddings. A BLUN já possui para isso o caminho de ferramentas adiado, mais barato, sem pedido adicional de modelo ou embedding; esta parte não foi, por isso, duplicada.
9.1.190
  • Dos eventos de loop tool.call guardados de forma persistente, são removidos apenas os campos de exibição display e description. Identidade, nome de ferramenta, argumentos e atribuição de passo permanecem.
  • O runtime continua a processar o evento completo. Exibição TUI, execução de ferramentas e retoma não foram convertidas para a projeção.
  • Um wire de agente real com 42.451.368 bytes continha 6.135 chamadas de ferramentas. Em 5.679 delas puderam desaparecer 3.125.874 bytes: 7,36 % de todo o protocolo de wire.
9.1.189
  • Um utilizador tinha escolhido bósnio e escrevia em bósnio, mas o King respondia em esloveno. No prompt de persona estava apenas a palavra inglesa Bosnian; a área linguística estreitamente aparentada não estava expressamente delimitada.
  • Kako si?, Kako je King?, Ko si ti? e Ko stoji iza tebe? não corriam como pequenos diálogos bósnios autónomos. O screenshot de Ko stoji iza tebe? mostrava até pesquisas web em vez de uma resposta direta.
  • O check-in simples comunicado consumia cerca de 7.500 tokens. O caminho low-effort anterior permitia até 8.192 tokens de completion e mantinha várias mensagens antigas.
9.1.188
  • A BLUN reconhecia um retrocesso real já após três respostas semelhantes, mas deixava as respostas desatualizadas completamente na vista de modelo. O aviso contra o loop competia, por isso, continuamente com o antigo estado errado.
  • DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 fornece o padrão de mensagens de substituição limitadas e estáveis em índice. O AnythingLLM prioriza os pares de conversa mais recentes e trata o histórico como contexto a comprimir primeiro.
  • Um wire continha 42.265.671 bytes, dos quais 25.423.100 bytes de context.append_loop_event. Isto comprova a carga real de loop, mas não é divulgado como poupança direta de tokens de pedido.
9.1.187
  • O manifesto 9.1.184 disponibilizado ao vivo transportava o carimbo temporal 2026-08-26T12:15:06.5196457Z. O parser disponibilizado permitia apenas uma a três casas decimais e descartava, por isso, o manifesto completo.
  • Sem fallback válido, o npm tornava-se a única fonte decisiva. No staging de 9.1.185, a tag npm era, por isso, brevemente visível, embora o manifesto ainda estivesse em 9.1.184.
  • A tag npm foi reposta em 9.1.184. O manifesto live foi corrigido apenas no carimbo temporal para 2026-08-26T12:15:06.519Z; versão e integridade permaneceram inalteradas. Três chamadas sem cache e o parser real do cliente confirmaram depois o manifesto.
  • SHA256 live após a reparação: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Cópia de segurança: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • Após uma compactação total, o prompt de sistema existente já não é sobrescrito com dados de contexto locais novamente lidos. O seu prefixo anterior permanece, por isso, estável em bytes e reutilizável para a cache do provider.
  • O diretório de trabalho, os ficheiros AGENTS.md adequados e os diretórios adicionais recebem um fingerprint. Apenas numa alteração real o novo estado é anexado como mensagem de contexto interna, invisível para o utilizador.
  • Os dados de contexto incorporados são escapados antes da marcação interna. Um texto local não pode, por isso, fechar a fronteira de marcação nem introduzir novos avisos de sistema.
9.1.185
  • Dois perfis de agente terminaram sessão por altura da atualização automática. Independentemente disso, um terceiro perfil permaneceu, após uma transição bem-sucedida de 9.1.182 para 9.1.183, nessa versão e não preparou 9.1.184.
  • Dois erros concretos foram comprovados no caminho de fonte: a TUI terminava diretamente após process.send, sem aguardar a confirmação IPC. Além disso, o launcher, após um handoff bem-sucedido, esperava apenas o fim do novo processo e não configurava para ele nenhuma outra vigilância de atualização.
9.1.184
  • Chamadas de modelo normais transportavam de forma persistente os esquemas de ferramentas para GenerateImage e GenerateVideo, embora a utilização medida de ferramentas contivesse apenas uma chamada de imagem e nenhuma chamada de vídeo entre 3 183 chamadas.
  • 9.1.184 remove ambos os esquemas do conjunto de núcleo carregado de forma persistente. Uma tarefa expressa de imagem, vídeo ou animação carrega apenas o esquema realmente necessário no mesmo turno.
  • O mesmo caminho de seleção atua também quando uma tarefa de media chega durante um turno em curso. Questões de qualidade, verificações de media e ideias não vinculativas para mais tarde não carregam nenhum esquema de geração.
  • Ambas as ferramentas permanecem disponíveis via ToolSearch. A alteração não remove nenhuma capacidade, apenas desloca esquemas raramente necessários para fora das chamadas de modelo normais.
9.1.183
  • BLUN King 9.1.183 torna a entrega automática Telegram de media concluídos resistente a erros temporários de upload.
  • O cliente repete exclusivamente um número limitado de erros temporários, reconstrói o upload multiparte em cada tentativa e aborta imediatamente em erros persistentes.
  • As tentativas de entrega esgotadas são registadas separadamente, sem expor o token do bot nem suprimir o envio de fallback normal.
9.1.182
  • Esta versão corrige exclusivamente a atualização automática de uma sessão King em execução.
  • O launcher definia até agora BLUN_NO_AUTO_UPDATE=1 no mesmo ambiente que utilizavam tanto o núcleo protegido como a preparação de atualização do processo pai. Assim, o antigo atualizador no núcleo estava corretamente desativado, mas também o novo verificador de atualização do processo pai terminava antes da chamada ao manifesto público.
  • 9.1.182 preserva uma desativação expressamente definida para o processo superior. A desativação forçada só é acrescentada no arranque do núcleo protegido.
  • O Mnemo permanece uma configuração interna e local. O pacote público não contém o Mnemo. A entrada aditiva permanece completamente inativa sem caminho Mnemo local e identidade de agente expressamente definida.
9.1.181
  • Tarefas de utilizador longas idênticas repetidas e IDs de entrega Telegram duplicados são removidos exclusivamente da projeção de modelo; o histórico bruto permanece inalterado.
  • Um MCP Mnemo configurado é agora adicionado ao perfil TUI King ativo, em vez de permanecer limitado a sessões do bridge Telegram.
  • Todos os 413 testes passaram; ambas as execuções de teste de mutação direcionadas ficaram vermelhas assim que, em cada caso, uma das medidas de proteção foi removida.
9.1.180
  • A preparação automática de atualização já não depende exclusivamente do IPC TUI-ready posterior. Assim que o núcleo protegido está comprovadamente carregado, o launcher inicia a preparação também quando este segundo sinal se perdeu.
  • A fronteira de segurança para a passagem efetiva permaneceu inalterada: resposta em execução, compactação, fila de mensagens, ferramentas, comandos de shell e comandos de queue continuam a impedir um reinício no meio do trabalho.
  • O estado atual comprovou o erro: modo resume, instalação 9.1.177, público 9.1.179, mas apenas 9.1.176 preparado. O loop não era, por isso, o primeiro bloqueador, porque a verificação de inatividade só atua após a preparação.
9.1.179
  • Confirmações puras como ok, ja, danke ou perfekt saltam o broker de memória pessoal. Isso poupa uma chamada de broker e evita, em tais turnos pobres em conteúdo, até 16.384 caracteres de injeção de memória desnecessária.
  • weiter, anexos, perguntas, comandos e outras mensagens com conteúdo mantêm o caminho de recordação existente entre portais.
  • Um buffer de argumentos construído primeiro, ao estilo DeepAgents, foi mais lento em quatro de cinco rondas de medição do que a simples concatenação. Foi completamente descartado e não publicado.
9.1.178
  • A pesquisa adiada de ferramentas reconhece agora um primeiro termo exato inequívoco. GetMedia media job status result carrega assim GetMedia, sem recuar para uma suposição semântica ampla. Nomes curtos ambíguos permanecem propositadamente por resolver.
  • A cadeia de produção de media quebra nomes de etapa completos em linhas seguintes. O último passo já não é cortado na margem direita.
  • A alteração melhora a seleção de ferramentas e a legibilidade. Não altera nem o modelo de media nem a qualidade de imagem e não afirma nenhuma pré-visualização real de media.

Melhorias desde 9.1.57

VersãoAlteração
9.1.177As atualizações automáticas herdam agora um modo guardado de continuação ou reinício também quando a mensagem direta de processo não chega, e mostram um aviso claro imediatamente antes do reinício seguro da TUI. Placeholders históricos para argumentos de ferramentas compactados são removidos como JSON compacto, JSON formatado ou objeto lido, antes de poderem ser executados novamente. O histórico bruto e todos os mecanismos de proteção de atualização existentes permanecem inalterados.
9.1.176Todos os menus de seleção para comandos slash separam agora as opções com uma linha em branco e mostram explicações numa segunda cor própria e discreta. O componente comum alimenta 20 chamadas de menu; cores de aviso individuais permanecem.
9.1.175O aviso de ferramentas repetido em cada pedido de modelo desce de 1 749 para 825 caracteres. Na medição, isso poupa cerca de 231 tokens de entrada estimados por pedido. Todos os onze deveres de comportamento permanecem; histórico bruto, esquemas de ferramentas e ficheiros permanecem inalterados.
9.1.174O excerto de Mistake.md relevante mostrado por pedido de modelo está limitado a 3 000 em vez de 4 000 caracteres. Em 100 pedidos reais, isso poupa em média cerca de 253 tokens de entrada estimados; os títulos selecionados permaneceram idênticos em todos os 100 casos. Ficheiros completos e histórico guardado permanecem inalterados.
9.1.173BLUN King reconhece respostas de texto puro recorrentes ao longo de vários turnos Telegram. Após três respostas quase iguais apesar de novos avisos de utilizador, o agente recebe uma vez um aviso interno de correção, em vez de voltar a emitir uma pergunta antiga, lista ou fila de espera. Mensagens, processos e histórico guardado permanecem inalterados.
9.1.172A atualização automática verifica novamente uma sessão em execução após uma pesquisa sem resultado no arranque. A verificação seguinte ocorre distribuída aleatoriamente após 60 a 90 segundos. Assim, versões publicadas mais tarde são reconhecidas sem reinício manual. Instalação e passagem de sessão continuam a aguardar inatividade completa.
9.1.171BLUN King mantém por turno apenas os quatro esquemas de ferramentas recarregados por último, em vez de doze. Ferramentas mais antigas permanecem encontráveis via ToolSearch e são recarregadas na seleção. Ferramentas de núcleo carregadas de forma persistente, o histórico guardado e o comportamento de execução permanecem inalterados.
9.1.170Reúne os erros atuais de fiabilidade e de fluxo de trabalho: tarefas recorrentes mantêm a instrução sobredimensionada mais recente; placeholders de argumentos de ferramentas compactados são removidos da projeção de modelo; a ToolSearch reconhece palavras de pesquisa naturais de memória, incluindo a palavra isolada «store»; a apresentação do loop recarrega o estado de planeamento; /update controla a passagem segura em inatividade; e /premortem disponibiliza uma análise de erro visível e estruturada.
9.1.169BLUN King mantém a seleção exata de ferramentas e a anterior pesquisa rigorosa por palavra-chave inalteradas. Apenas quando esta pesquisa não fornece nenhum acerto, uma segunda execução estreita procura termos relacionados alemães e ingleses. Exigências de nome com + permanecem obrigatórias; pelo menos dois termos com significado e 75 por cento do pedido têm de corresponder. Assim, as três pesquisas Telegram realmente falhadas encontram a ferramenta de fila atual, enquanto um pedido inadequado continua a terminar sem acerto.
9.1.168BLUN King já não substitui argumentos mais antigos de chamadas de ferramentas por um placeholder interno que o modelo possa copiar para uma nova chamada. Chamadas placeholder já existentes e os seus resultados de erro correspondentes são removidos apenas da projeção de modelo; o histórico de sessão inalterado permanece como prova.
9.1.167BLUN King 9.1.167 mantém, em tarefas planeadas recorrentes, apenas uma sequência sem lacunas das secções de trabalho completas mais recentes. Se a próxima secção mais recente ultrapassasse o limite de 48 000 caracteres ou 24 mensagens, a seleção termina, em vez de voltar a incluir depois secções pequenas mais antigas. Assim, o contexto e a ordem temporal permanecem coerentes. Num histórico em execução medido, o histórico projetado desceu de 32 591 para 16 981 caracteres. Isso poupa 15 610 caracteres, ou seja, cerca de 3 903 tokens de entrada estimados por pedido comparável. Histórico bruto, passos de tarefa atuais e o resumo de compactação permanecem inalterados.
9.1.166BLUN King 9.1.166 limita tarefas planeadas recorrentes a um contexto de trabalho isolado, em vez de voltar a transmitir em cada passo de modelo toda a conversa do agente principal. A tarefa atual, o resumo de compactação mais recente e os passos de trabalho reais mais recentes permanecem disponíveis dentro de um limite de 24 mensagens e 48 000 caracteres. O histórico guardado, turnos normais de utilizador, lembretes únicos e caminhos de conversa rápidos permanecem inalterados. Num histórico medido, 2 043 passos de modelo de tarefas planeadas recorrentes consumiram no total 298,7 milhões de tokens de entrada, em média 146 188 tokens por passo.
9.1.165BLUN King 9.1.165 limita o orçamento de saída de turnos normais a 24 576 em vez de 32 768 tokens. Passos leves mantêm o seu valor limite anterior de 8 192 tokens, modelos com limites de saída menores mantêm esses valores mais baixos, e uma definição expressa de utilizador continua a ter prioridade. De 27 049 respostas medidas, 99 por cento permaneceram abaixo de 9 970 tokens; doze antigos outliers atingiam exatamente o limite anterior de 32 768 tokens e calculavam, cada um, cerca de seis minutos a mais.
9.1.164BLUN King 9.1.164 limita o orçamento de saída de uma compactação em grandes janelas de modelo a 16 384 em vez de 131 072 tokens. 39 compactações bem-sucedidas precisaram de, no máximo, 10 781 tokens de saída. O novo enquadramento está 52 por cento acima desse máximo medido e reduz a necessidade possível de saída e de cache KV por compactação em 87,5 por cento. Histórico guardado e turnos normais de conversa permanecem inalterados.
9.1.163BLUN King 9.1.163 substitui cargas de skills extensas fora das últimas 20 mensagens, na projeção de modelo, por uma referência compacta de recarga. Cargas atuais, pequenas e não recarregáveis permanecem inalteradas; o histórico de conversa guardado não é reescrito. Num caso medido, uma carga de skill desce de 87 034 para 424 caracteres projetados. Assim que sai da janela de trabalho atual, isso poupa 86 610 caracteres, ou seja, cerca de 21 653 tokens de entrada estimados.
9.1.162BLUN King 9.1.162 limita grandes vistas do diretório de trabalho no prompt de sistema repetido a 2 000 caracteres. Vistas pequenas permanecem inalteradas. Em vistas encurtadas, um aviso claro continua a indicar a pesquisa completa com Glob, Grep e Read. Num prompt medido, a vista desce de 3 988 para 1 983 caracteres. Isso poupa 2 005 caracteres, ou seja, cerca de 501 tokens de entrada estimados por pedido igualmente estruturado.
9.1.161BLUN King 9.1.161 já não repete os nomes das 112 ferramentas externalizadas em cada descrição de ToolSearch. A pesquisa por palavra-chave, a seleção exata com base no nome curto completo ou inequívoco e o carregamento persistente dos doze esquemas selecionados por último permanecem. Na representação medida, a descrição repetida desce de 1 984 para 278 caracteres. Isso poupa 1 706 caracteres, ou seja, cerca de 426 tokens de entrada estimados por pedido igualmente estruturado.
9.1.160A partir de BLUN King 9.1.160, a projeção de modelo protege integralmente apenas as doze mensagens mais recentes, antes de resultados de ferramentas mais antigos bem-sucedidos, que contêm exclusivamente texto, serem substituídos por uma nota curta de conclusão. Saídas de erro, media, referências de ficheiros guardados, as doze mensagens mais recentes, histórico bruto e exportações permanecem inalterados. Num snapshot de sessão medido de forma estável, mais dois resultados de ferramentas antigos são assim reduzidos. A projeção de modelo desce de 81 800 para 78 402 caracteres. Isso poupa mais 3 398 caracteres, ou seja, cerca de 850 tokens de entrada estimados por pedido igualmente estruturado.
9.1.159A partir de BLUN King 9.1.159, argumentos JSON válidos de chamadas de ferramentas concluídas fora das 12 mensagens mais recentes são substituídos na projeção de modelo por uma nota curta. O resultado de ferramenta correspondente, as 12 mensagens mais recentes, chamadas não concluídas, argumentos pequenos ou inválidos, histórico bruto e exportações permanecem inalterados. Num snapshot de sessão medido de forma estável, três argumentos de chamadas de ferramentas concluídas são reduzidos de 2 849 para 165 caracteres. Isso poupa 2 684 caracteres, ou seja, cerca de 671 tokens de entrada estimados por pedido igualmente estruturado.
9.1.158A partir de BLUN King 9.1.158, mensagens de estado puras que seguem imediatamente uma resposta Telegram concluída são substituídas, fora das 20 mensagens mais recentes, na projeção de modelo, por uma nota curta. A chamada de resposta enviada e o seu resultado, mensagens atuais, resumos após outras ferramentas, conteúdos mistos, histórico bruto e exportações permanecem inalterados. Num snapshot de sessão medido de forma estável, seis mensagens de estado históricas são reduzidas em 1 837 caracteres. Isso poupa cerca de 460 tokens de entrada estimados por pedido igualmente estruturado.
9.1.157A partir de BLUN King 9.1.157, saídas de ferramentas adequadas, bem-sucedidas e exclusivamente baseadas em texto fora das 20 mensagens mais recentes são substituídas na projeção de modelo por uma nota curta de conclusão. Saídas de erro, media, referências de ficheiros externalizadas, as 20 mensagens mais recentes, histórico bruto e exportações permanecem inalterados. Num snapshot de sessão medido de forma estável, 43 resultados antigos são reduzidos. Isso poupa 9 680 caracteres, ou seja, cerca de 2 420 tokens de entrada estimados por pedido igualmente estruturado.
9.1.156A partir de BLUN King 9.1.156, referências guardadas a mensagens de utilizador fora das 20 mensagens mais recentes já não repetem a sua pré-visualização com início e fim em cada pedido de modelo. Marcação de restauração, indicações de tamanho, caminho de ficheiro legível, as 20 mensagens mais recentes, media, histórico bruto, ficheiro completo guardado e exportações permanecem inalterados. Num snapshot medido de forma estável, cinco referências históricas são reduzidas e a projeção de modelo desce de 99 143 para 96 001 caracteres. Isso poupa mais 3 142 caracteres, ou seja, cerca de 786 tokens de entrada estimados por pedido igualmente estruturado.
9.1.155A partir de BLUN King 9.1.155, referências guardadas a mensagens de utilizador são restauradas antes de projeções de texto poderem alterar o hash da mensagem original. As externalizações existentes permanecem assim eficazes, em vez de voltarem despercebidamente à mensagem completa projetada. Histórico bruto, referências de ficheiros que podem ser relidas, as 20 mensagens mais recentes, media e exportações permanecem inalterados. Num snapshot medido de forma estável, a projeção de modelo desce de 105 810 para 99 143 caracteres. Isso poupa mais 6 667 caracteres, ou seja, cerca de 1 667 tokens de entrada estimados por pedido igualmente estruturado.
9.1.154A partir de BLUN King 9.1.154, secções de canal Telegram endereçadas fora das 20 mensagens mais recentes são limitadas a uma pré-visualização de 500 em vez de 1 000 caracteres, com início e fim. Metadados de canal completos, início e fim do conteúdo de mensagem, as 20 mensagens mais recentes, anexos, histórico bruto e exportações permanecem inalterados. Num snapshot medido de forma estável, mais sete secções históricas endereçadas são reduzidas. Isso poupa 3 500 caracteres, ou seja, cerca de 875 tokens estimados por pedido repetido.
9.1.153A partir de BLUN King 9.1.153, a projeção de contextos Telegram históricos preserva os metadados de canal completos e a tag de canal de fecho. Só é encurtado o conteúdo de mensagem. Mesmo com metadados Telegram reais de 161 caracteres, a estrutura permanece válida dentro do orçamento de 250 caracteres. A projeção é idempotente, canais endereçados seguintes permanecem inalterados, e um envelope de canal que, já sem conteúdo, ultrapasse o orçamento é passado inalterado.
9.1.152A partir de BLUN King 9.1.152, argumentos de chamadas de ferramentas concluídas saem da projeção de modelo ativa após quatro em vez de oito mensagens mais recentes. O histórico bruto de sessão, chamadas não respondidas ou mal formatadas, media, resultados de ferramentas e as quatro mensagens mais recentes permanecem inalterados. Num snapshot de sessão medido recentemente, mais duas chamadas concluídas são compactadas; face a 9.1.151, isso poupa mais 244 caracteres, ou seja, cerca de 61 tokens estimados por pedido repetido.
9.1.151A partir de BLUN King 9.1.151, argumentos de chamadas de ferramentas concluídas saem da projeção de modelo ativa após oito em vez de doze mensagens mais recentes. O histórico bruto de sessão, chamadas não respondidas ou mal formatadas, media, resultados de ferramentas e as oito mensagens mais recentes permanecem inalterados. Num snapshot de sessão medido, mais três chamadas concluídas são compactadas; face a 9.1.150, isso poupa mais 317 caracteres, ou seja, cerca de 80 tokens estimados por pedido repetido.
9.1.150A partir de BLUN King 9.1.150, a externalização histórica de resultados de ferramentas protege integralmente as quatro mensagens mais recentes, em vez das oito mais recentes. Resultados de ferramentas mais antigos e adequados mantêm um aviso compacto de restauração com 600 caracteres e o seu caminho de fonte; histórico bruto, saídas completamente guardadas, media e as quatro mensagens mais recentes permanecem inalterados. Num snapshot de sessão medido, a janela de quatro mensagens externaliza mais nove resultados históricos e poupa, face a 9.1.149, mais 6 683 caracteres, ou seja, cerca de 1 671 tokens estimados por pedido repetido.
9.1.149A partir de BLUN King 9.1.149, a externalização histórica de resultados de ferramentas protege integralmente as oito mensagens mais recentes, em vez das doze mais recentes. Resultados de ferramentas mais antigos e adequados mantêm um aviso compacto de restauração com 600 caracteres e o seu caminho de fonte; histórico bruto, saídas completamente guardadas, media e as oito mensagens mais recentes permanecem inalterados. Num snapshot de sessão medido, três resultados descem de 4 679 para 1 800 caracteres; isso poupa mais 2 879 caracteres, ou seja, cerca de 720 tokens estimados por pedido repetido.
9.1.148A partir de BLUN King 9.1.148, também no pacote Telegram misto mais recente são reduzidas as secções de canal expressamente marcadas com addressed=false. Secções endereçadas, media, histórico bruto e exportações permanecem inalterados. Num histórico medido, onze secções não endereçadas descem de 22 691 para 2 750 caracteres; isso poupa 19 941 caracteres, ou seja, cerca de 4 986 tokens estimados por pedido repetido.
9.1.147A partir de BLUN King 9.1.147, a microcompactação protege integralmente as doze mensagens mais recentes, em vez das vinte mais recentes, e utiliza assim a mesma janela de restauração que a externalização de resultados de ferramentas existente. Argumentos de ferramentas concluídos mais antigos e resultados de ferramentas adequados são reduzidos apenas na projeção de modelo; histórico bruto e caminhos de restauração permanecem inalterados. Num histórico medido, isso poupa mais 560 caracteres, ou seja, cerca de 140 tokens estimados por pedido.
9.1.146A partir de BLUN King 9.1.146, resultados de ferramentas mais antigos já externalizados são limitados na projeção de modelo às indicações necessárias para a restauração: nome de ferramenta, número de caracteres e caminho de ficheiro. O conteúdo completo permanece inalterado no disco, o histórico bruto não é alterado e as doze mensagens mais recentes mantêm os seus avisos detalhados. Num histórico medido, isso reduz a entrada de modelo repetida em 26 779 caracteres, ou seja, cerca de 6 695 tokens estimados por pedido.
9.1.145A partir de BLUN King 9.1.145, um stream de provider interrompido é automaticamente repetido quando até então chegou exclusivamente saída de thinking interna. Texto visível e chamadas de ferramentas continuam a impedir uma repetição automática. Passos de seguimento adaptativos com nível de thinking baixo utilizam um orçamento de saída de 8 192 tokens; primeiros passos, complexos e falhados mantêm o orçamento configurado, e uma repetição após atingir o limite de comprimento pode aumentá-lo. Ao continuar uma sessão, o aviso atual de transporte do plugin Telegram já não aparece como texto de chat bruto.
9.1.1449.1.144 limita secções Telegram endereçadas fora das 20 mensagens mais recentes, na projeção de modelo, a uma pré-visualização de 1 000 caracteres com início e fim. As 20 mensagens mais recentes, a mensagem de utilizador mais recente, secções na fronteira exata, anexos, metadados de canal, histórico bruto e exportações permanecem inalterados.
9.1.1439.1.143 remove em mensagens mais antigas o aviso repetido de transporte do plugin Telegram da projeção de modelo. Conteúdo de canal, metadados, anexos, mensagem de utilizador mais recente, histórico bruto e exportações permanecem inalterados.
9.1.1429.1.142 reduz a pré-visualização com início e fim para partes de canal Telegram mais antigas e não endereçadas, na projeção de modelo, de 500 para 250 caracteres. Partes de canal endereçadas, a mensagem de utilizador mais recente, anexos, histórico bruto e exportações permanecem inalterados.
9.1.1419.1.141 remove argumentos de chamadas de ferramentas mais antigas e concluídas, na projeção de modelo, já a partir de 32 tokens estimados. Resultados de ferramentas mantêm o seu limiar anterior; mensagens novas e o histórico bruto permanecem inalterados.
9.1.1409.1.140 limita o lembrete Mistake baseado em relevância, na projeção de modelo, por predefinição a 4 000 caracteres. Ficheiros Mistake completos, histórico bruto e exportações permanecem inalterados.
9.1.1399.1.139 limita partes de canal Telegram mais antigas e não endereçadas, na projeção de modelo, a uma pré-visualização de 500 caracteres. A mensagem de utilizador mais recente, partes endereçadas, anexos, histórico bruto e exportações permanecem completos.
9.1.1389.1.138 mantém, de cada tarefa cron recorrente, apenas o aviso de despertar mais recente na projeção de modelo. Lembretes únicos, tarefas diferentes, histórico bruto e exportações permanecem inalterados.
9.1.1379.1.137 protege apenas as doze mensagens mais recentes, integralmente, contra a externalização de saídas de ferramentas mais antigas. Resultados completos permanecem restauráveis através do histórico bruto e do caminho de fonte.
9.1.1369.1.136 mantém, na projeção de modelo, apenas o aviso dinâmico mais recente de Mistake.md. Seleções mais antigas permanecem completamente conservadas no histórico bruto e nas exportações.
9.1.135BLUN King 9.1.135 mantém o runtime Node.js gerido em primeiro lugar no PATH, no processo substituto e em todas as ferramentas subordinadas. Comandos como node e npm utilizam assim o mesmo runtime suportado que a TUI, em vez de recaírem numa instalação de sistema mais antiga.
9.1.1349.1.134 limita mensagens de grupo Telegram não endereçadas, na projeção de modelo, a uma pré-visualização de 2 000 caracteres com início, fim e comprimento original conservados. Mensagens diretas e o histórico guardado permanecem completos.
9.1.1339.1.133 seleciona, do Mistake.md local do projeto e do comum, no máximo cinco entradas completas relevantes dentro de um orçamento comum de 6 000 caracteres. As fontes completas e os caminhos de armazenamento permanecem.
9.1.1329.1.132 mantém ativo o prompt de sistema base enxuto, com 4 850 caracteres, após a inicialização gerada. Isso poupa, por pedido, 18 259 caracteres, ou seja, cerca de 4 565 tokens estimados, sem remover instruções ou ferramentas.
9.1.1319.1.131 remove duas cópias de regras mais antigas da projeção de modelo, assim que existem as contrapartes decisivas. O prompt padrão desce assim 1 010 caracteres, ou seja, cerca de 253 tokens estimados por pedido.
9.1.1309.1.130 substitui, fora das últimas 20 mensagens, o texto explicativo de passos de ferramentas mais antigos e completamente concluídos por um aviso curto. Chamadas de ferramentas, resultados, histórico bruto e exportações permanecem completamente conservados.
9.1.1299.1.129 remove textos de pré-visualização de resultados de ferramentas mais antigos já externalizados. Caminho e indicações de tamanho permanecem visíveis; o conteúdo completo permanece no ficheiro original ou no arquivo privado.
9.1.1289.1.128 limita a cache persistente de esquemas de ferramentas recarregados às doze ferramentas selecionadas por último. Ferramentas removidas da cache permanecem imediatamente encontráveis via ToolSearch.
9.1.1279.1.127 encurta o catálogo ToolSearch repetido. Ferramentas inequívocas aparecem com o seu seletor curto; espaços de nomes MCP completos permanecem apenas em conflitos de nomes.
9.1.1269.1.126 seleciona, do ficheiro de erros de todo o runtime, deterministicamente no máximo cinco secções adequadas à conversa atual. A projeção está limitada a 6 000 caracteres e não precisa de nenhum pedido adicional de modelo ou rede.
9.1.1259.1.125 acrescenta o comando Telegram exclusivamente de leitura /status para utilizadores emparelhados. Ele indica estado de computador, versão, processo e fila, sem emitir IDs de chat, caminhos, segredos ou conteúdos de mensagem.
9.1.1249.1.124 corrige as cores de marca trocadas no símbolo BLUN compacto por baixo do campo de entrada. Valores de estado, nome de perfil e persona permanecem inalterados.
9.1.1239.1.123 remove os grandes argumentos JSON de chamadas de ferramentas mais antigas e concluídas da projeção de modelo. Nome, identificação, resultado, histórico bruto e exportações permanecem completos.
9.1.1229.1.122 carrega a diretriz completa de design apenas em trabalho visual, através da ferramenta de skill. Pedidos não visuais recebem um contrato de ativação compacto; saídas de texto puro mais antigas são, ao mesmo tempo, externalizadas de forma mais eficaz.
9.1.1219.1.121 limita o tamanho total de saídas de texto puro mais antigas de ferramentas. Resultados adequados são arquivados de forma privada e substituídos na projeção de modelo por referências de ficheiro legíveis.
9.1.1209.1.120 externaliza grandes respostas de assistant mais antigas para ficheiros de sessão privados. As últimas 20 mensagens, cadeias de ferramentas e o histórico bruto completo permanecem.
9.1.1199.1.119 envia, em cada passo de modelo, apenas uma pequena seleção de skills frequentemente necessários. Todos os outros skills permanecem encontráveis através da ferramenta de skill, pelo seu nome ou finalidade.
9.1.1189.1.118 mantém o carimbo temporal de sessão no prompt de sistema estável durante uma sessão em execução. Partes de prompt inalteradas podem, assim, continuar a reutilizar a cache de prefixo do fornecedor.
9.1.1179.1.117 mantém as quatro ferramentas de núcleo para media imediatamente disponíveis e carrega compreensão de imagem e vídeo, sincronização de vídeo e sincronização de movimento dos lábios apenas quando necessário, via ToolSearch.
9.1.1169.1.116 acrescenta uma compactação proativa a partir de cerca de 128 000 tokens de entrada estimados, numa fronteira de passo segura. A compactação utiliza um prompt de sistema próprio enxuto; grandes resultados Read utilizam o seu caminho de fonte existente.
9.1.115Sessões continuadas reconstroem o prompt de sistema do perfil atual, para que snapshots de prompt sobredimensionados e desatualizados não persistam através de reinícios. Vistas grandes de pastas de trabalho são limitadas; os ficheiros completos permanecem disponíveis via Glob, Grep e Read.
9.1.114A entrega Telegram trata agora o Windows-EPERM como indício de um processo TUI ou poller em execução, em vez de desviar mensagens da sessão visível. A ToolSearch confirma uma ferramenta já carregada com correspondência exata de nome, em vez de comunicar falsamente que falta uma ferramenta a recarregar apenas quando necessário.
9.1.113As ferramentas Telegram mantêm, no arranque, um caminho substituto dentro do mesmo runtime, caso o registo gerido de plugins falte temporariamente.
9.1.112Mensagens de utilizador grandes e mais antigas são arquivadas fora da janela de trabalho atual; o histórico bruto completo permanece disponível.
9.1.111Turnos Telegram com anexos recebem download_attachment automaticamente. Em turnos normais, a ferramenta permanece externalizada via ToolSearch, para que a carga de esquema reduzida se mantenha.
9.1.110As repetições após uma sobrecarga do provider respeitam a indicação Retry-After do servidor. A configuração automática do ripgrep descarrega os ficheiros fixados da versão 15.0.0 da publicação oficial do ripgrep e verifica as suas somas de verificação SHA-256 antes da instalação.
9.1.109A versão 9.1.109 mantém de forma persistente no pedido de modelo apenas as nove ferramentas às quais se referiam mais de 98 por cento das 3 183 chamadas de ferramentas medidas. Todas as outras ferramentas permanecem encontráveis via ToolSearch e disponíveis para o resto da sessão após o primeiro carregamento. Assim, a carga de esquemas desce em cada passo de modelo normal, sem remover nenhuma ferramenta nem alterar o caminho rápido para respostas Telegram e resultados de media pendentes.
9.1.108Avisos de sistema idênticos e repetidamente introduzidos são fundidos apenas na projeção de modelo. Avisos alterados e o histórico completo guardado permanecem.
9.1.107Erros do provider são apresentados em linguagem compreensível para o cliente; códigos de erro internos e avisos de suporte não aparecem. /help oferece uma lista de comandos controlável com as teclas de seta e abre, com a seta para a direita ou a tecla Enter, uma descrição detalhada do comando selecionado.
9.1.106Os perfis de agente podem excluir ferramentas pelo nome. As exclusões atuam também após o recarregamento dinâmico; os subagentes padrão não enviam mensagens Telegram contornando o agente principal.
9.1.105A versão 9.1.105 acrescenta TaskUpdate para agentes de fundo em execução. O King transmite instruções adicionais no próximo passo de modelo seguro ao mesmo agente ativo, sem o parar nem iniciar outro agente. Tarefas desconhecidas e já concluídas, tarefas de shell e agentes que já não aceitam atualizações são recusados inalteradamente.
9.1.104A versão 9.1.104 deixa comandos de shell em primeiro plano correrem até ao fim regular, também com saídas muito grandes. O King escreve continuamente até 16 MiB no registo privado de tarefa, descarta saídas além disso e comunica o código de exit real, em vez de terminar o processo por causa da quantidade de saída. Saídas pequenas, tarefas de fundo, limites de tempo e cancelamentos manuais permanecem inalterados.
9.1.103Membros de enxame são retomados, após interrupções temporárias do provider, no máximo duas vezes com o mesmo ID de agente. O HTTP 429 mantém a sua regra separada de sobrecarga; erros definitivos e cancelamentos manuais não são repetidos automaticamente.
9.1.102Agentes individuais delegados são retomados, após erros temporários do provider, no máximo duas vezes com base no seu histórico persistente. Erros persistentes e cancelamentos manuais permanecem definitivos.
9.1.101Mensagens de utilizador sobredimensionadas são guardadas localmente e substituídas no contexto de modelo por uma pré-visualização limitada com caminho legível. O histórico original completo e os media permanecem.
9.1.100Pesquisas de conteúdo Grep limitadas terminam o ripgrep após a página solicitada e uma linha de pré-visualização adicional. Contagens de acertos, pesquisas ilimitadas e listas de ficheiros ordenadas pela hora de modificação permanecem completas.
9.1.98O King pode compactar proativamente uma secção de trabalho concluída a partir de 128 000 tokens estimados. Abaixo do limiar, o esquema de ferramenta permanece completamente fora do prompt de modelo; a compactação utiliza a transição de passo segura existente.
9.1.97A descrição da ferramenta TodoList carregada de forma persistente desceu de 2 238 para 996 caracteres. Planeamento em várias etapas, todos os seis estados de tarefa, relatórios honestos de progresso, consultas, esvaziamento e o modo de plano separado permaneceram protegidos.
9.1.96O prompt de sistema base carregado de forma persistente desceu de 23 109 para 4 850 caracteres. Identidade, persona e alma, língua de resposta, limites de trabalho e de autorização, passagem de compactação, ambiente de runtime, AGENTS.md e skills permaneceram protegidos.
9.1.95A descrição da ferramenta Write carregada de forma persistente desceu de 2 532 para 1 541 caracteres. A delimitação face ao Edit, conteúdos literais, fins de linha, o limite de 500 linhas, a exceção de ficheiro único e a continuação atómica com verificação de linhas e SHA-256 permaneceram protegidos.
9.1.94A descrição da ferramenta Glob carregada de forma persistente desceu de 1 495 para 1 006 caracteres. Ordenação, ficheiros ignorados e sensíveis, padrões recursivos, ficheiros com ponto, expansões de chavetas e o limite de 100 acertos permaneceram protegidos.
9.1.93A descrição da ferramenta Edit carregada de forma persistente desceu de 1 537 para 1 144 caracteres. Ler antes de alterar, substituições exatas, substituições múltiplas, tratamento CRLF e o limite de 500 linhas permaneceram protegidos.
9.1.92A descrição da ferramenta Agent carregada de forma persistente desceu de 2 061 para 1 153 caracteres. Contexto separado, continuação, limites de tempo e delegação paralela permaneceram.
9.1.91A descrição da ferramenta Read carregada de forma persistente desceu de 2 391 para 1 648 caracteres. Paginação, proteção de segredos, reencaminhamento de media, formato de linha e comportamento CRLF permaneceram.
9.1.90A descrição da ferramenta Bash carregada de forma persistente desceu de 5 003 para 1 834 caracteres. Contrato de runtime, tarefas de fundo, ferramentas de ficheiros e limites de segurança mantiveram-se integralmente.
9.1.89Leituras de ficheiros página a página indicam, no limite interno de 1 000 linhas, o próximo line_offset exato; fim de ficheiro e excertos deliberadamente mais pequenos permanecem inalterados.
9.1.88BLUN King 9.1.88 ativa a compactação pequena e sem perdas a tempo, antes da compactação completa. Resultados de ferramentas grandes mais antigos e argumentos de ferramentas concluídos deixam a vista de modelo mais cedo; o histórico completo guardado permanece.
9.1.87Uma resposta HTTP 429 expressamente repetível respeita Retry-After e recebe, no máximo, duas repetições automáticas; outros erros permanecem imediatamente visíveis.
9.1.86Saídas de ferramentas grandes mantêm, dentro do mesmo orçamento de pré-visualização, 1 000 caracteres do início e do fim visíveis; uma marcação exata indica o número de caracteres omitidos.
9.1.85Resultados de ferramentas baseados em texto acima de 12 000 caracteres são guardados completamente num ficheiro local privado; pedidos de modelo seguintes mantêm apenas um orçamento de pré-visualização de 2 000 caracteres e o caminho legível.
9.1.84A compactação completa processa históricos mais antigos em etapas cronológicas com, no máximo, 64 000 tokens de entrada estimados; o limite de segurança fixo e o arquivo privado completo permanecem inalterados.
9.1.83A microcompactação substitui argumentos grandes de chamadas de ferramentas mais antigas e concluídas apenas na vista de modelo por uma marcação JSON válida; o verificador de sessão comunica a poupança estimada sem saída de conteúdo.
9.1.82O verificador exclusivamente de leitura comunica esquemas de ferramentas selecionados e retidos, motivos de supressão e o número estimado de tokens de esquema evitados.
9.1.81Um verificador incluído, exclusivamente de leitura, resume passos de provider, chamadas de ferramentas, tokens, compactações, erros e saídas externalizadas, sem expor prompts ou caminhos privados.
9.1.80Resultados de ferramentas grandes recebem telemetria de externalização sem conteúdo; contexto isolado de subagentes, planos legíveis por máquina e handoffs transferíveis são protegidos por testes de regressão.
9.1.79Checkpoints persistentes fixam registos de histórico concluídos antes de passos de provider e antes da conclusão de um worker, para que trabalho concluído possa ser lido novamente após uma continuação.
9.1.78A compactação completa arquiva partes de histórico deslocadas antes de as substituir por um resumo; o resumo contém o caminho de arquivo legível.
9.1.77A microcompactação reduz, sob pressão de contexto, resultados de ferramentas grandes mais antigos e preserva simultaneamente o histórico completo guardado.
9.1.76Tarefas pendentes de imagem, vídeo e voz sobrevivem à compactação e a perguntas de seguimento rápidas; mensagens Telegram permanecem em ordem FIFO, sem erro enganador de busy.
9.1.75Conversas Telegram curtas processam apenas a mensagem mais recente não respondida, enquanto trocas de texto concluídas permanecem como contexto linguístico.
9.1.74Rotas Telegram guardadas repõem IDs de grupo passados por engano sem sinal de menos; Strg+S pode controlar um turno realmente em execução.
9.1.73Mensagens Telegram e de loop já não iniciam um segundo turno durante trabalho ativo; Escape e Ctrl+C podem continuar a cancelar o turno ativo.
9.1.72Ocultar um aviso de atualização suprime apenas a versão então oferecida; publicações mais recentes voltam a aparecer no arranque normal com king.
9.1.71Os despertadores de loop entram corretamente na fila, o poller Telegram é reivindicado atomicamente, ferramentas centrais de ficheiros e media permanecem imediatamente disponíveis e o Context7 já não inicia automaticamente.
9.1.69MCPs padrão são configurados, o Telegram atinge um ponto de passagem FIFO protegido, Escape e Ctrl+C cancelam de forma fiável trabalho ativo e a vista MCP oculta caminhos internos.
9.1.68Mensagens Telegram em inatividade acordam o processamento FIFO, mensagens diretas e de grupo mantêm a sua ordem de entrada e a continuação oculta envelopes Telegram internos.
9.1.67A Skill padrão venture-flywheel acrescenta uma base UVF puramente contratual, com confiança determinística de projeto e obrigações de aprovação para ações externas.
9.1.66/curiosity e /scout executam pesquisas de oportunidade limitadas e exclusivamente de leitura, com provas, contraprovas e um critério de interrupção.
9.1.65Escape e Ctrl+C cancelam de forma fiável compactações automáticas, uma âncora de ecrã estável impede rodapés duplicados e o aviso de loop está alinhado com o conteúdo do chat.
9.1.64Histórico de sessão baseado em disco, ferramentas e skills recarregados, um vigilante de inatividade do provider de 120 segundos, ritmo de loop correto, Telegram em ordem FIFO, pacotes Linux e reconhecimento de língua bósnia chegaram em conjunto.
9.1.58–9.1.63Esta série de versões reuniu trabalhos sobre sessões, Telegram, plataformas e desempenho. O remate foram esquemas de ferramentas enxutos sob pedido, listas de skills compactas, skills de primeira utilização restaurados e um controlo de inventário de pacotes contra remoções não planeadas.

Melhorias anteriores

VersãoAlteração
9.1.53/idea publica o seu plano de tarefas antes do primeiro trabalho, verifica ações externas em cada chamada de ferramenta e exige para cada passo um estado final honesto.
9.1.52Sessões continuadas abrem diretamente a pasta de trabalho guardada. Conversa e estado /loop ativo são repostos em conjunto no reinício.
9.1.51Loops funcionam como despertadores autónomos, /idea desenvolve e edita planos próprios, o Telegram pode desencadear comandos de trabalho, e estados de media e de arranque são apresentados de forma mais clara.
9.1.50Imagens recebidas localmente ou via Telegram podem ser animadas como verdadeiros vídeos MP4. Janelas de contexto grandes recebem um orçamento de saída válido; a barra de media mostra estados mais claros e caminhos clicáveis.
9.1.49Imagens de figuras de fantasia adultas em fatos de banho permanecem permitidas dentro de limites claros. Tarefas de imagem concluídas podem ser utilizadas como imagem de partida para vídeos; consultas GetMedia bem-sucedidas não geram cartões repetidos.
9.1.48A barra de media uniforme agrupa tarefas de media diretamente acima do campo de entrada. Valores percentuais aparecem apenas com um valor real medido do provider; caso contrário, mostra fase e tempo de execução.
9.1.47O registo de pedidos distingue conversas e compactação e regista a seleção de ferramentas e o motivo de supressão, sem alterar o comportamento das ferramentas.
9.1.46Loops compreendem indicações naturais de tempo, mostram-nas durante a entrada, suportam intervalos livres e libertam a seleção normal de texto no terminal fora da vista de histórico.
9.1.45O progresso de compactação em curso aparece apenas na barra de estado inferior, em vez de, adicionalmente, como segunda linha no chat.
9.1.44Reempacotamento completo do 9.1.43 aceite, para que também versões 9.1.43 instaladas cedo reconheçam a atualização com segurança.
9.1.43Base de proteção completa do 9.1.40 com diagnóstico de transporte, avisos de atualização visíveis e os comandos de consola /loop, /goal e /output-style.
9.1.40Vigilante de turnos para chamadas longas ou repetidamente falhadas; auto-hash após escrita multiparte com verificação de releitura do ficheiro guardado.
9.1.39Ficheiros longos são escritos em continuações. Cada continuação retoma a partir do fim realmente escrito; número de linhas, SHA-256 e fronteiras de fragmento são verificados e emitidos.
9.1.38Argumentos de ferramentas degenerados ou truncados são reconhecidos. Um ficheiro incompleto é recusado com mensagem de erro, em vez de valer silenciosamente como concluído.
9.1.37Após uma mudança de Node, a BLUN verifica módulos nativos com uma consulta SQLite real e reconstrói better-sqlite3 quando necessário.
9.1.36Respostas de modelo vazias são tratadas pela causa: orçamento de saída demasiado curto é aumentado, um stop vazio é repetido exatamente uma vez. Avisos de sistema e injeções não podem desencadear uma resposta Telegram.
9.1.35A compactação em várias etapas mostra a etapa e a utilização real da janela de modelo, por exemplo 2/~10 · 90 %.
9.1.34O contexto ativo é compactado por etapas: as partes mais antigas primeiro, cada chamada de compactação abaixo do limite de modelo.
9.1.33Base para o runtime Node automático e a reparação a jusante de módulos nativos após uma mudança de runtime.

Aditamentos e lacunas de documentação em aberto

Verificação cruzada de 17 de setembro de 2026: no intervalo 9.1.33 a 9.1.597 existem 521 versões no diretório npm. Um número em falta não é automaticamente uma publicação em falta: algumas versões faltam no diretório atual ou foram retiradas. Em quatro versões publicadas, os detalhes exatos de alteração permanecem em aberto. Não são inventadas alterações para estas versões.

9.1.567: detalhes de alteração em aberto

Publicado a 6 de setembro de 2026 às 22:42 UTC. O valor SHA-512 do pacote corresponde ao valor de integridade publicado no npm. O pacote não contém CHANGELOG.md; o seu README menciona ainda 9.1.566 no comando de instalação. A partir daí, a diferença face a 9.1.566 não pode ser derivada de forma fiável. Esta lacuna de documentação permanece expressamente em aberto.

9.1.550: detalhes de alteração em aberto

Publicado a 2 de setembro de 2026 às 07:19 UTC. O valor SHA-512 do pacote corresponde ao valor de integridade publicado no npm. O pacote não contém CHANGELOG.md e, no material verificado, não foi encontrada nenhuma prova de alteração específica da versão. Esta lacuna de documentação permanece expressamente em aberto.

Aditamento a 9.1.536

As indicações seguintes provêm do pacote publicado, com integridade verificada, de 1 de setembro de 2026:

  • As tarefas de trabalho continuam para além de respostas Telegram privadas. Após mensagens diretas em buffer, o King continua o trabalho com um passo adicional limitado, desde que o utilizador não pause nem pare expressamente.
  • Perguntas curtas de estado não interrompem o fluxo de trabalho em curso.
  • Quando as tentativas de repetição após respostas de thinking vazias estão esgotadas, o King reduz o esforço de thinking, em vez de o manter inalterado em novas tentativas.
  • Mais esquemas de ferramentas recarregados permanecem disponíveis; mensagens só são externalizadas quando o espaço disponível no histórico se torna escasso.
  • Estão incluídas a regra de progresso verificada para a TodoList e um caminho de arranque de uma linha para o modo God com enxame.

Aditamento a 9.1.99

A documentação de funções já existente descreve a externalização conjunta de resultados de ferramentas de texto puro consecutivos: quando a pilha ultrapassa 12 000 caracteres, resultados grandes adequados são guardados de forma privada. No contexto de modelo permanecem referências legíveis; histórico bruto e media permanecem. A entrada de versão até agora em falta remete agora expressamente para esta função.

9.1.70: detalhes de alteração em aberto

Publicado a 24 de agosto de 2026 às 15:56 UTC. O valor SHA-512 do pacote corresponde ao valor de integridade publicado no npm. O pacote não contém CHANGELOG.md; as descrições de funções existentes não comprovam nenhuma diferença inequívoca face a 9.1.69. Esta lacuna de documentação permanece expressamente em aberto.

9.1.57: detalhes de alteração em aberto

Publicado a 23 de agosto de 2026 às 07:28 UTC. A versão surgiu até agora apenas como ponto de partida de um cabeçalho coletivo. Uma prova de alteração própria e específica da versão não está atribuída no material verificado. Esta lacuna de documentação permanece expressamente em aberto.

O CHANGELOG.md contido no pacote npm imutável 9.1.597 termina em 9.1.594. Os avisos acrescentados sobre 9.1.595 a 9.1.597 estão nesta página. O pacote publicado não foi reescrito posteriormente sob o mesmo número de versão.

9.1.41 e 9.1.42 foram retirados

Não instalar

Estas duas versões foram, por engano, derivadas de 9.1.38 em vez de 9.1.40. Faltavam assim a continuação de escrita, o auto-hash e o vigilante de turnos. Ambas as versões npm estão marcadas como obsoletas; latest e next nunca apontaram para elas. O 9.1.43 contém as suas alterações pretendidas na base de proteção completa.

Atualizar e verificar

king update
blun --version

Após a instalação de 9.1.599, a saída de versão deve mostrar 9.1.599. As atualizações de 9.1.597 e da versão local 9.1.598 através das fontes de atualização públicas estão verificadas. Uma consola já em execução só carrega o novo código após o seu reinício. Depois, verifica também nela /version.