Vespi Kernel 0.1.4

v0.1.4

Kernel snapshot, candidate cut, publication date pending. Previous version: v0.1.3-kernel. This is source you read and run; it does not install itself or update Lore Plugin's pinned kernel.

Vespi in one line

Vespi keeps the authority you granted, the result that was checked and the next agreed action together when an operation changes hands. You can resume what still holds, while an uncertain exercised effect returns to you for reconciliation. This is tested continuation logic, not demonstrated autonomous operation across hosts.

What you no longer have to carry

The operation retains its agreement and receipts rather than relying only on a handoff summary. In the continuation tests, an exercised not_verified receipt or a failed receipt with settlementUnknown requires needsPerson: true and reconciliation_required before that action is selected again; the host must supply trustworthy receipts and observations, and only a later verified receipt resolves that recorded uncertainty.

Operation and continuation tests cover the stable idempotencyKey passed to perform, per-action maxAttempts and the synchronous injected io.now clock, but the destination must honor the key, an attempt cap is not a shared money budget, and the kernel cannot establish whether that clock is trustworthy. Delegation tests cover deadlineMs and delegationStatus, but deadlines report status only when queried and never schedule or execute work.

The agreement keeps its order. Its purpose is to preserve your agency and reduce repeated decisions; its method coordinates bounded authority, a human gate and receipts; each operation's concrete result must be checked. Lore Plugin supplies the coordinator's method and criterion, while this kernel supplies operation semantics. The agreement is not evidence that a novice user has tried the combined product, that work resumes autonomously, or that an institution has adopted it.

The authority, the gate and the receipt

Authority and gate tests exercise asset, ceiling, destination, expiry and distinct named approvals, but ordinary gate names are identity labels rather than authenticated signatures, and budgets are not accumulated across operations. The gate shows the declared cost, refuses consent attributed to the operation's agent and names an exit; its tests do not establish the real identity of the person answering.

Receipt and anchor tests check integrity and preservation of the digest sent, confirmed and returned during anchoring, but an unsigned SHA-256 digest is recomputable and does not prove authorship or the effect. An anchor reaches anchored only after an injected verifier confirms the digest and network; the kernel itself does not submit to Stellar.

D3 remains explicit: a newly built receipt stamps stellar:testnet in its pending anchor, including a local receipt, and the anchor is excluded from its digest in receipt.js; this default does not prove a network interaction and becomes configurable in 0.1.5. Compatibility is conditional: old receipts without checks retain their previous shape, as regressions verify, but an old claim with an unknown reserved zk. check is now refused as not_verified and its newly built digest changes. Unknown exercised shapes also carry exercisedUnknown; there is no promise that every old input keeps its digest.

What entered from the 0.1.3 promise

The previous note announced emergency access, zero knowledge, skill provenance and x402 inside the kernel. All enter this cut, with these boundaries.

Emergency authority can be granted in advance with scope, trigger, expiry, a use cap and post-use reviewers, as emergency regressions and host-principal tests verify, but authenticate is a host-injected port and the opaque principals it returns are not proof of real identity. Exercise requires the grantee's principal; executor and reviewer independence follows the identities returned by that port. An open review blocks another use, and accepting a review does not verify the effect. Grant and renewal rely on bound approvers: omitting by is allowed, so any handle holder can request renewal and the approver is not told who asked. This module neither persists its ledger nor executes or verifies an effect nor supplies a trusted clock. D4: it counts uses, not money; the consuming project must impose the money ceiling. The final independent emergency verdict required minor fixes, recorded as applied by the builder and represented in those regressions; this is not an external security audit.

Skill provenance compares repository, fixed commit, author and recomputed content digest against a resolver's own evidence, as provenance tests verify, but the resolver is injected and not authenticated, so matching provenance neither proves authorship nor establishes that a skill is safe. The resolver receives neither the declared author nor contentDigest. Receipts distinguish provenanceSource: verified from declared, and nameSource remains declared. Hardening regressions cover hostile data, including data on polluted prototypes, but do not defend against a host or same-process code replacing built-in functions after module loading or during a call. Fields inherited from a resolver's class prototype are not observed evidence. The final independent verdict was conditional on fixes and acceptance of this data-versus-code boundary; the builder records both as applied.

