These projects remain separate, runnable repositories. / Estos proyectos siguen siendo repositorios ejecutables por separado.
Kernel re-pin, 26 Oct 2026. This project now vendors Vespi kernel 0.1.8 (release v0.1.8-kernel, commit 13dbe24). Suite: 13 of 13 pass in docs/suite-2026-10-26.txt. Mentions of 0.1.6 below describe the 2026-10-11 capture.
Escribano keeps a readable local record of each change to a fictional DAO's governing contract.
The unit is the change and its receipt: what changed, who authorized it, and how it follows the previous version.
Why
Imagine joining an organization after a difficult decision. You can find the current contract, but the person who kept the old copies has left. The document does not tell you which version came first, who approved the change, or why a proposal that lacked enough support was refused. A record that keeps only today's text leaves that explanation in someone's memory.
Escribano explores a local, append-only history in which a contract change is treated as an event with an identifier and a receipt. The record is meant to let a reader follow the change back through earlier versions. The project is a software model of that form; it is not a legal register or a filing service.
In one minute
In a fictional DAO called La Fragua, a member proposes changing the contract's notice period. Bruna, Nilo, and Sabina are fictional members. The proposal does not change the contract by itself. Each person's authority must still be current and within its budget, expiry, and origin; the project counts distinct member identities toward its three-approval threshold. If support is short, the proposal stays pending. If the threshold is met, the intended flow records the change and a receipt in a local append-only file. A reader can then inspect the current version and walk back through the history. The names and scenario are invented for explanation, not evidence of a real organization or filing.
What it looks like in practice
The source README documents a terminal walkthrough using fictional member names. These are the documented commands, not output reproduced from this public checkout:
node src/cli.js proponer c-1 plazo "60 dias"
node src/cli.js firmar c-1 bruna
node src/cli.js decidir c-1 bruna,nilo
node src/cli.js firmar c-1 sabina
node src/cli.js decidir c-1 bruna,nilo,sabina
node src/cli.js estado
node src/cli.js historial
node src/cli.js auditar
The project rules say the first decision is short of the three-member threshold and leaves the proposal pending. The recorded run dated 2026-10-11 records this case passing: the test 1. un cambio sin quórum no entra, y vuelve con la salida que lo dice. An earlier capture, dated 2026-10-03, was red because the project was pinned to an older kernel cut (0.1.3); that re-pin is now done. The public repository has no source or test files with which to reproduce the terminal walkthrough.
Why Escribano
| You need | What it gives you | Where it lives |
|---|
| To understand how the latest contract came to be | A proposed history of changes, receipts, and earlier versions in a local append-only record | How it works |
| To see which people counted toward a change | A model that counts distinct members with current authority, not repeated attestations from one identity | How it works |
| To know why authority is bounded | Rules for budget, expiry, origin, delegation, and revocation | How it works |
| To distinguish a record check from proof of identity | A separate verification model, with the limits of an unkeyed digest explained | Legal and limits |
| To see what was tested and what it covers | Test names, the 2026-10-11 capture, and the recorded result of each case | Evidence |
How it works
member proposes a contract change
|
v
check authority, limits, and distinct approvals
| |
threshold not met threshold met
| |
v v
proposal stays pending append local entry + receipt
|
current version + full history
|
separate verifier checks the record
| Actor | Rights in the model | Limits |
|---|
| Proposer | Any member can propose a change. | A proposal is not an approval and does not change the contract. |
| Members | A member with current authority can attest to a proposal. | Membership alone is not authority. Attestations are fictional and local, not cryptographic signatures. |
| Authorization giver | Grants, delegates, or revokes authority with a budget, expiry, and origin. | Delegation can only reduce authority. Revocation affects future changes and does not erase accepted history. |
| Verifier | Recalculates from the stored record separately from the execution report. | It checks the supplied local data; it does not establish identity, truth, or legal effect. |
| Reader | Reads the current state and full history without special authority. | Reading does not grant power to change the contract. |
The illustrated flow uses three distinct approvals. That threshold is a project design choice. The cited Wyoming provisions do not set a multiple-signature requirement for changing a contract.
What it is not
Escribano is not a legal filing, a legal register, a deployed smart contract, a DAO service, a cryptographic signature system, a blockchain anchor, or legal advice. Its people and approvals are fictional local attestations. Its receipt digest cannot prove who wrote a record or when it existed.
Evidence you can open
The recorded run dated 2026-10-11 reports 13 tests, all passing and none skipped on Node v24.15.0. It ran node --test test/*.test.js in a clean clone of the project with an empty HOME and no network. The kernel is Vespi 0.1.6, commit 39d4573, copied into the project at vendor/vespi-kernel, and the suite checks that copy against its SOURCE.md, module by module and commit by commit. An earlier capture, dated 2026-10-03, was red because the project was pinned to an older kernel cut (0.1.3); that re-pin is since done.
All eight adversarial assertions pass in this run: the missing-quorum detail, the revoked-member detail, identical-change idempotency, reading an older version, altered-history detection, expired authorization, delegated-budget limits, and leaving an under-quorum proposal pending. The phase record says all eight cases were written first and observed red before implementation. See the exact test names and recorded outcomes in Evidence.
The public checkout contains no test files or source code, so this capture cannot be rerun here. The result describes what these thirteen tests exercise; it does not establish a finished or ready-to-use product.
Escribano, Vespi, and Lore Plugin
Escribano consumes Vespi's kernel and the agreement says it does not modify it. The documented design uses the kernel's authority checks, operation receipts, verification separate from execution, and continuity reconstructed from the record. Lore Plugin supplies the installed project context from which Escribano's kernel copy was selected. The current public checkout does not include code for an independent inspection of those integrations. Vespi is the kernel project; Lore Plugin provides the host context described by the agreement.
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.8, in the pinned copy of the v0.1.8-kernel release (vendor/vespi-kernel, commit 13dbe24). 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.
What it does not do, and what is not verified
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.
Escribano does not submit documents to Wyoming, amend filed articles, confer DAO status, create a legal entity, deploy a contract, write to a blockchain, or produce a deposit with legal effect. The agreement cites Wyoming W.S. 17-31 as a reference for the shape of a record with an identifier and update history. It does not claim legal compliance. The project has not been compared with an actual filing process or reviewed by a competent legal professional.
The records and member names are synthetic. Approvals are local attestations, not cryptographic signatures. SHA-256 is unkeyed: someone who can rewrite the local file can recalculate its digest, so it does not prove authenticity or time of creation. There is no blockchain or testnet anchor; the receipt anchor is described as pending. The recorded run of 2026-10-11 passes its 13 tests, and readiness for use is not established. More detail is in Legal and limits.
How to review this project
Start with the agreement's model and the walkthrough in How it works. Compare intended behavior with the recorded results in Evidence, then read Legal and limits. The source is in this repository under the review-only license, whose terms govern reading and evaluation. Run npm test on Node 24 from the project root.
Author
Andrés Peña, repository authority: andresanemic.
How it works · Evidence · Legal and limits · Review-only license · Vespi · Lore Plugin
Nueva fijación del kernel, 26 oct. 2026. Este proyecto ahora vendoriza el kernel de Vespi 0.1.8 (release v0.1.8-kernel, commit 13dbe24). Suite: 13 de 13 aprobadas en docs/suite-2026-10-26.txt. Las menciones a 0.1.6 más abajo describen la captura del 2026-10-11.
Escribano conserva un registro local y legible de cada cambio al contrato rector de una DAO ficticia.
La unidad es el cambio y su recibo: qué cambió, quién lo autorizó y cómo sigue a la versión anterior.
Por qué
Imagina que te incorporas a una organización después de una decisión difícil. Encuentras el contrato vigente, pero la persona que guardaba las copias anteriores ya no está. El documento no te dice qué versión fue primero, quién aprobó el cambio ni por qué se rechazó una propuesta que no tenía suficiente apoyo. Si solo se conserva el texto de hoy, esa explicación queda en la memoria de alguien.
Escribano explora un historial local append-only en el que cada cambio del contrato se trata como un evento con identificador y recibo. El registro busca que quien lo lea pueda seguir el cambio hacia atrás, hasta las versiones anteriores. Es un modelo de software para esa forma de registro, no un registro legal ni un servicio de presentación.
Si estás evaluando Find Your Way o Meridian, empieza aquí
En un minuto
En una DAO ficticia llamada La Fragua, una persona propone cambiar el plazo de aviso del contrato. Bruna, Nilo y Sabina son miembros ficticios. La propuesta no cambia el contrato por sí sola. La autoridad de cada persona debe seguir vigente y respetar su presupuesto, vencimiento y origen; para el umbral de tres aprobaciones del proyecto cuentan identidades distintas. Si falta apoyo, la propuesta queda pendiente. Si se alcanza el umbral, el flujo previsto registra el cambio y un recibo en un archivo local append-only. Después, cualquiera puede revisar la versión actual y recorrer el historial hacia atrás. Los nombres y el caso son inventados para explicar el modelo, no son evidencia de una organización o presentación real.
Cómo se ve en la práctica
El README fuente documenta un recorrido de terminal con nombres de miembros ficticios. Estos son los comandos documentados, no una salida reproducida desde esta copia pública:
node src/cli.js proponer c-1 plazo "60 dias"
node src/cli.js firmar c-1 bruna
node src/cli.js decidir c-1 bruna,nilo
node src/cli.js firmar c-1 sabina
node src/cli.js decidir c-1 bruna,nilo,sabina
node src/cli.js estado
node src/cli.js historial
node src/cli.js auditar
Las reglas del proyecto indican que la primera decisión no alcanza el umbral de tres miembros y deja la propuesta pendiente. La corrida registrada del 2026-10-11 registra este caso como aprobado: la prueba 1. un cambio sin quórum no entra, y vuelve con la salida que lo dice. La captura anterior, del 2026-10-03, estaba en rojo porque el proyecto estaba fijado a un corte anterior del núcleo (0.1.3); esa re-fijación ya está hecha. El código y las pruebas están en este repositorio: ejecuta npm test con Node 24 para repetir la suite.
Por qué Escribano
| Necesitas | Qué te da | Dónde vive |
|---|
| Entender cómo se llegó al contrato vigente | Un historial propuesto de cambios, recibos y versiones anteriores en un registro local append-only | Cómo funciona |
| Ver quién contó para un cambio | Un modelo que cuenta miembros distintos con autoridad vigente, no varias atestaciones de una identidad | Cómo funciona |
| Saber qué límites tiene la autoridad | Reglas de presupuesto, vencimiento, origen, delegación y revocación | Cómo funciona |
| Distinguir una revisión del registro de una prueba de identidad | Un modelo de verificación separado y los límites de un digest sin clave | Marco legal y límites |
| Saber qué se probó y qué cubre | Nombres de pruebas, la captura del 2026-10-11 y el resultado registrado de cada caso | Evidencia |
Cómo funciona
un miembro propone un cambio al contrato
|
v
revisar autoridad, límites y aprobaciones distintas
| |
no alcanza el umbral alcanza el umbral
| |
v v
queda pendiente agregar entrada local + recibo
|
versión actual + historial completo
|
verificador aparte revisa el registro
| Actor | Derechos en el modelo | Límites |
|---|
| Quien propone | Cualquier miembro puede proponer un cambio. | Proponer no es aprobar ni cambia el contrato. |
| Miembros | Quien tiene autoridad vigente puede atestiguar una propuesta. | Ser miembro no basta para tener autoridad. Las atestaciones son ficticias y locales, no firmas criptográficas. |
| Persona que otorga autorizaciones | Otorga, delega o revoca autoridad con presupuesto, vencimiento y origen. | Delegar solo puede reducir autoridad. Revocar afecta cambios futuros y no borra el historial aceptado. |
| Verificador | Recalcula desde el registro almacenado, por separado del informe de ejecución. | Comprueba los datos locales recibidos; no establece identidad, verdad ni efecto legal. |
| Lector | Lee el estado actual y el historial completo sin autoridad especial. | Leer no concede poder para cambiar el contrato. |
El flujo ilustrado usa tres aprobaciones distintas. Ese umbral es una decisión de diseño del proyecto. Los artículos de Wyoming citados no establecen un requisito de varias firmas para cambiar un contrato.
Qué no es
Escribano no es una presentación legal, un registro jurídico, un contrato inteligente desplegado, un servicio DAO, un sistema de firmas criptográficas, un anclaje en blockchain ni asesoría jurídica. Sus personas y aprobaciones son atestaciones locales ficticias. El digest del recibo no puede probar quién escribió el registro ni cuándo existía.
Evidencia que puedes abrir
La corrida registrada del 2026-10-11 informa 13 pruebas, todas aprobadas y ninguna omitida sobre Node v24.15.0. Corrió node --test test/*.test.js en un clon limpio del proyecto, con HOME vacío y sin red. El núcleo es Vespi 0.1.6, commit 39d4573, copiado dentro del proyecto en vendor/vespi-kernel, y la suite verifica esa copia contra su SOURCE.md, módulo por módulo y commit por commit. La captura anterior, del 2026-10-03, estaba en rojo porque el proyecto estaba fijado a un corte anterior del núcleo (0.1.3); esa re-fijación ya está hecha.
Las ocho aserciones adversariales pasan en esta corrida: el detalle del quórum insuficiente, el detalle del miembro revocado, la idempotencia de un cambio repetido, la lectura de una versión anterior, la detección de historial alterado, la autorización vencida, los límites de presupuesto delegado y dejar pendiente una propuesta sin quórum. El registro de fases dice que los ocho casos se escribieron primero y se observaron en rojo antes de implementar. Evidencia conserva sus nombres y resultados registrados.
La copia pública no incluye los archivos de pruebas ni el código, así que no se puede repetir aquí esta corrida. El resultado describe lo que ejercen estas trece pruebas; no demuestra que el producto esté terminado ni listo para usarse.
Escribano, Vespi y Lore Plugin
Escribano consume el núcleo de Vespi y, según el acuerdo, no lo modifica. El diseño documentado usa las comprobaciones de autoridad del núcleo, recibos de operaciones, verificación separada de la ejecución y continuidad reconstruida desde el registro. Lore Plugin aporta el contexto instalado del que se seleccionó la copia del núcleo. El código de esas integraciones está en este repositorio, en src/, para inspeccionarlo por cuenta propia. Vespi es el proyecto del núcleo; Lore Plugin aporta el contexto de hosts descrito en el acuerdo.
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.8, en la copia fijada del release v0.1.8-kernel (vendor/vespi-kernel, commit 13dbe24). 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.
Qué no hace y qué no está verificado
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.
Escribano no presenta documentos en Wyoming, no enmienda artículos depositados, no confiere condición de DAO, no crea una persona jurídica, no despliega contratos, no escribe en una blockchain ni produce un depósito con efecto legal. El acuerdo cita Wyoming W.S. 17-31 como referencia para la forma de un registro con identificador e historial de actualizaciones. No afirma cumplimiento legal. El proyecto no se ha comparado con un proceso real de presentación ni lo ha revisado una persona competente en derecho.
Los registros y nombres de miembros son sintéticos. Las aprobaciones son atestaciones locales, no firmas criptográficas. SHA-256 no usa una clave: quien pueda reescribir el archivo local también puede recalcular su digest, por lo que no prueba autenticidad ni fecha de creación. No hay anclaje en blockchain ni testnet; el anclaje del recibo figura como pending. La corrida registrada del 2026-10-11 aprueba sus 13 pruebas, y no se ha establecido que el proyecto esté listo para usarse. Hay más detalle en Marco legal y límites.
Cómo revisar el proyecto
Empieza por el modelo del acuerdo y el recorrido de Cómo funciona. Compara el comportamiento previsto con los resultados registrados en Evidencia, y luego lee Marco legal y límites. El código está en este repositorio bajo la licencia de solo revisión, que establece las condiciones de lectura y evaluación. Ejecuta npm test con Node 24 desde la raíz del proyecto.
Autor
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
