Queen — a budget proposal is often unclear: who asked, who could answer, what the price covers.
The brief and the approved limits travel with the proposal. Evidence: 45/45 tests. Fictional clients and campaigns.
We submitted Vespi to the Find Your Way hackathon and plan to participate in Meridian.
For judges: How it works · Evidence · Limits · Review-only license.
The source is in this repository: run npm test on Node 24.
Run it / Córrelo
git clone https://github.com/andresanemic/queen.git
cd queen
npm test
npm run recorridoNode 24. npm test runs the suite; npm run recorrido replays the walkthrough. / Node 24. npm test ejecuta la suite; npm run recorrido repite el recorrido.
These projects remain separate, runnable repositories. Vespi Desktop is the planned workspace for the kit and kernel, with Hive as its creation studio; this project is not yet integrated into an installable Desktop app. / Estos proyectos siguen siendo repositorios ejecutables por separado. Vespi Desktop será el espacio de trabajo del kit y el kernel, con Hive como taller de creación; este proyecto aún no está integrado en una app Desktop instalable.
Read in English
Queen makes a budget proposal only after the commissioning project has answered through a receipted conversation, and only within the authority a person granted.
The unit is the receipted conversation: without an open, read conversation with the project that made the request, there is no proposal.
Queen is a fictional marketing-agency scenario for a narrower coordination problem. A project asks for a proposal, but an agent cannot safely fill the gaps from memory or accept whichever nearby voice replies. Queen opens a conversation with the commissioning project through Vespi, asks for what is missing, checks that the answer has a valid receipt and belongs to the right project and scope, and then formulates within a human-granted spending ceiling. The marketing agency is the setting. What the project demonstrates is coordination within authority. Its x402 payment layer checks and records a simulated payment request; settlement is not real.
A request for a budget can arrive with missing detail and no durable trail. If an agent guesses, the proposal may describe work nobody asked for. If a neighboring project or observer answers, their words may be mistaken for the commissioning project's authority. If the same request is formulated twice, a second price can appear beside the first. These are small handoffs with consequential ambiguity: who asked, who was allowed to answer, what the price covers, and who set the ceiling can disappear between a conversation and a quote.
Queen makes that handoff readable. A third party can follow the request, the conversation, a rejected answer, the accepted answer, the ceiling check, and the receipt in a local record. The point is not to make a marketing decision for anyone. It is to leave enough context around a proposal for another person to see why it exists and where the authority ends.
The example follows proyecto-corcheta, a fictional project that asks Queen for a launch campaign budget for three pieces. A person gives Queen an example mandate capped at 80,000 USD, with a destination and a named pause authority. Queen opens and confirms the conversation, asks what pieces are needed and when, and records an interjection from observador-externo as a rejection because that observer is not the commissioning project. proyecto-corcheta then answers with a verifiable receipt. The recorded proposal totals 70,000 USD, below the example ceiling. Queen shows the cost before the payment step, labels settlement simulated, verifies the receipt separately, and leaves one proposal line even when the same request is formulated again. The record says the external anchor is pending. There is no real payment, network settlement or public transaction hash.
The following is a faithful excerpt from the recorded walkthrough. Identifiers, destination and amounts are fictional or synthetic examples. The event labels and reported amounts are copied from the captured terminal screen; the excerpt does not describe a live payment.
encargo_recibido proyecto-corcheta: presupuesto para una campana de lanzamiento de tres piezas
conversacion_abierta con proyecto-corcheta
lectura_confirmada lee el encargo
pregunta a proyecto-corcheta: que piezas necesita y cuantas
pregunta a proyecto-corcheta: para cuando las necesita y con que destino de cobro
mensaje_de_tercero observador-externo: habla en la conversacion pero no es la contraparte
respuesta_rechazada observador-externo: observador-externo no es la contraparte del encargo enc-corcheta-001
respuesta_aceptada proyecto-corcheta firma b1f10aaeeadd...
propuesta_formulada 70000 USD
pago_simulado 70000 USD -> billetera-de-ejemplo (simulado)
verificacion por verificador-externo: 4 ok, 3 no
recibo 7246db9a5d6c...
cierre completa
The receipt separates the checks that passed from the claims it cannot cover:
Estado: verified
Capacidad: pago-x402-simulado
Firma: 7246db9a5d6ca7654dedb6f2479d3a41...
Anclaje: pending (stellar:testnet)
Verifico: el verificador externo, sobre la evidencia
Cubierto: el gasto declarado cabe en el techo del mandato | el efecto quedo en el destino que declara el mandato | quien pago es la contraparte del encargo | el pago se declaro simulado y no como pago real
NO cubierto: x402 settlement on a live network | tx hash on-chain in a public explorer | pago real a un tercero real | external anchor
Those excerpts show a local software walkthrough, not a production transcript. The same recorded run reports that the receipt chain has 13 lines, a repeated formulation returns the same receipt, and only one proposal line and one simulated payment request were recorded. The project sources do not include a real service response or market validation.
| You need | What it gives you | Where it lives |
|---|---|---|
| A proposal grounded in a request | A conversation opened and read with the commissioning project before formulation | How it works |
| The right project to answer | A receipted reply is checked against the counterparty and the request's scope; the observer's message remains a rejection | How it works |
| A budget bounded by a person's mandate | A hard ceiling; an amount above it returns blocked before the payment request | How it works |
| One result when the same request is formulated again | The second formulation returns the same receipt and does not add another proposal line | Evidence |
| A record a reviewer can inspect | A local hash-linked log and receipts that include rejected input and declared coverage | Evidence |
Queen is a project walkthrough about an agent asking, checking, formulating and recording within granted authority. Its unit is the conversation that has been opened, read and answered with a receipt. It is not a marketing service, CRM, sales funnel, payment product or blockchain application. It does not decide whether a proposal is good, promise acceptance, consent for the person who granted authority or settle a real payment.
Two sources of authority meet, but do not replace one another. The person's mandate gives Queen a hard ceiling, asset, destination, expiry and pause authority. The commissioning project's request defines the work and the only project whose in-scope answer counts.
Person's mandate Commissioning project's request
ceiling · asset · destination scope · conversation · answer
\ /
v v
Queen opens and reads the conversation
asks · checks scope and receipt
rejects an out-of-scope speaker
|
v
proposal within the hard ceiling
|
v
simulated payment request · sealed receipt
|
v
local linked record · separate verifier
|
v
third-party reader
| Actor | Rights and role | Boundary |
|---|---|---|
| Person granting the mandate | Sets the ceiling, asset, destination, expiry and who may pause | Queen cannot enlarge the grant. An expired mandate does not revive by itself. |
| Commissioning project | Opens the request and is the only project whose in-scope answer counts | A nearby speaker or a reply outside the request's scope is rejected. |
| Queen | Asks, checks receipts, formulates, requests simulated payment and records the route | It cannot consent for the person or exceed the ceiling. |
| Separate verifier | Recalculates checks from evidence instead of relying on the executor's report | It does not establish factual truth or external settlement. |
| Third reader | Reads the local record and receipts without Queen | Hash links reveal edits to the presented file; they do not identify who authored or preserved it. |
The recorded run of 2026-10-11 reports 45 tests, pass 45, fail 0, skipped 0, on Node v24.15.0, run in a clean clone with empty HOME and no network. Passing cases cover the complete request-to-proposal route, receipts and their declared coverage, simulated-payment disclosure, the pending external anchor, separate verification, local-chain auditing, reconstruction from receipts, rejection of an unauthorized speaker, the hard ceiling and idempotent formulation. The five adversarial RED cases and one control case were written and observed before implementation. Their names and scope are listed in Evidence. The 2026-10-03 capture was red because the project was pinned to an old kernel cut (0.1.3); that re-pin to Vespi 0.1.6 (commit 39d4573) is done and verified in the new capture.
The kernel checks pass in the new capture: the suite verifies the copy vendored in vendor/vespi-kernel against its SOURCE.md (per-module digest and commit) for Vespi 0.1.6 (39d45733839d0a05f60248fc6e5b81c892c464f8).
Lore Plugin supplies the project-routing and coordination setting described by Queen's agreement. Queen uses Vespi's kernel for bounded authority, operations, receipts, a human gate that shows the cost before the payment request, separate verification and continuation from receipts. Its conversation is implemented as a delegation, so a reply needs the right scope and a verifiable receipt. The agreement says Queen loads a vendored copy and fixes the kernel modules by digest. The earlier digest mismatches are recorded in Evidence; the new capture shows the re-pinned kernel verifying.
What this relationship means. The project was built with Lore Plugin's method (its agreement and criterion live in the project, in acuerdo.md and lore/), and its operations, authority and receipts run on the Vespi kernel 0.1.6, in the pinned copy prepared for Lore Plugin 2.5.2 (skills/vespi/core/kernel). That copy sits in the project as vendor/vespi-kernel and the suite verifies it against its SOURCE.md. Lore Plugin does not run inside the project. This project does not use the kernel's newer capabilities (Stellar pubnet anchors, live x402 settlement, the ZK verifier, emergency access); it exercises the core of operations, authority and receipts.
Review status: this project has not been audited. The Vespi kernel it runs on has had superreviews with Claude Code and no independent external security audit.
The payment settlement is simulated. There is no network call, real x402 settlement, blockchain write, Stellar testnet transaction, public transaction hash or completed external anchor; the receipt says pending. The project's agreement says the primary x402 specification was not read, so Queen makes no conformance claim. The names, destination and amounts in the walkthrough are fictional or synthetic. The hash-linked file can be replaced and its chain recomputed by someone who can rewrite the whole file. A verified receipt describes checks against supplied evidence; it does not prove a real-world payment, authorship or factual truth. The green suite accredits only what those tests cover; it does not establish production readiness, adoption or acceptance. Legal and limits records the rest of the boundary.
Read the walkthrough, then compare the test record and limits with the project agreement. The source is in this repository under the review-only license, which permits reading and cloning for evaluation. Run npm test on Node 24 from the project root and compare its output with Evidence. The kernel re-pin is done, so a reviewer can expect a clean run against the vendored kernel and compare it with the reference docs/suite-2026-10-11.txt.
Andrés Peña, repository authority: andresanemic.
How it works · Evidence · Legal and limits · Review-only license · Vespi · Lore Plugin
Leer en español
Funcionó.
Queen formula un presupuesto solo después de que el proyecto contratante haya respondido en una conversación con recibo, y únicamente dentro de la autoridad que concedió una persona.
La unidad es la conversación con recibo: sin una conversación abierta y leída con el proyecto que hizo el encargo, no hay propuesta.
Queen es un escenario ficticio de agencia de marketing para un problema más acotado de coordinación. Un proyecto pide una propuesta, pero un agente no puede completar con seguridad los vacíos de memoria ni aceptar la respuesta de cualquier voz cercana. Queen abre una conversación con el proyecto contratante a través de Vespi, pregunta lo que falta, comprueba que la respuesta tenga un recibo válido y corresponda al proyecto y al alcance correctos, y después formula dentro de un techo de gasto concedido por una persona. La agencia de marketing es el escenario. Lo que el proyecto muestra es coordinación dentro de la autoridad. Su capa de pago x402 comprueba y registra una solicitud de pago simulada; la liquidación no es real.
Una solicitud de presupuesto puede llegar con datos incompletos y sin un rastro duradero. Si el agente adivina, la propuesta puede describir un trabajo que nadie pidió. Si responde un proyecto vecino o una persona observadora, sus palabras pueden confundirse con la autoridad del proyecto contratante. Si el mismo encargo se formula dos veces, puede aparecer un segundo precio junto al primero. Son ambigüedades pequeñas en un traspaso con consecuencias: entre la conversación y la cotización pueden perderse quién pidió, quién podía responder, qué cubre el precio y quién fijó el techo.
Queen deja ese traspaso legible. Una tercera persona puede seguir el encargo, la conversación, una respuesta rechazada, la respuesta aceptada, la comprobación del techo y el recibo en un registro local. El objetivo no es decidir por nadie si una campaña conviene. Es conservar contexto suficiente alrededor de una propuesta para que otra persona pueda entender por qué existe y dónde termina la autoridad.
- Lee la base del proyecto y su recorrido. Empieza por Cómo funciona.
- Abre el registro de pruebas. Consulta Evidencia.
- Lee los límites jurídicos y de verificación. Consulta Marco legal y límites.
- Lee los términos en la licencia de solo revisión y ejecuta
npm test(Node 24).
El ejemplo sigue a proyecto-corcheta, un proyecto ficticio que pide a Queen un presupuesto para una campaña de lanzamiento de tres piezas. Una persona entrega a Queen un mandato de ejemplo con un techo de 80.000 USD, un destino y una autoridad de pausa. Queen abre y confirma la conversación, pregunta qué piezas hacen falta y para cuándo, y registra la intervención de observador-externo como rechazo porque esa persona no es el proyecto contratante. Después, proyecto-corcheta responde con un recibo verificable. La propuesta registrada suma 70.000 USD, por debajo del techo de ejemplo. Queen muestra el costo antes del paso de pago, etiqueta la liquidación como simulada, verifica el recibo por separado y deja una sola línea de propuesta aunque el mismo encargo se vuelva a formular. El registro deja el anclaje externo en pending. No hay pago real, liquidación en red ni hash público de transacción.
El siguiente bloque es un extracto fiel del recorrido registrado. Los identificadores, el destino y los montos son ficticios o sintéticos. Las etiquetas de eventos y los montos informados se copian de la pantalla de terminal capturada; el extracto no describe un pago en vivo.
encargo_recibido proyecto-corcheta: presupuesto para una campana de lanzamiento de tres piezas
conversacion_abierta con proyecto-corcheta
lectura_confirmada lee el encargo
pregunta a proyecto-corcheta: que piezas necesita y cuantas
pregunta a proyecto-corcheta: para cuando las necesita y con que destino de cobro
mensaje_de_tercero observador-externo: habla en la conversacion pero no es la contraparte
respuesta_rechazada observador-externo: observador-externo no es la contraparte del encargo enc-corcheta-001
respuesta_aceptada proyecto-corcheta firma b1f10aaeeadd...
propuesta_formulada 70000 USD
pago_simulado 70000 USD -> billetera-de-ejemplo (simulado)
verificacion por verificador-externo: 4 ok, 3 no
recibo 7246db9a5d6c...
cierre completa
El recibo separa las comprobaciones que pasaron de las afirmaciones que no puede cubrir:
Estado: verified
Capacidad: pago-x402-simulado
Firma: 7246db9a5d6ca7654dedb6f2479d3a41...
Anclaje: pending (stellar:testnet)
Verifico: el verificador externo, sobre la evidencia
Cubierto: el gasto declarado cabe en el techo del mandato | el efecto quedo en el destino que declara el mandato | quien pago es la contraparte del encargo | el pago se declaro simulado y no como pago real
NO cubierto: x402 settlement on a live network | tx hash on-chain in a public explorer | pago real a un tercero real | external anchor
Esos extractos muestran un recorrido local de software, no una transcripción de producción. La misma corrida registrada informa que la cadena del recibo tiene 13 líneas, que una formulación repetida devuelve el mismo recibo y que quedó registrada una sola propuesta y una sola solicitud de pago simulado. Las fuentes del proyecto no contienen respuestas de un servicio real ni validación de mercado.
| Necesitas | Qué te da | Dónde está |
|---|---|---|
| Una propuesta fundada en un encargo | Una conversación abierta y leída con el proyecto contratante antes de formular | Cómo funciona |
| Que responda el proyecto correcto | La respuesta con recibo se contrasta con la contraparte y el alcance; el mensaje del observador queda rechazado | Cómo funciona |
| Un presupuesto limitado por el mandato de una persona | Un techo duro; si lo supera, vuelve bloqueado antes de solicitar el pago | Cómo funciona |
| Un solo resultado al volver a formular el mismo encargo | La segunda formulación devuelve el mismo recibo y no agrega otra línea de propuesta | Evidencia |
| Un registro que pueda revisar otra persona | Un registro local de huellas encadenadas y recibos que incluye entradas rechazadas y cobertura declarada | Evidencia |
Queen es un recorrido de proyecto sobre un agente que pregunta, comprueba, formula y registra dentro de una autoridad concedida. Su unidad es la conversación abierta, leída y respondida con recibo. No es un servicio de marketing, CRM, embudo de ventas, producto de pagos ni aplicación de blockchain. No decide si una propuesta es buena, no promete que la aceptarán, no consiente por la persona que concedió la autoridad ni liquida pagos reales.
Se encuentran dos fuentes de autoridad, pero ninguna reemplaza a la otra. El mandato de la persona da a Queen un techo duro, un activo, un destino, un vencimiento y una autoridad de pausa. El encargo del proyecto contratante define el trabajo y cuál es el único proyecto cuya respuesta dentro del alcance cuenta.
Mandato de la persona Encargo del proyecto contratante
techo · activo · destino alcance · conversación · respuesta
\ /
v v
Queen abre y lee la conversación
pregunta · revisa alcance y recibo
rechaza voces fuera de alcance
|
v
propuesta bajo el techo duro
|
v
solicitud de pago simulada · recibo sellado
|
v
registro local encadenado · verificador separado
|
v
tercera persona lectora
| Actor | Derechos y función | Límite |
|---|---|---|
| Persona que concede el mandato | Fija el techo, activo, destino, vencimiento y quién puede pausar | Queen no puede ampliar el permiso. Un mandato vencido no revive por sí solo. |
| Proyecto contratante | Abre el encargo y es el único proyecto cuya respuesta dentro del alcance cuenta | Se rechaza a una voz cercana o una respuesta fuera del alcance del encargo. |
| Queen | Pregunta, comprueba recibos, formula, solicita el pago simulado y registra el recorrido | No puede consentir por la persona ni superar el techo. |
| Verificador separado | Recalcula las comprobaciones desde la evidencia en lugar de confiar en el informe del ejecutor | No establece la verdad factual ni una liquidación externa. |
| Tercera persona lectora | Lee el registro local y los recibos sin Queen | Las huellas revelan ediciones del archivo presentado; no identifican quién lo creó o conservó. |
La ejecución registrada del 2026-10-11 informa 45 pruebas, 45 aprobadas, 0 fallan, 0 omitidas, en Node v24.15.0, corrida en un clon limpio con HOME vacío y sin red. Los casos aprobados cubren el recorrido completo desde el encargo hasta la propuesta, los recibos y su cobertura declarada, la declaración del pago simulado, el anclaje externo en pending, la verificación separada, la auditoría de la cadena local, la reconstrucción desde recibos, el rechazo de una voz no autorizada, el techo duro y la formulación idempotente. Los cinco casos adversariales RED y un caso de control se escribieron y observaron antes de la implementación. Evidencia enumera sus nombres y alcance. La captura del 2026-10-03 estaba en rojo porque el proyecto apuntaba a un corte viejo del kernel (0.1.3); esa nueva fijación a Vespi 0.1.6 (commit 39d4573) ya está hecha y verificada en la captura nueva.
Los controles del kernel pasan en la captura nueva: la suite verifica la copia vendorizada en vendor/vespi-kernel contra su SOURCE.md (digest por módulo y commit) para Vespi 0.1.6 (39d45733839d0a05f60248fc6e5b81c892c464f8).
Lore Plugin aporta el marco de enrutamiento entre proyectos y coordinación que describe el acuerdo de Queen. Queen usa el kernel de Vespi para la autoridad acotada, las operaciones, los recibos, una compuerta humana que muestra el costo antes de solicitar el pago, la verificación separada y la continuación desde recibos. La conversación de Queen se implementa como una delegación, por lo que la respuesta necesita el alcance correcto y un recibo verificable. El acuerdo dice que Queen carga una copia vendorizada y fija por digest los módulos del kernel. Los desajustes anteriores de digest quedaron registrados en Evidencia; la captura nueva muestra el kernel con la fijación nueva verificado.
Qué significa esta relación. El proyecto se construyó con el método de Lore Plugin (su acuerdo y su criterio viven en el proyecto, en acuerdo.md y lore/), y sus operaciones, autoridad y recibos corren sobre el kernel de Vespi 0.1.6, en la copia fijada para Lore Plugin 2.5.2 (skills/vespi/core/kernel). Esa copia está en el proyecto como vendor/vespi-kernel y la suite la verifica contra su SOURCE.md. Lore Plugin no corre dentro del proyecto. Este proyecto no usa las capacidades nuevas del kernel (anclas Stellar pubnet, liquidación x402 en vivo, el verificador ZK, el acceso de emergencia); ejerce el núcleo de operaciones, autoridad y recibos.
Estado de revisión: este proyecto no ha sido auditado. El kernel de Vespi sobre el que corre ha tenido superreviews con Claude Code y ninguna auditoría de seguridad externa independiente.
La liquidación del pago es simulada. No hay llamada de red, liquidación x402 real, escritura en blockchain, transacción en Stellar testnet, hash público de transacción ni anclaje externo completado; el recibo dice pending. El acuerdo del proyecto dice que no se leyó la especificación primaria de x402, así que Queen no afirma conformidad. Los nombres, el destino y los montos del recorrido son ficticios o sintéticos. Una persona que pueda reemplazar el archivo completo puede recalcular la cadena de huellas. Un recibo verificado describe comprobaciones sobre la evidencia suministrada; no prueba un pago real, autoría ni verdad factual. La suite en verde acredita solo lo que esas pruebas cubren; no demuestra que el proyecto esté listo para producción, que tenga adopción ni que haya sido aceptado. Marco legal y límites registra las demás fronteras.
Lee el recorrido y compara después el registro de pruebas y los límites con el acuerdo. El código está en este repositorio bajo la licencia de solo revisión, que permite leerlo y clonarlo para evaluarlo. Ejecuta npm test con Node 24 desde la raíz del proyecto y compara su salida con Evidencia. La nueva fijación del kernel ya está hecha, así que quien revise puede esperar una ejecución limpia frente al kernel vendorizado y compararla con la referencia docs/suite-2026-10-11.txt.
Andrés Peña, autoridad del repositorio: andresanemic.
Cómo funciona · Evidencia · Marco legal y límites · Licencia de solo revisión · Vespi · Lore Plugin