0 · EL CATÁLOGO DE CLASES — la documentación viva

LAS CLASES — valor campo (el formato) · objeto valor (el origen, content-addressed)

Documento VIVO (se actualiza aquí — 2026-08-25).

Documento VIVO (se actualiza aquí — 2026-08-25). Arriba: el catálogo vigente, cada clase con sus propiedades y a qué acción de campo afecta (chips). Debajo: LAS PROPIEDADES de la forma, cada una con todas sus variables, la estandarización adoptada, su evidencia documental y ejemplos. Cada propiedad lleva su evaluación 🤖 AI FIRST (cómo afecta el estándar al consumidor agente — entender · aprender · recuperar — y si es la mejor opción). Lo propuesta espera dictado; lo andamio converge con su was_to_be.

A FUTURO — LA ACTUALIZACIÓN CONTINUA (dictado 2026-08-25):

A FUTURO — LA ACTUALIZACIÓN CONTINUA (dictado 2026-08-25): cuando el contrato aarpia VOE (los 6 contextos de clases) tenga su propio contexto en su nodo con su ContextVM, será un contexto de instancias CONTINUAMENTE ACTUALIZADAS — cada actualización de una clase será una instancia nueva con su evento firmado y su snapshot: el registro solo crece, cada versión queda trazable por su ⬡, toda dirección resuelve a su versión exacta, y los gates del auditor GIT validan POR CÓDIGO cada instancia al crearse — nada de IA, todo automatizado. El documento definitions JSON es EL CANÓNICO sobre el que todo lo demás se sustenta; este HTML es su espejo de trabajo, jamás la verdad.

LA COLUMNA VERTEBRAL — CLASE → TIPO → INSTANCIA (dictado 2026-08-25):

LA COLUMNA VERTEBRAL — CLASE → TIPO → INSTANCIA (dictado 2026-08-25): cada instancia de tipo de contexto declarado se construye sobre el anidamiento de los SEIS CONTEXTOS DE TIPOS — uno por cada tipo, y cada uno construido SOBRE SU CLASE (espejo 1 a 1 con las 6 clases de este documento; se arman automáticos, jamás a mano; NO existe contexto global de tipos). Las reglas viven siempre en las DMN de los tipos de acción de campo de una instancia concreta — todo son acciones de campo, también las del sobre. El desarrollo, en framework.md §2. Y la ley del CEIP-03 (dictada y CORREGIDA 2026-08-25): los cuatro tipos de evento NO son iguales en naturaleza — ①④ son de ACCIÓN EVENTO (el trigger abre · la validación sella) y ②③ de ACCIÓN CAMPO (el agente y el worker van campo a campo); lo que SÍ es igual en los cuatro son LAS ETIQUETAS comunes del protocolo (las clases objeto valor con su formato por sus clases valor campo — el sobre: C·l·L·T·S·a·F); qué se dice en cada uno y sus reglas por tipo, al final — y el ③ se trabaja primero. Y cuando una regla común y una de un CO casan a la vez: GANA LA DEL CO — siempre que tenga permisos para crearla.

EL CATÁLOGO VIGENTE — 29 clases (24 dictadas el 2026-08-25; 4 más el 26 por dictado: el cifrado del ①, el documento del lote, el fuente custodiado y la referencia a blob; la 25.ª, string.genesis.random_hex128, el 26) · los outputs SON la clase valor campo

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día:

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día: las 29 clases (25 + las 4 del 26) coinciden una a una con catalog.entries (alias · tipo · formato · método · facetas); corregido aquí: las facetas pasan a la tabla por tipo de D5 (law_inside.admitted_facets_by_primitive_type; el validador que las comprueba es código custodiado del auditor GIT, no schema.js), la forma canónica es RFC 8785 (D2), los 25 nombres de formato, las componedoras por su type_id, y «afecta a» completado con x · y · X · Y y la ① de la S. Y en la revisión final del 26 (tarde): 29 clases (las 4 del 26: el cifrado del ①, el documento del lote, el fuente custodiado, la referencia a blob), serialización rfc8785 en las 8 clases object/array (la forma canónica ES el formato de la clase: ley canonical_form_is_the_format), la huella siempre de los bytes guardados (ley hash_is_of_the_stored_bytes: la clase manda al escribir, jamás se canoniza al verificar), la firma determinista dicha con su mecánica y sus fuentes (signatures_verify_never_recompute: ExternalMu-ML-DSA sí, HashML-DSA §5.4 prohibido), las pattern_note medidas por el auditor en las clases 26 y 28, y el único hueco abierto de esta clase: wire_format del cifrado del ① — open_hole (contrato). Ningún (d) pendiente aquí.

alias (explica; la identidad es el contenido + ⬡)	primitive_type	semantic_format · verification	constraining_facets	composition	afecta a (acción de campo)
string.signature.schnorr_hex128 ↩	string	signature · verify	pattern ^[0-9a-f]{128}$	—	componer_etiqueta_lcomponer_etiqueta_Ccomponer_etiqueta_Lcomponer_etiqueta_Tcomponer_etiqueta_Scomponer_etiqueta_acomponer_etiqueta_Fcomponer_etiqueta_xcomponer_etiqueta_ycomponer_etiqueta_Xcomponer_etiqueta_Yfirmar_sigmoment_snapshots de toda regla
string.hash.sha256_hex64 ↩	string	hash · recompute	pattern ^[0-9a-f]{64}$	—	calcular_idcomponer_etiqueta_Sla ① de la S es el id (envelope.tags[S].positions[1], en vigor desde 2026-08-25T19:17:49Z) · referencia a evento (id) · referencia de función (body_sha256)
string.public_key.xonly_hex64 ↩	string	public_key · resolve	pattern ^[0-9a-f]{64}$	—	pubkeyfirmar_sig
string.alias.four_parts_dotted ↩	string	alias · resolve	pattern (4 partes punteadas)	—	componer_etiqueta_lcomponer_etiqueta_Ccomponer_etiqueta_acomponer_etiqueta_xcomponer_etiqueta_X
integer.protocol_kind.nostr_range ↩	integer	protocol_kind · catalog	minimum 0 · maximum 65535	—	kind
integer.time_instant.epoch_seconds ↩	integer	time_instant · pattern	minimum 0	—	created_at
string.lifecycle_phase.enumeration ↩	string	lifecycle_phase · catalog	enum (las SEIS fases — corregido 2026-08-25: 6 FASES · 5 PROCESOS; las dos del loop pertenecen al MISMO proceso)	—	componer_etiqueta_L
string.lifecycle_state.snake_case ↩	string	lifecycle_state · pattern	pattern ^[a-z0-9_]+$	—	la 4ª parte del alias (el estado deseable)
string.decision_policy.hit_policy ↩	string	decision_policy · catalog	enum (las 7 de DMN)	—	toda tabla DMN del contrato
boolean.flag.two_valued ↩	boolean	flag · pattern	type boolean	—	event_class_from_roles (has_trigger · has_validation)
array.snapshot_collection.list_of_signatures ↩	array	snapshot_collection · verify · rfc8785	minItems 0	LIST · items_ref → signature	moment_snapshots de toda reglacomponer_etiqueta_S
string.free_text.unbounded ↩	string	free_text · pattern	type string	—	content (cuando su kind lo dicte)
object.function_reference.snapshot_and_body_hash ↩	object	function_reference · by_parts · rfc8785	required [snapshot, body_sha256]	OBJECT · properties_ref → signature + hash	TODA regla: sus funciones entran como inputs D4 (26): el cuerpo custodiado es un.wasm por sha256 en el almacén de blobs, ejecutado aislado (wazero como especificacion_artefacto); D4 (26): el cuerpo custodiado es un .wasm por sha256 en el almacén de blobs, ejecutado aislado (wazero como especificacion_artefacto); CADA EJECUCIÓN es una instancia en el contexto de la función — ley function_execution_is_an_instance_of_its_context DICTADO (26): body_hash = sha256 del.WASM (lo que se ejecuta), nunca del fuente — cada nodo con su lógica: DICTADO (26): body_hash = sha256 del .WASM (lo que se ejecuta), nunca del fuente — cada nodo con su lógica: la regla entra en el flujo del contexto de infra cuya lógica es EJECUTAR; el que CONSTRUYE (fuente + especificacion_artefacto → .wasm) es otro contexto de infra y su ④ guarda hash del fuente → hash del .wasm; nodos ejecutores intercambiables por determinismo (entries/12.body_is · ley infra_two_contexts)
string.token_type.code_list ↩	string	token_type · catalog	pattern ^[a-z0-9_]+$ (la lista la da el catálogo vigente)	—	componer_etiqueta_T
string.flow_step.enumeration ↩	string	flow_step · catalog	enum (los 4 tipos de evento del flujo)	—	componer_etiqueta_F
array.tag.string_tuple ↩	array	tag · by_parts · rfc8785	minItems 2 — la longitud de cada etiqueta la declara envelope.tags[*].positions, no la clase	TUPLE · coordenadas RFC 6901: /0 const · /1../n refs	componer_etiqueta_lcomponer_etiqueta_Scomponer_etiqueta_Ccomponer_etiqueta_Lcomponer_etiqueta_Tcomponer_etiqueta_acomponer_etiqueta_Fcomponer_etiqueta_xcomponer_etiqueta_ycomponer_etiqueta_Xcomponer_etiqueta_Y las ONCE componedoras (entries/0..10) escriben esta clase
string.property_name.snake_case ↩	string	property_name · pattern	pattern ^[a-z0-9_]+$	—	writes_to.destination de toda regla (a qué campo va)
string.snapshot_type.enumeration ↩	string	snapshot_type · catalog	enum (snapshot_live · snapshot_pinned)	—	componer_etiqueta_S la MARCA de cada consumido: la MARCA de cada consumido: CÓMO se resolvió — snapshot_live · snapshot_pinned (paso 5, 25 tarde; renombrados «para saber bien qué es») — el mismo dato que ya escribe cada input como origin.resolution, ahora con clase
object.resolved_snapshot.event_reference_and_snapshot_type ↩	object	resolved_snapshot · by_parts · rfc8785	required reference · snapshot_type	OBJECT · properties_ref → event_reference (id+sig) · snapshot_type	componer_etiqueta_SUN consumido con su marca — lo que la regla entrega a la S
array.resolved_snapshot_collection.list_of_resolved_snapshots ↩	array	resolved_snapshot_collection · by_parts · rfc8785	minItems 0	LIST · items_ref → resolved_snapshot	moment_snapshots (OUT 3) de TODA regla desde el 25 — la traza que alimenta la S (antes: list_of_signatures, que se queda para colecciones llanas)
object.event_reference.id_and_signature ↩	object	event_reference · by_parts · rfc8785	required id · sig	OBJECT · properties_ref → hash (id) · signature (sig)	componer_etiqueta_S LA REFERENCIA A UN EVENTO (dictado 25, «sí, exactamente»): LA REFERENCIA A UN EVENTO (dictado 25, «sí, exactamente»): el id FILTRA en el REQ (ids), el sig VERIFICA y ES el snapshot — cierra el hallazgo del REQ sin índices ni bases
string.field_action_role.enumeration ↩	string	field_action_role · catalog	enum (trigger · transduction · validation)	—	componer_etiqueta_a LAS TRES CLASES DE ACCIÓN DE CAMPO, con su clase (26): LAS TRES CLASES DE ACCIÓN DE CAMPO, con su clase (26): un enum que llevaba días suelto — línea roja 4. Da el ORDEN dentro de la acción de evento: trigger · transducciones · validación
string.composed_alias.pattern ↩	string	composed_alias · pattern	pattern del CEIP-07 (espejo del itemDefinition composed_alias, mirror_of)	—	componer_etiqueta_aEL d DE UN MANIFIESTO (26): el legible de la a — no es un alias de cuatro partes (medido falso por el auditor contra el d real); la ② de la a lleva esta clase
string.process_type_id.pattern ↩	string	process_type_id · pattern	token.estado_deseable (dos partes; espejo del itemDefinition)	—	componer_etiqueta_ycomponer_etiqueta_Yel legible de la y y de la Y — cazado por el auditor ANTES del primer evento: iba a nacer con la clase de cuatro partes
string.genesis.random_hex128 ↩	string	genesis · pattern	^[0-9a-f]{128}$ — identificador OPACO, aleatorio, NO content-addressed	—	componer_etiqueta_lcomponer_etiqueta_Xcomponer_etiqueta_Y EL GÉNESIS dicho como lo que es (26): EL GÉNESIS dicho como lo que es (26): 64 bytes de azar (dictado 21); vestía la clase de una FIRMA con un método imposible (verify sin clave ni mensaje). Random vs sig: elevado, undecided
string.ciphertext.hpke_base64 ↩	string	ciphertext · verify	base64 — el cifrado HPKE del ① (X-Wing + ChaCha20-Poly1305, D6a); el destino verifica al descifrar (AEAD)	—	content del ① (23301)clase 26 (26, d7): el content lleva la clase que le asigna el kind wire_format = open_hole: wire_format = open_hole: enc \|\| ct es decisión de aarpia, no RFC 9180 (§10); cota del auditor ≥ 1 516 chars; X-Wing es draft; Auth: no → la autoría es la firma nostr pattern_note (auditor 26): pattern_note (auditor 26): este pattern solo comprueba alfabeto base64 y padding — hoy acepta 4 caracteres; la cota ≥ 1 516 no está a propósito hasta que se dicte el formato de cable (open_hole (contrato): wire_format)
object.batch_attestation.checkpoint_and_seals ↩	object	batch_attestation · by_parts · rfc8785	required: root · tree_size · mldsa44_signature · ots_pending · witness_cosignatures	root → hash.sha256_hex64; tree_size · mldsa44 · ots · witness: clases pendientes del primer 3309	content del 3309 / 3318clase 27 (26, d7)
string.source_code.as_custodied ↩	string	source_code · pattern	^[\s\S]*$ — texto TAL CUAL se custodió; huella = sha256 de los bytes guardados; jamás se reformatea; example_invalid: 42 (no es texto)	—	cuerpo custodiado (③ content.codigo)clase 28 (26, d15): 276 cuerpos de hoy (236 no JSON · 40 JSON) por su época; el fuente es un dato con otro formato pattern_note (auditor 26): pattern_note (auditor 26): este pattern NO PUEDE fallar (casa cualquier texto) — no es una restricción, existe para que la forma exista; lo único que la clase rechaza es lo que no es texto (example_invalid 42 falla por TIPO)
object.blob_reference.sha256_size_mediatype ↩	object	blob_reference · by_parts · rfc8785	required: sha256 · size · media_type (el descriptor OCI)	sha256 → hash.sha256_hex64; size · media_type: clases pendientes	el .wasm · las capas de una imagenclase 29 (26, d15): el cuerpo binario vive en el almacén; el evento lleva la referencia

LAS LEYES DE LA CLASE VALOR CAMPO — dictadas el 26 (clase_valor_campo.law_inside)

ley

qué dice

estado

admitted_facets_by_primitive_type

LA TABLA DE FACETAS ADMITIDAS POR TIPO PRIMITIVO, como DATO (D5 por tipo): el validador del auditor la lee y no lleva lista dentro; una faceta fuera de la tabla de su tipo es ROJO; type_key = "type" obligatoria en las 29 (= primitive_type); patrones en dialecto RE2; números exactos (math/big); format SIEMPRE aserción. Uso medido (26): array.minItems 3 · integer.maximum 1 · integer.minimum 2 · object.required 3 · string.enum 5 · string.pattern 10.

tipo	en uso	reservadas (sin uso hoy)
string	pattern · enum	minLength · maxLength · format
integer	minimum · maximum	—
array	minItems	maxItems · items
object	required	—
boolean	—	—

dictada 26

canonical_form_is_the_format

LA FORMA CANÓNICA ES EL FORMATO DE LA CLASE — no una ley aparte sobre «documentos»: las 8 clases object/array llevan semantic_format.serialization = rfc8785; el documento del ③ (y el ② y el 33300) la heredan por su clase; el dato viaja tipado con su forma (línea roja 4). Determinista mientras no cambie la versión de esa instancia de tipo; cambiarla es una versión nueva.

dictada 26

hash_is_of_the_stored_bytes

LA HUELLA ES SIEMPRE DE LOS BYTES TAL COMO SE GUARDARON. El formato de la clase dice qué bytes son admisibles AL ESCRIBIR (object/array: solo la forma rfc8785; cuerpo de código: tal cual se custodió, jamás reformateado; binario: la referencia por sha256); JAMÁS se canoniza al verificar — se canoniza antes de escribir, y solo hay una huella posible. Medida del auditor (26): 276/276 cuerpos casan crudo contra crudo; 40 cuerpos JSON no canónicos y 242 contents no canónicos son deuda de época.

dictada 26

signatures_verify_never_recompute

UNA FIRMA SE VERIFICA, JAMÁS SE RECOMPUTA (D9 de la revisión: ningún método nuevo). La variante determinista de ML-DSA es el MISMO Sign con rnd = 32 ceros (FIPS 204 líneas 1229–1230, confirmación cruzada): hace idempotente el FIRMAR para la bóveda, no da a nadie un recompute; no se usa en producción (solo vectores de prueba) — la norma la CONDICIONA (§3.4, «should not» donde el canal lateral sea preocupación y no esté mitigado; verificado contra el texto: líneas 926 · 939–943 · índice 222). Firmar sin ver el documento: ExternalMu-ML-DSA (RFC 9881 App. D; firmas indistinguibles); jamás HashML-DSA §5.4 (RFC 9881 §8.3 «MUST NOT»).

dictada 26

genesis_random_vs_sig

si el génesis sigue siendo azar (64 bytes) o pasa a ser un sig: elevado, sin resolver.

undecided

entries/25 · wire_format

el formato de cable del cifrado del ① (enc || ct, base64, sin prefijo) es DECISIÓN DE AARPIA, no de RFC 9180 (§10: «does not specify a wire format»); cota del auditor ≥ 1 516 chars para X-Wing (enc 1 120 + tag 16); X-Wing es draft (dirección con snapshot); Auth: no — la autoría es la firma nostr. Se dicta con el primer ① del build nuevo.

open_hole (contrato)

LAS PROPIEDADES DE LA FORMA — con todas sus variables, la estandarización, su evidencia y ejemplos

propiedad	sus variables (todas)	estandarización adoptada · evidencia documental · ejemplo
primitive_type	null · boolean · object · array · number · string · integer	JSON Schema draft-07 §6.1.1 — el keyword `type`. Evidencia (literal): «one of the six primitive types (null, boolean, object, array, number, string), OR integer which matches any number with a zero fractional part» — verificado 2026-08-24. Uso en el catálogo (medido 2026-08-26): string 16 · array 3 · object 3 · integer 2 · boolean 1 — null y number los admite la norma y ninguna clase los usa. 🤖 AI FIRST — JSON es la lengua nativa del consumidor agente: las tool-definitions de todos los proveedores de IA SON JSON Schema — el agente valida y genera sin traductor. Mejor opción frente a XSD/XML (verboso, doble parseo) y a binarios (ilegibles). ÓPTIMO. Matiz dicho: draft-07 sigue siendo el typeLanguage del contrato; el motor que lo ejecuta es, desde D5/D7 (26), el validador de facetas propio del auditor GIT en Go 1.27 (código custodiado, EaaC) — schema.js fue el instrumento de la era de las pruebas, no la referencia. string · "texto" (no es un tipo)
semantic_format .name	los 25 del catálogo: signature · hash · public_key · alias · protocol_kind · time_instant · lifecycle_phase · lifecycle_state · decision_policy · flag · snapshot_collection · free_text · function_reference · token_type · tag · property_name · flow_step · snapshot_type · resolved_snapshot · resolved_snapshot_collection · event_reference · field_action_role · composed_alias · process_type_id · genesis	JSON Schema draft-07 §7 «Semantic Validation With format» — QUÉ es el dato dentro de su sintaxis. Con la advertencia exigida por el auditor: en la norma, format es anotación OPCIONAL («Implementations MAY support…»); AQUÍ es ASERCIÓN — el reverso de la norma, dicho. Las familias usan el término de su protocolo: signature y x-only (BIP-340) · kind y tag (NIP-01) · hit_policy (DMN). 🤖 AI FIRST — el agente lee QUÉ es el dato sin inferirlo — y al ser ASERCIÓN (no anotación ignorable como en la norma) puede CONFIAR: en la norma un format puede no aplicarse y el agente no sabría si se comprobó. La inversión es pro-agente. ÓPTIMO. signature
semantic_format .verification	recompute · resolve · pattern · catalog · verify · by_parts	CÓMO se comprueba, como dato — cada variable con su norma: recompute → FIPS 180-4 (verificación de digest: se recalcula y compara — solo lo reproducible: el id) · resolve → RFC 3986 (resolución de un identificador contra su autoridad) · pattern → XSD 1.1 §4.3.4 (la faceta pattern: la forma escrita es la prueba) · catalog → OASIS genericode (code list: la lista cerrada la da un custodio) · verify → FIPS 186-5 (DSS) · BIP-340 (verificación de firma contra la clave pública, JAMÁS se reproduce) · by_parts → JSON Schema (validación estructural: los subschemas se aplican a las partes). Evidencia de verify (§A, BIP-340, literal): «the value MUST be a fresh uniformly random 32-byte string» y «verifiers … cannot recompute signatures» — firmar dos veces da dos firmas. by_parts: dictado 2026-08-25 tras el rojo del auditor; el método estructural vive como DATO (structural_method) y su gate lo lee. 🤖 AI FIRST — conocimiento OPERATIVO declarado: el agente sabe CÓMO comprobar cada dato sin leer código — recompute lo rehace, verify pide la clave, catalog consulta la lista. Ninguna norma externa ofrece este campo como dato; por eso se ancla variable a variable. ÓPTIMO (y nació de cazar una mentira: el §A). signature→verify · id→recompute · signature→recompute (el error cazado) DICTADO (26, d9): ningún método nuevo — una firma es SIEMPRE verify; DICTADO (26, d9): ningún método nuevo — una firma es SIEMPRE verify; la determinista de ML-DSA = mismo Sign con rnd = 32 ceros (idempotente para la bóveda, no un recompute para nadie); sin uso en producción salvo vectores de prueba D6 (d), 26: «recompute entra en el catálogo de métodos como opción para la variante determinista de ML-DSA, sin usarla» — decidido en el informe, NO escrito en el contrato (el enum de verification y la ley signatures_verify_never_recompute no lo mencionan).
constraining_facets	POR TIPO PRIMITIVO (dictado 2026-08-26, D5 — dato en law_inside.admitted_facets_by_primitive_type): string → pattern · enum (reservadas: minLength · maxLength · format) · integer → minimum · maximum · array → minItems (reservadas: maxItems · items) · object → required · boolean → ninguna. type obligatoria en las 25 (= primitive_type; no es faceta restrictiva). Uso medido: pattern 10 · enum 5 · minItems 3 · required 3 · minimum 2 · maximum 1; reservadas en uso: 0. Una faceta fuera de la tabla de su tipo es ROJO. Escritas en la forma canónica RFC 8785 (D2)	XSD 1.1 Part 2 §4.3 «Constraining Facets» — la forma exacta. Evidencia (literal): «length, minLength, maxLength, pattern, enumeration, whiteSpace, max/minInclusive…»; la cascada es XSD §2.4.2.1 «facet-based restriction»: cada nivel restringe al anterior, jamás lo contradice. Una faceta fuera de la tabla de su tipo es ROJO (ley, D5): el validador del auditor GIT LEE la tabla del contrato y no lleva ninguna lista dentro (gate construido el 26: 24 facetas juzgadas, 0 reservadas en uso; el día que entre format lo acepta solo). La lista plana anterior (con const, sin required) venía de JSON Schema, no del contrato — cazada el 26. 🤖 AI FIRST — ejecutables y en la forma canónica RFC 8785 (D2): dos agentes que comparan clases llegan al MISMO veredicto byte a byte (igualdad estructural decidible) — sin canónico, el mismo schema en otro orden parecería otra clase. Y la tabla por tipo garantiza que nada aplica en silencio: una faceta que no está en la tabla de su tipo es rojo, así que el agente jamás cree validado lo que no se validó. ÓPTIMO. pattern ^[0-9a-f]{128}$ · minimum en una clase string (fuera de la tabla de su tipo) · const (no está en ninguna tabla)
alias	tres segmentos punteados: primitive_type.semantic_format.constraining_facets	RFC 6920 (el nombre hablable junto al hash) + notación punteada jerárquica (RFC 6838, vendor tree): el alias EXPLICA; LA IDENTIDAD ES EL CONTENIDO y su ⬡ cuando el nodo de las clases publique (B1). Dos clases iguales en sus tres propiedades SON la misma clase. Evidencia (RFC 6920, Abstract, literal): la norma del content-addressing define junto al hash «binary and human-speakable formats for these names» — el nombre legible que acompaña a la identidad-hash es parte del propio estándar. El punteado jerárquico es la convención normada de los media types (RFC 6838 §3.2, el árbol por segmentos). El gate del auditor mide que el alias sea lo que explica (su regla, en verde). 🤖 AI FIRST — el nombre punteado se AUTO-EXPLICA: el agente infiere las tres propiedades sin resolver nada — y como la identidad es el contenido, el nombre jamás miente sobre qué versión es. ÓPTIMO. string.signature.schnorr_hex128 · un alias que no casa con sus propiedades
composition	OBJECT — properties_ref (claves con nombre) · LIST — items_ref (homogéneo, un schema para todos) · TUPLE — posiciones fijas por coordenada RFC 6901 (/0, /1, …)	JSON Schema: list y tuple validation · RFC 6901 JSON Pointer — SIEMPRE por referencia a la clase del elemento, jamás copiando sus facetas. Evidencias (literales): tuple = «a sequence of fixed length where each item may have a different schema»; list = «a sequence of arbitrary length where each item matches the same schema» (json-schema.org); coordenadas = «JSON Pointer defines a string syntax for identifying a specific value within a JSON document» con índices «zero-based» (RFC 6901 §3–4). En draft-07 la tupla es `items` como array de schemas. 🤖 AI FIRST — por referencia = UNA verdad que el agente lee (la copia divergente envenena el aprendizaje); las coordenadas RFC 6901 se parsean mecánicamente, sin heurística. Matiz dicho: en draft-07 la tupla es items-array, menos autoexplicativa que prefixItems (2020-12) — el coste de la ejecutabilidad medida. ÓPTIMO con matiz. /1 → string.signature.schnorr_hex128 · copiar el pattern del elemento dentro de la colección
example_valid · example_invalid	un valor que DEBE pasar · un valor que DEBE caer — obligatorios en toda clase	JSON Schema draft-07 §10.4 (la keyword `examples`) + ISO/IEC/IEEE 29119 (casos de prueba positivos y negativos) — y la ley del auditor que los hace OBLIGATORIOS (pagada tres veces en un día): una clase que nadie vio rechazar es una clase que nadie sabe si rechaza. El gate corre los dos contra el schema derivado. 🤖 AI FIRST — es few-shot learning declarado: un agente aprende un formato MÁS RÁPIDO por el par pasa/cae que por el schema, y el negativo le enseña el límite exacto. Oro para el consumidor agente. ÓPTIMO. "9a1d…70e3" pasa · "9A1D" cae (mayúsculas — y cae POR LA RAZÓN esperada)