The x402 paid-effect contract declares fixed terms and orders preparation, separate inspection, a fresh authority check before send, delivery validation and settlement verification, as x402 regressions verify with synthetic ports, but signing, HTTP, XDR and Horizon remain host-supplied ports. claims is mandatory and synchronous; operation identity is part of the effect key, so retries of the same identity are refused while different operations can pay for the same goal. The included memory store is not durable and never releases a reservation, even after a refusal before send. Provider idempotency is a hint. EFFECT_KEY_VERSION identifies the version of stored keys; it does not let a host reconstruct an unseen key from a receipt. The kernel checks the validator's output and digest shape, not their correspondence, and inspects plainness only at the top level. No refund handling or shared money budget is included. Anyone can build on this contract by supplying their own ports. The 0.1.3 testnet receipt is historical evidence for the earlier adapter. The independent kernel verdict required minor fixes, now represented in the regressions.

The reference bridge with the real Stellar SDK does not enter 0.1.4 because two independent reviews rejected it. The first found that 15 of 20 attacks were not blocked, and the second found that 13 out of 26 were not blocked, including replay of the same authorization, overwriting its inspection window and reads that continue after cancellation. Neither review demonstrated improper settlement or key disclosure. The integration is deferred to 0.1.5. Its source remains in the working tree, but this release does not present it as a shipped or reviewed integration.

The ZK port pins a key digest and agreed public inputs, as port tests verify, but trusts an injected cryptographic backend; a backend label is not a certificate of its code. Its checks do not authenticate the presenter, attest an institution, prevent replay or prove transport privacy. Curve and subgroup checks belong to the backend, and verification after perform is not a pre-effect gate. The verifier-echo guard compares object identity, not content.

The experimental BN254 Groth16 reference is included as an internal backend, with arithmetic and pairing evidence in independent fixtures and reference tests, but is not a public API, has no external audit and is not production ready. Groth16 proofs are malleable, so proofDigest cannot serve as replay protection. A degenerate key accepts forgeries; neither the port nor the reference establishes setup quality or the key's institutional provenance. Verification consumes synchronous CPU that a Promise timeout cannot interrupt; exposure requires a host worker or process budget. It is not constant time. The independent verdict required port and reference fixes, recorded as applied and covered by review regressions; this does not establish private membership proofs in Casa Firme or Vela.

What was tested, and what was not

The saved suite result records the command and exact counts for this cut. A todo is not a passing test. These are local kernel tests; no reference-bridge SDK suite is part of this cut. Review verdicts are model reviews independent of their builders, not an external security audit. The new modules have not demonstrated integration with Casa Firme or Vela. A simulated security review (three reviewers on OpenCode models plus a verifier that reproduced each finding; it is not a review by Anthropic) found ten issues in this cut, all fixed with a red test first; a real security-review is planned before the next freeze.

That file names the commit the suite ran on: the parent of the commit that stores it. The later commits of this cut change documents and not src/, and you can check that with git diff <tested commit> HEAD --stat -- src, which must print nothing. Two commits carry the 0.1.4 name, the one the suite ran on and the one that stores its result, so read the count with that distinction in mind.

Saved testnet evidence contains 50 Horizon readbacks: 5 cases are semantically verified against operation, memo, asset, amount and recipient, and 45 are partially verified against only the facts their local run records declared, with 0 discrepancies. Expectations come from local execution records, never from Horizon. The evidence guide explains how to recompute that comparison and what remains unchecked; chain success is not complete semantic verification. Everything is Stellar testnet with fictional data and no real money. The 0.1.3 receipt is historical evidence for the earlier adapter only.

Functional-project source access

The project repositories remain public and currently contain README files only, according to the owner's access schedule. Their code is scheduled to enter the main branch by a push on 12 October 2026 at 20:29 Chile time and to be removed from that branch by another push on 16 October at 19:31. This gives a 30-minute margin around deliberation, from 12 October at 20:59 to 16 October at 19:01. Removing code with a new commit does not erase it from Git history, and a copy already obtained cannot be withdrawn. This is the stated access window, not proof of a future push.

