Vespi Kernel 0.1.7

Vespi Kernel 0.1.7

Continue with the same approval, reconcile uncertain effects

This release keeps the network and resource of a scoped payment approval attached to the operation and its receipt. If a payment stops before send, the memory store lets the same operation retry after renewed approval; once send was called, uncertainty keeps its reservation for reconciliation. Delivered JSON must now match the digest on its receipt.

It also records a rejected valid skill request and provenance verification time, rejects resolver text whose UTF-8 encoding loses information, and contains unreadable nested receipt context as a failed receipt. x402 receipts include the internally computed effect-key hash and version; the public rejection-code catalog is frozen. Effect keys retain their version-2 format.

Evidence

• Kernel: 1,218 passed, 0 failed, 0 TODO, 0 skipped. Frozen suite result.
• x402 demo: 86 passed, using the Stellar SDK with local fixtures; no live payment.
• Twelve pending tests were activated and fixed or strengthened; twelve obsolete or out-of-contract expectations were retired; six regressions were added. Disposition and reasons.
• A separate Sol review found grant scope dropped by operation construction and a hidden serialization hook; both were reproduced, fixed and rechecked. This is our own model review, not an external security audit. Threat model.

Adoption and limits

This is not a test-only release. Existing receipts still verify, but newly built provenance/x402 receipts have additional sealed fields and different digests. Consumers that pin exact result/receipt keys must adapt before adopting it. JSON delivery validators must report SHA-256 of JSON.stringify(output); mismatched hashes, nested accessors/proxies, sparse arrays, hidden fields and serialization hooks are refused. Without output, the digest remains the validator's report.

Explicit grant network/resource constraints are enforced and preserved by operation construction and the human gate. Legacy grants without those fields keep their generic scope. The system clock supplies provenance verification time; it is not authenticated time. Publishing an effect-key hash permits receipt correlation, but does not disclose signed authorization or the private provider hint.

Custom claims stores may offer synchronous releaseEffect only with reservations that do not expire or get reassigned during a run; lease-based stores need owner-bound release and are outside this contract. Memory claims remain process-local. No new mainnet, durability, autonomous runtime or production-security claim is made.

Lore Plugin and all functional projects retain their existing kernel pins. This release does not vendor or repin any of them. The published 0.1.6 tag remains intact.

---

Retomar con la misma aprobación, reconciliar efectos inciertos

Esta release conserva la red y el recurso de una aprobación de pago acotada en la operación y su recibo. Si un pago se detiene antes de enviar, el almacén en memoria permite reintentar la misma operación tras renovar la aprobación; una vez llamado el envío, la incertidumbre conserva la reserva para reconciliar. El JSON entregado debe coincidir con el digest de su recibo.

También registra una solicitud válida de skill rechazada y el instante de verificación de procedencia, rechaza texto del resolver cuya codificación UTF-8 pierde información y contiene contexto anidado ilegible con un recibo fallido. Los recibos x402 incluyen el hash y versión de la clave de efecto calculada dentro del kernel; el catálogo público de códigos queda congelado. Las claves conservan el formato de versión 2.

Evidencia

• Kernel: 1.218 pasan, 0 fallos, 0 TODO, 0 omitidas. Resultado congelado.
• Demo x402: 86 pasan, con SDK de Stellar y fixtures locales; sin pago vivo.
• Doce pruebas pendientes se activaron y corrigieron o reforzaron; doce expectativas obsoletas o fuera del contrato se retiraron; seis regresiones se agregaron. Resolución y motivos.
• Una revisión separada Sol encontró pérdida de alcance al construir operaciones y un hook oculto de serialización; ambos se reprodujeron, corrigieron y re-verificaron. Es revisión propia con modelos, no auditoría externa. Modelo de amenazas.

Adopción y límites

No es una release solo de tests. Los recibos existentes siguen verificando; los nuevos de procedencia/x402 tienen campos sellados adicionales y otros digests. Quien fija las claves exactas de resultados/recibos debe adaptarse antes de adoptar. Los validadores JSON deben reportar SHA-256 de JSON.stringify(output); se rechazan hashes ajenos, accessors/proxies anidados, arrays con huecos, campos ocultos y hooks de serialización. Sin output, el digest sigue siendo reporte del validador.