EL CATÁLOGO VIGENTE — LAS CLASES SON LOS CONTEXTOS (dictado 2026-08-25; las 14 genéricas, derogadas) · 12 orígenes leídos del contrato (las once componedoras y las once etiquetas) — regenerado 2026-08-26

La clase objeto valor de un dato ES el contexto concreto de donde viene, por su dirección de dos capas — aquí vive el content-addressed. La resolución es la naturaleza del contexto, heredada por la regla, jamás tecleada.

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día:

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día: los 12 orígenes coinciden con los origin.alias de las once componedoras; corregido aquí: la grafía de la resolución (snapshot_pinned · snapshot_live, unificada el 25 noche en 123 valores), qué input es live en el archivo, D1 en «la clase = la dirección», D4 en funcion_codigo.activo, y la columna «etapa» y las partes normalizer · editor · provenance dichas como lo que son: declaradas en la clase, sin rellenar por ningún origen (0 de 11 manifiestos). Y el 26 por la tarde, dos dictados: la T (como la l: génesis del tipo · instancia del catálogo live · alias del nivel estándar) y el catálogo del contrato, que estaba VACÍO, se llena con exactamente estos 12 contextos, DERIVADO de las componedoras (clase_objeto_valor.catalog.entries = 12, status open: crece cuando una regla nueva lea de un contexto nuevo; cada entrada con su resolución —la unánime de sus inputs; si mixta, la naturaleza: registro/tipo declarado live, archivo pinned—, qué entrega, quién la lee, ejemplos que resuelven/fallan y su etapa por regla: scaffold 4 · definitive 3 · declared 3 · contract 2).

la clase = el contexto (alias · ⬡)	resolución	etapa (desde el 26: dato del catálogo del contrato, por REGLA sobre el alias — scaffold · declared · definitive · contract)	qué entrega (su formato — la cascada)	afecta a (acción de campo)
aarpia.archivo.evento.publicado + ⬡ ↩	snapshot_pinned (consumed · chosen_co · executed_field_action · manifest · instance_genesis) · snapshot_live (previous_validation: el ④ anterior de X e Y)	definitivo — el archivo (el derecho a leer) stage «definitive» (catálogo 26) D9 (26): el archivo llevará su registro Merkle con testigo; hoy NO tiene identidad para firmar checkpoints (strfry no firma) — pendiente de D9	hash.sha256_hex64 · signature.schnorr_hex128 · signature.schnorr_hex128 · snapshot_type.enumeration · genesis.random_hex128 · signature.schnorr_hex128 · alias.four_parts_dotted · genesis.random_hex128 · signature.schnorr_hex128 · process_type_id.pattern · consumed (resolved_snapshot.event_reference_and_snapshot_type) · chosen_co (signature.schnorr_hex128) · executed_field_action (alias.four_parts_dotted) · manifest (signature.schnorr_hex128) · instance_genesis (genesis.random_hex128) · previous_validation (signature.schnorr_hex128)	etiqueta Setiqueta Xetiqueta Ycomponer_etiqueta_Scomponer_etiqueta_Ccomponer_etiqueta_acomponer_etiqueta_Xcomponer_etiqueta_Y en el contrato
aarpia.catalogos.resolucion_direccion.vigente + ⬡ ↩	snapshot_pinned	andamio · was_to_be: su contexto stage «scaffold» (catálogo 26)	snapshot_type_token (signature.schnorr_hex128)	componer_etiqueta_S en el contrato
aarpia.catalogos.tipo_evento_flujo.vigente + ⬡ ↩	snapshot_pinned	andamio · was_to_be: su contexto stage «scaffold» (catálogo 26)	signature.schnorr_hex128 · flow_step.enumeration · flow_step_token (signature.schnorr_hex128)	etiqueta Fcomponer_etiqueta_F en el contrato
aarpia.catalogos.tipo_token.vigente + ⬡ ↩	snapshot_pinned · snapshot_live	andamio · was_to_be: su contexto stage «scaffold» (catálogo 26)	signature.schnorr_hex128 · token_type.code_list · asset_type (token_type.code_list)	etiqueta Tcomponer_etiqueta_T en el contrato DICTADO (26): la T como la l — se lee LIVE (¿sigue catalogado? ¿dónde está anidado?) y se escribe en ① el génesis del tipo; DICTADO (26): la T como la l — se lee LIVE (¿sigue catalogado? ¿dónde está anidado?) y se escribe en ① el génesis del tipo; el catálogo de tokens que crece es de naturaleza live (ley T_pairs_with_l; sobre y componedora ya coinciden)
aarpia.framework.clase_accion_campo.vigente + ⬡ ↩	snapshot_pinned	el contrato (pinned siempre) stage «contract» (catálogo 26)	signature.schnorr_hex128 · composed_alias.pattern · field_action_role (field_action_role.enumeration)	etiqueta acomponer_etiqueta_a en el contrato
aarpia.framework.clase_accion_evento.vigente + ⬡ ↩	snapshot_pinned	el contrato (pinned siempre) stage «contract» (catálogo 26)	fsm_row (lifecycle_phase.enumeration) · flow_step (flow_step.enumeration)	componer_etiqueta_Lcomponer_etiqueta_F en el contrato
aarpia.framework.tipo_contexto.declarado + ⬡ ↩	snapshot_live · snapshot_pinned	los tipos del nodo (andamio: tipo_objeto_valor custodia las fases) stage «declared» (catálogo 26): uno de los seis contextos de tipos; su nodo nace con 1.27 (hoy solo corre tipo_contexto.declarado)	signature.schnorr_hex128 · signature.schnorr_hex128 · alias.four_parts_dotted · context_type_first_record (signature.schnorr_hex128) · context_type_current_record (signature.schnorr_hex128) · context_type_alias (alias.four_parts_dotted) · context_alias (alias.four_parts_dotted)	etiqueta xcomponer_etiqueta_xcomponer_etiqueta_X en el contrato
aarpia.framework.tipo_objeto_valor.declarado + ⬡ ↩	snapshot_pinned	los tipos del nodo (andamio: tipo_objeto_valor custodia las fases) stage «declared» (catálogo 26): uno de los seis contextos de tipos; su nodo nace con 1.27 (hoy solo corre tipo_contexto.declarado)	signature.schnorr_hex128 · lifecycle_phase.enumeration · phase_token (signature.schnorr_hex128)	etiqueta Lcomponer_etiqueta_L en el contrato
aarpia.framework.tipo_proceso.declarado + ⬡ ↩	snapshot_live · snapshot_pinned	los tipos del nodo (andamio: tipo_objeto_valor custodia las fases) stage «declared» (catálogo 26): uno de los seis contextos de tipos; su nodo nace con 1.27 (hoy solo corre tipo_contexto.declarado)	signature.schnorr_hex128 · signature.schnorr_hex128 · process_type_id.pattern · process_type_first_record (signature.schnorr_hex128) · process_type_current_record (signature.schnorr_hex128) · process_type_alias (process_type_id.pattern) · process_type_id (process_type_id.pattern)	etiqueta ycomponer_etiqueta_ycomponer_etiqueta_Y en el contrato
aarpia.infra.funcion_codigo.activo + ⬡ ↩	snapshot_pinned	andamio: el código en el nodo D4 (26): el cuerpo custodiado pasa a.wasm por sha256 en el almacén de blobs; D4 (26): el cuerpo custodiado pasa a .wasm por sha256 en el almacén de blobs; wazero custodiado como especificacion_artefacto; cada ejecución es UNA INSTANCIA de este contexto (ley function_execution_is_an_instance_of_its_context) D5 de la revisión (26): D5 de la revisión (26): body_hash = sha256 del .WASM, nunca del fuente; en infra son DOS contextos con dos lógicas — el que CONSTRUYE (fuente + especificacion_artefacto → .wasm; su ④ guarda hash del fuente → hash del .wasm, toolchain, opciones) y el que EJECUTA (.wasm + inputs → worker, memoria, duración); nodos ejecutores intercambiables por determinismo (infra_two_contexts) stage «scaffold» (catálogo 26)	fn_compose (function_reference.snapshot_and_body_hash)	componer_etiqueta_lcomponer_etiqueta_Scomponer_etiqueta_Ccomponer_etiqueta_Lcomponer_etiqueta_Tcomponer_etiqueta_acomponer_etiqueta_Fcomponer_etiqueta_xcomponer_etiqueta_ycomponer_etiqueta_Xcomponer_etiqueta_Y en el contrato
aarpia.registros.context_owner.registrado + ⬡ ↩	snapshot_live · snapshot_pinned	definitivo — el registro stage «definitive» (catálogo 26)	signature.schnorr_hex128 · signature.schnorr_hex128 · alias.four_parts_dotted · co_first_record (signature.schnorr_hex128) · co_current_record (signature.schnorr_hex128) · co_alias (alias.four_parts_dotted)	etiqueta Ccomponer_etiqueta_C en el contrato
aarpia.registros.token.registrado + ⬡ ↩	snapshot_live	definitivo — el registro stage «definitive» (catálogo 26)	genesis.random_hex128 · signature.schnorr_hex128 · alias.four_parts_dotted · token_genesis (genesis.random_hex128) · token_registration_snapshot (signature.schnorr_hex128) · token_alias (alias.four_parts_dotted) · instance_token (signature.schnorr_hex128) · token_record (signature.schnorr_hex128)	etiqueta lcomponer_etiqueta_lcomponer_etiqueta_Ccomponer_etiqueta_T en el contrato
aarpia.gobernanza.contrato.vigente + ⬡ (futuro — el scope y el permiso)	snapshot_live	andamio H42 NO es entrada del catálogo (ningún input la lee — la única divergencia que queda en la vara del auditor, correcta y dicha); NO es entrada del catálogo (ningún input la lee — la única divergencia que queda en la vara del auditor, correcta y dicha); será el origen de execution_governance (open_hole del alineamiento: el permiso del CO para EJECUTAR el tipo no es dato)	la suscripción del CO al contexto · los permisos del usuario (roles por instancia y POR CAMPO) · el grupo de CO por contrato — el Knowledge Source de toda regla (caducidad encadenada: live al decidir, congelado al escribir)	trigger ① (wallet.chosen_co)datalake_permission de toda regla

EL CATÁLOGO DEL CONTRATO (dictado 26, d12, opción 1) — clase_objeto_valor.catalog:

EL CATÁLOGO DEL CONTRATO (dictado 26, d12, opción 1) — clase_objeto_valor.catalog: 12 entradas, status open (el único estado de catálogo dictado; y es verdad: crece cuando una regla nueva lea de un contexto nuevo). DERIVADO de las componedoras, jamás tecleado (derived_from: set(entries.name) == set(origin.alias de todos los inputs); regenerar da las mismas entradas). Cada entrada: name (el contexto) · resolution (la unánime de sus inputs; si mixta, la naturaleza: registro/tipo declarado live, archivo pinned) · resolutions_declared_by_inputs · qué entrega · quién la lee · example_resolves (alias @ ⬡) / example_fails (pinned sin snapshot: la mina del alias sin hash; live con alias que nadie registró) · stage por REGLA sobre el alias. La frontera (boundary): una entrada es una dirección en value_object.origin — de dónde viene el DATO; la de value_type.ref.context (dónde vive su CLASE) NO es origen y no entra: medido con dos extracciones, estrecha 12 = catálogo, amplia 16 (las 4 de más son las clases del framework, excluidas con razón). Verificado por el auditor: 12 = 12, diferencia ninguna.

entrada (name = el contexto)	resolution (de la clase)	declaradas por sus inputs	stage	read_by
aarpia.registros.token.registrado	snapshot_live	snapshot_live	definitive	l · C · T
aarpia.infra.funcion_codigo.activo	snapshot_pinned	snapshot_pinned	scaffold	l · S · C · L · T · a · F · x · y · X · Y
aarpia.archivo.evento.publicado	snapshot_pinned	snapshot_pinned · snapshot_live	definitive	S · C · a · X · Y
aarpia.catalogos.resolucion_direccion.vigente	snapshot_pinned	snapshot_pinned	scaffold	S
aarpia.registros.context_owner.registrado	snapshot_live	snapshot_pinned · snapshot_live	definitive	C
aarpia.framework.clase_accion_evento.vigente	snapshot_pinned	snapshot_pinned	contract	L · F
aarpia.framework.tipo_objeto_valor.declarado	snapshot_pinned	snapshot_pinned	declared	L
aarpia.catalogos.tipo_token.vigente	snapshot_live	snapshot_live	scaffold	T
aarpia.framework.clase_accion_campo.vigente	snapshot_pinned	snapshot_pinned	contract	a
aarpia.catalogos.tipo_evento_flujo.vigente	snapshot_pinned	snapshot_pinned	scaffold	F
aarpia.framework.tipo_contexto.declarado	snapshot_live	snapshot_pinned · snapshot_live	declared	x · X
aarpia.framework.tipo_proceso.declarado	snapshot_live	snapshot_pinned · snapshot_live	declared	y · Y

LAS PROPIEDADES DE LA FORMA — con todas sus variables, la estandarización, su evidencia y ejemplos

propiedad	sus variables (todas)	estandarización adoptada · evidencia documental · ejemplo
la clase = la dirección (alias · snapshot)	alias: 4 partes punteadas (dominio.subdominio.token.estado_deseable) · snapshot: el sig (128 hex) — hueco hasta publicar. D1 confirmada (26): el snapshot ES la firma; la referencia a un evento lleva el par id + sig (el id pide en el REQ, la firma verifica)	CONTENT-ADDRESSED — RFC 6920 «Naming Things with Hashes» + FIPS 180-4 (sha-256) + NIP-01: la identidad de una cosa ES su hash; el alias solo explica. Evidencias (literales): «This document defines a set of ways to identify a thing … using the output from a hash function» (RFC 6920, Abstract) · «The sha-256 algorithm … is mandatory to implement» (§2) · y su porqué, que es nuestra resurrección: «this allows for many forms of in-network storage, without requiring as much trust in the infrastructure» (§1). El id nostr = sha256 de la serialización canónica (NIP-01); Bitcoin usa la misma función, dos veces («it is computed twice»). El sig NO es hash: es ATESTACIÓN (BIP-340 — verify, jamás recompute). 🤖 AI FIRST — RECUPERAR garantizado por matemática: lo que el agente rescata por hash ES lo custodiado — RFC 6920: «without requiring as much trust in the infrastructure» — la memoria del sistema no puede corromperse en silencio. sha-256 frente a opciones más rápidas (blake3): lo fijan el transporte (nostr) y la interoperabilidad (RFC 6920 mandatory, Bitcoin) — la mejor opción es la que no crea una segunda verdad. ÓPTIMO. aarpia.registros.token.registrado + ⬡9a1d… · el alias solo, sin su hueco de ⬡ (la mina del alias sin hash)
resolution	snapshot_pinned · snapshot_live (la grafía unificada el 2026-08-25 noche en los 123 valores del contrato; «pinned · live» a secas está derogada — undecided.address_resolution_spelling, resuelto)	La distinción normativa URN / URL — RFC 3986 §1.1.3: snapshot_pinned = el nombre persistente (siempre lo mismo para esa key) · snapshot_live = el localizador (resuelve a lo vigente al decidir, CONGELADO al escribirse — «live al decidir, pinned al quedar escrito»). Evidencias (RFC 3986 §1.1.3, literales): URN = URIs «required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable» · URL = «provide a means of locating the resource by describing its primary access mechanism» — identidad persistente vs acceso a lo actual: nuestra pareja exacta. Y ES DEL CONTEXTO, no de la regla: un registro se lee vivo, un catálogo/contrato pinned — la regla la escribe HEREDADA, jamás tecleada. El gate mide que una misma dirección jamás declare dos resoluciones; el sitio único de declaración llegará con tipo_contexto.declarado. 🤖 AI FIRST — frescura DECLARADA: el agente sabe sin ejecutar qué puede memorizar para siempre (pinned) y qué debe releer (live) — sin esto, o relee todo (caro) o memoriza obsoleto (peor). ÓPTIMO. el registro de tokens → snapshot_live · el contrato → snapshot_live (mataría el replay determinista)
stage	scaffold (andamio) · definitive — y en todo scaffold: was_to_be OBLIGATORIO. Medido 26: el dato existe en el itemDefinition del origen y en la ley origin_stages; NINGÚN input de las once componedoras lo escribe (was_to_be en 0 inputs; origin = alias · snapshot · resolution)	Niveles de madurez normados (IETF: Internet-Draft → RFC · W3C Process: Working Draft → Recommendation) + la redirección declarada (HTTP 301 «Moved Permanently», RFC 9110 §15.4.2): el dato vive provisional PORQUE su contexto no existe, y CONVERGE — cuando exista, en la regla cambia la dirección y nada más: el hash es el mismo, lo que llega allí es EL MISMO dato. El par scaffold/definitive es el ciclo de madurez que las normas mismas practican; y el was_to_be es el análogo técnico de la redirección permanente DECLARADA: el destino de convergencia dicho como dato. Obligatorio desde 2026-08-24: un provisional que no dice a dónde converge no se puede saldar jamás. El backlog de scaffolds es una MEDIDA de los gates, nunca un rojo eterno. 🤖 AI FIRST — el agente distingue lo provisional de lo definitivo Y SABE A DÓNDE converge (was_to_be): puede planificar la migración y nada se le rompe en silencio — la redirección declarada es navegable por máquina. ÓPTIMO. andamio + was_to_be: el contexto de las fases · andamio sin was_to_be (no entra)
provenance (la parte de dentro)	registry · context_instance · request · domain_constant · computed — medido 26: parte declarada en clase_objeto_valor.parts; ningún input de las componedoras la lleva (0 ocurrencias en clase_accion_campo)	W3C PROV-DM (Recommendation, 30-04-2013) — el modelo de datos normativo de la PROCEDENCIA. Los actos sin dirección (lo declarado, lo manual, lo computado) NO son clases: son la provenance — la lección del invento derogado (generic_origin_families). Evidencia (PROV-DM §1, literal): «Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness» — la trazabilidad total, dicha por el W3C. Y nuestras variables mapean a sus tres tipos nucleares: computed → Activity («consuming, processing, transforming … or generating entities») · registry/context_instance → Entity consumida · request (lo manual) → Agent («bears some form of responsibility» — y entra SIEMPRE por una interfaz con sus procesos: la ley del modo). Lo computado LLEVA la dirección de su función (dictado 2026-08-25); el reloj es la única excepción sin dirección, dicha. 🤖 AI FIRST — PROV se diseñó literalmente para esto: «form assessments about its quality, reliability or trustworthiness» — el agente pondera cada input por su procedencia: lo computado se re-lee como hecho, lo manual se atribuye a su Agent responsable. LA Recommendation del W3C, sin alternativa seria. ÓPTIMO. computed + la dirección de contrato.evento · «derived» como clase suelta (derogado)
value_type (la cascada)	referencia de dos capas a la clase valor campo con la que ENTREGA (catalog_ref + ⬡)	JSON Schema draft-07 §8.3 (`$ref`: la referencia tipada — «The value of the $ref property MUST be a URI Reference») + XSD §2.4.2.1 (derivación por restricción) — y la 4ª LÍNEA ROJA que las junta: acción campo ⊃ objeto valor ⊃ valor campo — declarar el origen ES declarar el formato. El dato que una regla consume nació tipado y su clase viaja con él; un input jamás re-declara (ni puede equivocar) el formato de lo que consume. Ejecutada por el typeLanguage: una regla con un input sin sus clases NO PARSEA — no entra en ningún manifiesto, no la carga ningún ContextVM, no la ejecuta ningún motor (c28). 🤖 AI FIRST — el dato viaja tipado: el agente JAMÁS adivina el formato de lo que consume — y c28 hace que lo mal tipado ni parsee: una regla rota no se puede ni cargar. ÓPTIMO. el registro de tokens entrega signature ×2 + alias · un input con origen y sin formato
normalizer · editable · editor	normalizer/editor: nostr · aarpia · context_owner — editable: true · false	XSD value constraints (`fixed` vs `default`: el valor que fija el schema vs el que puede poner el documento) + RBAC (INCITS 359 / NIST: quién tiene el permiso de escribir) — el dominio en tres valores (dictado 2026-08-22): quién dicta la norma del campo · fijo o libre · quién pone el dato. editable=false es el `fixed` de XSD (solo el normalizador lo pone); editable=true es el campo con editor autorizado — y QUIÉN puede es el modelo de roles (RBAC). La ley del papel (c27): disparador y validación los calcula SIEMPRE el motor (editable false); solo la transducción puede ser manual; el modo es de la acción de evento entera y mezclar está prohibido. Invariante: si no es editable, el editor ES el normalizador. 🤖 AI FIRST — el agente sabe ANTES de actuar qué campos puede escribir (RBAC declarado) y cuáles calcula el motor (fixed): el error de permiso se previene en el contrato, no se descubre en el rechazo. ÓPTIMO. las once componedoras: editable false · domain aarpia (entries/0..10) · una validación editable · medido 26: normalizer y editor no los rellena ningún manifiesto (0 de 11) — son partes declaradas en la clase, no datos vivos de los orígenes

★ LA GUÍA — LAS ETIQUETAS: acciones de campo con sus clases objeto valor y valor campo, relacionadas con sus CEIPs

EL CAMINO (dictado 2026-08-25):

EL CAMINO (dictado 2026-08-25): «primero definimos las etiquetas, que son acciones campo con sus clases objeto valor y valor campo, relacionadas con CEIPs — será nuestra guía». Cada fila: una etiqueta o campo del sobre, su DECISIÓN tomada en el camino CEIP, su acción de campo (el tipo componedor), sus dos clases y su estado. Lo verde está en el contrato con gates; lo amarillo espera; lo tachado se retiró con su porqué.

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día:

REVISIÓN FINAL DEL 26 (tarde) — contra el contrato desplegado + D1–D11 y las leyes del día: corregido aquí: la l① es genesis (clase 25), la a② es composed_alias (clase 23), las componedoras por su type_id, las cifras de deuda de emisor por etiqueta (emitter_debt, censo del auditor del 26), la FSM situada donde vive (clase_accion_evento.decisions[fsm]), el content del ① con HPKE (D6a), D1 · D2 · D6 en sig · id · pubkey · created_at · kind, la medida de la p, CEIP-04 cerrado, y los orígenes completos de X e Y. Lo (d) que quedaba —la T y «7→5»— se dictó el mismo día y está cerrado arriba.