D5: Vela's sealed content remains plaintext in the demonstration, as declared by the owner; a real deployment requires encryption at rest and third-party key custody. Neither that protection nor consumer integration is demonstrated by this kernel's tests.

What 0.1.4 does NOT bring and moves to 0.1.5

Spend-authority narrowing from feat/linux stays out because the base grantSpend constructor can be affected by inherited setters. A corrected candidate requires independent verification before inclusion; there is no narrow(parent, child) claim for this cut.

The deferred x402 cases are HX-09, HX-11, HX-12 and HX-13: naming a rejected control risks sealing host-written text, recording the effect-key version changes receipt shape and digests, publishing the key widens what leaves the process, and a formal public code catalog widens the API. R2-05 leaves release of a pre-send reservation for an explicit crash/retry design; H11 leaves network and resource fields out of the spend authority, so that authority does not bind them.

The deferred provenance cases are N07 and N08: unpaired surrogate text can collide through lossy UTF-8 encoding, and nested receipt getters can still throw in the base builder. H12d and H13d leave refused capability requests absent from the structured requested list and provenance verification time absent from the receipt; both need a public receipt contract decision. Emergency H21 leaves accessor-bearing renewal changes accepted through one validated read, because rejecting them would contradict existing read-once tests; its proposed rejection remains deferred, not implemented.

The reference bridge with the real Stellar SDK is excluded from this cut and deferred to 0.1.5 after two independent reviews rejected it. The first review found that 15 of 20 attacks were not blocked; the second found that 13 out of 26 were not blocked, including authorization replay, an overwritten inspection window and reads that continue after cancellation. Neither review demonstrated improper settlement or key disclosure. The 0.1.4 x402 contribution is the injected-port paid-effect contract described above; the historical 0.1.3 testnet receipt does not validate this reference integration.

Those named deferrals do not account for every todo: provenance function-replacement tests document the boundary outside the contract, while x402 R3 cases document nested-output limits, reliance on the validator's digest and the deliberately unavailable key recomputation. Recursive output inspection remains 0.1.5 work; the other declared boundaries are not promises of later fixes.

There is no durable ledger or claims store, autonomous cross-host runtime, scheduler, mainnet evidence, second payment provider, production readiness or regulatory certification. Receipt chaining, pre-effect intent and accumulated budgets remain open without a delivery promise. The working architecture still labels operation semantics SUPPORTED, autonomous operation UNTESTED, and the Final Vespi Gate READY_FOR_MUSE_DISCOVERY and NOT_READY_FOR_IMPLEMENTATION; these are candidate boundaries, not shipped runtime abilities.

---

v0.1.4

Corte candidato del kernel, fecha de publicación pendiente. Versión anterior: v0.1.3-kernel. Es código que lees y ejecutas; no se instala solo ni actualiza la copia del kernel fijada en Lore Plugin.

Vespi en una línea

Vespi conserva juntas la autoridad que otorgaste, el resultado comprobado y la siguiente acción acordada cuando una operación cambia de manos. Puedes retomar lo que sigue valiendo, mientras un efecto ejercido incierto vuelve a ti para reconciliarlo. Es lógica de continuidad probada, no operación autónoma demostrada entre hosts.

Lo que ya no tienes que cargar tú

La operación conserva su acuerdo y sus recibos en vez de depender solo de un resumen de traspaso. En las pruebas de continuidad, un recibo not_verified con efecto ejercido o un recibo failed con settlementUnknown exige needsPerson: true y reconciliation_required antes de volver a seleccionar esa acción; el host debe aportar recibos y observaciones confiables, y solo un recibo verificado posterior resuelve esa incertidumbre registrada.

Las pruebas de operación y continuidad cubren la clave estable idempotencyKey que recibe perform, maxAttempts por acción y el reloj síncrono inyectado io.now, pero el destino debe respetar la clave, el tope de intentos no es un presupuesto compartido de dinero y el kernel no puede demostrar que el reloj sea confiable. Las pruebas de delegación cubren deadlineMs y delegationStatus, pero los plazos informan el estado solo cuando los consultas y nunca programan ni ejecutan trabajo.

