Releases

Cada release de Korvun trae binarios firmados para seis plataformas (Linux, macOS, Windows × x86-64, ARM64), y desde la v0.4.0 también las apps de escritorio: cada artefacto está cubierto por un manifiesto de checksums firmado con cosign, y cada uno de los seis archivos headless trae además un SBOM; las apps de escritorio no lo traen hoy. Cómo descargar y verificar está en la guía de instalación.

Todas las releases viven en GitHub: github.com/Sebastian197/korvun/releases

La historia hasta hoy

Release	Qué trajo
v0.16.1	Release actual — la Beta (patch) — una release de CURAS con una superficie nueva: korvun intent bind --grant ata un grant firmado a un enlace de ejecución, así que la delegación atenuada que la v0.16.0 entregó implementada, probada e inalcanzable pasa a ser algo que un operador puede poner en el camino de una ejecución — y un inicio bajo ella sella config_generation 0, ninguna cláusula consultada, con un grant_chain que nombra el grant. La cura grave: cuatro escritores pagaban la cadencia de retención DESPUÉS de su propio commit y devolvían su error, de modo que una escritura durable se reportaba a sí misma como un rechazo — y en el aparcamiento era lo peor posible, porque el id de la aprobación se perdía, el ejecutor leía un rechazo y escribía una SEGUNDA fila de actions mientras la PENDIENTE esperaba a una persona a la que nadie iba a avisar. Más SEIS fichas cerradas — el error determinista de la purga que se publicaba como la única clase TRANSITORIA, GetApprovalByAction devolviendo el error crudo del driver donde cada puerta hermana responde con una clase nombrada, korvun approvals list ocultando una fila con un estado fuera de los cinco que conoce (corrupción disfrazada de ausencia), una lista de pendientes que tiraba el id que su propio godoc prometía, un rechazo pintando un recibo no acuñado bajo un título que afirma uno sellado, y la forma del recibo saliendo de TypeScript para que acortar el id acuñado ya no pueda romper la pantalla con seis paquetes Go en verde — más un HALLAZGO que ninguna ficha describía, un id estricto juzgado en el almacén por una sola pregunta compartida en tres puertas, y una guarda de CI que mantiene el CLI de Wails emparejado con su librería. La ficha del propio director sobre ese hallazgo, que veía el mismo síntoma EN LA PANTALLA, sigue abierta: si tres puertas de servidor cierran su mitad es adjudicación suya, no un hecho que esta release reclame. Límites conocidos, sin suavizar: re-atar SIN la bandera sigue chocando con el índice único, así que no hay camino de vuelta a la cláusula de configuración desde la línea de comandos; no existe comando que reemplace ni liste todos los enlaces de un (actor, canal); ninguna pasada externa corrió contra este tag — sin créditos; y ningún modelo real ha recorrido una delegación de punta a punta.
v0.16.0	la Beta (minor) — la pieza 3 entera: un NOMBRE verificado, un PROPÓSITO firmado y una AUTORIDAD firmada detrás de cada efecto que pide un modelo. Cada puerta de entrada acuña una credencial autenticada opaca justo donde su propia autenticación triunfa, y el coordinador la convierte en evidencia de identidad firmada que se escribe en la misma transacción que la acción; una intención es un contrato firmado y versionado con su propio ciclo de vida; los grants de autoridad van firmados y solo pueden atenuar, con presupuestos compartidos a lo largo de una cadena. Bajo un perfil que lo pida — authority.mode: "strict", apagado por defecto — StartAuthorization es la frontera de confirmación duradera: verifica la evidencia y el alcance actuales, debita la intención y cada grant, registra la prueba de inicio firmada y, para una petición aprobada, reclama sus parámetros, todo a la vez, y solo un inicio confirmado entrega al coordinador una credencial de invocación. El documento de aprobación gana el bloque AUTORIDAD: quién pidió, bajo qué contrato, por qué cadena de principales, y el presupuesto que quedaba CUANDO SE APARCÓ LA PETICIÓN — una instantánea firmada que se verifica en cada lectura, no un contador en vivo. Trae un CAMBIO DE COMPORTAMIENTO que hay que leer antes: con el modo estricto encendido, read_file, http_fetch y webhook_call pasan a ser de mundo cerrado y solo arrancan bajo términos que enumeren los recursos, las etiquetas de datos y los destinos que pueden tocar — y el alcance es de la INTENCIÓN, así que cualquier operación sin analizador registrado se rechaza también. Un arranque no estricto sobre un perfil activado se rehúsa por su nombre, imprimiendo el digest que hace falta para arrancarlo. Los problemas conocidos están en las notas, sin suavizar: ninguna puerta pública ata un grant firmado a un enlace de ejecución, así que la delegación está implementada y probada pero no es alcanzable desde el CLI; los fichados de la v0.15.2 siguen todos abiertos; y ninguna pasada externa juzgó este tag — sin créditos —, así que ninguna lectura adversarial, interna o externa, cubre el árbol que nombra.
v0.15.1	la Beta (patch) — el parche que cura los tres P1 de la decimoséptima pasada externa y acota lo que la ventana puede afirmar. El claim de la aprobación vuelve a leer los parámetros purgados dentro de su propia transacción y se niega si la purga no se sostuvo; cada celda que el claim lee tiene una sola clase de error, separando un almacén que no contestó de una fila que no convierte; webhook_call solo llama éxito a un 2xx del receptor, y una conexión que nunca se obtuvo cierra FAILED; las puertas de aprobaciones y el /message de la consola contestan solo a un par en loopback, con nombre propio y sin opción de apagarlo; un recibo sella una marca nombrada en vez de una referencia vacía cuando la fila de la aprobación no se puede usar, y receipt verify y ledger check rechazan ese recibo por su nombre. En la ventana, solo una respuesta que la pantalla pueda probar que es de ESTA acción pinta una ejecución: el digest debe ser IDÉNTICO al que envió, el recibo acuñado y el resultado una cadena no vacía, y una respuesta rechazada con un campo del tipo equivocado se rechaza entera. Corrige además lo que el proyecto AFIRMABA — el digest que viaja desde la ventana, la narración de la ceremonia de aprobaciones, la promesa del SBOM acotada a los seis archivos headless — y añade una guarda para que las cinco afirmaciones de release actual nombren la misma release que releaseFacts.tag. Los problemas conocidos quedan fichados para la v0.15.2 en las notas de release, sin suavizar — incluido que el consumo único sigue dando una segunda ejecución frente a una restauración confirmada después del claim mientras la acción sigue APPROVED, y que el texto de la re-lectura tras un params_digest_mismatch dice que la ventana no decidió lo que sí decidió.
v0.15.0	la Beta (minor) — el sí humano, en la ventana: la quinta etapa de la Execution Trust Layer, y la que trae las aprobaciones. Son opcionales: con approvals.enabled activado, una acción irreversible bajo techo acotado se APARCA como petición hasta que una persona la decide —en la ventana de escritorio o con el CLI del operador— o hasta que caduca (TTL por defecto, una hora), contra el mismo almacén, los mismos cinturones y el mismo claim que consume una vez los parámetros guardados — un consumo con dos límites conocidos en la v0.15.0: un trigger que restaura los parámetros dentro de la propia transacción del claim lo rompe (corregido en master, sale en la v0.15.1), y otra conexión que los vuelva a escribir después de que el claim confirme, mientras la acción siga APPROVED, seguida de una segunda ejecución, vuelve a disparar el efecto (fichado para la v0.15.2). Si el aparcamiento falla, o la procedencia de la petición no se puede resolver, cae cerrada a la misma denegación. Sin esa opción esa acción se deniega con approval_unavailable, como desde v0.13.0; ninguna release anterior podía aparcarla ni decidirla. La petición se lee como un documento, no como un diálogo: el digest impreso en ocho grupos con la línea que avisa de que un solo carácter distinto lo convierte en otro digest, la operación, la clase de efecto dicha con todas las letras (write_irreversible — irreversible, no documented undo), los parámetros literales, el origen, la ley exacta que exigió la aprobación y la caducidad nombrada dos veces, relativa y absoluta. Aprobar se ARMA reteclando los seis últimos caracteres del digest y es el botón pequeño; Rechazar es el grande y no exige ceremonia. Aprobar ejecuta EXACTAMENTE lo que el digest sella, y el claim purga los parámetros guardados, dentro de esos mismos dos límites; rechazar cierra la acción aparcada con su propio recibo sellado y no entrega nada. Cada decisión deja un recibo firmado en la cadena. Los problemas conocidos quedan fichados para la v0.15.1 en las notas de release, sin suavizar — incluido que las curas de clase viajan revisadas por una sola pasada interna que no llegó a ver sus propias curas.
v0.14.0	la Beta (minor) — el libro de actas y los recibos verificables: la cuarta etapa de la Execution Trust Layer. Cada desenlace terminal de una acción — denegada, sombreada, exitosa o fallida — deja un recibo canónico firmado con Ed25519 en una cadena hash de solo-añadir, nacido en la MISMA transacción que el desenlace (la atomicidad rige DENTRO del store; un efecto externo completado justo antes de un cierre terminal fallido es una ventana documentada hasta la etapa 6 — véase la errata de v0.14.0); los resultados crudos jamás tocan el disco — solo digests. El operador re-juzga el libro offline, cada fallo que juzga la escalera nombrado (un recibo cuyos bytes almacenados no parsean se rechaza con el error de lectura y sin nombre de escalera): korvun receipt verify, korvun ledger check (una falsificación que deja el perfil inconsistente, nombrada en su primer check roto, el recibo borrado de DENTRO de la cadena denunciado por su hueco con su posición) y korvun receipt rotate-key — cada era de la cadena verifica con la clave de su era. El límite se confiesa en cada línea pública: tamper-evident, jamás «immutable». Desde R14 la confesión nombra CUATRO puntos ciegos, tres de ellos verificados por ejecución — un corte de cola, una cadena re-firmada con una clave que el atacante registró dentro del perfil y una configuración apuntada a otra tienda — y cada uno exige un anclaje externo que Korvun aún no entrega; el cuarto, no ejecutado, es una fila cuya columna de búsqueda cambió de clase de almacenamiento, leída como ausencia por el lector que la busca. Migraciones automáticas v4→v6 a prueba de crash; recibos exentos de la poda de retención; ~1.25 ms por acción gobernada bajo el techo de 5 ms. Aceptada mediante la ceremonia de la caza de la falsificación sobre el perfil real del director.
v0.13.0	La Beta (minor) — efectos y política por acción: la tercera etapa de la Execution Trust Layer. Cada operación lleva su clase declarada en una escalera de consecuencias con orden total (lo desconocido ordena por encima de critical — fail-closed); los techos de efecto despiertan como décima dimensión de la atenuación, juzgados por el mismo validador con oráculo en el store, la CLI (--effect-ceiling) y la puerta; cada decisión pinea la ley exacta que la tomó (gobernanza + registro de efectos, versionada); y bajo autoridad acotada lo irreversible exige un sí humano — muriendo con el no honesto approval_unavailable hasta que llegue el workflow de aprobación. Recibos intactos por construcción; migraciones automáticas v2→v4 a prueba de crash; el exterior byte a byte. Aceptada mediante la ceremonia de la escalera sobre el perfil real del director.
v0.12.0	La Beta (minor) — identidad, intención y autoridad: la segunda etapa de la Execution Trust Layer. Cada acción registrada sabe QUIÉN la pide (un principal nacido de la procedencia autenticada — un remitente forjado jamás acuña al operador), bajo QUÉ intención humana y con CUÁNTA autoridad — que solo puede menguar: el muro de atenuación (juzgado por oráculo, property-tested y fuzzeado en el gate permanente) rechaza cualquier delegación que amplíe nombrando la dimensión, y gobierna también al operador. Primera herramienta de operador: korvun intent / korvun grant, cada acto con su recibo identificado — rechazos incluidos. Cero config nueva; migración automática v1→v2 del store a prueba de crash; los recibos siguen siendo byte-compatibles. Aceptada mediante la ceremonia del operador sobre el perfil real del director.
v0.11.0	La Beta (minor) — el Action Kernel: la primera etapa de la Execution Trust Layer. Cada acción de herramienta nace como sobre canónico con digest determinista, recibe una decisión explicable registrada ANTES de cualquier efecto (el ensayo jamás ejecuta — ahora con recibo; las herramientas alucinadas se deniegan con su regla; un intento sin registro posible falla cerrado) y deja un registro durable, capado y autogestionado — con CERO cambio de experiencia, cero config nueva y un único camino a la ejecución vigilado por máquina. Peaje completo ~1 ms por llamada (techo 5 ms); analizadores fuzzeados de cuna. Aprobada por la pasada manual del director: chat idéntico más un recibo real de la aduana leído de su propio perfil.
v0.10.0	La Beta (minor) — el escritorio honesto, y la cara nueva. El chat nunca miente: el JSON de protocolo no puede llegar a un canal, la espera nombra a quién está pensando de verdad, y una petición muerta lo dice en pantalla con el reintento a mano (a los 60 segundos avisa, pero nunca corta por su cuenta). El escritorio gana sus salas que faltaban: elegir cerebro en Nuevo chat, un panel de Secretos de solo escritura sobre el llavero del sistema, un onboarding que habla OpenAI-compatible y valida el modelo elegido, borrado de cables con el ratón, y un panel de modelo que bloquea las formas de corrupción antes de Aplicar. Además, la identidad de la K gobernada A1 en la web, el README, el icono de la app y la cabecera del CLI — y un defecto real de enrutado (un código fatal de cierre enmascarado) cazado y arreglado por el trabajo de deflake. Todo bajo la sexta ley y el bash del director: cero rompe-usos.
v0.9.2	La Beta (patch) — los cuatro hallazgos rompe-uso de la auditoría UX exhaustiva, arreglados y verificados a mano sobre la build empaquetada: los cables del lienzo se pueden desconectar, cambiar de proveedor limpia el warmup huérfano, el rastro del reload queda en el log con su contrato de cutover fijado, y la salud del modelo llega a la UI (badge en el builder + aviso en el chat). La primera release bajo la sexta ley de la casa: diseño primero, y una pasada manual sobre la build empaquetada como aduana de cada release.
v0.9.1	La Beta (patch) — siete arreglos de escritorio salidos de la primera auditoría de campo de la app empaquetada: el Builder pierde su puerta de token embebida, aprende el proveedor openai-compatible con verdad, las configs del escritorio siempre llevan el bloque admin, el lienzo responde (aviso al soltar modelos, cierres del panel), el escritorio escribe log a fichero y el canal webhook gana su miga de pan en el asistente.
v0.9.0	La Beta — la pasarela universal de modelos: cualquier endpoint compatible-OpenAI, en la nube o local, se convierte en modelo de primera clase solo con config — mismo motor de políticas, misma privacidad por localidad declarada, mismas herramientas gobernadas (tool calling nativo incluido), con la cuota distinguida del rate limit, los redirects rechazados y la clave sin aflorar jamás. Los cambios completos están en las notas de GitHub.
v0.8.0	La memoria gobernada cierra la última pieza de la beta: notas acotadas mediante la herramienta gobernada memory_note, /recall deliberado de la cola de una sesión, /notes para el operador. Los cambios completos están en las notas de GitHub.
v0.7.0	La consola del operador + herramientas y skills gobernadas — la pestaña Chat (takeover, sesiones, chat directo), permisos tri-estado con ensayo en shadow, el escudo de red, skills en markdown, tool calling nativo con fallback honesto.
v0.6.0	El lienzo del builder visual — arrastra canales, cerebros y modelos desde una paleta, cables validados, la exclusión de privacidad dibujada como cable gris discontinuo, personalidad por cerebro, aplicación en caliente.
v0.5.0	El canal webhook genérico — POST de JSON de entrada, respuestas a tu URL; auth Bearer que falla cerrado, identidad de conversación, 503 honesto en saturación.
v0.4.0	Korvun Desktop — la pasarela tras una ventana nativa: onboarding en el primer arranque, secretos en el llavero del sistema, el builder embebido.
v0.3.0	El canal de Discord — Gateway de entrada con resume/reconexión, REST de salida, menciones bloqueadas por defecto, una familia anti-bucle completa.
v0.2.0	Resiliencia + la CLI — calentamiento de modelos locales al arrancar, tiempos por intento generosos, reintento con fallback diferenciado; serve, config check, status.

Las notas de cada release se publican en GitHub — esta página es un mapa, no un espejo.