etiqueta / campo	LA DECISIÓN (del camino CEIP)	acción de campo	clase objeto valor (el contexto)	clase(s) valor campo	CEIPs	estado
l ↩	[⬡génesis, ⬡registro, alias] — el génesis nace en el create de initial y queda para siempre; mientras no registrado: [génesis, génesis] (la ley del arranque). Token o token parte: el isomorfismo	componer_etiqueta_l DECLARADA (canonical_field_action_types/0)	aarpia.registros.token.registrado (live)	genesis (①: random_hex128, desde 26-ago 07:24Z — vestía la clase de una firma) · signature · alias → tag.string_tuple	030506	contrato+gates deuda del emisor (censo 26, auditor): l#3 226 de 226 — escriben el ID del token donde va su alias; l#1 36 de 357 con el nombre donde va el génesis → a pruebas
C ↩	[⬡ del PRIMER registro (inmóvil — #C da todo el CO a través de sus relevos), ⬡ del momento, alias] — SIN génesis (un CO no se usa sin registrar; 2026-08-22). Hoy: siempre Arya Digital (estado del andamio de gobernanza)	componer_etiqueta_C DECLARADA (25 noche, revisada por el operador): DECLARADA (25 noche, revisada por el operador): entries/2 — inputs chosen_co (del ①) · co_first_record (⬡ del ④ que SELLA el primer registro: snapshot_pinned) · co_current_record (⬡ del registro vigente: snapshot_live) · co_alias · instance_token · fn_compose; UNIQUE, tres reglas excluyentes: registered → ["C", ⬡primer, ⬡vigente, alias] · unregistered → C nula (rechazo del ④) · founding → el arranque en llano. Cada instancia de contexto es un REGISTRO	aarpia.registros.context_owner.registrado (live)	signature ×2 · alias → tag.string_tuple	030506	ley deuda del emisor (censo 26, auditor): deuda del emisor (censo 26, auditor): C#3 324 de 324 — escriben el ID del CO donde va su alias de cuatro partes → a pruebas (la cifra vieja «15 índices» era de una medida anterior sin eje temporal)
L ↩	LA FASE — SE LEE del tipo de proceso declarado (jamás se elige); [⬡ de la fase en su catálogo, legible]. 6 FASES · 5 PROCESOS (las dos del loop, mismo proceso)	componer_etiqueta_L DECLARADA (25 noche, revisada): DECLARADA (25 noche, revisada): entries/3 — la fase se LEE de la fila de la FSM (el primer DMN) del proceso de la instancia, jamás se elige; seis reglas UNIQUE, una por fase; ⬡ de la fase en el catálogo del andamio + legible del contrato	aarpia.framework.tipo_objeto_valor.declarado (andamio · pinned)	signature · lifecycle_phase.enumeration	030502	ley L en llano CERRADA el 23-ago 22:19 (auditor, con eje temporal) deuda del emisor (censo 26): L#2 139 de 223 en ② (grafía legada, H47) · 1 001 eventos con una TERCERA posición (el alias del catálogo) RESUELTO (opción A, 25 noche): RESUELTO (opción A, 25 noche): los tokens del andamio se llamaban fase.intermedio/loop_activo/loop_inactivo; cargados fase.intermediate · loop_active · loop_inactive (3/3 en el archivo); nodo andamio y consola con el nombre del contrato; traductor FaseCanonica con fecha de muerte H47 (bóveda · registro · registro_co: 5 emisores del legado → 0)
T ↩	EL TIPO DEL TOKEN, construido COMO LA l y pareja de ella (dictado 26): al crear la instancia del tipo de contexto declarado (token o token parte) nace el tipo con su GÉNESIS (azar, como la l) y con el mismo nombre que el token lleva en la l, y se dispara su instancia en el catálogo de tokens, donde se anida bajo un tipo estándar de aarpia (n niveles, cuando exista el contexto del catálogo). [génesis del tipo (pinned) · ⬡ instancia loop_activo del tipo en el catálogo (LIVE) · alias del nivel estándar donde está anidado]. En el evento que crea el tipo, ② = ①. Si el token no se crea sino que se ELIGE entre los l existentes, la T toma su valor del catálogo automáticamente. «Token de contexto / parte» sigue sin ser un tipo: es una relación	componer_etiqueta_T DECLARADA (25 noche, revisada): DECLARADA (25 noche, revisada): entries/4 — la T es el TIPO DE ACTIVO (factura · empresa · pago…) del catálogo que crece; «token de contexto / parte» NO es un tipo: es una relación (contexto + proceso) y no viaja; al crear un token se registra en el registro Y se dispara una instancia en el catálogo, donde se relaciona con una tipología estándar; reglas catalogued → ["T", ⬡tipo, legible] · uncatalogued → T nula (rechazo) REESCRITA (26, dictado «la T como la l»): REESCRITA (26, dictado «la T como la l»): entries/4 con 5 inputs (token_record · type_genesis · type_catalog_instance · standard_level_alias · fn_compose, todos live del catálogo salvo fn_compose) y TRES reglas UNIQUE: catalogued → ["T", génesis, ⬡instancia, alias-nivel] · founding → ["T", génesis, génesis, alias-nivel] (el evento que crea el tipo) · uncatalogued → T nula (rechazo). Ley T_pairs_with_l en el sobre; época anterior (dos posiciones) en history	aarpia.catalogos.tipo_token.vigente (andamio) RESUELTO (26): el sobre y la componedora leen LIVE (¿sigue catalogado? ¿dónde está… RESUELTO (26): el sobre y la componedora leen LIVE (¿sigue catalogado? ¿dónde está anidado?) y escriben en ① el génesis, que no se mueve — live al decidir, pinned al escribir	genesis.random_hex128 · signature.schnorr_hex128 · token_type.code_list (desde el 26 11:45Z; antes: signature · token_type.code_list)	0305	ley ARREGLADO (25 noche, «dale»): ARREGLADO (25 noche, «dale»): el catálogo de tipos de activo YA existía en el andamio (8 tipos); cargador con -tipo = tipo de ACTIVO obligatorio; nodo con la T CERRADA (rechazo, jamás literal; excepción acotada del arranque), tipo corregible por versión (evento nuevo), resolutor con refresco; 8 versiones a dato_estandar verificadas en el archivo (④ con [⬡, «dato_estandar»]) deuda inmutable dicha: 8 cargas de la mañana + 8 ④ de las 20:58→21:19 con la T en llano (el primer parche no tocó el SQL) deuda del emisor (censo 26): T#1/#2 36 de 135 · 924 eventos con una TERCERA posición
S ↩	LA CAUSALIDAD — el ⬡ (sig) de CADA evento consumido, una etiqueta por consumido; viaja en el sobre porque una cadena solo en la base podría mentir. SUSTITUYÓ A LA e: la norma le exige 32 bytes y un snapshot son 64. Y DESDE EL 25 (paso 5) DICE CÓMO SE RESOLVIÓ CADA CONSUMIDO: [S, ⬡consumido, resolution] (forma intermedia del paso 5, sustituida esa misma noche por la de cuatro posiciones — abajo) — live (la instancia pedida POR SUS SEÑAS: token · contexto · estado/fase → su ⬡ del momento) · pinned (el ⬡ del evento pedido). La regla lo entrega en su traza (moment_snapshots) y la S lo publica	componer_etiqueta_S DECLARADA (25 noche): DECLARADA (25 noche): canonical_field_action_types/entries/1 — inputs consumed (clase 18: referencia id+sig + snapshot_type) · snapshot_type_token (⬡ en el catálogo del andamio) · fn_compose; UNIQUE, dos filas excluyentes (snapshot_live / snapshot_pinned); una ejecución por consumido, a la vez cuando son n	el evento publicado, por su REFERENCIA id + sig (pinned) · la instancia de contexto por sus señas (live) — EL DATALAKE, con contrato de suscripción · live/pinned custodiados en el andamio (resolucion_direccion.*)	hash (id) · signature (sig) · signature (⬡ del tipo) · snapshot_type.enumeration ← resolved_snapshot_collection (la traza de la regla)	04030610	ley FÓRMULA (ley s_formula, 25 noche): FÓRMULA (ley s_formula, 25 noche): S = lo consumido del flujo + los moment_snapshots de las reglas que el evento ejecutó — nada más; el ④ no repite lo de sus ③; sin marca (el id resuelve a su F). CEIP-04 CERRADO REQ resuelto: id filtra · sig verifica snapshot_live / snapshot_pinned = tokens del andamio (renombrados por dictado) LA S COMPLETA: [S, id (pinned), sig (live), ⬡ (snapshot_type), "snapshot_live" \|… LA S COMPLETA: [S, id (pinned), sig (live), ⬡ (snapshot_type), "snapshot_live" \| "snapshot_pinned" (alias)] — posición ③ nombrada por el operador: snapshot_type deuda del emisor (censo 26): S#1 183 de 183 — siguen escribiendo el sig donde va el id (en vigor desde 25-ago 19:17Z) D6 (26): las hojas del árbol del lote son las S del 3309 (una por evento del lote, en orden)
a ↩	LOS TIPOS EJECUTADOS — una por tipo de acción de campo del evento: [⬡ del manifiesto 33300, su d]. Cada tipo declara DÓNDE está publicado su manifiesto (published_as: d + hueco B1)	componer_etiqueta_a DECLARADA (26, revisada — el operador corrigió la pregunta: DECLARADA (26, revisada — el operador corrigió la pregunta: el ④ valida TODAS las acciones de campo; trigger, transducción y validación son las tres clases, cada tipo con su manifiesto): entries/5 — inputs executed_field_action (del ②) · manifest (published_as del tipo, el 33300 en el archivo) · field_action_role (clase 22) · fn_compose; UNIQUE published → ["a", ⬡manifiesto, d] · unpublished → a nula (rechazo); UNA ejecución por acción de campo, EN ORDEN: trigger · transducciones · validación la última Y EN EL ① TAMBIÉN (dictado 26 tarde): Y EN EL ① TAMBIÉN (dictado 26 tarde): una a por manifiesto SOLICITADO [a, ⬡manifiesto pinned, alias vacío] — la skill que el agente leyó tiene versión; lo pedido (①), lo ejecutado (③) y lo validado (④) se comparan por hash; el ContextVM comprueba que sean los que la DMN de ese proceso para ese CO admite (si no, 3308) — request_envelope.the_a_in_the_request	el manifiesto publicado (33300, vía published_as · pinned)	signature · composed_alias.pattern (clase 23: el d del manifiesto, ② desde 25-ago 22:37Z)	0703	ley deuda del emisor (censo 26): deuda del emisor (censo 26): a#1 142 de 142 — una sola posición con la coordenada del manifiesto del NODO (un 33300 por nodo, no por tipo) y sin segunda posición
F ↩	EL TIPO DE EVENTO DEL FLUJO — [⬡ del tipo, legible]; los 4 CUSTODIADOS y verificados contra el archivo por las dos mitades: trigger_event_action 91139c… · agent_request 19d4396d… · field_action_execution e3f5b4e6… · event_action_validation 723fde7f…. El kind sigue siendo el índice fino; la F el filtro grueso (#F)	componer_etiqueta_F DECLARADA (26): entries/6 — flow_step (del contrato: DECLARADA (26): entries/6 — flow_step (del contrato: qué paso del flujo ES este evento) · flow_step_token (⬡ en el catálogo del andamio) · fn_compose; UNIQUE, cuatro reglas, una por tipo; ["F", ⬡tipo, legible]; cardinalidad one. 0 de 1632 eventos la llevan hoy: nace cuando los emisores adopten las componedoras	aarpia.catalogos.tipo_evento_flujo.vigente (andamio · pinned)	signature · flow_step.enumeration	0205	CREADA (25)
x ↩	EL CONTEXTO (tipo) al que pertenece la acción — primero de LOS CUATRO DATOS FUNDAMENTALES (dictado 26: «sin contexto, proceso, instancia de contexto e instancia de proceso es imposible reconstruir las historias»). [⬡ primer registro del tipo, ⬡ vigente, alias de cuatro partes]	componer_etiqueta_x DECLARADA (26): entries/7	aarpia.framework.tipo_contexto.declarado (live)	signature · signature · alias.four_parts_dotted	03	leyes four_fundamental_data · the_action_group (C · l · x · y juntas y en orden; el orden es firmable) · geneses_are_distinct (l① · X① · Y① distintos) emitter_debt: null — aún sin emisores
y ↩	EL PROCESO (tipo: token.estado_deseable) — resuelto contra la FSM y declarado en tipo_proceso.declarado, uno de los seis contextos de tipos del nodo. [⬡, ⬡, token.estado_deseable]	componer_etiqueta_y DECLARADA (26): entries/8	aarpia.framework.tipo_proceso.declarado (live)	signature · signature · process_type_id.pattern (clase 24)	03	leyes four_fundamental_data · the_action_group (C · l · x · y juntas y en orden; el orden es firmable) · geneses_are_distinct (l① · X① · Y① distintos) emitter_debt: null — aún sin emisores
X ↩	LA INSTANCIA DE CONTEXTO — identidad: UN GÉNESIS POR INSTANCIA fundado al abrirla (opción ii; la solicitud ① era efímera por NIP-01 y colgaba todo del archivo). [⬡génesis, ⬡ del ④ ANTERIOR (primer evento: [génesis, génesis]), alias del contexto]	componer_etiqueta_X DECLARADA (26): entries/9	el archivo: instance_genesis (pinned) · previous_validation (live, el ④ anterior) + tipo_contexto.declarado: context_alias (live)	genesis.random_hex128 · signature · alias.four_parts_dotted	0304	leyes four_fundamental_data · the_action_group (C · l · x · y juntas y en orden; el orden es firmable) · geneses_are_distinct (l① · X① · Y① distintos) emitter_debt: null — aún sin emisores
Y ↩	LA INSTANCIA DE PROCESO — igual que la X, con su propio génesis y su ④ anterior; el legible es el process_type_id. Con el kind (tipo de acción evento + fase) y la X (qué parte y de qué contexto) los campos de cada DMN se encapsulan quirúrgicamente	componer_etiqueta_Y DECLARADA (26): entries/10	el archivo: instance_genesis (pinned) · previous_validation (live, el ④ anterior) + tipo_proceso.declarado: process_type_id (live)	genesis.random_hex128 · signature · process_type_id.pattern	0304	leyes four_fundamental_data · the_action_group (C · l · x · y juntas y en orden; el orden es firmable) · geneses_are_distinct (l① · X① · Y① distintos) emitter_debt: null — aún sin emisores
pubkey	EL ACTOR — quién es lo resuelve gobernanza desde la clave, jamás el evento; una clave por actor; rotar es un relevo declarado. D6c (26): la clave postcuántica (ML-DSA-44, semilla de 32 bytes) es una credencial más del actor en la bóveda, y las dos claves (Schnorr ↔ PQ) se firman mutuamente en el registro del CO antes de que haga falta. La bóveda tiene INSTANCIAS (D8, 26): de casa (hoy) · en el mismo dispositivo (el enclave custodia la semilla; la firma la calcula el nodo — «no sale del dispositivo», no «del chip») · COLD WALLET (un solo nodo pide la firma a un dispositivo frío por QR · USB · NFC); lo que recibe cada instancia es DATO suyo (payload_accepted: event_id 32 B, computable sin saber quién firma · external_mu 64 B, DEPENDE de la pk del firmante y ≠ id · whole_event, el humano confirma); NIP-46/NIP-55 mandan el evento entero y no son nuestra cold wallet (diseño propio, declarado). El ctx de ML-DSA: open_hole (contrato) (mldsa_ctx: ≤ 255 bytes, vacío por defecto — FIPS 204 líneas 1233 · 1244; el valor de aarpia con el primer 3309)	pubkey por declarar	aarpia.autenticacion.boveda_credenciales.activa (live)	public_key.xonly_hex64	09	ley
created_at	EL RELOJ DEL NODO EJECUTOR — leído UNA vez y congelado; el lote lo ancla por fuera: ley batch_attestation_is_two_events (D6, 26) — el 3309 inmediato (raíz Merkle sobre las firmas + tree_size + firma ML-DSA-44 + OTS pendiente + sitio para las co-firmas del testigo) y el 3318 horas después con la prueba OTS definitiva; un lote, una raíz, dos sellos; max_leaves = 1 000 (dictado d10; techo MEDIDO por el auditor 1 149 — el archivo aplica 262 144 aunque declara 524 288 —; margen a 1 000: 154 hojas, prudencia; el 265 de un relay externo es CALCULADO, no medido, y solo importa si el 3309 sale de casa); nace completo: las hojas son sus S, raíz + tree_size en el content, witness_cosignatures reservado (D9); lleva F (non_flow_kinds). El origen tiene dirección (el nodo); el DATO sigue siendo la frontera del determinismo	created_at por declarar	el nodo ejecutor — contextvm (live; cada cliente/relay su nodo)	time_instant.epoch_seconds	sin CEIP propio	ley
kind	SE LEE, JAMÁS SE ELIGE — la FSM (fase × tipo de token × acción de evento) lo genera automático de LA SITUACIÓN: condensa el paso, el desenlace, la fase y el tipo — y DICE qué reglas aplicar por campo y por mensaje ①②③④. Fuera de la FSM: el lote 3309 y el 3318 (ley batch_attestation_is_two_events; entran en kinds.go con D7) y el manifiesto 33300. kind_catalogue (26, d11): los 19 kinds como DATO (paso · papel · permanencia · clase de content), y cada kind un TOKEN del andamio con su snapshot (salida aarpia.catalogos.kind.vigente); los 14 del ④ siguen siendo de la FSM; kinds.go se deriva de la tabla (D7); las 19 cargas con el emisor nuevo (8 kinds vivos · 11 sin un solo evento). Y la F la llevan también 3309 · 3318 · 33300: qué F lo dice el kind (non_flow_kinds; valor en la revisión final)	kind por declarar	aarpia.framework.clase_accion_evento.vigente — decisions[fsm] (14 reglas UNIQUE: phase · context_token_type · event_action → kind; pinned · hueco B1). Corregido 26: la FSM no vive en clase_contexto	protocol_kind.nostr_range	02	ley
content	POR KIND: cifrado en el ① con HPKE híbrido X-Wing (ML-KEM-768 + X25519, ChaCha20-Poly1305 — D6a, 26; ya en Go 1.26; NIP-44 v2 declara sin seguridad postcuántica y queda atrás) · direcciones en el ② · el documento con su output en el ③ · VACÍO en el ④ (las etiquetas SON las direcciones — al bus solo direcciones). content_by_kind (26, d7): la clase del content LA DICE EL KIND — ① string.ciphertext.hpke_base64 (26) · ④ VACÍO (ley) · 3309/3318 object.batch_attestation.checkpoint_and_seals (27) · ② ③ 33300 pendientes de la revisión final por kind; nada entra en un evento sin su clase y su formato, ni el cuerpo — y la huella es siempre de los bytes guardados (hash_is_of_the_stored_bytes)	content por declarar	la fila FSM (pinned)	por kind (content_by_kind): ciphertext.hpke_base64 (①) · vacío (④) · batch_attestation.checkpoint_and_seals (3309/3318) · pendiente (② ③ 33300)	08	ley
id	UNA SOLA IDENTIDAD — sha256 de la serialización canónica [0, pubkey, created_at, kind, tags, content]: content-addressed POR SÍ MISMO (recompute — de las pocas donde la palabra es verdad). Ni un dato nuevo: la misma información validada. D2 (26): la forma la fija NIP-01 y el contrato cierra su hueco — los controles 0x00–0x1F van como \u00XX (ley control_characters_in_id_serialization); medido por el auditor: 0 casos en 1 646 eventos y los 1 646 ids recomputan; el id de go-nostr no pasa por encoding/json (JSON v2 no lo cambia). Los DOCUMENTOS (clases, manifiestos, blobs JSON) van en RFC 8785 puro (ley canonical_form_of_documents)	calcular_id por declarar	el nodo ejecutor + el sobre en composición (pinned) + fn contrato.evento	hash.sha256_hex64	01	ley
sig	EL SNAPSHOT — solo existe cuando quien tenía que firmar firmó; es ATESTACIÓN sobre el id (§A, BIP-340: se VERIFICA contra la clave, JAMÁS se recomputa — firmar dos veces da dos firmas). La bóveda lo crea en SU contexto: la privada jamás sale, cada firma un evento trazado. D1 confirmada (26): el snapshot sigue siendo la firma; toda referencia a un evento lleva id + sig. D6 (26): la firma postcuántica NO cabe aquí ni puede ir en las etiquetas del evento que firma — va en el 3309 por lote (ML-DSA-44 sobre la raíz); la bóveda firma sin ver el documento (External μ) y cross-firma las dos claves. Precisado el 26 (tarde): la vía es ExternalMu-ML-DSA (RFC 9881 App. D; firmas indistinguibles del ML-DSA puro), JAMÁS HashML-DSA §5.4 (RFC 9881 §8.3 «MUST NOT»); la variante determinista es el mismo Sign con rnd = 32 ceros — ningún método nuevo, una firma es siempre verify; no se usa en producción (la norma la condiciona) — deterministic_signing_note · sources · mechanics	firmar_sig por declarar	aarpia.autenticacion.boveda_credenciales.activa (live)	signature.schnorr_hex128 (verify)	0109	ley
e	RETIRADA — la norma le exige 32 bytes (un id) y un snapshot son 64: no cabía sin romperla. Su función la hace la S	—	—	—	04	retirada
p	hoy repite la pubkey del firmante (no aporta); NIP-01 la define como «pubkey referenciada» — QUÉ ACTOR referencia cada evento es DECISIÓN DEL OPERADOR; vive como pendiente EN el dato del sobre. MEDIDO (auditor, 26; undecided.the_p_tag): en producción en 1 621 de 1 632 eventos (99,3 %) — la etiqueta más usada tras la l — y el sobre no declara qué es, su forma ni su cardinalidad; su momento es el CEIP-09. DICTADO 26 (tarde): la p es DEUDA A ELIMINAR — mi propuesta de usarla como «Para:» (la clave del ContextVM destino) la retiró el operador: direccionar por clave rompe el diseño (las claves se relevan; el canal es la C: el ContextVM se suscribe por #C + #x); sale del sobre cuando los emisores renazcan en 1.27; lo publicado con p se juzga por su época (undecided.the_p_tag, decidido)	—	—	—	09	tu decisión
(el caso)	la etiqueta de la instancia de proceso (hallazgo G7 del agente cliente: sin ella el relay no filtra por caso sin caminar la S) — APARCADA por orden hasta aviso	—	—	—	futuro	aparcada
(estado)	NO EXISTE etiqueta de estado — el estado actual es el último al que se transicionó (el último create): LO DICE EL PROCESO, jamás un campo que puede mentir. Y loop_active/loop_inactive son las dos fases del proceso loop	—	—	—	03	ley

LOS DIEZ CEIPs — el estado de la revisión (el detalle, en revision-ceips.html)

CEIP	estado de la revisión	lo que queda de cada uno
01 · el sig es el snapshot	✅ REVISADO Y VALIDADO	nada — su fruto (el paquete del DMN del sobre, §A verify) está en el contrato con gates
05 · C·l·L·T	✅ VALIDADO Y CONSTRUIDO	nada — el sobre como dato; su deuda de censo, a las pruebas
03 · las tres capas	🔨 EN CONSTRUCCIÓN — el actual	el evento ③ HECHO · las once componedoras del sobre HECHAS · quedan los campos · la deuda de emisores por etiqueta (emitter_debt, censo del auditor del 26: C 324/324 · l 226/226 · L 139/223 · T 36/135 · S 183/183 · a 142/142 · F 0/1632) → a las pruebas
04 · la S y el event chain	✅ CERRADO (25 noche: ley s_formula)	S = lo consumido del flujo + los moment_snapshots de las reglas que el evento ejecutó; el ④ no repite lo de sus ③; la referencia a evento es id + sig (D1). Queda su detalle fino en su turno del orden
02 · kinds por paso y fase	POR REVISAR (con el 08)	el 3312 dictado y SIN implementar («más adelante») · RESUELTO (dictado 26): RESUELTO (dictado 26): la clase de proceso es <proceso><tipo de token> — 7 clases de proceso (5 del token de contexto + 2 del token parte: initial · intermedio; loop, final y final_alt son SIEMPRE del contexto) · 16 tablas de decisión (12 + 4) · 8 filas de la FSM (6 + 2). Tres cuentas de tres cosas — 5 procesos · 7 clases de proceso · 8 filas —, no una contradicción; «7→5» retirado. Ley process_classes_by_token_type; fila initial·part_token (fsm_rule_15/16) y tablas create_initial_part / transition_initial_part añadidas; la ley de las 14 queda como historia (superseded_by) el contrato sostenía 14 DMN = 7 clases de proceso × create/transition y 5 procesos: si son dos cuentas de cosas distintas o hay que derogar una lo dice el operador · los kinds del lote 3309 · 3318 (ley del 26) · los kinds del ①②③④ tras el ③ kind_catalogue (26, d11): los 19 kinds como dato del contrato, cada uno un token del andamio con su snapshot; los del ④ siguen siendo de la FSM
08 · el content por kind	POR REVISAR (con el 02)	el content del 3312 espera al 3312; el resto medido en censo (④ vacío: 0 fallos) content_by_kind (26): ① cifrado (clase 26) · ④ vacío (ley) · 3309/3318 lote (clase 27) · ② ③ 33300 en la revisión final
06 · live / pinned	POR REVISAR	reforzado ya (URN/URL · verify/by_parts · la caducidad de permisos «contra el permiso DEL SOBRE») — su revisión formal, a su turno
09 · los actores	POR REVISAR	ampliado con los 4 actores del flujo; en su turno: LA ETIQUETA p (tu decisión — qué actor referencia cada evento)
10 · el efímero no se pierde	POR REVISAR	porqué ampliado (telemetría · process mining · LOS TOKENS del agente) — y el límite del auditor: esa medida HOY NO EXISTE, se construye cuando mandes
07 · el manifiesto y el alias compuesto	POR REVISAR — el último	cierra con los manifiestos POR TIPO (H25) y la publicación de las once componedoras (published_as ya escrito con su hueco B1) EL MANIFIESTO como dato (26, ley the_manifest): EL MANIFIESTO como dato (26, ley the_manifest): la instancia de tipo_accion_campo.declarado PUBLICADA (33300 por su d; direcciones jamás valores; común o por CO; tres papeles de UN dato: lo que el ContextVM ejecuta · la skill del agente (D10: MCP, esquema derivado del manifiesto) · lo que el ④ cita con su a; tres manifiestos: contexto · uno por tipo de acción de campo · asyncapi) B1 sigue: published_as.snapshot null × 11; 0 de 11 manifiestos de componedoras publicados (10 eventos 33300 son índices de nodos) — con el emisor nuevo

LAS LEYES DICTADAS EL 26 — dónde viven y qué dicen (el inventario entero: 33 nodos del contrato con dictado del 26 u open_hole)

Leído del contrato desplegado.

Leído del contrato desplegado. Lo open_hole (contrato) es un hueco DECLARADO por el propio contrato con su porqué — no una divergencia del HTML: espera dictado. Lo que sigue en la revisión final del flujo de los cuatro mensajes: L · T · X · Y en el ①; la tabla de reglas por kind; la clase del documento del ② · ③ · 33300; el kind y la clase del checkpoint; los valores de ctx y wire_format; el worker y la gobernanza de ejecución como inputs; las 19 cargas de kinds y los 11 manifiestos de componedoras (con el emisor nuevo).

clase	ruta	en una frase	estado
clase_accion_campo	law_inside.function_execution_is_an_instance_of_its_context	cada ejecución de una función custodiada es UNA INSTANCIA en el contexto de la función (el que llama entra como actor solicitante; el worker de ese contexto ejecuta el .wasm; su ③/④ registran worker · .wasm · ejecutor · inputs · memoria · duración; el que llama lee el snapshot y lo mete en su S); infra_two_contexts: CONSTRUIR y EJECUTAR	dictada
clase_accion_campo	law_inside.the_manifest	qué es el manifiesto: la instancia de tipo_accion_campo.declarado PUBLICADA; lleva direcciones, jamás valores; común o por CO; tres papeles de un dato; tres manifiestos; deuda B1 dicha	dictada
clase_accion_campo	law_inside.agent_door_is_mcp_from_the_manifest	D10: la puerta del agente IA es MCP (stateless · discover · orden determinista); cada nodo expone sus manifiestos como tools y el esquema SE DERIVA DEL MANIFIESTO, jamás del código Go; lo en revisión (SEP-2640) no se adopta; MCP ofrece, el ① es, el contrato decide	dictada
clase_accion_campo	law_inside.the_complete_alignment	EL TIPO DE ACCIÓN DE CAMPO ES DONDE TODO SE CRUZA (4 mensajes · 6 clases · 3 dominios · 3 verbos · piezas de Go · agente · firma); la DMN con sus n reglas es donde se mide (situación × papel × dominio × validez; PRIORITY; línea roja 4 por fila); «milimétrico» = 3 comprobaciones (el motor lee solo el contrato · la misma fila da la skill y el ③ · por kind cada input/output sabe su regla); determinismo en negocio · seguridad · infraestructura. Medido por el auditor (measured_2026_08_26): 4 de 6 direcciones son dato, worker y gobernanza de ejecución solo prosa; roles = transduction × 11; las 3 comprobaciones hoy inmedibles (sin motor · sin manifiesto publicado · sin tabla) — estado futuro	dictada
clase_accion_campo	the_complete_alignment.open_holes.worker_address	el manifiesto debe llevar la dirección del WORKER que puede ejecutarlo (constitución §4) y hoy ninguna componedora tiene ese input	open_hole (contrato)
clase_accion_campo	the_complete_alignment.open_holes.execution_governance	el permiso del CO para EJECUTAR el tipo no es dato (editar sí: scope · editable · author); a dictar como input con origen aarpia.gobernanza.contrato.vigente	open_hole (contrato)
clase_accion_evento	law_inside.field_actions_in_the_event	una a por manifiesto ejecutado; el ④ valida TODAS las acciones de campo	dictada
clase_accion_evento	law_inside.process_classes_by_token_type	la clase de proceso es <proceso><tipo de token>: 7 clases (5 contexto + 2 parte: initial · intermedio) · 16 DMN · 8 filas de la FSM; loop, final y final_alt siempre del contexto; fila initial·parte (fsm_rule_15/16) y tablas create/transition_initial_part; the_fourteen_dmns queda como historia	dictada
clase_accion_evento	envelope.tags[F].non_flow_kinds	3309 · 3318 · 33300 SÍ llevan F (son instancias de un contexto); qué F lo dice el kind; el valor, en la revisión final	dictada
clase_accion_evento	envelope.laws.cardinality_is_data · positions_have_their_epoch · four_fundamental_data · the_action_group · geneses_are_distinct	las leyes del sobre de la mañana: cardinalidad como dato; cada posición con su época; los cuatro datos fundamentales (x · y · X · Y); el grupo de la acción C · l · x · y juntos y en orden; l① · X① · Y① distintos	dictadas
clase_accion_evento	envelope.laws.canonical_form_of_documents · control_characters_in_id_serialization	D2: RFC 8785 puro para los documentos (a través de su clase); \u00XX para los controles 0x00–0x1F del id; medido: 0 casos en 1 646 eventos	dictadas
clase_accion_evento	envelope.laws.batch_attestation_is_two_events	D6b: el lote en DOS eventos por necesidad — 3309 inmediato (raíz sobre las firmas + tree_size + ML-DSA-44 + OTS pendiente + witness_cosignatures) y 3318 con la prueba OTS definitiva; born_complete (las hojas son sus S); max_leaves 1 000; techo medido 1 149; margin_at_1000; el 265 calculado, no medido; F_tag	dictada
clase_accion_evento	envelope.laws.T_pairs_with_l	la T como la l: génesis del TIPO (①, pinned) · instancia loop_activo en el catálogo (②, live) · alias del nivel estándar (③); en el evento que crea el tipo ② = ①; elegido entre los l existentes → la T sale del catálogo; los tipos de activo del DRD son los niveles estándar; componer_etiqueta_T reescrita (catalogued · founding · uncatalogued)	dictada
clase_accion_evento	envelope.laws.request_envelope	el ①: el grupo C · l · x · y (abre el canal: #C + #x, jamás por clave) + F + S (el ④ vigente; vacía en un alta) + una a por manifiesto solicitado; alias VACÍO (discreción); la p deuda a eliminar; L · T · X · Y no decididos (CEIPs)	dictada
clase_accion_evento	envelope.laws.agent_request_telemetry	d8: la telemetría del ② son campos de negocio de su documento, con sus clases, firmados por quien gastó	dictada
clase_accion_evento	envelope.laws.archive_transparency_log_and_witness	D9: el archivo mantiene un registro Merkle (tlog, RFC 6962) de los id y publica checkpoints; CADA UNO LO CO-FIRMA EL TESTIGO ANTES DE PUBLICARSE (sin co-firma no se publica); el testigo es el auditor GIT (hoy su nodo andamio; mañana el contexto testigo con su nodo); límite RFC 9162 §1; atomicidad; dos árboles (archivo vs lote); el simulacro verifica la consistencia; las actas entran; obligaciones del testigo (estado persistente antes de responder); split view no resuelto por sí solo; independencia medida; pendiente: el kind del checkpoint, su clase, el ctx, y la IDENTIDAD DEL ARCHIVO (strfry no firma)	dictada
clase_accion_evento	archive_transparency_log_and_witness.independence_of_custody	el día que el archivo tenga clave, archivo y testigo serían dos usuarios de la misma bóveda: ¿basta, o el testigo custodia su clave aparte? antes del primer checkpoint	open_hole (contrato)
clase_accion_evento	envelope.content_by_kind	la clase del content la dice el kind: ① 25 · ④ vacío · 3309/3318 26 · ② ③ 33300 pendientes	dictada
clase_accion_evento	envelope.kind_catalogue	los 19 kinds como dato, cada uno un token del andamio con su snapshot (salida aarpia.catalogos.kind.vigente); cargas con el emisor nuevo (loads)	dictada
clase_contexto	law_inside.the_node_image_and_the_vault_instances	D8: UNA imagen estándar del ContextVM por plataforma (el contexto es dato que el nodo carga por hash; manifiesto OCI en 33300, capas/binario en blobs por sha256, atestación in-toto/SLSA); el contexto viaja (móvil) y habla por su canal; la bóveda tiene instancias (casa · dispositivo · cold wallet); cold_signer_payload (payload_accepted_values: event_id · external_mu · whole_event, dato de cada instancia); ExternalMu sí, HashML-DSA prohibido; NIP-46/55 leídas y descartadas como respaldo	dictada
clase_contexto	the_node_image_and_the_vault_instances.mldsa_ctx	el ctx de ML-DSA no tiene valor declarado (norma: ≤ 255 bytes, vacío por defecto; un dominio por uso, con el primer 3309)	open_hole (contrato)
clase_contexto	law_inside.open_hole_the_classes_do_not_declare_their_processes	hueco anterior al 26, sigue abierto: las clases no declaran sus procesos	open_hole (contrato)
clase_contexto	six_phases_five_processes.part_token_processes	los cinco procesos son del token de contexto; el parte tiene dos (initial · intermedio)	dictada
clase_objeto_valor	catalog (12 entradas · derived_from · boundary)	d12: el catálogo se llena con exactamente los contextos que las componedoras leen, derivado; frontera origen ≠ clase	dictada (status open)
clase_valor_campo	law_inside.admitted_facets_by_primitive_type · canonical_form_is_the_format · hash_is_of_the_stored_bytes · signatures_verify_never_recompute (+ deterministic_signing_note · sources · mechanics)	ver la tabla de leyes de la pestaña CLASES VALOR CAMPO	dictadas
clase_valor_campo	catalog.entries 25 · 26 · 27 · 28	las cuatro clases del 26: string.ciphertext.hpke_base64 (① — wire_format open_hole) · object.batch_attestation.checkpoint_and_seals (3309/3318; tres partes con clase pendiente) · string.source_code.as_custodied (el fuente tal cual; 276 cuerpos por su época) · object.blob_reference.sha256_size_mediatype (el .wasm y las capas: el descriptor OCI)	dictadas
mapa a Go	D1 – D11	todas decididas el 26 (pestaña MAPA A GO 1.27): D1 snapshot = sig · D2 RFC 8785 · D3 evaluador propio · D4 Wasm + wazero · D5 validador de facetas del auditor · D6 plan PQ · D7 Go 1.27 (go-nostr probado) · D8 imagen estándar + bóveda con instancias · D9 tlog + testigo · D10 MCP desde el manifiesto · D11 gates sobre testing (deuda del arnés, adopción con 1.27)	decididas

LAS DECISIONES DEL CAMINO QUE NO SON ETIQUETAS

decisión	estado	en una frase
6 FASES · 5 PROCESOS	✅ dictada y cerrada	las dos del loop pertenecen al mismo proceso; mi inversión corregida CON LA HISTORIA DICHA. RESUELTO (dictado 26): RESUELTO (dictado 26): la clase de proceso es <proceso><tipo de token> — 7 clases de proceso (5 del token de contexto + 2 del token parte: initial · intermedio; loop, final y final_alt son SIEMPRE del contexto) · 16 tablas de decisión (12 + 4) · 8 filas de la FSM (6 + 2). Tres cuentas de tres cosas — 5 procesos · 7 clases de proceso · 8 filas —, no una contradicción; «7→5» retirado. Ley process_classes_by_token_type; fila initial·part_token (fsm_rule_15/16) y tablas create_initial_part / transition_initial_part añadidas; la ley de las 14 queda como historia (superseded_by)
común vs CO casando a la vez	✅ dictado	GANA LA DEL CO — siempre que tenga permisos para crearla (resuelve contra gobernanza)
el andamio de gobernanza del scope	dictado · POR CONSTRUIR (H42)	futuro aarpia.gobernanza.contrato.vigente: suscripción → owner automático → roles por instancia Y POR CAMPO; hoy 1 CO (Arya Digital) + 1 owner; caducidad encadenada — jamás la historia open_hole (contrato) execution_governance (alineamiento 26): open_hole (contrato) execution_governance (alineamiento 26): hay DOS gobernanzas — quién puede EDITAR el tipo es dato (scope · editable · author); quién puede EJECUTARLO (la que nombra la constitución) solo existe en prosa; a dictar como input de cada tipo de acción de campo con origen aquí
la telemetría del ②	dictada · medida POR CONSTRUIR	process mining al milímetro: por campo qué regla·worker·cómputo; del agente IA los TOKENS GASTADOS por tipo de usuario — el auditor no la da por cubierta LEY (26, d8): agent_request_telemetry — los tokens gastados, el modelo por dirección,… LEY (26, d8): agent_request_telemetry — los tokens gastados, el modelo por dirección, la duración y el coste son CAMPOS DE NEGOCIO del documento del ②, con sus clases, firmados por quien gastó (hoy el ContextVM; mañana el agente IA); se declaran con la clase del ② en la revisión final
el 3312 (el campo entra sin sellar)	dictado · sin implementar	«más adelante», tu palabra — nadie lo adelanta
la referencia de PAGOS (AV1)	más adelante	pausada: «no se toca hasta que el contrato de clases esté cerrado»
NIP-59 (gift wrap)	no se usa	exigiría un interior SIN FIRMA y el CEIP-09 exige todo firmado — el ① va cifrado SIN envoltura, y desde D6a (26) con HPKE híbrido X-Wing en vez de NIP-44
el kind único	derogado (18)	en el registro con su patrón vigilado
las 14 familias genéricas	derogadas (25)	«las clases son los contextos» — registro generic_origin_families, deudores de prosa vigilados

EL CAMINO QUE QUEDA, en orden:

EL CAMINO QUE QUEDA, en orden: ⑤ el evento ③ — HECHO (entrada live/pinned · permiso en dos escalones · n campos, cadena y modos · las columnas de la (c) · el DRD · event_reference id+sig · live/pinned en el andamio); la S COMPLETA (snapshot_type) y su FÓRMULA como ley; resolution unificada con la clase 17; priority retirada, UNIQUE dentro del dominio → CEIP-04 CERRADO → las ONCE componedoras del sobre HECHAS (l · S · C · L · T · a · F · x · y · X · Y; los cuatro datos fundamentales; la cardinalidad y la ÉPOCA de cada posición como dato; el génesis dicho como lo que es) → los campos pubkey · created_at · kind · content · calcular_id · firmar_sig → la p y la etiqueta del caso (la revisión de etiquetas) → el CEIP-04 (la S y su detalle fino) → 02+08 → 06 → 09 → 10 → 07 → TODAS las pruebas en LA CONSOLA (127.0.0.1:8096), al terminar de definir el contrato desde las clases.
26-ago — LAS DECISIONES DE GO 1.27 (pestaña MAPA A GO 1.27): D1 el snapshot es la firma, referencia a evento id + sig · D2 RFC 8785 puro para los documentos y \u00XX para los controles del id (leyes canonical_form_of_documents · control_characters_in_id_serialization) · D3 evaluador JSON Logic propio custodiado («a la manera DMN 1.5», no conformance) · D4 funciones en Wasm con wazero custodiado, ley function_execution_is_an_instance_of_its_context · D5 facetas admitidas POR TIPO (admitted_facets_by_primitive_type; validador del auditor GIT, EaaC) · D6 plan postcuántico (① con HPKE X-Wing · atestación ML-DSA-44 por lote: ley batch_attestation_is_two_events, 3309 · 3318 · bóveda con cross-firma) · D7 el build nace en Go 1.27 (go-nostr probado bajo 1.27 por el auditor) · D8 una imagen estándar del ContextVM por plataforma, el contexto como dato, la bóveda con instancias y cold wallet (ley the_node_image_and_the_vault_instances) · D9 el archivo con registro Merkle y TESTIGO = el auditor (ley archive_transparency_log_and_witness) · D10 la puerta del agente es MCP con el esquema derivado del manifiesto (leyes the_manifest · agent_door_is_mcp_from_the_manifest · the_complete_alignment) · D11 los gates sobre testing, deuda del arnés con adopción en 1.27. LAS ONCE, DECIDIDAS. Y las doce (d) del contrato salidas de la revisión del HTML, dictadas todas (T · clases de proceso por tipo de token · el ① · la F fuera del flujo · body = .wasm · la forma canónica como formato · el content por kind · la telemetría · recompute · el techo del lote · los kinds como dato · el catálogo OV). Lo que queda es la revisión final del flujo de los cuatro mensajes por tipo de evento y proceso — y hasta entonces no se construye nada (dictado 26).

① trigger_event_action ⬡ 91139c5436c3… — acción EVENTO · el actor usuario por su interfaz

REVISIÓN FINAL DEL 26 (tarde) contra el contrato desplegado (build/consola/contrato) + D1–D11 decididas lo que el CONTRATO deja declarado como hueco va marcado open_hole (contrato) — con su porqué y quién lo decide; nada se rellena aquí por cuenta propia.

DECISION componer_solicitud_trigger PROPUESTA MÍA (no es un hueco del contrato):

DECISION componer_solicitud_trigger

PROPUESTA MÍA (no es un hueco del contrato):

PROPUESTA MÍA (no es un hueco del contrato): no existe en él (11 componedoras + fsm + 16 DMN); nombre e inputs se deciden en la revisión final del flujo de los 4 mensajes por tipo de evento y proceso (dictado 26: «no nos vamos a crear nada» hasta entonces)

· HIT POLICY por dictar · QUESTION ¿qué solicitud ① se compone para lo que el actor pide desde su interfaz? · INFORMATION REQUIREMENTS la intención del actor · el CO elegido (wallet) · el anuncio del destino · la situación · KNOWLEDGE REQUIREMENTS rules_engine · AUTHORITY ks_framework · ks_governance

?	I N P U T S				O U T P U T S
?	actor.intentla interfaz — comandos por acción de campo, generados desde la propia peticiónpor acción de campo pedida	wallet.chosen_coaarpia.gobernanza.contrato.vigente (andamio H42) — lo contratado ∩ los permisossignature ×2 · alias (la C)	recipient.announcementel anuncio del usuario-contexto destino — a qué clave cifrar — y con D6a, también la clave de encapsulación híbrida (X-Wing) que anunciapublic_key.xonly_hex64 (+ clave HPKE, D6a)	situationtipo de token · proceso · estado · fase — la situación de la que todo se derivatoken_type · lifecycle_phase · lifecycle_state	el sobre comúnlas ONCE etiquetas — el grupo de la acción C · l · x · y primero; L · T · S · a · F · X · Y — pares de clases DICTADO (26, ley request_envelope): DICTADO (26, ley request_envelope): el ① lleva EL GRUPO DE LA ACCIÓN C · l · x · y (lo que el usuario trae; y lo que abre el canal: el ContextVM se suscribe por #C + #x — jamás por clave), la F = trigger_event_action y la S (el ④ vigente de la instancia; vacía en un alta). DISCRECIÓN: la posición del alias va VACÍA en el ①, solo hashes. La p (99,3 % de los eventos, sin ley) es DEUDA A ELIMINAR: direccionar por clave rompe el diseño DICTADO (26, tarde): DICTADO (26, tarde): EL ① LLEVA UNA a POR MANIFIESTO SOLICITADO [a, ⬡manifiesto pinned, alias vacío] — la skill que el agente leyó tiene versión; lo pedido (①), lo ejecutado (③) y lo validado (④) se comparan por hash; el ContextVM comprueba que sean los que la DMN de ese proceso para ese CO admite (si no, 3308). Ley request_envelope.the_a_in_the_request L · T · X · Y en el ①: no decidido — se estudian en la revisión de los CEIPs	contentstring.ciphertext.hpke_base64 (clase 26 — content_by_kind 23301, d7): la petición CIFRADA con HPKE híbrido X-Wing, base64; el destino la verifica al descifrar (AEAD) open_hole (contrato): open_hole (contrato): wire_format — enc \|\| ct es DECISIÓN DE aarpia, no de RFC 9180 (§10 no fija formato de cable); cota si enc \|\| ct: ≥ 1 516 chars base64 con padding (X-Wing enc 1 120 B + tag 16 B; auditor); X-Wing es draft (IANA KEM 25722) → dirección con snapshot; Auth: no → la autoría del ① es la firma nostr; se dicta con el primer ① del build nuevo
R-F	constante del tipo (any)				F: ["F", ⬡91139c5436c3…, "trigger_event_action"] — tag.string_tuple (legible: flow_step.enumeration)
R-k	constante del tipo (any)				kind: 23301 (efímero por NIP-01: «pasa y no se guarda»; que el ARCHIVO lo conserve es ley del relay de archivo, contextvm.md §10, no del kind) — protocol_kind kind_catalogue (26, d11): kind_catalogue (26, d11): 23301 = ① request, firmado por quien pide, efímero, content clase 26; uno de los 19 kinds como DATO del contrato, cada uno un token del andamio (cargas con el emisor nuevo)
R-c	la petición del actor + la clave del anuncio del destino				content: la petición CIFRADA con HPKE híbrido X-Wing (ML-KEM-768 + X25519, ChaCha20-Poly1305 — D6a, dictado 26; NIP-44 v2 declara «no post-quantum security») hacia la clave de encapsulación del anuncio del destino (jamás NIP-59: el interior iría sin firma). La clase del content la dice el kind (content_by_kind): aquí string.ciphertext.hpke_base64
R-a	los manifiestos que la petición pide — cada uno por su snapshot				DICTADO (26, tarde — request_envelope.the_a_in_the_request): DICTADO (26, tarde — request_envelope.the_a_in_the_request): UNA a POR MANIFIESTO SOLICITADO [a, ⬡manifiesto (pinned), alias VACÍO]. Cuatro razones: (1) la skill que el agente leyó tiene VERSIÓN — sin la dirección el ContextVM podría aplicar otra y la traza se rompería sin error; (2) el ④ cita lo ejecutado → lo pedido (①), lo ejecutado (③) y lo validado (④) se comparan POR HASH (la cadena 82/82 del auditor aplicada a toda acción); (3) el proceso (y) solo no dice qué trae la petición — el modo es de la acción de evento entera: el ① dice para qué transducciones trae dato; (4) el ContextVM VALIDA que sean los que la DMN de ese proceso para ese CO admite (disparadores y validaciones los calcula el motor; el ① solo trae transducciones) — si no, 3308
	LAS RULES DE NEGOCIO del trigger (qué acciones de campo pide, con qué campos): POR DICTAR
annotation — LOS CAMPOS COMUNES (los mismos en los 4 tipos — la ley matizada): pubkey → quien solicita: persona, agente u OTRO ContextVM (la coreografía); su ContextVM actúa EN NOMBRE del CO elegido (public_key; quién es lo resuelve gobernanza) · created_at → el reloj DEL NODO EJECUTOR, leído una vez y congelado (time_instant; el OTS ancla) · id → sha256 de la serialización canónica NIP-01, con los controles 0x00–0x1F como \u00XX (D2, ley envelope.laws.control_characters_in_id_serialization; medido por el auditor: 0 casos en 1 646 eventos, los 1 646 ids recomputan; el id de go-nostr no pasa por encoding/json) (hash — content-addressed por sí mismo, recompute) · sig → LA BÓVEDA firma con la credencial del actor (signature — EL SNAPSHOT: verify, jamás recompute §A; D1 confirmada el 26: el snapshot ES el sig y la referencia a un evento es id + sig; D6c: la clave PQ es una credencial más de la bóveda —semilla de 32 B, ExternalMu-ML-DSA (RFC 9881 App. D; jamás HashML-DSA §5.4, que RFC 9881 §8.3 prohíbe — cazado por el auditor el 26)— cross-firmada con la Schnorr en el registro del CO) · la S → las referencias de lo que pide: el ⬡ de la instancia/token sobre el que solicita DICTADO (26): la S del ① = el ④ vigente de la instancia sobre la que actúa (su UTXO); vacía en un alta de instancia nueva. Ley request_envelope · y las ONCE etiquetas del sobre con sus pares de clases — el grupo de la acción C · l · x · y primero, y L · T · S · a · F · X · Y (la l, C, L, T del estado de la instancia; la a de los tipos ejecutados). Posiciones pinned · live · snapshot_type · alias (los CUATRO roles dictados — envelope_tag.role; la S lleva ⬡snapshot_type en la ③); solo la ① se indexa (NIP-01); sin etiqueta de estado.

CEIPs: CEIP-08CEIP-09CEIP-10CEIP-03·05

② agent_request ⬡ 19d4396d446f… — acción CAMPO · el agente IA, campo a campo

DECISION componer_peticion_agente PROPUESTA MÍA (no es un hueco del contrato):

DECISION componer_peticion_agente

PROPUESTA MÍA (no es un hueco del contrato):

· HIT POLICY por dictar · QUESTION ¿qué tipos de acción de campo, con qué direcciones, bajo qué regla — por cada campo que el ① pide? · INFORMATION REQUIREMENTS el ① consumido · los manifiestos del nodo · la situación · KNOWLEDGE REQUIREMENTS rules_engine · los manifiestos como skills · AUTHORITY el contrato (la IA propone; el contrato decide en ④)

?	I N P U T S			O U T P U T S
?	trigger_eventel ① consumido — por su referencia id + sig (la S de este ② desciende de él: [S, id, sig, ⬡snapshot_type, snapshot_pinned])event_reference.id_and_signature	node.manifestslos tipos de acción de campo del nodo — cada uno un manifiesto con sus n entradas por paressignature · alias (su d)	situationtipo de token · proceso · estado · fase → EL KIND, automático — y DICE qué reglas aplicar por campotoken_type · lifecycle_phase · lifecycle_state · protocol_kind	② la petición, POR CAMPOdirecciones anidadas (context + pointer + ⬡) — jamás datos; cuando una regla direcciona una función .wasm (pinned, por sha256), el ContextVM ENTRA COMO ACTOR SOLICITANTE en el flujo del contexto de la función — cada ejecución es una instancia allí (D4, ley clase_accion_campo.law_inside.function_execution_is_an_instance_of_its_context) — y son DOS contextos de infra, dos lógicas (infra_two_contexts, d5): el que CONSTRUYE (fuente + especificacion_artefacto → .wasm; su ④: sha256 del fuente → sha256 del .wasm, toolchain, opciones) y el que EJECUTA (.wasm + inputs → worker, memoria, duración); la regla apunta al .wasm por su sha256 (body_is); nodos ejecutores intercambiables por determinismo	el sobre comúnlas ONCE etiquetas (el grupo de la acción C · l · x · y primero)
R-F	constante del tipo (any)			F: ["F", ⬡19d4396d446f…, "agent_request"] — tag.string_tuple (legible: flow_step.enumeration)
R-k	constante del tipo (any)			kind: 23302 (efímero por NIP-01; «conservado para la telemetría» es prosa del 23 DICTADO (23 en prosa, escrito 26 — d8, opción 1): DICTADO (23 en prosa, escrito 26 — d8, opción 1): la telemetría del ② (tokens gastados, modelo por dirección, duración, coste) son CAMPOS DE NEGOCIO del documento del ②, con sus clases, firmados por quien gastó (hoy el ContextVM; mañana el agente IA); se declaran con la clase del ② en la revisión final. Ley agent_request_telemetry ) — protocol_kind
R-c	los tipos elegidos de los manifiestos			content: DIRECCIONES — qué tipo · qué direcciones · bajo qué regla, por campo content_by_kind 23302: content_by_kind 23302: la clase del documento del ② se define en la revisión final por kind (serialización rfc8785 por su clase al nacer); con ella, los campos de la telemetría (agent_request_telemetry)
R-firmador	la instancia de bóveda que firmará este ② — y, en la cadena, lo que se le manda para firmar el ③/④ que pide			DICTADO (26, D8 opción 3 — clase_contexto.the_node_image_and_the_vault_instances.cold_signer_payload): DICTADO (26, D8 opción 3 — clase_contexto.the_node_image_and_the_vault_instances.cold_signer_payload): LO QUE RECIBE UN FIRMADOR ES DATO DE SU INSTANCIA DE BÓVEDA (payload_accepted): event_id · external_mu · whole_event — event_id: el id de 32 B, computable SIN saber quién firma; external_mu: el μ de 64 B de ExternalMu-ML-DSA (RFC 9881 App. D: μ = H(H(pk) ‖ 0x00 ‖ len(ctx) ‖ ctx ‖ M) — DEPENDE de la pk del firmante: quien compone necesita la pública de la instancia ANTES; firmas indistinguibles de ML-DSA puro; jamás HashML-DSA §5.4, que RFC 9881 §8.3 prohíbe); whole_event: la cold wallet con pantalla lo muestra y un humano confirma. Bóveda de casa o enclave firman por hash; el ② nombra el payload que manda y, si es external_mu, la instancia cuya pk usó open_hole (contrato): open_hole (contrato): mldsa_ctx — el ctx de la fórmula del μ no tiene valor declarado en aarpia; FIPS 204 verificado (l. 1233 vacío por defecto; 1244/1280 ≤ 255 B; 1247 error si se pasa); un dominio por uso como dato, con el primer 3309
	LAS RULES del agente (cómo elige tipos y reglas de los manifiestos ante lo que el ① pide): POR DICTAR
annotation — LOS CAMPOS COMUNES (los mismos en los 4 tipos — la ley matizada): pubkey → EL AGENTE IA (clave tipo agente_ia; hoy firma el ContextVM — la intención dictada 2026-08-23). La IA propone (②); el contrato decide (④). Y la SKILL que lee para componerlo es EL MISMO MANIFIESTO que el ContextVM ejecuta, descubierto por MCP con el esquema derivado del manifiesto, jamás del código (D10, ley agent_door_is_mcp_from_the_manifest) (public_key; quién es lo resuelve gobernanza) · created_at → el reloj DEL NODO EJECUTOR, leído una vez y congelado (time_instant; el OTS ancla) · id → sha256 de la serialización canónica NIP-01, con los controles 0x00–0x1F como \u00XX (D2, ley envelope.laws.control_characters_in_id_serialization; medido por el auditor: 0 casos en 1 646 eventos, los 1 646 ids recomputan; el id de go-nostr no pasa por encoding/json) (hash — content-addressed por sí mismo, recompute) · sig → LA BÓVEDA firma con la credencial del actor (signature — EL SNAPSHOT: verify, jamás recompute §A; D1 confirmada el 26: el snapshot ES el sig y la referencia a un evento es id + sig; D6c: la clave PQ es una credencial más de la bóveda —semilla de 32 B, ExternalMu-ML-DSA (RFC 9881 App. D; jamás HashML-DSA §5.4, que RFC 9881 §8.3 prohíbe — cazado por el auditor el 26)— cross-firmada con la Schnorr en el registro del CO) · la S → desciende del ① que responde · y las ONCE etiquetas del sobre con sus pares de clases — el grupo de la acción C · l · x · y primero, y L · T · S · a · F · X · Y (la l, C, L, T del estado de la instancia; la a de los tipos ejecutados). Posiciones pinned · live · snapshot_type · alias (los CUATRO roles dictados — envelope_tag.role; la S lleva ⬡snapshot_type en la ③); solo la ① se indexa (NIP-01); sin etiqueta de estado. Y LA TELEMETRÍA dictada: de cada ② quedan LOS TOKENS GASTADOS por tipo de usuario — cada petición del agente es una fila del mining de mañana. LEY (26, d8): agent_request_telemetry — campos de negocio del documento del ②, con sus clases, firmados por quien gastó; LEY (26, d8): agent_request_telemetry — campos de negocio del documento del ②, con sus clases, firmados por quien gastó; se declaran con la clase del ② en la revisión final

CEIPs: CEIP-09CEIP-10CEIP-08

③ field_action_execution ⬡ e3f5b4e635f0… — acción CAMPO · un worker por ③ — y el ③ lleva n campos de negocio (paso 5)

🔨 LA PESTAÑA DE TRABAJO — «tendríamos que irnos al evento ③ y trabajarlo, porque ahí sí…

🔨 LA PESTAÑA DE TRABAJO — «tendríamos que irnos al evento ③ y trabajarlo, porque ahí sí puedo explicar mejor los inputs y outputs según el tipo de evento». Sus filas de negocio se escriben con tu explicación. PASO 5 HECHO (25 tarde): la entrada del datalake live/pinned, los dos escalones de permiso, n campos por ③ y la cadena — escritos aquí Y en el contrato (3 clases · la S pos.2 · el output de toda regla · 3 leyes; el 26 por la tarde: 9 GATES EN VERDE LACRADOS POR EL AUDITOR —fe— sobre el contrato de ahora mismo, y mi cortesía sin caché en verde · consola 200). Y AHORA LAS COLUMNAS DE LA (c), validadas («valido, exacto, todo cuadra según el DMN»): situación × tipo de acción de campo × dominio eligen la fila; los inputs del datalake, la función y la vigencia son sus condiciones. Tu ejemplo fiscal es la primera fila de negocio. HECHO después: la S completa (snapshot_type), las once componedoras del sobre (entries 0–10), los cuatro datos fundamentales (x · y · X · Y) y el grupo de la acción. Los campos del sobre, tras el 26: sig (D1: el snapshot ES la firma; referencia id + sig) · id (D2: NIP-01 + \u00XX) · content (content_by_kind: su clase la dice el kind) · pubkey (D6c/D8: la credencial del actor en SU instancia de bóveda; PQ cross-firmada) · created_at y kind (derivados del nodo y de la FSM). Y las CINCO leyes de la mañana más las DIECIOCHO de la tarde, todas en su sitio en esta pestaña y en la guía.

DRD — las cuatro figuras de la norma DMN, y son las nuestras (validado 25):

DRD — las cuatro figuras de la norma DMN, y son las nuestras (validado 25): DECISION el CAMPO DE NEGOCIO que nace (su clase valor campo + writes_to) · INPUT DATA las variables del DATALAKE — cada una con su contexto de origen (clase objeto valor), su snapshot_live/snapshot_pinned heredado, sus filtros REQ y EL CONTRATO DE SUSCRIPCIÓN que la permite · BUSINESS KNOWLEDGE MODEL el contexto al que se llama para LA FUNCIÓN (una por regla, y puede ser muy distinta: ⬡ + sha256 — con D4 es un .wasm por sha256 en el almacén, ejecutado AISLADO y como INSTANCIA en el contexto de la función

DICTADO (26): body_hash = sha256 del.WASM (lo que se ejecuta), nunca del fuente — cada nodo con su lógica:

DICTADO (26): body_hash = sha256 del .WASM (lo que se ejecuta), nunca del fuente — cada nodo con su lógica: la regla entra en el flujo del contexto de infra cuya lógica es EJECUTAR; el que CONSTRUYE (fuente + especificacion_artefacto → .wasm) es otro contexto de infra y su ④ guarda hash del fuente → hash del .wasm; nodos ejecutores intercambiables por determinismo (entries/12.body_is · ley infra_two_contexts)

) · KNOWLEDGE SOURCE gobernanza — el CO y el usuario en nombre del CO · DECISION TABLE ejecutar_accion_campo · HIT POLICY PRIORITY sobre la columna dominio: CO de la instancia > CO del contexto > aarpia («gana la del CO siempre que tenga permisos para crearla» — el permiso es PREVIO: sin él la fila no existe) · DENTRO DEL DOMINIO UNIQUE (validado 25 noche): mismo dominio, situación y role ⇒ las filas NO se solapan; solaparse es rojo; el entero priority RETIRADO — «primero esta, luego aquella» es una condición (vigencia, inputEntries), nunca un número · AUTHORITY el manifiesto del tipo — y esto es lo que EL WORKER va a buscar para ejecutar

P	I N P U T S — la (c): situación × tipo × dominio · Input Data · BKM · vigencia · Knowledge Source							O U T P U T S — compound (Decision)
P	situationtipo de token · proceso · estado · fase — DERIVADA de graph_facts, jamás tecleadatoken_type · process_type_id · lifecycle_state · lifecycle_phase	field_action_rolequé clase de acción de campo: transduction · trigger · validationfield_action_role (enum)	domainde quién es la regla — PRIORITY: instancia > contexto > aarpiaenum de tres	datalake_inputs (Input Data)n variables, cada una: contexto de origen · resolution: snapshot_live (por señas → REQ #l #C #L #T #F + kinds) \| snapshot_pinned (por referencia id + sig) — la clase 17, una sola escritura (línea roja 4) · filtrosvalue_object{origin, value_type} · event_reference.id_and_signature	function (BKM)la función custodiada — una por regla; con D4: un .wasm por sha256, y CADA EJECUCIÓN ES UNA INSTANCIA EN EL CONTEXTO DE LA FUNCIÓN — su worker ejecuta, su ③/④ registran worker · .wasm · ejecutor · inputs · memoria · duración, y este ③ lee ese ④ y lo mete en su S (ley function_execution_is_an_instance_of_its_context)object.function_reference.snapshot_and_body_hash	validityde una fecha a otra fecha (opcional; ausente = siempre)time_instant × 2	permission (Knowledge Source)DOS ESCALONES: contrato de suscripción del CO con el contexto que vende (aunque sea el mismo CO) · permisos que ese CO dio al usuario ≥ estos datos; caducan ⇒ sin acceso, lo escrito no se invalidaaarpia.gobernanza.contrato.vigente (andamio H42)	valueel valor de negocio TIPADO por su clase valor campo	writes_toproperty_name.snake_case — EL CAMPO que nace	moment_snapshotslist_of_resolved_snapshots — cada ⬡ resuelto CON su marca snapshot_live \| snapshot_pinned (alimenta la S)
R-F	any	transduction	aarpia	constante del tipo				F: ["F", ⬡e3f5b4e635f0…, "field_action_execution"] — tag.string_tuple
R-k	any	transduction	aarpia	constante del tipo				kind: 3303 (regular) → la base de su canal (+ el archivo por backfill) — protocol_kind kind_catalogue: 3303 = ③ acción de campo ejecutada, firmado por el worker content_by_kind 3303: la clase de sobre del documento del ③ se define en la revisión final; el output ya lleva la suya (canonical_form_is_the_format)
R-c	any	transduction	aarpia	el output compuesto de la regla ejecutada				content: EL DOCUMENTO con su output — el dato Y el campo al que va DICTADO (26): la forma canónica ES EL FORMATO de la clase valor campo del output — las… DICTADO (26): la forma canónica ES EL FORMATO de la clase valor campo del output — las 6 clases object/array del catálogo llevan semantic_format.serialization = rfc8785; el documento del ③ la hereda por su clase (el dato viaja tipado con su forma). Determinista mientras no cambie la versión de esa instancia; cambiarla es una versión nueva. Ley canonical_form_is_the_format LA HUELLA (26, d6/d7 — ley hash_is_of_the_stored_bytes): LA HUELLA (26, d6/d7 — ley hash_is_of_the_stored_bytes): sha256 SIEMPRE de los bytes tal como se guardaron; el formato de la clase dice qué bytes son admisibles AL ESCRIBIR (object/array: solo rfc8785 — las 8 clases del catálogo que lo son llevan serialization; un cuerpo de código: tal cual se custodió, string.source_code.as_custodied, clase 28; un cuerpo binario —el .wasm—: object.blob_reference.sha256_size_mediatype, clase 29); JAMÁS se canoniza al verificar — se canoniza antes de escribir. Deuda de época medida por el auditor: 242 de 366 contents JSON y 40 de 276 cuerpos custodiados no canónicos; su huella sigue siendo la de sus bytes crudos (82/82 crudo contra crudo)
R-live	any	any	any	input pedido POR SUS SEÑAS (token · contexto · estado/fase · CO) — el REQ filtra las posiciones indexadas, jamás por ⬡	any	any	contrato vigente ∧ permiso ≥ estos datos	el dato (puede ser un object: el paquete que me venden)	su campo	+ {⬡ de la instancia de contexto EN EL MOMENTO, "snapshot_live"}
R-pinned	any	any	any	input pedido POR SU REFERENCIA id + sig — el id filtra (ids), el sig verifica: el dato de ESA versión, sin señas	any	any	contrato vigente ∧ permiso ≥ estos datos	el dato de esa versión	su campo	+ {⬡ pedido, "snapshot_pinned"}
R-sin-permiso	any	any	any	any	any	any	sin contrato de suscripción ∨ sin permiso del usuario ∨ caducados	NO HAY LECTURA — el input no entra; el desenlace lo dice el ④ con su kind; la historia ya escrita no se invalida
R-n-campos	② con n campos de negocio del MISMO proceso			any	LA MISMA función para los n	any	any	UN SOLO ③ con n outputs — uno por campo, una a por cada tipo; UNA firma del worker cubre los n
R-cadena	② con campos encadenados			el output del anterior es el input del siguiente	any	any	any	EN COLA — content → id → sig → snapshot del evento; y TODOS los ③ se validan en el ④ A LA VEZ, en UN mensaje de acción evento
R-modos	② con n acciones de campo — siempre del mismo proceso			any	distintas reglas o funciones → EN PARALELO (como las etiquetas) · misma regla y función → A LA VEZ · encadenadas → EN COLA	any	any	granularidad TOTAL desde la petición: unas en paralelo, otras juntas, otras en cola
EJEMPLO DE NEGOCIO DEL OPERADOR (25 tarde) — el usuario fiscal, no técnico, en nombre de su CO, en la pestaña de reglas del registro de instancias: PRIORITY entre R1 · R2 · R3
R1	empresa · intermediate · alta	transduction	context_owner_of_instance	cif ← registro mercantil de España (live: #l #C #L) · régimen ← catálogo de regímenes de actividad (pinned: id + sig)	fn_actividad ⬡… + sha256 — «este dato con aquel»	2026-01-01 → 2026-12-31	contrato de suscripción con los DOS contextos ∧ usuario en nombre del CO	actividad_económica (enumeration del catálogo)	actividad_económica	{⬡cif, snapshot_live} · {⬡régimen, snapshot_pinned}
R2	misma	misma	context_owner_of_context	la regla del CO dueño del contexto — pierde ante R1 por PRIORITY				…
R3	misma	misma	aarpia	la regla común — pierde ante R1 y R2				…
	LAS COMPONEDORAS del sobre con esta forma — HECHAS (entries 0–10) — EL GRUPO DE LA ACCIÓN (dictado 26, forma final): C · l · x · y juntos y en orden, sus ① distintos — lo que el usuario trae: CO, token, tipo de contexto, tipo de proceso («conocemos el contexto y el proceso, no sus instancias»: X · Y y L los abre o resuelve el kind). LAS ONCE ETIQUETAS CON SU COMPONEDORA: componer_l (0) · S (1) · C (2) · L (3) · T (4) · a (5) · F (6) · x (7) · y (8) · X (9) · Y (10) — los cuatro datos fundamentales (por su type_id: componer_etiqueta_l · _S · _C · _L · _T · _a · _F · _x · _y · _X · _Y). Y LAS LEYES DEL SOBRE (clase_accion_evento.envelope.laws, verificadas 26-ago contra el contrato desplegado): s_formula · the_action_group · geneses_are_distinct · four_fundamental_data · cardinality_is_data (la cardinalidad de cada etiqueta es un dato: one · one_per_consumed · one_per_executed_field_action) · positions_have_their_epoch (cada posición lleva su in_force_from y su history: un evento se juzga contra la forma de su época) · pinned_position_never_moves (la ① es la que el relay indexa: ahí va lo que no cambia en ningún evento) · only_the_alias_position_is_legible (la ley sagrada: el alias es el único sitio legible del sobre) · no_state_tag (sin etiqueta de estado: el estado lo dice el proceso, por el kind) · field_actions_in_the_event (una a por manifiesto ejecutado) · y las del 26: canonical_form_of_documents · control_characters_in_id_serialization · batch_attestation_is_two_events (max_leaves 1000; techo medido 1 149) · request_envelope (el ①: grupo C·l·x·y + F + S, alias vacío; la p deuda a eliminar) · agent_request_telemetry · T_pairs_with_l · process_classes_by_token_type (7 clases de proceso · 16 DMN · 8 filas) · kind_catalogue (los 19 kinds como dato, cada uno un token del andamio con su snapshot; cargas con el emisor nuevo) · content_by_kind (la clase del content la dice el kind). Y en clase_valor_campo: admitted_facets_by_primitive_type · canonical_form_is_the_format · hash_is_of_the_stored_bytes (la huella es siempre de los bytes guardados; la clase manda al escribir; jamás se canoniza al verificar). LOS CAMPOS: sig (D1) · id (D2) · content por kind (d7) · pubkey en su instancia de bóveda (D8) — created_at y kind derivados
EL MANIFIESTO (validado por el operador el 26 — ley clase_accion_campo.law_inside.the_manifest): NO es documentación del tipo de acción de campo: ES EL TIPO DE ACCIÓN DE CAMPO, PUBLICADO — cada instancia de tipo_accion_campo.declarado es un evento 33300 direccionable por su d (alias compuesto), cuyo content es el documento declarado (o su huella al almacén); su versión ES su snapshot. Lleva DIRECCIONES, jamás valores: el verbo (trigger · transducción · validación), la situación, el dominio, sus inputs (cada uno con la dirección de su origen — clase objeto valor, resolución heredada — y de su formato), su output (clase valor campo), la regla (token parte, por dirección con snapshot), la función (el .wasm por sha256), el worker, la gobernanza del CO — todas pinned: sella el árbol entero. Común a todos los canales o UNO POR CO (el ContextVM lo elige por la C). TRES PAPELES DE UN SOLO DATO: lo que el ContextVM ejecuta · la skill del agente IA (D10) · lo que el ④ cita con su a. TRES MANIFIESTOS: el del contexto (type) · uno por tipo de acción de campo · el asyncapi — los tres 33300 por su d; el nodo republica su índice (medida del nodo, no fe). Deuda dicha: los manifiestos de las once componedoras están declarados (published_as con su d) y NO publicados (snapshot null × 11 — B1): se publican con el emisor nuevo.
EL ALINEAMIENTO COMPLETO (dictado 26 — ley the_complete_alignment; repasado con el auditor por encargo del operador): EL TIPO DE ACCIÓN DE CAMPO ES EL PUNTO DONDE TODO SE CRUZA — los 4 mensajes (① pide · ② compone · ③ ejecuta · ④ valida, cada uno con su kind leído de los verbos) · las 6 clases (inputs = objeto valor; output = valor campo; regla = token parte; acción de evento = kind; proceso = fase; contexto = identidad) · los 3 dominios · los 3 verbos · las piezas de Go (evaluador D3 · validador D5 · .wasm D4 · Canonicalize · sha256 de los bytes guardados) · el agente (la skill MCP es el mismo manifiesto, D10) · la firma (la instancia de bóveda y su payload). LA DMN CON SUS n REGLAS ES DONDE SE MIDE: situación × papel × dominio × validez; PRIORITY instancia > contexto > aarpia, UNIQUE dentro; y por fila la línea roja 4 — un input sin su clase es una regla que no existe. MILIMÉTRICO = tres comprobaciones: (1) cada fila la ejecuta el motor leyendo SOLO el contrato; (2) la misma fila produce la skill MCP y el documento del ③ — tres vistas, un dato; (3) por kind, cada input/output sabe qué regla le aplica (la tabla de la revisión final). MEDIDO POR EL AUDITOR (26): (a) de las seis direcciones del manifiesto, CUATRO son dato (tipo de valor 55 · objeto valor 44 · regla · función 11/11) y DOS solo prosa — open_hole (contrato): open_hole (contrato): worker_address — «worker» 11 veces, todas en texto: qué worker puede ejecutar el tipo no es input de ninguna componedora; a dictar (input por tipo, o dato del nodo) open_hole (contrato): open_hole (contrato): execution_governance — HAY DOS GOBERNANZAS y solo una tiene dato: scope · editable · author dicen quién puede EDITAR el tipo; el permiso del CO para EJECUTARLO (la que nombra la constitución) es prosa (16 veces): a dictar como input (aarpia.gobernanza.contrato.vigente, live), leído en ② y validado en ④ — y de los tres verbos hoy solo cruza UNO en las once componedoras (transduction × 11; trigger y validación esperan la revisión del ④); published_as.snapshot null × 11 (B1). Corrección medida por mí a su (a): writes_to y moment_snapshots están 11/11 bajo output. (su «null × 11» leía una ruta que no existe — «ausente» no es «null»). (b) De 55 claves de una componedora la ley nombra 26; con papel y sin nombrar: scope · editable · author · writes_to · moment_snapshots · published_as · hitPolicy. (c) LAS TRES COMPROBACIONES SON HOY INMEDIBLES y describen el estado futuro: la 1 hasta que exista el motor (su condición necesaria sí está en verde: toda variable de inputEntries declarada en inputs — gate logica_de_las_reglas); la 2 hasta que se publique el primer manifiesto de componedora (10 eventos 33300 en el registro, 0 de 11 son componedoras); la 3 hasta que se escriba la tabla por kind. Hoy la ley no se puede verificar contra nada, y eso está escrito.
annotation — LOS CAMPOS COMUNES (los mismos en los 4 tipos): pubkey → EL WORKER — un worker por ③ (n campos, UNA firma); ejecuta y FIRMA su ③ («cuando quien ejecuta es una máquina, el actor es la máquina — y sigue habiendo actor») (public_key; quién es lo resuelve gobernanza) · created_at → el reloj DEL NODO EJECUTOR, leído una vez y congelado (time_instant; el OTS ancla) · id → sha256 de la serialización canónica NIP-01, controles como \u00XX (D2, ley control_characters_in_id_serialization) (hash, recompute) · sig → LA BÓVEDA firma con la credencial del actor (signature — EL SNAPSHOT: verify, jamás recompute §A; D1 confirmada el 26: el snapshot ES el sig y la referencia a un evento es id + sig; D6c: la clave PQ es una credencial más de la bóveda —semilla de 32 B, ExternalMu-ML-DSA (RFC 9881 App. D; jamás HashML-DSA §5.4, que RFC 9881 §8.3 prohíbe — cazado por el auditor el 26)— cross-firmada con la Schnorr en el registro del CO) · la S → desciende del ② que ejecuta + cada ⬡ que resolvió, con su snapshot_type en la ③ posición (s_formula: ninguna marca dice si una S es consumido del flujo o lectura del datalake) · y las ONCE etiquetas del sobre con sus pares de clases — el grupo de la acción C · l · x · y primero, y L · T · S · a · F · X · Y. Y EL DATALAKE ES LA SUMA DE LOS REQ GUARDADOS: la petición con sus filtros y lo que volvió son los inputs resueltos del ③, su traza va a la S del ④, el archivo lo conserva — qué leyó cada CO, cuándo, bajo qué contrato: la trazabilidad total y la prueba de lo «comprado».

CEIPs: CEIP-03CEIP-06CEIP-09CEIP-10

④ event_action_validation ⬡ 723fde7f2244… — acción EVENTO · el ContextVM notario sella

DECISION componer_etiqueta_l — DECLARADA (canonical_field_action_types/0;

DECISION componer_etiqueta_l — DECLARADA (canonical_field_action_types/0; la etiqueta l la referencia) · HIT POLICY UNIQUE · QUESTION ¿qué etiqueta l nace para esta instancia? · INFORMATION REQUIREMENTS token_genesis · token_registration_snapshot · token_alias · fn_compose · KNOWLEDGE REQUIREMENTS rules_engine · contrato.evento (⬡+sha256) · AUTHOR 6e33c72a…63f7 (el agente — repaso final pendiente)

U	I N P U T S				O U T P U T S — compound
U	token_genesisaarpia.registros.token.registrado (live)genesis.random_hex128 (clase 25 — el génesis es azar opaco, no una firma; 26-ago)	token_registration_snapshotaarpia.registros.token.registrado (live)signature	token_aliasaarpia.registros.token.registrado (live)alias.four_parts_dotted	fn_composeaarpia.infra.funcion_codigo.activo · d: contrato.evento (pinned · andamio)function_reference	ltag.string_tuple	writes_toproperty_name: "l"	moment_snapshotslist_of_resolved_snapshots — cada ⬡ resuelto con su snapshot_type (alimenta la S)
R1	inputEntries: {"!!": {"var":"token_registration_snapshot"}}		— el token resuelve en su registro		outputEntries.l: ["l", génesis, ⬡registro, alias] — ① pinned · ② live · ③ alias
R2	inputEntries: {"!": {"var":"token_registration_snapshot"}}		— aún no registrado		outputEntries.l: ["l", génesis, génesis, alias] — la ley del arranque: jamás un error
R-F	constante del tipo (any)				F: ["F", ⬡723fde7f2244…, "event_action_validation"] — tag.string_tuple (legible: flow_step.enumeration)
R-k	LA SITUACIÓN: fase × tipo de token × acción de evento (la FSM)				kind: uno de los CATORCE del ④ (14 números de kind; 16 tablas desde el 26, la fila initial·parte reutiliza 3304/3305) (kinds.go: 3304 trigger · 3305 validado · 3306 sella final · 3307 sella final_alt · 3308 rechazo · 3310/3311 loop · 3312 sin sello · 3313 create intermedio · 3314 create loop_activo · 3315 create loop_inactivo · 3316 create final · 3317 create final_alt) — SE LEE de la fila FSM (clase_accion_evento.decisions[fsm]: 16 reglas desde el 26 = 8 FILAS × create/transition — las 6 fases del token de contexto + initial · intermedio del token PARTE; ley process_classes_by_token_type: LA CLASE DE PROCESO ES <proceso><tipo de token> — 7 clases de proceso (5 + 2), 16 tablas de decisión (12 + 4; 17 decisiones con la fsm); el parte NO tiene loop, final ni final_alt: son siempre del contexto; fsm_rule_15/16 y create/transition_initial_part añadidos el 26 — el initial del parte escucha el ① dentro de una instancia de contexto viva en initial o intermedio, dispara una instancia por parte y funda el génesis del parte, 3304/3305), jamás se elige; condensa el paso, el desenlace, la fase y el tipo. El 3309 NO es un ④ (es el lote); 3308 y 3312 no salen de la FSM: el rechazo se lacra y no mueve el snapshot, el sin-sello solo trae el dato a su campo
R-c	constante del tipo (any)				content: "" — VACÍO: las etiquetas SON las direcciones (al bus solo direcciones) content_by_kind (26, d7): EMPTY para los 14 kinds del ④, como ley
R-T	el tipo del token, leído LIVE del catálogo de tokens (¿sigue catalogado? ¿dónde está anidado?)				DICTADO (26, 11:45Z — ley T_pairs_with_l): DICTADO (26, 11:45Z — ley T_pairs_with_l): LA T SE CONSTRUYE COMO LA l Y VA PAREJA A ELLA — [T, génesis del TIPO (pinned: nace al crear la instancia del tipo de contexto declarado, token o parte, con el mismo nombre que la l), ⬡ instancia loop_activo del tipo en el catálogo (LIVE), alias del NIVEL ESTÁNDAR de aarpia donde está anidado (los tipos de activo del DRD son los niveles; n niveles con el contexto del catálogo)]; en el evento que crea el tipo ② = ①; si el token se ELIGE entre los l existentes, la T sale del catálogo; componer_etiqueta_T reescrita (5 inputs; catalogued · founding · uncatalogued). Época anterior (dos posiciones) en history; deuda de emisor medida: 926 T de tres valores con el contenido invertido + 169 de dos, ninguna desde el 25 22:31Z
R-lote	al cerrar el LOTE de ④ — ley envelope.laws.batch_attestation_is_two_events (D6, dictado 26): un árbol Merkle (RFC 6962) sobre las FIRMAS del lote, una raíz, dos sellos				3309 INMEDIATO: hojas = sus S (una por evento del lote, en orden de árbol; tree_size = nº de S ⇒ cualquier prueba de inclusión se deriva del 3309 solo) · content {root, tree_size, mldsa44_signature, ots_pending, witness_cosignatures (D9)} · 3318 HORAS DESPUÉS: la prueba OTS definitiva citando al 3309 por S. OTS = cuándo · ML-DSA = quién responde. NACE COMPLETO (born_complete): las hojas son sus S en orden de árbol, raíz y tree_size en el content, y el sitio para las co-firmas del testigo desde el primer evento. DICTADO (26, d10): 1000 hojas por lote como DATO del contrato (max_leaves); DICTADO (26, d10): 1000 hojas por lote como DATO del contrato (max_leaves); al llegar a 1000 se cierra y empieza otro; techo MEDIDO por el auditor 1149 (cmd/techo_del_lote: bisección publicando y releyendo, dos kinds; hoja 221 B, cabecera 6 949 B; maxEventSize 262 144 aplicado vs 524 288 declarado; maxNumTags 2 000 no muerde). Margen a 1 000: 34195 B libres (154 hojas de holgura): las co-firmas del testigo caben (~170), el tree_size es irrelevante; el factor real es un relay externo — el «265» es CALCULADO sobre un 64 KB supuesto, no medido: con 1 000 el 3309 no sale de casa, y si un día debe salir se mide ESE relay F_tag (26, d4): el 3309 y el 3318 SÍ llevan F — también son instancias de un contexto; F_tag (26, d4): el 3309 y el 3318 SÍ llevan F — también son instancias de un contexto; qué F y en qué fase lo dice el kind; el valor concreto se define al final, tipo de evento por tipo de evento (envelope.tags[F].non_flow_kinds)
R-archivo	el archivo, al publicar un checkpoint de su registro Merkle (raíz + tamaño) — un árbol DISTINTO del lote: el del archivo es sobre los id de todos los eventos; el del lote sobre las firmas de un ContextVM				DICTADO (26, D9 — ley archive_transparency_log_and_witness): DICTADO (26, D9 — ley archive_transparency_log_and_witness): el archivo mantiene un tlog RFC 6962 de los id y publica checkpoints; la prueba de consistencia entre dos demuestra «solo crece» entre ellos (17 hashes + 5 tiles para 60,8 M, con control negativo); LÍMITE de la norma: sin testigo el archivo es tercero de confianza (RFC 9162 §1). EL TESTIGO CO-FIRMA CADA CHECKPOINT ANTES DE PUBLICARSE — sin co-firma no se publica (tlog-witness v1.0.0: en la ruta de publicación). EL TESTIGO ES EL AUDITOR GIT — hoy, en pruebas, firma el ContextVM de su nodo andamio; mañana el contexto testigo tendrá su nodo y cada co-firma será una instancia validada por su ContextVM. Obligaciones del testigo (sus 7 MUST (witness_obligations): verificar la firma del origen · 404 si origen desconocido · prueba de consistencia · 409 si el tamaño viejo no es el del ÚLTIMO que él co-firmó · raíces idénticas · PERSISTIR antes de responder · 422 si no verifica) ⇒ el testigo TIENE ESTADO. Atomicidad. El simulacro verifica la consistencia antes de leer un cuerpo; las actas del auditor entran en el mismo registro límites dichos: el testigo NO resuelve el split view por sí solo («under discussion» en la spec); límites dichos: el testigo NO resuelve el split view por sí solo («under discussion» en la spec); independencia medida: contenedores · volúmenes · claves: VACUA — el archivo (strfry) NO TIENE CLAVE, no firma nada por diseño; y el checkpoint lo firma el log: el archivo necesita una identidad propia (pending; lectura no decidida: su ContextVM como usuario-contexto en la bóveda) open_hole (contrato): open_hole (contrato): independence_of_custody — con clave, archivo y testigo serían dos USUARIOS de la misma bóveda: ¿basta, o el testigo custodia aparte? Sin norma que lo diga; lo decide el operador antes del primer checkpoint pending: el kind del checkpoint y la clase de su content (revisión final); el ctx si va con ML-DSA
R-kinds	todo kind del sistema				DICTADO (26, d11 — envelope.kind_catalogue): DICTADO (26, d11 — envelope.kind_catalogue): LOS 19 KINDS COMO DATO — los 14 del ④ (propiedad de decisions[fsm], listados para que haya un solo sitio) + ① 23301 · ② 23302 · ③ 3303 · lote 3309/3318 · manifiesto 33300 — cada uno con paso, papel, permanencia, clase de content (content_by_kind) y SU TOKEN del andamio (salida aarpia.catalogos.kind.vigente, snapshot null hasta la carga: «son tokens también, ahora en andamio, con sus snapshots»); kinds.go se DERIVA de la tabla en 1.27. Cargas: CON EL EMISOR NUEVO (opción 1) — el de hoy escribe la T vieja y el ① en claro, y 11 de los 19 kinds no han emitido un solo evento (auditor)
	LAS ONCE COMPONEDORAS DEL SOBRE HECHAS (entries 0–10: l · S · C · L · T · a · F · x · y · X · Y); quedan los campos: pubkey · created_at · kind · content · calcular_id · firmar_sig — tres fijados el 26: sig (D1), id (D2), content del ① y pubkey PQ (D6)
annotation — LOS CAMPOS COMUNES (los mismos en los 4 tipos — la ley matizada): pubkey → EL NOTARIO — el ContextVM: su firma ES el sello del contexto; el sig ES el snapshot (CEIP-01); con D6c su clave PQ (ML-DSA-44) es una credencial más en la bóveda, cross-firmada con la Schnorr en el registro del CO, y con ella firma la raíz del lote (3309) (public_key; quién es lo resuelve gobernanza) · created_at → el reloj DEL NODO EJECUTOR, leído una vez y congelado (time_instant; el OTS ancla) · id → sha256 de la serialización canónica NIP-01, con los controles 0x00–0x1F como \u00XX (D2, ley envelope.laws.control_characters_in_id_serialization; medido por el auditor: 0 casos en 1 646 eventos, los 1 646 ids recomputan; el id de go-nostr no pasa por encoding/json) (hash — content-addressed por sí mismo, recompute) · sig → LA BÓVEDA firma con la credencial del actor (signature — EL SNAPSHOT: verify, jamás recompute §A; D1 confirmada el 26: el snapshot ES el sig y la referencia a un evento es id + sig; D6c: la clave PQ es una credencial más de la bóveda —semilla de 32 B, ExternalMu-ML-DSA (RFC 9881 App. D; jamás HashML-DSA §5.4, que RFC 9881 §8.3 prohíbe — cazado por el auditor el 26)— cross-firmada con la Schnorr en el registro del CO) · la S → s_formula ENTERA: los consumidos del flujo (el ①, la proyección UTXO anterior, los ③) + los moment_snapshots de las reglas que el ④ ejecutó (gobernanza, permisos, contrato de suscripción — los propios del ④); el ④ NO repite las lecturas de sus ③ — cada S = [S, id, sig, ⬡snapshot_type, legible] desde el paso 5 — una etiqueta S por cada uno · y las ONCE etiquetas del sobre con sus pares de clases — el grupo de la acción C · l · x · y primero, y L · T · S · a · F · X · Y (la l, C, L, T del estado de la instancia; la a de los tipos ejecutados). Posiciones pinned · live · snapshot_type · alias (los CUATRO roles dictados — envelope_tag.role; la S lleva ⬡snapshot_type en la ③); solo la ① se indexa (NIP-01); sin etiqueta de estado. Y el desenlace es suyo: valida (3304–3307 · 3310–3317) o no valida — y no validar es el RECHAZO 3308 (se lacra y NO mueve el snapshot), que no es lo mismo que la transición VALIDADA a final_alt (3307: sella).

CEIPs: CEIP-01CEIP-02CEIP-03CEIP-04CEIP-05CEIP-06CEIP-07

EL CONTRATO aarpia VOE MAPEADO A GO 1.27 — DESDE LAS CLASES DE aarpia, nunca al revés · abierta el 2026-08-26 · se rellena a medida que el operador decide

Cada fila parte de un elemento del contrato (una clase, una etiqueta, un campo del…

Cada fila parte de un elemento del contrato (una clase, una etiqueta, un campo del evento, una faceta) y dice con qué pieza de Go 1.27 se construye, qué se escribe nosotros y se custodia como código y qué decisión lo fija. Estados: open_hole (contrato) (hueco que el contrato declara, con quién lo decide) · decidido (con el dictado y su fecha) · derivado — sin decisión (sale solo de la ley o de una decisión ya tomada). Marcas de Go: pieza de la biblioteca estándar · Go NO lo trae (se escribe o se custodia) · dependencia de fuera. Esta pestaña documenta, no legisla: el contrato (los seis JSON) no se toca desde aquí. Fuente: agente-contextvm/investigacion-go-1-27.md (§2 y §3) y sus anexos A–E.

0 · LAS ONCE DECISIONES — 11 decididas · 0 esperan (cerradas el 26) — el índice de esta pestaña

D	la pregunta, en llano	lo que propongo	filas de esta pestaña que fija	estado
D1	Qué es un snapshot: la FIRMA (sig) o el id	sigue siendo la firma; toda referencia lleva id + sig	clase objeto valor · firmar_sig (calcular_id es D2; las etiquetas son derivadas)	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: el snapshot es la FIRMA (sig); la referencia a un evento lleva el par id + sig (el id pide en el REQ, la firma verifica) — la ley vigente, confirmada
D2	La forma canónica de un documento antes del hash	RFC 8785 (JCS) puro; números grandes como texto con formato; controles 0x00–0x1F fijados	clase acción evento · calcular_id · Documento	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: los documentos se canonizan con RFC 8785 (JCS) puro, tal cual lo trae Go 1.27 (jsontext.Value.Canonicalize); los números grandes de negocio van como texto con su formato declarado (una clase valor campo); el id del evento sigue la regla de NIP-01 y el contrato fija los controles 0x00–0x1F como \u00XX
D3	El motor de las reglas JSON Logic	evaluador propio pequeño, custodiado como token de código (BKM)	clase acción campo · reglas · DMN	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: evaluador JSON Logic propio, escrito en Go y custodiado como token de código (BKM) en el nodo andamio — dentro del registro no por ser Go sino por estar custodiado y ser reproducible; las tablas se dicen «a la manera DMN 1.5», no «conformance DMN»
D4	Las funciones de negocio: Wasm y su ejecutor	el .wasm como blob sha256; wazero custodiado como especificacion_artefacto	funciones custodiadas · almacén de blobs	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: las funciones de negocio custodiadas se compilan a WebAssembly (GOOS=wasip1) — el .wasm es un blob por sha256 en el almacén, direccionado pinned desde la regla y ejecutado aislado (sin reloj, azar ni red del nodo); el ejecutor wazero (Go puro, sin CGO) se custodia como especificacion_artefacto; plugins de Go descartados · A (dictado 26): CADA EJECUCIÓN DE LA FUNCIÓN ES UNA INSTANCIA EN EL CONTEXTO DE LA FUNCIÓN — el ContextVM que llama entra como actor solicitante; el worker de ese contexto ejecuta el .wasm y su ③/④ registran el cómputo (worker por su clave, .wasm y ejecutor por hash, inputs por snapshot, memoria y duración); el que llama lee el snapshot y lo mete en su S. Ley function_execution_is_an_instance_of_its_context
D5	La validación de las facetas	validador propio (pattern RE2 declarado · enum · min/max exactos · length · items); format siempre aserción	clase valor campo · facetas	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: validador de facetas propio (pattern en RE2 declarado · enum · min/max exactos · length · items · format SIEMPRE aserción), custodiado como código — EaaC, siempre por código; LO ESCRIBE EL AUDITOR GIT (dictado: para eso está, entre otras cosas), y más adelante queda como nuestros tests en el sistema de repositorio propio (la forja) · POR TIPO (dictado 26): tabla de facetas admitidas por tipo primitivo como DATO en clase_valor_campo.law_inside.admitted_facets_by_primitive_type — string: pattern·enum (+minLength·maxLength·format reservadas) · integer: minimum·maximum · array: minItems (+maxItems·items) · object: required · boolean: ninguna; type obligatoria en las 25 = primitive_type; una faceta fuera de la tabla de su tipo es ROJO; el validador la lee, sin listas dentro
D6	El plan postcuántico	① primero (hpke X-Wing, ya en 1.26) · atestación ML-DSA-44 por lote en OTRO evento · bóveda con External μ · cross-firma de claves · no: SLH-DSA, composite, determinista	content del ① · firmar_sig · pubkey · el 3309	decidido 2026-08-26 · las cuatro piezas validadas: decidido 2026-08-26 · las cuatro piezas validadas: a) primero el cifrado del ① con HPKE híbrido X-Wing (ya en Go 1.26) · b) la firma PQ (ML-DSA-44) en un evento de atestación POR LOTE, firmando LA MISMA RAÍZ Merkle que ancla OpenTimestamps (un lote, una raíz, dos sellos: OTS = cuándo, ML-DSA = quién responde; retro-atestación de la historia) · c) la bóveda: clave PQ como credencial más (semilla 32 B, firma sin ver el documento) y cross-firma Schnorr↔PQ en el registro del CO · d) no: composite propio, SLH-DSA, FN-DSA, determinista en producción. Queda por MEDIR: si la atestación va en el mismo 3309 o en evento propio, según cómo trate hoy el 3309 la prueba OTS tardía · CERRADA (dictado 26): DOS EVENTOS POR NECESIDAD — 3309 inmediato (raíz del lote + tamaño + firma ML-DSA-44 sobre la raíz + compromiso OTS pendiente) y 3318 horas después (prueba OTS definitiva, cita al 3309 por S); un lote, una raíz, dos sellos. Ley batch_attestation_is_two_events
D7	Subir el build a Go 1.27	sí: golang:1.27.0-alpine · go 1.27 + toolchain en go.mod · GOTOOLCHAIN=local en CI; go-nostr probado bajo 1.27 (auditor)	especificacion_artefacto	decidido 2026-08-26 · opción 1, YA: decidido 2026-08-26 · opción 1, YA: el build nuevo nace en Go 1.27 — golang:1.27.0-alpine, go 1.27 + toolchain go1.27.0, GOTOOLCHAIN=local en CI; las tres vigilancias de huellas; el contexto del framework de clases se crea en 1.27 con todo lo decidido (dictado: hasta cerrar todas las decisiones y crear el contexto de las clases no hay clases ni se construye — ahora se define todo)
D8	Las imágenes de contenedor como datos	manifest OCI en un evento; capas por sha256 en blobs; atestación in-toto/SLSA en DSSE dentro de un evento	especificacion_artefacto · almacén de blobs	decidido 2026-08-26 · opción 1 con dos precisiones del operador: decidido 2026-08-26 · opción 1 con dos precisiones del operador: (1) UNA imagen estándar del ContextVM por plataforma (el contexto es dato que el nodo carga por hash; manifiesto OCI en evento, capas/binario en blobs por sha256, atestación in-toto/SLSA); (2) el contexto viaja —a un móvil con su nodo— y habla por su canal; LA FIRMA: la bóveda tiene instancias — de casa, en el dispositivo (enclave custodia la semilla), o COLD WALLET (un solo nodo pide la firma a un dispositivo frío: id/μ, jamás el documento). Ley the_node_image_and_the_vault_instances en clase_contexto · LO QUE RECIBE EL FIRMADOR es dato de cada instancia de bóveda (opción 3): hash (id/μ: nada del negocio sale; bóveda de casa o enclave) o evento entero (la cold wallet con pantalla lo muestra y un humano confirma, como NIP-46/55 y las cold wallets de Bitcoin); NIP-46 (cifra con NIP-44, por relay) y NIP-55 (mismo dispositivo, Android) no son nuestra cold wallet: diseño propio, declarado
D9	El archivo con tlog y su testigo	log Merkle RFC 6962 de los id; el auditor co-firma cada raíz (tlog-witness); sin co-firma no se publica	el archivo · el 3309 · actas	decidido 2026-08-26 · opción 1 con precisión del operador: decidido 2026-08-26 · opción 1 con precisión del operador: el archivo mantiene un registro Merkle (tlog, RFC 6962) de los id y publica raíces; CADA RAÍZ LA CO-FIRMA EL TESTIGO ANTES DE PUBLICARSE (sin co-firma no se publica; RFC 9162 §1: sin testigo el archivo es tercero de confianza); el testigo es el auditor GIT — hoy, en pruebas, firma el ContextVM de su nodo andamio; mañana el contexto testigo tendrá su nodo y cada co-firma será una instancia validada por su ContextVM; atomicidad; dos árboles distintos (el del archivo y el del lote); el simulacro verifica la consistencia; las actas del auditor entran en el mismo registro. Ley archive_transparency_log_and_witness
D10	AI FIRST con MCP	contrato → schema → tool; SDK oficial de Go; sin adoptar lo no aprobado	manifiestos · agente IA del nodo	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: la puerta del agente IA es MCP (stateless, discover, orden determinista); cada nodo expone sus manifiestos como herramientas y el esquema de cada una SE DERIVA DEL MANIFIESTO, jamás del código Go; lo en revisión en MCP no se adopta; MCP ofrece, el evento ① es, el contrato decide. Y con él: EL MANIFIESTO como dato (ley the_manifest), LA a EN EL ① (una por manifiesto solicitado, alias vacío) y EL ALINEAMIENTO COMPLETO por el tipo de acción de campo y su DMN (ley the_complete_alignment, a repasar con el auditor)
D11	Los gates sobre testing (campo del auditor)	T.Attr · T.ArtifactDir · OutputType — se recoge, no se decide aquí	gates	decidido 2026-08-26 · cerrada por el operador (opción 1): decidido 2026-08-26 · cerrada por el operador (opción 1): deuda del arnés del auditor con fecha de adopción en el build de 1.27 — el arnés nuevo nace sobre T.Attr (veredicto tipado en -json), T.ArtifactDir (evidencias por prueba: modo fe / cortesía) y OutputType (línea clasificada); el arnés de hoy no se toca mientras se documenta; aviso escrito: AllocsPerRun entra en pánico con pruebas paralelas desde 1.25

A · LAS SEIS CLASES DEL CONTRATO → CÓMO SE CONSTRUYEN EN GO

clase aarpia	qué es (en el contrato)	cómo se construye en Go 1.27	piezas de Go	decisión	estado
clase_valor_campo	EL FORMATO (29 clases el 26: + cifrado del ①, documento del lote, fuente custodiado, referencia a blob): tipo primitivo + facetas admitidas POR TIPO; la forma canónica ES EL FORMATO de la clase (canonical_form_is_the_format: serialization rfc8785 en las object/array); la huella siempre de los bytes guardados (hash_is_of_the_stored_bytes) (D5 — clase_valor_campo.law_inside.admitted_facets_by_primitive_type): string: pattern · enum [+ minLength · maxLength · format reservadas] · integer: minimum · maximum · array: minItems [+ maxItems · items reservadas] · object: required · boolean: —; type obligatoria = primitive_type; una faceta fuera de la tabla de su tipo es rojo	UN SOLO molde: Documento {bytes tal cual · canónico · sha256}; el tipo primitivo como ETIQUETA en el dato (jsontext.Kind / enum propio), jamás un tipo de Go por clase; las facetas se comprueban con un validador nuestro; los patrones en dialecto RE2 (regexp de Go); números exactos con big.Rat	encoding/json/jsontext · regexp (RE2) · math/big · errors.Join Go NO lo trae (validador de facetas)	D5	decidido 2026-08-26 · D5: decidido 2026-08-26 · D5: validador propio, lo escribe el auditor GIT; facetas admitidas POR TIPO como dato del contrato; format siempre aserción — texto completo en el índice (0)
clase_objeto_valor	EL ORIGEN: el contexto concreto por su dirección de dos capas (alias + ⬡) y su resolución snapshot_live / snapshot_pinned · desde el 26 el catálogo LLENO: 12 contextos DERIVADOS de las componedoras (status open; resolución unánime de sus inputs o la naturaleza: registro/tipo declarado live, archivo pinned; etapa por regla: scaffold 4 · definitive 3 · declared 3 · contract 2; frontera dicha: value_object.origin es origen, value_type.ref.context es la clase — 12 vs 16)	la dirección se resuelve con un REQ de nostr (snapshot_live: filtros #l #C #L #T #F + kinds; snapshot_pinned: ids); la referencia a un evento es id + sig; los ⬡ repetidos se internan con unique	unique · net (WebSocket vía go-nostr) dependencia de fuera (go-nostr para el REQ)	D1	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: el snapshot es la FIRMA (sig); la referencia a un evento lleva el par id + sig (el id pide en el REQ, la firma verifica) — la ley vigente, confirmada
clase_accion_campo	EL MANIFIESTO (the_manifest: el tipo publicado, 33300 por su d; direcciones jamás valores; tres papeles de un dato): inputs con su clase objeto valor · output con su clase valor campo · reglas en tabla de decisión (a la manera DMN 1.5) con JSON Logic dentro · la ejecución de funciones como instancia del contexto de infra (function_execution_is_an_instance_of_its_context, dos contextos: construir · ejecutar) · la puerta del agente por MCP desde el manifiesto (agent_door_is_mcp_from_the_manifest) · EL ALINEAMIENTO COMPLETO (the_complete_alignment: el punto de cruce, la DMN donde se mide, tres comprobaciones; open_holes worker_address · execution_governance)	las reglas viven en LISTAS ORDENADAS (jamás map: Go no garantiza su orden y FIRST/RULE ORDER lo necesitan); el evaluador JSON Logic es código custodiado (BKM) que recorre jsontext.Value; typeRef de DMN = nuestras clases; se dice «a la manera DMN», no «DMN»	jsontext.Value · slices Go NO lo trae (motor JSON Logic)	D3	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: evaluador JSON Logic propio, escrito en Go y custodiado como token de código (BKM) en el nodo andamio — dentro del registro no por ser Go sino por estar custodiado y ser reproducible; las tablas se dicen «a la manera DMN 1.5», no «conformance DMN»
clase_accion_evento	EL SOBRE: once etiquetas con componedora · kinds por fase · 15 leyes del sobre · action_group · y desde el 26: kind_catalogue (19 kinds como dato) · content_by_kind · request_envelope (el ①) · T_pairs_with_l · batch_attestation_is_two_events · archive_transparency_log_and_witness · agent_request_telemetry · process_classes_by_token_type (16 DMN)	el evento NIP-01 se serializa A MANO (array posicional; go-nostr lo hace hoy y JSON v2 no cambia los ids); el contrato y las declaraciones se LEEN con json/v2 en estricto (RejectUnknownMembers · duplicados y UTF-8 inválido rechazados · error con JSON Pointer); la forma canónica de los documentos = RFC 8785 (jsontext.Value.Canonicalize)	encoding/json/v2 · jsontext.Canonicalize · crypto/sha256	D2	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: los documentos se canonizan con RFC 8785 (JCS) puro, tal cual lo trae Go 1.27 (jsontext.Value.Canonicalize); los números grandes de negocio van como texto con su formato declarado (una clase valor campo); el id del evento sigue la regla de NIP-01 y el contrato fija los controles 0x00–0x1F como \u00XX
clase_proceso	LA FSM: seis fases · create/transition · kinds · y desde el 26 LA CLASE DE PROCESO ES <proceso><tipo de token> (process_classes_by_token_type): 7 clases (5 del contexto + initial · intermedio del parte) · 16 DMN · 8 filas de la FSM; loop, final y final_alt siempre del contexto	datos interpretados sobre Documento (graph_facts + JSON Logic): el motor no sabe de fases, recorre lo declarado; los kinds se LEEN del contrato (contrato.KindsDesenlace)	interpretación — sin pieza propia	—	derivado — sin decisión
clase_contexto	LA IDENTIDAD: alias de cuatro procedencias · custody_goes_pinned · el CO · y desde el 26 EL NODO Y LA BÓVEDA (the_node_image_and_the_vault_instances): un nodo = ContextVM + tipo de contexto declarado; UNA imagen estándar por plataforma; el contexto viaja como dato; la bóveda tiene instancias (casa · dispositivo · cold wallet) y cada una declara qué recibe para firmar (cold_signer_payload: event_id · external_mu · whole_event); mldsa_ctx open_hole	datos interpretados; el alias se COMPONE (dominio · subdominio · token · estado deseable) desde sus contextos, jamás se teclea	interpretación — sin pieza propia	—	derivado — sin decisión

La regla que preside la tabla: Go no puede crear tipos mientras corre — y eso obliga a lo que la ley pide: el motor no ejecuta «el contexto X», ejecuta un manifiesto. Un solo molde (Documento) y las seis clases como datos; cero código por tipo, cero despliegue por tipo nuevo.

B · LOS CAMPOS DEL EVENTO (el sobre) → GO

campo	qué es (dictado)	cómo se construye en Go 1.27	piezas de Go	decisión	estado
tags — las ONCE etiquetas	C · l · x · y · L · T · S · a · F · X · Y, cada una con su componedora; el grupo de la acción C · l · x · y primero y en orden	un array de arrays de texto; el ORDEN es firmable (el id cubre el array tal cual — medido por el auditor) ⇒ las etiquetas se componen en lista, en el orden del contrato	[][]string · orden = dato del contrato	—	derivado — sin decisión
pubkey	EL ACTOR (quién firma): la clave pública de su credencial en la bóveda	la clave vive en la bóveda; el nodo solo lleva la pública; cuando haya clave PQ, las dos se firman mutuamente en el registro de CO	crypto/mldsa (PQ) · btcec (Schnorr) dependencia de fuera	D6	decidido 2026-08-26 · D6: decidido 2026-08-26 · D6: ① con HPKE X-Wing · atestación ML-DSA-44 por lote en DOS eventos (3309 inmediato + 3318 con el OTS definitivo) · clave PQ en la bóveda con cross-firma · no composite/SLH-DSA/FN-DSA/determinista — texto completo en el índice (0)
created_at	el reloj DEL NODO EJECUTOR, leído una vez y congelado; el OTS ancla por lote	time.Now() una vez por evento; el lote: ley batch_attestation_is_two_events (D6) — 3309 inmediato con raíz + tree_size + ML-DSA-44 + OTS pendiente, 3318 con la prueba OTS definitiva; el testigo co-firma (D9)	time · x/mod/sumdb/tlog	D9	decidido 2026-08-26 · opción 1 con precisión del operador: decidido 2026-08-26 · opción 1 con precisión del operador: el archivo mantiene un registro Merkle (tlog, RFC 6962) de los id y publica raíces; CADA RAÍZ LA CO-FIRMA EL TESTIGO ANTES DE PUBLICARSE (sin co-firma no se publica; RFC 9162 §1: sin testigo el archivo es tercero de confianza); el testigo es el auditor GIT — hoy, en pruebas, firma el ContextVM de su nodo andamio; mañana el contexto testigo tendrá su nodo y cada co-firma será una instancia validada por su ContextVM; atomicidad; dos árboles distintos (el del archivo y el del lote); el simulacro verifica la consistencia; las actas del auditor entran en el mismo registro. Ley archive_transparency_log_and_witness
kind	la instrucción completa: paso del flujo + desenlace; SE LEE de los tipos de acción de campo ejecutados	un entero leído del contrato; jamás elegido; desde el 26 LOS 19 KINDS SON DATO (envelope.kind_catalogue: paso · papel · permanencia · clase de content · token del andamio) y kinds.go SE DERIVA de la tabla en 1.27; el ④ los lee de la FSM (16 reglas)	int — dato del contrato	d11	DICTADO (26, d11): los 19 kinds como dato y cada kind un token del andamio con su snapshot; cargas con el emisor nuevo (opción 1)
content	① cifrado hacia la clave del usuario-contexto destino · ② direcciones · ③ el documento con su output · ④ VACÍO	el ① se cifra con HPKE híbrido (X-Wing = ML-KEM-768 + X25519, ChaCha20-Poly1305): lo tenemos desde 1.26; el content lleva la clase que le asigna el kind (content_by_kind, dictado 26): ① cifrado (clase 26) · ④ vacío · 3309/3318 lote (clase 27) · ② ③ 33300 en la revisión final — llega con los campos del sobre	crypto/hpke · crypto/mlkem	D6	decidido 2026-08-26 · D6: decidido 2026-08-26 · D6: ① con HPKE X-Wing · atestación ML-DSA-44 por lote en DOS eventos (3309 inmediato + 3318 con el OTS definitivo) · clave PQ en la bóveda con cross-firma · no composite/SLH-DSA/FN-DSA/determinista — texto completo en el índice (0)
calcular_id	sha256 de la serialización canónica NIP-01: [0, pubkey, created_at, kind, tags, content]	serialización a mano (siete escapes; <>& y no-ASCII verbatim); medido por el auditor: 0 casos con <>& o controles en 1 646 eventos, los 1 646 ids recomputan; el contrato fija los controles 0x00–0x1F	crypto/sha256 · strconv dependencia de fuera (go-nostr hoy)	D2	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: los documentos se canonizan con RFC 8785 (JCS) puro, tal cual lo trae Go 1.27 (jsontext.Value.Canonicalize); los números grandes de negocio van como texto con su formato declarado (una clase valor campo); el id del evento sigue la regla de NIP-01 y el contrato fija los controles 0x00–0x1F como \u00XX
firmar_sig	LA BÓVEDA firma con la credencial del actor — EL SNAPSHOT: verify, jamás recompute	Schnorr/BIP-340 NO está en la biblioteca estándar: la firma de cada evento depende hoy de btcec (la desalineación real); la PQ (ML-DSA) sí está en 1.27 pero no cabe en sig: va en un evento de atestación. LA BÓVEDA TIENE INSTANCIAS (D8): casa · dispositivo (el enclave custodia la semilla; no calcula BIP-340 ni ML-DSA por hardware) · cold wallet (un solo nodo pide la firma a un dispositivo frío); lo que recibe cada firmador es DATO de su instancia (cold_signer_payload: event_id 32 B · external_mu 64 B — RFC 9881 App. D, depende de la pk; jamás HashML-DSA §5.4 · whole_event); ExternalMu firma sin ver el documento; open_hole (contrato): mldsa_ctx (valor de aarpia, con el primer 3309)	crypto/mldsa (stdlib, 1.27) dependencia de fuera (btcec para Schnorr)	D1 · D6	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: el snapshot es la FIRMA (sig); la referencia a un evento lleva el par id + sig (el id pide en el REQ, la firma verifica) — la ley vigente, confirmada decidido 2026-08-26 · D6: decidido 2026-08-26 · D6: ① con HPKE X-Wing · atestación ML-DSA-44 por lote en DOS eventos (3309 inmediato + 3318 con el OTS definitivo) · clave PQ en la bóveda con cross-firma · no composite/SLH-DSA/FN-DSA/determinista — texto completo en el índice (0)
el lote — 3309 · 3318	ley envelope.laws.batch_attestation_is_two_events (D6): un árbol Merkle sobre las firmas del lote, una raíz, dos sellos (OTS = cuándo · ML-DSA = quién responde); hojas = las S del 3309 (born_complete: nace con raíz, tamaño y el sitio del testigo); content object.batch_attestation.checkpoint_and_seals {root, tree_size, mldsa44_signature, ots_pending, witness_cosignatures} (clase 27; tres partes con clase pendiente del primer 3309); F sí, por el kind (F_tag); max_leaves 1000; margen a 1 000: 154 hojas de holgura; el 265 del relay externo es calculado, no medido	x/mod/sumdb/tlog (RFC 6962) para la raíz y las pruebas de inclusión O(log n); crypto/mldsa para la firma. EL TECHO, medido por el auditor (build/gates/cmd/techo_del_lote, bisección publicando y releyendo): con la S de 221 B y la cabecera de 6 949 B entran 1 149 hojas y no 1 150; el archivo DECLARA max_message_length 524 288 y APLICA maxEventSize 262 144 (factor 2); maxNumTags 2 000 no muerde hoy (1 160 etiquetas) y nadie lo declara por NIP-11	x/mod/sumdb/tlog · crypto/mldsa	D9 · techo	DICTADO (26, d10): 1 000 hojas por lote como dato del contrato (max_leaves); DICTADO (26, d10): 1 000 hojas por lote como dato del contrato (max_leaves); al llegar a 1 000 se cierra y empieza otro; techo medido por el auditor 1 149 (262 144 aplicado vs 524 288 declarado) escrito al lado con su método

La desalineación real, dicha:

La desalineación real, dicha: la firma con la que se firma cada evento (Schnorr, la que exige nostr) no está en la biblioteca estándar de Go — lo que decide si un evento es válido depende hoy de una librería de fuera. No es culpa de Go: es el precio del transporte. 1.27 lo alivia a medias (la PQ sí es de la casa).

C · LO QUE GO NO TRAE Y SE CUSTODIA COMO CÓDIGO (EaaC) — coherente con la línea roja 3

pieza	para qué	cómo	de dónde	decisión	estado
motor de reglas JSON Logic	ejecuta las reglas de cada acción de campo	evaluador propio sobre jsontext.Value (operador = único miembro; var por JSON Pointer; aritmética big.Rat), custodiado como token de código (BKM) en el nodo andamio	Go NO lo trae	D3	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: evaluador JSON Logic propio, escrito en Go y custodiado como token de código (BKM) en el nodo andamio — dentro del registro no por ser Go sino por estar custodiado y ser reproducible; las tablas se dicen «a la manera DMN 1.5», no «conformance DMN»
validador de facetas	comprueba las facetas de la tabla POR TIPO del contrato, leída como dato y sin lista dentro: string: pattern · enum [+ minLength · maxLength · format reservadas] · integer: minimum · maximum · array: minItems [+ maxItems · items reservadas] · object: required · boolean: —; type obligatoria = primitive_type; format siempre aserción	propio, pequeño: nuestras facetas son las de XSD/JSON Schema, pocas y nuestras	Go NO lo trae	D5	decidido 2026-08-26 · D5: decidido 2026-08-26 · D5: validador propio, lo escribe el auditor GIT; facetas admitidas POR TIPO como dato del contrato; format siempre aserción — texto completo en el índice (0)
ejecutor de Wasm	corre una función de negocio custodiada (.wasm por sha256) con determinismo: sin reloj ni azar del anfitrión	wazero (Apache-2.0, sin CGO) custodiado como especificacion_artefacto; GOOS=wasip1, //go:wasmexport, ~2 MB, monohilo	Go NO lo trae	D4	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: las funciones de negocio custodiadas se compilan a WebAssembly (GOOS=wasip1) — el .wasm es un blob por sha256 en el almacén, direccionado pinned desde la regla y ejecutado aislado (sin reloj, azar ni red del nodo); el ejecutor wazero (Go puro, sin CGO) se custodia como especificacion_artefacto; plugins de Go descartados · A (dictado 26): CADA EJECUCIÓN DE LA FUNCIÓN ES UNA INSTANCIA EN EL CONTEXTO DE LA FUNCIÓN — el ContextVM que llama entra como actor solicitante; el worker de ese contexto ejecuta el .wasm y su ③/④ registran el cómputo (worker por su clave, .wasm y ejecutor por hash, inputs por snapshot, memoria y duración); el que llama lee el snapshot y lo mete en su S. Ley function_execution_is_an_instance_of_its_context
el firmador frío (cold wallet)	firmar desde un dispositivo frío sin bóveda en el nodo (D8, opción del operador)	diseño PROPIO, declarado: un solo nodo pide la firma a un dispositivo frío por QR · USB · NFC; lo que recibe es dato de su instancia (whole_event para confirmar en pantalla; event_id/external_mu a ciegas); las normas nostr leídas de la fuente por el auditor NO son esto — NIP-46 es el firmador remoto por relay y CIFRA CON NIP-44 (descartado para el ①), NIP-55 es del mismo dispositivo por Intents y Android-only; las cold wallets de Bitcoin firman BIP-340, ninguna ML-DSA hoy	Go NO lo trae (se declara y se construye con el build)	D8	decidido 2026-08-26 · opción 3: lo que recibe el firmador es dato de cada instancia de bóveda
firma Schnorr / BIP-340	la firma que nostr exige en cada evento	btcec vía go-nostr — fuera de la stdlib; verificar cada evento depende de una librería de fuera	dependencia de fuera	—	hoy: sin alternativa (el transporte la exige)
firma postcuántica ML-DSA	la atestación por lote y las claves PQ de los actores	crypto/mldsa (FIPS 204): semilla de 32 bytes; ExternalMu-ML-DSA (RFC 9881 App. D: μ externo de 64 B, firmas indistinguibles del ML-DSA puro; jamás HashML-DSA §5.4, prohibido por RFC 9881 §8.3); la variante determinista NO es otro algoritmo — el mismo Sign con rnd = {0}^32 (FIPS 204 l. 1229–1230): idempotente para la bóveda, ningún método nuevo (una firma es siempre verify; d9), no en producción (§3.4 la CONDICIONA: canal lateral mitigado; verificado l. 926/939–943); la stdlib expande la matriz A por Verify (2,1× con clave repetida): si el ratio importa, filippo.io/mldsa o CIRCL custodiados	stdlib 1.27	D6	decidido 2026-08-26 · D6: decidido 2026-08-26 · D6: ① con HPKE X-Wing · atestación ML-DSA-44 por lote en DOS eventos (3309 inmediato + 3318 con el OTS definitivo) · clave PQ en la bóveda con cross-firma · no composite/SLH-DSA/FN-DSA/determinista — texto completo en el índice (0)
log Merkle (tlog)	demostrar que el archivo solo crece; el lote del 3309 como árbol	golang.org/x/mod/sumdb/tlog (RFC 6962, sha256 de 32 bytes = nuestro id); el testigo co-firma (c2sp tlog-witness v1.0.0)	x/mod (del propio proyecto Go)	D9	decidido 2026-08-26 · opción 1 con precisión del operador: decidido 2026-08-26 · opción 1 con precisión del operador: el archivo mantiene un registro Merkle (tlog, RFC 6962) de los id y publica raíces; CADA RAÍZ LA CO-FIRMA EL TESTIGO ANTES DE PUBLICARSE (sin co-firma no se publica; RFC 9162 §1: sin testigo el archivo es tercero de confianza); el testigo es el auditor GIT — hoy, en pruebas, firma el ContextVM de su nodo andamio; mañana el contexto testigo tendrá su nodo y cada co-firma será una instancia validada por su ContextVM; atomicidad; dos árboles distintos (el del archivo y el del lote); el simulacro verifica la consistencia; las actas del auditor entran en el mismo registro. Ley archive_transparency_log_and_witness
MCP (el agente descubre las herramientas)	cada nodo expone sus manifiestos como skills — LA SKILL ES EL MISMO MANIFIESTO (the_manifest); el esquema de cada tool SE DERIVA DEL MANIFIESTO, jamás del código Go; MCP ofrece, el ① es, el contrato decide (agent_door_is_mcp_from_the_manifest); el ② lo compone mañana el agente IA del nodo	SDK oficial de Go v1.7.0; Tool.InputSchema explícito derivado del contrato (JSON Schema 2020-12); orden determinista; sin adoptar «Skills over MCP» (SEP-2640, en revisión); lo que el agente hace lo registra su ② y su telemetría, no MCP	dependencia de fuera (SDK oficial)	D10	decidido 2026-08-26 · opción 1: decidido 2026-08-26 · opción 1: la puerta del agente IA es MCP (stateless, discover, orden determinista); cada nodo expone sus manifiestos como herramientas y el esquema de cada una SE DERIVA DEL MANIFIESTO, jamás del código Go; lo en revisión en MCP no se adopta; MCP ofrece, el evento ① es, el contrato decide. Y con él: EL MANIFIESTO como dato (ley the_manifest), LA a EN EL ① (una por manifiesto solicitado, alias vacío) y EL ALINEAMIENTO COMPLETO por el tipo de acción de campo y su DMN (ley the_complete_alignment, a repasar con el auditor)

D · LA especificacion_artefacto DEL NODO (el build) → GO 1.27

ingrediente	valor propuesto	decisión	estado
imagen base	FROM golang:1.27.0-alpine (hoy: 1.26.6-alpine en seis nodos — el relay va en golang:1.25-alpine; 1.27.0 es el parche más nuevo)	D7	decidido 2026-08-26 · opción 1, YA: decidido 2026-08-26 · opción 1, YA: el build nuevo nace en Go 1.27 — golang:1.27.0-alpine, go 1.27 + toolchain go1.27.0, GOTOOLCHAIN=local en CI; las tres vigilancias de huellas; el contexto del framework de clases se crea en 1.27 con todo lo decidido (dictado: hasta cerrar todas las decisiones y crear el contexto de las clases no hay clases ni se construye — ahora se define todo)
go.mod	go 1.27 + toolchain go1.27.0; GOTOOLCHAIN=local en CI; go test invoca stdversion (gate gratis)	D7	decidido 2026-08-26 · opción 1, YA: decidido 2026-08-26 · opción 1, YA: el build nuevo nace en Go 1.27 — golang:1.27.0-alpine, go 1.27 + toolchain go1.27.0, GOTOOLCHAIN=local en CI; las tres vigilancias de huellas; el contexto del framework de clases se crea en 1.27 con todo lo decidido (dictado: hasta cerrar todas las decisiones y crear el contexto de las clases no hay clases ni se construye — ahora se define todo)
destino	GOOS=linux GOARCH=amd64 (los contenedores de Docker Desktop: linux/amd64) · CGO_ENABLED=0	D7	decidido 2026-08-26 · opción 1, YA: decidido 2026-08-26 · opción 1, YA: el build nuevo nace en Go 1.27 — golang:1.27.0-alpine, go 1.27 + toolchain go1.27.0, GOTOOLCHAIN=local en CI; las tres vigilancias de huellas; el contexto del framework de clases se crea en 1.27 con todo lo decidido (dictado: hasta cerrar todas las decisiones y crear el contexto de las clases no hay clases ni se construye — ahora se define todo)
ingredientes estampados	GOFIPS140 · DefaultGODEBUG · GOEXPERIMENT (el único que NO queda grabado: se fija en la especificación) — todos leídos con go version -m -json	D7	decidido 2026-08-26 · opción 1, YA: decidido 2026-08-26 · opción 1, YA: el build nuevo nace en Go 1.27 — golang:1.27.0-alpine, go 1.27 + toolchain go1.27.0, GOTOOLCHAIN=local en CI; las tres vigilancias de huellas; el contexto del framework de clases se crea en 1.27 con todo lo decidido (dictado: hasta cerrar todas las decisiones y crear el contexto de las clases no hay clases ni se construye — ahora se define todo)
la imagen como dato	manifest OCI (mediaType + digest sha256 + size) en un evento; capas al almacén de blobs por sha256 (un solo hash por capa, declarado cuál); atestación in-toto/SLSA en DSSE	D8	decidido 2026-08-26 · opción 1 con dos precisiones del operador: decidido 2026-08-26 · opción 1 con dos precisiones del operador: (1) UNA imagen estándar del ContextVM por plataforma (el contexto es dato que el nodo carga por hash; manifiesto OCI en evento, capas/binario en blobs por sha256, atestación in-toto/SLSA); (2) el contexto viaja —a un móvil con su nodo— y habla por su canal; LA FIRMA: la bóveda tiene instancias — de casa, en el dispositivo (enclave custodia la semilla), o COLD WALLET (un solo nodo pide la firma a un dispositivo frío: id/μ, jamás el documento). Ley the_node_image_and_the_vault_instances en clase_contexto · LO QUE RECIBE EL FIRMADOR es dato de cada instancia de bóveda (opción 3): hash (id/μ: nada del negocio sale; bóveda de casa o enclave) o evento entero (la cold wallet con pantalla lo muestra y un humano confirma, como NIP-46/55 y las cold wallets de Bitcoin); NIP-46 (cifra con NIP-44, por relay) y NIP-55 (mismo dispositivo, Android) no son nuestra cold wallet: diseño propio, declarado
prohibiciones que cambian huellas en 1.27	jamás hashear bytes comprimidos (compress/flate cambia su salida) · jamás hashear el marshal de un struct · nada que dependa de tablas Unicode (15 → 17) en una identidad · ningún gate compara textos de error JSON	—	derivado — sin decisión

E · LAS LEYES DICTADAS EL 26 → SU PIEZA DE GO (el inventario entero: 33 nodos con dictado del 26 u open_hole, leídos del contrato)

ley / dato	ruta en el contrato	qué dice, en una frase	pieza de Go 1.27 que la ejecuta	estado (leído del contrato)
function_execution_is_an_instance_of_its_context	clase_accion_campo/definitions/law_inside/function_execution_is_an_instance_of_its_context	cada ejecución de una función custodiada es una instancia en el contexto de infra que ejecuta (el que llama entra como actor; dos contextos: construir · ejecutar); body = el .wasm	wazero custodiado (D4) · el flujo de dos ContextVM	dictado 2026-08-26
the_manifest	clase_accion_campo/definitions/law_inside/the_manifest	qué es el manifiesto: el tipo de acción de campo publicado (33300 por su d); direcciones, jamás valores; tres papeles de un dato; tres manifiestos	encoding/json/v2 (lectura estricta) · SDK MCP (la skill) · el evento por go-nostr	dictado 2026-08-26
agent_door_is_mcp_from_the_manifest	clase_accion_campo/definitions/law_inside/agent_door_is_mcp_from_the_manifest	D10: la puerta del agente es MCP; el esquema de cada tool se deriva del manifiesto, jamás del código	SDK oficial MCP (Tool.InputSchema desde el manifiesto)	dictado 2026-08-26
the_complete_alignment	clase_accion_campo/definitions/law_inside/the_complete_alignment	el tipo de acción de campo como punto de cruce; la DMN donde se mide; tres comprobaciones milimétricas; medido con el auditor (a · b · c)	todas las piezas: evaluador · validador · wazero · Canonicalize · sha256	dictado 2026-08-26
worker_address	clase_accion_campo/definitions/law_inside/the_complete_alignment/open_holes/worker_address	el worker como dirección del manifiesto: solo prosa (11 veces) — a dictar	—	open_hole (contrato): decide el operador
execution_governance	clase_accion_campo/definitions/law_inside/the_complete_alignment/open_holes/execution_governance	el permiso del CO para EJECUTAR el tipo: solo prosa (16 veces); editar sí tiene dato — a dictar	—	open_hole (contrato): decide el operador
field_actions_in_the_event	clase_accion_evento/definitions/law_inside/field_actions_in_the_event	una etiqueta a por cada manifiesto ejecutado en el ④	[][]string en el orden del contrato	dictado 2026-08-26
process_classes_by_token_type	clase_accion_evento/definitions/law_inside/process_classes_by_token_type	la clase de proceso es <proceso><tipo de token>: 7 clases · 16 DMN · 8 filas; el parte solo initial e intermedio	interpretación de decisions[fsm] (16 reglas)	dictado 2026-08-26
non_flow_kinds	clase_accion_evento/definitions/envelope/tags/6/non_flow_kinds	el 3309, el 3318 y el 33300 llevan F; qué F lo dice el kind; valor al final	dato	dictado 2026-08-26
cardinality_is_data	clase_accion_evento/definitions/envelope/laws/cardinality_is_data	la cardinalidad de cada etiqueta es un dato (one · one_per_consumed · one_per_executed_field_action)	[][]string	dictado 2026-08-26
positions_have_their_epoch	clase_accion_evento/definitions/envelope/laws/positions_have_their_epoch	cada posición lleva su in_force_from y su history: un evento se juzga contra la forma de su época	dato por posición	dictado 2026-08-26
four_fundamental_data	clase_accion_evento/definitions/envelope/laws/four_fundamental_data	contexto · proceso · instancia de contexto · instancia de proceso: x · y · X · Y	componedoras 7–10 (evaluador)	dictado 2026-08-26
the_action_group	clase_accion_evento/definitions/envelope/laws/the_action_group	C · l · x · y juntos y en orden; el orden es firmable	[][]string (el id cubre el array)	dictado 2026-08-26
geneses_are_distinct	clase_accion_evento/definitions/envelope/laws/geneses_are_distinct	l① · X① · Y① son tres valores distintos en un evento	comparación de bytes	dictado 2026-08-26
canonical_form_of_documents	clase_accion_evento/definitions/envelope/laws/canonical_form_of_documents	D2: los documentos en RFC 8785 puro; enteros grandes como texto con formato	encoding/json/jsontext Value.Canonicalize	dictado 2026-08-26
control_characters_in_id_serialization	clase_accion_evento/definitions/envelope/laws/control_characters_in_id_serialization	D2: los controles 0x00–0x1F del id como \u00XX (medido: 0 casos en 1 646, ids recomputan)	serialización a mano (strconv; go-nostr hoy) · crypto/sha256	dictado 2026-08-26
batch_attestation_is_two_events	clase_accion_evento/definitions/envelope/laws/batch_attestation_is_two_events	D6: 3309 inmediato (raíz + tamaño + ML-DSA-44 + OTS pendiente + testigo) y 3318 con la prueba OTS; max_leaves 1000; techo 1 149; margen; F sí	golang.org/x/mod/sumdb/tlog · crypto/mldsa	dictado 2026-08-26
T_pairs_with_l	clase_accion_evento/definitions/envelope/laws/T_pairs_with_l	la T como la l: génesis del tipo · instancia del catálogo live · alias del nivel estándar	componer_etiqueta_T (evaluador JSON Logic)	dictado 2026-08-26
request_envelope	clase_accion_evento/definitions/envelope/laws/request_envelope	el ①: grupo C·l·x·y + F + S + una a por manifiesto; alias vacío; canal por #C + #x, jamás por clave; la p deuda a eliminar	crypto/hpke (X-Wing) para el content · go-nostr para el evento	dictado 2026-08-26
agent_request_telemetry	clase_accion_evento/definitions/envelope/laws/agent_request_telemetry	la telemetría del ② son campos de su documento, firmados por quien gastó	dato (clases con la del ②)	dictado 2026-08-26
archive_transparency_log_and_witness	clase_accion_evento/definitions/envelope/laws/archive_transparency_log_and_witness	D9: tlog del archivo + testigo = el auditor (hoy su nodo andamio); 7 MUST; atomicidad; dos árboles; simulacro; actas	x/mod/sumdb/tlog · c2sp tlog-witness (estado persistente del testigo)	dictado 2026-08-26
independence_of_custody	clase_accion_evento/definitions/envelope/laws/archive_transparency_log_and_witness/independence_of_custody	archivo y testigo como dos usuarios de la misma bóveda: ¿basta? — antes del primer checkpoint	—	open_hole (contrato): decide el operador
content_by_kind	clase_accion_evento/definitions/envelope/content_by_kind	la clase del content la dice el kind: ① clase 26 · ④ vacío · lote clase 27 · ② ③ 33300 pendientes	encoding/json/v2 por clase	dictado 2026-08-26
kind_catalogue	clase_accion_evento/definitions/envelope/kind_catalogue	los 19 kinds como dato, cada uno un token del andamio; kinds.go derivado; cargas con el emisor nuevo	kinds.go generado desde la tabla (D7)	dictado 2026-08-26
open_hole_the_classes_do_not_declare_their_processes	clase_contexto/definitions/law_inside/open_hole_the_classes_do_not_declare_their_processes	(anterior al 26) las clases no declaran sus procesos	—	open_hole (contrato): decide el operador
the_node_image_and_the_vault_instances	clase_contexto/definitions/law_inside/the_node_image_and_the_vault_instances	D8: una imagen estándar del ContextVM por plataforma; el contexto como dato; el contexto viaja; la bóveda con instancias (casa · dispositivo · cold wallet)	OCI + in-toto/SLSA · runtime/secret · crypto/mldsa (ExternalMu)	dictado 2026-08-26
cold_signer_payload	clase_contexto/definitions/law_inside/the_node_image_and_the_vault_instances/cold_signer_payload	lo que recibe un firmador es dato de su instancia: event_id · external_mu · whole_event	crypto/sha256 (id) · crypto/mldsa (μ externo)	dictado 2026-08-26
mldsa_ctx	clase_contexto/definitions/law_inside/the_node_image_and_the_vault_instances/mldsa_ctx	el ctx de ML-DSA sin valor declarado (≤ 255 B, vacío por defecto — verificado)	crypto/mldsa Options.Context	open_hole (contrato): decide el operador
derived_from	clase_objeto_valor/definitions/catalog/derived_from	d12: el catálogo se llena con los 12 contextos que las componedoras leen, derivado; frontera origen/clase	script de derivación (regenerable)	derivado
admitted_facets_by_primitive_type	clase_valor_campo/definitions/law_inside/admitted_facets_by_primitive_type	D5: las facetas admitidas POR TIPO como dato; faceta fuera de la tabla = rojo	validador del auditor (regexp RE2 · math/big), sin lista dentro	dictado 2026-08-26
canonical_form_is_the_format	clase_valor_campo/definitions/law_inside/canonical_form_is_the_format	d6: la forma canónica es el formato de la clase (serialization rfc8785 en las object/array)	jsontext.Value.Canonicalize por clase	dictado 2026-08-26
hash_is_of_the_stored_bytes	clase_valor_campo/definitions/law_inside/hash_is_of_the_stored_bytes	d6/d7: la huella es siempre de los bytes guardados; se canoniza al escribir, jamás al verificar	crypto/sha256 sobre los bytes guardados	dictado 2026-08-26
wire_format	clase_valor_campo/definitions/catalog/entries/25/wire_format	el formato de cable del cifrado del ① (enc \|\| ct) es decisión de aarpia — con el primer ①	crypto/hpke	open_hole (contrato): decide el operador

Este es el cierre de la documentación:

Este es el cierre de la documentación: cada ley del 26 con su sitio en el contrato y la pieza de Go que la ejecutará. Los open_hole son huecos que el contrato declara con quién los decide — no faltas del HTML. Y lo que aún no se puede medir (las tres comprobaciones del alineamiento) queda dicho como estado futuro.

Lo que Go da por diseño y aarpia exige:

Lo que Go da por diseño y aarpia exige: reproducible (mismo código → mismo binario byte a byte, con la ficha de fabricación grabada: debug/buildinfo) · direccionado por hash (sus módulos, en un log de transparencia) · sin dependencias ocultas en lo que decide (sha256, HPKE, ML-DSA en la stdlib). Es la resurrección hecha norma del lenguaje.

1 · EL CONTRATO — el DRD leído de las seis clases

ARQUITECTO DE CONTEXTOS — un tipo de contexto, proceso a proceso

EL BPMN DE LA INSTANCIA — BPMN 2.0, dibujado desde lo declarado y las filas de la FSM

`type.<alias>.json` — la piedra angular, construida hasta aquí

EL DRD DEL CONTRATO — las decisiones de las seis clases, cada DMN pintada del contrato

4 · LOS CANÓNICOS — contra los que se prueba

el contexto

INSTRUCCIONES — qué es cada vista y de dónde sale lo que pinta

La prosa que antes encabezaba cada vista vive aquí, entera. Cada bloque enlaza con su vista; lo que las vistas pintan desde el contrato o el relay conserva sus propias notas, plegadas, junto al dato que explican.

LA CONSOLA · aarpia VOE · sandbox mortal

La interfaz del framework en el sandbox: aarpia.framework.tipo_contexto.declarado · v12 · panel lateral. En el panel de la izquierda solo queda el logotipo; esto se lee aquí y en «acerca de», dentro del menú de tu sesión.

LA ENTRADA — quién firma, en nombre de quién, y con qué wallet

En el panel de la izquierda: arriba, en nombre de qué Context Owner (la tarjeta con su avatar y su C); abajo, quién solicita — el actor que firma el ①, con el botón entrar con la wallet aarpia VOE y, al pulsar la tarjeta, el menú tu sesión: la wallet, la conexión (el relay del sandbox), dónde publica la wallet, la apariencia (claro u oscuro), «acerca de» y estas instrucciones.

SIN WALLET: no se puede firmar. Sin wallet no se firma: publicar un sobre con una firma inventada llenaría el relay de eventos que NO son eventos, y este banco de pruebas existe para lo contrario. Y sin wallet no se ofrece «crear instancia», porque no se podría firmar: esto NO es esconder una acción —que es lo que el server side prohíbe—; es que falta la IDENTIDAD con la que se pide, no un permiso que el nodo tenga que decidir. Quien pide sin poder firmar no está pidiendo.

Con wallet: firma tu actor · tu clave · NIP-07. La firma la da NIP-07: la página → window.nostr → la wallet → su nodo → la bóveda. La privada JAMÁS sale. Y gobernanza resuelve quién eres a partir de esa clave.

La C del Context Owner: su alias, su pinned y su live vienen del nodo, no inventada; si está sin resolver, se dice el porqué (esperando /frontera). El relay del sandbox, conectado o cerrado, y las instancias reconstruidas de sus eventos, con la hora — lo que ves es lo que hay en el relay.

La wallet te ofrece sus relays; si están acotados a este origen, la entrada va a esos y solo a esos — y es una BARANDILLA, no un muro: NIP-07 solo firma, así que quien publica es esta página. La frontera del sandbox la sostiene su código, no la wallet — se dice porque creerse protegido es peor que no estarlo. Si es la flota general, SIN acotar a este origen, también se dice.

0 · EL CATÁLOGO DE CLASES — la documentación viva → ir a la vista

Las clases valor campo (el formato) y objeto valor (el origen), la guía de las once etiquetas con sus CEIPs, los cuatro mensajes ① ② ③ ④ y el mapa a Go — tal cual está en su documento, incrustado aquí y conectado con el resto: cada clase y cada etiqueta de la vista 1 enlaza a su fila, y desde cada fila ↩ vuelve a la vista 1, donde la misma cosa se lee del JSON. → 1 · EL CONTRATO

fuente: agente-contextvm/clases-catalogo.html — cómo se incrusta y qué se cuenta

fuente agente-contextvm/clases-catalogo.html (2026-08-26 18:07 · 232 KB), leída por construir_consola.py en cada construcción — actualizar el catálogo actualiza la consola · 8 pestañas incrustadas · 165 filas con id (115 clases · 11 etiquetas · 6 campos NIP-01 · 33 leyes) · 52 anclas de vuelta a la vista 1 · enlazables desde la vista 1: 29 clases valor campo · 12 clases objeto valor · 11 etiquetas · 73 nombres de ley · 2 «<» de texto escapados

1 · EL CONTRATO — el DRD leído de las seis clases → ir a la vista

Lo que sale solo del contrato, sin declarar nada. Cada bloque dice de qué ruta del contrato sale. Arriba el DRD (DMN 1.5 §6: Decision · Input Data · Business Knowledge Model · Knowledge Source, y sus tres requerimientos informationRequirement · knowledgeRequirement · authorityRequirement); después la cima, la Decision fsm; las 16 DecisionTable de las acciones de evento; el BPMN de la clase; el sobre; los catálogos; y las once componedoras — en cada InputClause su clase objeto valor (origen · resolución) y su clase valor campo (formato); en cada OutputClause solo la clase valor campo (la línea roja 4, visible).

ARQUITECTO DE CONTEXTOS — un tipo de contexto, proceso a proceso → ir a la vista

El arquitecto de contextos — la página del contexto aarpia.framework.tipo_contexto.declarado, donde se construye cada tipo de contexto declarado (mote dictado por el operador el 30-ago; antes «declarador»). Las preguntas salen de los contratos (clase_contexto.vigente → clase_proceso.vigente → clase_accion_evento.vigente), que la página lee del nodo en /contrato/…. Identidad (el alias de cuatro procedencias: dominio · subdominio · token · estado deseable) → los procesos por fase → los tipos resueltos contra la FSM (decisions[fsm], hitPolicy UNIQUE, exactamente un hit, con el motor JSON Logic) → las constraints del contrato → el BPMN de la instancia → el definitions → guardar/cargar la declaración como 33300 en el relay del sandbox. Nada se teclea dos veces.

las seis clases · los JSON tal como los sirve el nodo — Los definitions del contrato aarpia VOE, tal como los sirve el nodo en /contrato/… — es lo que el formulario y el arnés leen. Cada uno apunta al que lo contiene y al que contiene (definitions.containment). Se leen en FRAMEWORK › el contrato de las seis clases y en el nodo (/contrato/aarpia.framework.clase_*.vigente.json); esa pestaña salió del panel del arquitecto el 30-ago por ruido (dictado del operador).

EL BPMN DE LA INSTANCIA — startEvent · endEvent · exclusiveGateway · parallelGateway · inclusiveGateway · complexGateway (k de n) · eventBasedGateway · sequenceFlow — los split_gateway y join_gateway de decisions[fsm], resueltos por proceso declarado

type.<alias>.json — la piedra angular, construida hasta aquí — crearDefinitions() · name · namespace · itemDefinitions · decisions · knowledgeSources — el contrato estructural de lo declarado

3 · INSTANCIAS — los registros y los cuatro mensajes por dentro → ir a la vista

Cada instancia de contexto con sus instancias de proceso, su fase, su estado y sus eventos — reconstruidas del relay del sandbox por REQ #C. Cada evento abierto según NIP-01 (id · pubkey · created_at · kind · tags · content · sig): las etiquetas del sobre con sus posiciones y sus clases (snapshot_pinned · snapshot_live · alias), la S (lo consumido), la a (los manifiestos), el content por kind — y la auditoría por evento: qué DecisionTable rigió, qué regla hizo hit, con qué inputs y sus snapshots. Los cuatro mensajes con su actor: ① quien pide · ② el ContextVM (mañana el agente) · ③ el worker · ④ el ContextVM que valida y sella.

LOS PROCESOS DE ESTA INSTANCIA — la máquina del arquitecto de contextos. El create de cada proceso viene del estado deseable del anterior: por eso el «estado actual» del DMN es siempre el que otro evento validó antes. Y las acciones que se ofrecen salen de lo declarado — la interfaz ofrece, el ContextVM valida y contesta con su kind. SNAPSHOT VIGENTE — el sig del último ④ validado, venga del proceso que venga. GÉNESIS — nació en el create del initial (regla de alta: random con forma de sig).

LAS PÁGINAS DEL CONTEXTO (desde la barra de la página o desde las partes del panel; una a la vez): EL GRAFO — el BPMN de la FSM de este contexto (decisions[fsm] → pares · listens_to · triggers · seals · split_gateway · join_gateway (bpmnDeLaClase)) · DMN DE ACCIÓN DE EVENTO — las Decision create_* / transition_* de sus procesos (decisions[create_* | transition_*] · process_class · field_action_slots · decisionTable) · DMN DE ACCIÓN DE CAMPO — sus tipos de acción de campo y sus reglas (aquí se ponen): una tabla con los tipos declarados por este contexto — sus reglas, tal como están hoy (stubs: se dice, no se maquilla) — y debajo las 11 componedoras canónicas del contrato con su DecisionTable (clase_accion_campo · canonical_field_action_types (las canónicas) · contract.contextvm (las declaradas)) · LA DEFINICIÓN — lo que este contexto declara: su type y sus diez canónicos (CANONICOS[i] · conModelo(raíz)) · LOS MANIFIESTOS — los 33300 firmados por el ContextVM de ese contexto: el del contexto (con su identidad y sus procesos) y uno por cada tipo de acción de campo; de ahí leen el agente IA y el ContextVM: cada tipo es un manifiesto con sus reglas, y cada `a` de un evento apunta a uno de ellos (kind 33300 · d · pubkey · content). Sin wallet no se ofrece «crear instancia»: entrar vive en el panel, en la tarjeta del actor.

TIPOS DE CONTEXTO DECLARADOS — las instancias de aarpia.framework.tipo_contexto.declarado. Cada instancia de este contexto ES un tipo de contexto declarado, y la primera es él mismo: se fabrica a sí mismo. Declarar un contexto no es escribir configuración: es crear una instancia y caminar sus procesos — la identidad, la máquina, el payload y los diez canónicos se rellenan cada uno en su proceso. La tabla dice, por instancia: qué declara, su Context Owner, su snapshot vigente, cuántos procesos y eventos tiene, su fase y su estado, y las acciones que su contexto declara desde ese estado (una acción se nombra por su estado deseable).

4 · LOS CANÓNICOS — contra los que se prueba → ir a la vista

Los diez archivos canónicos del contexto elegido, por rama de actor (dictado 30/31-ago; P4.2). No son documentación: SON el contexto. La piedra angular es type — la identidad y el primer determinismo, recalculada y que nadie edita —; el segundo determinismo va en los tres contract.<actor>. Cada uno con su sha256 sobre la forma canónica RFC 8785 (JCS) del JSON generado, descargable; su clase valor campo en el contrato está pendiente (envelope.content_by_kind[33300]: pending) y la publicación al sandbox llega en el paso 3.

CANONICOS[i][1]() · conModelo(instancia.declarado) — generado desde la declaración cargada · gates del auditor: hoy solo la identidad, parte de type

LA NORMA — a la manera de qué está hecho todo esto

a la manera de DMN 1.5 y BPMN 2.0, con JSON Logic en vez de FEEL — no conformance · el sobre según NIP-01 (id · pubkey · created_at · kind · tags · content · sig; REQ · EVENT · OK · EOSE) · la verdad es el contrato que sirve el nodo en /contrato/*.json: la página no lleva copia de nada

0 · EL CATÁLOGO DE CLASES — la documentación viva

LAS CLASES — valor campo (el formato) · objeto valor (el origen, content-addressed)

EL CATÁLOGO VIGENTE — 29 clases (24 dictadas el 2026-08-25; 4 más el 26 por dictado: el cifrado del ①, el documento del lote, el fuente custodiado y la referencia a blob; la 25.ª, string.genesis.random_hex128, el 26) · los outputs SON la clase valor campo

LAS LEYES DE LA CLASE VALOR CAMPO — dictadas el 26 (clase_valor_campo.law_inside)

LAS PROPIEDADES DE LA FORMA — con todas sus variables, la estandarización, su evidencia y ejemplos

EL CATÁLOGO VIGENTE — LAS CLASES SON LOS CONTEXTOS (dictado 2026-08-25; las 14 genéricas, derogadas) · 12 orígenes leídos del contrato (las once componedoras y las once etiquetas) — regenerado 2026-08-26

LAS PROPIEDADES DE LA FORMA — con todas sus variables, la estandarización, su evidencia y ejemplos

★ LA GUÍA — LAS ETIQUETAS: acciones de campo con sus clases objeto valor y valor campo, relacionadas con sus CEIPs

LOS DIEZ CEIPs — el estado de la revisión (el detalle, en revision-ceips.html)

LAS LEYES DICTADAS EL 26 — dónde viven y qué dicen (el inventario entero: 33 nodos del contrato con dictado del 26 u open_hole)

LAS DECISIONES DEL CAMINO QUE NO SON ETIQUETAS

① trigger_event_action ⬡ 91139c5436c3… — acción EVENTO · el actor usuario por su interfaz

② agent_request ⬡ 19d4396d446f… — acción CAMPO · el agente IA, campo a campo

③ field_action_execution ⬡ e3f5b4e635f0… — acción CAMPO · un worker por ③ — y el ③ lleva n campos de negocio (paso 5)

④ event_action_validation ⬡ 723fde7f2244… — acción EVENTO · el ContextVM notario sella

EL CONTRATO aarpia VOE MAPEADO A GO 1.27 — DESDE LAS CLASES DE aarpia, nunca al revés · abierta el 2026-08-26 · se rellena a medida que el operador decide

0 · LAS ONCE DECISIONES — 11 decididas · 0 esperan (cerradas el 26) — el índice de esta pestaña

A · LAS SEIS CLASES DEL CONTRATO → CÓMO SE CONSTRUYEN EN GO

B · LOS CAMPOS DEL EVENTO (el sobre) → GO

C · LO QUE GO NO TRAE Y SE CUSTODIA COMO CÓDIGO (EaaC) — coherente con la línea roja 3

D · LA especificacion_artefacto DEL NODO (el build) → GO 1.27

E · LAS LEYES DICTADAS EL 26 → SU PIEZA DE GO (el inventario entero: 33 nodos con dictado del 26 u open_hole, leídos del contrato)

1 · EL CONTRATO — el DRD leído de las seis clases

ARQUITECTO DE CONTEXTOS — un tipo de contexto, proceso a proceso

EL BPMN DE LA INSTANCIA — BPMN 2.0, dibujado desde lo declarado y las filas de la FSM

type.<alias>.json — la piedra angular, construida hasta aquí

EL DRD DEL CONTRATO — las decisiones de las seis clases, cada DMN pintada del contrato

4 · LOS CANÓNICOS — contra los que se prueba

INSTRUCCIONES — qué es cada vista y de dónde sale lo que pinta

LA CONSOLA · aarpia VOE · sandbox mortal

LA ENTRADA — quién firma, en nombre de quién, y con qué wallet

0 · EL CATÁLOGO DE CLASES — la documentación viva → ir a la vista

1 · EL CONTRATO — el DRD leído de las seis clases → ir a la vista

ARQUITECTO DE CONTEXTOS — un tipo de contexto, proceso a proceso → ir a la vista

3 · INSTANCIAS — los registros y los cuatro mensajes por dentro → ir a la vista

4 · LOS CANÓNICOS — contra los que se prueba → ir a la vista

LA NORMA — a la manera de qué está hecho todo esto

`type.<alias>.json` — la piedra angular, construida hasta aquí