El acuerdo conserva su orden. Su finalidad es cuidar tu agencia y reducir decisiones repetidas; su método coordina autoridad acotada, puerta humana y recibos; el resultado concreto de cada operación debe comprobarse. Lore Plugin aporta el método del coordinador y el criterio, y este kernel aporta la semántica de la operación. El acuerdo no demuestra que una persona sin experiencia haya probado el producto combinado, que el trabajo se reanude de forma autónoma ni que una institución lo haya adoptado.

La autoridad, la puerta y el recibo

Las pruebas de autoridad y puerta ejercitan activo, techo, destino, vencimiento y aprobaciones con nombres distintos, pero los nombres de la puerta ordinaria son etiquetas de identidad y no firmas autenticadas, y los presupuestos no se acumulan entre operaciones. La puerta muestra el costo declarado, rechaza el consentimiento atribuido al agente de la operación y nombra una salida; sus pruebas no establecen la identidad real de quien responde.

Las pruebas de recibos y anclaje comprueban integridad y conservación del digest enviado, confirmado y devuelto al anclar, pero un digest SHA-256 sin firma se puede recalcular y no demuestra autoría ni efecto. El ancla llega a anchored solo cuando un verificador inyectado confirma digest y red; el kernel no envía transacciones a Stellar por sí mismo.

D3 queda explícito: todo recibo nuevo estampa stellar:testnet en su ancla pendiente, incluso si es local, y el ancla queda fuera del digest en receipt.js; ese valor no prueba interacción con una red y se parametriza en 0.1.5. La compatibilidad tiene condiciones: los recibos antiguos sin checks conservan su forma anterior, como comprueban las regresiones, pero una afirmación antigua con un control reservado zk. desconocido ahora se rechaza como not_verified y cambia su digest al construirla de nuevo. Las formas desconocidas de gasto ejercido también llevan exercisedUnknown; no se promete conservar el digest de toda entrada antigua.

Qué entró de lo anunciado en 0.1.3

La nota anterior anunció emergencia, conocimiento cero, procedencia de skills y x402 dentro del kernel. Todo entra en este corte, con estas fronteras.

Puedes otorgar autoridad de emergencia por adelantado con alcance, disparador, vencimiento, tope de usos y revisores posteriores, como verifican las regresiones de emergencia y las pruebas de principales del host, pero authenticate es un puerto inyectado por el host y sus principales opacos no prueban identidad real. El ejercicio exige el principal del grantee; la independencia entre ejecutor y revisor depende de la identidad que devuelve ese puerto. Una revisión abierta bloquea otro uso, y aceptar la revisión no verifica el efecto. El otorgamiento y la renovación dependen de aprobadores vinculados: se permite omitir by, por lo que cualquier titular del handle puede pedir una renovación y el aprobador no recibe quién la pidió. El módulo no persiste su registro, no ejecuta ni verifica efectos y no aporta reloj confiable. D4: cuenta usos, no dinero; el proyecto consumidor debe imponer el techo en dinero. El veredicto independiente final exigió arreglos menores, que el constructor registra como aplicados y que figuran en esas regresiones; no es una auditoría de seguridad externa.

La procedencia de skills compara repositorio, commit fijo, autor y digest recalculado del contenido con evidencia propia de un resolver, como verifican sus pruebas, pero el resolver es inyectado y no se autentica, por lo que una procedencia coincidente no demuestra autoría ni seguridad de la skill. El resolver no recibe author ni contentDigest declarados. Los recibos distinguen provenanceSource: verified de declared, y nameSource sigue en declared. Las regresiones de endurecimiento cubren datos hostiles, incluidos datos en prototipos contaminados, pero no defienden contra un host o código del mismo proceso que reemplaza funciones integradas después de cargar el módulo o durante una llamada. Los campos heredados del prototipo de una clase del resolver no cuentan como evidencia observada. El veredicto independiente final quedó condicionado a arreglos y a aceptar esta frontera entre datos y código; el constructor registra ambas cosas como aplicadas.