Se conservan y exigen los alcances explícitos de red/recurso al crear operaciones y aprobar en la puerta humana. Los grants antiguos sin esos campos mantienen su alcance genérico. La hora de verificación viene del reloj del proceso, sin autenticar tiempo externo. Publicar el hash de la clave permite relacionar recibos, sin divulgar autorización firmada ni hint privado del proveedor.

Los almacenes externos pueden ofrecer releaseEffect síncrono únicamente con reservas que no expiren ni se reasignen durante el run; los almacenes con leases necesitan liberación ligada al propietario y quedan fuera del contrato. Los claims en memoria siguen ligados al proceso. No se afirma nueva capacidad mainnet, durabilidad, runtime autónomo ni seguridad de producción.

Lore Plugin y los proyectos funcionales conservan sus pins existentes. Esta release no vendoriza ni cambia sus versiones de kernel. El tag publicado de 0.1.6 permanece intacto.

GitHub validation / Verificación en GitHub

Commit: 35d0094fd477f164b23333d1f00afb32407511ea.

• Kernel CI: 1,218/1,218 on Linux, macOS and Windows; no failures, skipped tests or TODOs.
• CodeQL: JavaScript/TypeScript and GitHub Actions analyses succeeded.
• CodeQL and secret-scanning open alerts: 0 at publication. Dependabot alerts are disabled in the repository; this release does not change that setting.
• Las 139 rutas de las 12 copias fijadas comprobadas permanecieron idénticas; no se vendorizó ni repineó Lore Plugin o proyectos funcionales.

Vespi Kernel 0.1.6 · Servine

Servine

Vespi Kernel 0.1.6 · local cut

This cut contains the local commits after 0.1.5. The skill provenance resolver now preserves every unique declared capability when a duplicate appears before a unique name. A regression test prevents URL checks based on substring matching. The README, judge guide and capability catalog now enter from a single English hero with a separate Spanish box.

The cut also adds examples/refusal.js, which shows an over-limit operation refused and an in-limit one verified, a threat model and a note on why Stellar, and the README now says exactly what the x402 demo adapter is. No runtime capability was added. The package remains a source checkout, not an npm package.

Review. This cut went through a superreview run with the multi-agent code review of Claude Code: five findings, one of them normal (the duplicated capability above), fixed in this cut. Those are our own reviews: there is no independent external security audit. See the threat model.

Find Your Way: the submission is complete, with its video, and this is the last tag before it. The complete suite result is recorded in SUITE_RESULT_0.1.6.txt.

---

Vespi Kernel 0.1.6 · corte local

Este corte reúne los commits locales posteriores a 0.1.5. El resolver de procedencia conserva cada capacidad declarada única aunque antes aparezca un nombre duplicado. Una regresión impide comprobar URLs mediante coincidencias de subcadenas. El README, la guía para jueces y el catálogo de capacidades comparten ahora una sola entrada en inglés y una caja separada en español.

El corte agrega además examples/refusal.js, que muestra una operación fuera del límite rechazada y una dentro del límite verificada, un modelo de amenazas y una nota de por qué Stellar, y el README dice ahora exactamente qué es el adaptador de demo x402. No se agregó una capacidad de ejecución. El paquete sigue siendo un checkout fuente, no un paquete npm.

Revisión. Este corte pasó por una superreview hecha con la revisión de código multiagente de Claude Code: cinco hallazgos, uno normal (la capacidad duplicada de arriba), corregido en este corte. Son revisiones propias: no hay auditoría de seguridad externa independiente. Ver el modelo de amenazas.

Find Your Way: la postulación está completa, con su video, y este es el último tag antes de él. El resultado de la suite completa está en SUITE_RESULT_0.1.6.txt.

Vespi kernel 0.1.5

Vespi kernel 0.1.5

English

A receipt left pending before anchor confirmation now keeps the selected network. buildReceipt({ anchorNetwork }) accepts stellar:testnet and stellar:pubnet; testnet remains the default. Naming a network does not submit a transaction.

An opt-in x402 reference bridge under demo/x402/ is selected with --bridge=1. It binds a signed authorization to the declared Stellar transfer and bounds/cancels Horizon reads. A malformed resolved Horizon response returns a closed failure. The bridge does not make payments for the host.

Evidence for the tagged cut: kernel suite 1,220 tests, 1,196 passed, 0 failed and 24 explicit TODO; x402 demo 86/86; benchmark harness 3 shape checks. Stellar SDK fixtures use loopback: they do not prove live payment, mainnet settlement, production security or comparative superiority. Durable storage, host identity, budget and autonomous execution remain outside this kernel.

