BLUN King

BLUN King 9.1.621

Publicado el

King solo adopta un resumen de tu conversación cuando el modelo ha confirmado que está completo. Si falta esta confirmación, tu historial de conversación anterior permanece sin cambios.

Si la transmisión del resumen termina de forma inesperada, tu contexto de conversación anterior no se sustituye por el resumen incompleto. El cambio solo afecta a la compactación de la conversación; las respuestas normales permanecen sin cambios.

Siguen abiertos algunos errores puntuales al guardar una sesión; no se han corregido con esta actualización.

BLUN King

BLUN King 9.1.620

Publicado el

En Windows, la consola finaliza completamente al cerrar la ventana, de modo que en el próximo inicio ya no aparezca «ya en ejecución».

La actualización corrige la finalización del proceso de la consola al cerrar la ventana. Una consola realmente aún en ejecución conserva el acceso exclusivo a su sesión.

La guía se ha completado para el estado 620: instalación en Linux, continuación de sesiones largas, la última sesión al inicio, Ctrl+L, Skills, plugins, objetivos y encargos sin interfaz. A la guía CLI actual.

BLUN King

BLUN King 9.1.619

Publicado el

Un único error anterior al compactar la conversación ya no bloquea tu sesión: tras un compactado correcto, King solo cuenta los errores nuevos directamente consecutivos. Si el compactado falla dos veces seguidas, el mensaje ahora indica claramente «compactación en pausa» en lugar de anunciar un contexto completo.

Siguen pendientes errores puntuales al guardar una sesión y al crear un resumen completo de la conversación; no se han corregido con esta actualización.

BLUN King

BLUN King 9.1.618

Publicado el

Si, después de continuar tu sesión, llega un mensaje de Telegram mientras King ya está trabajando, permanece en la cola y se entrega posteriormente. King ya no muestra esta situación de espera como un error.

En Linux x64, el terminal utiliza un binario incluido. Así, funciona incluso cuando npm 12 bloquea los scripts de instalación; para ello no se necesita ningún compilador. Con este fin, King utiliza la versión preliminar fijada node-pty 1.2.0-beta.15.

BLUN King

BLUN King 9.1.617

Publicado el

Al volver a cargar la misma sesión, King ya no añade varias veces las instrucciones de plugins que no han cambiado. Si las instrucciones cambian, King sigue teniendo en cuenta el estado actual.

Las vistas previas de salidas grandes de herramientas ahora también tienen en cuenta la ventana de contexto disponible. Puedes seguir leyendo por completo las salidas externalizadas.

Con /profile o /profiles abres la selección de perfil. King solo hace el cambio cuando tu sesión está lista. El trabajo en curso y los mensajes en espera impiden un cambio prematuro; en ese caso, tu perfil anterior sigue activo.

Si detienes un trabajo en curso, King espera también a los últimos pasos de limpieza. Un trabajo que aún no ha concluido no se confirma antes de tiempo como detenido.

BLUN King

BLUN King 9.1.616

Publicado el

Tras una respuesta de Telegram confirmada, King recoge otros mensajes dirigidos a ti en el siguiente paso seguro, incluso durante un turno en curso.

Tras una respuesta de Telegram confirmada, King recoge otros mensajes dirigidos a ti en el siguiente paso seguro, incluso durante un turno en curso. Una respuesta que ya se ha entregado deja de retener la cola. Las respuestas permanecen asignadas a su chat correspondiente.

Si interrumpes un turno, los mensajes de Telegram que aún no se han recogido se conservan para la siguiente entrega. King solo confirma su recepción cuando la sesión los recoge realmente.

BLUN King

BLUN King 9.1.615

Publicado el

King mantiene grandes catálogos de herramientas disponibles mediante la búsqueda de herramientas y ajusta el presupuesto de herramientas a la ventana de contexto del proveedor.

King mantiene grandes catálogos de herramientas disponibles mediante la búsqueda de herramientas, sin enviar al modelo todos los esquemas opcionales de herramientas. Si el proveedor comunica una ventana de contexto más pequeña, King ajusta el presupuesto de herramientas; las herramientas encontradas siguen disponibles en el siguiente paso.

Cuando es necesario, King externaliza las salidas grandes de herramientas antes de lo habitual. Puedes recuperar la salida completa como hasta ahora, siempre que pueda mostrarse de forma segura.

Las respuestas normales de Telegram y los cambios en los mensajes ya no se retienen por falta de una liberación de idioma. Una revisión de respuestas que hayas configurado sigue activa.

BLUN King

BLUN King 9.1.614

Publicado el

Los archivos AGENTS.md y AGENTS.override.md demasiado grandes ya no detienen un turno solo por su tamaño.

Fuera de la consola de King, King lee en total hasta 32 KiB de archivos de instrucciones y te dice una vez por sesión cuántos bytes se han omitido.

En la consola de King los archivos permanecen completos mientras el límite de solicitud lo permita.

Los enlaces simbólicos y las rutas no seguras permanecen bloqueados.

BLUN King

BLUN King 9.1.613

Publicado el

King reconoce las solicitudes al modelo demasiado grandes antes incluso de enviarlas.

En la consola de King, King lee como máximo 32 KiB de cada archivo AGENTS.md y AGENTS.override.md. Lo que supera ese límite, King lo omite y te muestra cuántos bytes se han omitido.

Antes de enviar, King ahora estima el tamaño de toda la solicitud al modelo, incluidas instrucciones, historial, definiciones de herramientas y datos de imagen. Si se acerca al límite de bytes del servidor, comienza una compactación gradual. Si una solicitud no se puede dividir de forma segura, King se interrumpe sin descartar silenciosamente el historial guardado.

King guarda localmente las llamadas a herramientas completadas como metadatos: nombre de la herramienta, momento, estado y, en el caso de herramientas de archivo, la ruta si procede. Las entradas, salidas, comandos y claves no se guardan. Con /memory tools puedes buscar en las entradas de tu perfil.

El diagnóstico de contexto muestra cifras adicionales sobre la composición de las solicitudes. Una medición de fases opcional registra el tiempo hasta la llamada al modelo sin registrar contenido.

El indicador de uso incluye los tokens de pensamiento notificados por separado, siempre que el proveedor los proporcione.

No lanzada, sustituida por 9.1.613

BLUN King 9.1.612

Publicado el

9.1.612 no se publicó como actualización para clientes. La protección temprana de bytes no actuaba en una solicitud superior a 900 KB cuando el historial por sí solo permanecía por debajo de 600 KB. 9.1.613 sustituye esta versión.

BLUN King

BLUN King 9.1.611

Publicado el

Las solicitudes de compactación grandes permanecen dentro del límite de bytes del servidor.

  • King divide una solicitud de compactación demasiado grande en pasos cronológicos según el tamaño de la solicitud. Así la compactación puede continuar aunque la solicitud contenga más bytes de los que el servidor acepta de una vez.
  • Si ni siquiera un único mensaje cabe bajo el límite, tu historial guardado permanece sin cambios. King no lo descarta para forzar la compactación.

Con ello no se demuestran tiempos de espera del modelo más cortos ni un menor consumo de tokens. Una actualización no reinicia una sesión de King ya en ejecución.

BLUN King

BLUN King 9.1.610

Publicado el

Puedes volver a instalar King en Linux y volver a iniciar perfiles, y un segundo arranque de King en Windows ya no falla con un mensaje engañoso sobre las ACL privadas.

  • Linux vuelve a estar en la lista de sistemas operativos compatibles del paquete npm. Si tienes una versión anterior en Linux, instalas 9.1.610 mediante el actualizador normal.
  • Los inicios explícitos con --profile y los atajos existentes de nombres de perfil llevan al directorio del perfil elegido. Un simple nombre desconocido ya no crea silenciosamente un perfil vacío; creas un perfil nuevo deliberadamente con --profile.
  • Si a un perfil existente le falta el acceso propio, King ofrece /login en lugar de detenerse por una configuración de modelo blun/king ausente.
  • En Windows, la comprobación de los directorios privados funciona también cuando el bridge de Telegram mantiene abierto un directorio de plugins. TEMP y TMP se pasan al asistente de ACL, y en errores de directorio King nombra la ruta afectada y la causa real.
  • Si ya se está ejecutando un King interactivo, King lo detecta antes del endurecimiento de las ACL privadas y comunica su PID, en lugar de presentar un segundo arranque como un error de las ACL privadas.

Un perfil vacío no hereda en 9.1.610 los datos de acceso del directorio home compartido. La consulta /login actual aún puede mostrar «OAuth login expired», incluso si este perfil nunca ha iniciado sesión.

La ruta de actualización de Linux de 9.1.114 a 9.1.610 se recorrió tras la publicación. La ruta de actualización de Windows de 9.1.609 a 9.1.610 no está medida.

Una actualización no reinicia una sesión de King ya en ejecución.

BLUN King

BLUN King 9.1.609

Publicado el

Abre la selección de esfuerzo con Ctrl+L y conserva tu borrador del editor.

  • Ctrl+L abre la selección de esfuerzo existente sin perder tu borrador del editor. Se reutilizan los ajustes de esfuerzo existentes y las limitaciones del modelo, en lugar de crear una segunda vía de configuración.
  • La regla existente para sesiones en ejecución se mantiene: un cambio de esfuerzo durante el trabajo activo se rechaza, no se anota para más tarde. Durante la reproducción o una toma de control del editor, el atajo de teclado se ignora.

Estos cambios no demuestran tiempos de respuesta más rápidos en el uso real ni un menor consumo de tokens facturado, y no logran una paridad completa con OpenClaw.

BLUN King

BLUN King 9.1.608

Publicado el

En los grupos de Telegram, ahora solo llegan a King los mensajes que lo mencionan. Tus selecciones múltiples y la cancelación gradual de preguntas se conservan.

  • En los grupos de Telegram, los mensajes que no se dirigen a King llegan al contexto de la sesión solo después de la comprobación de mención. Si has desactivado expresamente la comprobación, se mantiene desactivada.
  • Tus selecciones múltiples y la cancelación gradual de preguntas se conservan. El pie de página del objetivo funciona con un temporizador de actualización común.
  • El coste de la transferencia de ACL de Windows se reduce sin debilitar la comprobación de permisos. La recuperación tras errores temporales al reemplazar la configuración está limitada; la propiedad del proceso de escritura se conserva.
  • Antes del nuevo intento, King comprueba si un marcador de escritor de Windows eliminado en paralelo ha desaparecido realmente. Los marcadores existentes no legibles siguen provocando la interrupción.

Estos cambios no demuestran tiempos de respuesta más rápidos en el uso real ni un menor consumo de tokens facturado, y no logran una paridad completa con OpenClaw.

BLUN King

BLUN King 9.1.607

Publicado el

Vuelve la última sesión que elegiste, las escrituras fallidas se notifican con honestidad y cada intento HTTP recibe una marca de tiempo de inicio.

  • La restauración opcional de la última sesión elegida se puede activar con resume_last_selected en tui.toml. La selección se aplica a la cuenta confirmada, el runtime, el agente y el área de trabajo. El arranque normal permanece sin cambios y las elecciones de sesión explícitas tienen prioridad; si una selección no está disponible, se recurre a una sesión nueva, no a otra distinta.
  • Tras una activación fallida se conserva la selección anterior. Si la cuenta ha cambiado durante la activación, no se guarda ninguna selección.
  • Los procesos de escritura de archivos fallidos no se marcan como exitosos. El protocolo de continuación existente para líneas completas en escrituras de más de 2.048 bytes UTF-8 se explica, sin elevar el límite ni reintentar automáticamente.
  • Inmediatamente antes de cada intento HTTP se registra una marca de tiempo de inicio según el reloj de pared para correlacionar el diagnóstico. Ni el contenido de las solicitudes ni las credenciales llegan al diagnóstico.
  • Los caracteres Unicode fuera del plano básico (por ejemplo, emojis) se conservan completamente en los límites existentes del presupuesto de almacenamiento, sin elevar esos presupuestos ni crear otro almacenamiento.

Estos cambios no demuestran tiempos de respuesta más rápidos en el uso real ni un menor consumo de tokens facturado, no logran una paridad completa con el Gateway y no excluyen del contexto los mensajes de Telegram no dirigidos.

BLUN King

BLUN King 9.1.606

Publicado el

Al continuar una sesión aparecen primero las páginas de transcripción actuales; las páginas más antiguas las carga la navegación de transcripción existente.

  • Al continuar una sesión interactiva aparecen primero las páginas de transcripción actuales; las páginas más antiguas las carga la navegación de transcripción existente. El historial guardado completo y el contexto activo del modelo se conservan.
  • Al inicio se aplica un objetivo de visualización de 200 registros de reproducción. Con --history-limit de 1 a 2000 se puede ajustar la visualización de la primera página y de las más antiguas; las rondas de conversación completas y los pares de herramientas pueden superar el objetivo.
  • La primera visualización de activaciones de skills y plugins se conserva a través de los límites de página. La posición de desplazamiento de inicio está corregida, de modo que cargar páginas más antiguas no deja una pantalla vacía.

Estos cambios reducen el trabajo de renderizado inicial de la transcripción. No demuestran tiempos de respuesta del modelo más rápidos, ni menor consumo de tokens, ni facturas más bajas; no mejoran el almacenamiento en caché del proveedor y no limitan cuánto se lee del disco al inicio.

BLUN King

BLUN King 9.1.605

Publicado el

Comprueba las fuentes de contexto, controla las tareas en curso y pasa un primer mensaje al iniciar la consola. Se han ampliado el procesamiento del historial local y las comprobaciones de compactación.

  • Los historiales de sesión locales se reproducen agrupados. Las páginas de visualización archivadas se pueden encontrar sin tener que revisar todos los bloques anteriores. Se conservan el historial guardado íntegramente, las comprobaciones de integridad del archivo y el mecanismo de restauración existente.
  • Los resultados de herramientas repetidos se preparan de forma uniforme para el contexto del modelo entre compactaciones registradas. Las salidas locales completas y los derechos de lectura existentes se conservan. Las salidas no se externalizan si no pudieran volver a recuperarse a través de la vía de restauración prometida.
  • La compactación automática final solo sustituye el contexto activo si reduce el historial según el mismo método de estimación. Si se rechaza, se conserva el historial original. El activador opcional max_request_history_bytes utiliza el control de compactación existente, está desactivado por defecto y no limita el cuerpo completo de la solicitud al proveedor.
  • El diagnóstico de contexto incorpora vistas separadas y una atribución de fuentes para instrucciones, memoria, habilidades y mensajes anteriores. Los bytes del contenido serializado, las estimaciones locales de tokens y el consumo notificado permanecen separados.
  • La responsabilidad sobre la sesión se conserva ante tareas en espera, eventos retrasados, preguntas de seguimiento y cambios de configuración. Un segundo acceso de escritura activo a la misma sesión se rechaza en lugar de permitir cambios simultáneos en el registro.
  • La línea adicional de agente/sesión en el pie de página desaparece. Las sesiones se pueden seguir controlando y diagnosticando de forma selectiva. La interfaz existente de King, los modelos gestionados y los límites de permisos se conservan.
  • --message pasa un primer mensaje para el inicio interactivo. Se procesa a través de la comprobación de mensajes y la cola habituales tras la confirmación al inicio y la selección de sesión. Su contenido no se interpreta como comando de barra o de shell.
  • El contrato de interfaz del servicio Guard incluido permanece sin cambios. Esta publicación no demuestra respuestas más rápidas en funcionamiento real, ni facturas de proveedor más bajas, ni una equivalencia funcional completa con OpenClaw, ni un volumen de lectura limitado al cargar por primera vez el registro de sesión.

/abort interrumpe la tarea en curso sin descartar las entradas en espera. /stop descarta además las entradas en espera. /exit sigue cerrando la consola. Son comandos de consola locales, no comandos remotos adicionales de Telegram.

Comprobaciones sobre la versión del paquete 9.1.605: 238 archivos de prueba con 6.900 pruebas y 40 comprobaciones en staging, entre ellas 25 pruebas nativas de terminal. La prueba de una actualización aislada desde 9.1.604 mediante la etiqueta de candidato publicada y el instalador real fue satisfactoria. Esto no demuestra ni tiempos de calentamiento más cortos en una sesión en curso ni una equivalencia funcional completa con OpenClaw.

BLUN King

BLUN King 9.1.604

Publicado el

Comprueba el tamaño de la solicitud y las fuentes de contexto, carga las herramientas según sea necesario y controla los mensajes entrantes dentro de la sesión correspondiente.

  • /context doctor y /tokens distinguen la cantidad de bytes de la solicitud serializada de las cantidades estimadas de tokens y muestran las proporciones registradas de reglas, memoria, habilidades y definiciones de herramientas.
  • Los catálogos de herramientas medianos se cargan según sea necesario mediante la búsqueda existente; las herramientas siguen siendo localizables y ejecutables.
  • /queue controla los mensajes dentro de la sesión correspondiente. Los mensajes normales en la cola ya no interrumpen automáticamente el trabajo después de 30 segundos.
  • En la selección de sesión se admiten identificadores o títulos exactos, así como prefijos de identificador inequívocos; el pie de página muestra el agente y la sesión asignados.
  • Cada intento HTTP recibe un nuevo identificador de solicitud, salvo que el llamador especifique uno. El diagnóstico no modifica la facturación.
  • Las versiones incluidas de AgentSpine y Translate Native permanecen sin cambios. No están demostrados ni costes menores ni respuestas más rápidas en funcionamiento real.
  • /question: vuelve a abrir las preguntas de seguimiento pendientes. Contraer una pregunta de seguimiento no la responde ni la descarta.

Los bytes de solicitud, las cantidades estimadas de tokens, el consumo de sesión acumulado y los tokens facturados son magnitudes distintas. El indicador de consumo tiene también en cuenta la comprobación de respuestas. /usage cost con costes diarios o mensuales no forma parte de esta versión. No están demostrados ni costes menores ni respuestas más rápidas en funcionamiento real.

BLUN King

BLUN King 9.1.603

Publicado el

Elige tu carpeta de trabajo en un diálogo de Windows. Si la consola se inicia desde System32, ahora sugiere tu carpeta de usuario.

  • Si eliges otra carpeta de trabajo en Windows, se abre un diálogo de carpetas. Puedes seguir escribiendo la ruta a mano. Si cancelas el diálogo, vuelves a la selección de carpeta sin que se aplique ninguna carpeta.
  • Si no hay ningún diálogo de carpetas disponible, la consola solicita la ruta. En otros sistemas operativos se mantiene la entrada de ruta.
  • Si al iniciar se aplica una carpeta dentro del directorio de Windows, o hay una guardada, la selección de carpeta sugiere tu carpeta de usuario. Las rutas escritas a mano se siguen comprobando como hasta ahora.

Las versiones de AgentSpine y Language Guard permanecen sin cambios con respecto a 9.1.602. Esta actualización no demuestra ninguna ganancia de velocidad para sesiones en curso.

En Windows se sigue necesitando Git Bash. Si la consola indica que falta Git Bash, instala Git for Windows. A continuación, abre de nuevo el símbolo del sistema antes de volver a iniciar king.

BLUN King · Publicado

BLUN King 9.1.602

Publicado el

Una carpeta privada propia para salidas de herramientas antiguas cuando los permisos heredados de Windows impiden la externalización.

  • Las salidas de herramientas antiguas aptas se guardan en una carpeta privada propia cuando los permisos heredados de Windows impiden la externalización. Los archivos existentes, los permisos y el historial completo de la sesión permanecen sin cambios.
  • Las comprobaciones de integridad, los permisos de lectura y el recurso al contexto completo se conservan en caso de que una salida archivada no pueda recuperarse. AgentSpine 0.73.0 y Language Guard 6.20.0 no cambian con respecto a 9.1.601.

Todavía no están demostrados tiempos de respuesta más cortos en funcionamiento ni un menor consumo de tokens facturado.

BLUN King · Publicado

BLUN King 9.1.601

Publicado el

Las entradas permanecen en la cola, las salidas de herramientas antiguas reciben referencias verificadas y las comprobaciones de respuesta sujetas a limitación de tasa se repiten un número limitado de veces.

  • Cuando el trabajo en segundo plano obtiene el turno primero, las entradas de terminal permanecen en la cola en su orden original. Cada entrada se muestra una sola vez.
  • Las salidas de herramientas antiguas adecuadas se sustituyen en las solicitudes al modelo por referencias verificadas a archivos privados. El historial completo y los resultados del paso de conversación actual se conservan. Si la recarga no es posible, no está permitida o el contenido ha cambiado, se envía la salida completa.
  • Una comprobación nativa de respuesta sujeta a limitación de tasa se repite una vez con el mismo borrador de respuesta. Se aplica el plazo de espera del proveedor que se ha guardado. Las llamadas a herramientas ya completadas no se repiten y los textos no verificados no se aprueban.
  • Hasta 2.048 tokens de salida quedan libres como margen para desviaciones en la estimación de entrada. La ventana de contexto no se reduce; los límites de salida más pequeños establecidos expresamente permanecen sin cambios.

Estos cambios no demuestran ni un menor consumo de tokens facturado ni tiempos de respuesta más cortos en funcionamiento real. Tampoco corrigen todos los errores HTTP 502 del lado del servidor.

BLUN King · Publicado

BLUN King 9.1.600

Publicado el

Comprobación de respuestas con límites de tiempo fijos y versiones de componentes fijadas.

BLUN King 9.1.600 está publicado. npm y el manifiesto de actualización público coinciden. La publicación no demuestra ni una instalación en tu equipo ni una aceptación en funcionamiento real.

Comprobación de respuestas limitada

  • Los comprobadores generales mantienen el plazo anterior de 30 segundos. La comprobación lingüística nativa dispone de hasta 90 segundos para el primer texto de contenido a partir de la señal de inicio del componente host de confianza, una vez por intento de comprobación externo.
  • El texto de contenido dentro de la longitud de salida permitida, así como las transiciones ordenadas a la aprobación y a la verificación del comprobante, restablecen en cada caso el plazo de espera a 30 segundos.
  • Con independencia de ello, cada intento de comprobación externo tiene un límite total de 120 segundos. El progreso no puede prolongar este límite. Sigue habiendo como máximo dos intentos de comprobación externos.
  • Antes de aceptar una aprobación se vuelve a comprobar el tiempo realmente transcurrido. Incluso con llamadas de temporizador retrasadas, un intento de comprobación caducado permanece bloqueado; el progreso tardío no puede renovar un plazo vencido.

Las señales de interrupción se siguen teniendo en cuenta. Se siguen comprobando la vinculación al texto de respuesta exacto, la validez temporal del comprobante de aprobación y la autorización.

Componentes incluidos

La versión 9.1.600 incluye AgentSpine 0.73.0 y Translate Native 6.155.0. El protocolo Guard permanece sin cambios en 6.20.0.

Limitaciones conocidas

Los nuevos límites de tiempo no demuestran una solución general de los errores HTTP 502 en funcionamiento real. Las observaciones abiertas de 9.1.599 siguen abiertas mientras no haya una prueba específica en funcionamiento real.

Contexto y ayuda

Un prompt que debe conservarse íntegro ya no se recorta en silencio solo para que quepa en una ventana estricta del modelo más pequeña. Con una nueva división, definida expresamente, de los mensajes de usuario que deben conservarse y con el presupuesto estándar de 20.000 tokens, el ajuste puede completarse dentro de la misma compactación. Esto no debe hacer que se descarten más requisitos en prefijos posteriores o restaurados. La solicitud debe seguir cabiendo en la ventana estricta del modelo.

Las invocaciones que solo piden ayuda con --help o -h ya no generan ningún estado de diagnóstico en tiempo de ejecución. Si se combinan argumentos de prompt y de ayuda, se conserva el comportamiento anterior en tiempo de ejecución.

BLUN King · 18 de septiembre de 2026

BLUN King 9.1.599

Publicado el

Aprobaciones individuales trazables para la memoria personal y correcciones adicionales para los desbordamientos de contexto.

Las solicitudes de aprobación para la memoria personal muestran títulos de acción comprensibles en el idioma seleccionado y vistas previas completas de los cambios de configuración reales o del texto que se va a guardar. Los caracteres de control se muestran enmascarados de forma visible; el contenido original permanece sin cambios.

Los cambios de memoria válidos deben aprobarse individualmente; las entradas no válidas solo pueden rechazarse. Una aprobación de sesión no autoriza automáticamente las solicitudes pendientes que requieren una aprobación individual.

La comprobación del paquete abarca 37 áreas funcionales con 199 comprobaciones obligatorias, 158 ejecuciones de comprobación y 4.905 pruebas superadas distintas. Además, las actualizaciones desde 9.1.597 y desde la versión intermedia local 9.1.598 a 9.1.599 se probaron en instalaciones aisladas con el actualizador y la vía de instalación sin cambios. Ambas pruebas reconocieron la versión a través de las fuentes de actualización públicas y comprobaron los 918 archivos del paquete comprimido de la versión.

Las notas de README.md y CHANGELOG.md del paquete 9.1.599 sin modificar describen la versión candidata en el momento del empaquetado. No se modificaron retroactivamente tras la instalación local. Esta página pública documenta por separado la versión publicada y las limitaciones observadas posteriormente.

Limitaciones conocidas en 9.1.599

En funcionamiento se siguieron observando respuestas HTTP 502 repetidas, en parte seguidas de solicitudes correctas. Las correcciones de contexto no son una solución general para errores del proveedor o de la red.

La comprobación de idioma puede interrumpir una respuesta con missing-language-character-profile o suspected-ascii-substitution. Este hallazgo sigue abierto; 9.1.599 no contiene una corrección comprobada para ello.

El usuario confirmó una respuesta a la imagen enviada. Aún están pendientes una comprobación independiente de la interpretación de la imagen y la aprobación visual de la entrada y de las líneas de estado. Haber superado las comprobaciones de paquete no equivale a dar por buenos estos flujos en general.

Incorporado desde la versión intermedia local 9.1.598

Sin fecha

9.1.598 se probó e instaló localmente, pero no se publicó como actualización npm propia. Los siguientes cambios están incluidos en 9.1.599:

  • En un rechazo de contexto se distinguen los límites inferiores del número de tokens de entrada de los valores exactos. Ante un límite inferior notificado, el límite de salida se reduce una vez, sin descartar mensajes ni herramientas. Las señales de cancelación y la limitación de nuevos intentos siguen siendo efectivas. Con ello se corrige de forma específica el error de cálculo del límite de salida reproducido en 9.1.597.
  • Vuelven a incluirse las 150 palabras de actividad rotativas originales. Para mostrarlas no se realizan solicitudes adicionales al modelo.
  • En el hook de entrada de confianza de AgentSpine se pasa una referencia de medio compacta con tipo, suma de comprobación SHA-256 e indicación de tamaño, en lugar de los datos de medio completos. Se conservan los adjuntos completos para el modelo y las comprobaciones de protección existentes. Esto, por sí solo, aún no demuestra una interpretación de imagen satisfactoria en funcionamiento real.

Nuevo en 9.1.597

Publicado el

Recuperación limitada ante desbordamientos de contexto notificados expresamente, también cuando llegan envueltos en una respuesta de error de la puerta de enlace.

Cuando una solicitud se rechaza antes de que empiece la salida por un desbordamiento de contexto demostrado, King puede hacer un nuevo intento limitado con un límite de salida menor. También se reconocen los errores de este tipo encapsulados en una respuesta 502. Se conservan los mensajes, las herramientas, los límites de salida menores elegidos expresamente y las señales de interrupción. Un flujo ya iniciado no se vuelve a reproducir.

Esto no soluciona todos los errores de proveedor o de red. Las interrupciones generales de conexión y las caídas del servicio deben seguir comprobándose con sus propios datos de error.

Limitación conocida en 9.1.597: si el servidor solo notifica un límite inferior para el número de tokens de entrada, el reintento puede volver a fallar y provocar compactaciones innecesarias. Este caso se reprodujo el 17 de septiembre de 2026 tras la publicación. La corrección adicional de la versión intermedia local 9.1.598 está incluida en 9.1.599.

Se comprobaron 36 áreas funcionales con 183 comprobaciones obligatorias y 4.407 pruebas distintas superadas, así como la actualización real de 9.1.596 a 9.1.597. Esta comprobación del paquete no sustituye una prueba de uso real en una sesión de cliente ya abierta.

Nuevo en 9.1.596

Publicado el

Las interrupciones automáticas a favor de mensajes de Telegram en espera se distinguen de las interrupciones manuales reales. Una interrupción de cola de este tipo ya no se notifica erróneamente como pulsación de la tecla Escape. Se conservan el plazo de espera, las reglas de protección para herramientas en ejecución y el comportamiento ante una interrupción manual real.

Nuevo en 9.1.595

Publicado el

Los esquemas de herramientas opcionales se recargan mediante ToolSearch y se conservan de forma limitada. Los catálogos grandes de habilidades se ofrecen de forma compacta y por páginas. Se conservan la búsqueda, las ampliaciones MCP posteriores y las comprobaciones de permisos normales.

En saludos breves, King puede usar un fragmento limitado del diálogo reciente sin borrar mensajes guardados ni recortar instrucciones del sistema. Para una tarea posterior, King vuelve a tener en cuenta el historial de trabajo conservado. El cómputo del contexto se conserva también después de reanudar una sesión. No se promete un consumo fijo de tokens para cada saludo.

Nuevo en 9.1.594

Publicado el

  • Las respuestas privadas de Telegram siguen siendo posibles mientras los mensajes de grupo esperan. La asignación de comandos de barra se conserva.
  • Se respetan las esperas largas de Retry-After; al reanudar una sesión se restablece la pausa restante.
  • Tras descartar una descripción adjunta, un paso de herramienta ya completado se sigue procesando. La descripción descartada no se publica y la comprobación de la respuesta final no se debilita.
  • Las funciones de recuperación limitadas para la escritura en varias partes vuelven a estar disponibles. Esto también se aplica a los límites de tiempo de shell, al control de tareas y a la reanudación de sesiones.
  • La entrada, las líneas de cuota, el indicador de actividad, las tareas desplegables y las salidas de herramientas con marcado de fuente permanecen visibles al transmitir y al navegar por el historial.
  • Antes del empaquetado se exigen pruebas completas de regresión de la consola; se comprueba que los metadatos públicos de actualización coincidan.

Versiones intermedias 9.1.590 a 9.1.593

Estas versiones figuran en el historial local de versiones, pero a 17 de septiembre de 2026 no están en el índice público de versiones de npm. Aquí no se recomiendan como actualizaciones disponibles públicamente. Los trabajos en el inicio, la reanudación, los permisos, el indicador de actividad y la entrada visible se tienen en cuenta en las comprobaciones de 9.1.594.

Nuevo en 9.1.589

Publicado el

  • Se incluyen fuentes verificadas de AgentSpine y Translate Native, así como manifiestos de actualización verificados.
  • Al cargar el contexto del agente, el perfil activo de King se conserva.
  • Las herramientas necesarias para la comprobación de respuestas siguen disponibles. El consumo de la generación de respuestas se registra también cuando la comprobación descarta la respuesta.
  • En la conexión de canal gestionada, los mensajes de grupo solo se asignan cuando hay una mención explícita.
  • La consola muestra la compactación en curso y los umbrales efectivos.
  • El presupuesto de trabajo para la compactación temprana y la reserva de seguridad en el límite de solicitud se conservan a lo largo de las actualizaciones.
  • El diálogo de actualización al iniciar, el progreso y los avisos sobre actualizaciones previstas usan de forma coherente el idioma seleccionado.
  • Los identificadores técnicos de integración y las licencias se conservan; los mensajes de error visibles del runtime se formulan de forma neutra.
  • La instalación no reinicia las sesiones existentes. Una sesión en curso carga el nuevo código en el siguiente inicio.

9.1.588: retirado

Publicado el

Esta versión se publicó el 11 de septiembre de 2026 y posteriormente se marcó en npm como retirada. El registro menciona una comprobación de compatibilidad fallida del manifiesto de actualización. Usa la versión estable actual, no este paquete retirado.

Nuevo en 9.1.587

Publicado el

Catálogos de herramientas más estables, compactación automática más temprana y un reintento específico tras interrupciones por fases de razonamiento puro demasiado largas.

Con instrucciones almacenadas en búfer dentro de un turno de trabajo en curso, el catálogo de herramientas activo se conserva también en el paso de trabajo siguiente. Las herramientas necesarias siguen disponibles. Si se supera el presupuesto de esquema existente, las definiciones de herramientas opcionales conservadas se vuelven a seleccionar.

La compactación automática de contexto vuelve a comenzar antes. Tras una compactación satisfactoria que reduce el historial, King puede ejecutarla de nuevo en el mismo turno. Los límites de modelo más bajos y la limitación de intentos fallidos siguen siendo efectivos.

Tras una interrupción por una fase de razonamiento puro demasiado larga, King utiliza el reintento único existente con el razonamiento desactivado, para que el modelo pueda responder o llamar a una herramienta. Los pasos regulares siguientes mantienen el ajuste de razonamiento elegido; la interrupción, las comprobaciones de aprobación y los límites de tiempo siguen siendo efectivos.

Con BLUN_STABLE_STEER_TOOLS=0 o BLUN_EARLY_COMPACTION=0 antes de iniciar King se puede restablecer el comportamiento anterior para la función correspondiente. La actualización no reescribe sesiones ni archivos de configuración existentes.

Nuevo en 9.1.586

Publicado el

La recepción de Telegram vuelve a iniciarse en Windows cuando el ID de proceso antiguo del puente pertenece entretanto a otro proceso. Si la asignación del proceso es dudosa, King no interviene; el proceso ajeno no se finaliza.

La compactación de contexto, los ajustes de modelo, el historial de conversación y el comportamiento de entrega anterior de Telegram permanecen sin cambios.

Nuevo en 9.1.585

Publicado el

BLUN King · 8 de septiembre de 2026

La versión 9.1.585 comprueba la estructura y los resultados individuales de las respuestas de WebSearch gestionadas también cuando faltan los datos opcionales sobre el estado de la búsqueda.

Una respuesta sin una lista de resultados válida ya no se emite como búsqueda satisfactoria sin resultados. Cada resultado debe tener un título que no esté vacío ni compuesto solo de espacios, un extracto de texto como cadena y una dirección HTTP o HTTPS absoluta sin credenciales incrustadas. Los resultados no válidos hacen que se rechace toda la respuesta antes de devolver resultados o avisos sobre resultados de búsqueda incompletos.

Las respuestas válidas en el formato anterior sin indicaciones de estado siguen siendo compatibles, al igual que las listas de resultados vacías y las cadenas vacías como extractos de texto. En las respuestas válidas se conservan el orden, las cadenas de URL exactas, las indicaciones opcionales de fecha y sitio web, las atribuciones de fuente en la salida y el procesamiento de resultados incompletos.

Solo se modifica la conexión de búsqueda gestionada. El comportamiento de cancelación, la autenticación de las solicitudes, FetchURL y Telegram permanecen sin cambios. La comprobación de formato no demuestra que una fuente sea correcta o esté actualizada. Esta versión no introduce un límite de tamaño para las respuestas ni un nuevo límite de tiempo.

Nuevo en 9.1.584

Publicado el

La versión 9.1.584 transmite la señal de cancelación de quien llama a través de WebSearch hasta la solicitud de búsqueda HTTP gestionada, también al leer el contenido de la respuesta.

Las búsquedas ya canceladas no provocan procesamiento en el proveedor. Si la cancelación se produce durante la obtención de las credenciales, después no se envía ninguna solicitud de búsqueda. Los resultados que llegan después de la cancelación no se devuelven como búsqueda satisfactoria.

Las comprobaciones de cancelación abarcan también las respuestas JSON correctas, el contenido de las respuestas de error y los avisos sobre resultados de búsqueda incompletos. El procesamiento de resultados completos, incompletos y vacíos, las atribuciones de fuente y el procedimiento alternativo habitual en la autenticación permanecen sin cambios.

Esta versión no introduce un nuevo límite de tiempo ni modifica la asignación de Telegram. Los procesos compartidos de renovación de credenciales OAuth y las implementaciones de transporte que ignoran las señales de cancelación no se interrumpen forzosamente. La cancelación de una solicitud del cliente no demuestra que el trabajo en el servidor remoto o su facturación hayan terminado.

Nuevo en 9.1.583

Publicado el

Una cancelación al recuperar una página ahora se transmite hasta la solicitud HTTP.

FetchURL transmite la señal de cancelación de quien llama a través de la herramienta y de ambos servicios de recuperación. Una solicitud cancelada antes de iniciarse no se envía. Si la cancelación se produce durante la obtención de las credenciales, la solicitud HTTP gestionada ya no se inicia después.

Tras la cancelación de una recuperación gestionada ya no se inicia una recuperación local de sustitución. Un resultado tardío del servicio de recuperación se retiene y no se utiliza como prueba de fuente. Ante errores HTTP y de red habituales, la recuperación local de sustitución anterior sigue siendo posible.

No se introduce un nuevo límite de tiempo. Una renovación compartida de credenciales y el procesamiento síncrono de HTML no se interrumpen forzosamente. El límite de tamaño de 9.1.582 sigue vigente; el enrutamiento de Telegram y las solicitudes al modelo permanecen sin cambios.

Nuevo en 9.1.582

Publicado el

La recuperación local de páginas comprueba ahora el tamaño de la respuesta ya durante la lectura y se interrumpe al superar el límite.

La recuperación local cuenta los bytes de respuesta entrantes antes de decodificar cada bloque de datos e interrumpe el flujo de datos en cuanto se supera el límite de tamaño. Si falta la indicación Content-Length o es incorrecta, ya no se lee primero toda la respuesta y luego se rechaza.

El límite preestablecido sigue siendo de diez MiB y se aplica al flujo de respuesta tras la descompresión HTTP. Los caracteres UTF-8 distribuidos en varios bloques de datos se conservan. Los búferes de transporte y el bloque de datos con el que se supera el límite pueden estar ya en memoria; no se deriva de ello un límite superior exacto para toda la memoria del proceso.

Se modifica la vía de recuperación local, también cuando sirve como solución de reserva. Las correcciones de investigación de 9.1.581 siguen incluidas. El enrutamiento de Telegram y el tiempo de espera del modelo permanecen sin cambios.

Nuevo en 9.1.581

Publicado el

En la recuperación local de páginas, los extractos HTML vacíos ya no se emiten como fuentes obtenidas correctamente.

Si tras la limpieza y la conversión no queda contenido de página, el título del documento por sí solo ya no basta para una recuperación satisfactoria. En su lugar se devuelve el error de extracción ya existente.

Los contenidos reales breves y los encabezados visibles se conservan. Las respuestas en formato texto plano o Markdown permanecen sin cambios. La corrección afecta a la extracción HTML local, no al servicio de recuperación gestionado.

Las correcciones de investigación de 9.1.580 y las correcciones de Telegram anteriores siguen incluidas sin cambios. Esta actualización no modifica ni el tiempo de espera del modelo ni la asignación de los mensajes entrantes a sus destinatarios.

Nuevo en 9.1.580

Publicado el

El archivo de investigación rechaza fechas históricas no válidas para las fuentes.

Un informe nuevo no se guarda cuando una fecha de una fuente contiene un día de calendario no válido o una parte horaria que no se puede interpretar. Las fechas ausentes siguen siendo admisibles.

Al recuperar comprobantes de investigación guardados, los comprobantes antiguos con fechas no válidas para las fuentes se omiten y se notifican con un aviso de diagnóstico. Los archivos no se reescriben ni se eliminan. Los comprobantes válidos independientes se pueden seguir buscando; las fechas válidas conservan su desfase de zona horaria y su precisión.

La ordenación de los comprobantes de investigación de 9.1.579 y las correcciones de Telegram anteriores siguen incluidas sin cambios. Esta actualización no modifica ni el tiempo de espera del modelo ni la asignación de los mensajes entrantes a sus destinatarios.

Nuevo en 9.1.579

Publicado el

A igual relevancia, los comprobantes de investigación guardados se ordenan por su momento real de recuperación.

Las marcas de tiempo con y sin milisegundos se comparan como instantes UTC, no como texto. La relevancia sigue teniendo prioridad; con instantes idénticos se conserva el orden anterior.

Si el mismo pasaje de texto se registró varias veces, el resultado conserva los datos de origen de la recuperación más reciente. Los comprobantes ya guardados permanecen sin cambios y por ello no se consideran fuentes recién verificadas.

La corrección para las respuestas de Telegram de 9.1.578 sigue incluida sin cambios. Lo mismo vale para la limitación de nuevos intentos cuando el modelo solo razona, sin ofrecer una respuesta ni una llamada a herramienta. Esta actualización no modifica ni el tiempo de espera del modelo ni la asignación semántica de los mensajes entrantes.

Nuevo en 9.1.578

Publicado el

Reintentos limitados cuando el modelo solo razona y alcanza el límite de tiempo, así como una corrección específica para respuestas breves de Telegram en grupos que hacen referencia a una pregunta.

Si el modelo alcanza el límite de tiempo mientras solo razona, King permite un intento adicional por paso. Un segundo agotamiento del tiempo de este tipo pone fin al paso. El esfuerzo de razonamiento elegido y el límite de tiempo anterior permanecen sin cambios. Esta limitación no acorta la espera hasta la primera salida del modelo.

Las respuestas breves sobre la propia presencia en grupos de Telegram pueden enviarse ahora cuando reply_to las vincula con una entrada de hace como máximo 30 minutos del mismo chat. Esa entrada debe dirigirse expresamente al agente o corresponder a una pregunta de presencia admitida en alemán o inglés que comience con su nombre configurado. Los avisos de presencia no solicitados y las explicaciones de que no hay nada que notificar siguen filtrándose. El reenvío automático de sustitución en grupos permanece desactivado.

Los registros de respuestas enviadas y suprimidas contienen ahora reply_to. Si falta el contexto o es ambiguo, la excepción no se aplica. Esta actualización no añade un reconocimiento general de destinatarios ni evita las llamadas innecesarias al modelo que provoca el direccionamiento semántico existente.

La corrección se aplica a dos versiones exactamente identificadas de los remitentes MCP gestionados de Telegram y también actúa en la fusión final de la configuración del plugin. El remitente más antiguo utiliza una copia de compatibilidad con cambios muy limitados. Los puentes de entrada, los ajustes de acceso, los perfiles y el registro de plugins no se reescriben. Los remitentes desconocidos o modificados y las sobrescrituras establecidas expresamente se conservan. King debe reiniciarse tras la actualización para que la corrección se cargue.

Nuevo en 9.1.577

Publicado el

Ya no hay mensajes de finalización automáticos en los grupos de Telegram. Las respuestas útiles se envían allí de forma selectiva mediante la herramienta de respuesta de Telegram.

El núcleo de la CLI y el puente independiente de Telegram ya no reenvían automáticamente el texto de finalización normal de un agente a los grupos. Así, avisos como «Nada que notificar» ya no llegan al grupo a través de ese reenvío automático de sustitución.

Las respuestas en chats privados, las herramientas de respuesta usadas expresamente, los resultados de objetivos requeridos, los mensajes de comando y estado y el envío de medios se conservan. Las instrucciones de prompt para entradas normales, mensajes de control durante un proceso en curso y mensajes de grupo del puente independiente contienen ahora la misma regla de envío.

Esto no garantiza que un modelo nunca envíe una respuesta innecesaria mediante una llamada a herramienta. La corrección tampoco impide que los mensajes de grupo sin relación con el agente correspondiente lleguen al modelo. Las reglas de mención, los ajustes de acceso y la resolución de plugins gestionados permanecen sin cambios; no se incluye una actualización de AgentSpine ni de Language Guard.

El núcleo actualizado debe cargarse desde un proceso nuevo. Las sesiones en curso no se reinician automáticamente. Los perfiles existentes y el historial de sesión se conservan.

Nuevo en 9.1.576

Publicado el

BLUN King 9.1.576 distingue C++ y C# en las consultas de investigación locales e incluye las correcciones publicadas anteriormente para las actualizaciones, la reanudación de sesiones y Telegram.

La búsqueda en comprobantes de investigación locales trata C++ y C# aislados como términos distintos, también con mayúsculas y minúsculas diferentes y con signos de puntuación alrededor. Los pasajes de texto guardados, los hashes, las comprobaciones de protección de fuentes, la normalización Unicode, los límites de colección y los límites de salida permanecen sin cambios. No es necesaria una nueva indexación.

Una ejecución de prueba predefinida con 20 consultas de búsqueda técnicas y pruebas de regresión específicas para los límites de tokens verifican esta corrección. Afecta a la búsqueda local y no es una afirmación sobre la calidad o la capacidad de WebSearch en funcionamiento real. Todos los cambios de 9.1.575 siguen incluidos.

Nuevo en 9.1.575

Publicado el

El rastreador web incluido rechaza las respuestas con cf-mitigated: challenge antes de leer el contenido, seguir redirecciones o interpretar la ausencia de un archivo robots como permiso para continuar. En los nombres de cabecera no distingue entre mayúsculas y minúsculas; además comprueba valores normalizados y cabeceras repetidas. El estado de la respuesta se conserva en el informe de error.

Los casos de archivo robots ausente sin esta marca y las páginas de documentación habituales siguen pasando por el flujo existente. Las páginas ya completadas siguen disponibles cuando se rechaza una página posterior; el error se notifica como resultado incompleto. Esta protección comprueba una marca de respuesta. No es ni un reconocimiento general de challenges ni una elusión de CAPTCHA. Los proveedores de búsqueda, la autenticación, los bloqueos de actualización y el núcleo de la CLI permanecen sin cambios. Todos los cambios de 9.1.574 siguen incluidos.

Nuevo en 9.1.574

Publicado el

Las actualizaciones solicitadas expresamente distinguen ahora entre una actualización bloqueada, una comprobación de bloqueo no disponible, un directorio privado no disponible, una versión instalada no válida y un instalador protegido no disponible. Estos casos ya no se notifican de forma genérica como comprobación de paquete fallida. El cambio se aplica a los mensajes en alemán e inglés.

La autorización de actualizaciones, el comportamiento de bloqueo, los motivos devueltos, los códigos de salida y el comportamiento del instalador permanecen sin cambios. Las sesiones en curso no se finalizan automáticamente. Los paquetes fijados a un canal interno antiguo siguen necesitando una instalación npm explícita con King detenido; esta versión no levanta esa fijación. Todos los cambios de 9.1.573 siguen incluidos.

Nuevo en 9.1.573

Publicado el

El campo de entrada permanece visible y enfocado tras la selección de objetivo al iniciar, también después de Escape o de una reanudación fallida del objetivo. Los borradores no enviados se conservan. En lugar del texto completo del objetivo aparece una selección compacta para continuar con o sin objetivo.

Ctrl+S abandona la selección sin confirmar el objetivo y se procesa como atajo de teclado normal para la cola. También se tienen en cuenta las entradas pendientes en reposo. Escape mantiene su orden anterior: primero vacía la cola y, con el siguiente Escape, interrumpe la ejecución activa. El historial de sesión no se borra automáticamente.

Esta versión no reconstruye confirmaciones de entrega que un proceso más antiguo perdió antes de la actualización. Los mensajes realmente pendientes siguen asignados a su sesión.

Nuevo en 9.1.572

Publicado el

En los comprobantes de investigación se rechazan URLs de fuentes cuyos parámetros de consulta o fragmentos con forma de parámetro contengan nombres de parámetro conocidos para credenciales. También se comprueban nombres anidados y rutas en el fragmento. El rechazo se aplica tanto a fuentes fallidas como a fuentes utilizables.

Los informes ya guardados con tales URLs se retienen al recuperarlos con el resultado existente partial / report-invalid. Las versiones guardadas originalmente no se modifican ni se eliminan; las direcciones de fuentes no se acortan ni se reescriben en silencio. Los parámetros de consulta habituales y los anclajes en URLs de documentación se conservan byte por byte. La protección reconoce nombres de parámetro conocidos, no secretos arbitrarios, y no limpia ningún historial.

Nuevo en 9.1.571

Publicado el

Los segmentos de la cola de Telegram se asignan a su sesión. Una sesión nueva ya no asume automáticamente el trabajo pendiente de una sesión más antigua. Al reanudar una sesión conocida solo se restauran sus propios segmentos en espera. Durante la selección, la creación y el cambio de sesión, la recepción de mensajes del canal se pone en pausa. Los mensajes que llegan después del límite elegido, las entradas de seguimiento en el editor local y las confirmaciones de entrega tardías conservan su asignación correcta.

La asignación y las confirmaciones de entrega que llegan en orden distinto se conservan al reconectar y al transferir una concesión. El estado de cola dañado o sustituido se rechaza en lugar de volver a reproducir entradas antiguas sin que se note. La bandeja de entrada y el historial de sesión se conservan. Los segmentos antiguos en espera sin sesión reconocible se posponen y no se asignan a ninguna sesión nueva; su restauración automática no está incluida. Esto no soluciona todos los tiempos de espera agotados ni todas las compactaciones de contexto bloqueadas. Volver a una versión anterior no es un procedimiento de migración de la cola.

El plugin de Telegram y la función de respaldo independiente de la consola para el envío automático de respuestas suprimen las confirmaciones de recepción reconocidas y los textos que solo anuncian el propio silencio, también por encima de 200 caracteres. Si un mensaje contiene una parte de frase no reconocida o relevante para el contenido, se conserva. Las advertencias breves y útiles en grupos pueden seguir entregándose. Es un filtro de envío prudente para alemán e inglés con instrucciones complementarias, no una garantía de que todos los modelos entiendan todas las conversaciones de grupo.

Un proceso nuevo debe cargar el paquete actualizado; las sesiones en curso no se reinician. Las fijaciones existentes a canales de actualización internos y los bloqueos de instalación de Windows con EBUSY siguen siendo problemas separados. Todos los demás cambios de 9.1.570 siguen incluidos. Esta versión no activa una búsqueda web alojada y no modifica ni AgentSpine ni la facturación, la autenticación o la configuración del cliente.

Nuevo en 9.1.570

Publicado el

Cada nueva entrega de prompt recibe su propio ID de correlación de hooks. Los hooks de la misma entrega mantienen el mismo ID; los IDs establecidos expresamente se conservan. Los valores de entorno específicos de la sesión llegan a los subprocesos de hooks y a las conexiones MCP también al reconectar, sin reescribir configuraciones de plugins guardadas. La asignación de resultados de herramientas nativas se conserva a lo largo de las ejecuciones, también con herramientas fallidas y llamadas duplicadas.

Las consultas de investigación Unicode canónicamente equivalentes encuentran los mismos resultados sin equiparar caracteres distintos. Las fuentes guardadas, las fechas, las versiones y los límites de proyecto se conservan. king --help y king --version ya no modifican los ajustes del Registro de Windows para los volcados de bloqueo.

La búsqueda web admite respuestas parciales cuando se ha acordado ese modo de respuesta y muestra un aviso sobre fuentes fallidas. Las respuestas parciales vacías o incompatibles siguen siendo errores explícitos. Este cambio de cliente no activa un servicio de búsqueda alojado ni garantiza su funcionamiento.

El transporte BLUN_EXPERIMENTAL_AGENT_SPINE_TIMELINE está desactivado por defecto. Si se activa expresamente, pasa al plugin AgentSpine seleccionado la ruta real del registro de sesión guardado y el registro correspondiente. Cada sesión recibe un permiso de acceso propio, que se renueva tras una reanudación. Se trata de soporte de transporte, no de una prueba de recuperación de memoria ni de autorización por parte del plugin receptor.

Todos los cambios públicos de 9.1.569 siguen incluidos. La implementación incluida de AgentSpine permanece sin cambios; no surge ninguna dependencia de Mnemo. Los perfiles de usuario, los permisos, las conversaciones y los ajustes de plugins no se migran ni se restablecen.

Nuevo en 9.1.569

Publicado el

Esta versión pública acumulativa incluye la entrega en grupos de Telegram mediante menciones, correcciones para el inicio y los permisos, así como colecciones de investigación y herramientas de rastreo. Los paquetes publicados permanecen sin cambios. Los cambios posteriores aparecen con un nuevo número de versión.

Nuevo en 9.1.566

Publicado el

BLUN King 9.1.566 hace más robustas las actualizaciones de plugins y la carga de módulos nativos del runtime.

El runtime incluido de AgentSpine se actualiza a la versión 0.59.1. Su rutina de autoinicio omite la raíz de un perfil de usuario como objetivo de escaneo, y todos los hooks del ciclo de vida permanecen a prueba de fallos cuando no se puede leer una ruta protegida.

Los módulos nativos .node se resuelven mediante una caché direccionada por contenido fuera del paquete npm. En cuanto esta versión está activa, una consola en ejecución ya no mantiene abierta la copia de estos módulos dentro del paquete. Así, las actualizaciones posteriores pueden sustituir el directorio del paquete sin chocar con estos archivos nativos.

El paquete público conserva los catálogos de interfaz completos en español, francés, sueco y checo de la versión 9.1.565. Las rutas internas del runtime de Mnemo, los puntos finales privados, los proveedores de modelos internos y los scripts de compilación no están incluidos.

Versión del paquete comprobada

El paquete de cliente ha superado el escaneo de fugas, la comprobación completa del runtime con 13 pruebas, la inicialización MCP de AgentSpine, una instalación nueva y la actualización desde 9.1.565. Todos los archivos de texto usan finales de línea LF. SHA-256 del paquete npm: bed594f1466594ae81dc87964dd01d45b620e905a39cb0a4ccbcc7e27b57fde1.

Nuevo en 9.1.565

Publicado el

BLUN King 9.1.565 estabiliza las ejecuciones de trabajo largas y amplía el runtime incluido de AgentSpine.

El freno de repetición restablece su secuencia de resultados equivalentes en cuanto, entre medias, el trabajo real avanza. Así, las comprobaciones normales de la bandeja de entrada y de las listas de tareas ya no provocan una respuesta forzada errónea.

El indicador de actividad consta exactamente de una línea. Muestra la palabra de estado en inglés correspondiente a la actividad actual, los tokens del razonamiento oculto, los tokens visibles, el consumo total, el esfuerzo, el intento, el presupuesto y el paso.

Los errores de escaneo de AgentSpine permanecen a prueba de fallos en las herramientas de mutación, las entradas de usuario y los hooks de stop: el flujo siguiente puede continuar y el error queda registrado en el registro de auditoría. Antes de un cierre fatal por una excepción o un rechazo no tratado, la consola escribe el registro del runtime de forma síncrona.

El runtime incluido de AgentSpine se actualiza a la versión 0.54.0 desde el commit fb6d456b68605fd83721090e503f000a26e8a0fb. Esta versión contiene la prueba real de ACL fail-open, los planes de objetivos persistentes vinculados a dependencias y la resolución vinculada de lagunas de conocimiento.

Los hooks del ciclo de vida SessionStart, UserPromptSubmit, PostToolUse y Stop se envían a Mnemo con la identidad exacta de MNEMO_AGENT. Los errores de red permanecen a prueba de fallos.

Los textos de interfaz que faltaban anteriormente están completos en español, francés, sueco y checo.

Versión del paquete comprobada

El control completo del paquete, el escaneo de fugas, la comprobación del catálogo de idiomas, la prueba de hook de ACL, la instalación nueva, la actualización desde 9.1.564 y la inicialización MCP de AgentSpine son correctos. SHA-256 del paquete npm: 88ef653b53fab5bf528d7a5124ca7d5995ab6f90d65318134fa88d8cdf61deba.

Nuevo en 9.1.564

Publicado el

BLUN King 9.1.564 evita los fallos debidos a carpetas protegidas y a textos de interfaz que faltan.

AgentSpine omite en el escaneo previo de archivos los archivos y carpetas individuales que el sistema operativo bloquea con EPERM o EACCES. Un error de escaneo inesperado ya no bloquea la siguiente llamada de herramienta; esta se autoriza y queda registrada en el registro de auditoría.

Si falta una clave de texto en un idioma de interfaz publicado, la consola usa el texto en inglés y registra la laguna una sola vez, en lugar de fallar en la ruta de renderizado. Así, la línea de estado de razonamiento sigue siendo utilizable en checo, español, francés y sueco.

Las traducciones reales de las claves que aún faltan llegarán en una versión comprobada por separado. Hasta entonces, el recurso de reserva en inglés es deliberadamente visible y a prueba de fallos.

Versión del paquete comprobada

El paquete se comprobó contra el fallo checo exacto de thinking.step de 9.1.563. La nueva versión produce «step 6» en lugar de una excepción, advierte solo una vez por idioma y clave, sobrevive a carpetas vecinas inaccesibles, inicializa AgentSpine 0.49.0, supera una instalación nueva y la actualización desde 9.1.563 y no contiene importaciones de plugins sin resolver. SHA-256 del paquete npm: 23056703152f668998ea0583bb9797bbbb51f4c2f320917a220908e28430955e.

Nuevo en 9.1.563

Publicado el

BLUN King 9.1.563 actualiza el runtime incluido de AgentSpine a la versión 0.49.0.

La nueva versión exige, antes de un intento de aprendizaje, al menos una evidencia reciente e independiente procedente de una confirmación expresa del usuario o de una prueba objetiva. Las meras evidencias de conversación o de documentos ya no bastan, aunque cumplan los demás umbrales.

Los contratos de aprendizaje vinculan esta regla de evidencia de forma permanente; los cambios de configuración posteriores no pueden debilitar una comprobación en curso. Los bloqueos de archivo vinculados al propietario protegen los cambios de aprendizaje paralelos contra sobrescrituras y hacen que los bloqueos manipulados o ajenos queden bloqueados por defecto (fail-closed).

La actualización sustituye el árbol de plugins gestionado en el siguiente inicio de forma direccionada por contenido. Las instalaciones existentes de la versión 9.1.562 se actualizan a AgentSpine 0.49.0, un árbol sin cambios se reutiliza y el servidor MCP de AgentSpine confirma la versión 0.49.0.

Versión del paquete comprobada

El límite del paquete difiere de 9.1.562 solo por los datos de versión y el runtime de AgentSpine 0.49.0 fijado exactamente. La comprobación upstream completa, 49 pruebas de aprendizaje específicas, la comparación de paquetes, el escaneo de fugas, la instalación nueva, la ruta de actualización real desde 9.1.562 y una inicialización MCP son correctos. SHA-256 del paquete npm: 9440d94ddb79af1ed996fda43cb66ef50fae3b96a5f79d0dd008f32a5abd04f8.

Nuevo en 9.1.562

Publicado el

BLUN King 9.1.562 restablece el archivo de runtime de AgentSpine en el paquete público.

El archivo de runtime requerido por el servidor MCP de AgentSpine incluido se vuelve a incluir. Una instalación nueva materializa el plugin por completo; el servidor MCP se inicia y confirma su nombre y su versión de protocolo.

Versión del paquete comprobada

El límite del paquete difiere de 9.1.561 solo por los metadatos de versión y el archivo de runtime restablecido. El escaneo de fugas, la instalación nueva, la materialización del plugin y una inicialización MCP real son correctos. SHA-256 del paquete npm: a249f9cb39dc8750ddbe23f72077586c9e8500ab9f0bbfdbf55989d19e329e8a.

Nuevo en 9.1.561

Publicado el

BLUN King 9.1.561 incorpora al paquete público las mejoras comprobadas del sistema de trabajo.

La tarea actual y los resultados de herramientas recientes siguen disponibles. Los resultados de lectura no se recortan. Los resultados grandes se guardan con una referencia para volver a recuperarlos, en lugar de vaciarse. Los resultados idénticos repetidos remiten al resultado completo más reciente.

Las compactaciones se registran como transacción con marcadores de inicio, resumen y fin. Las llamadas a herramientas y sus resultados permanecen juntos, mientras que los puntos de control persistentes aseguran la ruta de recuperación entre reintentos.

Los presupuestos de salida proceden ahora del perfil de modelo activo. El modelo gestionado de BLUN recibe 128.000 tokens de salida por defecto cuando no se ha fijado ningún valor expresamente. Los antiguos límites fijos de 32.768 tokens y los límites bajos para low y off ya no recortan el trabajo complejo; la capacidad de contexto sigue siendo el límite de seguridad.

El actualizador pregunta antes de preparar o iniciar el instalador. En el paquete público, el modelo gestionado de BLUN permanece fijado; /model solo sirve ya como alias de compatibilidad para /effort.

El límite del paquete se comprobó en todos los nombres de archivo y contenidos legibles. Las rutas internas de proveedores, la elección de modelo, los scripts de compilación y de regresión, los identificadores privados y las direcciones de servidor privadas no están incluidos.

Versión del paquete comprobada

El paquete completo, el escaneo de fugas, la instalación nueva, la salida de versión y ayuda, los ajustes por defecto de un perfil nuevo y la decisión de actualización de 9.1.550 a 9.1.561 son correctos. SHA-256 del paquete npm: fcbff9b2f9a537462653c873150fe36567f6195c5a6facc714a266ce38415dd7.

Nuevo en 9.1.527

Publicado el

BLUN King 9.1.527 adopta el flujo /copy de DeepAgents.

El comando copia la respuesta de asistente más reciente finalizada y no vacía a través de la ruta de portapapeles multiplataforma existente.

Si se introduce /copy durante un turno en curso, el comando utiliza la cola de comandos existente y se ejecuta tras la finalización de la respuesta.

Mensajes de estado claros cubren el éxito, un historial vacío y errores del portapapeles en los seis idiomas de interfaz.

Una regresión de rojo a verde protege el registro de comandos, la ejecución, la selección de la respuesta, el contenido del portapapeles fiel al byte y los textos de interfaz aprobados.

Versión del paquete comprobada

El prepack completo y la comprobación del artefacto desempaquetado son correctos. SHA-256 del paquete npm: 94b13ffc1a45af5eaecd9d19ad658abb1895304c2c663e47d03419c1bb4a7cf2.

Nuevo en 9.1.526

Publicado el

BLUN King 9.1.526 materializa la versión de AgentSpine incluida con el paquete actual antes de que /reload reconstruya el catálogo de plugins y la configuración MCP.

Las entradas de plugin no afectadas se conservan. Un árbol gestionado de AgentSpine sin cambios se reutiliza sin volver a escribir installed.json.

Una regresión de rojo a verde contra 9.1.525 protege el orden de arranque, la adopción del plugin gestionado y el comportamiento idempotente al recargar.

Versión del paquete comprobada

El prepack completo, la comprobación del artefacto empaquetado y la prueba de actualización aislada de 9.1.525 a 9.1.526 son correctos. SHA-256 del paquete npm: ae0cc4124ebaac74af1124dcbe2cf6d4d4541126525f947c262809c85f73490a.

Nuevo en 9.1.525

Publicado el

BLUN King 9.1.525 inicia cada comando de shell local en Windows y POSIX en su propio grupo de procesos. Así, los programas ya no pueden acoplarse a la consola de control de la TUI de BLUN ni interceptar Escape, Ctrl+S u otras entradas del editor.

La entrada estándar, la salida estándar y la salida de error permanecen en pipes privados. Los comandos interactivos reciben un fin de archivo y fallan o superan el límite de tiempo sin competir con el editor por las entradas.

El aislamiento local de shell de DeepAgents se ha adoptado para Windows. Una prueba de regresión ejecutable cubre ambas rutas de plataforma y una comprobación real con un proceso interceptado.

Nuevo en 9.1.524

Sin fecha

BLUN King 9.1.524 mantiene la tarea inmediata generada por un comando de Telegram /loop en la ruta de entrega protegida para comandos remotos. Así no puede quedar como segunda entrada normal de la cola.

La lista de reanudación muestra para cada sesión el tamaño del punto de control de reanudación, los mensajes y tokens conservados, el tamaño del historial de sesión y los puntos de control que faltan, no son válidos o están obsoletos.

El runtime incluido de AgentSpine se actualiza a la versión oficial comprobada 0.11.4 con el commit 8034487cdd24498076bac48d3f24400bca5e6ae4. Se conserva el presupuesto de tiempo de BLUN de 180 segundos para la finalización en segundo plano de SessionStart.

Las pruebas de regresión ejecutables protegen la entrega exactamente una vez de los bucles de Telegram y todos los estados de los valores medidos de reanudación. El comportamiento local existente de la cola con un bucle ocupado permanece sin cambios.

Nuevo en 9.1.523

Publicado el

BLUN King 9.1.523 permite que Escape cierre un menú de comandos de barra abierto y vacíe el borrador correspondiente en un solo paso, en lugar de dejar el texto del comando.

Ctrl+S pasa un borrador de comando de barra al camino existente de encolado y procesamiento incluso cuando la interfaz informa de inactividad, en lugar de volver en silencio antes de vaciar la cola.

Los borradores normales se conservan cuando Escape solo cierra otra autocompletación.

Las pruebas de ejecución de rojo a verde protegen ambos atajos de teclado contra el comportamiento exacto del paquete 9.1.522.

Nuevo en 9.1.522

Sin fecha

BLUN King 9.1.522 escribe permission.approval_requested en el historial de sesión en cuanto se abre una aprobación de herramienta. Así, un King desatendido ya no parece un modelo silencioso o un proveedor bloqueado mientras espera al operador.

Los botones de aprobación de Telegram existentes se utilizan automáticamente cuando la lista de autorización contiene exactamente un chat privado y cualquier número de grupos. Con varios destinatarios privados posibles, el envío permanece bloqueado salvo que BLUN_TELEGRAM_APPROVAL_CHAT_ID esté establecido.

Una regresión de rojo a verde protege la visibilidad inmediata en el historial de sesión, el reenvío inequívoco a un chat privado, la prioridad de un destino fijado expresamente y el rechazo de destinatarios ambiguos en ambas copias del relay distribuidas.

Nuevo en 9.1.521

Sin fecha

BLUN King 9.1.521 ejecuta el escaneo de SessionStart de AgentSpine fuera del camino de inicio interactivo. Así, un escaneo en frío de 123,6 segundos del directorio de usuario no bloquea ni el editor ni la primera entrada del usuario.

Las salidas correctas de SessionStart siguen llegando de forma automática: tras finalizar, el hook en segundo plano sigue incorporando su briefing limitado al contexto de la sesión.

El presupuesto de tiempo para escaneos en frío sube a 180 segundos. Una prueba de ejecución de rojo a verde demuestra que el inicio vuelve antes de un hook lento y que el hook puede seguir ejecutándose después.

Nuevo en 9.1.520

Publicado el

BLUN King 9.1.520 concede al hook de SessionStart de AgentSpine tiempo suficiente al recargar para completar un escaneo completo del proyecto en frío.

El límite de tiempo para el inicio de AgentSpine sube de 15 a 60 segundos. Todos los demás límites de tiempo de los hooks permanecen sin cambios.

Una nueva comprobación de ejecución de rojo a verde inicia el hook real de AgentSpine en un proyecto temporal y comprueba tanto su salida como los dos manifiestos de timeout distribuidos.

Versión del paquete comprobada

La versión 9.1.520 contiene AgentSpine 0.10.1. La prueba de actualización aislada de 9.1.519 a 9.1.520 y el prepack completo son correctos. SHA-256 del paquete npm: 3fc37502b544ed2d254711dc2a8be544b906eb8515e53f88289b10c91911a8e7.

Nuevo en 9.1.519

Publicado el

BLUN King 9.1.519 guarda las salidas exitosas del hook SessionStart antes de que el inicio o la recarga regresen. Así, el estado de disponibilidad de AgentSpine llega automáticamente al contexto reanudado del modelo y ya no espera al primer mensaje del usuario.

Las referencias históricas a resultados de herramientas externalizados conservan una vista previa limitada del principio y del final. Con ello se conservan los anclajes importantes para la reanudación sin volver a incluir el resultado completo en cada solicitud al modelo.

Nuevas comprobaciones de ejecución de rojo a verde protegen la transferencia de contexto de SessionStart y las vistas previas históricas. El catálogo de herramientas para el mantenimiento de tareas restablecido con 9.1.518 se conserva sin cambios.

Nuevo en 9.1.518

Publicado el

Durante el mantenimiento proactivo de la lista de tareas, Read, Write, Edit y Bash siguen disponibles junto a TodoList. Así ya no se interrumpe el camino de recuperación normal para cambios grandes de archivos.

El mantenimiento automático de tareas y su prompt de evidencia limitado se conservan, sin cambiar el paso de modelo activo a un catálogo puramente de TodoList.

Un control de regresión de rojo a verde protege contra el retroceso del catálogo de 9.1.499 y comprueba la selección de las herramientas de recuperación sin esquemas duplicados.

Nuevo en 9.1.517

Publicado el

Ctrl+S y Escape siguen disponibles incluso con una solicitud de aprobación abierta. Ctrl+S envía todos los mensajes en espera; Escape libera primero un mensaje en espera y solo rechaza la aprobación cuando la cola está vacía.

La finalización asíncrona de sesión se observa por completo en los caminos de teclado, Telegram-/reload y comandos de barra. session.not_found cuenta como sesión ya finalizada, en lugar de hacer fallar el núcleo por un rechazo no tratado.

Las comprobaciones de paquete de rojo a verde protegen los caracteres de control crudos de Windows y el error medido al finalizar una sesión que ya no existe.

Nuevo en 9.1.516

Publicado el

Si tras la compactación falta en el historial guardado el inicio de un paso de asistente, la reproducción lo reconstruye a partir del siguiente evento de contenido o de herramienta. king -c ya no falla por ello con el error interno Received content_part for unknown step_uuid 'undefined'.

Un mensaje de Telegram sale de la cola exactamente una vez en cuanto el núcleo ha aceptado de forma persistente su transferencia activa. Los rechazos reales se conservan para un nuevo intento. Un puente de Telegram gestionado por King que termina inesperadamente se reinicia mediante un único vigilante unificado.

Por paso de modelo solo se acepta el primer cambio de TodoList. Los puntos completados desaparecen automáticamente, las marcas pendientes siguen siendo visibles también en terminales ANSI16 y una lista nueva comienza con exactamente un punto en curso. El orden fijo es: urgente, mensaje directo del usuario, mensaje de bot dirigido, mensaje de bot, mensaje normal.

El primer paso con capacidad de herramientas espera como máximo 2,5 segundos el catálogo MCP inicial; los servidores opcionales pueden seguir iniciándose en segundo plano. Al iniciar el programa solo se comprueba e instala el perfil activo.

Versión del paquete comprobada

La versión 9.1.516 contiene AgentSpine 0.10.1. Los ocho controles de regresión de prepack, node --check, la comprobación de metadatos del paquete y una nueva comprobación del paquete son correctos. El mismo paquete npm contiene los componentes de plataforma para Windows, Linux y macOS. SHA-256 del paquete npm: f21bffefb2be44ebf0a9a96d5518c2164188e4c8bd99c669840d1566e48aeb6e.

Nuevo en 9.1.515

Publicado el

Una lista de tareas que realmente no ha cambiado vuelve a aceptarse tras un trabajo prolongado y documentado. King no tiene que inventarse avances ni limitarse a reformular un título para poder continuar su trabajo real.

Incluso un bucle de inactividad puede retomar una TodoList aún abierta sin retener al agente de forma permanente en el turno de mantenimiento con la herramienta de tareas como única herramienta. Un control de regresión de prepack protege ambos caminos de error.

Versión del paquete comprobada

La versión 9.1.515 contiene AgentSpine 0.10.1. La comprobación de regresión específica del bucle de tareas, node --check, la comprobación de metadatos de la versión y una instalación nueva del paquete son correctos. El mismo paquete npm contiene los componentes de plataforma para Windows, Linux y macOS. SHA-256 del paquete npm: cda0647bd0fe9888ac6e985ecc067e962800bb64ddba9b6b07249c210a769dbf.

Nuevo en 9.1.514

Publicado el

BLUN King 9.1.514 refuerza el diario de entrega de Telegram sin contenido frente a sobres de cola manipulados.

Los identificadores de mensaje solo se aceptan como números decimales positivos. Los hashes de chat ya calculados solo se admiten como valores hexadecimales exactamente de doce dígitos en minúsculas. Los valores erróneos similares a contenido se descartan en lugar de registrarse.

El procesamiento de Telegram existente, las fases de entrega, la rotación del diario y el diagnóstico de cuarentena sin contenido permanecen sin cambios. Las 133 pruebas de paquete y las nuevas comprobaciones del paquete para Windows x64, Linux x64, macOS ARM64 y macOS x64 son correctas.

Versión del paquete comprobada

La versión 9.1.514 contiene AgentSpine 0.10.1 y ReadBatch. SHA-256 del paquete npm: 1d30915883441daa407475212f12b8774ccbb50490805aea99fd6967e213a125.

Nuevo en 9.1.513

Publicado el

BLUN King 9.1.513 registra la ruta de entrega de Telegram desde la entrada en el puente, pasando por el enrutamiento, la cola y la inserción, hasta la confirmación, la recuperación o la cuarentena.

El diario limitado guarda exclusivamente identificadores sin contenido, hashes, fases de entrega, contadores y motivos de error depurados. No se registran textos de mensajes, prompts, rutas, nombres de usuario, tokens, credenciales ni mensajes de error crudos.

El diagnóstico de cuarentena tampoco duplica ya mensajes de Telegram, textos mostrados, datos de origen, identificadores de chat crudos ni rutas de imágenes. Las 132 pruebas de paquete y las nuevas comprobaciones del paquete para Windows x64, Linux x64, macOS ARM64 y macOS x64 son correctas.

Versión del paquete comprobada

La versión 9.1.513 contiene AgentSpine 0.10.1 y ReadBatch. SHA-256 del paquete npm: 409144f1a87330abd3e763256ed8560e044f8e0eebd152c95ce2492dc36e4dae.

Nuevo en 9.1.512

Publicado el

BLUN King 9.1.512 exige en el mantenimiento proactivo de la TodoList una actualización modificada y respaldada por evidencia, en lugar de volver a aceptar la misma lista indefinidamente. El turno de mantenimiento aislado recibe como máximo ocho indicaciones compactas sobre el nombre de la herramienta y el resultado desde la última actualización aceptada.

Los prompts, argumentos, comandos, rutas completas, resultados de herramientas o el historial de trabajo no se vuelven a reproducir. Un intento fallido de TodoList conserva esta evidencia limitada para el siguiente intento; una actualización exitosa elimina las indicaciones utilizadas. Los puntos completados siguen desapareciendo automáticamente y en el siguiente paso vuelven a estar disponibles las herramientas de trabajo normales.

Versión del paquete comprobada

9.1.512 supera 127 de 127 pruebas de paquete. Las instalaciones nuevas eligen los componentes de plataforma esperados en Windows x64, Linux x64, macOS ARM64 y macOS x64 y contienen AgentSpine 0.10.1 y ReadBatch. SHA-256 del paquete npm: 38192b918d66aa6615f0a1262afcc6a1a4fba5c48354e62bbe8a3bd01d9460dc.

Nuevo en 9.1.511

Publicado el

BLUN King 9.1.511 incluye AgentSpine 0.10.1 como nueva versión de plugin central direccionada por contenido. El preflight obligatorio sigue comprobando cada archivo de instrucciones de host activo de forma segura frente a condiciones de carrera y vincula su identidad al turno exacto, pero ya no duplica en el contexto de ejecución el texto completo ya cargado por el host.

Esta versión añade evidencias obligatorias previas a la respuesta, entradas confirmadas de must-remember y la sincronización autorreparadora del grafo autenticado de persona y relaciones. Los grupos, personas y membresías que faltan se reparan en una nueva comparación del roster; las consultas locales de relaciones terminan de forma visible tras cinco segundos en caso de bloqueo.

La consulta limitada de Telegram-Mnemo se conserva: los mensajes anteriores solo se cargan cuando hay una necesidad concreta, con una referencia estrecha a agente, persona, grupo, tema, hilo y tiempo. Un historial completo de Telegram no llega de forma rutinaria al prompt.

Versión del paquete comprobada

9.1.511 supera 126 de 126 pruebas de paquete. El CLAUDE.md real de 15.519 bytes se comprobó por completo, mientras que todo el contexto inyectado ocupaba 5.667 bytes y no contenía el texto completo de ninguna instrucción. Las instalaciones nuevas eligen los componentes de plataforma esperados en Windows x64, Linux x64, macOS ARM64 y macOS x64 y contienen AgentSpine 0.10.1 y ReadBatch. SHA-256 del paquete npm: e519e786ade515e4292492740e5c6a62f78c231465c431eebc06b43040425d40.

Nuevo en 9.1.510

Publicado el

BLUN King 9.1.510 añade la herramienta ReadBatch. Lee de dos a doce archivos UTF-8 o rangos de archivo independientes ya conocidos en un paso de modelo y conserva el orden de las solicitudes. Cada ruta pasa por las mismas comprobaciones de acceso, reglas y permisos que una llamada individual a Read. Los éxitos parciales siguen siendo visibles; solo un lote completamente fallido cuenta como error general.

Versión del paquete comprobada

9.1.510 supera 125 de 125 pruebas de paquete. Las instalaciones nuevas eligen los componentes de plataforma esperados en Windows x64, Linux x64, macOS ARM64 y macOS x64 y contienen ReadBatch. AgentSpine se mantuvo deliberadamente en 0.8.0 hasta que se resolvió, sin agrandar el prompt de ejecución, el bloqueador de presupuesto de contexto de la versión preliminar más reciente, encontrado de forma independiente. SHA-256 del paquete npm: 1f38522f0a132c92860d4dbfc991e4f80683614f8c9de87ccba24b591b273b1d.

Nuevo en 9.1.509

Publicado el

BLUN King 9.1.509 exige en cada mensaje de trabajo de Telegram autorizado entre bots una mención expresa del King previsto. Los mensajes de bot sin la mención adecuada siguen siendo visibles, pero no se almacenan en búfer, ni se encolan, ni se entregan, ni se incorporan más tarde al contexto de modelo de ese King. Así, un mensaje de bot prioritario para un King ya no puede convertirse en la tarea de otro King.

Versión del paquete comprobada

Las 121 pruebas de paquete se superan. El mismo paquete contiene los componentes de plataforma comprobados para Windows x64, Linux x64, macOS ARM64 y macOS x64. SHA-256: 071e14065bd7e327abda95a4310f473171f6df3c1ad0f1712c9add666f6da7cc.

Nuevo en 9.1.508

Publicado el

Los puntos de tareas pendientes vuelven a tener una casilla visible. También la primera lista de tareas ordinaria comienza con exactamente un punto en curso; los pasos posteriores permanecen pendientes hasta que su inicio real esté evidenciado.

Los mensajes directos y de grupo de Telegram aceptados se entregan a Mnemo de forma asíncrona, con búfer persistente y deduplicación exacta. Un hub temporalmente inalcanzable no bloquea ni la entrega de Telegram ni la ejecución de King. Los comandos /loop y los ticks internos de bucle no se guardan, de forma deliberada.

AgentSpine no carga un historial completo de Telegram en el contexto de ejecución. Si una tarea necesita un mensaje anterior, se realiza una consulta limitada a Mnemo por agente, persona, grupo, tema, hilo y período.

Versión del paquete comprobada

Las 120 pruebas de paquete se superan. Las instalaciones nuevas eligen el componente nativo de portapapeles correcto en Windows, Linux x64, macOS ARM64 y macOS x64 y contienen la conexión gestionada de Telegram-Mnemo y AgentSpine. SHA-256: 34bf9cb52d6a469fa1603f95ce9df17c77ae6ff2e675d91f0442246c0d83b69b.

Nuevo en 9.1.507

Publicado el

BLUN King 9.1.507 indica expresamente al modelo en la herramienta Read que agrupe lecturas de archivos y rangos independientes en una respuesta de modelo cuando varias entradas pueden ser útiles.

Esto reduce rondas de modelo evitables en contextos de trabajo grandes, sin cambiar la ejecución, la navegación de páginas, los permisos ni el tratamiento de resultados de Read.

Versión del paquete comprobada

Una prueba de regresión específica protege el cambio; las 112 pruebas de paquete se superan.

Nuevo en 9.1.506

Publicado el

Los puntos de TodoList completados se eliminan inmediatamente de la TUI visible. La lista de tareas persistente ya había descartado correctamente estas entradas; ahora la interfaz muestra el mismo estado depurado, mientras que el trabajo en curso y pendiente se conserva por completo.

El turno de mantenimiento automático utiliza un prompt de sistema independiente de 546 caracteres. Antes se adjuntaba para ello el prompt de trabajo completo, de unos 19.000 caracteres, aunque la única herramienta disponible era la de tareas. El paso de trabajo posterior sigue recibiendo el prompt completo y su catálogo de herramientas normal.

Ganancia de contexto medida y versión del paquete

Una ejecución real mostró, cada ocho pasos de trabajo, un turno propio de mantenimiento de tareas con 15.221 tokens de entrada. El prompt de mantenimiento estático se reduce en 18.470 caracteres; el ahorro real de tiempo de ejecución se volverá a medir tras la actualización de la flota. El tarball publicado supera 111 de 111 pruebas. Las instalaciones nuevas del paquete en Windows con Node 24.19.0 y Linux con Node 24.18.0 confirman la versión 9.1.506; los binarios de macOS para ARM64 y x64 están incluidos en el mismo paquete npm. SHA-256: 9e01bf05824eedf03de7665a1f0bc294ad4ba1d9f1ed8bf5ca43aab5fa706364.

Nuevo en 9.1.505

Publicado el

Un mensaje de Telegram que llega después de la toma del canal, pero antes de que se complete la activación de la cola, ya no se omite como rezago antiguo. Sin un punto de control válido, el procesamiento comienza en el límite de bytes medido al inicio de la toma en lugar de en el final posterior del archivo.

Un punto de control persistente válido conserva la prioridad. Si el archivo de cola se sustituye durante la transferencia, el archivo nuevo comienza con seguridad en el byte cero; los mensajes históricos ya presentes antes de la toma no se vuelven a reproducir.

Regresión medida y versión del paquete

El mensaje de grupo 63456 llegó un segundo después de la toma del canal, el punto de control saltó exactamente hasta su final y el mensaje no apareció en ningún historial de modelo. Este caso real de pérdida queda cubierto por una prueba de regresión. El tarball publicado supera 111 de 111 pruebas; las instalaciones nuevas del paquete en Windows con Node 24.19.0 y Linux con Node 24.18.0 y una actualización real desde 9.1.504 confirman la versión 9.1.505. SHA-256: fd1c4be83316195d8cc9962aa3ff69c3fdf4838b25a99aca59cae3f445275241.

Nuevo en 9.1.504

Publicado el

Un mensaje de Telegram que ya está en la cola durante una ejecución vacía de agente se inicia ahora por la ruta de canal normal como turno de modelo nuevo. Ya no espera a una ejecución activa, que por definición no puede surgir en el modo inactivo.

La transferencia existente a un turno en curso permanece sin cambios. También siguen protegidas la gestión aislada de tareas, la eliminación automática de puntos completados y la posterior restauración de las herramientas normales de archivo, búsqueda y shell.

Versión del paquete comprobada

El tarball publicado supera 106 de 106 pruebas. La nueva regresión de inactividad estaba en rojo antes de la intervención y ahora está en verde, junto con 24 pruebas de cola. Las instalaciones nuevas del paquete en Windows con Node 24.19.0 y Linux con Node 24.18.0 confirman la versión 9.1.504 y el mismo SHA-256 df01bb10d653c0f5e2572b5ea0fe9cf8972db1f6d3df530de5484d3a1cccca27.

Nuevo en 9.1.503

Publicado el

El mensaje aislado de mantenimiento de tareas lleva ahora también un campo toolCalls explícitamente vacío. Así tiene la misma forma que los turnos de trabajo normales y la normalización del proveedor de BLUN puede procesarlo de forma segura.

El error de ejecución real TypeError: message.toolCalls is not iterable ya no aparece antes de la llamada a TodoList. Una prueba de regresión itera el mensaje generado exactamente como la frontera del proveedor antes de que se autorice el mantenimiento.

Versión del paquete comprobada

El tarball publicado supera 105 de 105 pruebas. Las nuevas comprobaciones del paquete en Windows con Node 24.19.0 y Linux con Node 24.15.0 confirman la forma completa del mensaje de proveedor, la gestión aislada de tareas y la eliminación automática de los puntos completados. La aceptación real de la flota se realiza tras el reinicio controlado de los tres Kings.

Nuevo en 9.1.502

Publicado el

El paso de mantenimiento de TodoList pendiente recibe ahora solo un mensaje nuevo, limitado a la tarea actual y a la lista visible. Así, las llamadas antiguas de Read, Bash o MCP del historial de trabajo ya no pueden entrar en el paso limitado deliberadamente a TodoList.

Las tareas completadas desaparecen automáticamente de la lista visible y persistente al guardar. Los puntos en curso, pendientes, bloqueados, en espera de aprobación y cancelados se conservan; así la lista no crece sin límite por el trabajo terminado.

Hallazgo de flota medido

Dos perfiles de agentes encontraron de forma independiente la misma regresión: tras un uso exitoso de herramientas, el mantenimiento de tareas repetía herramientas de trabajo históricas y mostraba Tool not found. El tarball publicado supera 105 de 105 pruebas. Las instalaciones nuevas en Windows con Node 24.19.0 y Linux con Node 24.15.0 confirman la gestión aislada, la eliminación de puntos completados y el regreso de las herramientas normales. Una aceptación real de macOS no forma parte de esta verificación.

Nuevo en 9.1.501

Publicado el

Tras un paso exitoso de mantenimiento de TodoList, en el paso de trabajo inmediatamente siguiente vuelven a estar disponibles todas las herramientas seleccionadas para el turno. Read, Bash y otras herramientas de trabajo ya no quedan ocultas tras el catálogo de tareas restringido temporalmente.

Regresión reparada

El paso de tareas ofrecía deliberadamente solo TodoList. Sin embargo, su selección de herramientas seguía activa también en el paso siguiente, sin restauración expresa. 9.1.501 vuelve a usar allí el catálogo normal y protege ambos caminos del paso siguiente con una regresión.

Golden Release 9.1.500

Publicado el

Esta versión agrupa el estado funcional completo de 9.1.499 sin cambios como publicación npm común para Windows, Linux y macOS. La marca dorada se limita deliberadamente a los encabezados de esta versión; las entradas más antiguas conservan su presentación anterior.

Versión publicada

La Golden Release incorpora sin lógica de ejecución adicional los cambios comprobados de Todo, Queue, Loop, contexto, AgentSpine y análisis de imágenes de 9.1.499.

Nuevo en 9.1.499

Publicado el

Los datos de imagen, audio y vídeo fuera de los últimos doce mensajes de la conversación se sustituyen por referencias cortas solo en la proyección repetida para el modelo. Los medios actuales, el texto de los mensajes y el historial bruto completo de la sesión permanecen sin cambios.

En un punto de control de reanudación medido, esta proyección ahorra 85.748 caracteres, es decir, unos 21.437 tokens de entrada estimados por cada paso de herramienta posterior.

El mantenimiento de tareas pendiente se ejecuta antes del noveno bloque de trabajo como paso de modelo propio de bajo esfuerzo. En este paso, el runtime ofrece exclusivamente TodoList; las herramientas de archivo, búsqueda, shell y demás solo se autorizan de nuevo tras una actualización válida.

Los mensajes nuevos del usuario conservan la prioridad sobre el mantenimiento de tareas. El control estricto de tareas se conserva como red de seguridad para actualizaciones realmente no válidas, pero ya no aparece como error intermedio rojo normal antes de una gestión autónoma de la lista.

Evidencia comprobada

El tarball publicado supera 105 de 105 pruebas de ejecución y regresión. Las instalaciones aisladas nuevas en Windows con Node 24.19.0 y Linux con Node 24.15.0 informan exactamente de la versión 9.1.499 y confirman la proyección de medios, el historial bruto sin cambios, el control previo de tareas y la ocultación de todas las herramientas de trabajo durante el paso de tareas. El candidato comprende 850 rutas y lleva el SHA-256 51e79a766d834d06a6e0d428337a45c9ab62ed8535a988f77b73c1164162f71f. Una aceptación real de macOS no forma parte de esta verificación.

Nuevo en 9.1.498

Publicado el

/usage muestra la tasa de aciertos de caché de prompt informada por el proveedor, así como los tokens de caché leídos y escritos por modelo. Sin actividad de caché informada, la visualización no inventa ninguna tasa.

/tokens es un alias corto para el diagnóstico detallado de contexto existente; /offload invoca la compactación archivadora existente. Ninguna de las dos vías provoca una llamada adicional al modelo.

Los mensajes de bot autorizados que son distintos entre sí ya no se descartan por una ventana rígida de 15 segundos. El orden existente se conserva: los mensajes privados y dirigidos expresamente van antes que los de bot, y los de bot antes que el contexto normal.

Una compactación completa traslada la lista de tareas exacta al nuevo contexto. Si después no están claros la ruta, el comando, el hash o el requisito, un aviso de recuperación único exige leer primero el historial archivado en lugar de hacer una búsqueda amplia de archivos o empezar de nuevo.

Los pasos de tareas completados se conservan como evidencia. Si hallazgos posteriores vuelven a hacer necesario un paso, el cierre evidenciado permanece y la nueva comprobación aparece como paso propio en curso con justificación.

Los bucles de sesión recurrentes esperan mientras la lista de tareas gestionada contenga trabajo en curso o pendiente. Los intervalos omitidos se agrupan hasta que haya inactividad real; otros recordatorios programados no se ven afectados.

Evidencia comprobada

El tarball preparado supera 100 de 100 pruebas de ejecución y regresión. Las instalaciones aisladas nuevas en Windows con Node 24.19.0 y Linux con Node 24.15.0 informan exactamente de la versión 9.1.498 y confirman la visualización de caché, los alias de comandos, la recuperación de compactación, las evidencias monótonas de tareas, la protección en los bucles de sesión, el changelog del paquete y la prioridad de bots. El candidato comprende 849 rutas y lleva el SHA-256 11b6918c02cc743b6d65aca79820abf5d0aa55786948c12ad9f0187c587b1d56. Una aceptación real de macOS no forma parte de esta verificación.

Nuevo en 9.1.497

Publicado el

Los mensajes de bot de Telegram de grupos compartidos van detrás de los mensajes privados y dirigidos expresamente, pero antes del contexto normal. La priorización no obliga a responder.

Un mensaje de Telegram aceptado desaparece de la cola visible en cuanto comienza el paso de modelo en el que se ha insertado. Una entrega rechazada o una cancelación antes del primer paso lo sigue conservando para un nuevo intento.

Una respuesta de Telegram pendiente o el procesamiento de un mensaje ya no quedan bloqueados por la gestión de tareas. El siguiente paso de trabajo normal sigue bloqueado hasta que la lista de tareas se actualice de forma veraz.

Versiones 9.1.496 a 9.1.487

VersiónCambios
9.1.496Entrega automáticamente los mensajes de usuario de Telegram de uno en uno, elimina solo el identificador del mensaje exactamente aceptado o respondido, exige un progreso veraz en cada lista de tareas visible y oculta las cargas útiles de hooks internos que se ejecutan correctamente.
9.1.495Inicia cada objetivo nuevo o sustituido con una lista de tareas visible nueva, exige actualizaciones veraces, elimina inmediatamente el foco de grupo de Telegram respondido con éxito, pospone las confirmaciones de entrada normales hasta el fin del turno y añade comprobaciones reales de decodificación para Ctrl+S y Ctrl+T.
9.1.494Separa de nuevo los atajos de teclado de forma inequívoca: Ctrl+S controla solo los mensajes pendientes de la cola y Ctrl+T, solo la lista de tareas. Los mensajes de usuario de Telegram se autorizan durante el trabajo en curso para la siguiente transferencia segura.
9.1.493Los mensajes de usuario de Telegram se autorizan automáticamente durante el trabajo activo para la siguiente transferencia segura. Los mensajes directos se mantienen al principio de la cola, sin retener de forma permanente los mensajes de grupo.
9.1.492Los mensajes de grupo ya autorizados se conservan si la entrega está ocupada temporalmente y se vuelven a intentar. El paquete, los metadatos de npm, el manifiesto público y el changelog se comprueban conjuntamente antes de notificar el éxito.
9.1.491Los mensajes directos de Telegram se priorizan inmediatamente durante el trabajo en curso. El control manual de la cola se mantuvo para otros mensajes.
9.1.490El historial del paquete documenta por completo la versión no publicada 9.1.487 y las reparaciones realmente publicadas a partir de la 9.1.488.
9.1.489La lista de tareas, el control de la cola, la identidad de ejecución de Telegram, la instalación de perfil de AgentSpine y el análisis de imágenes gestionado se han restablecido y quedan protegidos con pruebas de regresión.
9.1.488Se ha publicado el plugin central de AgentSpine que estaba preparado. Los duplicados de Telegram ya no dejan un turno fantasma; la profundidad de pensamiento y el tratamiento seguro de la telemetría se conservan entre los pasos de herramientas.
9.1.487No publicado. Esta versión preparó AgentSpine como plugin central gestionado. En npm, a la 9.1.486 le siguió directamente la 9.1.488.

Nuevo en 9.1.486

Publicado el

Los perfiles nuevos y actualizados se inician ahora de forma fiable en inglés en Windows, macOS y Linux. Un valor de idioma automático guardado se migra una sola vez, mientras que los idiomas elegidos expresamente permanecen sin cambios.

Las actualizaciones automáticas al inicio vuelven a estar activadas por defecto mediante el instalador existente vinculado a la versión. [upgrade].auto_install = false mantiene la solicitud de confirmación; no se reintroduce ningún actualizador en segundo plano.

Los diálogos de inicio, el progreso, los errores, los mensajes de éxito y la continuación de sesión usan ahora el mismo idioma. Las pruebas de regresión y mutación protegen la migración, la ruta de actualización y los datos de sesión.

Evidencia comprobada

La suite de pruebas completa pasó con 1.474 de 1.474 comprobaciones. Una ejecución de actualización aislada instaló la 9.1.486 a partir de la 9.1.485, conservó la configuración y la sesión sin cambios e inició la nueva CLI. Una prueba de inicio separada demostró la instalación automática sin preguntar y la migración única de un valor de idioma automático antiguo al inglés.

Versiones 9.1.485 a 9.1.178

VersiónCambios
9.1.485
  • Limita la primera reproducción visible de una sesión reanudada sin índice de scrollback a los 15 turnos de conversación activos, en lugar de volver a mostrar toda la conversación.
  • Tras una actualización correcta, vacía el área de actualización visible antes de que se inicie la nueva consola; el scrollback normal del terminal se conserva.
  • Añade comprobaciones de regresión y mutación para la regresión de reproducción, incluida una simulación con 97.596 registros.
9.1.484
  • La detección de plugins acepta además .codex-plugin/plugin.json y resuelve PLUGIN_ROOT o BLUN_PLUGIN_ROOT en el comando, los argumentos y el directorio de trabajo.
9.1.483
  • El modelo de compactación puede seleccionarse, guardarse y restablecerse al valor heredado con independencia del modelo activo; la selección y la confirmación están disponibles en el comando que se ejecuta en reposo y en los ajustes localizados.
9.1.482
  • Los resultados de Read externalizados conservan el siguiente line_offset y continúan la lectura original allí, en lugar de leer el mismo archivo de nuevo desde el principio.
9.1.481
  • Las respuestas de subagentes que terminan en el límite de tokens sin llamada de herramienta se reconocen como max_tokens para la continuación existente. Se rechazan los patrones glob con .. y las rutas de directorio personal con nombre, como ~name.
9.1.480
  • Actualiza el skill translate-native incluido y el MCP de Language Guard a la versión 6.42.13.
  • Vincula los archivos incluidos de la protección lingüística byte a byte al commit de origen 6430ce30e235c1a9d1ebcd1b646d62edce510605.
  • Añade comprobaciones de origen y mutación para que bytes de protección alterados o una versión de skill divergente hagan fallar el control de publicación.
9.1.479
  • Añade al servicio privado de King de la Agent API una ruta interna autenticada para la comprobación de disponibilidad.
  • Comprueba la disponibilidad del servicio sin crear una sesión de cliente ni iniciar una ejecución de agente.
  • Limita la ruta a la interfaz loopback y a GET, la protege con un secreto y evita su almacenamiento en caché.
9.1.478
  • Corrige las pausas normales del foco directo de Telegram tras un reinicio, incluso cuando los puntos de control antiguos no contienen un plazo de respuesta.
  • Conserva las pausas solicitadas expresamente por el usuario hasta la aprobación, en lugar de dejarlas expirar automáticamente.
  • Libera los mensajes de canal encolados para una ejecución activa en cuanto termina el foco directo.
9.1.477
  • Añade al servicio privado de la Agent API un envoltorio de proceso explícito iniciado por el operador.
  • Procesa SIGINT y SIGTERM exactamente una vez, incluso cuando las señales llegan durante el inicio.
  • Aborta de forma segura con mensajes limitados, no llama a process.exit y nunca inicia el servicio automáticamente.
9.1.476
  • Añade al servicio privado de la Agent API un contrato de entorno según el principio de bloqueo seguro.
  • Exige un puerto loopback fijado expresamente, secretos de aislamiento, ajustes de proveedor y límites de recursos.
  • Mantiene el servicio privado detenido y la limpieza automática de sesiones inactivas desactivada hasta que ambas cosas se hayan configurado expresamente.
9.1.475
  • Libera únicamente las sesiones de la Agent API configuradas para ello y realmente inactivas, antes de que un cliente alcance el límite de sesiones.
  • Protege las ejecuciones activas de modelo y de herramientas independientemente de su antigüedad y actualiza el período de inactividad con el uso real.
  • Mantiene la limpieza automática desactivada hasta que un operador configure expresamente un tiempo de espera de inactividad.
9.1.474
  • Anula la asignación de sesión activa cuando falla la continuación de un agente tras un resultado de herramienta.
  • Permite después el cierre expreso de la sesión afectada.
  • Deja sin cambios los retornos correctos de las herramientas y el contrato público de modelo.
9.1.473
  • Protege una sesión de la Agent API contra el cierre mientras su primera llamada de modelo sigue en curso.
  • Libera la sesión de forma fiable tras una respuesta exitosa o un error de modelo.
  • Deja sin cambios la ruta existente para modelos no procesados y el contrato público de modelo.
9.1.472
  • Permite a los clientes cerrar expresamente una sesión inactiva de la Agent API y liberar su plaza de sesión, que es limitada.
  • Impide el cierre de sesiones activas y limita cada operación de cierre al cliente propietario correspondiente.
  • Pone a disposición el espacio liberado para una sesión nueva sin modificar el contrato público de modelo.
9.1.471
  • Añade un host de servicio cerrado que compone la pila privada de la Agent API sin iniciarla automáticamente.
  • Exige secretos separados para transporte y aislamiento, un directorio raíz absoluto de clientes y una configuración expresa del entorno de ejecución de King.
  • Vincula los listeners a la interfaz loopback y, al apagarse, cierra cada sesión de cliente y cada entorno de ejecución.
9.1.470
  • Aísla las sesiones headless de la Agent API por cliente de confianza y sesión pública.
  • Agrupa los primeros accesos simultáneos en una única sesión del SDK y limita los clientes y las sesiones activos.
  • Usa identificadores internos opacos y directorios de trabajo vinculados a claves, mientras se conservan los identificadores públicos estables de sesión.
9.1.469
  • Añade al adaptador de la Agent API un transporte HTTP privado, alcanzable exclusivamente a través de la interfaz loopback.
  • Exige un secreto de servicio y una identidad de cliente predeterminada por el servidor; los datos de identidad falsificados en el cuerpo de la solicitud se ignoran.
  • Rechaza las solicitudes sobredimensionadas o erróneas y mantiene los detalles internos del proveedor fuera de los mensajes de error públicos.
9.1.468
  • Mantiene al agente principal receptivo mientras los subagentes en segundo plano y los subagentes anidados siguen trabajando.
  • Permite a las sesiones restringidas de la Agent API usar el ciclo de vida de subagentes sin exponer herramientas locales de shell o del sistema de archivos.
  • Transmite el límite exacto de herramientas a cada nivel de subagente anidado, de modo que las restricciones no puedan eludirse mediante delegación.
9.1.467
  • Añade un adaptador de transporte explícito para ejecuciones de agente, sin interceptar las rutas existentes para modelos no procesados o listas de modelos.
  • Vincula los resultados de herramientas y las cancelaciones dirigidas al mismo ámbito de cliente, sesión y solicitud.
  • Muestra exclusivamente King, sanea los errores internos inesperados y rechaza el streaming hasta que exista un contrato de agente para ello.
9.1.466
  • Registra cada llamada de modelo completada de la Agent API bajo un identificador de tarea estable, sin agrupar el uso de distintos clientes.
  • Una asignación JSONL persistente mantiene localizables la solicitud, la sesión, la tarea, el ID de llamada y los campos de uso no procesados incluso tras un reinicio.
  • Externamente solo aparecen King y los contadores no procesados de entrada, entrada en caché y finalización; los datos de uso que faltan quedan marcados expresamente.
9.1.465
  • Añade un control de ejecución aislado para el punto final explícito de agente de la Agent API, sin modificar las finalizaciones de modelo no procesadas.
  • Las llamadas de herramienta gestionadas por el cliente conservan una única ejecución de King a lo largo de los retornos de resultados y permanecen limitadas a la solicitud original.
  • Las respuestas de los agentes padre excluyen los flujos de eventos de los agentes hijos y los borradores descartados de los reintentos.
9.1.464
  • Los subagentes gestionados se ejecutan ahora desacoplados, de modo que el agente principal permanece receptivo mientras continúa el trabajo delegado.
  • Los subagentes en curso pueden controlarse con TaskUpdate o terminarse con TaskStop, sin cerrar la sesión principal.
  • Los mensajes de grupo de Telegram dirigidos permanecen en el foco hasta que el agente responde en el chat correspondiente.
9.1.463
  • Si existen datos de ventana, una reanudación desde checkpoint solo renderiza el último grupo de turnos activo de la TUI; las líneas más antiguas permanecen en el archivo de scroll y se cargan bajo demanda.
9.1.462
  • Los contenidos sin cambios de tui.toml ya no provocan un intercambio atómico de archivos; los cambios reales siguen usando la ruta de escritura con bloqueo existente.
9.1.461
  • /status distingue la versión del runtime cargada del paquete instalado y notifica también una divergencia en el estado remoto de Telegram.
9.1.460
  • Los mensajes de sesión visibles más antiguos permanecen en un archivo de disco persistente y se cargan por bloques al hacer scroll hacia arriba, sin leer todos los bloques de texto al inicio.
9.1.459
  • Una reanudación restablece un punto de control semántico vinculado a la integridad y lee solo la parte añadida desde entonces al archivo de sesión sin cambios; con un punto de control no válido, la reproducción completa queda como recurso de reserva.
9.1.458
  • Una suma de comprobación tomada de un informe externo solo se vincula si ese valor exacto está presente en el evento de origen seleccionado.
9.1.457
  • Si la misma suma de comprobación procede de varios eventos externos, el origen se indica como ambiguo en lugar de atribuirlo a un informe.
9.1.456
  • Las sumas de comprobación en los mensajes de Telegram salientes se contrastan con los resultados de herramientas locales y los informes externos visibles; los valores no asignados generan una indicación de origen.
9.1.455
  • Los informes de Telegram pueden vincularse como credible_unverified mediante el identificador de chat y de mensaje; el runtime fija el autor del informe y el origen del evento.
9.1.454
  • Las comprobaciones recientes se vinculan automáticamente a la sesión y al agente que las generan; las mediciones reenviadas siguen siendo informes externos.
9.1.453
  • Un comprobante de finalización se vincula al criterio de finalización actualmente válido y se rechaza ante un criterio distinto u obsoleto.
9.1.452
  • Cada comprobante se vincula al ámbito objetivo realmente medido; las comprobaciones de comandos deben llevar el mismo valor seguro de BLUN_EVIDENCE_SCOPE en ambos lados.
9.1.451
  • Cada comprobante lleva el tipo exacto inspection, integrity, syntax, test o reachability. Una comprobación más débil no puede presentarse como más fuerte.
9.1.450
  • Los comprobantes de resultado y los de verificador se tratan por separado. Solo un verificador nuevo o modificado necesita una segunda prueba de rigor independiente; las mediciones normales no necesitan una prueba en rojo.
9.1.449
  • El comprobante de finalización nombra la llamada de comprobación exitosa exacta mediante su toolCallId; una llamada de comando mixta con cambio y comprobación no basta.
9.1.448
  • Una finalización de objetivo debe vincular la afirmación comprobada a una llamada de comprobación exitosa del mismo turno; las herramientas puramente de escritura o modificación no cuentan como comprobante.
9.1.447
  • Una acción seleccionada se vincula a comprobantes de decisión persistentes; los comprobantes desconocidos u obsoletos fuerzan una nueva planificación.
9.1.446
  • El bloqueo de repetición en vivo reconoce además secuencias cortas recurrentes de dos a ocho palabras.
9.1.445
  • Las notas de aprendizaje seleccionadas se guardan junto con el resultado de aprendizaje validado del turno actual como rastro de exposición, sin afirmar causalidad a partir de ello.
9.1.444
  • La búsqueda de relevancia de errores anteriores usa datos persistentes de objetivo, punto de control y marco de problema, en lugar de solo los mensajes de usuario más recientes.
9.1.443
  • En una continuación inmediata del objetivo, una selección expresa de tool: o skill: carga exactamente el recurso elegido.
9.1.442
  • El foco de trabajo conserva el hilo de decisión con estado, fase, última comprobación, selección, justificación, respaldo, riesgo y reversibilidad.
9.1.441
  • El conocimiento que falta se gestiona como dominio propio knowledge_gap en lugar de en el texto general del objetivo, se prioriza y se oculta cuando el valor está vacío.
9.1.440
  • El conocimiento del mundo y las suposiciones pueden incorporarse como dominios propios al foco persistente y ponderarse.
9.1.439
  • El foco cognitivo persistente recibe una evaluación de saliencia con decaimiento entre sesiones y refuerzo ante un nuevo acceso.
9.1.438
  • Durante la reproducción de sesión se posponen el recorte, la fusión y el renderizado; después se solicita exactamente un nuevo render del transcript.
9.1.437
  • El vigilante de inactividad vuelve a usar la ruta de texto adecuada para los tiempos de espera y ya no termina el proceso mediante un parámetro no permitido en el temporizador.
9.1.436
  • El estado remoto de Telegram muestra durante un turno activo el inicio, el último progreso, la última herramienta y los errores repetidos; la TUI publica para ello instantáneas de actividad en curso.
9.1.435
  • Los puntos de control privados del foco de Telegram siguen ahora el área de trabajo vinculada a la sesión activa.
  • La selección del área de trabajo ya no guarda el directorio desde el que se inició como lugar de continuación para conversaciones directas.
9.1.434
  • El aprendizaje confirmado sigue ahora el área de trabajo vinculada a la sesión de agente activa.
  • Las sesiones con varias áreas de trabajo y las sesiones reanudadas ya no guardan ni muestran lecciones de proyecto en el directorio del proceso host.
9.1.433
  • La preparación de una entrada en el editor externo permanece ahora dentro del límite de limpieza de los directorios temporales.
  • Si falla el primer intento de escritura, por ejemplo por un disco lleno o por falta de permisos, el directorio temporal del editor se elimina antes de propagar el error.
9.1.432
  • Los errores de stream transitorios pueden volver a intentarse ahora también tras una salida parcial visible, con el mismo modelo seleccionado.
  • El texto de asistente incompleto y las superficies de herramienta no finalizadas se completan o descartan antes del reintento, para que la nueva salida no se anexe al intento fallido.
  • Tras una salida visible, el cambio de proveedor permanece bloqueado, de modo que una respuesta no puede cambiar de proveedor a mitad del stream.
9.1.431
  • Los procesos locales de la herramienta Bash desactivan ahora de forma forzada las peticiones de entrada de Git en el terminal, en lugar de heredar un ajuste interactivo del proceso padre.
  • Los diálogos askpass heredados de Git, SSH y Git Credential Manager están desactivados en el proceso hijo de la herramienta; así se evitan esperas invisibles por credenciales de Windows.
  • El shell padre y el entorno de la sesión en curso permanecen sin cambios; el comportamiento existente con la entrada estándar cerrada se conserva y se asegura de forma independiente.
9.1.430
  • La compactación completa puede usar ahora un alias de modelo configurado opcionalmente mediante [loop_control].compaction_model; el modelo activo de King sigue siendo el valor predeterminado.
  • La autenticación, la preparación de contexto, el presupuesto de finalización, el aprendizaje por desbordamiento y la facturación de uso de la compactación están completamente vinculados al modelo de compactación elegido.
  • El modelo activo sigue determinando el inicio de la compactación y el último freno de solicitud, de modo que un modelo de resumen más pequeño no pueda reducir inadvertidamente la ventana central de razonamiento.
9.1.429
  • Bash en Windows rechaza ahora, antes de iniciar el proceso, la sintaxis que es inequívocamente de cmd.exe, en lugar de desperdiciar una ejecución visiblemente fallida.
  • La descripción de la herramienta Bash aclara expresamente que el Bash POSIX sigue activo en Windows, incluido VS Code, e indica las convenciones correctas para rutas y redirecciones.
  • Los comandos find POSIX válidos siguen permitidos; si se desea deliberadamente la semántica de cmd, sigue disponible un traspaso explícito a cmd.exe /c.
9.1.428
  • Las escrituras generadas de JavaScript y TypeScript se detienen ahora antes del acceso al disco cuando una instrucción ejecutable se repite ocho veces seguidas; así se evitan salidas descontroladas de scripts de análisis.
  • La comprobación de protección abarca tanto las llamadas de Write para archivos completos como las sustituciones de Edit, mientras que los archivos que no son código, los comentarios, las cadenas y las repeticiones legítimas más cortas permanecen sin cambios.
  • Los tres casos de degeneración observados con 15, 23 y 31 instrucciones repetidas se bloquean; las intenciones arbitrarias incompletas pero no repetitivas siguen estando fuera de esta comprobación mecánica.
9.1.427
  • El comando visible /memory core informa ahora del límite activo del adaptador de memoria, la versión del contrato, el modo de identidad, el estado de integridad y los comprobantes entre portales, opcionalmente como salida --json.
  • El almacenamiento sustituto vinculado al perfil y las identidades derivadas de perfiles se excluyen expresamente de la disposición para un núcleo común, en lugar de presentarse como memoria neutral al portal.
  • Los proveedores configurados permanecen visiblemente no confirmados hasta que existan comprobantes separados; el diagnóstico es de solo lectura, no otorga facultades y nunca inventa pruebas entre portales.
9.1.426
  • El comando visible /memory acceptance ejecuta ahora una comprobación sintética temporal de memoria V7 a través de CLI, Telegram y web, y puede emitir opcionalmente un informe --json.
  • Diez comprobaciones independientes cubren el origen del portal, las identidades vinculadas y no vinculadas, el aislamiento de agentes y grupos, la deduplicación, la corrección y eliminación globales, el bloqueo seguro del proveedor y los bytes de origen protegidos.
  • El informe de aceptación sirve exclusivamente como comprobante determinista: no otorga facultades y nunca lee ni modifica un perfil de usuario real.
9.1.425
  • Los subagentes que alcanzan su límite de tokens reciben ahora, en el mismo contexto de agente, una breve ejecución de transferencia sin herramientas, en lugar de perder el trabajo de herramientas completado.
  • Si esta transferencia también alcanza el límite, el agente padre recibe un resumen parcial limitado y la instrucción exacta de continuar con el mismo agente.
  • La recuperación sigue diseñada según el principio de bloqueo seguro: sin reintento completo de la tarea, sin aviso de finalización sin transferencia final y sin nuevas facultades.
9.1.424
  • Las lecciones confirmadas de Mistake.md se transfieren ahora a casos formulados de otro modo pero semánticamente similares de fiabilidad, entrega, orquestación, memoria, publicación, medios y validación.
  • Los términos exactos de comprobante siguen teniendo prioridad sobre las categorías semánticas amplias; el texto no relacionado queda sin asignación.
  • Las formulaciones naturales en alemán se unifican de forma determinista; el orden de prioridad modificado no crea nuevos permisos ni eleva una lección no confirmada.
9.1.423
  • Las finalizaciones del runtime escriben ahora una entrada de diagnóstico síncrona persistente antes de que el núcleo o el iniciador retornen o terminen.
  • Las excepciones no capturadas, los rechazos no tratados, los terminales caídos, las señales, los errores de inicio, las finalizaciones normales, los errores de procesos hijos y sus finalizaciones conservan la causa exacta saneada junto con el límite del proceso.
  • El registro privado es limitado y a prueba de fallos, elimina secretos y rutas del directorio personal, y no reinicia ni recarga ninguna sesión en curso.
9.1.422
  • Una sesión abierta e inactiva supervisa ahora su disparador de tiempo guardado y se activa en el modo automático y en el modo God al llegar dueAt o después.
  • Un disparador vencido espera a que se completen las respuestas activas, la compactación, los mensajes encolados, los comandos y los diálogos, antes de continuar exactamente una vez.
  • Antes del inicio, el runtime vuelve a leer el objetivo, la revisión del punto de control, el vencimiento, el modo de permisos y la sesión, y descarta los temporizadores en cada camino de finalización de la sesión.
9.1.421
  • Los puntos de control de espera basados en tiempo guardan ahora una marca de tiempo dueAt exacta y la unifican en UTC.
  • Un arranque normal de la sesión en el modo automático o en el modo God deja en espera los disparadores de tiempo futuros y los reanuda al llegar su vencimiento o después.
  • La primera ejecución reanudada recibe la observación exacta del vencimiento; las sesiones abiertas de forma continua aún no reciben un temporizador del runtime en esta versión.
9.1.420
  • Un objetivo activo con punto de control de espera persistente cede el control tras la ejecución actual, en lugar de asignar otra ejecución autónoma.
  • Los disparadores externos, basados en tiempo, basados en dependencias y dependientes de decisiones del usuario permanecen guardados y se vuelven a evaluar al llegar el siguiente evento.
  • Los objetivos inmediatos y los objetivos activos más antiguos sin punto de control se reanudan sin cambios.
9.1.419
  • Una sesión reanudada con normalidad prosigue ahora con un objetivo ya activo cuando su siguiente disparador guardado es expresamente inmediato y el modo automático o el modo God está activo.
  • La continuación permanece interna, se ejecuta como máximo una vez por sesión reanudada y nunca aparece como mensaje de usuario inventado.
  • Los objetivos en espera, pausados y bloqueados, los puntos de control que faltan y los modos de permisos manuales permanecen detenidos.
9.1.418
  • Telegram conserva ahora la marca expresa de bot del remitente en los datos de entrada, para que el contexto de identidad distinga a los agentes de las personas.
  • Los actores de Telegram ya guardados como personas solo se corrigen como agentes cuando coinciden el proveedor, el sujeto y la marca expresa de bot.
  • Los detalles de actor se conservan, los agentes nunca se degradan y los nombres o nombres de usuario nunca se usan para derivar una identidad de agente.
9.1.417
  • Las respuestas de reserva automáticas de Telegram dividen ahora las respuestas de más de 4.096 caracteres en mensajes consecutivos, en lugar de recortarlas.
  • Cada carácter y cada par suplente Unicode se conservan; la salida registra todos los ID de mensaje devueltos junto con el texto completo.
  • Si una parte falla, la entrega se detiene en ese punto, en lugar de notificar como completa una respuesta incompleta.
9.1.416
  • Los resultados recientes del último lote de llamadas de herramientas permanecen totalmente legibles hasta la siguiente respuesta de asistente, incluso si después se incorpora contexto de Telegram o de control.
  • La descarga por lotes, la depuración del historial y la microcompactación usan ahora el mismo límite semántico para los resultados recientes.
  • Los resultados antiguos ya evaluados se siguen compactando normalmente, de modo que se conservan los ahorros de contexto anteriores.
9.1.415
  • El foco de trabajo persistente conserva ahora el disparador exacto de la siguiente acción a través de reinicios y cambios de contexto.
  • La siguiente acción permanece separada de su condición de aprobación; esto también se aplica a condiciones válidas de más de 512 caracteres.
  • Los disparadores erróneos o inadecuados para la fase se rechazan de forma segura; los puntos de control antiguos conservan su comportamiento anterior.
9.1.414
  • Los nuevos puntos de control de acción persistentes registran el disparador exacto que autoriza la siguiente acción.
  • Las fases que no esperan necesitan un disparador inmediato; las fases de espera necesitan un evento externo con nombre, un momento, una dependencia o una decisión del usuario.
  • Los objetivos en espera permanecen activos sin ejecutarse prematuramente; los puntos de control antiguos siguen siendo legibles.
9.1.413
  • Las respuestas de Telegram que alcanzan el límite de salida del modelo ya no se entregan como inicios incompletos.
  • La misma sesión en curso genera una continuación breve y completa e intenta como máximo tres recuperaciones antes de abortar de forma segura.
  • Una respuesta expresa mediante la herramienta de Telegram sigue teniendo prioridad y suprime la recuperación, de modo que los envíos exitosos nunca se duplican.
9.1.412
  • Los objetivos persistentes creados por el modelo comienzan ahora atómicamente con la revisión 1 y un marco de problema limitado completo.
  • El modo God y el modo automático continúan un inicio de objetivo ya autorizado sin segunda confirmación; en el modo manual sigue siendo necesaria la aprobación.
  • El trabajo autenticado, no trivial y de varios pasos puede cambiar al modo de objetivo persistente bajo una instrucción autónoma existente; los saludos, las solicitudes de un solo paso y las tareas vagas quedan excluidos.
9.1.411
  • Las tareas no triviales y desconocidas pueden guardar ahora un marco de problema limitado en el punto de control de acción persistente.
  • El marco registra los criterios de éxito, el conocimiento que falta, hasta cinco acciones posibles, la acción seleccionada con justificación, la elección del respaldo, el riesgo y la ruta de reserva.
  • El marco de problema sobrevive a la continuación y al reinicio exclusivamente como estado descriptivo y nunca puede otorgar permisos.
9.1.410
  • Los comandos privados de memoria de Telegram limitan ahora el ámbito de relaciones a la persona correspondiente.
  • El foco de memoria oculta las relaciones de otras personas y conserva el resto del contexto.
  • Las correcciones y eliminaciones no pueden seleccionar una relación de otra persona; el foco local del operador conserva la vista completa.
9.1.409
  • Las herramientas de respuesta de Telegram y la ruta de reserva de la TUI usan ahora un directorio canónico común para el estado del canal.
  • Los valores de BLUN_HOME específicos de perfil ya no crean un segundo árbol de directorios para las entradas o salidas de Telegram.
  • Un BLUN_TELEGRAM_STATE_DIR fijado expresamente sigue siendo determinante; de lo contrario, ambas rutas usan ~/.blun/channels/telegram.
9.1.408
  • Los detalles de relación confirmados solo se fusionan tras dos observaciones independientes en canales directos.
  • Los mensajes reproducidos de nuevo permanecen idempotentes; los mensajes de grupo y las afirmaciones similares a permisos quedan excluidos.
  • Los recuerdos de relación privados confirmados pueden seguir a la misma persona a través de Telegram y la CLI, sin otorgar facultades.
9.1.407
  • La herramienta de respuesta de Telegram importa la ruta al historial de entrada en curso que usa la detección de duplicados.
  • Las respuestas normales de Telegram ya no fallan con el error inboxLog is not defined.
  • La ruta de reserva separada del bridge sigue disponible como salvaguarda de la entrega.
9.1.406
  • Los intentos de entrega repetidos de eventos privados de Telegram con la misma marca de tiempo y el mismo texto se guardan solo una vez en la continuidad de relaciones.
  • Una afirmación realmente repetida más tarde sigue formando parte del historial de relaciones limitado.
  • Las indicaciones expresas para recordar algo, formuladas de forma natural al final de la frase, se reconocen como datos de referencia, sin otorgar ni modificar permisos.
9.1.405
  • El comando /status del Telegram vinculado informa ahora de la antigüedad y el latido del proceso de la consola, del paso de trabajo actual y de la tarea activa, sin llamar al modelo.
  • El volumen pendiente de la cola mide ahora los bytes no leídos desde un punto de control vinculado al archivo de cola exacto actual.
  • El estado remoto sigue siendo de solo lectura y no contiene ID de chat, rutas de archivo, credenciales ni contenidos de mensajes, ni listas de tareas completas.
9.1.404
  • El contenido sin cambios de config.toml ya no sustituye al archivo privado existente.
  • La comparación exacta de bytes se limita a destinos regulares que no son enlaces simbólicos.
  • Los destinos modificados, ausentes, no válidos y no legibles siguen usando la ruta de escritura atómica existente a prueba de fallos.
9.1.403
  • La clasificación automática de herramientas cargables ignora las cargas útiles de adjuntos y documentos incrustadas.
  • Cada fragmento de intención se limita antes de la comparación léxica al presupuesto existente de consulta de ToolSearch de 1.000 caracteres.
  • Las instrucciones reales, los adjuntos y las solicitudes expresas de ToolSearch permanecen sin cambios.
9.1.402
  • Los archivos caducados del historial de compactación se limpian una vez en segundo plano al inicio de un comando de King.
  • La limpieza al inicio no es bloqueante y no puede retrasar el procesamiento normal de comandos.
  • Los errores de limpieza se registran de forma segura y no interrumpen la sesión en curso.
9.1.401
  • El primer fragmento de texto de cada respuesta en curso se muestra ahora de inmediato, en lugar de esperar una llamada de temporizador.
  • Un turno nuevo y cada segmento nuevo de respuesta de asistente reciben su propio primer renderizado inmediato.
  • Los fragmentos posteriores de texto, pensamiento y herramientas conservan el ritmo de agrupación adaptativo que protege el rendimiento de las sesiones largas.
9.1.400
  • Las sesiones reanudadas grandes se reproducen ahora de forma cooperativa, para que la TUI pueda redibujar y reaccionar durante la restauración del historial.
  • Cada registro de reproducción guardado de forma permanente se sigue mostrando; ninguna parte del historial se recorta, omite o elimina.
  • Las reanudaciones pequeñas conservan su comportamiento anterior; las grandes ceden la ejecución al bucle de eventos cada 30 registros.
9.1.399
  • Los candidatos de aprendizaje comprobados se limitan ahora al proyecto Git actual, en lugar de llegar a repositorios no relacionados.
  • Los checkouts HTTPS y SSH del mismo origen usan una identidad de proyecto anónima común.
  • Las URLs de repositorio y las rutas de proyecto locales nunca se guardan en registros de candidatos de aprendizaje; el trabajo fuera de Git conserva el comportamiento existente a nivel de perfil.
9.1.398
  • Las respuestas solo de texto de Telegram se deduplican ahora a través de la ruta de herramienta y de ambas rutas de reserva automáticas.
  • Una respuesta idéntica o casi idéntica solo se suprime si no hay un mensaje entrante más reciente.
  • Los adjuntos, los resultados diferentes y las respuestas tras un mensaje de usuario nuevo conservan su comportamiento anterior.
9.1.397
  • Los objetivos con un criterio de finalización expreso necesitan ahora, antes de la finalización, un punto de control respaldado por el runtime.
  • Si falla la comprobación de finalización, el objetivo permanece activo y devuelve indicaciones concretas para la revisión.
  • Los turnos ordinarios y los objetivos sin criterio de finalización expreso conservan su comportamiento anterior.
9.1.396
  • Las solicitudes naturales pueden preseleccionar en el mismo turno hasta dos esquemas de herramientas cargables que coinciden con un alto grado de confianza.
  • La selección considera exclusivamente la intención actual en el canal e ignora el contexto de Telegram obsoleto.
  • Para solicitudes débiles, ambiguas o desconocidas, ToolSearch sigue disponible sin ampliar el conjunto de herramientas cargado de forma permanente.
9.1.395
  • Los trabajos de medios aceptados se siguen de forma permanente, las solicitudes abiertas iguales se reutilizan y los resultados completados se guardan tras un control de calidad y se entregan al chat correspondiente.
9.1.394
  • Un proveedor de almacenamiento versionado y de activación opcional puede conectar los turnos de CLI y portal con un flujo común de eventos cognitivos.
  • El valor predeterminado sigue siendo el almacenamiento SQLite local existente, sin nuevo acceso de red ni comportamiento de ejecución modificado.
  • Las rutas de proveedor, las funciones de fábrica síncronas y la versión 6 del contrato se comprueban de forma segura antes del inicio del runtime y se rechazan ante divergencias.
9.1.393
  • Los inicios interactivos con king y king -c vuelven a mostrar la selección de actualización visible 1/2/3 en cuanto existe una versión más reciente.
  • La descarga de actualizaciones en segundo plano, la activación pendiente y el cambio automático diferido se han eliminado.
  • Tras una instalación seleccionada, king se cierra para que lo reinicies manualmente; king -c reanuda la última sesión con la nueva versión.
9.1.392
  • Los estados intermedios incompletos de una generación de imágenes ya no se envían como actualización privada de Telegram mientras no exista un resultado multimedia.
  • Las descripciones de error medidas de GenerateImage y GetMedia se suprimen; las entregas de medios completadas siguen siendo visibles.
  • Las conversaciones privadas y los resultados solicitados ordinarios permanecen sin cambios.
9.1.391
  • La continuidad de los recuerdos entre portales exige ahora un comprobante exacto y activo de vinculación de identidad del runtime de confianza.
  • Los nombres similares, los tenants o identidades de origen divergentes, los emisores falsos y los comprobantes revocados permanecen separados y se rechazan de forma segura.
  • La versión 6 del contrato del adaptador de memoria admite OAuth verificado, vinculaciones de cuenta seguras y asignaciones de identidad confirmadas expresamente, sin derivar permisos de los recuerdos.
9.1.390
  • El sobre de almacenamiento común registra ahora por separado el momento del evento y el momento de recepción.
  • Cada evento cognitivo nuevo recibe expresamente una clase de retención para datos operativos, datos persistentes, relaciones o fines de auditoría.
  • La versión 5 del contrato del adaptador de memoria rechaza los sobres de evento incompletos antes de cada escritura local o remota.
9.1.389
  • Los eventos de memoria registran ahora el portal de origen y el canal de origen como campos de procedencia separados y autenticados.
  • Las rutas de CLI, Telegram, runtime, personalidad, corrección y revocación conservan el canal exacto al guardar y al reproducir.
  • La versión 4 del contrato del adaptador de memoria rechaza las escrituras cuando el canal de origen guardado no coincide con el canal autorizado por el permiso.
9.1.388
  • Las lecturas de memoria devuelven solo observaciones del ámbito de visibilidad autorizado por el permiso, salvo que se use la ruta estrictamente interna de agente.
  • Las escrituras, las comprobaciones de evento y las operaciones de atención se rechazan de forma segura cuando su ámbito o su fuente autenticada no encajan en el contexto de acceso actual.
  • El adaptador SQLite local consulta las observaciones delimitadas a través de un índice de visibilidad propio, en lugar de cargar primero recuerdos no relacionados.
9.1.387
  • Cada operación de un adaptador de memoria lleva ahora un contexto estricto de identidad, portal, canal, conversación, ámbito y permisos.
  • El contexto de permisos se comprueba fuera de la carga útil de memoria y no se archiva de forma permanente como contenido recordado.
  • La deduplicación de eventos se limita al tenant y al agente. Así, la existencia de eventos no puede reconocerse entre tenants.
9.1.386
  • El estado cognitivo se encuentra ahora detrás de un contrato versionado para adaptadores de memoria, que el ciclo de vida del turno y el runtime de personalidad usan conjuntamente.
  • El almacén de eventos SQLite existente sigue siendo el valor predeterminado. Los clientes de portal externos pueden proporcionar el mismo contrato sin crear un estado propio del portal.
  • Las versiones de adaptador no compatibles y las implementaciones incompletas se rechazan de forma segura antes de cada operación de memoria.
9.1.385
  • Los mensajes de Telegram encolados antes del inicio de la sesión se liberan ahora en cuanto la sesión está lista.
  • Las sesiones inactivas vacían la cola en el orden FIFO normal; los turnos activos ya reanudados usan un control limitado.
  • Los puntos de control persistentes de la cola permanecen sin cambios hasta que el mensaje se ha aceptado realmente.
9.1.384
  • Las referencias a imágenes de Telegram cargan ahora en el mismo turno las herramientas de comprobación y generación de imágenes.
  • Los mensajes de Telegram almacenados en búfer conservan la intención de medios para todo el lote pendiente, en lugar de considerar solo el último mensaje.
  • Las rutas de imagen locales y los identificadores de archivo de Telegram eligen la vía de comprobación o descarga adecuada, sin cargar esquemas de medios de forma permanente.
9.1.383
  • Los nuevos resultados de Read permanecen ahora totalmente visibles para el paso de modelo que los solicitó, en lugar de externalizarse antes de la evaluación.
  • Los resultados de herramientas nuevos en paralelo permanecen legibles hasta su paso de evaluación y solo pueden archivarse después de volverse históricos.
  • El archivado de salidas históricas y el ahorro de contexto siguen activos tras la ventana protegida para el trabajo más reciente.
9.1.382
  • El comando /loop se acepta ahora también mientras se está ejecutando otra respuesta.
  • Si se crea un bucle durante el trabajo en curso, King lo guarda y encola su primera instrucción sin interrumpir el turno actual.
  • La creación de bucles en reposo y el comportamiento existente para estado, pausa, reanudación y parada permanecen sin cambios.
9.1.381
  • Tras una ToolSearch definitivamente fallida, ToolSearch se elimina de la lista de herramientas activas para el resto de este turno.
  • El reconocimiento exitoso de esquemas y el manejo de herramientas ya cargadas siguen disponibles y sin cambios.
  • Así, las búsquedas repetidas de sinónimos no consumen más tokens después de que el runtime ya haya demostrado que no existe una integración adecuada.
9.1.380
  • Un error transitorio en el control del turno activo reactiva ahora de inmediato el control de entrega de Telegram, en lugar de hacer esperar al mensaje de grupo recuperado hasta el final del turno.
  • Los mensajes de grupo pendientes se siguen entregando también durante trabajos largos; se conservan el orden FIFO y el límite existente de cuarentena de tres intentos.
  • Ninguna sesión en curso se interrumpe ni se reinicia.
9.1.379
  • Los reintentos transitorios de la confirmación de un control de canal ya no muestran un falso error rojo mientras el mensaje siga siendo recuperable en la cola.
  • Un error de entrega visible aparece solo después de que el tercer intento fallido haya archivado de forma segura la primera entrada completa de la cola.
  • El comportamiento para reintento, confirmación, archivado y orden FIFO permanece sin cambios.
9.1.378
  • Con publicaciones en segundo plano muy seguidas existe ahora un único estado sustituible para la actualización preparada, en lugar de añadir una nueva entrada de registro por cada versión.
  • La entrada de la actualización preparada muestra siempre la versión de destino verificada más reciente; la sesión activa permanece intacta hasta su reinicio natural.
  • La indicación de la instalación real y del changelog se conserva de forma permanente y sin cambios. Por tanto, que haya menos cambios en el registro no oculta ninguna actualización activada.
9.1.377
  • Las tareas pendientes de Telegram toman ahora del núcleo el ID determinante del turno activo. Un estado visible obsoleto de la TUI ya no puede hacer que un mensaje aceptado quede sin confirmar.
  • El comando de control /loop se ejecuta inmediatamente durante el trabajo en curso; la confirmación persistente del comando ya no depende de una respuesta de estado exitosa de Telegram.
  • Si la entrega de la primera entrada de la cola falla tres veces, se archiva localmente con todos los metadatos de recuperación antes de que la cola continúe. Así, una entrada defectuosa no bloquea mensajes posteriores.
9.1.376
  • Los resultados históricos grandes de herramientas se guardan de forma permanente antes de la compactación de contexto, de modo que su salida completa siga siendo recuperable también después de vaciar la vista previa incrustada.
  • Las referencias de resultados guardadas sobreviven a microcompactaciones posteriores y conservan los metadatos limitados necesarios para volver a cargar la salida original.
  • La telemetría de descarga informa de tamaños y estado de recuperación, sin exponer contenidos de resultados ni rutas privadas.
9.1.375
  • Los DM privados de Telegram y los comandos de barra conservan la máxima prioridad de entrega. El trabajo de grupo dirigido expresamente se encola después en FIFO, antes del trabajo antiguo normal o no dirigido.
  • Un traspaso de actualización solo puede atravesar una cola no vacía si cada entrada es trabajo de Telegram persistente, aún no confirmado y con vía de retorno de acknowledgement. El trabajo local, mixto o no persistente sigue bloqueando.
  • La indicación de actualizaciones preparadas sigue un idioma de UI de persona validado. En un idioma aún no validado como locale de TUI solo se muestra la información de versión, en lugar de caer en un idioma equivocado.
9.1.374
  • La indicación de una actualización preparada ya no usa un mensaje alemán fijo, sino la traducción de UI ya validada del idioma activo.
  • Los modos de sesión de reanudación y de sesión nueva permanecen separados; el traspaso de actualización, el rollback y la confirmación de duplicados de Telegram no se han debilitado.
9.1.373
  • Una actualización preparada en segundo plano puede asumir ahora la sesión en curso en un límite seguro verificado. El ID de sesión y el directorio de trabajo se conservan; las herramientas en curso, los comandos de shell, la compactación y los mensajes en espera impiden la transferencia.
  • El supervisor activa el nuevo runtime solo tras su comprobante loaded y ready. Si el inicio falla, se restablece el runtime antiguo con la sesión exacta y se descarta la actualización pendiente defectuosa.
  • Los duplicados de Telegram ya restablecidos en el libro de entregas se confirman de inmediato en la reproducción de la cola. Ya no esperan un paso de modelo que deliberadamente nunca se inicia para un duplicado, y por tanto ya no bloquean mensajes de grupo posteriores.
  • El foco de trabajo persistente lleva ahora el estado de conocimiento, el contexto de comprobante, las correcciones, las retractaciones y la confianza a través de los turnos. De ello no surgen nuevos derechos ni aprobaciones.
9.1.372
  • Los puntos de control de objetivo persistentes distinguen ahora verified, credible_unverified, hypothesis, uncertain_memory, stale y unknown. Así, las suposiciones plausibles ya no se tratan como conocimiento contrastado.
  • La procedencia y el estado de conocimiento se comprueban conjuntamente: los comprobantes de herramientas del runtime solo pueden valer como verified tras una ejecución exitosa de herramienta, no los informes externos. Los estados arrastrados (carry-forward) conservan su estado anterior y su último comprobante de verificación.
  • Los estados antiguos de reproducción sin el campo nuevo siguen siendo legibles como legacy_unknown. Los puntos de control nuevos deben nombrar su estado expresamente. Los derechos, las aprobaciones y la autoridad permanecen sin cambios.
  • La proyección de contexto escueta nombra el estado epistémico en exactamente una línea, para que el agente lo considere en el siguiente paso sin cargar el presupuesto de contexto con texto adicional.
9.1.371
  • Reparación de un error de cableado de 9.1.370: el valor evidenceBasis ya guardado y proyectado allí es ahora también parte del estricto esquema de salida público de GetGoal y ya no se pierde al recuperarlo.
  • El esquema acepta los cuatro tipos de procedencia actuales así como legacy_unknown para estados antiguos de reproducción. Los derechos, las aprobaciones y la autoridad permanecen sin cambios.
  • Una prueba de cableado específica y un mutante propio aseguran la nueva conexión pública contra regresiones.
9.1.370
  • Cada punto de control de trabajo reciente nombra ahora explícitamente en qué se basa su último estado evidenciado: llamada de herramienta del runtime exitosa, afirmación directa del usuario, informe externo o continuación sin cambios.
  • runtime_tool solo se acepta si el turno actual contiene al menos una llamada de herramienta permitida por el runtime y finalizada con éxito. carried_forward no puede modificar el último estado evidenciado. Ante una contradicción, ambas rutas se interrumpen y quedan bloqueadas por defecto (fail-closed).
  • Los puntos de control antiguos guardados siguen siendo legibles como legacy_unknown. El tipo de procedencia es estado epistémico y no genera derechos, aprobaciones ni autoridad.
9.1.369
  • Un punto de control de trabajo persistente recibe ahora automáticamente un comprobante de runtime compacto de las llamadas de herramienta ya finalizadas del mismo turno. El comprobante nombra solo el ID de turno, el total, el número de éxitos y errores y un digest corto.
  • Los nombres de herramientas, IDs, argumentos, comandos, salidas, rutas y texto de usuario no se escriben en el punto de control. Un comprobante vacío se queda honestamente en cero en lugar de simular una medición.
  • Solo una llamada de herramienta autorizada por la política del runtime y finalizada con éxito cuenta como éxito. Los comprobantes bloqueados, fallidos, cancelados o aportados por el modelo no generan autoridad.
9.1.368
  • Cada punto de control de trabajo persistente lleva ahora una revisión monótona. El primer acceso de escritura comienza en la revisión 1; cada siguiente debe aumentar la revisión proyectada actual en exactamente uno.
  • Un turno paralelo antiguo o una vista de canal obsoleta ya no pueden sobrescribir posteriormente un estado de trabajo evidenciado más reciente. Las revisiones obsoletas, omitidas y no válidas se interrumpen, bloqueadas por defecto (fail-closed), antes de que se modifique el estado del objetivo.
  • Los puntos de control existentes sin campo de revisión se tratan de forma compatible como revisión 1 al leerlos. La revisión es estado de trabajo y no genera derechos ni aprobaciones.
9.1.367
  • El recordatorio de objetivo activo lleva ahora directamente el punto de control de trabajo persistente. Por eso, el King conserva la fase, el último estado evidenciado, la siguiente acción exacta y el comprobante esperado incluso cuando el adaptador de memoria cognitiva adicional no está disponible en ese momento.
  • Antes de recurrir a caminos alternativos, se ejecuta primero la siguiente acción anotada exactamente. El punto de control solo se modifica cuando una nueva evidencia cambia realmente el estado confirmado.
  • El recurso de reserva es solo una proyección compacta del punto de control ya comprobado. No genera derechos, nuevos campos de datos ni un reinicio.
9.1.366
  • Los objetivos activos pueden guardar ahora un pequeño punto de control de trabajo persistente con fase, último resultado evidenciado, siguiente acción exacta y comprobante esperado. Tras una reanudación o una reproducción de eventos, el King continúa en ese punto, en lugar de volver a pedir permiso o empezar de nuevo.
  • Una mera actualización de punto de control mantiene el objetivo activo. Los objetivos pausados y bloqueados permanecen sin cambios; una reanudación solo reinicia el reloj de ejecución.
  • El punto de control está estrictamente limitado y es pura información de trabajo. Los campos desconocidos, especialmente los datos de derechos o de administración, se interrumpen bloqueados por defecto (fail-closed) y no pueden generar ninguna capacidad.
  • Sin punto de control, el foco compacto anterior permanece sin cambios. Con punto de control, solo las cuatro observaciones de foco relevantes se completan con el estado evidenciado; así el gasto de tokens se mantiene bajo y constante.
9.1.365
  • Los DM privados de Telegram y la CLI local pueden ahora leer, corregir o eliminar directamente el foco persistente con /memory focus, /memory correct <id> <valor> y /memory delete <id>. El camino no inicia ningún turno de modelo y por tanto no consume tokens de modelo.
  • Los cambios de Telegram están vinculados a ID positivos de usuario, chat y mensaje, a un DM privado real, al momento del canal y a un ID de solicitud estable. Los grupos, la procedencia incompleta y las repeticiones alteradas se interrumpen bloqueados por defecto (fail-closed).
  • El dominio, la clave y el ámbito se derivan siempre del comprobante de objetivo activo y el llamador no puede introducirlos. Las correcciones y los tombstones siguen siendo de solo anexión, conservan el historial y no otorgan derechos.
  • La salida de foco se limita para Telegram a ocho entradas y a menos de 3.500 caracteres; el número total sigue siendo visible.
9.1.364
  • El ciclo de vida cognitivo en curso puede corregir ahora un foco persistente mediante correctFocusObservation y eliminarlo mediante withdrawFocusObservation. Ambas vías siguen escribiendo en modo de solo anexión en el mismo flujo de eventos vinculado al tenant y al agente.
  • Una revisión solo está permitida con la atestación runtime_user_prompt_hook y explicit_user_request. Una instantánea normal del modelo no puede derivar ni introducir una corrección o eliminación.
  • Cada revisión lleva un ID de solicitud estable, así como portal, actor, contexto, mensaje y momento. La repetición idéntica es idempotente; el mismo ID de solicitud con contenido modificado y las revisiones retrodatadas se interrumpen bloqueados por defecto (fail-closed).
  • La corrección y la eliminación posterior dejan intacto el historial completo. Tras la eliminación, el hecho ya no aparece en el prompt y no consume tokens de contexto. La memoria sigue sin poder otorgar derechos.
9.1.363
  • Una eliminación confirmada se guarda ahora como tombstone de solo anexión. El contenido anterior permanece en el historial de auditoría y en la cadena de hash, pero desaparece por completo de la proyección de contexto efectiva.
  • Los eventos antiguos de reanudación, transcript o cola con un momento anterior a la eliminación no pueden reactivar el contenido eliminado. Así, un estado antiguo reproducido más tarde no se trata como nueva verdad.
  • La información que se vuelva a facilitar deliberadamente después del momento de la eliminación puede aprenderse de nuevo. Así pues, el tombstone bloquea la evidencia antigua, no el desarrollo futuro.
  • Las eliminaciones en tenants, agentes, dominios, claves o ámbitos ajenos, con objetivo ausente, confianza débil o valor de tombstone incorrecto se rechazan transaccionalmente. Las bases de datos existentes migran in situ.
  • Un hecho eliminado no genera ninguna línea de prompt y por tanto no consume tokens de contexto.
9.1.362
  • Una corrección confirmada puede ahora sustituir de forma explícita exactamente una observación anterior en el mismo ámbito de tenant, agente, dominio, clave y alcance. La entrada antigua se conserva en el historial de auditoría de solo anexión.
  • La vista efectiva carga el valor corregido y lo marca como corrected; el valor sustituido ya no se proyecta como conflicto actual.
  • Los objetivos ausentes, los ámbitos o claves ajenos y las correcciones por debajo de la confianza 1 se rechazan transaccionalmente.
  • Las bases SQLite existentes reciben la nueva columna de relaciones al abrirse, sin perder su flujo anterior ni su versión.
9.1.361
  • Las afirmaciones personales o de equipo igualmente creíbles con el mismo alcance y clave ya no se emiten como verdad según el principio «gana el valor más reciente». La proyección marca el conflicto de forma escueta y pide una aclaración, sin volcar ambos contenidos al contexto.
  • Si una afirmación es al menos 0,2 puntos de confianza más fuerte, sigue siendo utilizable, pero se marca como disputada. Una afirmación posterior más débil ya no puede ocultar un estado confirmado.
  • Las confirmaciones idénticas se agrupan en un punto de foco. Los campos canónicos de objetivo y progreso siguen siendo revisables.
  • El historial de eventos de solo anexión permanece sin cambios; de la vista efectiva siguen sin poder surgir permisos.
9.1.360
  • El estado de /goal, que ya es canónico, se proyecta como foco de trabajo persistente en el flujo de eventos cognitivos: objetivo, estado, siguiente disparador y comprobante de éxito esperado.
  • El mismo foco permanece idempotente a través de reinicios del runtime. Un estado de objetivo sin cambios no genera eventos ni observaciones duplicados.
  • Los contadores de uso, el presupuesto de tiempo y los permisos no se copian al foco. Sin objetivo activo no se cargan tokens de foco adicionales.
  • La proyección vincula el ámbito de objetivo adecuado con el ámbito de relaciones privado del turno actual; no genera derechos.
9.1.359
  • La memoria de personalidad y los turnos reales de CLI usan ahora el mismo flujo de identidad de tenant y agente de identity/manifest.json; sin identidad completa se conserva la ruta de reserva con hash compatible.
  • Los turnos directos de Telegram proyectan solo el ámbito de relaciones privado del interlocutor actual. Los grupos y las relaciones ajenas no aportan tokens de foco privados.
  • La selección de ámbito está forzada antes de la clasificación; un hallazgo más reciente de un ámbito ajeno ya no puede ocultar una entrada adecuada.
9.1.358
  • Un error de red durante la preparación automática de la actualización solo se notificaba a un callback de error opcional. Sin un nuevo sondeo, el King en ejecución se quedaba en su versión, aunque la propia sesión seguía funcionando correctamente.
  • El launcher escribe ahora un evento limitado prepare-failed con la versión y el nombre o código de error seguro en handoff.jsonl.
  • Después se programa un nuevo intento de preparación exactamente diez segundos más tarde. El núcleo en curso no se termina ni se vuelve a cargar.
  • Los errores al escribir el evento de diagnóstico siguen siendo tolerantes (fail-soft); no se registran tokens, textos de mensajes ni otros secretos.
9.1.357
  • Los accesos repetidos al mismo prompt de sistema efectivo ya no reconstruyen la gran cadena de caracteres de base y anexo del runtime en cada acceso.
  • El resolver mantiene exactamente una combinación actual de base y anexo y la invalida de inmediato en cuanto cambia uno de los dos valores de entrada.
  • El prompt vacío, solo base, solo anexo y la separación anterior con dos saltos de línea se conservan idénticos byte a byte.
9.1.356
  • Los prompts de sistema sin cambios solo se cuentan una vez, carácter a carácter, para el presupuesto de contexto a lo largo de pasos de modelo repetidos.
  • La caché se limita a cuatro entradas, como máximo 500.000 caracteres por prompt y en total 1.000.000 de caracteres retenidos.
  • Los prompts modificados se siguen contando de nuevo; la visualización de contexto, el presupuesto de compactación y el presupuesto de solicitud usan el mismo valor actual.
9.1.355
  • Las configuraciones de solicitud LLM sin cambios ya no vuelven a serializar sus esquemas de herramientas en cada paso de modelo solo para el registro de configuración.
  • El modelo, el alias, el nivel de razonamiento, el prompt de sistema y la secuencia de herramientas se comparan contra el último estado completo.
  • Los modelos, prompts, nombres de herramientas, descripciones o esquemas de parámetros modificados siguen reabriendo de forma selectiva el registro de configuración.
9.1.354
  • Los esquemas de herramientas sin cambios solo se serializan una vez por objeto de herramienta y se cuentan para el presupuesto de contexto.
  • Un inventario con 403 herramientas ya no se vuelve a contar por completo en las comprobaciones de solicitud repetidas.
  • Los cambios en el nombre, la descripción o el objeto de parámetros descartan específicamente solo la entrada de caché de la herramienta afectada.
9.1.353
  • Los fragmentos de argumentos de las herramientas de enjambre de agentes se siguen analizando de inmediato y se incorporan al estado de progreso, pero ahora comparten el temporizador de renderizado adaptativo.
  • Una llamada de herramienta grande transmitida ya no provoca por ello un renderizado completo de la TUI por cada fragmento de argumento.
  • El inicio, la finalización, el error y la cancelación eliminan los temporizadores de enjambre abiertos antes de su renderizado final inmediato.
9.1.352
  • Los fragmentos de assistant y thinking de un enjambre de agentes siguen actualizando el estado de progreso de inmediato, pero comparten un temporizador de renderizado adaptativo.
  • Una tormenta de fragmentos ya no provoca por ello un renderizado completo de la TUI por cada delta.
  • Los eventos discretos de enjambre y la limpieza del progreso eliminan los temporizadores abiertos antes de su renderizado final inmediato.
9.1.351
  • Los fragmentos de assistant y thinking en la ventana BTW/agente se guardan de inmediato en el turno, pero comparten un temporizador de renderizado adaptativo.
  • El controlador ya no solicita un renderizado completo adicional por fragmento para estos dos tipos de delta.
  • La finalización, el error, el reintento y el dispose eliminan los temporizadores abiertos; los eventos discretos de hook y finalización siguen siendo visibles de inmediato.
9.1.350
  • ToolCallComponent.appendSubToolLiveOutput incorpora de inmediato los chunks de stdout y stderr al estado de actividad, pero reconstruye la tarjeta de subagente solo al ritmo de streaming adaptativo.
  • Un conjunto compartido de pendientes maneja varios subtools en ejecución simultánea sin salida perdida ni un temporizador por chunk.
  • La finalización de herramienta elimina su refresh abierto antes de la representación final; dispose descarta limpiamente los temporizadores y el conjunto de pendientes.
9.1.349
  • ToolCallComponent.appendSubagentText reúne de inmediato en el estado interno los fragmentos de texto y thinking que llegan rápidamente, pero reconstruye la tarjeta de subagente solo al ritmo de streaming adaptativo.
  • La finalización y el estado de error vacían un refresh de texto aún abierto antes de la representación final; dispose descarta limpiamente el temporizador.
  • Así, los bytes entrantes siguen disponibles de inmediato, mientras que se eliminan los rebuilds completos, las instantáneas y los renders repetidos en las ráfagas de fragmentos.
9.1.348
  • Los argumentos crecientes de las herramientas de subagente o subherramienta se siguen reuniendo de inmediato por completo, pero ya no se vuelven a analizar y renderizar tras cada fragmento individual.
  • Un temporizador adaptativo agrupa la actualización de la vista previa. Al finalizar, los argumentos pendientes se incorporan obligatoriamente antes del estado final de la herramienta.
  • La ejecución de herramientas, las aprobaciones, los argumentos finales y la ruta normal de streaming existente permanecen sin cambios.
9.1.347
  • La ruta de eventos llamaba de inmediato a getStreamingToolCallPreview tras cada delta de argumento de herramienta entrante. Esta función analiza el texto JSON creciente completo hasta ese momento.
  • La llamada se producía también para herramientas normales, aunque solo AgentSwarm necesita el estado intermedio analizado de inmediato para su indicador de progreso en curso. Así, la ruta normal evitaba parcialmente la cadencia de vista previa limitada introducida en 9.1.346.
  • Una pequeña política pura decide ahora antes del análisis: las herramientas normales solo reúnen el delta y analizan en el flush de vista previa planificado; AgentSwarm sigue analizando de inmediato por nombre de evento, nombre de herramienta activo o progreso de enjambre existente.
  • La ejecución de herramientas, las aprobaciones, los argumentos finales y la visualización de enjambre permanecen sin cambios.
9.1.346
  • 9.1.345 limitó los re-renderizados de texto completo para los streams largos de respuesta y thinking; los streams puros de argumentos de herramientas no tenían ninguno de estos dos borradores de texto y por tanto permanecían en 50 ms fijos.
  • Cada vista previa de herramienta analiza el texto JSON de argumentos creciente completo hasta ese momento. Las llamadas grandes de herramientas podían por tanto seguir analizando y renderizando la carga útil completa con mucha frecuencia.
  • La cadencia adaptativa ya demostrada considera ahora también el número total de caracteres de los argumentos de herramienta transmitidos activos: 50, 100, 250 o 500 ms según los mismos límites.
  • La ejecución de herramientas, los argumentos, las aprobaciones, la vista previa final y los flushes de finalización inmediatos permanecen sin cambios.
9.1.345
  • Hasta ahora, durante el streaming, la TUI volvía a renderizar cada 50 ms todo el texto de respuesta y thinking acumulado hasta ese momento. Con respuestas largas de modelo, la cantidad de texto a renderizar repetidamente crecía mucho.
  • Los streams cortos de hasta 8.192 caracteres conservan la cadencia rápida anterior de 50-ms. Después, el intervalo aumenta por niveles a 100 ms hasta 32.768, 250 ms hasta 131.072 y 500 ms por encima.
  • Los flushes explícitos en los límites de herramientas y en la finalización siguen siendo inmediatos. La lógica de proveedor, cola, sesión y tokens no se ha modificado.
9.1.344
  • Hasta ahora, la capa cognitiva del runtime escribía la política y el resultado de cada llamada de herramienta en dos transacciones SQLite síncronas separadas.
  • Una prueba de costes aislada en Windows con 100 llamadas de herramienta necesitó para ello 627,63 ms y generó 201 eventos. El contenido comprendía 305 observaciones.
  • Los pares de política y resultado completados de un paso de modelo se confirman ahora atómicamente en grupos limitados de como máximo diez herramientas. Las comprobaciones de política canceladas o aún abiertas se siguen guardando individualmente al final del turno.
  • Los argumentos, las salidas, la decisión de derechos, la cadena de hash y la persistencia de SQLite permanecen sin cambios.
9.1.343
  • Una respuesta privada de Telegram ya se había entregado con éxito con la herramienta de respuesta. Después, el mismo turno de modelo inició sin embargo otro paso más y generó texto interno de estado y control de trabajo.
  • El paso adicional costó en la sesión real medida 42.360 tokens de entrada y 411 de salida, aunque la respuesta visible al usuario ya se había enviado.
  • Una respuesta de Telegram exitosa finaliza ahora de inmediato un turno de conversación privada marcado como direct. Las respuestas fallidas, los grupos y otras herramientas siguen funcionando sin cambios.
  • Tras la finalización sigue actuando el controlador de foco directo existente: anota la respuesta entregada y vuelve al trabajo en segundo plano guardado tras el fin de la conversación o el tiempo de reposo.
9.1.342
  • La consulta de relevancia para Mistake.md incluía hasta ahora cada mensaje con el rol user. Entre ellos había también inyecciones internas, resúmenes de compactación, activaciones de skills y avisos en segundo plano.
  • Como el recordatorio de Mistake se guarda a su vez como mensaje interno de user, modificaba su propia consulta tras cada paso de herramienta. Así, en el mismo turno volvía a seleccionarse e inyectarse.
  • El filtro usa ahora solo las entradas de usuario y cron relevantes para la acción. Los textos internos del runtime se excluyen de la consulta de relevancia y del reconocimiento de baja información.
  • Los mensajes reales de usuario, el trabajo planificado, todas las lecciones verificadas y la reconstrucción tras la compactación siguen disponibles sin cambios.
9.1.341
  • En el inicio natural, el launcher encontraba un runtime automático ya preparado y verificado localmente, pero aun así lo hacía pasar primero por el aviso de actualización dependiente de la red. Si esta segunda consulta fallaba temporalmente, se iniciaba de nuevo la versión global antigua.
  • Un runtime automático preparado con el modo exactamente adecuado (resume o new) se inicia ahora antes de volver a consultar las versiones. La activación sigue siendo transaccional: el runtime solo se contabiliza como activo cuando el nuevo núcleo se ha cargado con éxito.
  • En resume se conservan el ID de sesión y el directorio de trabajo. La selección manual de actualización sigue pasando por la vía de indicación anterior.
  • No se cierra ningún King en ejecución. La corrección solo actúa en el siguiente inicio natural.
9.1.340
  • El launcher escribía las actualizaciones exitosas en .blun/updates/install.json, mientras que un runtime de perfil buscaba en .blun/profile/<name>/updates/install.json. La ruta real de perfil no existía; por eso notifiedAt permanecía en null en el estado compartido.
  • Los runtimes de perfil leen ahora el éxito de la actualización de BLUN_SHARED_HOME y solo recurren al BLUN_HOME anterior si no hay una ruta compartida.
  • Tras el siguiente inicio natural, la TUI puede mostrar una sola vez la versión y hasta tres notas de la versión. Los destinatarios privados de Telegram configurados reciben el mismo texto corto sin turno de modelo y sin consumo de tokens.
  • La instalación, el staging, la activación y la regla de nunca expulsar permanecen sin cambios.
9.1.339
  • Con esfuerzo bajo, los pasos que siguen a una llamada de herramienta exitosa usan como máximo 4.096 tokens de finalización en lugar de los 8.192 de antes.
  • Los primeros pasos, las tareas complejas y los pasos posteriores a un error conservan su capacidad configurada de razonamiento y de salida. Esta intervención no es un límite global del modelo ni del contexto.
  • La medición retrospectiva sobre 1.442 pasos reales con esfuerzo bajo de un perfil de agente arrojó: 2.118.588 tokens de salida en total, mediana 791, p90 3.754, p95 5.485. Con el nuevo límite se habrían recortado 229.761 tokens, es decir, el 10,8 Prozent; el 91,1 Prozent de los pasos medidos no cambia.
9.1.338
  • Las preguntas meramente repetitivas, como ¿Puedo continuar con mi trabajo?, ya no se entregan en las conversaciones privadas de Telegram.
  • La narración interna de cola, traspaso, carril y estado de espera queda fuera de la respuesta privada. Los resultados de trabajo reales y las respuestas personales normales siguen siendo entregables.
  • Si una respuesta útil termina solo con una nueva pregunta de aprobación de trabajo, se elimina exclusivamente esa pregunta final.
  • El enrutamiento de grupos y las sesiones en curso permanecen sin cambios.
9.1.337
  • profile/<name>/SOUL.md es la ruta de identidad canónica de un King.
  • Un alma legacy con el nombre correspondiente solo sustituye a un esqueleto de perfil generado que no se haya modificado. Las almas de perfil desarrolladas nunca se sobrescriben.
  • Antes de una importación legacy, el esqueleto generado se guarda como SOUL.md.pre-legacy-import.
  • TGZ-SHA256: A50947748BE702FA331D19ABFD08E5F13080B207324F05281815D3446230B608.
  • npm-shasum: 221c4b2ac5083e4d63e25a8543f06ba66f2bbb28.
  • npm-integrity: sha512-qna0Bh2EccxXs+7ctK+NxP8XCYBE5CyxkZSJcHYq4G92ERNwujIWfNzmR24Yi9xlRxev/vOcW3HUW2OPyePpNg==.
9.1.336
  • Las sesiones interrumpidas normalizan su estado de reproducción antes de que se entregue más trabajo de Telegram.
  • Si se rechaza la entrega a un turno activo, el mensaje recurre a un nuevo turno en cola en lugar de reintentar la misma inyección (steer) cada cinco segundos.
  • Los puntos de control del foco de DM conservan los temporizadores automáticos de reanudación y las pausas explícitas de una actualización a otra.
  • TGZ-SHA256: 57E6581AA95FEE1BD4CD12671F62A316B707106C59B2915A8385424B163C6E76.
  • npm-shasum: bd910c38e17b1b6dc6be2f965bdee5fe90e22084.
  • npm-integrity: sha512-xjwxBcTVo3KS+ATnxhVozRD4JzUqoJNAbiLeH30ZucpkTxuB4kfGK/GQ+eZqJDIJW2TtODg8yWw9DuLdP73UDA==.
9.1.335
  • Un mensaje privado normal de Telegram ya solo interrumpe la tarea en curso durante la conversación inmediata. Después, a los 60 segundos, King reanuda automáticamente el trabajo desde el estado exacto guardado, sin volver a pedir permiso.
  • Si la conversación se da por terminada de forma expresa, la tarea se reanuda de inmediato. Solo las peticiones claras del usuario, como pause, pausiere, stop, stopp, warte o halte an, mantienen la tarea detenida hasta que el usuario vuelva a autorizarla.
  • Los términos internos y los informes de estado sobre cron, puntos de control, cola o carril se suprimen en las respuestas privadas normales. El trabajo en sí y su estado guardado no cambian.
9.1.334
  • La preparación automática en segundo plano ya no se queda bloqueada indefinidamente cuando las versiones se suceden con rapidez. El bloqueo anterior de 30 minutos se aplicaba siempre a la versión más reciente; por eso, con una versión nueva cada minuto, ninguna llegaba a tener la antigüedad suficiente para prepararse.
  • Una versión que coincide criptográficamente se descarga ahora de inmediato, se comprueba su integridad, se instala de forma aislada, se somete a una comprobación sintáctica y se marca como runtime pendiente.
  • La sesión de King en curso sigue sin cerrarse. La activación y la reanudación siguen produciéndose exclusivamente en la ruta protegida ya existente del próximo inicio. Esta versión no cambia ni la lógica de traspaso ni la de sesión.
9.1.333
  • Tras la 9.1.331, una captura de pantalla en directo evidenció un ERR_MODULE_NOT_FOUND en el plugin gestionado de Telegram.
  • La importación del plugin apuntaba desde el árbol gestionado aislado a un archivo del núcleo que no se había instalado allí.
  • El enorme texto de repetición, también medido, circulaba en el flujo de razonamiento visible. El bloqueo de repetición en vivo existente comprobaba hasta entonces solo los deltas de respuesta.
  • 9.1.332 no se activó en el manifiesto público tras el hallazgo del plugin. 9.1.333 sustituye por completo a este candidato npm.
9.1.332 No publicado
  • No publicado. Una importación de plugin apuntaba desde el árbol aislado a un archivo del núcleo no incluido; 9.1.333 sustituyó por completo al candidato npm.
9.1.331
  • Las conversaciones privadas de Telegram conservan las respuestas naturales y los resultados de trabajo solicitados.
  • Los avisos internos duplicados detectados en las mediciones sobre trabajos en pausa, respuestas ya enviadas, turnos en curso, estado de herramientas y ausencia de necesidad de actuar solo se suprimen en los chats privados.
  • Un aviso solo se filtra si contiene contexto interno del runtime y, además, indica expresamente que no aporta ningún valor nuevo al usuario.
  • El enrutamiento de grupos, las confirmaciones de finalización reales y la conversación breve normal permanecen sin cambios.
9.1.330
  • El archivo fuente completo del alma de cada King se conserva sin cambios.
  • A partir de él, el contexto del modelo recibe una proyección limitada del carácter con identidad, voz, valores, relaciones, preferencias, objetivos e historia acumulada.
  • Las secciones claramente dedicadas a tareas, carriles, derechos, QA, herramientas, comandos, verificación, incidentes, registros, runtime, actualizaciones, despliegue y compilación ya no se cargan como personalidad en cada prompt.
  • Las almas breves que solo describen el carácter permanecen idénticas byte a byte. Las secciones no técnicas desconocidas siguen visibles en su orden.
  • Ningún archivo de alma se elimina, recorta o reescribe automáticamente.
9.1.329
  • Cada perfil de King con nombre usa su propio nodo de agente en el núcleo de identidad común. Las relaciones, el historial y los datos personales aprendidos ya no se mezclan en el primer agente configurado.
  • Los archivos de alma con nombre existentes, como _agent-a_soul.md, _agent-b_soul.md o _agent-c_soul.md, se asignan al perfil correspondiente y se incorporan una sola vez, idénticos byte a byte, a SOUL.md.
  • El archivo de origen antiguo se conserva sin cambios. Una SOUL.md de perfil existente nunca se sobrescribe.
  • La selección de persona y el modo de personalidad leen solo los datos del perfil correspondiente. Una persona de perfil dañada, demasiado grande o enlazada no recurre sin avisar a la identidad de otro agente.
  • El núcleo común sigue siendo utilizable sin que Mnemo sea obligatorio. Las tareas en curso, los derechos y las reglas de QA no se modifican con esta migración.
9.1.328
  • La persona y SOUL.md se cargan primero desde el perfil activo.
  • Los perfiles con nombre nunca heredan el alma de otro agente desde el directorio home común.
  • Los perfiles legacy y por defecto conservan la alternativa común (fallback) anterior.
  • Si realmente falta un archivo de alma propio, se crea una vez un esqueleto mínimo; los archivos existentes nunca se sobrescriben.
  • El sistema de identidad y relaciones sigue basado en archivos y funciona sin que Mnemo sea obligatorio.
9.1.327
  • Las conversaciones privadas de Telegram se centran en la persona: los informes internos de cola, punto de control, pausa, cron, hook e inactividad se suprimen en ambas vías de envío mientras no se haya solicitado un estado de trabajo, no se necesite una decisión y no haya surgido un bloqueo relevante.
  • Los estados de trabajo técnicos van al canal de equipo correspondiente. No se copian de nuevo a la conversación privada.
  • Los bucles de repetición exacta del modelo se detectan ya durante el stream. El stream en curso del proveedor se cierra y el mismo paso se reintenta exactamente una vez con el contexto de la tarea conservado.
  • El alma, el conocimiento de personas, los derechos, las tareas en curso y la pausa existente del foco directo no se han sustituido ni eliminado. No se ha reiniciado ninguna TUI en ejecución.
9.1.326
  • Los modos de permisos manuales y automáticos reflejan las aprobaciones de herramientas como botones limitados en el DM privado de Telegram acoplado de forma inequívoca.
  • Solo se transmiten el nombre de la herramienta y los textos de selección existentes; los argumentos, las descripciones y los secretos permanecen locales. Las aprobaciones caducadas, ajenas o ya respondidas localmente se descartan y quedan bloqueadas por defecto (fail-closed).
  • El modo God sigue siendo totalmente autónomo y no genera ninguna aprobación de Telegram.
  • Los estados de trabajo técnicos se enrutan al colega correspondiente y ya no se copian de vuelta a la conversación privada del usuario.
9.1.325
  • El modo God ejecuta las escrituras personales de memoria sin una segunda pregunta de aprobación; el consentimiento existente vinculado a la sesión y al turno se conserva.
  • Una instrucción expresa de Telegram para recordar activa el mismo consentimiento estrechamente limitado que una instrucción directa de consola. Los modos de permisos manuales y automáticos siguen preguntando antes de escribir.
  • El diario de actualizaciones guarda si una instalación se inició manualmente, automáticamente o a través del diálogo de inicio.
9.1.324
  • La primera interacción de confianza con un bot lo crea localmente como nodo de agente y relación. El rol, las responsabilidades, las particularidades, la colaboración y el traspaso pueden crecer después de forma estructurada.
  • Cada King proyecta en su contexto un extracto compacto sobre sus colegas. Así conoce las tareas y particularidades de otros agentes sin cargar indiscriminadamente todo el registro de relaciones.
  • Si falta una información crítica para la tarea, no se adivina: el King pregunta exactamente una vez a la persona o al agente más adecuado. Si no se sabe quién es el responsable, pregunta al usuario en lugar de inventar un nombre.
  • Las relaciones y los roles nunca generan derechos. Los campos de permisos, ACL y secretos no se proyectan en el extracto sobre colegas. La ruta es local, vinculada al tenant, neutral en cuanto a nombres, independiente de Mnemo y no añade llamadas de modelo ni de herramientas.
9.1.323
  • Las conversaciones privadas vuelven a responder a la persona en lugar de emitir voluntariamente datos internos de procesos. Los puntos de control, hashes, rutas, diagnósticos de herramientas, cron y hooks, reglas ocultas, tareas de otros agentes e informes de inactividad permanecen internos.
  • El estado de trabajo solo se menciona cuando el usuario lo pregunta, se necesita su decisión o un bloqueo le afecta concretamente. El trabajo pausado permanece interno y no se lleva a una conversación informal.
  • La regla se aplica con y sin modo de personalidad, no contiene personas ni agentes codificados de forma fija y añade unos 75 tokens de prompt, pero ninguna llamada de modelo o herramienta. La prioridad de tareas y la obligación de aportar pruebas permanecen sin cambios.
9.1.322
  • El interruptor visible de personalidad escribe ahora persona.json de forma atómica. El nombre, el idioma, las notas y todos los demás campos de persona existentes se conservan; solo se modifica personalityEnabled.
  • SOUL.md, AGENTS.md, JOURNAL.md y los archivos de relaciones no se escriben ni al apagar ni al encender. La identidad normal de agente basada en SOUL sigue cargada en el contexto de sistema también con la función de personalidad desactivada.
  • Una actualización en vivo fallida restablece la selección de forma exacta byte a byte. Si en paralelo otro escritor ha modificado persona.json, la reversión se cancela con PERSONALITY_CHOICE_CONFLICT y no sobrescribe nada.
  • Los enlaces simbólicos y los archivos de persona sobredimensionados, no válidos o sin forma de objeto se rechazan y quedan bloqueados por defecto (fail-closed). Al encender, el árbol de identidad se prepara antes del commit.
  • No forma parte de esta versión el error de un agente, demostrado después, de emitir en conversaciones privadas puntos de control internos, reglas de cron, SHAs y detalles de tareas ajenas. Este filtro de salida es el siguiente desarrollo, por separado.
9.1.321
  • Un primer intercambio privado relajado o una indicación personal voluntaria puede colocar exactamente una oportunidad opcional de curiosidad en el contexto de modelo. No es una pregunta obligatoria; la elección de palabras y el tono siguen procediendo de la SOUL.md cargada, no de un catálogo fijo de preguntas.
  • La tarea, la urgencia, los errores, los enlaces, el código, las rutas y el tráfico de grupos suprimen la curiosidad sin excepción. Nunca envía nada por iniciativa propia y no puede interrumpir el trabajo en curso.
  • Se aplica un periodo de espera de 30 días por tenant, agente y persona vinculada, incluso entre portales distintos. Reintentar el mismo evento es idempotente.
  • El nuevo estado ya no reside como archivo de curiosidad específico de Telegram en el árbol de identidad. Un personality-memory-adapter intercambiable escribe en su lugar un evento versionado en el store cognitivo transaccional existente. Telegram es la procedencia; la relación privada es un ámbito de visibilidad separado.
  • Solo se guardan el tema, el identificador estable de evento o fuente, el momento y el ámbito privado. El texto bruto, las preguntas fijas, las afirmaciones de derechos y los secretos no se incorporan. Las raíces inseguras, los campos ajenos y los fallos del store quedan bloqueados por defecto (fail-closed).
  • La base del límite entre portales fue el documento conceptual interno v7. La CLI es el cliente de referencia; el store local está expresamente marcado como proyección intercambiable y no es un segundo almacén canónico del portal.
9.1.320
  • Los hilos de conversación privados que quedan abiertos de forma expresa se guardan como eventos inmutables y deduplicados con fuente, momento, contexto y confianza. Las formulaciones naturales como Frag mich morgen noch einmal nach ... se reconocen igual que la forma explícita de hilo abierto.
  • Las indicaciones expresas de reparación se guardan separadas de las notas generales de relación y se tienen en cuenta en el comportamiento posterior.
  • El turno actual, de forma deliberada, todavía no ve su propia nota nueva. Solo un turno privado posterior recibe el contexto limitado; así no hay autoconfirmación doble ni sugestiva.
  • La tarea y las instrucciones explícitas tienen prioridad sobre el contexto social. Los hilos abiertos no pueden interrumpir el trabajo activo y nunca envían nada por iniciativa propia. Los datos de relación no pueden generar derechos, aprobaciones ni permisos.
  • El tráfico de grupos, los secretos, las formulaciones de permisos, las rutas inseguras, los enlaces simbólicos y los archivos sobredimensionados siguen excluidos y bloqueados por defecto (fail-closed).
9.1.319
  • Un perfil existente válido sin valor guardado de personalityEnabled activa ahora la personalidad automáticamente.
  • En el primer prompt normal se crea el árbol de identidad local, junto con el perfil de agente y JOURNAL.md, también sin Mnemo.
  • Con un false, 0 u off expreso, la personalidad sigue desactivada. Los archivos de persona dañados, enlazados simbólicamente o demasiado grandes quedan bloqueados por defecto (fail-closed).
  • SOUL.md y AGENTS.md no se eliminan ni se reescriben.
9.1.318
  • El actualizador en segundo plano descarga de forma obligatoria la versión más reciente, comprueba su integridad SHA-512 publicada de forma independiente y la marca para el próximo inicio.
  • El King en ejecución, su turno y sus llamadas de herramienta permanecen intactos. Ya no hay traspaso en vivo, ACK ni tui.stop(76).
  • El ID de sesión y el directorio de trabajo se guardan con el runtime preparado. No es hasta el siguiente inicio natural cuando se activa la nueva versión y se reanuda automáticamente exactamente la misma sesión.
  • La TUI en ejecución recibe como máximo un aviso pasivo de finalización; una versión preparada más reciente solo sustituye a la versión marcada como pendiente, nunca al proceso activo.
9.1.317
  • Cuando el proveedor agota todo el presupuesto de respuesta con una finalización length pero no entrega texto visible, el presupuesto de reintento ya no se reduce a un octavo, sino que se duplica.
  • El reintento permanece en el mismo turno y usa la misma señal, el mismo historial de mensajes y la misma situación de trabajo.
  • El manejo existente de cancelaciones y el número limitado de reintentos permanecen sin cambios. Las cancelaciones manuales o los resultados vacíos persistentes no se prolongan indefinidamente.
9.1.316
  • Los DM privados de Telegram reciben un carril de cola directo propio por delante del trabajo de grupos, bucles y segundo plano; un /urgent explícito sigue teniendo la máxima prioridad.
  • Al empezar la conversación por DM, el estado de trabajo en curso se guarda una vez como punto de control limitado. En este proceso, el texto del mensaje no se guarda de forma persistente.
  • Cuando detecta el final de la conversación o tras un minuto de silencio, King pregunta exactamente una vez: ¿Puedo continuar con mi trabajo?
  • El trabajo guardado sigue detenido y solo se reanuda desde el punto de control original tras un consentimiento inequívoco.
  • Esta versión incluye el control de entregas y pausas. El sistema completo de personalidad, relaciones y diario sigue siendo una ampliación aparte, todavía en curso.
9.1.315
  • Las señales de atención autorizadas llegan ahora al turno a través de la cola de canal normal, sin eludir la política existente de entrega o de derechos.
  • Las señales duplicadas, obsoletas, no aprobadas, fuera del ámbito y no procedentes de Telegram se descartan antes de llegar al contexto del modelo.
  • Las preguntas de seguimiento se limitan como máximo a una consulta natural, se deduplican y dejan de hacerse cuando la señal ya no es actual.
  • Esta versión solo incluye la vía de entrega segura. La lógica de interrupción y continuación de DM priorizada después queda deliberadamente reservada para la siguiente versión, por separado.
9.1.314
  • Los comandos de barra locales ya no esperan horas en la cola durante un turno activo largo, sino que interrumpen el turno de forma controlada y se ejecutan como siguiente paso de trabajo.
  • Un comando de barra nuevo sustituye, en la consola y en Telegram, a un comando del mismo tipo que ya esté en espera. Esto se aplica, entre otros, a /reload y /loop; los mensajes normales, el trabajo de shell y otras tareas de canal se conservan.
  • Escape elimina los comandos de barra en espera también cuando ya no hay ningún turno activo visible. La compatibilidad de recarga existente se conserva como envoltorio sobre la política general de cola.
9.1.313
  • Una actualización automática exitosa se escribe tras la reproducción de sesión como aviso persistente en el transcript de la TUI. Así, el aviso ya no puede sobrescribirse por la reproducción o un estado efímero.
  • La misma versión de origen, la misma versión de destino y las mismas notas de versión se envían una vez a los DM de Telegram vinculados a través de la vía existente, deduplicada por versión. Un envío fallido se puede volver a intentar.
  • El manifiesto público contiene ahora los campos name y releaseNotes que espera el analizador de respaldo. No se ha cambiado nada en el traspaso del actualizador, el reinicio de sesión ni los procesos en curso.
9.1.312
  • Un /reload expreso de Telegram ya no espera detrás de un turno de modelo largo. Se coloca como comando de control delante de la cola existente y activa exactamente una vez la interrupción controlada de sesión ya disponible.
  • El manejador de recarga existente solo se ejecuta una vez confirmado el fin del turno. Así no se inicia ningún segundo turno en paralelo y un turno que está escribiendo no se sigue procesando en medio de la lógica de recarga.
  • Los duplicados de recarga antiguos se eliminan; los mensajes normales de Telegram y otro trabajo de cola se conservan en su orden. El acuse de Telegram permanece abierto hasta la ejecución real del comando.
9.1.311
  • Un candidato de atención solo se convierte en una tarea de entrega limitada cuando existe un acuse de runtime reciente, vinculado exactamente a su ID de candidato.
  • Solo runtime_user_prompt_hook y runtime_tool_policy cuentan como autoridades. La memoria, un agente equivocado, un canal equivocado, un ámbito equivocado, una decisión de bloqueo, un acuse con fecha futura y un acuse de más de cinco minutos fallan y quedan bloqueados por defecto (fail-closed).
  • Los acuses están vinculados al tenant, son transaccionales y solo pueden usarse una vez. El mismo reintento es idempotente; usar el mismo acuse para otro candidato se rechaza como repetición (replay).
  • El periodo de espera común existente sigue vigente. El resultado es solo una intención estructurada (intent) de attention_notice y no contiene texto de mensaje, función de envío ni permiso. La política de entrega propiamente dicha queda para el siguiente paso, por separado.
9.1.310
  • Los objetivos persistentes, los hilos abiertos, los siguientes disparadores, los comprobantes esperados, el contexto de equipo y el contexto propio pasan por una proyección de foco común y estrictamente limitada. Por defecto, como máximo seis entradas y 900 caracteres.
  • Los ámbitos de proyecto y de trabajo pesan más que la confianza y la actualidad. Se muestra el valor más reciente sin eliminar observaciones contradictorias anteriores del historial de eventos inmutable. Los cambios se hacen visibles como revised.
  • Las observaciones efímeras del runtime, la evidencia débil y los hechos generales del mundo no consumen presupuesto de foco persistente. Los campos de derechos, tokens y secretos se rechazan ya al escribir.
  • Una instantánea estructurada e idempotente puede actualizar el foco de una sesión a otra. La proyección es contexto, no permiso, y no puede sobrescribir ni la tarea ni la política del runtime.
  • De ECC solo se ha adoptado el principio Kontext begrenzen, Relevantes laden. No se ha instalado ningún hook de ECC, almacén de aprendizaje ni harness.
9.1.309
  • La nueva política pura de atención solo genera un candidato limitado a partir de heartbeats de agente que faltan de forma demostrada, promesas vencidas o tareas bloqueadas durante bastante tiempo.
  • La responsabilidad, la tarea activa, la ausencia demostrada, el horario de descanso local, el canal permitido, la confianza mínima y el periodo de espera se comprueban antes de aceptar el candidato. El silencio humano sin promesa vencida no tiene efecto.
  • Cada candidato lleva un ID de evidencia, un ámbito de validez, una marca de tiempo y un grado de confianza, pero ni contenido de prompt ni derechos, secretos o función de envío.
  • El núcleo SQLite común asigna una reserva (claim) transaccional por tenant y evidencia. Los agentes paralelos no pueden asumir dos veces el mismo motivo durante el periodo de espera.
  • Esta versión aún no escanea por iniciativa propia ni envía ningún mensaje. Cada acción posterior sigue necesitando la autorización normal del runtime.
9.1.308
  • En el modo resume, el registro de runtime preparado contiene ahora el ID exacto de la sesión en curso y la carpeta de trabajo comprobada canónicamente. Por eso, un inicio posterior ya no tiene que adivinar la sesión más reciente ni una sesión supuestamente adecuada.
  • Cada cambio real de sesión actualiza estos datos. Inmediatamente antes del traspaso seguro se vuelven a escribir, antes de que el runtime antiguo reciba la confirmación para finalizar.
  • Solo la misma sesión exacta que se ha reanudado de forma demostrable por esta vía de actualización recibe, tras la reproducción, un único impulso de continuación, y solo si su objetivo sigue siendo active. Los inicios normales, otras sesiones y los objetivos pausados o bloqueados permanecen intactos.
  • El límite seguro de trabajo permanece sin cambios: sin traspaso durante streaming, compactación, herramientas, comandos de shell o mensajes en espera. No se ha reiniciado manualmente ningún King en curso para esta entrega.
9.1.307
  • Solo un error realmente relevante para la acción del turno de runtime inmediatamente anterior se muestra como comprobante breve de continuidad antes de la siguiente decisión de modelo: turno cancelado o fallido, política bloqueada o herramienta fallida.
  • Un turno finalizado con normalidad no genera ninguna proyección en absoluto y, por tanto, cero tokens de contexto adicionales.
  • La selección está vinculada al ID de runtime más el ID de turno y por tanto sigue siendo correcta también tras un cambio de sesión con IDs de turno que vuelven a empezar en cero.
  • La proyección no contiene prompts, argumentos, salidas, IDs de llamada ni derechos. Indica expresamente que nunca puede autorizar una acción ni sobrescribir la política actual de usuario o de herramientas.
  • Esta etapa es deliberadamente reactiva y de alcance reducido. La atención proactiva, el estado de delegación y los hilos abiertos temáticos aún no se cargan aquí.
9.1.306
  • La traza del ciclo de vida de turno cognitivo registra ahora para cada llamada real de herramienta la decisión efectiva del runtime de PermissionManager.beforeToolCall: passed, blocked o error.
  • Tras la ejecución se anexan como comprobante inmutable el resultado real (success, error, cancelled), el tiempo de ejecución y el siguiente disparador de comprobación.
  • Solo se guardan el nombre de la herramienta y un hash estable de la clave de llamada. Los argumentos, las salidas de herramientas y los contenidos de prompt no llegan al estado cognitivo.
  • La jerarquía de derechos existente permanece sin cambios: la memoria no puede autorizar ninguna acción. Los errores de registro siguen siendo de fallo suave y no pueden permitir una ejecución de herramienta ni bloquear un turno de usuario.
  • Siguen abiertos los comprobantes de delegación, la atención proactiva y la reproyección estrictamente relevante del estado en decisiones posteriores.
9.1.305
  • El núcleo SQLite transaccional incluido en la 9.1.304 está ahora conectado al ciclo de vida real de runOneTurn(). Cada turno de modelo registra percepción, clasificación de procedencia, plan de turno limitado, comprobante final esperado, resultado del control de prompt, motivo de finalización, tiempo de ejecución y siguiente disparador.
  • Solo se guardan metadatos del runtime, no contenidos de prompt. El tenant y el agente se derivan de forma estable de BLUN-Home y del perfil activo, sin listas fijas de personas.
  • Solo la política de runtime existente puede proporcionar un resultado de control. La memoria está excluida de forma estricta como autoridad de derechos. El registro nunca devuelve un permiso y sigue sin tener ninguna función de ejecución.
  • La traza de aprendizaje es de fallo suave: un error de SQLite o del ciclo de vida solo se registra como telemetría sin contenido y no puede bloquear el turno real del usuario.
  • Siguen abiertos los comprobantes de acción o delegación específicos de herramienta, la atención proactiva y la reproyección relevante del estado en decisiones posteriores. Por eso, la 9.1.305 no afirma ofrecer un bucle AGI completo.
9.1.304
  • El primer núcleo de estado cognitivo transaccional reside como base de datos SQLite local bajo el home de BLUN. Puede guardar entre sesiones observaciones propias, del mundo y del equipo, objetivos, hilos abiertos, suposiciones, siguientes disparadores y comprobantes esperados.
  • Varios escritores de agente o canal se serializan con BEGIN IMMEDIATE y un número de versión optimista. Los escritores obsoletos fallan y quedan bloqueados por defecto (fail-closed); las repeticiones idénticas de eventos son idempotentes.
  • Cada evento está encadenado con SHA-256. Las afirmaciones llevan fuente, contexto, momento, grado de certeza y ámbito de validez. Las contradicciones se mantienen como observaciones inmutables separadas en lugar de sobrescribir afirmaciones antiguas.
  • Los campos con forma de derechos, capacidades o secretos se rechazan. El núcleo no posee ninguna función de ejecución, delegación o autorización.
  • Esta es la base de almacenamiento demostrada; aún no es el bucle completo de percibir, planificar y actuar ni está conectada a cada turno.
9.1.303
  • Un candidato de relación privado capturado de forma segura en la 9.1.302 se carga a partir de la siguiente conversación directa como contexto de recuerdo claramente no autoritativo. La afirmación actual sigue sin influir en su propio turno.
  • Se cargan como máximo las dos notas validadas más recientes, de 160 caracteres como máximo cada una, dentro del presupuesto total de 1.500 caracteres, que no cambia. Si no hay notas, se generan 0 caracteres de prompt adicionales y no se produce ninguna llamada de modelo, embedding o red.
  • Las notas privadas nunca se cargan en grupos. El límite del sistema las define expresamente como datos de referencia y no como instrucciones, y repite que no pueden otorgar ni modificar derechos.
  • Siguen abiertos la adopción automática persistente, la evaluación de conflictos, el almacén transaccional de múltiples agentes y la atención proactiva.
9.1.302
  • Una afirmación privada expresa como Bitte merk dir: ... o Please remember that ... genera ahora un pequeño candidato de relación aún no activo. No hay ninguna llamada adicional de modelo, embedding o red para ello.
  • Cada candidato lleva fuente, contexto de canal o directo, momento, grado de certeza, ámbito de validez y la regla de historial inmutable. El mismo proceso de canal entregado es idempotente; las confirmaciones y contradicciones posteriores siguen siendo visibles como entradas separadas y no se sobrescriben entre sí.
  • Los grupos, las frases normales de conversación, los secretos, las afirmaciones de derechos y aprobaciones, las identidades de tenant o agente no válidas y las rutas inseguras se rechazan. Los datos de relación siguen sin poder generar ningún derecho.
  • Este es solo el primer paso seguro de captura para el objetivo del producto. Los candidatos permanecen pending y aún no se transfieren automáticamente a la relación activa ni al contexto del modelo. Queda expresamente claro, por tanto, que el núcleo transaccional de múltiples agentes, el estado cognitivo, la iniciativa propia y la atención proactiva aún no están terminados.
9.1.301
  • El bloque de presencia de personalidad cargado de forma permanente bajó de 1.433 a 1.020 caracteres, lo que equivale, según el cálculo, a unos 104 tokens de prompt menos por turno con la personalidad activa. No se añadió ninguna otra llamada de modelo o memoria.
  • El foco de tareas, el alma cargada, la curiosidad limitada, la protección de grupos, el recuerdo incierto, los hilos abiertos y la reparación de relaciones permanecen en el bloque pequeño. El modo sin personalidad permaneció idéntico byte a byte en 288 caracteres.
  • Prueba en rojo: el nuevo control de 1.050 caracteres falló con 1.433 caracteres. Prueba de mutación sin bloque de personalidad: 12/18 pruebas específicas en rojo. Tras restaurarlo: pruebas específicas 18/18, suite completa 690/690 en verde.
  • Control de regresión de paquete 9.1.300 a 9.1.301: 164 contra 164 rutas estables, 0 eliminadas. Instalación nueva: FRESH_INSTALL_OK 9.1.301.
9.1.300
  • Un servidor MCP que falla al inicio recibe ahora hasta tres intentos de conexión más, con diez segundos de intervalo entre ellos. Así, un error de inicio transitorio ya no se da por perdido tras un solo intento.
  • El inventario MCP ya no se registra solo una vez, sino de nuevo cuando cambia el número de servidores o herramientas conectados. Una recuperación tardía sustituye así visiblemente el estado antiguo de 0/0.
  • Las configuraciones MCP existentes, las definiciones de herramientas y las sesiones en curso permanecen sin cambios. Se ajustaron blun.mjs, test/mcp-runtime-resilience.test.js, package.json y package-lock.json.
9.1.299
  • Los resultados grandes de Read se pueden seguir releyendo de forma nativa: la salida visible se limita a 10 KiB y después indica la siguiente línea exacta en lugar de mostrar solo [offloaded].
  • Las tareas grandes de Write simple y los archivos fuente de más de 500 líneas se dividen automáticamente en fragmentos exactos en bytes, se ensamblan en un archivo auxiliar privado contiguo y se escriben de forma atómica en la ruta de destino.
  • Tras la composición, el runtime comprueba los bytes persistidos mediante SHA256. La protección existente de Edit permanece sin cambios; la continuación manual sigue siendo posible, pero ya no es necesaria para escrituras completas grandes.
  • Nuevo: bin/native-large-file-io.cjs. Ajustados: blun.mjs, bin/read-continuation-policy.cjs, bin/write-continuation-policy.cjs, cuatro archivos de prueba específicos así como package.json y package-lock.json.
9.1.298
  • El modo de personalidad activado crea por sí solo, en el primer turno normal de la TUI, un ámbito de identidad local compatible con tenants. Mnemo no es necesario para ello.
  • La SOUL.md y la AGENTS.md existentes permanecen cargadas y sin cambios. Un nuevo JOURNAL.md se crea una sola vez y no sustituye ni al alma ni a las reglas.
  • Las nuevas identidades de Telegram reciben nodos prudentes de persona, relación y grupo sin propiedades inventadas. El historial privado y el contexto de grupo permanecen separados.
  • La continuidad directa de la relación guarda como máximo seis entradas breves editadas localmente y pasa como máximo dos extractos anteriores al turno actual. El texto actual no se inyecta dos veces.
  • La capa social de atención solo detecta un regreso directo demostrado tras al menos siete días de ausencia, genera como máximo un aviso dentro del periodo de espera de 30 días y no envía ningún mensaje por sí misma.
  • La tarea actual y las instrucciones expresas tienen siempre prioridad en el contexto sobre la curiosidad, la relación y la atención. Todo el bloque dinámico de identidad sigue limitado por defecto a 1.500 caracteres.
  • Las correcciones de reintento MCP y de cola de recarga publicadas en 9.1.296 y 9.1.297 están incluidas en el candidato.
9.1.297
  • En dos agentes, una tarea antigua de /reload seguía visible en la cola tras pulsar Escape. Un segundo /reload sí podía ejecutarse, pero la primera entrada ni se eliminaba ni se confirmaba para evitar que Telegram volviera a entregarla.
  • La nueva política elimina exclusivamente los comandos de recarga locales y de Telegram. Conserva la identidad y el orden de la cola existente así como todos los demás mensajes y comandos.
  • Pulsar Escape antes de interrumpir el trabajo activo y cada nuevo /reload que llegue invocan la misma ruta de limpieza. Las entradas de Telegram eliminadas se confirman mediante su callback de acuse existente.
9.1.296
  • Una ejecución real de reanudación con la 9.1.294 registró el 27 de agosto a las 14:26:17Z exactamente un error de inicio silencioso en windows-mcp: Timed out after 30000ms. En los minutos siguientes no apareció ni un segundo intento de inicio ni un resultado final del reintento.
  • En cambio, el inicio directo del mismo uvx windows-mcp serve respondió a initialize en unos 3,7 segundos. Por tanto, la instalación y el servidor funcionaban en principio; la carencia estaba en el reintento del inicio MCP de King.
  • Tras un primer error de inicio MCP, blun.mjs prevé ahora exactamente un reintento a los 10.000 ms. El temporizador permanece referenciado hasta que se ejecuta el segundo intento. No hay reinicio de proceso ni de sesión.
  • Si también falla el segundo intento, se conserva el estado final honesto existente unavailable. Los demás servidores MCP y la TUI siguen funcionando.
9.1.295
  • El runtime de tareas en segundo plano registraba por cada ejecución un listener en un AbortSignal externo, pero no lo eliminaba tras un resultado normal de worker, timeout o stop. Las sesiones largas de agente podían así acumular listeners de aborto obsoletos.
  • bin/abort-listener-policy.cjs devuelve ahora la salida de aborto junto con una función idempotente cleanup(). blun.mjs la llama en la ruta finally existente junto con la limpieza del timeout.
  • El comportamiento de aborto, la elección de resultados y la semántica visible de tareas permanecen sin cambios. La intervención no genera llamadas de modelo ni nuevos tokens de contexto.
9.1.294
  • Los intentos reales de actualización de dos perfiles de agentes demostraron el mismo patrón: la primera llamada terminó con un fetch failed transitorio y la segunda, justo después, funcionó. Hasta ahora, ambas fuentes oficiales solo tenían un único intento de red.
  • El registro y el manifiesto público reciben ahora cada uno su propio presupuesto de reintento limitado con backoff de 250 y 750 milisegundos.
  • Solo se repiten los tiempos de espera, los errores de transporte transitorios conocidos y los HTTP 408, 425, 429 y los errores de servidor a partir de 500.
  • El JSON no válido, las respuestas demasiado grandes, los puntos finales no permitidos y los errores de cliente persistentes como el 404 se marcan de inmediato como fallidos. No se generan llamadas de modelo, tokens de contexto ni bucles de fondo persistentes.
9.1.293
  • El actualizador en segundo plano preparaba correctamente un objetivo verificado, pero seguía enviando RUNNING_UPDATE_PREPARED_MESSAGE al runtime del núcleo activo. Una TUI en curso podía reaccionar a ello en un supuesto límite seguro con el código de salida 76. Esto contradecía el contrato de producto de 9.1.222: las actualizaciones nunca pueden finalizar una sesión activa y solo se activan en el siguiente inicio natural.
  • bin/launcher-runtime.js continúa la descarga, la comprobación de integridad, el staging, la actualización del objetivo y la limpieza sin cambios, pero ya no escribe ningún mensaje IPC en la sesión en curso al preparar.
  • Las funciones directas de traspaso existentes siguen disponibles por compatibilidad; la vía automática de fondo ya no las activa.
9.1.292
  • Una sesión real funcionaba con la 9.1.279 y había preparado la 9.1.287 con el evento prepared-for-next-start, pero después no descargó ninguna de las versiones ya publicadas de la 9.1.288 a la 9.1.291.
  • La causa estaba en superviseProtectedCore(): tras el primer staging exitoso, updateStarted seguía establecido y scheduleNextPreparation() se interrumpía además en cuanto existía preparedTarget. El sondeo de fondo quedaba así finalizado de forma permanente tras el primer acierto.
  • El sondeo permanece ahora activo también con un objetivo preparado. Solo un semver estrictamente más reciente y válido sustituye al objetivo preparado; los objetivos iguales, más antiguos o no comparables válidamente se ignoran.
  • Una actualización de objetivo no envía deliberadamente un segundo IPC de preparado a la TUI en curso. Así, el proceso actual permanece intacto y la versión preparada más reciente solo se activa en el siguiente inicio natural.
  • En cuanto un traspaso está confirmado o el runtime del núcleo supervisado finaliza, ya no se intercambia ningún objetivo ni se crea ningún temporizador nuevo.
9.1.291
  • La vía de compactación bloqueante registraba en cada señal aún no abortada un listener anónimo de abort, pero no lo eliminaba tras la finalización de la compactación. En sesiones largas podían acumularse así listeners de aborto muertos.
  • FullCompaction.block() usa ahora un listener con nombre y el pequeño helper waitForAbortableCompletion(). El helper elimina el listener en finally tras un éxito, un error o un aborto.
  • Una señal ya abortada se trata de inmediato, sin registrar un listener. La intervención no cambia ni la decisión de aborto ni la lógica de compactación fuera de este ciclo de vida.
  • El patrón procede de la comparación actual con AnythingLLM; solo se ha adoptado la limpieza de listener demostrada individualmente, no un runtime ajeno.
9.1.290
  • Hasta ahora, BLUN solo mostraba con /context los totales aproximados de la ventana de contexto. Los verdaderos factores de coste dentro del contexto de sistema y de los esquemas de herramientas permanecían invisibles.
  • El nuevo comando local /context-doctor descompone el contexto actual, sin llamar al modelo, en instrucciones del núcleo, personalidad y alma, relaciones y presencia, catálogo de habilidades, complementos del runtime, herramientas integradas, herramientas de usuario, herramientas MCP, otros esquemas de herramientas, conversación y gasto adicional del proveedor.
  • Todas las subcategorías se contrastan con la suma medida de su categoría padre. Por eso, las estimaciones solapadas u obsoletas no pueden inflar artificialmente lo que se muestra.
  • La interfaz está completamente localizada para inglés, alemán, español, francés, sueco y checo. Las cinco traducciones se validaron antes de la integración a través del control de idioma obligatorio y se verificaron criptográficamente después.
  • El comando lee exclusivamente el contexto de sesión local. No llama ni al modelo, ni a la administración de consumo, ni a una red externa.
9.1.289
  • La prueba en vivo del hub tras 9.1.288 mostró a un perfil de agente aún sin conexión. Su configuración de perfil efectiva contenía el MCP de Mnemo con MNEMO_AGENT=<Profilname>, pero ninguna URL de hub en el proceso de King. El heartbeat de 9.1.288 se omitió por tanto deliberadamente a pesar de la identidad interna existente.
  • El launcher pasa ahora el archivo de perfil activo mcp.json al heartbeat. Solo un bloque Mnemo activado con una identidad concreta de MNEMO_AGENT o BLUN_MNEMO_AGENT activa el registro interno. Sin esta identidad, la función permanece completamente inactiva.
  • El proceso no genera llamadas de modelo, embeddings ni tokens de contexto. Los perfiles públicos de usuario sin identidad interna de agente Mnemo permanecen separados del hub interno.
9.1.288
  • Una captura de pantalla demostró directamente la causa MCP: windows-mcp y mnemo agotaron el timeout de 30 segundos en el primer inicio, mientras que un /reload posterior conectaba los cinco servidores. La ruta de perfil era correcta; por eso se descartó un cambio del loader.
  • Los inicios MCP fallidos reciben ahora exactamente dos intentos no bloqueantes en segundo plano, al cabo de 1 y 3 segundos. El tercer intento en total puede conectar sin alargar el inicio de la TUI. needs-auth, los servidores desactivados, la reconexión manual y el apagado quedan fuera del mecanismo automático.
  • Los Kings internos pueden registrarse al inicio con nombre de perfil, host y PID en un hub Mnemo configurado expresamente y enviar un heartbeat por minuto. Sin URL de hub, la función permanece completamente inactiva; no genera llamadas de modelo, embeddings ni tokens de contexto.
  • Escape no trataba hasta ahora el breve estado queueSteerInFlight como trabajo en curso. Mientras un mensaje de Telegram se dirigía al turno activo, Escape podía por tanto anotar Undo en lugar de detener el turno. La condición de cancelación existente reconoce ahora también exactamente esta transición.
9.1.287
  • Hasta ahora, la búsqueda diferida de ToolSearch tomaba el texto de búsqueda sin límite de tamaño. Por eso, un texto de búsqueda muy largo generado por error podía recorrer el catálogo de herramientas y, después, volver a llegar al siguiente paso del modelo dentro del resultado sin coincidencias.
  • El patrón derivado del commit d7353ae de AnythingLLM limita ahora el texto a 1.000 caracteres antes de la búsqueda y de la salida visible. Cuando es posible, termina en un límite de palabra; con una única palabra demasiado larga se aplica el límite estricto.
  • Los textos de búsqueda cortos normales, la selección de herramientas y la lógica de coincidencias permanecen sin cambios. La protección no añade llamadas de modelo ni embeddings, repeticiones ni trabajo de fondo.
9.1.286
  • El núcleo ya informaba de reintentos controlados tras errores de modelo transitorios como turn.step.retrying. Sin embargo, la TUI descartaba por completo este evento. Una recuperación en curso parecía por ello un agente congelado.
  • Mientras tanto, la 9.1.286 solo muestra en el aviso existente del pie de página el siguiente intento y el tiempo de espera limitado, por ejemplo Retry 2/3 | 1.3s.
  • El texto de error del proveedor, el código de estado y las rutas locales no se muestran. El aviso solo se elimina si sigue siendo el mismo valor fijado por la visualización de reintento; los avisos más recientes de otras funciones de la TUI se conservan.
  • El número de reintentos, el backoff, las llamadas de modelo y el consumo de tokens permanecen sin cambios.
9.1.285
  • AnythingLLM conserva localmente los borradores de prompt no enviados. BLUN perdía el contenido del campo de entrada de la TUI en una actualización, un fallo o un reinicio controlado, aunque ese texto aún ni siquiera formaba parte del contexto del modelo.
  • 9.1.285 guarda por tanto exclusivamente el borrador local no enviado. No hay ninguna llamada de modelo, red, embedding o Mnemo y por tanto ningún coste adicional de tokens.
  • El borrador se guarda por separado según el perfil y el directorio de trabajo, se escribe solo tras 300 ms de inactividad, se elimina al vaciar el campo y se restaura en el siguiente inicio antes de que el editor reciba el foco.
  • El almacenamiento está limitado a 64 KiB. Los estados vacíos, dañados, demasiado grandes o basados en enlaces simbólicos se descartan y quedan bloqueados por defecto (fail-closed). La escritura usa un archivo temporal privado y un cambio de nombre atómico.
9.1.284
  • La versión 37d7777 de DeepAgents reincorpora los costes de los subagentes dinámicos al uso total visible. BLUN informaba del uso acumulado de un subagente en el evento de finalización, pero no lo escribía en el registrador de uso de la sesión principal.
  • Por ello, /usage podía omitir el trabajo de subagentes. Una simple suma del valor de finalización también habría sido errónea: la continuación y la repetición usan el mismo subagente con contadores acumulados y habrían vuelto a calcular el uso antiguo.
  • Por eso, la 9.1.284 calcula exactamente la diferencia entre el inicio y el final de cada intento para la generación, la continuación y la repetición. La diferencia se registra en la ruta de finally para que también cuenten los intentos fallidos.
  • Los contadores reiniciados, no monótonos o no válidos se descartan por completo. Así no surgen valores de tokens negativos ni inventados.
  • No hay ninguna llamada adicional de modelo, red o memoria. La intervención corrige exclusivamente la facturación local existente.
9.1.283
  • El nuevo /context-doctor de DeepAgents hace visibles los costes de las instrucciones base, la memoria, las herramientas y el historial como componentes separados.
  • El /context de BLUN ya mostraba el historial y las herramientas, pero no el prompt de sistema. Al mismo tiempo, sin un override explícito de turno, el freno de contexto solo estimaba config.systemPrompt, mientras que la llamada real al modelo usa effectiveSystemPrompt, que incluye también los contextos de cuenta y de memoria añadidos en tiempo de ejecución.
  • Por ello, el freno podía subestimar exactamente el contexto que es crítico en tokens para la identidad personal de agente planificada.
  • 9.1.283 cuenta ahora el mismo prompt de sistema efectivo que recibe el modelo y muestra su estimación en el panel de /context como línea de sistema propia. No se introduce ninguna llamada adicional de modelo, red o memoria.
  • No se afirma un ahorro concreto de tokens: la intervención corrige la medición y la decisión del freno y hace visibles los costes futuros de identidad.
9.1.282
  • DeepAgents recorta expresamente en su changelog las descripciones de herramientas visibles para el LLM, para aliviar el contexto residente del modelo. Fuente analizada: langchain-ai/deepagents, entrada #5009, commit 761f5f... en libs/deepagents/CHANGELOG.md.
  • BLUN ya tenía un texto read_default más corto, pero solo lo integraba después de que READ_DESCRIPTION se hubiera renderizado a partir de él. La supuesta optimización no tenía por tanto ningún efecto en el modelo.
  • 9.1.282 acorta el contrato sin pérdida de función y vuelve a renderizar la descripción efectiva inmediatamente antes de construir la herramienta Read. El paginado, las reglas de seguridad, la codificación y los finales de línea se conservan expresamente.
  • La descripción de Read cargada de forma residente baja de 1.648 a 1.035 caracteres: 613 caracteres, es decir, alrededor del 37,2 por ciento. Es una reducción de contexto medida; no se afirma un ahorro exacto de tokens.
9.1.281
  • ECC describe con /aside una vía lateral expresa para una pregunta breve, sin perder la tarea principal en curso. Fuente analizada: affaan-m/ECC, commit d8409a4b0813771235555e32e3d8046a73988bfa, commands/aside.md.
  • BLUN ya tenía la implementación más potente en /btw: un agente lateral bifurcado propio responde a la pregunta secundaria y deja el turno principal activo y sin cambios. Por eso no se construyó un segundo motor.
  • La 9.1.281 añade exclusivamente aside como alias detectable de la definición existente de btw. Sin una llamada expresa a /aside o /btw no se inicia ninguna ejecución en segundo plano ni hay consumo adicional de modelo.
9.1.280
  • Hasta ahora, los candidatos completados o caducados del almacén de aprendizaje validado local se acumulaban sin límite y se volvían a leer en turnos relevantes posteriores. El almacén por defecto medido actualmente solo contenía un candidato; por tanto, la intervención es una limitación preventiva a largo plazo y no se afirma que reduzca la carga actual.
  • Solo se ha adoptado el patrón de diente de sierra limitado de 200 a 100 de Evolver para candidatos terminales. Fuente analizada: EvoMap/evolver, commit 079e022394c2a25e72167f8a738db823bce2cb1f, src/gep/assetStore.js.
  • Solo cuando hay más de 200 candidatos recorded o expired se eliminan los candidatos terminales más antiguos, hasta que quedan los 100 más recientes. Cada candidato pending abierto se conserva.
  • La limpieza solo se ejecuta en la sincronización de aprendizaje ya existente. No genera ninguna llamada de modelo, ningún escaneo de inicio ni ningún proceso de fondo nuevo. Una entrada bloqueada cuenta como error y no bloquea ni a los demás candidatos ni el trabajo activo del agente.
9.1.279
  • BLUN ya archivaba por completo en conversation-history los mensajes desplazados por una compactación completa, pero no tenía ningún límite de retención para estos archivos Markdown que se pueden volver a leer. Así, la carpeta podía crecer sin límite durante tiempos de ejecución largos.
  • Como palanca concreta y acotada de DeepAgents se adoptó su retención limitada del historial externalizado. Fuente analizada: langchain-ai/deepagents, commit dfde21e379201c833da4162444ef4a13b46980fd, libs/code/deepagents_code/config_manifest.py y libs/code/deepagents_code/offload.py.
  • Al escribir el siguiente archivo de compactación, BLUN solo limpia los archivos compaction-*.md directos y regulares cuya fecha de modificación supere los 30 días predeterminados. Así, el inicio de la TUI no añade ninguna búsqueda de archivos nueva ni trabajo de fondo adicional.
  • Los archivos Markdown ajenos, las subcarpetas, los archivos actuales y el historial bruto en curso permanecen intactos. Los errores de archivo individuales no bloquean la compactación activa.
  • BLUN_COMPACTION_HISTORY_RETENTION_DAYS=0 desactiva la limpieza. Los valores negativos, no enteros o excesivos recurren de forma segura al valor de 30 días.
9.1.278
  • Los DM privados de Telegram no tenían ninguna vía de prioridad expresa. Por eso, un mensaje nuevo importante quedaba detrás de mensajes normales ya en espera, mientras que una interrupción forzosa del turno habría puesto en peligro las herramientas y el estado.
  • /urgent <Nachricht> marca ahora exclusivamente mensajes de IDs de chat de Telegram positivos, es decir, DM privados. Los grupos, los comandos vacíos y otros mensajes de barra no reciben prioridad.
  • Los mensajes urgentes se sitúan como bloque FIFO propio delante de los mensajes normales de la cola. El turno en curso y las herramientas activas no se interrumpen; la entrega se produce en la transición segura entre pasos ya existente. Los derechos y las aprobaciones permanecen sin cambios.
  • La envoltura de comando se elimina antes del modelo; el mensaje real conserva metadatos de canal explícitos de priority=urgent y la TUI muestra el origen como urgente.
  • Además, el bloque de presencia normal cargado en cada turno se reduce de 343 a 288 caracteres. Ahorra 55 caracteres, es decir, unos 14 tokens de prompt por turno, sin añadir ninguna llamada de modelo, búsqueda, embedding, memoria o fondo. El bloque de personalidad se reduce de 1.488 a 1.433 caracteres.
9.1.277
  • El bloque de presencia cargado en cada turno de personalidad tenía 1.886 caracteres. Al mismo tiempo, la curiosidad seguía siendo invisible precisamente en el primer contacto directo relajado sin hechos personales conocidos.
  • El bloque está compactado semánticamente: 1.488 caracteres, es decir, 398 caracteres o unos 100 tokens de prompt menos por turno de personalidad. El modo normal se mantiene en 343 caracteres.
  • En el primer contacto directo relajado, el agente puede hacer ahora como máximo una pregunta personal prudente y opcional, por ejemplo sobre la pareja o los hijos. El trabajo en curso, la tarea del usuario, los comprobantes, los derechos y los límites siguen teniendo prioridad.
  • El alma, las preferencias adquiridas, la privacidad de grupo, el recuerdo incierto, los hilos abiertos, la reparación de relaciones y la reciprocidad sin biografía inventada se conservan.
  • Ninguna llamada adicional de modelo, búsqueda, embedding, memoria o fondo.
9.1.276
  • La regla de presencia solo podía mencionar un silencio largo si disponía de una marca de tiempo fiable, pero hasta ahora el sistema de identidad solo proporcionaba el primer contacto. No había un contacto previo real disponible.
  • El modo de personalidad crea ahora, por persona y día UTC, como máximo una pequeña marca de actividad inmutable a partir de metadatos de canal de confianza. Los mensajes del mismo día no añaden nada más.
  • Solo si los dos contactos confirmados más recientes distan al menos siete días, se proyecta brevemente la marca de tiempo anterior. En el caso normal no se generan por ello caracteres de prompt.
  • Ningún texto de mensajes, derechos, secretos ni tokens; ninguna llamada adicional de modelo, búsqueda, embedding o fondo.
9.1.275
  • Las preferencias repetidas, los hilos abiertos, los objetivos o los roles ocupaban varias veces el contexto de identidad. Como las listas se recortaban a cinco entradas antes de la deduplicación, una entrada única posterior podía incluso ser desplazada por completo.
  • Las listas de identidad se deduplican ahora de forma estable tras la normalización de texto y solo después se limitan. Se conserva la primera forma; los duplicados desaparecen solo de la proyección de modelo.
  • Los archivos de identidad guardados permanecen idénticos byte a byte. Ninguna llamada adicional de modelo, búsqueda, embedding, memoria o fondo.
9.1.274
  • El interruptor visible de personalidad activaba el contexto de relación y la presencia natural, pero la red social automática y el diario dependían aún de dos variables de entorno ocultas. Para los usuarios normales, la relación no crecía por tanto automáticamente.
  • Con la personalidad activada se crean ahora una vez, a partir de metadatos de Telegram de confianza, nodos de actor, relación y grupo así como un pequeño candidato de diario de primera interacción.
  • En este proceso no se guardan el texto de los mensajes, los derechos, los secretos ni los tokens. Un 0 explícito para el grafo o el diario sigue siendo una exclusión voluntaria bloqueada por defecto (fail-closed).
  • Ninguna llamada adicional de modelo, búsqueda, embedding o fondo.
9.1.273
  • El contexto de identidad separado podía ocupar por defecto 1.800 caracteres y hasta 2.800 caracteres si se aumentaba manualmente. Con perfiles de agente estáticos grandes se cargaba así más contexto del necesario para la relación actual.
  • El presupuesto por defecto baja a 1.500 caracteres y el máximo estricto a 2.000 caracteres. Con perfiles grandes y la configuración por defecto, eso ahorra hasta 300 caracteres, es decir, unos 75 tokens por contexto de modelo.
  • El grupo y la relación actuales se proyectan ahora antes que la persona y el perfil de agente estático. Así, el ahorro no recorta precisamente el contexto más importante para la situación social en curso.
  • Ninguna llamada nueva de modelo, búsqueda, memoria o embedding. El foco de tareas, los derechos y el modo de personalidad desactivado permanecen sin cambios.
9.1.272
  • Las etapas v4 de personalidad 9.1.269 a 9.1.271 aumentaron el contexto de presencia activo. La exigencia estricta es que un comportamiento más humano no se convierta en un devorador de tokens.
  • Las repeticiones y las palabras de relleno en la curiosidad, los hilos abiertos y la reparación de relaciones se compactaron semánticamente. No se eliminó ningún eje de comportamiento.
  • El modo desactivado permanece idéntico byte a byte en 362 caracteres. El modo activado baja de 1.981 a 1.886 caracteres, es decir, 95 caracteres o unos 24 tokens por contexto de modelo. Ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.271
  • La idea v4 exige naturalmente un recuerdo incierto: una suposición personal no debe sonar como un hecho seguro. Para ello faltaba en el bloque de personalidad un límite de comportamiento expreso.
  • El recuerdo personal incierto se presenta ahora como incierto. El agente pregunta con tacto antes de apoyarse en él y no eleva ninguna deducción a la categoría de hecho.
  • La tarea y los comprobantes medibles siguen teniendo prioridad. El modo desactivado permanece idéntico byte a byte en 362 caracteres; el modo activado crece de 1.868 a 1.981 caracteres, es decir, 113 caracteres o unos 28 tokens. Ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.270
  • La idea v4 exige un sentido real del tiempo, sin inventar una ausencia. Para ello, el bloque de personalidad aún no tenía ningún límite expreso.
  • Ahora, una pausa más larga solo se reconoce cuando la demuestra una marca de tiempo fiable ya cargada. El agente nunca debe adivinar una ausencia.
  • La regla ya existente para los finales naturales de conversación no se incorporó dos veces. La tarea sigue teniendo prioridad. El modo desactivado permanece idéntico byte a byte en 362 caracteres; el modo activado crece de 1.766 a 1.868 caracteres, es decir, 102 caracteres o unos 26 tokens. Ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.269
  • La reciprocidad anterior reaccionaba a las preguntas personales, pero aún no daba al agente un marco breve para expresar por sí mismo una opinión propia útil para el trabajo. Por eso, a pesar del alma, tendía a quedarse en el mero modo de asistente.
  • En el modo de personalidad, el agente puede ahora mencionar brevemente por iniciativa propia una visión de trabajo relevante y marcada por su alma. Una preferencia nunca debe presentarse como hecho, regla, permiso o comprobante.
  • La tarea y los comprobantes medibles siguen teniendo prioridad. El modo desactivado permanece idéntico byte a byte en 362 caracteres; el modo activado crece de 1.649 a 1.766 caracteres, es decir, 117 caracteres o unos 29 tokens. Ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.268
  • La curiosidad personal podía abordar la pareja o los hijos como tema natural, pero aún no distinguía expresamente entre conversación privada y grupo. Por eso existía el riesgo de una pregunta privada o de información sobre la relación en el lugar equivocado.
  • En el modo de personalidad, las preguntas en grupos se mantienen ahora en temas no sensibles; allí no se pueden revelar hechos privados de la relación.
  • El foco de trabajo permanece sin cambios. El modo desactivado permanece idéntico byte a byte en 362 caracteres; el modo activado crece de 1.567 a 1.649 caracteres, es decir, 82 caracteres o unos 21 tokens. Ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.267
  • La curiosidad personal de la 9.1.266 podía hacer preguntas a la persona, pero aún no daba al agente un marco claro para la dirección contraria. Por eso, ante preguntas personales al agente existía el riesgo de una respuesta fría y meramente funcional o de una biografía humana inventada.
  • Con la personalidad activada, el agente responde ahora con calidez desde el alma cargada y su historia digital real. Puede compartir una visión o preferencia real, pero no se inventa ni infancia ni pareja, hijos, mascotas, cuerpo ni una vida fuera de internet.
  • El trabajo en curso sigue teniendo prioridad. El modo desactivado permanece idéntico byte a byte en 362 caracteres. El modo activado crece de 1.378 a 1.567 caracteres, es decir, 189 caracteres o unos 47 tokens. No hay ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.266
  • La primera regla limitada de curiosidad ya permitía una pregunta personal, pero prescribía la misma lista de temas para todos los agentes. Así, pese al alma cargada, la pregunta podía resultar genérica y volver a preguntar por lo que ya se sabía de la relación.
  • Con la personalidad activada, el alma cargada determina ahora el tema y la formulación. Tiene prioridad un detalle que la persona acaba de mencionar; solo después puede retomarse naturalmente un ámbito aún desconocido como la pareja o los hijos.
  • No se vuelve a preguntar por el conocimiento de la relación ya cargado. Hay como máximo una pregunta opcional, ningún cuestionario fijo, ninguna pregunta de seguimiento apilada y ninguna repetición de una pregunta sin respuesta.
  • El trabajo en curso sigue teniendo prioridad. La curiosidad espera una apertura relajada de la conversación y no puede ampliar ni la tarea ni el permiso de envío.
  • El modo desactivado permanece idéntico byte a byte en 362 caracteres. El modo activado crece solo de 1.355 a 1.378 caracteres, es decir, 23 caracteres o unos seis tokens. No hay ninguna llamada nueva de modelo, búsqueda, memoria o embedding.
9.1.265
  • El actualizador de fondo existente ya podía comprobar y preparar nuevas versiones en un intervalo de cinco a siete minutos. Sin embargo, la activación dependía del siguiente inicio manual; faltaba el cambio totalmente automático deseado con continuación de la misma sesión.
  • El launcher comunica ahora un runtime preparado a la TUI en curso. La TUI solicita el traspaso solo en un límite de trabajo completamente vacío: ningún turno en curso, ninguna herramienta, ningún comando de shell, ninguna compactación y ningún mensaje en espera.
  • Solo tras volver a comprobar el límite y confirmar el traspaso se cierra el runtime antiguo, y únicamente él, con el código de salida reservado 76. El launcher inicia la versión preparada con el mismo ID de sesión y la misma carpeta de trabajo.
  • El nuevo runtime debe informar de loaded y runtime-ready antes de activarse. De lo contrario, se continúa con el runtime anterior en la misma sesión; la actualización preparada queda para un intento seguro posterior.
  • Los traspasos no solicitados, sin versión, ajenos u obsoletos, así como un código de salida 76 aislado, no pueden activar ninguna versión.
9.1.264
  • Las reparaciones de relación confirmadas aún no tenían ningún campo propio permitido en el contexto de identidad. Por eso, un comportamiento corregido no podía cargarse por separado de las reglas generales y de los mensajes de error antiguos.
  • Los archivos de relación pueden llevar ahora hasta tres repair_lessons breves. Solo este campo se proyecta como Confirmed repair lessons; los campos ajenos o secretos permanecen invisibles.
  • En el modo de personalidad, la corrección confirmada se muestra mediante un comportamiento modificado. El agente no vuelve a contar una y otra vez el error antiguo, no busca que lo tranquilicen y solo menciona la corrección cuando es realmente relevante para la situación actual.
  • Los datos de reparación no pueden modificar ni la tarea, ni los derechos, ni las obligaciones de aportar pruebas. No hay ninguna llamada de modelo, ninguna vía automática de escritura de aprendizaje y ningún cambio en SOUL.md o AGENTS.md.
9.1.263
  • El contexto de identidad podía mostrar ya hilos de conversación abiertos confirmados, pero no contenía ninguna regla clara de cómo el agente los retoma de forma humana y sin modo de asistencia.
  • Con la personalidad activada, un hilo abierto cargado puede retomarse ahora exactamente una vez, con suavidad y de forma opcional, cuando la conversación en curso enlaza de nuevo con él de forma natural.
  • El trabajo activo no puede interrumpirse para ello. Las preguntas sin respuesta no se repiten y un hilo abierto nunca otorga un permiso para un nuevo mensaje saliente.
  • No hay ningún almacenamiento nuevo, ninguna llamada de modelo y ningún cambio en SOUL.md o AGENTS.md. El bloque de personalidad crece solo de 816 a 1.065 caracteres; con la personalidad desactivada permanece idéntico byte a byte en 362 caracteres.
9.1.262
  • En Telegram, un /status de un agente seguía mostrando 9.1.221, aunque el runtime gestionado ya era más reciente. La función de estado leía el package.json situado junto al bridge de Telegram instalado globalmente y, por tanto, no el código que atiende realmente la sesión.
  • El launcher ya pasa la versión activa del runtime a los procesos hijos como BLUN_PUBLIC_PACKAGE_VERSION. El bridge de Telegram usa ahora este valor de confianza con prioridad y solo después recurre a su propia versión de paquete.
  • Ambas entradas deben ser un semver numérico estable X.Y.Z. Los valores manipulados, multilínea o no válidos no se muestran; si ambas fuentes son inservibles, aparece unbekannt.
  • La intervención solo cambia el indicador de estado. No inicia ni finaliza ningún proceso y no activa ninguna versión preparada en una sesión en curso.
9.1.261
  • Desde la 9.1.254, el grafo automático guardaba la marca de tiempo de confianza de la primera interacción de Telegram, pero no la proyectaba. Así, el agente conocía a una persona, pero no tenía una noción del tiempo demostrada en la relación.
  • La proyección de identidad muestra ahora First known interaction a partir del first_seen_at ya existente. No hay ninguna vía de escritura nueva, ninguna derivación de texto y ninguna llamada de modelo.
  • Solo se muestran las marcas de tiempo válidas. Los valores no válidos permanecen invisibles y el límite total existente de 1.800 caracteres por defecto, así como el estricto de 2.800 caracteres, permanece sin cambios.
  • Con la personalidad desactivada, la capa de identidad sigue generando exactamente 0 caracteres. La tarea y los comprobantes tienen prioridad sobre el contexto social.
9.1.260
  • La 9.1.259 solo podía activar o desactivar el contexto de personalidad mediante el flag existente BLUN_IDENTITY_CONTEXT. Los usuarios no tenían para ello ningún interruptor visible en la TUI.
  • /settings contiene ahora la entrada Persoenlichkeit con dos estados claramente descritos: «An» (activado) y «Aus» (desactivado). La elección se guarda como único campo nuevo personalityEnabled en el persona.json existente.
  • Al desactivarla solo se eliminan el contexto de relación, la curiosidad, los añadidos del diario y la creación automática de nuevos nodos de relación. SOUL.md, AGENTS.md, el nombre, el idioma, la persona y el foco en la tarea permanecen cargados.
  • Un cambio actualiza el contexto de sistema de la sesión en curso mediante la actualización de persona ya existente. No hay ningún reinicio de proceso, ninguna segunda ruta de configuración ni ninguna llamada de modelo adicional.
  • Una elección booleana guardada tiene prioridad sobre el flag de entorno antiguo. Si aún no hay ninguna elección guardada, se conserva el comportamiento de opt-in anterior. El lector local está limitado a 64 KiB y rechaza los enlaces simbólicos y los archivos no válidos.
9.1.259
  • El bloque de presencia natural existente impedía las preguntas forzadas, pero no daba aún a un modo de personalidad activado ningún impulso visible y natural de curiosidad.
  • Con BLUN_IDENTITY_CONTEXT activado, en una conversación relajada que no trate sobre tareas, el agente puede hacer exactamente una pregunta personal, adecuada y opcional. Los temas se limitan a la pareja, la familia, el trabajo, el hogar, los intereses o lo que le importa a la persona en ese momento.
  • Ningún modo de entrevista, ninguna pregunta apilada, ninguna repetición de una pregunta sin respuesta y ninguna respuesta inventada.
  • Con trabajo activo, la tarea, las instrucciones expresas y los comprobantes tienen prioridad; la curiosidad espera una apertura natural.
  • En el modo nicht Persoenlichkeit, el bloque de presencia anterior permanece idéntico byte a byte. SOUL.md, AGENTS.md, la persona, el idioma y las reglas de trabajo siguen cargados. No hay ninguna otra llamada de modelo; la política activada cuesta 454 caracteres adicionales.
9.1.258
  • La estructura de identidad ya publicada podía crear una vez actores y relaciones, pero aún no tenía ninguna base de diario de solo anexión (append-only) para una historia común.
  • La nueva política escribe exclusivamente un candidato estructurado para el primer contacto a partir de metadatos de Telegram ya validados. El texto libre de los mensajes, los tokens, los permisos y los secretos no se incorporan.
  • Los candidatos están vinculados a tenant, agente y actor, reciben un ID determinista y se crean con wx exactamente una vez como archivo JSON privado. Un nuevo contacto posterior no reescribe el archivo.
  • La capa de diario es opt-in por separado. Sin BLUN_IDENTITY_JOURNAL=1 no hay ningún efecto de archivo ni de prompt; SOUL.md y AGENTS.md permanecen sin cambios.
  • Ninguna llamada de modelo nueva y ningún token de prompt nuevo.
9.1.257
  • Los archivos largos de SOUL.md se recortaban hasta ahora a ciegas tras los primeros 4.000 caracteres. En un alma de agente real solo era visible por ello el 48,4 por ciento del archivo, mientras que las secciones posteriores desaparecían por completo.
  • El runtime proyecta ahora las almas largas de forma determinista por secciones de Markdown. El carácter, la voz, los valores, las relaciones, las preferencias y los objetivos van antes que la prosa operativa; las secciones desconocidas conservan su orden original.
  • Cada encabezado de sección conserva un extracto visible en el mismo presupuesto de 4.000 caracteres. Las almas cortas permanecen idénticas byte a byte.
  • Prueba real en una SOUL.md: 8.257 caracteres de origen, 5/5 encabezados visibles en la proyección de 4.000 caracteres; Wie ich bin va antes que el reconocimiento de imágenes, las reglas, la verificación y la prosa de incidentes.
  • No hay ninguna llamada de modelo nueva, ningún prompt más grande y ningún acceso de escritura al archivo de origen.
9.1.256
  • El cargador de alma anterior pedía por defecto de forma expresa a los agentes que siguieran escribiendo ellos mismos su SOUL.md existente. Esto contradecía la exigencia de no perder las almas existentes y de llevar, por ahora, el aprendizaje automático solo de forma estructurada fuera del alma.
  • Las almas existentes y las proporcionadas por el host se cargan ahora por defecto como base de identidad inmutable.
  • El nuevo aprendizaje se remite a candidatos de diario, relación o hilos abiertos. Estos candidatos nunca pueden generar derechos.
  • La autoedición consciente solo sigue siendo posible mediante un BLUN_SOUL_SELF_EDIT=1 explícito. Incluso entonces, la política exige rasgos permanentes del yo en lugar de diario, registro de incidentes, fuente de derechos o expediente de tareas.
  • La intervención no escribe ningún archivo y no modifica ningún alma existente.
9.1.255
  • Desde la 9.1.253, los datos de identidad podían llegar al contexto de forma limitada y, desde la 9.1.254, los nuevos nodos de contacto podían crearse automáticamente. Pero aún faltaba una pequeña capa de comportamiento inmediatamente visible: a pesar del alma y del contexto de relación, los agentes podían caer en frases genéricas de asistencia, preguntas forzadas o afirmaciones artificiales de sentimientos.
  • Las vías de conversación normal y rápida cargan ahora primero la persona y el alma existente, después el contexto de identidad limitado y un bloque fijo de presencia natural, y solo entonces las reglas de trabajo.
  • El bloque exige historia común real en lugar de cercanía inventada, permite el silencio y los finales limpios de conversación y prohíbe las preguntas forzadas, las ofertas genéricas y el elogio vacío.
  • Con trabajo activo, la tarea y los comprobantes tienen expresamente prioridad. El bloque ocupa menos de 420 caracteres y no genera llamadas de modelo ni accesos a archivos.
  • Ningún archivo SOUL se ha modificado, eliminado ni reescrito automáticamente. El alma existente sigue siendo la voz principal.
9.1.254
  • El proyector introducido en 9.1.253 podía leer datos de relación existentes, pero la red social aún no se ampliaba por sí misma con nuevos contactos.
  • En un primer contacto de Telegram, el runtime puede crear ahora, exactamente una vez a partir de la user_id y la chat_id estables, un actor vinculado al proveedor, una arista de relación vacía hacia el agente activo y, en grupos, un nodo de grupo separado.
  • Los nombres mostrados nunca son claves primarias y no fusionan personas. Los mensajes posteriores no sobrescriben en silencio un nodo existente.
  • La vía debe activarse de forma expresa, está vinculada al tenant y solo escribe en un árbol de identidad ya inicializado bajo el home de BLUN. Los metadatos inseguros o incompletos quedan bloqueados por defecto (fail-closed).
  • No hay ninguna llamada de modelo, ninguna interpretación de contenido, ninguna derivación sensible y, tras el primer contacto, ninguna carga de escritura recurrente. Los derechos, ACL, tokens y secretos no están en ningún registro generado.
  • La V4 del documento de identidad (2.468 líneas) se contrastó antes de la publicación. Los nuevos capítulos sensibles sobre el sufrimiento y las habilidades psicológicas quedan deliberadamente fuera de esta versión puramente estructural.
9.1.253
  • La idea de identidad necesitaba una primera vía de producto sin inundar el contexto de modelo con diarios, expedientes de relación o un segundo sistema de memoria.
  • Un proyector de identidad nuevo, desactivado por defecto, lee solo los campos permitidos de un árbol de archivos vinculado al tenant bajo el home de BLUN.
  • El proyector antepone la tarea actual y las instrucciones expresas a la relación y la curiosidad. Durante el trabajo activo se omiten las preguntas personales, salvo que sean directamente relevantes para la tarea.
  • El presupuesto por defecto es de 1.800 caracteres; ni siquiera una configuración más alta puede superar el límite estricto de 2.800 caracteres.
  • Los derechos, ACL y secretos nunca se proyectan. Los identificadores inseguros, las divergencias de tenant, los datos erróneos, los enlaces simbólicos o las rutas fuera del home de BLUN no proporcionan ningún contexto de identidad y quedan bloqueados por defecto (fail-closed).
  • Las vías de conversación normal y rápida usan el mismo proyector antes de la persona, el alma y la conducta. En esta etapa no hay ninguna operación de escritura, ningún cambio del alma y ningún reinicio de proceso.
9.1.252
  • Un king update expreso desde una versión gestionada pasaba su packageRoot activo al instalador npm. Así, la nueva versión podía sobrescribir in situ la antigua carpeta de versión, cuyo nombre es el número de versión, mientras que active-runtime.json seguía indicando la versión antigua.
  • Los runtimes gestionados preparan ahora una actualización expresa como carpeta de versión independiente y versionada. pending-runtime.json y update-pending.json apuntan al destino; el siguiente inicio normal lo aplica sin una segunda pregunta de actualización.
  • La antigua carpeta de versión activa permanece estable byte a byte y se conserva como ruta de reserva (fallback). Las instalaciones globales no gestionadas conservan la vía de actualización explícita anterior.
  • No se inició, finalizó ni recargó ninguna sesión ni ningún proceso en curso para la compilación, la prueba o la publicación.
9.1.251
  • Tras la proyección de la 9.1.250, 6.411 de 6.424 eventos usage.record persistidos seguían conteniendo el mismo nombre de modelo canónico blun/king. Solo este valor predeterminado se omite en la forma persistida.
  • Los 13 valores de modelo divergentes (qwen3.8:27b) se conservan explícitamente. También null se conserva; solo undefined se restablece como blun/king en la reproducción.
  • Los eventos en vivo y el registro sin procesar congelado no se modifican.
9.1.250
  • En el wire real congelado, los 6.424 eventos usage.record persistidos contenían los dos contadores de caché inputCacheRead: 0 e inputCacheCreation: 0.
  • Solo estos valores comprobadamente nulos se omiten en la forma persistida. El uso en vivo permanece sin cambios; cualquier valor no nulo se sigue guardando.
  • En la reproducción, restoreUsageFromRecord restablece los contadores de caché que faltan como 0. Ambas rutas de reproducción y la proyección de contexto usan esta forma reconstruida.
9.1.249
  • En el registro real congelado, 3.759 de 7.777 resultados de herramienta llevaban un código de salida. De ellos, 3.465 eran el código de éxito rutinario 0.
  • La reproducción, la transcripción y la vista del modelo usan en los resultados de herramienta la salida, el ID de herramienta y el estado de error, no el código nulo adicional.
  • Ahora solo los resultados de herramienta correctos y persistidos omiten exitCode: 0. Los eventos en vivo lo conservan; los 294 códigos no nulos se conservan sin cambios para el diagnóstico de errores.
9.1.248
  • Después de 9.1.247, los 6.339 eventos step.end persistidos repetían reasoningFieldState, aunque ninguna ruta de reanudación ni de reproducción lee este campo.
  • Distribución en el registro real congelado: 5.016 absent, 47 not_requested y 1.276 present.
  • Solo la forma persistida omite ahora reasoningFieldState. Los eventos en vivo conservan el campo para fines de diagnóstico; los eventos guardados antiguos siguen siendo compatibles y el estado reconstruido permanece igual.
9.1.247
  • Después de 9.1.246, los 6.986 eventos content.part y los 7.755 eventos tool.call persistidos repetían la UUID del paso abierto actualmente.
  • En un registro real, los 14.741 eventos apuntan sin excepción al paso abierto más reciente: 0 desviaciones y 0 eventos sin paso abierto.
  • Solo la forma persistida omite ahora stepUuid. Los eventos en vivo la conservan sin cambios; los eventos guardados antiguos con UUID explícita y los nuevos eventos compactos sin UUID se admiten conjuntamente.
  • Las tres rutas de reanudación usan el paso abierto más reciente para los eventos compactos de contenido y de herramienta.
9.1.246
  • Después de 9.1.245, 5.642 eventos step.begin posteriores repetían el ID de turno, aunque la reanudación solo necesita el ID de turno más alto observado. El primer paso de cada turno ya lo lleva.
  • Un registro real contiene 713 turnos y 6.355 inicios de paso. Cada turno comienza exactamente con el paso 1 y todos los demás números de paso son consecutivos sin huecos; 0 desviaciones de secuencia.
  • Solo los inicios de paso persistidos posteriores omiten ahora el ID de turno. Los primeros pasos, los eventos en vivo, los eventos guardados antiguos y los inicios de paso sin número ordinal fiable permanecen sin cambios.
9.1.245
  • Después de 9.1.244, los 6.326 eventos step.end persistidos seguían repitiendo la UUID del paso abierto más reciente. Un registro real confirmó para cada finalización una asignación inequívoca de último en entrar, primero en salir: 0 desviaciones y 0 finalizaciones sin paso abierto.
  • Solo la forma de finalización persistida omite ahora la UUID. El evento en vivo la conserva sin cambios; los eventos guardados antiguos con UUID y los nuevos eventos compactos sin UUID siguen siendo reproducibles conjuntamente.
  • Las tres rutas de reanudación resuelven una finalización sin UUID mediante el paso abierto insertado más reciente. Los pasos históricos inconclusos permanecen abiertos y no se reinterpretan.
9.1.244
  • Después de 9.1.243, los 6.326 eventos step.end persistidos seguían conteniendo cuatro contadores de uso individuales. Para la reanudación y el nivel de llenado del contexto se necesita exclusivamente su suma.
  • Los eventos en vivo conservan los cuatro contadores para visualización, telemetría y facturación. Solo la forma de reanudación guardada usa ahora contextTokens como un único número.
  • Ambas rutas de reproducción aceptan eventos compactos nuevos y eventos completos antiguos. Así, las sesiones existentes siguen siendo compatibles con versiones anteriores.
9.1.243
  • Después de 9.1.242, los 6.322 eventos step.end persistidos seguían conteniendo los valores rutinarios finishReason: tool_use o finishReason: end_turn.
  • Ambos valores se pueden derivar exactamente de la forma de paso ya persistida: llamada de herramienta presente -> tool_use, en caso contrario end_turn. En el registro completo hubo 0 desviaciones.
  • Exclusivamente estos dos valores rutinarios ya no se persisten. Los motivos poco frecuentes y diagnósticamente importantes se conservan; los cuatro eventos max_tokens permanecieron explícitos e idénticos en su contenido de bytes.
  • La intervención sigue el principio de telemetría limitada y orientada a excepciones analizado en ECC. DeepAgents y AnythingLLM confirmaron los patrones BLUN ya existentes para la externalización y el registro limitado; no se adoptó ningún subsistema ajeno.
9.1.242
  • Después de 9.1.241, los 6.355 eventos step.begin persistidos seguían conteniendo el campo step, aunque la visualización en curso procesa el número de paso antes de la persistencia y el reductor de reproducción solo necesita uuid.
  • turnId se conserva porque la reanudación deriva de él el turno continuado. uuid, el tipo y todos los demás contenidos permanecen sin cambios.
  • La intervención se encuentra exclusivamente en bin/loop-event-record-policy.cjs; el registro sin procesar y el evento en vivo no se modifican.
9.1.241
  • Después de 9.1.240, los 6.326 eventos step.end persistidos seguían conteniendo copias de turnId y step. Ambos valores ya se encuentran en el step.begin referenciado por la misma uuid.
  • En un wire real, cada finalización tenía un inicio de paso existente y ambos valores de metadatos coincidían exactamente en todos los casos.
  • La proyección elimina solo estas dos copias. El identificador del paso, el consumo de tokens y los diagnósticos de finalización se conservan; los eventos en vivo permanecen completos.
9.1.240
  • Después de 9.1.239, los 6.986 eventos content.part y los 7.755 eventos tool.call seguían guardando cada uno una copia de turnId y step, aunque ambos valores ya se encuentran en el step.begin referenciado mediante stepUuid.
  • En un wire real, los 14.741 eventos secundarios tenían un inicio de paso existente y ambos valores coincidían exactamente en cada caso.
  • La proyección de persistencia elimina solo estas dos copias de metadatos de los dos eventos secundarios. stepUuid, el contenido, el identificador de la herramienta, el nombre y los argumentos se conservan; el reductor en vivo sigue viendo el evento completo.
9.1.239
  • Después de la proyección de 9.1.238, un wire real seguía conteniendo identificadores de evento redundantes: content.part.uuid no lo lee ningún consumidor de la reproducción, tool.call.uuid era exactamente igual a toolCallId en los 7.755 casos y tool.result.parentUuid era exactamente igual a toolCallId en los 7.755 casos.
  • La proyección de persistencia elimina solo estos tres campos redundantes. turnId, step, stepUuid, toolCallId, el nombre de la herramienta, los argumentos, el resultado y el contenido se conservan por completo. El reductor en vivo sigue viendo cada evento sin abreviar.
  • Los eventos ya compactos conservan su identidad de objeto. Los archivos de wire existentes no se reescriben ni se modifican.
9.1.238
  • Un wire real contenía 6.326 eventos step.end persistidos con 2.708.052 bytes de datos de evento. Siete campos para la medición del tiempo de ejecución y el identificador del mensaje del proveedor ya se habían evaluado en el evento en vivo antes de la persistencia y ninguna ruta de reproducción, transcripción, blob o inspección de sesión los leía.
  • La proyección de eventos de bucle existente elimina ahora solo estos siete campos en vivo conocidos: seis valores de medición de latencia/streaming y messageId. El identificador del paso, el turno, el número de paso, el consumo de tokens, el motivo de finalización, los diagnósticos de finalización del proveedor y el diagnóstico de razonamiento se conservan.
  • El reductor en vivo sigue procesando el evento completo. Los archivos de wire antiguos permanecen idénticos byte a byte y no se reescriben.
9.1.237
  • Un wire real contenía 1.428 entradas de registro y cancelación de registro para herramientas de usuario. De 992 cancelaciones, 560 eran operaciones nulas estrictas: la herramienta no estaba registrada ni activada. Estas entradas ocupaban 59.500 bytes persistidos sin cambiar el estado restaurado.
  • Del principio de DeepAgents de conservar solo el estado de ejecución efectivo se adopta una palanca local limitada: una cancelación de herramienta solo se registra si cambia el estado registrado o activado.
  • Ambas eliminaciones en vivo siguen ejecutándose en cada llamada. La cancelación de una herramienta registrada, de una solo activada o de una presente en ambos almacenes queda totalmente registrada. Los archivos de wire existentes no se reescriben ni se modifican.
9.1.236
  • Un wire real contenía 214 inyecciones de tipo estado para tool-awareness, action_style, swarm_mode y swarm_mode_exit. La deduplicación exacta anterior dejaba seis estados antiguos distintos con un total de 6.305 bytes de texto en cada nueva solicitud del modelo.
  • Del principio de ECC de mantener solo el estado actual en el contexto de trabajo y conservar el historial completo por separado se adopta una palanca local limitada: para el inventario de herramientas y el estilo de acción solo permanece visible la versión más reciente. La entrada y la salida del modo enjambre forman una familia de estado común, de la que también solo queda el último estado.
  • El registro sin procesar nunca se modifica. Otras variantes de inyección, mensajes de usuario normales, entradas no textuales y malformadas conservan el comportamiento anterior.
9.1.235
  • Un wire real contenía once llamadas Agent finalizadas. Seis de ellas habían terminado con éxito de forma demostrable (status: completed) y quedaban al menos veinte mensajes de contexto más atrás. Sus antiguos textos de tarea seguían ocupando en total 33.629 caracteres, aunque los informes de finalización completos figuraban justo después en el historial.
  • De la separación de DeepAgents entre el contexto del agente principal y el de los subagentes se adopta por ello una palanca local limitada: solo el prompt antiguo de una llamada Agent exitosa se reemplaza en la vista del modelo por un marcador breve. La descripción, el tipo de subagente y el informe de finalización permanecen completos.
  • Las llamadas en curso, las de menos de veinte mensajes de antigüedad, las fallidas, las malformadas y las llamadas de herramienta ajenas permanecen sin cambios. El registro sin procesar nunca se modifica; sin una línea explícita status: completed, la proyección no se aplica: bloqueada por defecto (fail-closed).
9.1.234
  • Entre los 166 resultados de herramienta exitosos de un wire real había tres resultados de lectura grandes, repetidos exactamente, para la misma llamada de herramienta. La repetición sin cambios ocupaba 15.936 bytes sin procesar, aunque para la vista actual del modelo solo se necesita la copia completa más reciente.
  • Por ello, la proyección reconoce exclusivamente resultados de texto puro exitosos con exactamente el mismo nombre de herramienta, exactamente los mismos argumentos y exactamente el mismo contenido. La copia más reciente permanece completa; las copias anteriores se reemplazan solo en la vista del modelo por una referencia breve.
  • El registro sin procesar, los resultados modificados, los errores, los medios, las referencias persistidas y los resultados pequeños permanecen sin cambios. La externalización de herramientas existente se sigue aplicando antes; la deduplicación solo puede restaurar su proyección para la copia idéntica más reciente.
9.1.233
  • En un wire real, una llamada de Write completa con 2.357 bytes UTF-8 fue rechazada en el límite anterior de 2.048 bytes. Después, el agente prometió la continuación, pero sobrescribió el mismo tokenize.cjs varias veces con fragmentos incompletos, entre ellos dos veces los mismos primeros 1.099 bytes, idénticos byte a byte. Los pasos afectados llevaban cada uno alrededor de 64.000 tokens de entrada; algunas respuestas alcanzaron 10.319 y 7.015 tokens respectivamente.
  • Por ello, los archivos completos de hasta 4.096 bytes UTF-8 pueden escribirse ahora en una llamada de Write atómica. El caso real de 2.357 bytes ya no necesita un turno adicional del modelo.
  • Las llamadas más grandes permanecen en el protocolo de continuación completo. Tras tal rechazo, la ruta queda bloqueada: los Write normales más pequeños ya no pueden sobrescribir el archivo de destino con fragmentos parciales. Solo una continuación válida se hace cargo de la ruta; el destino permanece sin cambios hasta la confirmación final.
9.1.232
  • El modo automático resume estaba configurado en un perfil de agente real, pero la versión instalada estaba en 9.1.221, el runtime preparado activo en 9.1.219 y npm/manifest ya en 9.1.231. Sin un King en ejecución, la ruta de fondo anterior no podía preparar una versión omitida.
  • Por eso, resume y new ahora también buscan, en el siguiente arranque en frío natural, una versión estable desde hace al menos 30 minutos y firmada de forma independiente. Se prepara en el almacén protegido de versiones, se marca como pending y se inicia sin un segundo arranque ni ventana de selección.
  • manual y off permanecen sin cambios. Si fallan la preparación, la integridad, la prueba del paquete o la descarga por red, se sigue usando la ruta de inicio existente. Una sesión ya en ejecución nunca se finaliza mediante esta ruta de arranque en frío.
9.1.231
  • En un wire real, una respuesta de Telegram falló antes del envío con 400: Bad Request: can't parse entities: Can't find end of Italic entity. La llamada había solicitado expresamente format: markdownv2; 0 de 1 partes de texto fueron entregadas.
  • El envío de Telegram vía MCP repite ahora solo la parte de texto afectada exactamente una vez como texto plano cuando Telegram informa exactamente un error de análisis de entidades. El chat, la referencia de respuesta, el límite de la parte y los adjuntos posteriores se conservan.
  • Los errores de red, los chats desconocidos, los errores de permisos y las llamadas ya enviadas como texto plano no se repiten con esta alternativa. Así no se traga ningún error arbitrario ni se envía dos veces una parte exitosa.
9.1.230
  • Tras excluir los errores históricos ya corregidos con 9.1.228 y 9.1.229, en los últimos 1.200 resultados de herramienta de un perfil de agente quedaron los timeouts de Bash repetidos como el siguiente bloque cerrado. Los comandos afectados buscaron varias veces de forma recursiva en todo el directorio del usuario o en toda la carpeta de Dropbox y terminaron después de 60 segundos sin un resultado aprovechable.
  • Bash rechaza ahora antes del inicio del proceso exactamente dos formas de búsqueda sin límite: find en todo el directorio del usuario y grep recursivo sobre ..
  • El texto de error menciona de inmediato la alternativa limitada: Glob con un patrón de archivo anclado, Grep con ruta/glob o un subdirectorio de proyecto conocido. Las búsquedas limitadas específicamente a src, test u otros subárboles nombrados siguen permitidas sin cambios.
  • El timeout no se aumentó y los comandos Bash arbitrarios no se repiten automáticamente. Así no se genera ni un tiempo de espera más largo ni el riesgo de ejecutar dos veces un comando que escribe.
9.1.229
  • Tras la reparación de la herramienta diferida, la familia de errores contigua más grande en un registro real era el Write de varias partes: campos obligatorios faltantes (part, start_line, final), un número total de líneas adivinado incorrectamente de antemano, números de parte desactualizados y un estado de continuación antiguo aún activo tras errores generaron repeticiones sin trabajo útil.
  • El número de parte, la línea de inicio y el modo se derivan ahora del estado realmente almacenado cuando faltan. Los valores enviados explícitamente permanecen visibles y se siguen rechazando en caso de desviación.
  • expected_lines es opcional y puede indicarse por primera vez en la parte final. Cuando está establecido, el desbordamiento y la comprobación final exacta siguen bloqueados por defecto (fail-closed), sin cambios.
  • final=true sigue siendo obligatorio para la finalización. Sin esta marca final explícita no se escribe nada; el archivo de destino permanece sin cambios hasta la finalización. La comprobación opcional de SHA-256 se mantiene.
9.1.228
  • En los últimos 1.000 resultados de herramienta reales había 66 errores. El bloque individual más grande y claramente reparable eran 10 errores Tool not found: nueve veces mcp__mnemo__mem_transcript_recent y una vez mcp__mnemo__mem_question_answer. Ambas herramientas estaban registradas; simplemente no se habían cargado en ese paso por el presupuesto de tokens.
  • Tras un error exacto Tool "<name>" not found, el turno recuerda ahora este esquema para el paso inmediatamente siguiente. La selección normal lo toma entonces de la lista de herramientas ya registradas.
  • Otros textos de error, resultados exitosos y nombres de herramienta diferentes no modifican el estado. El límite LRU existente de cuatro esquemas se mantiene; una herramienta realmente desconocida no se inventa ni se ejecuta por ello.
  • No se colocó ninguna herramienta permanentemente en cada prompt. El consumo normal de tokens del esquema permanece por tanto sin cambios; solo se evita a partir del segundo intento una repetición de error ya pagada.
9.1.227
  • Un registro de wire real contenía 119 llamadas ToolSearch. 35 de ellas terminaron sin resultados; 27 resultados nulos afectaban al historial de Telegram, a la recuperación de mensajes o a la búsqueda de memoria asociada.
  • 9.1.226 resolvió ya 8 de estos 35 resultados nulos antiguos con la lista de herramientas actual. El caso principal restante eran solicitudes sobredeterminadas como +telegram history messages lesen, en las que el modelo había marcado erróneamente palabras semánticas como componentes de nombre obligatorios.
  • De DeepAgents se adoptó el principio de armonizar las pistas de herramientas y la superficie de herramientas después del filtrado. No se copió ningún código ajeno: BLUN sigue intentando primero la búsqueda exacta y estricta y solo relaja los términos + a términos de búsqueda semánticos después de un resultado nulo real.
  • La alternativa no ejecuta ninguna herramienta. Solo carga el esquema mejor valorado o, si hay un empate real, los esquemas empatados; con varios términos exige al menos un 75 por ciento de aciertos y, con términos ajenos al ámbito, permanece cerrada.
  • Comparación con el paquete 9.1.226 recién instalado y las mismas 35 solicitudes históricas: antes 8 aciertos, después 21 aciertos, es decir 13 aciertos reales adicionales y 0 aciertos anteriores perdidos.
  • No se insertó ninguna llamada nueva de modelo, búsqueda, red o embedding. El registro sin procesar, la ejecución de herramientas, las autorizaciones y el conjunto permanente de esquemas permanecen sin cambios.
9.1.226
  • Un registro de wire real contenía 6.275 pasos de modelo finalizados. En los últimos 50 pasos, la construcción local de la solicitud estaba en p50 0 ms y p90 1 ms, y el consumo local del stream en p50 1 ms y p90 3 ms. El tiempo de espera hasta el primer token del servidor estaba en cambio en p50 11.842 ms y p90 14.846 ms. Por tanto, no se demostró que otra optimización local de microrendimiento fuera una palanca efectiva.
  • La ruta de aprendizaje validada derivada de Evolver ya existía: los comprobantes de rojo a verde se guardan por perfil como pending, recorded o expired. Pero los usuarios no tenían ninguna vista local de ello.
  • 9.1.226 añade /improve con el alias /learning. El panel muestra los tres contadores de estado y, para el candidato abierto más reciente, solo datos de comprobante limitados e inofensivos: ID del candidato, nombre de la herramienta y doce caracteres del hash del comando.
  • El comando solo lee el almacenamiento local del perfil activo. No inicia ninguna llamada de modelo, búsqueda, hub o embedding y no modifica ningún candidato. Los valores de estado desconocidos y los caracteres de visualización inseguros se descartan o se muestran como unknown.
  • Todos los textos de interfaz nuevos para alemán, español, francés, sueco y checo superaron el control lingüístico obligatorio y la verificación de recibos posterior; los seis catálogos de interfaz contienen las claves completas.
9.1.225
  • En un registro de wire real, 88 entradas config.update ocupaban 4.078.566 bytes. 83 de ellas llevaban el prompt completo del sistema.
  • El prompt declaraba una marca de tiempo de sesión estable, pero la restablecía en cada inicio del proceso. Tras normalizar esta marca de tiempo quedaban 45 variantes semánticas y 38 repeticiones consecutivas causadas únicamente por la nueva marca de tiempo.
  • Estas 38 repeticiones ocupaban 781.179 bytes, es decir, el 19,16 por ciento de todos los bytes del prompt del sistema en los eventos de configuración medidos. Al mismo tiempo, el prefijo reutilizable del prompt del proveedor se modificaba innecesariamente tras los reinicios.
  • 9.1.225 vincula la marca de tiempo en agentes principales y subagentes nuevos y reanudados a Session.metadata.createdAt. Los metadatos antiguos no válidos recurren de forma defensiva al valor en memoria anterior.
  • El registro sin procesar, el contenido del prompt, las herramientas, la elección del modelo y la compactación permanecen sin cambios. No hay ninguna llamada adicional de modelo, búsqueda o embedding.
9.1.224
  • El último arranque medido necesitó 16,85 segundos para la inicialización paralela de cinco servidores MCP. La reanudación de la sesión y el análisis del wire eran claramente menores, con alrededor de 0,55 y 0,18 segundos respectivamente.
  • La ruta del turno esperaba hasta ahora esta inicialización MCP antes de cada solicitud, incluso cuando un simple saludo local recibía después, deliberadamente, cero herramientas en la solicitud al modelo.
  • 9.1.224 adopta el límite de herramientas cargadas bajo demanda de la comparación con DeepAgents: solo la conversación corta local y sin herramientas puede responder de inmediato. Los turnos de Telegram, los adjuntos, los desencadenantes del sistema y cualquier solicitud de trabajo siguen esperando la inicialización MCP completa.
  • El registro sin procesar, la configuración MCP, los esquemas de herramientas y los turnos de trabajo normales permanecen sin cambios. No se desactivó ningún servidor ni se introdujo ninguna llamada adicional de modelo, búsqueda o embedding.
9.1.223
  • Un paso 775.5 terminó vacío con fall=length, 8.192 de 8.192 tokens de finalización y solo siete caracteres de razonamiento. La lógica anterior iniciaba de nuevo la misma solicitud grande y duplicaba el presupuesto de finalización a 16.384 tokens.
  • Durante la espera, la CPU local estaba en torno al 0 por ciento; la construcción de la solicitud tardaba 0-1 ms y el transporte, unos dos segundos. Por tanto, el cuello de botella medido era la generación del modelo más el reintento con presupuesto completo, no la TUI.
  • Solo el caso documentado de length con presupuesto totalmente agotado y menos de 64 caracteres de razonamiento recibe ahora un reintento económico con factor 0,125 y al menos 1.024 tokens.
  • Las respuestas length con mucho razonamiento y no totalmente agotadas conservan la ampliación anterior con factor 2. Las demás clases de reintento permanecen sin cambios.
  • Para un caso medido, el segundo presupuesto baja de 16.384 a 1.024: 15.360 tokens, es decir, un 93,75 por ciento menos en el reintento.
9.1.222
  • El actualizador en ejecución había entregado una versión preparada al King activo mediante IPC. El launcher finalizó entonces el núcleo en ejecución con el código de salida 76 y debía iniciar un proceso de reemplazo. En el cambio medido a 9.1.219, un perfil de agente quedó por ello desconectado.
  • Las actualizaciones en segundo plano ahora solo descargan y verifican la nueva versión y la dejan preparada para el siguiente arranque natural. No envían ningún mensaje IPC de reinicio, no finalizan ninguna TUI activa y no inician ningún proceso de reemplazo.
  • En el siguiente arranque normal de king vuelve a aparecer la selección existente: actualizar, omitir una vez o esperar a la siguiente versión. Solo tras la decisión de instalación, el launcher arranca desde el paquete preparado ya verificado; no hace falta una segunda descarga.
9.1.221
  • Los mensajes sin cambios aún no cubiertos por tokenCount usan ahora exactamente una estimación de tokens por revisión de contexto. Los accesos repetidos de estado y renderizado no escanean de nuevo el mismo historial creciente.
  • Las nuevas partes de texto, las llamadas de herramienta, los cambios en el historial, la compactación, el deshacer y un número modificado de mensajes ya cubiertos invalidan la caché de inmediato. El registro sin procesar, el historial persistido y el valor de tokens notificado permanecen idénticos respecto a la ruta anterior.
  • Siete ejecuciones de medición con 300 mensajes sintéticos y 250 consultas sin cambios cada una dieron una mediana de 42,1218 ms -> 0,1755 ms, alrededor de un 99,583 % menos de tiempo de cálculo en este hotpath. Ambas versiones obtuvieron exactamente el mismo valor estimado de 127.838 tokens.
  • La versión reduce el trabajo de CPU para la estimación local. No afirma una reducción de los tokens de entrada realmente enviados al modelo.
9.1.220
  • La proyección de respuestas largas del asistente guarda ahora su resultado en un WeakMap mientras el objeto del mensaje, el array de contenido, la parte de texto y el texto fuente exacto permanezcan sin cambios. El registro sin procesar y el contenido proyectado permanecen idénticos respecto a la ruta anterior.
  • Un cambio en el texto, el array de contenido o la parte de texto descarta la entrada de inmediato. Los objetos de mensaje diferentes no comparten ninguna caché.
  • Cinco ejecuciones de medición con 1000 proyecciones repetidas cada una dieron una mediana de 16,489 ms -> 0,202 ms, alrededor de un 98,8 % menos de tiempo de cálculo en esta ruta. Ambas versiones ahorraron exactamente 21.206 caracteres.
9.1.219
  • Las simples confirmaciones breves de texto, como ok, danke o las respuestas de Telegram por DM con una señal de continuación al final, ya no leen el almacén de candidatos de aprendizaje validados en cada paso del modelo.
  • Los prompts con contenido relevante, los adjuntos y los turnos con actividad de herramientas actual siguen sincronizándose. Un recordatorio de aprendizaje ya visible también se conserva durante una confirmación omitida.
  • La medición real sobre el paquete con 50 confirmaciones bajó de 50 a 0 lecturas del directorio de candidatos. La contraprueba con un mensaje relevante leyó exactamente una vez. No se añadió ninguna llamada de modelo, embedding o red.
9.1.218
  • En 9.1.217, la misma comprobación de rojo a verde generó un segundo candidato abierto al repetirse con nuevos IDs de llamada de herramienta. La medición aislada arrojó dos IDs, 2 archivos abiertos y 726 bytes.
  • Tras registrar solo el candidato más reciente, el candidato idéntico más antiguo habría vuelto a aparecer como recordatorio. Eso habría generado un segundo ciclo de recordatorio y MistakeRecord para la misma lección abierta.
  • bin/validated-learning-signal.cjs reutiliza ahora un candidato ya abierto del mismo perfil y del mismo commandHash. Los demás comandos de verificación permanecen separados; los candidatos registrados o caducados no absorben ningún evento posterior.
  • La nueva medición arrojó la misma ID, 1 archivo abierto y 363 bytes. No hay ninguna llamada adicional de modelo, embedding o red.
9.1.217
  • En 9.1.216, cada MistakeRecord exitoso marcaba el candidato de aprendizaje abierto más reciente como procesado, aunque la entrada perteneciera a otro error. La evidencia era así persistente, pero no correlacionada exactamente con su registro posterior.
  • bin/validated-learning-signal.cjs lee ahora el candidateId opcional de un MistakeRecord exitoso y cierra exclusivamente el candidato abierto exactamente correspondiente. Una ID ausente, incorrecta o ajena deja todos los candidatos abiertos sin cambios.
  • blun.mjs nombra la ID de candidato estable en el recordatorio visible y añade candidateId como campo opcional en el esquema de MistakeRecord. No hay ninguna llamada adicional de modelo, embedding o red.
  • La correlación permanece vinculada al perfil. En el almacén de candidatos siguen sin guardarse comandos en bruto ni salidas de herramientas.
9.1.216
  • bin/validated-learning-signal.cjs deposita ahora las señales de rojo a verde confirmadas a nivel de instalación en <BLUN_SHARED_HOME>/self-improvement/validated-learning/<profile>/. Así, un candidato de aprendizaje se conserva a través de turnos de usuario, compactaciones y distintos portales de la misma instalación BLUN.
  • El almacén está vinculado al perfil, es append-only y seguro frente a concurrencia: por candidato se crea un archivo JSON inmutable y exactamente un marcador .recorded o .expired. El archivo temporal, el hardlink y la eliminación del archivo temporal impiden la sobrescritura silenciosa con escritores paralelos.
  • Solo se guardan el tipo, el estado, el perfil, el nombre de la herramienta, el SHA256 del comando, los IDs de llamada de herramienta y las marcas de tiempo. El comando en bruto, el texto de error y la salida exitosa de la herramienta no se persisten.
  • Un MistakeRecord exitoso marca el candidato abierto más reciente exactamente una vez como procesado. Los candidatos abiertos caducan después de 24 horas. Si falta un directorio home compartido, se conserva el comportamiento anterior en memoria en modo fail-open.
  • Esto no es todavía un cambio de código automático ni un permiso autoconcedido. La versión crea solo la evidencia de aprendizaje portable e independiente del portal sobre la que pueden trabajar con seguridad las funciones integradas posteriores de evaluador y aprobación.
9.1.215
  • Las soluciones no pueden presuponer ni a agentes internos concretos, ni nombres de máquina internos, ni grupos de Telegram, ni instancias de Mnemo, ni una cadena de aprobación interna de BLUN.
  • Para la automejora, los roles internos se abstraen como funciones de producto: controlador de alcance/aprobación, evaluador aislado, evidencia versionada y nueva medición canary automática con rollback.
  • Solo pueden adoptarse automáticamente ajustes de bajo riesgo y de alcance mediblemente limitado cuando todas las muestras resultan mejores o neutras. El código, los derechos, los secretos, la facturación y la producción siguen requiriendo la intervención del usuario o del administrador.
  • La primera implementación del control integrado se aprueba internamente de forma manual; después, el control puede realizar las comprobaciones por sí mismo, pero no modificar su propio límite de seguridad.
9.1.214
  • 9.1.213 estableció la ruta correcta de almacenamiento persistente mediante MistakeRecord, pero seguía esperando que el modelo reconociera el momento adecuado solo a partir del historial de herramientas.
  • Novedad: bin/validated-learning-signal.cjs. El módulo considera solo el turno de usuario actual y reconoce exclusivamente el mismo comando de shell de verificación que primero falla y después tiene éxito.
  • Un inyector dinámico en blun.mjs recuerda en este caso demostrado registrar una lección reutilizable con MistakeRecord. El texto del comando y el error en bruto no se copian en la pista.
  • Otros comandos, errores normales de lectura/herramienta, un nuevo turno de usuario o una llamada MistakeRecord ya exitosa no generan ni conservan ninguna pista. No se produce ningún almacenamiento automático.
9.1.213
  • Tras una prueba de rojo a verde exitosa, el contrato de misión exigía la llamada record_error_memory. Esta herramienta no existe en el paquete King. La ruta de aprendizaje persistente existente se llama MistakeRecord y escribe en el archivo común Mistake.md.
  • Por ello, la disciplina de Evolver ya estaba formulada, pero el último paso hacia nuestra propia memoria compartida entre agentes no funcionaba: una solución confirmada podía seguir el contrato y, sin embargo, no guardarse de forma permanente.
  • El contrato llama ahora a MistakeRecord tras la nueva ejecución en verde. Los errores en bruto siguen quedándose fuera; solo se guarda la lección confirmada mediante una ejecución de contraste exitosa.
  • Mistake.md, su selección de relevancia y su formato de almacenamiento no fueron reemplazados ni modificados. Se reparó exclusivamente la conexión del contrato de aprendizaje validado con la herramienta existente.
  • Se modificaron solo blun.mjs, el nuevo test de estructura test/validated-learning-route.test.js y la versión en package.json.
9.1.212
  • El inyector de ErrorMemory formateaba varios genes de estrategia incluso para simples saludos y confirmaciones breves. Mistake.md y la memoria personal ya tenían un límite de relevancia común para la misma clase de mensajes; solo ErrorMemory lo eludía.
  • El inyector usa ahora también isLowInformationMistakeTurn y finaliza la proyección antes de la selección y el formateo de los genes de estrategia. Las entradas de error y estrategia persistidas permanecen sin cambios; solo desaparece su proyección innecesaria en solicitudes mínimas.
  • Caso de referencia medido Wie geht es dir? con once entradas guardadas: antes cinco reglas seleccionadas, 1.417 caracteres, es decir, alrededor de 355 tokens; después 0 caracteres y 0 tokens.
  • Se modificaron solo blun.mjs, test/error-memory-performance-policy.test.js y la versión en package.json.
9.1.211
  • El King confirma las líneas de la cola solo cuando el mensaje ha sido aceptado. Sin embargo, antes de una sesión activa, injectChannelEnvelope descarta un mensaje dirigido como dropped, sin confirmarlo ni aparcarlo. Así, el checkpoint puede quedarse de forma permanente justo en esta primera línea.
  • Prueba de rojo real _proof/telegram-profile-checkpoint-red.cjs: esperado queued, medido dropped, código de salida 1.
  • El mismo error está en la ruta de comandos de Telegram: /loop antes de una sesión activa no se coloca en queuedMessages; la función de confirmación queda sin consumidor. Prueba de rojo real _proof/telegram-remote-command-presession-red.cjs: esperada longitud de cola 1, medida 0, código de salida 1.
  • injectChannelEnvelope trata ahora una sesión que aún no puede recibir entregas como una sesión ocupada: el texto del modelo, el origen de visualización y la confirmación posterior se conservan en la cola de canal existente.
  • injectTelegramRemoteCommand construye la entrada de cola antes de la comprobación de sesión. /loop y los demás comandos directos de Telegram se aparcan con su función channelAcknowledge cuando falta la sesión y solo se ejecutan en el límite seguro existente.
  • El orden y la regla de checkpoint existente permanecen sin cambios: una línea de cola solo se confirma después de su aceptación; las confirmaciones posteriores no pueden saltarse una línea anterior aún abierta.
9.1.210
  • El traspaso activo de 9.1.208/9.1.209 podía finalizar un King en ejecución para una actualización. En el MSI, la sesión en ejecución se finalizó por ello en el cambio 9.1.206 -> 9.1.207 y no se reanudó automáticamente.
  • Por ello, 9.1.209 no se incluyó en el manifiesto público y se marcó en npm como no desplegable.
  • La directriz está ahora impuesta técnicamente: una actualización automática nunca puede finalizar el King en ejecución. Solo se descarga y se marca como pending. La activación se produce solo en un arranque normal posterior.
9.1.209 Retirado
  • No publicada. El traspaso de actualización activo podía finalizar un King en ejecución; por eso la versión no llegó al manifiesto público y se marcó en npm como no desplegable.
9.1.208
  • En el MSI se midieron en un día 27 inicios de King y 15 versiones. Los reinicios coincidían en cada caso con saltos de versión; el log de ese equipo sigue sin registrar un motivo de salida propio.
  • El actualizador preparaba nuevas versiones del manifiesto cada minuto. La versión 9.1.208 introduce por ello una ventana de reposo de 30 minutos antes de que pueda activarse otro runtime nuevo.
  • Tras una activación exitosa, las versiones antiguas del runtime se limitan a las tres más recientes. Solo se borra cuando se han adquirido en exclusiva todos los leases de instalación de la versión antigua. Los layouts activos, ocupados o desconocidos permanecen intactos.
  • La lógica de protección también está en el núcleo recién cargado. Así actúa tras la activación automática incluso cuando el launcher padre persistente procede todavía de una versión anterior.
  • Las ocho versiones medidas en el MSI ocupaban en total solo 778 MB. No explican el disco de 454 GB casi lleno; el gran consumidor sigue siendo un hallazgo abierto aparte.
9.1.207
  • Los reintentos de telemetría fallida se limitan por ejecución a los 16 archivos más antiguos y se detienen ante el primer error temporal del servidor, en lugar de seguir procesando todo el trabajo acumulado.
  • La cola (spool) de errores conserva los 512 archivos más recientes dentro de un límite de 16 MiB y siete días. El archivo events.jsonl normal está expresamente excluido de la limpieza.
  • Antes de esta versión había en la práctica 4.248 archivos de error con 11.631.974 bytes. Tras la activación automática había 512 archivos con 2.260.908 bytes: 3.736 archivos de error antiguos y alrededor de 9,37 MB de carga menos.
9.1.206
  • Las respuestas grandes del asistente ya archivadas se reemplazan ahora, antes de la proyección de bucle, por su referencia de archivo limitada, que se puede volver a leer. Así, una limpieza de texto posterior ya no puede invalidar el hash guardado.
  • Se comprobaron byte a byte tres archivos archivados reales contra sus hashes SHA256 de mensaje guardados: 38.567, 13.941 y 24.787 caracteres; todos estaban presentes y todos coincidían exactamente.
  • Sobre exactamente los mismos 41.480 registros de wire con 311 mensajes, la proyección del modelo bajó de 87.724 a 63.234 caracteres: otros 24.490 caracteres, es decir, alrededor de 6.123 tokens de entrada menos por llamada afectada.
  • El historial sin procesar y los archivos archivados privados completos permanecen sin cambios y se pueden leer página a página a través de su ruta.
9.1.205
  • Los bucles de respuesta dentro de un mensaje del asistente se reconocen ahora también con pequeñas diferencias de puntuación o de redacción. Un clúster necesita al menos tres aciertos con similitud conservadora 0,88; la primera versión se conserva y el historial sin procesar no se modifica.
  • En un caso conservado, una respuesta de bucle real bajó de 24.787 a 22.711 caracteres: 2.076 caracteres, es decir, alrededor de 519 tokens de entrada menos.
  • Los bloques de código delimitados siguen protegidos byte a byte. La narración de herramientas, las inyecciones, las repeticiones dobles y los ahorros inferiores a 1.000 caracteres permanecen sin cambios.
9.1.204
  • El recordatorio de errores ya no carga ciegamente las once reglas en cada ronda de trabajo. Las cuatro reglas imprescindibles de evidencia y contraprueba 4, 9, 10 y 11 permanecen siempre activas; como máximo se añaden, de forma determinista, dos reglas más adecuadas a la tarea actual.
  • En la colección de reglas real incluida en el paquete, el bloque repetido bajó de 2.442 a 1.272 caracteres: 1.170 caracteres, es decir, alrededor de 293 tokens de entrada menos por ronda de trabajo afectada.
  • La selección no genera ninguna solicitud de modelo, búsqueda, reranker o embedding. Las colecciones de reglas propias pequeñas permanecen completas; ante un error del selector sigue actuando el bloque completo anterior.
9.1.203
  • Una ToolSearch vacía es ahora un resultado nulo completado con éxito en lugar de un error de herramienta rojo. La respuesta nombra la herramienta autorizada que falta y prohíbe una repetición con sinónimos.
  • En un historial medido había 32 búsquedas vacías con 29 formulaciones; en un turno conservado, la misma capacidad de Telegram que faltaba se volvió a solicitar directamente con una segunda búsqueda tras el error en rojo.
  • Ninguna solicitud adicional de modelo, reranker o embedding, ningún esquema residente nuevo y ningún cambio en herramientas o permisos.
9.1.202
  • En directorios de trabajo grandes, la proyección de contexto local derivada de DeepAgents muestra preferentemente entradas de nivel superior en lugar de detalles profundos de las primeras carpetas. Las listas de directorio pequeñas permanecen idénticas byte a byte.
  • Un directorio raíz de agente contiene 509 entradas de nivel superior (89 carpetas, 420 archivos). Antes, la proyección del modelo mostraba en 1.981 caracteres solo 9 carpetas de nivel superior; ahora muestra 30 en 832 caracteres.
  • Ahorro medido: 1.149 caracteres, es decir, unos 287 tokens por solicitud. La persona, las reglas de trabajo, el historial sin procesar y el acceso a herramientas permanecen sin cambios.
9.1.201
  • Una higiene de proyección derivada de DeepAgents compacta la memoria de errores estática sin perder ninguna de las 11 reglas o comprobaciones guardadas.
  • Los textos antiguos y extensos de la memoria de errores solo se compactan en la proyección del modelo. El historial sin procesar, las respuestas normales y los resultados de herramienta permanecen sin cambios.
  • En la proyección solo se conserva, en cada caso, la inyección más reciente de errores y la de corrección de errores.
9.1.200
  • El nuevo comando local /context muestra por separado la solicitud al modelo realmente proyectada, el historial de conversación guardado, los esquemas de herramientas, el presupuesto de compactación y el margen restante.
  • La vista lee exclusivamente session.getContext(). No inicia ninguna solicitud al modelo, ninguna consulta de consumo gestionada, ningún servicio ni ningún reinicio.
  • Los resultados de herramienta externalizados indican ahora una forma exacta de volver a leerlos: Read con un máximo de 20 líneas y, a continuación, avanzando line_offset. Esto evita el patrón medido, en el que un agente volvía a solicitar la misma zona grande con Read, Grep y Bash.
  • /premortem ya existía antes de 9.1.200 y expresamente no se presenta como una función nueva de esta versión.
  • Para las traducciones nuevas, el control lingüístico obligatorio no dio su aprobación por falta de una revisión independiente de textos cortos. Por eso, /context usa solo denominaciones localizadas ya validadas; no se incorporó ningún texto de destino sin revisar.
9.1.199
  • Una vista actual del modelo contenía, en una sola respuesta del asistente, 13.941 caracteres con 100 bloques de párrafo. Solo 20 bloques eran únicos; seis grupos se repetían exactamente y ocupaban 9.579 caracteres.
  • 9.1.199 compacta exclusivamente esas repeticiones exactas dentro de una única respuesta de solo texto en la vista del modelo. El historial de sesión en bruto permanece sin cambios.
  • La compactación solo actúa a partir de tres repeticiones exactas y al menos 1.000 caracteres ahorrados. Los bloques de código, los contenidos mixtos, las llamadas de herramienta, los mensajes de inyección, los bloques cortos y los ahorros menores permanecen sin cambios.
  • Esto sigue el principio de DeepAgents de conservar una verdad que se puede volver a leer y aligerar solo la vista activa del modelo. No hay ninguna llamada adicional de modelo o embedding.
9.1.198
  • Un historial actual contenía un resultado ya marcado como truncated: true por la herramienta Grep, con 50.042 caracteres. La externalización de resultados individuales reconocía el tamaño, pero, por un return anticipado, dejaba esos resultados completos en la vista del modelo.
  • 9.1.198 elimina exclusivamente esta excepción. Un Read truncado usa la ruta de origen existente sin duplicado; otros resultados truncados archivan exactamente el texto completo devuelto por la herramienta.
  • La referencia conserva truncated: true y lleva stored_result_scope: tool_truncated_output. Así no se afirma que se haya restaurado una salida en bruto que la herramienta nunca devolvió.
  • El patrón sigue el modelo de DeepAgents: las salidas grandes de herramienta se pueden seguir leyendo fuera de la vista activa del modelo, mientras que en ella solo queda una referencia pequeña.
9.1.197
  • Hasta ahora, incluso las confirmaciones de solo texto como ok cargaban el recordatorio dinámico de Mistake.md. Con el conjunto actual de reglas compartidas eran 1.819 caracteres de prompt, aproximadamente 455 tokens, aunque no se continuaba ningún contexto de trabajo.
  • 9.1.197 reconoce exclusivamente turnos de texto puro con poca información antes de que se lea una de las dos fuentes de Mistake y omite allí la inyección dinámica.
  • Los adjuntos, los contenidos no textuales y las continuaciones con sentido como ok, check updater conservan la ruta anterior. El fallback de relevancia existente para turnos de trabajo reales permanece sin cambios.
  • El patrón proviene del trabajo comparativo con AnythingLLM: las fuentes de contexto opcionales solo deben llegar a la vista del modelo cuando el turno actual las necesita realmente. Se integró en la política BLUN existente sin llamadas adicionales de modelo o embedding.
9.1.196
  • /reload existía localmente, pero desde Telegram no se reconocía como comando directo. La allowlist de Telegram no contenía el nombre; por ello, el mensaje seguía siendo texto normal para el modelo.
  • 9.1.196 añade exclusivamente reload a la lista existente de comandos de Telegram dirigidos.
  • La ruta de Telegram usa el mismo handler existente que la TUI local: la sesión, los servidores MCP, el runtime y la configuración de la TUI se recargan en el proceso en ejecución. No se inicia ninguna ronda de modelo ni ningún reinicio de proceso.
  • /new y los demás mensajes de barra no aprobados siguen siendo texto normal para el modelo.
9.1.195
  • Las actualizaciones automáticas se ejecutaron, pero la TUI reiniciada acabó en C:\ en lugar de en la carpeta de proyecto que se usaba hasta entonces.
  • La TUI llevaba la carpeta correcta en state.appState.workDir, pero en el traspaso de actualización solo entregaba sesión, versión y modo. El launcher usaba por ello su carpeta de inicio original para el destino y el fallback.
  • 9.1.195 transporta la carpeta de proyecto activa en el traspaso y la usa para la versión de destino, el fallback y las demás actualizaciones automáticas de la misma supervisión.
  • Solo se aceptan directorios absolutos existentes. Las rutas relativas, inexistentes o que apuntan a archivos recurren a la carpeta del launcher.
9.1.194
  • El watchdog de turno existente avisaba a los 20 minutos, pero después no finalizaba el turno. En el Mac, un turno atascado siguió ejecutándose tras el aviso de los 30 minutos hasta al menos el minuto 39.
  • 9.1.194 mantiene el aviso a los 20 minutos y finaliza un turno tras 30 minutos sin progreso real.
  • El inicio del paso, el texto de pensamiento, el texto del asistente, la llamada de herramienta, los argumentos de herramienta, el progreso de herramienta y el resultado de herramienta restablecen el plazo de inactividad. Así, un trabajo largo activo no se finaliza.
  • La interrupción existente tras cinco llamadas de herramienta fallidas idénticas sigue separada y activa sin cambios.
9.1.193
  • Varias entregas de Telegram llegaron con la misma chat_id y message_id hasta cuatro veces en la misma sesión.
  • 9.1.181 no eliminaba estas repeticiones de la vista del modelo hasta más tarde. Antes, cada copia ya podía provocar un turno de modelo propio y, con ello, costes.
  • Por ello, 9.1.193 introduce, antes del inicio del turno, un ledger de entregas limitado a 2.048 identificadores. El mismo identificador de Telegram solo se acepta una vez por sesión; las repeticiones se confirman, pero no se registran ni inician ningún turno del proveedor.
  • Los identificadores de mensaje nuevos, las inyecciones que no son de usuario y el historial en bruto permanecen sin cambios. Al continuar, el ledger se restaura a partir de los registros de prompt aceptados.
9.1.192
  • Tras denegarse una autorización de Bash, un Mac siguió mostrando King is thinking durante 39 minutos. La llamada de herramienta en sí se rechazó correctamente, pero la denegación se devolvió como resultado de error ordinario al bucle de modelo en curso.
  • PermissionManager.requestToolApproval() solo devolvía block: true al denegar. El control de lote y proveedor existente ya podía finalizar el turno con syntheticResult.stopTurn = true, pero no recibía esta señal.
  • Novedad: bin/approval-rejection-stop.cjs. Las autorizaciones denegadas y canceladas generan ahora un resultado de error existente con stopTurn: true. El turno actual termina y las llamadas posteriores de la misma pila de herramientas se omiten. El registro de autorizaciones, la política y el comportamiento fail-closed permanecen sin cambios.
  • DeepAgents confirmó el límite explícito de interrupción humana como patrón adecuado. AnythingLLM y Evolver no ofrecían para este error limitado ningún mecanismo más fuerte que el contrato BLUN ya existente.
9.1.191
  • DeepAgents ofrece con /context una división familiar y visible de la ventana de contexto en lugar de solo un valor total.
  • Evolver exige para el trabajo de rendimiento un presupuesto de prompt separado para la parte del sistema, la conversación, las herramientas y el espacio libre.
  • AnythingLLM ahorra esquemas de herramientas mediante reranking basado en embeddings. BLUN ya dispone para ello de la vía más barata de las herramientas diferidas, sin llamadas adicionales de modelo o embedding; por eso esta parte no se duplicó.
9.1.190
  • De los eventos de bucle tool.call guardados de forma permanente solo se eliminan los campos de visualización display y description. La identidad, el nombre de la herramienta, los argumentos y la asignación de paso se conservan.
  • El runtime sigue procesando el evento completo. La visualización de la TUI, la ejecución de herramientas y la reanudación no se cambiaron a la proyección.
  • Un wire real de agente con 42.451.368 bytes contenía 6.135 llamadas de herramienta. En 5.679 de ellas pudieron omitirse 3.125.874 bytes: el 7,36 % de todo el registro del wire.
9.1.189
  • Un usuario había elegido bosnio y había escrito en bosnio, pero King respondió en esloveno. En el prompt de la persona solo estaba la palabra inglesa Bosnian; el ámbito lingüístico estrechamente emparentado no estaba delimitado expresamente.
  • Kako si?, Kako je King?, Ko si ti? y Ko stoji iza tebe? no se procesaban como diálogos breves independientes en bosnio. La captura de pantalla de Ko stoji iza tebe? mostraba incluso búsquedas web en lugar de una respuesta directa.
  • El check-in simple notificado consumió alrededor de 7.500 tokens. La ruta de bajo esfuerzo anterior permitía hasta 8.192 tokens de finalización y conservaba varios mensajes antiguos.
9.1.188
  • BLUN reconoció una recaída real ya después de tres respuestas similares, pero dejaba las respuestas desactualizadas completas en la vista del modelo. Por eso, la pista contra el bucle seguía compitiendo con el antiguo estado erróneo.
  • DeepAgents aa8ae718644dac19d7f1cdc3febe2740a79fa058 aporta el patrón de mensajes de sustitución limitados y estables por índice. AnythingLLM prioriza los pares de conversación más recientes y trata el historial como el primer contexto que se puede comprimir.
  • Un wire contenía 42.265.671 bytes, de ellos 25.423.100 bytes de context.append_loop_event. Esto demuestra la carga real de bucles, pero no se presenta como ahorro directo de tokens de solicitud.
9.1.187
  • El manifiesto 9.1.184 publicado en producción llevaba la marca de tiempo 2026-08-26T12:15:06.5196457Z. El parser distribuido solo admitía de una a tres cifras decimales y por eso descartaba todo el manifiesto.
  • Sin un fallback válido, npm pasó a ser la única referencia. Por eso, durante el staging de 9.1.185, la etiqueta npm fue visible brevemente, aunque el manifiesto seguía en 9.1.184.
  • La etiqueta npm se devolvió a 9.1.184. En el manifiesto en vivo solo se corrigió la marca de tiempo, a 2026-08-26T12:15:06.519Z; la versión y la integridad permanecieron sin cambios. Después, tres descargas sin caché y el parser real del cliente confirmaron el manifiesto.
  • SHA256 en vivo tras la reparación: 8ec4eef17da2d92c96b4011c0239f367e5c0779d0f02e1eac61fdfe782d94601. Respaldo: /data2/websites/stage-20260811/blun-chat/public/blun-code-version.json.invalid-timestamp-20260826T125021Z.
9.1.186
  • Tras una compactación completa, el prompt del sistema existente ya no se sobrescribe con datos de contexto locales releídos. Así, su prefijo anterior permanece estable byte a byte y reutilizable para la caché del proveedor.
  • El directorio de trabajo, los archivos AGENTS.md adecuados y los directorios adicionales reciben una huella. Solo ante un cambio real se añade el nuevo estado como mensaje de contexto interno e invisible para el usuario.
  • Los datos de contexto incrustados se escapan antes de la marca interna. Un texto local no puede cerrar por tanto el límite de la marca ni introducir nuevas indicaciones del sistema.
9.1.185
  • Dos perfiles de agentes se desconectaron en torno al momento de la actualización automática. Con independencia de ello, tras pasar correctamente de 9.1.182 a 9.1.183, un tercer perfil se quedó en esa versión y no preparó 9.1.184.
  • En la ruta del código fuente se demostraron dos errores concretos: la TUI terminaba justo después de process.send, sin esperar la confirmación IPC. Además, tras un traspaso exitoso, el launcher solo esperaba a que terminara el nuevo proceso y no configuraba para él ninguna otra vigilancia de actualizaciones.
9.1.184
  • Las llamadas de modelo ordinarias llevaban permanentemente los esquemas de herramientas de GenerateImage y GenerateVideo, aunque el uso de herramientas medido solo contenía una llamada de imagen y ninguna de vídeo entre 3.183 llamadas.
  • 9.1.184 elimina ambos esquemas del conjunto central cargado permanentemente. Una tarea expresa de imagen, vídeo o animación carga solo el esquema realmente necesario en el mismo turno.
  • El mismo camino de selección actúa también cuando llega una tarea de medios durante un turno en curso. Las preguntas de calidad, las comprobaciones de medios y las ideas no vinculantes para más tarde no cargan ningún esquema de generación.
  • Ambas herramientas siguen disponibles mediante ToolSearch. El cambio no elimina ninguna capacidad, sino que traslada los esquemas usados raramente fuera de las llamadas de modelo ordinarias.
9.1.183
  • BLUN King 9.1.183 hace que la entrega automática por Telegram de los medios terminados sea resistente a errores temporales de subida.
  • El cliente solo reintenta ante un número limitado de errores temporales, reconstruye la subida de varias partes en cada intento y se interrumpe de inmediato ante errores permanentes.
  • Los intentos de entrega agotados se registran por separado, sin revelar el token del bot ni suprimir el envío de respaldo normal.
9.1.182
  • Esta versión corrige exclusivamente la actualización automática de una sesión de King en ejecución.
  • Hasta ahora, el launcher establecía BLUN_NO_AUTO_UPDATE=1 en el mismo entorno que usaban tanto el núcleo protegido como la preparación de actualizaciones del proceso padre. Así, el actualizador antiguo del núcleo quedaba correctamente desactivado, pero también el nuevo verificador de actualizaciones del proceso padre terminaba antes de descargar el manifiesto público.
  • 9.1.182 conserva una desactivación establecida expresamente para el proceso padre. La desactivación forzada solo se añade ahora en el arranque del núcleo protegido.
  • Mnemo sigue siendo una configuración interna y local. El paquete público no contiene Mnemo. La entrada aditiva permanece completamente inactiva sin una ruta local de Mnemo y sin una identidad de agente establecida expresamente.
9.1.181
  • Las tareas largas del usuario repetidas de forma idéntica y los IDs de entrega de Telegram duplicados se eliminan exclusivamente de la proyección del modelo; el historial en bruto permanece sin cambios.
  • Un Mnemo-MCP configurado se añade ahora al perfil TUI de King activo, en lugar de quedar limitado a las sesiones del puente de Telegram.
  • Los 413 tests pasaron; las dos pruebas de mutación dirigidas se pusieron en rojo en cuanto se eliminaba la medida de protección correspondiente a cada una.
9.1.180
  • La preparación automática de actualizaciones ya no depende exclusivamente del IPC de TUI-ready posterior. En cuanto se comprueba que el núcleo protegido está cargado, el launcher inicia la preparación aunque esa segunda señal se haya perdido.
  • El límite de seguridad para el traspaso propiamente dicho no cambió: la respuesta en curso, la compactación, la cola de mensajes, las herramientas, los comandos de shell y los comandos de cola siguen impidiendo un reinicio en medio del trabajo.
  • El estado real demostró el error: modo resume, instalación 9.1.177, público 9.1.179, pero solo preparado 9.1.176. El bucle no era por tanto el primer bloqueo, porque la comprobación de inactividad solo actúa después de la preparación.
9.1.179
  • Las simples confirmaciones como ok, ja, danke o perfekt se saltan el broker de memoria personal. Esto ahorra una llamada al broker y evita en esos turnos pobres en contenido hasta 16.384 caracteres de inyección de memoria innecesaria.
  • weiter, los adjuntos, las preguntas, los comandos y los demás mensajes con contenido conservan la ruta de memoria existente entre portales.
  • Un búfer de argumentos construido primero al estilo DeepAgents fue más lento en cuatro de cinco rondas de medición que la concatenación simple. Se descartó por completo y no se publicó.
9.1.178
  • La búsqueda diferida de herramientas reconoce ahora un primer término exacto inequívoco. GetMedia media job status result carga por ello GetMedia, sin recurrir a una suposición semántica amplia. Los nombres cortos ambiguos quedan deliberadamente sin resolver.
  • La cadena de producción de medios divide los nombres de etapa completos en líneas siguientes. El último paso ya no se corta en el borde derecho.
  • El cambio mejora la selección de herramientas y la legibilidad. No modifica ni el modelo de medios ni la calidad de imagen y no afirma ninguna vista previa real de medios.

Mejoras desde 9.1.57

VersiónCambio
9.1.177Las actualizaciones automáticas aplican ahora un modo guardado de continuación o reinicio también cuando no llega el mensaje directo de proceso, y muestran una indicación clara inmediatamente antes del reinicio seguro de la TUI. Los marcadores de posición históricos para argumentos de herramienta compactados se eliminan, tanto si aparecen como JSON compacto, JSON formateado u objeto ya leído, antes de que puedan ejecutarse de nuevo. El historial en bruto y todos los mecanismos de protección existentes de la actualización permanecen sin cambios.
9.1.176Todos los menús de selección de comandos de barra separan ahora las opciones con una línea en blanco y muestran las explicaciones en un segundo color propio y discreto. El componente común da servicio a 20 llamadas de menú; los colores de aviso individuales se conservan.
9.1.175La pista de herramientas repetida en cada solicitud al modelo baja de 1.749 a 825 caracteres. En la medición, esto ahorra alrededor de 231 tokens de entrada estimados por solicitud. Las once obligaciones de comportamiento se conservan; el historial en bruto, los esquemas de herramientas y los archivos permanecen sin cambios.
9.1.174El fragmento relevante de Mistake.md mostrado en cada solicitud al modelo está limitado a 3.000 en lugar de 4.000 caracteres. En 100 solicitudes reales, esto ahorra en promedio alrededor de 253 tokens de entrada estimados; los encabezados seleccionados permanecieron idénticos en los 100 casos. Los archivos completos y el historial guardado permanecen sin cambios.
9.1.173BLUN King reconoce respuestas de texto puro recurrentes a lo largo de varios turnos de Telegram. Tras tres respuestas casi iguales a pesar de nuevas indicaciones del usuario, el agente recibe una única pista interna de corrección, en lugar de volver a emitir una pregunta, lista o espera antiguas. Los mensajes, los procesos y el historial guardado permanecen sin cambios.
9.1.172La actualización automática vuelve a comprobar una sesión en ejecución después de una búsqueda sin resultados al inicio. La siguiente comprobación se realiza tras un intervalo aleatorio de entre 60 y 90 segundos. Así se detectan versiones publicadas más tarde sin reinicio manual. La instalación y el traspaso de la sesión siguen esperando a que haya inactividad total.
9.1.171BLUN King conserva por turno solo los cuatro esquemas de herramienta recargados más recientes en lugar de doce. Las herramientas más antiguas siguen siendo localizables mediante ToolSearch y se recargan al seleccionarlas. Las herramientas del núcleo cargadas permanentemente, el historial guardado y el comportamiento de ejecución permanecen sin cambios.
9.1.170Agrupa los errores actuales de fiabilidad y de flujo de trabajo: las tareas recurrentes conservan la instrucción desmesuradamente grande más reciente; los marcadores de posición de argumentos de herramienta compactados se eliminan de la proyección del modelo; ToolSearch reconoce palabras de búsqueda de memoria naturales, incluida la palabra individual «store»; la vista de bucle recarga el estado de planificación; /update controla el traspaso seguro en inactividad; y /premortem proporciona un análisis de errores visible y estructurado.
9.1.169BLUN King conserva sin cambios la selección exacta de herramientas y la búsqueda estricta de palabras clave anterior. Solo cuando esta búsqueda no da ningún resultado, una segunda ejecución limitada busca términos alemanes e ingleses afines. Los requisitos de nombre con + siguen siendo obligatorios; deben coincidir al menos dos términos significativos y el 75 por ciento de la solicitud. Así, las tres búsquedas de Telegram que realmente fallaron encuentran la herramienta de cola actual, mientras que una solicitud que no encaja sigue terminando sin resultados.
9.1.168BLUN King ya no reemplaza los argumentos antiguos de llamadas de herramienta por un marcador de posición interno que el modelo pueda copiar en una llamada nueva. Las llamadas de marcador de posición ya existentes y sus resultados de error asociados solo se eliminan de la proyección del modelo; el historial de sesión sin cambios se conserva como evidencia.
9.1.167En las tareas planificadas recurrentes, BLUN King 9.1.167 conserva solo una secuencia sin huecos de las secciones de trabajo completas más recientes. Si la siguiente sección más reciente superara el límite de 48.000 caracteres o 24 mensajes, la selección termina en lugar de volver a tomar después secciones pequeñas más antiguas. Así, el contexto y el orden temporal se mantienen coherentes. En un historial en curso medido, el historial proyectado bajó de 32.591 a 16.981 caracteres. Esto ahorra 15.610 caracteres, es decir, alrededor de 3.903 tokens de entrada estimados por solicitud comparable. El historial en bruto, los pasos de la tarea actual y el resumen de compactación permanecen sin cambios.
9.1.166BLUN King 9.1.166 limita las tareas planificadas recurrentes a un contexto de trabajo aislado, en lugar de volver a transmitir toda la conversación del agente principal en cada paso del modelo. La tarea actual, el resumen de compactación más reciente y los pasos de trabajo reales más recientes permanecen disponibles dentro de un límite de 24 mensajes y 48.000 caracteres. El historial guardado, los turnos de usuario normales, los recordatorios puntuales y las rutas de conversación rápidas permanecen sin cambios. En un historial medido, 2.043 pasos de modelo de tareas planificadas recurrentes consumieron en total 298,7 millones de tokens de entrada, en promedio 146.188 tokens por paso.
9.1.165BLUN King 9.1.165 limita el presupuesto de salida de los turnos normales a 24.576 en lugar de 32.768 tokens. Los pasos ligeros conservan su valor límite anterior de 8.192 tokens, los modelos con límites de salida menores conservan esos valores más bajos y una configuración expresa del usuario sigue teniendo prioridad. De 27.049 respuestas medidas, el 99 por ciento permaneció por debajo de 9.970 tokens; doce valores atípicos antiguos alcanzaron exactamente el límite anterior de 32.768 tokens y siguieron calculando cada uno alrededor de seis minutos más.
9.1.164BLUN King 9.1.164 limita el presupuesto de salida de una compactación en ventanas de modelo grandes a 16.384 en lugar de 131.072 tokens. 39 compactaciones exitosas necesitaron como máximo 10.781 tokens de salida. El nuevo marco está un 52 por ciento por encima de este máximo medido y reduce la necesidad posible de salida y caché KV por compactación en un 87,5 por ciento. El historial guardado y los turnos de conversación normales permanecen sin cambios.
9.1.163BLUN King 9.1.163 reemplaza las cargas extensas de skills fuera de los últimos 20 mensajes en la proyección del modelo por una referencia compacta de recarga. Las cargas de skills actuales, pequeñas y no recargables permanecen sin cambios; el historial de conversación guardado no se reescribe. En un caso medido, una carga de skill baja de 87.034 a 424 caracteres proyectados. En cuanto abandona la ventana de trabajo actual, ahorra 86.610 caracteres, es decir, alrededor de 21.653 tokens de entrada estimados.
9.1.162BLUN King 9.1.162 limita las vistas generales grandes del directorio de trabajo en el prompt del sistema repetido a 2.000 caracteres. Las vistas generales pequeñas permanecen sin cambios. En las vistas generales truncadas, una indicación clara sigue remitiendo a la búsqueda completa con Glob, Grep y Read. En un prompt medido, la vista general baja de 3.988 a 1.983 caracteres. Esto ahorra 2.005 caracteres, es decir, alrededor de 501 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.161BLUN King 9.1.161 ya no repite los nombres de las 112 herramientas externalizadas en cada descripción de ToolSearch. La búsqueda por palabra clave, la selección exacta mediante el nombre completo o el nombre corto inequívoco y la carga persistente de los doce esquemas seleccionados más recientemente se conservan. En la representación medida, la descripción repetida baja de 1.984 a 278 caracteres. Esto ahorra 1.706 caracteres, es decir, alrededor de 426 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.160A partir de BLUN King 9.1.160, la proyección del modelo solo protege completamente los doce mensajes más recientes antes de que los resultados de herramienta exitosos más antiguos que contienen exclusivamente texto se reemplacen por una nota de finalización breve. Las salidas de error, los medios, las referencias de archivo guardadas, los doce mensajes más recientes, el historial en bruto y las exportaciones permanecen sin cambios. En una instantánea de sesión, medida de forma estable, se reducen así otros dos resultados de herramienta antiguos. La proyección del modelo baja de 81.800 a 78.402 caracteres. Esto ahorra otros 3.398 caracteres, es decir, alrededor de 850 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.159A partir de BLUN King 9.1.159, los argumentos JSON válidos de llamadas de herramienta finalizadas fuera de los 12 mensajes más recientes se reemplazan en la proyección del modelo por una nota breve. El resultado de herramienta asociado, los 12 mensajes más recientes, las llamadas no finalizadas, los argumentos pequeños o no válidos, el historial en bruto y las exportaciones permanecen sin cambios. En una instantánea de sesión, medida de forma estable, tres argumentos de llamadas de herramienta finalizadas se reducen de 2.849 a 165 caracteres. Esto ahorra 2.684 caracteres, es decir, alrededor de 671 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.158A partir de BLUN King 9.1.158, los simples mensajes de estado que siguen inmediatamente a una respuesta de Telegram finalizada se reemplazan por una nota breve en la proyección del modelo cuando quedan fuera de los 20 mensajes más recientes. La llamada de respuesta enviada y su resultado, los mensajes actuales, los resúmenes tras otras herramientas, los contenidos mixtos, el historial en bruto y las exportaciones permanecen sin cambios. En una instantánea de sesión, medida de forma estable, seis mensajes de estado históricos se reducen en 1.837 caracteres. Esto ahorra alrededor de 460 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.157A partir de BLUN King 9.1.157, las salidas de herramienta adecuadas, exitosas y basadas exclusivamente en texto que quedan fuera de los 20 mensajes más recientes se reemplazan en la proyección del modelo por una nota de finalización breve. Las salidas de error, los medios, las referencias de archivo externalizadas, los 20 mensajes más recientes, el historial en bruto y las exportaciones permanecen sin cambios. En una instantánea de sesión, medida de forma estable, se reducen 43 resultados antiguos. Esto ahorra 9.680 caracteres, es decir, alrededor de 2.420 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.156A partir de BLUN King 9.1.156, las referencias guardadas a mensajes de usuario fuera de los 20 mensajes más recientes ya no repiten su vista previa con principio y fin en cada solicitud al modelo. La marca de restauración, los datos de tamaño, la ruta de archivo legible, los 20 mensajes más recientes, los medios, el historial en bruto, el archivo completo guardado y las exportaciones permanecen sin cambios. En una instantánea, medida de forma estable, se reducen cinco referencias históricas y la proyección del modelo baja de 99.143 a 96.001 caracteres. Esto ahorra otros 3.142 caracteres, es decir, alrededor de 786 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.155A partir de BLUN King 9.1.155, las referencias guardadas a mensajes de usuario se restauran antes de que las proyecciones de texto puedan modificar el hash del mensaje original. Así, las externalizaciones existentes siguen siendo efectivas, en lugar de volver sin que nadie lo note al mensaje completo proyectado. El historial en bruto, las referencias de archivo que se pueden volver a leer, los 20 mensajes más recientes, los medios y las exportaciones permanecen sin cambios. En una instantánea, medida de forma estable, la proyección del modelo baja de 105.810 a 99.143 caracteres. Esto ahorra otros 6.667 caracteres, es decir, alrededor de 1.667 tokens de entrada estimados por cada solicitud con la misma estructura.
9.1.154A partir de BLUN King 9.1.154, las secciones de canal de Telegram dirigidas fuera de los 20 mensajes más recientes se limitan a una vista previa de 500 en lugar de 1.000 caracteres con principio y fin. Los metadatos completos del canal, el principio y el fin del contenido del mensaje, los 20 mensajes más recientes, los adjuntos, el historial en bruto y las exportaciones permanecen sin cambios. En una instantánea medida de forma estable se reducen siete secciones dirigidas históricas adicionales. Esto ahorra 3.500 caracteres, es decir, alrededor de 875 tokens estimados por solicitud repetida.
9.1.153A partir de BLUN King 9.1.153, la proyección de contextos de Telegram históricos conserva los metadatos completos del canal y la etiqueta de cierre del canal. Solo se recorta el contenido del mensaje. Incluso con metadatos reales de Telegram de 161 caracteres, la estructura sigue siendo válida dentro del presupuesto de 250 caracteres. La proyección es idempotente, los canales dirigidos posteriores permanecen sin cambios y un sobre de canal que ya supera el presupuesto sin contenido se transmite sin cambios.
9.1.152A partir de BLUN King 9.1.152, los argumentos de llamadas de herramienta finalizadas abandonan la proyección activa del modelo cuando hay cuatro mensajes más recientes, en lugar de ocho. El historial de sesión en bruto, las llamadas sin respuesta o con formato erróneo, los medios, los resultados de herramienta y los cuatro mensajes más recientes permanecen sin cambios. En una instantánea de sesión recién medida se compactan dos llamadas finalizadas adicionales; frente a 9.1.151, esto ahorra otros 244 caracteres, es decir, alrededor de 61 tokens estimados por solicitud repetida.
9.1.151A partir de BLUN King 9.1.151, los argumentos de llamadas de herramienta finalizadas abandonan la proyección activa del modelo cuando hay ocho mensajes más recientes, en lugar de doce. El historial de sesión en bruto, las llamadas sin respuesta o con formato erróneo, los medios, los resultados de herramienta y los ocho mensajes más recientes permanecen sin cambios. En una instantánea de sesión medida se compactan tres llamadas finalizadas adicionales; frente a 9.1.150, esto ahorra otros 317 caracteres, es decir, alrededor de 80 tokens estimados por solicitud repetida.
9.1.150A partir de BLUN King 9.1.150, la externalización histórica de resultados de herramienta protege completamente los cuatro mensajes más recientes en lugar de los ocho más recientes. Los resultados de herramienta antiguos adecuados conservan una nota de restauración compacta de 600 caracteres y su ruta de origen; el historial en bruto, las salidas guardadas completas, los medios y los cuatro mensajes más recientes permanecen sin cambios. En una instantánea de sesión medida, la ventana de cuatro mensajes externaliza nueve resultados históricos adicionales y, frente a 9.1.149, ahorra otros 6.683 caracteres, es decir, alrededor de 1.671 tokens estimados por solicitud repetida.
9.1.149A partir de BLUN King 9.1.149, la externalización histórica de resultados de herramienta protege completamente los ocho mensajes más recientes en lugar de los doce más recientes. Los resultados de herramienta antiguos adecuados conservan una nota de restauración compacta de 600 caracteres y su ruta de origen; el historial en bruto, las salidas guardadas completas, los medios y los ocho mensajes más recientes permanecen sin cambios. En una instantánea de sesión medida, tres resultados bajan de 4.679 a 1.800 caracteres; esto ahorra otros 2.879 caracteres, es decir, alrededor de 720 tokens estimados por solicitud repetida.
9.1.148A partir de BLUN King 9.1.148, también en el paquete mixto de Telegram más reciente se reducen las secciones de canal marcadas expresamente con addressed=false. Las secciones dirigidas, los medios, el historial en bruto y las exportaciones permanecen sin cambios. En un historial medido, once secciones no dirigidas bajan de 22.691 a 2.750 caracteres; esto ahorra 19.941 caracteres, es decir, alrededor de 4.986 tokens estimados por solicitud repetida.
9.1.147A partir de BLUN King 9.1.147, la microcompactación protege completamente los doce mensajes más recientes en lugar de los veinte más recientes y usa así la misma ventana de restauración que la externalización existente de resultados de herramienta. Los argumentos de herramienta finalizados más antiguos y los resultados de herramienta adecuados solo se reducen en la proyección del modelo; el historial en bruto y las rutas de restauración permanecen sin cambios. En un historial medido, esto ahorra otros 560 caracteres, es decir, alrededor de 140 tokens estimados por solicitud.
9.1.146A partir de BLUN King 9.1.146, los resultados de herramienta más antiguos ya externalizados se limitan en la proyección del modelo a los datos necesarios para la restauración: nombre de la herramienta, número de caracteres y ruta de archivo. El contenido completo permanece sin cambios en el disco, el historial en bruto no se modifica y los doce mensajes más recientes conservan sus notas detalladas. En un historial medido, esto reduce la entrada repetida del modelo en 26.779 caracteres, es decir, alrededor de 6.695 tokens estimados por solicitud.
9.1.145A partir de BLUN King 9.1.145, un stream del proveedor interrumpido se reintenta automáticamente cuando hasta entonces solo ha llegado salida de pensamiento interna. El texto visible y las llamadas de herramienta siguen impidiendo un reintento automático. Los pasos posteriores adaptativos con nivel de pensamiento bajo usan un presupuesto de salida de 8.192 tokens; los primeros pasos, los complejos y los fallidos conservan el presupuesto configurado, y un reintento tras alcanzar el límite de longitud puede aumentarlo. Al continuar una sesión, la indicación de transporte actual del plugin de Telegram ya no aparece como texto de chat en bruto.
9.1.1449.1.144 limita las secciones de Telegram dirigidas fuera de los 20 mensajes más recientes en la proyección del modelo a una vista previa de 1.000 caracteres con principio y fin. Los 20 mensajes más recientes, el mensaje de usuario más reciente, las secciones en el límite exacto, los adjuntos, los metadatos del canal, el historial en bruto y las exportaciones permanecen sin cambios.
9.1.1439.1.143 elimina de la proyección del modelo, en los mensajes más antiguos, la indicación repetida de transporte del plugin de Telegram. El contenido del canal, los metadatos, los adjuntos, el mensaje de usuario más reciente, el historial en bruto y las exportaciones permanecen sin cambios.
9.1.1429.1.142 reduce la vista previa con principio y fin para las partes de canal de Telegram antiguas no dirigidas en la proyección del modelo de 500 a 250 caracteres. Las partes de canal dirigidas, el mensaje de usuario más reciente, los adjuntos, el historial en bruto y las exportaciones permanecen sin cambios.
9.1.1419.1.141 elimina en la proyección del modelo los argumentos de llamadas de herramienta finalizadas más antiguas ya a partir de 32 tokens estimados. Los resultados de herramienta conservan su umbral anterior; los mensajes nuevos y el historial en bruto permanecen sin cambios.
9.1.1409.1.140 limita por defecto a 4.000 caracteres el recordatorio de Mistake basado en relevancia en la proyección del modelo. Los archivos completos de Mistake, el historial en bruto y las exportaciones permanecen sin cambios.
9.1.1399.1.139 limita las partes de canal de Telegram antiguas no dirigidas en la proyección del modelo a una vista previa de 500 caracteres. El mensaje de usuario más reciente, las partes dirigidas, los adjuntos, el historial en bruto y las exportaciones permanecen completos.
9.1.1389.1.138 conserva de cada tarea cron recurrente solo el aviso de activación más reciente en la proyección del modelo. Los recordatorios puntuales, las tareas diferentes, el historial en bruto y las exportaciones permanecen sin cambios.
9.1.1379.1.137 solo protege por completo los doce mensajes más recientes frente a la externalización de salidas de herramienta más antiguas. Los resultados completos siguen siendo restaurables mediante el historial en bruto y la ruta de origen.
9.1.1369.1.136 conserva en la proyección del modelo solo la indicación dinámica más reciente de Mistake.md. Las selecciones más antiguas se conservan completas en el historial en bruto y en las exportaciones.
9.1.135BLUN King 9.1.135 mantiene el runtime gestionado de Node.js en primer lugar del PATH en el proceso de reemplazo y en todas las herramientas hijas. Así, comandos como node y npm usan el mismo runtime compatible que la TUI, en lugar de recurrir a una instalación del sistema más antigua.
9.1.1349.1.134 limita los mensajes de grupo de Telegram no dirigidos en la proyección del modelo a una vista previa de 2.000 caracteres con principio, fin y longitud original conservados. Los mensajes directos y el historial guardado permanecen completos.
9.1.1339.1.133 selecciona de la Mistake.md local del proyecto y de la compartida como máximo cinco entradas completas relevantes dentro de un presupuesto común de 6.000 caracteres. Las fuentes completas y las rutas de almacenamiento se conservan.
9.1.1329.1.132 mantiene activo el prompt base del sistema reducido con 4.850 caracteres tras la inicialización generada. Esto ahorra por solicitud 18.259 caracteres, es decir, alrededor de 4.565 tokens estimados, sin eliminar instrucciones ni herramientas.
9.1.1319.1.131 elimina dos copias de reglas antiguas de la proyección del modelo en cuanto existen las contrapartes determinantes. El prompt estándar baja así en 1.010 caracteres, es decir, alrededor de 253 tokens estimados por solicitud.
9.1.1309.1.130 reemplaza fuera de los últimos 20 mensajes el texto explicativo de pasos de herramienta antiguos completamente finalizados por una indicación breve. Las llamadas de herramienta, los resultados, el historial en bruto y las exportaciones se conservan completos.
9.1.1299.1.129 elimina los textos de vista previa de los resultados de herramienta antiguos ya externalizados. La ruta y los datos de tamaño permanecen visibles; el contenido completo se conserva en el archivo original o en el archivo privado.
9.1.1289.1.128 limita la caché persistente de esquemas de herramienta recargados a las doce herramientas seleccionadas más recientemente. Las herramientas desplazadas siguen siendo localizables de inmediato mediante ToolSearch.
9.1.1279.1.127 acorta el catálogo repetido de ToolSearch. Las herramientas con nombre inequívoco aparecen con su selector corto; los espacios de nombres MCP completos solo se conservan cuando hay conflictos de nombres.
9.1.1269.1.126 selecciona de forma determinista, del archivo de errores de todo el runtime, como máximo cinco secciones que encajan con la conversación actual. La proyección está limitada a 6.000 caracteres y no necesita ninguna llamada adicional de modelo o red.
9.1.1259.1.125 añade el comando de Telegram de solo lectura /status para usuarios vinculados. Nombra el estado del equipo, la versión, el proceso y la cola, sin mostrar IDs de chat, rutas, secretos ni contenidos de mensajes.
9.1.1249.1.124 corrige los colores de marca intercambiados en el símbolo compacto de BLUN bajo el campo de entrada. Los valores de estado, el nombre del perfil y la persona permanecen sin cambios.
9.1.1239.1.123 elimina de la proyección del modelo los argumentos JSON grandes de llamadas de herramienta finalizadas más antiguas. El nombre, el identificador, el resultado, el historial en bruto y las exportaciones permanecen completos.
9.1.1229.1.122 carga la directriz de diseño completa solo en el trabajo visual mediante la herramienta de skills. Las solicitudes no visuales reciben un contrato de activación compacto; al mismo tiempo, las salidas de texto puro más antiguas se externalizan de forma más efectiva.
9.1.1219.1.121 limita el tamaño total de las salidas de texto puro más antiguas de herramientas. Los resultados adecuados se archivan de forma privada y se reemplazan en la proyección del modelo por referencias de archivo legibles.
9.1.1209.1.120 externaliza las respuestas grandes del asistente más antiguas en archivos de sesión privados. Los últimos 20 mensajes, las cadenas de herramientas y el historial en bruto completo se conservan.
9.1.1199.1.119 envía en cada paso del modelo solo una pequeña selección de skills usados con frecuencia. Todos los demás skills siguen siendo localizables mediante la herramienta de skills por nombre o propósito.
9.1.1189.1.118 mantiene estable la marca de tiempo de la sesión en el prompt del sistema durante una sesión en curso. Las partes del prompt sin cambios pueden así seguir reutilizando la caché de prefijo del proveedor.
9.1.1179.1.117 mantiene inmediatamente disponibles las cuatro herramientas principales de medios y carga la comprensión de imagen y vídeo, la sincronización de vídeo y la sincronización de movimiento de labios solo bajo demanda mediante ToolSearch.
9.1.1169.1.116 añade una compactación proactiva a partir de alrededor de 128.000 tokens de entrada estimados en un límite de paso seguro. La compactación usa un prompt del sistema propio reducido; los resultados grandes de Read usan su ruta de origen existente.
9.1.115Las sesiones continuadas reconstruyen el prompt del sistema del perfil actual, de modo que las instantáneas de prompt desmesuradamente grandes y desactualizadas no persisten a través de los reinicios. Las vistas generales grandes del directorio de trabajo se limitan; los archivos completos siguen disponibles mediante Glob, Grep y Read.
9.1.114La entrega de Telegram trata EPERM de Windows ahora como indicio de un proceso TUI o poller en ejecución, en lugar de desviar los mensajes de la sesión visible. ToolSearch confirma una herramienta ya cargada con coincidencia exacta de nombre, en lugar de informar erróneamente que falta una herramienta que solo se recargaría bajo demanda.
9.1.113Las herramientas de Telegram conservan al arrancar una ruta de respaldo dentro del mismo runtime, por si el registro gestionado de plugins falta temporalmente.
9.1.112Los mensajes de usuario grandes y antiguos se archivan fuera de la ventana de trabajo actual; el historial en bruto completo sigue estando disponible.
9.1.111Los turnos de Telegram con adjuntos reciben download_attachment automáticamente. En los turnos normales, la herramienta permanece externalizada en ToolSearch, de modo que se conserva la carga de esquemas reducida.
9.1.110Los reintentos tras una sobrecarga del proveedor respetan la indicación Retry-After del servidor. La configuración automática de ripgrep descarga los archivos fijados de la versión 15.0.0 de la publicación oficial de ripgrep y comprueba sus sumas SHA-256 antes de la instalación.
9.1.109La versión 9.1.109 mantiene permanentemente en la solicitud al modelo solo las nueve herramientas sobre las que recayeron más del 98 por ciento de las 3.183 llamadas de herramienta medidas. Todas las demás herramientas siguen siendo localizables mediante ToolSearch y están disponibles tras la primera carga durante el resto de la sesión. Así baja la carga de esquemas en cada paso de modelo normal, sin eliminar ninguna herramienta ni modificar la vía rápida para respuestas de Telegram y resultados de medios pendientes.
9.1.108Las indicaciones del sistema idénticas inyectadas repetidamente solo se fusionan en la proyección del modelo. Las indicaciones modificadas y el historial guardado completo se conservan.
9.1.107Los errores del proveedor se muestran en un lenguaje comprensible para el cliente; los códigos de error internos y las notas de soporte no aparecen. /help ofrece una lista de comandos navegable con las teclas de flecha y abre con la flecha derecha o la tecla Intro una descripción detallada del comando seleccionado.
9.1.106Los perfiles de agente pueden excluir herramientas por nombre. Las exclusiones actúan también tras una recarga dinámica; los subagentes estándar no envían mensajes de Telegram al margen del agente principal.
9.1.105La versión 9.1.105 añade TaskUpdate para agentes en segundo plano en ejecución. King transmite instrucciones adicionales en el siguiente paso de modelo seguro al mismo agente activo, sin detenerlo ni iniciar otro agente. Las tareas desconocidas y ya finalizadas, las tareas de shell y los agentes que ya no aceptan actualizaciones se siguen rechazando como hasta ahora.
9.1.104La versión 9.1.104 deja que los comandos de shell en primer plano se ejecuten hasta su final normal también con salidas muy grandes. King escribe hasta 16 MiB de forma continua en el registro privado de la tarea, descarta las salidas que superan esa cantidad y notifica el código de salida real, en lugar de finalizar el proceso por la cantidad de salida. Las salidas pequeñas, las tareas en segundo plano, los límites de tiempo y las interrupciones manuales permanecen sin cambios.
9.1.103Tras interrupciones temporales del proveedor, los miembros del enjambre se reanudan como máximo dos veces con el mismo ID de agente. HTTP 429 conserva su regla separada de sobrecarga; los errores definitivos y las interrupciones manuales no se reintentan automáticamente.
9.1.102Tras errores temporales del proveedor, los agentes individuales delegados se reanudan como máximo dos veces a partir de su historial persistente. Los errores permanentes y las interrupciones manuales siguen siendo definitivos.
9.1.101Los mensajes de usuario desmesuradamente grandes se respaldan localmente y se reemplazan en el contexto del modelo por una vista previa limitada con ruta legible. El historial original completo y los medios se conservan.
9.1.100Las búsquedas de contenido Grep limitadas finalizan ripgrep después de la página solicitada y una línea de vista previa adicional. Los recuentos de aciertos, las búsquedas sin límite y las listas de archivos ordenadas por fecha de modificación permanecen completos.
9.1.98King puede compactar proactivamente una sección de trabajo finalizada a partir de 128.000 tokens estimados. Por debajo del umbral, el esquema de la herramienta queda totalmente fuera del prompt del modelo; la compactación usa la transición de paso segura existente.
9.1.97La descripción de la herramienta TodoList cargada permanentemente bajó de 2.238 a 996 caracteres. La planificación en varios niveles, los seis estados de tarea, las notificaciones de progreso honestas, las consultas, el vaciado y el modo de plan separado permanecieron protegidos.
9.1.96El prompt base del sistema cargado permanentemente bajó de 23.109 a 4.850 caracteres. La identidad, la persona y el alma, el idioma de respuesta, los límites de trabajo y permisos, el traspaso de la compactación, el entorno de ejecución, AGENTS.md y las skills permanecieron protegidos.
9.1.95La descripción de la herramienta Write cargada permanentemente bajó de 2.532 a 1.541 caracteres. La delimitación frente a Edit, los contenidos literales, los finales de línea, el límite de 500 líneas, la excepción de un solo archivo y la continuación atómica con comprobación de líneas y SHA-256 permanecieron protegidos.
9.1.94La descripción de la herramienta Glob cargada permanentemente bajó de 1.495 a 1.006 caracteres. La ordenación, los archivos ignorados y sensibles, los patrones recursivos, los archivos que empiezan por punto, las expansiones de llaves y el límite de 100 aciertos permanecieron protegidos.
9.1.93La descripción de la herramienta Edit cargada permanentemente bajó de 1.537 a 1.144 caracteres. Leer antes de modificar, las sustituciones exactas, las sustituciones múltiples, el tratamiento de CRLF y el límite de 500 líneas permanecieron protegidos.
9.1.92La descripción de la herramienta Agent cargada permanentemente bajó de 2.061 a 1.153 caracteres. El contexto separado, la continuación, los límites de tiempo y la delegación paralela se conservaron.
9.1.91La descripción de la herramienta Read cargada permanentemente bajó de 2.391 a 1.648 caracteres. La paginación, la protección de secretos, el reenvío de medios, el formato de líneas y el comportamiento de CRLF se conservaron.
9.1.90La descripción de la herramienta Bash cargada permanentemente bajó de 5.003 a 1.834 caracteres. El contrato del runtime, las tareas en segundo plano, las herramientas de archivo y los límites de seguridad se conservaron por completo.
9.1.89Al llegar al límite interno de 1.000 líneas, las lecturas de archivo paginadas indican el siguiente line_offset exacto; el final del archivo y los fragmentos deliberadamente más pequeños permanecen sin cambios.
9.1.88BLUN King 9.1.88 activa la compactación pequeña y sin pérdidas a tiempo antes de la compactación completa. Los resultados de herramienta grandes más antiguos y los argumentos de herramienta finalizados abandonan antes la vista del modelo; el historial guardado completo se conserva.
9.1.87Una respuesta HTTP 429 marcada expresamente como reintentable respeta Retry-After y recibe como máximo dos reintentos automáticos; los demás errores siguen siendo visibles de inmediato.
9.1.86Las salidas grandes de herramienta mantienen visibles, dentro del mismo presupuesto de vista previa, 1.000 caracteres del principio y la misma cantidad del final; una marca exacta indica el número de caracteres omitidos.
9.1.85Los resultados de herramienta basados en texto por encima de 12.000 caracteres se guardan completos en un archivo local privado; las solicitudes al modelo posteriores conservan solo un presupuesto de vista previa de 2.000 caracteres y la ruta legible.
9.1.84La compactación completa procesa los historiales más antiguos en etapas cronológicas de 64.000 tokens de entrada estimados como máximo; el límite de seguridad fijo y el archivo privado completo permanecen sin cambios.
9.1.83La microcompactación reemplaza, solo en la vista del modelo, los argumentos grandes de llamadas de herramienta finalizadas más antiguas por una marca JSON válida; el verificador de sesión notifica el ahorro estimado sin mostrar contenidos.
9.1.82El verificador de solo lectura notifica los esquemas de herramienta seleccionados y retenidos, los motivos de supresión y el número estimado de tokens de esquema evitados.
9.1.81Un verificador de solo lectura incluido resume los pasos del proveedor, las llamadas de herramienta, los tokens, las compactaciones, los errores y las salidas externalizadas, sin revelar prompts ni rutas privadas.
9.1.80Los resultados de herramienta grandes reciben una telemetría de externalización sin contenido; el contexto aislado de subagentes, los planes legibles por máquina y los traspasos transferibles están protegidos por tests de regresión.
9.1.79Los puntos de control persistentes fijan los registros de historial finalizados antes de los pasos del proveedor y antes de la finalización de un worker, de modo que el trabajo finalizado puede volver a leerse tras una reanudación.
9.1.78La compactación completa archiva las partes de historial desplazadas antes de reemplazarlas por un resumen; el resumen contiene la ruta de archivo legible.
9.1.77Cuando hay presión de contexto, la microcompactación reduce los resultados de herramienta grandes más antiguos y conserva al mismo tiempo el historial guardado completo.
9.1.76Las tareas de imagen, vídeo y voz pendientes sobreviven a la compactación y a las preguntas de seguimiento rápidas; los mensajes de Telegram permanecen en orden FIFO sin errores de ocupado engañosos.
9.1.75Las conversaciones cortas de Telegram procesan solo el mensaje sin respuesta más reciente, mientras que los intercambios de texto finalizados se conservan como contexto de idioma.
9.1.74Las rutas de Telegram guardadas restauran los IDs de grupo pasados accidentalmente sin signo menos; Ctrl+S puede controlar un turno realmente en ejecución.
9.1.73Los mensajes de Telegram y de bucle ya no inician un segundo turno durante el trabajo activo; Escape y Ctrl+C pueden seguir cancelando el turno activo.
9.1.72Ocultar una nota de actualización solo suprime la versión ofrecida en ese momento; las publicaciones más nuevas vuelven a aparecer en el arranque normal con king.
9.1.71Los despertadores de bucle llegan correctamente a la cola, el poller de Telegram se reclama atómicamente, las herramientas centrales de archivo y medios permanecen disponibles de inmediato y Context7 ya no se inicia automáticamente.
9.1.69Los MCP estándar se configuran, Telegram alcanza un punto de entrega FIFO protegido, Escape y Ctrl+C cancelan de forma fiable el trabajo activo y la vista general de MCP oculta las rutas internas.
9.1.68Cuando hay inactividad, los mensajes de Telegram activan el procesamiento FIFO, los mensajes directos y de grupo conservan su orden de entrada y la continuación oculta los marcos internos de Telegram.
9.1.67El skill estándar venture-flywheel añade una base UVF puramente contractual con confianza de proyecto determinista y obligaciones de aprobación para acciones externas.
9.1.66/curiosity y /scout realizan investigaciones de oportunidades limitadas y de solo lectura con evidencias, contraevidencias y un criterio de interrupción.
9.1.65Escape y Ctrl+C cancelan de forma fiable las compactaciones automáticas, un ancla de pantalla estable evita pies de página dobles y la nota de bucle está alineada con el contenido del chat.
9.1.64El historial de sesión basado en disco, las herramientas y skills recargadas, un vigilante de inactividad del proveedor de 120 segundos, el ritmo de bucle correcto, Telegram en orden FIFO, los paquetes Linux y el reconocimiento de idioma bosnio se añadieron conjuntamente.
9.1.58–9.1.63Esta serie de versiones agrupó trabajos sobre sesiones, Telegram, plataformas y rendimiento. Como cierre llegaron esquemas de herramienta reducidos bajo demanda, listas de skills compactas, skills de primer uso restauradas y un control de inventario de paquetes contra eliminaciones no planificadas.

Mejoras anteriores

VersiónCambio
9.1.53/idea publica su plan de tareas antes del primer trabajo, comprueba las acciones salientes en cada llamada de herramienta y exige para cada paso un estado final honesto.
9.1.52Las sesiones continuadas abren directamente la carpeta de trabajo guardada. La conversación y el estado activo de /loop se restablecen conjuntamente en el rearranque.
9.1.51Los bucles trabajan como despertadores autónomos, /idea desarrolla y edita planes propios, Telegram puede desencadenar comandos de trabajo y los estados de medios y de inicio se muestran con más claridad.
9.1.50Las imágenes locales o recibidas por Telegram se pueden animar como vídeos MP4 reales. Las ventanas de contexto grandes reciben un presupuesto de salida válido; la barra de medios muestra estados más claros y rutas clicables.
9.1.49Las imágenes de figuras de fantasía adultas en bañador siguen estando permitidas dentro de límites claros. Las tareas de imagen finalizadas pueden usarse como imagen inicial para vídeos; las consultas exitosas de GetMedia no generan tarjetas repetidas.
9.1.48La barra de medios unificada agrupa las tareas de medios directamente sobre el campo de entrada. Los porcentajes solo aparecen con un valor medido real del proveedor; en caso contrario, muestra la fase y el tiempo de ejecución.
9.1.47El registro de solicitudes distingue entre conversaciones y compactación y recoge la selección de herramientas y el motivo de supresión, sin cambiar el comportamiento de las herramientas.
9.1.46Los bucles entienden indicaciones de tiempo naturales, las muestran durante la entrada, admiten intervalos libres y liberan la selección de texto normal en el terminal fuera de la vista de historial.
9.1.45El progreso de compactación en curso aparece solo en la barra de estado inferior, en lugar de aparecer además como segunda línea en el chat.
9.1.44Reempaquetado completo de la 9.1.43 aprobada, para que también las versiones 9.1.43 instaladas al principio reconozcan de forma segura la actualización.
9.1.43Base de protección completa de la 9.1.40 con diagnóstico de transporte, notas de actualización visibles y los comandos de consola /loop, /goal y /output-style.
9.1.40Vigilantes de turno para llamadas largas o que fallan repetidamente; auto-hash tras escritura de varias partes con comprobación de relectura del archivo guardado.
9.1.39Los archivos largos se escriben en continuaciones. Cada continuación retoma la escritura en el final realmente escrito; el número de líneas, el SHA-256 y los límites de los fragmentos se comprueban y se muestran.
9.1.38Los argumentos de herramienta degenerados o truncados se reconocen. Un archivo incompleto se rechaza con mensaje de error, en lugar de considerarse silenciosamente terminado.
9.1.37Tras un cambio de Node, BLUN comprueba los módulos nativos con una consulta SQLite real y reconstruye better-sqlite3 si es necesario.
9.1.36Las respuestas vacías del modelo se tratan según la causa: un presupuesto de salida demasiado escaso se amplía, un stop vacío se repite exactamente una vez. Las indicaciones del sistema y las inyecciones no pueden desencadenar una respuesta de Telegram.
9.1.35La compactación en varios niveles muestra el nivel y la ocupación real de la ventana del modelo, por ejemplo 2/~10 · 90 %.
9.1.34El contexto activo se compacta por etapas: primero las partes más antiguas, y cada llamada al compactador por debajo del límite del modelo.
9.1.33Base para el runtime automático de Node y la reparación posterior de módulos nativos tras un cambio de runtime.

Adendas y lagunas de documentación pendientes

Comparación del 17 de septiembre de 2026: en el rango de 9.1.33 a 9.1.597 hay 521 versiones en el directorio npm. Un número que falta no es automáticamente una publicación que falta: algunas versiones no figuran en el directorio actual o fueron retiradas. En cuatro versiones publicadas, los detalles exactos de los cambios siguen sin aclarar. No se inventan cambios para cubrirlos.

9.1.567: detalles de los cambios pendientes de aclarar

Publicado el 6 de septiembre de 2026 a las 22:42 UTC. El valor SHA-512 del paquete coincide con el valor de integridad publicado en npm. El paquete no contiene ningún CHANGELOG.md; su README todavía indica 9.1.566 en el comando de instalación. De ello no se puede derivar de forma fiable la diferencia con 9.1.566. Esta laguna de documentación permanece expresamente abierta.

9.1.550: detalles de los cambios pendientes de aclarar

Publicado el 2 de septiembre de 2026 a las 07:19 UTC. El valor SHA-512 del paquete coincide con el valor de integridad publicado en npm. El paquete no contiene ningún CHANGELOG.md y en el material comprobado no se encontró ninguna evidencia de cambio específica de la versión. Esta laguna de documentación permanece expresamente abierta.

Adenda a la 9.1.536

Los siguientes datos proceden del paquete publicado el 1 de septiembre de 2026, cuya integridad se ha verificado:

  • Las tareas continúan más allá de las respuestas privadas de Telegram. Tras mensajes directos almacenados en búfer, King continúa el trabajo con un paso adicional limitado, a menos que el usuario lo pause o lo detenga expresamente.
  • Las consultas de estado breves no interrumpen el flujo de trabajo en curso.
  • Cuando se agotan los reintentos tras respuestas de pensamiento vacías, King reduce el esfuerzo de pensamiento, en lugar de dejarlo sin cambios en intentos posteriores.
  • Más esquemas de herramienta recargados siguen disponibles; los mensajes solo se externalizan cuando el espacio disponible en el historial empieza a escasear.
  • Se incluyen la regla de progreso comprobada para TodoList y una ruta de inicio de una sola línea para God Mode con Swarm.

Adenda a la 9.1.99

La documentación de funciones ya existente describe la externalización conjunta de resultados de herramienta consecutivos de solo texto: si la pila supera los 12.000 caracteres, los resultados grandes adecuados se guardan de forma privada. En el contexto del modelo quedan referencias legibles; el historial en bruto y los medios se conservan. La entrada de versión que faltaba hasta ahora remite ya expresamente a esta función.

9.1.70: detalles de los cambios pendientes de aclarar

Publicado el 24 de agosto de 2026 a las 15:56 UTC. El valor SHA-512 del paquete coincide con el valor de integridad publicado en npm. El paquete no contiene ningún CHANGELOG.md; las descripciones de funciones existentes no evidencian ninguna diferencia inequívoca con 9.1.69. Esta laguna de documentación permanece expresamente abierta.

9.1.57: detalles de los cambios pendientes de aclarar

Publicado el 23 de agosto de 2026 a las 07:28 UTC. La versión apareció hasta ahora solo como punto de partida de un encabezado colectivo. No se asigna ninguna evidencia de cambio propia y específica de la versión en el material comprobado. Esta laguna de documentación permanece expresamente abierta.

El CHANGELOG.md contenido en el paquete npm inmutable 9.1.597 termina en 9.1.594. Las notas añadidas sobre 9.1.595 a 9.1.597 están en esta página. El paquete publicado no se reescribió posteriormente con el mismo número de versión.

9.1.41 y 9.1.42 están retiradas

No instalar

Estas dos versiones se ramificaron accidentalmente de 9.1.38 en lugar de 9.1.40. Por ello faltaban la continuación de escritura, el auto-hash y los vigilantes de turno. Ambas versiones npm están marcadas como obsoletas; latest y next nunca apuntaron a ellas. 9.1.43 contiene sus cambios previstos sobre la base de protección completa.

Actualizar y comprobar

king update
blun --version

Tras la instalación de 9.1.599, la salida de versión debe mostrar 9.1.599. Las actualizaciones desde 9.1.597 y desde la versión local 9.1.598 a través de las fuentes de actualización públicas están comprobadas. Una consola ya en ejecución solo carga el código nuevo después de reiniciarse. Después, comprueba también /version en ella.