El contrato x402 de efecto pagado declara términos fijos y ordena preparación, inspección separada, comprobación nueva de autoridad antes del envío, validación de entrega y verificación de liquidación, como verifican sus regresiones con puertos sintéticos, pero firma, HTTP, XDR y Horizon siguen siendo puertos que aporta el host. claims es obligatorio y síncrono; la identidad de la operación entra en la clave del efecto, de modo que se rechazan reintentos de la misma identidad y operaciones distintas pueden pagar por la misma meta. El almacén en memoria incluido no es durable y nunca libera una reserva, incluso tras un rechazo previo al envío. La idempotencia del proveedor es una pista. EFFECT_KEY_VERSION identifica la versión de claves guardadas; no permite reconstruir desde un recibo una clave que el host nunca vio. El kernel comprueba la forma de la salida y del digest declarados por el validador, no su correspondencia, y comprueba datos planos solo en el primer nivel. No incluye reembolsos ni presupuesto de dinero compartido. Cualquiera puede construir sobre este contrato si aporta sus propios puertos. El recibo de testnet del 0.1.3 es evidencia histórica del adaptador anterior. El veredicto independiente del kernel exigió arreglos menores, ahora representados en las regresiones.

El puente de referencia con el SDK real de Stellar no entra en el 0.1.4 porque dos revisiones independientes lo rechazaron. La primera revisión encontró que no se bloquearon 15 de 20 ataques y la segunda encontró que no se bloquearon 13 de 26, incluidos el reenvío de la misma autorización, la sobrescritura de su ventana de inspección y lecturas que continúan tras cancelar. Ninguna demostró liquidación indebida ni filtración de claves. La integración pasa al 0.1.5. Su código fuente permanece en el árbol de trabajo, pero esta versión no la presenta como integración entregada ni revisada.

El puerto ZK fija el digest de la clave y las entradas públicas acordadas, como verifican las pruebas del puerto, pero confía en un backend criptográfico inyectado; una etiqueta de backend no certifica su código. Sus comprobaciones no autentican a quien presenta la prueba, no acreditan una institución, no evitan el reuso ni prueban privacidad del transporte. La curva y el subgrupo los comprueba el backend, y verificar después de perform no es una puerta previa al efecto. La guardia contra el eco del verificador compara identidad de objetos, no contenido.

La referencia BN254 con Groth16 experimental entra como backend interno, con evidencia de aritmética y pairing en fixtures independientes y pruebas de la referencia, pero no es API pública, no tiene auditoría externa y no es apta para producción. Las pruebas Groth16 son maleables, por lo que proofDigest no sirve de antirreplay. Una clave degenerada acepta falsificaciones; ni el puerto ni la referencia establecen la calidad de la preparación ni la procedencia institucional de la clave. La verificación consume CPU síncrona que un timeout con Promise no interrumpe; exponerla requiere un worker o proceso con presupuesto del host. No es de tiempo constante. El veredicto independiente exigió arreglos del puerto y de la referencia, registrados como aplicados y cubiertos por regresiones de revisión; esto no demuestra pruebas privadas de pertenencia en Casa Firme o Vela.

Qué se probó y qué no

El resultado guardado de la suite registra el comando y los conteos exactos de este corte. Un todo no es una prueba aprobada. Son pruebas locales del kernel; este corte no incluye una suite de SDK para el puente de referencia. Los veredictos de revisión provienen de modelos independientes de sus constructores, no de una auditoría de seguridad externa. Los módulos nuevos no han demostrado integración con Casa Firme o Vela. Una revisión de seguridad simulada (tres revisores con modelos de OpenCode y un verificador que reprodujo cada hallazgo; no es una revisión de Anthropic) encontró diez problemas en este corte, todos corregidos con una prueba roja primero; antes del siguiente congelamiento se prevé un security-review real.

Ese archivo nombra el commit sobre el que se corrió la suite: el padre del commit que lo guarda. Los commits posteriores de este corte cambian documentos y no src/, y eso se comprueba con git diff <commit probado> HEAD --stat -- src, que debe salir vacío. Dos commits llevan el nombre 0.1.4, el sobre el que se corrió la suite y el que guarda su resultado, así que hay que leer el conteo con esa distinción presente.

La evidencia de testnet guardada contiene 50 lecturas de Horizon: 5 casos verificados semánticamente contra operación, memo, activo, monto y destinatario, y 45 parcialmente verificados solo contra los hechos que declararon sus registros locales de ejecución, con 0 discrepancias. Las expectativas vienen de esos registros, nunca de Horizon. La guía de evidencia explica cómo recalcular esa comparación y qué queda sin comprobar; el éxito en cadena no equivale a verificación semántica completa. Todo corresponde a Stellar testnet con datos ficticios y sin dinero real. El recibo del 0.1.3 es evidencia histórica del adaptador anterior.