Tagged source and limits · Detailed note

Español

El recibo de una operación detenida antes de confirmar su ancla conserva la red elegida. buildReceipt({ anchorNetwork }) acepta stellar:testnet y stellar:pubnet; testnet sigue siendo el valor por defecto. Nombrar la red no envía una transacción.

Incluye un puente x402 de referencia opt-in en demo/x402/, activable con --bridge=1. Vincula una autorización firmada a la transferencia Stellar declarada y acota/cancela las lecturas de Horizon. Una respuesta Horizon malformada devuelve un fallo cerrado. El puente no ejecuta pagos por el host.

Evidencia local del corte etiquetado: suite kernel 1.220 pruebas, 1.196 correctas, 0 fallos y 24 todo explícitos; demo x402 86/86; arnés de benchmark 3 comprobaciones de forma. Las fixtures con Stellar SDK usan loopback: no acreditan pago vivo, liquidación en mainnet, seguridad de producción ni ventaja comparativa. Almacenamiento durable, identidad del host, presupuesto y ejecución autónoma siguen fuera del kernel.

Código y límites del tag · Nota detallada

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...

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 rein...

v0.1.2-kernel — local boundary and preflight

v0.1.2-kernel

Local boundary and preflight · The current operation stays bounded.

This release hardens the local x402 boundary and makes the public surface explicitly bilingual. Local verification: 47/47 kernel tests and 53/53 x402 demo tests. The paid testnet path remains separate; this release makes no new live claim.

Fixed

• Prepared Soroban transfer and authorization-digest checks run before the paid request.
• Malformed prepared payloads fail before a second request.
• Local idempotency remains explicitly in-process and after x402 processing.
• README, demo guide, Genesis and Changelog distinguish current local state from future direction and historical evidence.
• Node 24+ is declared for the demo package.

Still not claimed

Durable cross-process operation storage, durable idempotency, production payment readiness, a general orchestration runtime or automatic Lore writes.

---

v0.1.2-kernel — Español

Frontera local y preflight · La operación actual sigue acotada.

Este release endurece la frontera local de x402 y hace explícitamente bilingüe la superficie pública. Verificación local: 47/47 tests del kernel y 53/53 tests de la demo x402. La ruta pagada de testnet sigue separada; este release no introduce una nueva afirmación de pago real.

Corregido

• La transferencia Soroban preparada y el digest de autorización se comprueban antes de la solicitud pagada.
• Los payloads preparados malformados fallan antes de una segunda solicitud.
• La idempotencia local queda explícitamente dentro del proceso y después del procesamiento x402.
• README, guía de la demo, Genesis y Changelog distinguen el estado local actual de la dirección futura y la evidencia histórica.
• Node 24+ queda declarado para el paquete de la demo.

Todavía no afirmado

Almacenamiento durable de operaciones entre procesos, idempotencia durable, preparación para pagos de producción, runtime general de orchestration o escrituras automáticas en Lore.

v0.1.1-kernel — authority hardening

v0.1.1-kernel

Hardening · Authority integrity, proven by tests.

External review findings, closed with TDD (16/16 green). No new capabilities.

Fixed

• Verifier exception after side effect returns a durable not_verified receipt (evidence kept, no rerun, never running, never verified).
• Grant consumption is per-grant, not per destination: split requirements against one grant share its single maxAmount; destination-specific grants keep separate budgets.
• Gate provenance survives terminal outcomes: receipts record preauthorized / human_gate_approved / human_gate_rejected, including failed runs.
• Changelog history kept honest (v0.1.0-kernel untouched); test command documented; autonomy working direction published as direction, not capability.

Still not claimed

General orchestration, arbitrary capabilities, production payments, swarms, multi-run budgeting.

---

v0.1.1-kernel — Español

Endurecimiento · Integridad de authority, probada con tests.

Hallazgos de revisión externa, cerrados con TDD (16/16 en verde). Sin capabilities nuevas.

Corregido

• Excepción del verificador tras side effect devuelve recibo not_verified durable (evidencia guardada, sin reintento, nunca running, nunca verified).
• El consumo es por grant, no por destino: requirements divididos contra un grant comparten su único maxAmount; grants con destino mantienen presupuestos separados.
• La provenance del gate sobrevive resultados terminales: los recibos registran preauthorized / human_gate_approved / human_gate_rejected, incluso en corridas fallidas.
• Historial del Changelog honesto (v0.1.0-kernel intacto); comando de tests documentado; dirección de autonomía publicada como dirección, no capability.

