v0.1.3-kernel — the operation is what gets kept

Published as v0.1.3-kernel on 2026-10-03. The previous tag is v0.1.2-kernel. This page says what the version changes for a person, and what was and was not tested. It is source you read and run, not something that installs itself.

Vespi in one line

The simplest way to say it. Vespi lets you build complex applications with AI without having to know how it is done. Its kernel and Lore Plugin already run the hard parts for you: loops until the work is done, test-first development, blind readers who judge the result without seeing how it was made, and a check by someone other than whoever did the work. You say what you want; Vespi keeps the operation standing and leaves a receipt anyone can verify. The kernel was built in part with Raven MCP (the MCP over the Stellar ecosystem's project directory) and Stellar, and the coordinator's method is distilled from The Fable Method (MIT).

What you no longer have to carry

The unit is the operation, and the operation is what gets kept.

Until now, when a session ended and another had to begin, what carried over was a summary. A summary does not say who allowed the thing, how much, until when, to whom, or whether the thing that was supposed to happen actually happened. Those are not details of a summary — they are the operation. So Vespi starts from the operation, and this version is what makes that hold.

• You re-decide less. Resuming what was agreed does not ask you anything. The kernel reads the operation back from its receipts, not from a handoff document, and it only continues if what it is about to do is still what was agreed.
• Anything off the agreement comes back to you. Three things open the gate, and only three: a verified receipt for an action outside the agreement, a change to the scope, amount, ceiling or status of the next action, and a last receipt for that action that was blocked, paused or needs_human_decision. It does not guess between them.
• The impossible thing comes back blocked, with its way out. Not retried blindly. The receipt names the exit, and the agreement says who may pause it.
• The agent never consents for you. If the operation declares an agent, an approval whose by is that agent is refused, the kernel writes down that the agent cannot consent for the person, and the operation returns to needs_human_decision.

The authority, the gate and the receipt

This is the depth, and it enters after the first screen, not instead of it.

• Authority is granted with three things at once — a clock, a budget and a destination. A grant with to covers only that destination. A grant without to covers any destination but keeps one budget: 400 + 400 against a 500 ceiling is not enough. An expired grant is refused with a reason that names the moment it expired, and now is injectable, so the same grant can be exercised on both sides of its own clock.
• Several people can be required. authority.signers = { required, allowed }. The gate returns identities, not cryptographic signatures, and the kernel counts distinct identities drawn from allowed. The same identity twice counts once; an identity outside allowed does not count; the operation's own agent never counts; approvals pre-loaded into the authority do not count, only approvals that arrive through the gate.
• The human gate has its four gestures: show the cost first, never let the agent give the consent that belongs to the person, keep what goes public optional and off, and name the exit in every refusal.
• Every step leaves a receipt with a SHA-256 fingerprint over the canonical form, and the fingerprint proves integrity, not authenticity: it carries no key, so anyone able to rewrite the receipts file can recompute it. Coverage is not a claim — a check counts as covered only when it came back true, and anything else is listed in notCovered by name.
• Anchoring on Stellar is an interface, not a certificate. pending when nothing reached the network, submitted when the adapter returned a transaction hash, and anchored only when the verifier confirms the digest and the network. A transaction hash on its own is not an anchor.

A capability outside the kernel

capabilities/respaldo/ copies a person's working tree — Lore, sites, images, video — into a folder that Drive, Dropbox or OneDrive already sync, incrementally and by SHA-256, with a manifest, a verification that recomputes every hash, a restoration that checks the hash before returning a file, and a «where is the latest copy» lookup. The destination is the grant's to: a folder the authority does not name opens the human gate and nothing is copied. It does not encrypt, keep versions, upload through any API or follow symbolic links, and says so in its LEEME.md. 17 tests, in both suites below.

What is deliberately still open

Written as open, not softened.

• 0.1.4 is already scoped and not built: emergency access granted in advance and exercised with an immediate receipt, a zero-knowledge proof verifier, skill provenance, and x402 live inside the kernel itself. The demo adapter already pays live on testnet (below).
• The receipt is not durable by itself. The kernel returns a receipt; whoever calls it owns where it lives. There is no cross-host runtime, scheduler, migration engine or quota manager here.
• One live x402 payment on testnet is verified, and nothing more: on 2026-10-02 the repaired adapter paid 0.01 USDC through the real facilitator, the receipt came back verified, and Horizon confirmed the transaction separately (abb968e86d8997f6f555c4efe50dd5a70671dc5064b8220a7f2ea221de7650d5, ledger 4988161). Its receipt still lists external anchor in notCovered. No mainnet, no second provider. Receipt: demo/x402/receipts/live-testnet-2026-10-02.json.
• The commits in this repository are not signed. git log --format='%G?' returns N for every commit in this repository. See ../NOTICE.
• No stable protocol, no production readiness, no regulatory compliance, and no external security review has run. A review enters this repository with its run attached, or it does not enter.

What was tested, and what was not

Claim	Result	Cut and scope
node --test test/*.test.js at the previous RC5 cut 54c20c7	181/181, exit 0	Historical baseline carried by the installed RC5 plugin; not the 0.1.3 result.
Core suite, node --test test/*.test.js at 2dcfd92	203/203, exit 0	Kernel tests, run on 2026-10-02.
Full suite, node --test at 2dcfd92	252/252, exit 0	Includes the x402 demo with its dependencies available.
Full suite, node --test at 7dcec77	252/252, exit 0	Run again on 2026-10-03 on the tree that was published; the tag adds only the text changes that say «released».
One live x402 payment, demo/x402 run against the real facilitator	verified, 0.01 USDC	Stellar testnet, 2026-10-02, transaction abb968e8… confirmed separately on Horizon.
Benchmark for this version	Not run. No figure on this page describes a measured effect of 0.1.3.	—
External review	Pending. No review is credited here without its run attached.	—
Installation	None from this release. The kernel is source you read and run; Lore Plugin carries its own fixed copy of it.	—

---

v0.1.3

Publicado como v0.1.3-kernel el 2026-10-03. La etiqueta anterior es v0.1.2-kernel. Esta página dice qué cambia la versión para una persona, y qué se probó y qué no. Es código que se lee y se corre, no algo que se instale solo.

Vespi en una línea

Lo más simple. Vespi te permite construir aplicaciones complejas con IA sin que tengas que saber cómo se hace. Su kernel y Lore Plugin ya ejecutan por ti lo difícil: ciclos hasta terminar el trabajo, desarrollo con la prueba primero (TDD), lectores ciegos que juzgan el resultado sin ver cómo se hizo, y una verificación hecha por alguien distinto de quien trabajó. Tú dices qué quieres; Vespi mantiene viva la operación y deja un recibo que cualquiera puede comprobar. El kernel se construyó en parte con Raven MCP (el MCP sobre el directorio de proyectos del ecosistema Stellar) y Stellar, y el método del coordinador se destiló de The Fable Method (MIT).

Lo que ya no tienes que cargar tú

La unidad es la operación, y lo que se conserva es la operación.

Hasta ahora, cuando una sesión terminaba y otra tenía que empezar, lo que pasaba era un resumen. Un resumen no dice quién autorizó la cosa, cuánto, hasta cuándo, a quién, ni si la cosa que debía pasar de verdad pasó. Eso no son detalles de un resumen: es la operación. Por eso Vespi parte de la operación, y esta versión es lo que hace que eso se sostenga.

• Vuelves a decidir menos. Retomar lo acordado no te pregunta nada. El kernel relee la operación desde sus recibos, no desde un documento de traspaso, y solo continúa si lo que está a punto de hacer sigue siendo lo acordado.
• Lo que se sale del acuerdo vuelve a ti. Tres cosas abren la puerta, y solo tres: un recibo verificado de una acción fuera del acuerdo, un cambio en el alcance, la cantidad, el techo o el estado de la siguiente acción, y un último recibo de esa acción que fuera blocked, paused o needs_human_decision. No adivina entre ellas.
• Lo imposible vuelve bloqueado, con su salida. No se reintenta a ciegas. El recibo nombra la salida, y el acuerdo dice quién puede pausarlo.
• El agente nunca consiente por ti. Si la operación declara un agente, se rechaza una aprobación cuyo by sea ese agente, el kernel deja escrito que el agente no puede consentir por la persona, y la operación vuelve a needs_human_decision.

La autoridad, la puerta y el recibo

Esta es la profundidad, y entra después de la primera pantalla, no en vez de ella.

• La autoridad se otorga con tres cosas a la vez: un reloj, un presupuesto y un destino. Un grant con to cubre solo ese destino. Uno sin to cubre cualquier destino pero conserva un presupuesto: 400 + 400 contra un techo de 500 no alcanza. Un grant vencido se rechaza con una razón que nombra el momento en que venció, y now es inyectable, así que el mismo grant se puede ejercitar a los dos lados de su propio reloj.
• Se puede exigir más de una persona. authority.signers = { required, allowed }. La puerta devuelve identidades, no firmas criptográficas, y el kernel cuenta identidades distintas tomadas de allowed. La misma identidad dos veces cuenta una sola vez; una identidad fuera de allowed no cuenta; el agente de la operación nunca cuenta; las aprobaciones cargadas de antemano en la autoridad no cuentan, solo las que llegan por la puerta.
• La puerta humana tiene sus cuatro gestos: mostrar el costo primero, nunca dejar que el agente dé el consentimiento que le toca a la persona, mantener lo que sale a lo público opcional y apagado, y nombrar la salida en todo rechazo.
• Cada paso deja un recibo con una huella SHA-256 sobre la forma canónica, y la huella prueba integridad, no autenticidad: no lleva clave, así que cualquiera que pueda reescribir el archivo de recibos puede recalcularla. La cobertura no es una afirmación: un chequeo cuenta como cubierto solo cuando volvió true, y cualquier otra cosa aparece en notCovered por su nombre.
• Anclar en Stellar es una interfaz, no un certificado. pending cuando nada llegó a la red, submitted cuando el adaptador devolvió un hash de transacción, y anchored solo cuando el verificador confirma el digest y la red. Un hash por sí solo no es un anclaje.

Una capacidad fuera del kernel

capabilities/respaldo/ copia el árbol de trabajo de una persona —Lore, sitios, imágenes, video— a una carpeta que Drive, Dropbox u OneDrive ya sincronizan, de forma incremental y por SHA-256, con un manifiesto, una verificación que recalcula cada huella, una restauración que comprueba la huella antes de devolver un archivo y una búsqueda de «dónde está la última copia». El destino es el to del grant: una carpeta que la autoridad no nombra abre la puerta humana y no se copia nada. No cifra, no lleva versiones, no sube por ninguna API ni sigue enlaces simbólicos, y lo dice en su LEEME.md. 17 pruebas, dentro de las dos suites de abajo.

Lo que sigue deliberadamente abierto

Escrito como abierto, no suavizado.

• El 0.1.4 ya está acotado y no está construido: acceso de emergencia otorgado por adelantado y ejercido con recibo inmediato, un verificador de pruebas de conocimiento cero, procedencia de skills y x402 en vivo dentro del propio kernel. El adaptador de la demo ya paga en vivo en testnet (abajo).
• El recibo no es durable por sí solo. El kernel devuelve un recibo; quien lo llama decide dónde vive. Aquí no hay runtime cross-host, scheduler, migration engine ni quota manager.
• Hay un pago x402 live verificado en testnet, y nada más: el 2026-10-02 el adaptador reparado pagó 0,01 USDC a través del facilitator real, el recibo volvió verified y Horizon confirmó la transacción por separado (abb968e86d8997f6f555c4efe50dd5a70671dc5064b8220a7f2ea221de7650d5, ledger 4988161). Su recibo todavía lista external anchor en notCovered. Sin mainnet, sin un segundo proveedor. Recibo: demo/x402/receipts/live-testnet-2026-10-02.json.
• Los commits de este repositorio no están firmados. git log --format='%G?' devuelve N para todos los commits de este repositorio. Ver ../NOTICE.
• No hay protocolo estable, ni producción lista, ni cumplimiento regulatorio, y no se ha corrido ninguna revisión de seguridad externa. Una revisión entra a este repositorio con su corrida adjunta, o no entra.

Qué se probó, y qué no

Afirmación	Resultado	Corte y alcance
node --test test/*.test.js en el corte RC5 anterior 54c20c7	181/181, exit 0	Línea base histórica que llevaba el plugin RC5 instalado; no es el resultado del 0.1.3.
Suite central, node --test test/*.test.js en 2dcfd92	203/203, exit 0	Pruebas del kernel, corridas el 2026-10-02.
Suite completa, node --test en 2dcfd92	252/252, exit 0	Incluye la demo x402 con sus dependencias disponibles.
Suite completa, node --test en 7dcec77	252/252, exit 0	Corrida de nuevo el 2026-10-03 sobre el árbol que se publicó; la etiqueta agrega solo los cambios de texto que dicen «publicado».
Un pago x402 live, demo/x402 contra el facilitator real	verificado, 0,01 USDC	Stellar testnet, 2026-10-02, transacción abb968e8… confirmada por separado en Horizon.
Benchmark de esta versión	No corrido. Ninguna cifra de esta página describe un efecto medido del 0.1.3.	—
Revisión externa	Pendiente. Aquí no se acredita ninguna revisión sin su corrida adjunta.	—
Instalación	Ninguna desde este lanzamiento. El kernel es código que se lee y se corre; Lore Plugin lleva su propia copia fija.	—