A202 MCP Server

A202: el Protocolo de Acuerdo Verificable para el Comercio Dirigido por Agentes

Estado: Informativo en su totalidad.

A202 es comercio verificable para transacciones de agente a agente o dirigidas por agentes: una especificación abierta de autoridad comercial, estado de negociación y conformidad verificable para transacciones entre organizaciones independientes, incluidas las transacciones realizadas en su nombre por agentes de software.

Define objetos tipados para la autoridad comercial delegada, una máquina de estados para la transacción y para cada sesión bilateral dentro de ella, reglas sobre qué puede revelarse a quién, y una suite de conformidad ejecutable que convierte cada uno de esos elementos en una verificación que una implementación pasa o falla.

La declaración completa de propósito, alcance y no-objetivos está en CHARTER.md.

Creado y desarrollado por A. A. Musse. Ver MAINTAINERS.md.

Estado

Publicado, pre-1.0.

• v0.1.0 es la primera versión etiquetada del conjunto: una etiqueta, un digest para cada archivo de esquema, el manifiesto de conformidad y las notas de versión, publicados juntos. Ver RELEASES.md y CHANGELOG.md. Antes de 1.0, un incremento MINOR puede romper la compatibilidad, y cualquier ruptura incluye notas de migración.
• El nombre es A202, pronunciado "A dos-cero-dos", y en su forma completa A202, el Protocolo de Acuerdo Verificable para el Comercio Dirigido por Agentes. La forma larga es un descriptor y no una expansión: las letras no lo representan. El 202 es HTTP 202 Accepted, que A202-0017 convierte en el estado que devuelve un envío aceptado, porque la aceptación es el primitivo sobre el que se construye el resto de la especificación. El prefijo de código de razón A202-, los identificadores de propuesta A202-NNNN y la cadena de versión de especificación a202-commercial/0.1 se derivan del nombre.
• A202™ es una marca comercial de Plural Worlds. El uso permitido del nombre se indica en TRADEMARK.md.
• Los valores de esquema $id se resuelven bajo https://schemas.a202.org. Los hosts de fixtures usan nombres reservados .invalid, porque los datos de prueba nunca deben resolverse.
• Licenciado bajo la Apache License, Versión 2.0. Una sola licencia cubre todo el repositorio: texto de especificación, esquemas, fixtures, manifiesto, ejecutor y documentos informativos. La licencia incluye una concesión expresa de patentes de cada contribuyente. Ver LICENSE y CONTRIBUTING.md.
• Las contribuciones externas se aceptan según los términos de CONTRIBUTING.md: contribuciones entrantes bajo la misma licencia, con una firma de certificado de origen de desarrollador.

Estructura

Ruta	Contenido
CHARTER.md	Propósito, alcance, no-objetivos, principios de diseño
GOVERNANCE.md	Cómo se gestiona el proyecto y qué controla y qué no controla el patrocinador
MAINTAINERS.md	Quién mantiene este repositorio
CONTRIBUTING.md	Estado de contribución y los términos bajo los que se acepta una contribución
SECURITY.md	Divulgación coordinada privada
THREAT-MODEL.md	Adversarios asumidos, propiedades defendidas y qué no se defiende deliberadamente
CODE_OF_CONDUCT.md	Conducta esperada
TRADEMARK.md	El nombre A202 y qué uso de él está y no está permitido
RELEASES.md	Versionado, en qué consiste una versión, política de compatibilidad
CHANGELOG.md	Qué cambió y dónde se acumulan las notas de versión requeridas por RELEASES.md
.github/	Enrutamiento de revisión, los formularios de pull request e issue, y el flujo de trabajo que ejecuta la suite en cada cambio
proposals/	El proceso de propuesta de cambio A202
schemas/	Modelo comercial canónico, modelo de extensión de perfil de transacción y los esquemas JSON
authority/	Mandato comercial: autoridad delegada, restricciones, delegación, aprobación, revocación
discovery/	Invitación de contraparte: cómo una parte no registrada entra en una transacción nombrada
negotiation/	Máquinas de estado de transacción y sesión, y semántica de eventos de subasta
conformance/	Fixtures, manifiesto, ejecutor normativo y definiciones de grado de conformidad

Cada documento de especificación lleva un encabezado de estado que indica qué secciones son normativas y cuáles informativas.

Ejecutar la suite de conformidad

El ejecutor valida cada fixture nombrado en el manifiesto contra los esquemas y luego aplica los invariantes que JSON Schema no puede expresar. La validez del esquema no es conformidad, que es la razón por la que existe el ejecutor.

Necesita jsonschema>=4.18. Si no está en el intérprete del sistema, un entorno virtual es suficiente:

python3 -m venv .venv && .venv/bin/pip install "jsonschema>=4.18"

Ejecútelo desde la raíz del repositorio:

python3 conformance/run-conformance.py --verbose

El resultado esperado es que cada fixture pase y ninguno falle, con los totales que lleva el manifiesto: el manifiesto es la única fuente para el recuento, y el ejecutor lo imprime en cada ejecución. El ejecutor también verifica que cada fixture negativo sea rechazado por el código de razón que el manifiesto declara para él, siempre que la capa normativa genere códigos. Ejecútelo antes y después de cualquier cambio de esquema.

Cada fixture negativo es mínimo: eliminar el único elemento ofensivo debe dejar un documento que valide limpiamente. Un fixture negativo que falla por una razón incidental no prueba nada, así que verifíquelo al añadir uno.

La suite no depende de que alguien recuerde ejecutarla. Se ejecuta, junto con las pruebas de la implementación de referencia y las pruebas del servidor MCP, en cada pull request y en cada push a la rama predeterminada, bajo .github/workflows/checks.yml. GOVERNANCE.md, sección 3.4, exige que la suite pase para cualquier cambio en esquemas, fixtures, manifiesto o ejecutor, y ese flujo de trabajo es lo que convierte el requisito en una puerta.

Por dónde empezar a leer

1. CHARTER.md para saber qué es esto y qué no es deliberadamente.
2. schemas/canonical-commercial-model-v0.1.md para el modelo de objetos, el sobre y los invariantes que la validación de esquemas no puede expresar.
3. negotiation/pilot-transaction-state-machine-v0.1.md para saber qué mueve el estado y qué no.
4. conformance/manifest-v0.1.json para los fixtures que deciden si una implementación coincide con cualquiera de los anteriores.