Todavía no afirmado

Orquestación general, capabilities arbitrarias, pagos productivos, enjambres, presupuesto multi-run.

v0.1.0-kernel — first executable code

v0.1.0-kernel

First executable code · The operation runs.

Vespi grows its first reusable code: a minimal executable operation kernel (src/, zero dependencies, 8/8 tests green) exercised against an x402/Stellar testnet capability (demo/x402).

The same operation gates without authority (needs_human_decision, zero side effect) and continues with it — 0.01 testnet USDC settled and independently verified (experiments/002). The Operator-Professor loop runs with zero human interventions (experiments/001).

What exists

• Minimal operation kernel: goal, requirements, authority check, human gate only when insufficient, execute, verify, receipt.
• x402 v2 round-trip behind a real boundary: the kernel imports nothing x402/Stellar.
• Three recorded paths (success, rejected_policy, rejected_human) plus one real verification failure kept as evidence.
• Counterparty-bound grants (destination travels with the approval).

What this release does not claim

General orchestration, arbitrary capabilities, production payments, swarms, brief generation (deterministic template, declared), multi-run budgeting. Demo accounts are temporary; the production receiver is pending.

---

v0.1.0-kernel — Español

Primer código ejecutable · La operación corre.

Vespi suma su primer código reusable: un kernel de operación ejecutable mínimo (src/, cero dependencias, 8/8 tests en verde) ejercido contra una capability x402/Stellar testnet (demo/x402).

La misma operación frena sin authority (needs_human_decision, cero side effect) y continúa con ella — 0.01 USDC testnet liquidados y verificados independientemente (experiments/002). El loop Operador-Professor corre con cero intervenciones humanas (experiments/001).

Qué existe

• Kernel de operación mínimo: goal, requirements, chequeo de authority, gate humano solo si falta, ejecutar, verificar, recibo.
• Round-trip x402 v2 detrás de una frontera real: el kernel no importa nada x402/Stellar.
• Tres caminos registrados (éxito, rejected_policy, rejected_human) más un fallo de verificación real conservado como evidencia.
• Grants con contraparte (el destino viaja con la aprobación).

Qué no afirma este release

Orquestación general, capabilities arbitrarias, pagos productivos, enjambres, generación de brief (plantilla determinista, declarada), presupuesto multi-run. Las cuentas demo son temporales; el receptor productivo sigue pendiente.

Genesis · The unit is the operation.

v0.0.1-genesis

Genesis · The unit is the operation.

This is the first public snapshot of Vespi.

It is intentionally small. The purpose of this release is to make the origin visible before the implementation hardens.

What exists

• A bilingual public definition of the problem.
• A provisional operation-first architecture.
• Explicit separation between capability, context, visibility and authority.
• A first model of heterogeneous bodies and bounded authority.
• The initial Stellar flagship direction.
• A public genesis that records both current theses and current non-claims.

What this release does not claim

This is not a production runtime, stable protocol, compliance product or finished multi-agent framework.

The architecture is still being arbitrated in public.

Why publish this early?

Because the history is part of the evidence.

Vespi should not arrive later with a polished origin story. Specs, rejected ideas, tests, RCs and changes of direction should remain inspectable as they happen.

Vespi is being defined in public. This repository records not only what survives, but what gets rejected.

---

v0.0.1-genesis — Español

Génesis · La unidad es la operación.

Este es el primer corte público de Vespi.

Es deliberadamente pequeño. El objetivo de este release es hacer visible el origen antes de que la implementación se endurezca.

Qué existe

• Una definición pública bilingüe del problema.
• Una arquitectura provisional centrada en la operación.
• Separación explícita entre capability, context, visibility y authority.
• Un primer modelo de cuerpos heterogéneos y authority acotada.
• La dirección inicial del flagship Stellar.
• Un génesis público que registra tanto las tesis actuales como aquello que todavía no afirmamos.

Qué no afirma este release

Esto no es todavía un runtime de producción, un protocolo estable, un producto de compliance ni un framework multiagente terminado.

La arquitectura sigue bajo arbitraje público.

¿Por qué publicarlo tan temprano?

Porque la historia también es evidencia.

Vespi no debería aparecer después con un relato de origen perfecto. Specs, ideas rechazadas, tests, RCs y cambios de dirección deben quedar inspeccionables mientras ocurren.

---