Acceso al código de los proyectos funcionales

Los repositorios de los proyectos son siempre públicos y hoy contienen solo README, según el calendario de acceso del dueño. Su código entra por un push a la rama principal el 12 de octubre de 2026 a las 20:29, hora de Chile, y se retira de esa rama por otro push el 16 de octubre a las 19:31. El margen es de 30 minutos alrededor de la deliberación, del 12 de octubre a las 20:59 al 16 de octubre a las 19:01. Retirar el código con un commit nuevo no lo borra del historial de Git, y una copia que ya obtuviste no se puede retirar. Es la ventana de acceso declarada, no evidencia de un push futuro.

D5: el contenido sellado de Vela queda en claro en la demostración, según la decisión del dueño; un despliegue real exige cifrado en reposo y custodia de claves de un tercero. Las pruebas de este kernel no demuestran esa protección ni integración con consumidores.

Qué NO trae el 0.1.4 y pasa al 0.1.5

El comparador de reducción de autoridad de gasto de feat/linux queda fuera porque el constructor base grantSpend puede verse afectado por setters heredados. Una candidata corregida requiere verificación independiente antes de entrar; este corte no afirma narrow(padre, hijo).

Los casos x402 diferidos son HX-09, HX-11, HX-12 y HX-13: nombrar el control rechazado puede sellar texto escrito por el host, registrar la versión de la clave del efecto cambia forma y digest del recibo, publicar la clave amplía lo que sale del proceso y un catálogo formal de códigos públicos amplía la API. R2-05 deja la liberación de reservas previas al envío para un diseño explícito de caída y reintento; H11 deja red y recurso fuera de la autoridad de gasto, por lo que esa autoridad no los vincula.

Los casos de procedencia diferidos son N07 y N08: los sustitutos Unicode sin pareja pueden colisionar por la codificación UTF-8 con pérdida, y los getters anidados del recibo aún pueden lanzar desde el constructor base. H12d y H13d dejan la petición de capacidad rechazada fuera de la lista estructurada de lo solicitado y la hora de verificación de procedencia fuera del recibo; ambos requieren una decisión sobre su contrato público. H21 de emergencia deja cambios de renovación con accesores aceptados mediante una lectura validada, porque rechazarlos contradiría las pruebas existentes de lectura única; el rechazo propuesto sigue diferido, sin implementar.

El puente de referencia con el SDK real de Stellar queda fuera de este corte y pasa al 0.1.5 tras el rechazo de dos revisiones independientes. La primera revisión encontró que no se bloquearon 15 de 20 ataques y la segunda encontró que no se bloquearon 13 de 26, incluidos reenvío de autorización, sobrescritura de la ventana de inspección y lecturas que continúan tras cancelar. Ninguna demostró liquidación indebida ni filtración de claves. Lo que sí aporta x402 al 0.1.4 es el contrato de efecto pagado con puertos inyectados descrito arriba; el recibo histórico de testnet del 0.1.3 no valida esta integración de referencia.

Esos casos nombrados no explican todos los todo: las pruebas de sustitución de funciones en procedencia documentan la frontera fuera del contrato, y los casos R3 de x402 documentan los límites de salida anidada, confianza en el digest del validador y reconstrucción deliberadamente inaccesible de la clave. La inspección recursiva queda para 0.1.5; las demás fronteras declaradas no prometen arreglos futuros.

No hay registro de emergencia ni claims durables, runtime autónomo entre hosts, planificador, evidencia de mainnet, segundo proveedor de pagos, preparación para producción ni certificación regulatoria. El encadenamiento de recibos, la intención previa al efecto y los presupuestos acumulados siguen abiertos sin promesa de entrega. La arquitectura de trabajo sigue marcando la semántica de operación como SUPPORTED, la operación autónoma como UNTESTED y el Final Vespi Gate como READY_FOR_MUSE_DISCOVERY y NOT_READY_FOR_IMPLEMENTATION; son fronteras de candidatas, no capacidades de runtime entregadas.