Papel de las vías de implementación
La sección de implementación explica cómo UAIX convierte a UAI-1 de un estándar publicado en software implementable y evidencia de publicación. El objetivo no es sólo describir el estándar, sino mostrar dónde ocurren realmente los registros de publicación, validación, empaquetado, integración del tiempo de ejecución y lanzamiento.
Pistas actuales
- WordPress Pista de publicaciónpara publicación, distribución, lanzamiento de paquetes, alineación de descubrimiento y documentación pública.
- Pista del puente.NETpara la integración del lado del servicio y del tiempo de ejecución más allá del sitio web público.
- Paquete.NET NuGetdocumenta la familia de paquetes C# propiedad de UAIX, las identidades de los paquetes NuGet.org, los comandos de instalación y los límites de autoridad para los implementadores de.NET.
- Módulos portátiles y paquetes de soporte donde las funciones compartidas necesitan una implementación estable.
Familia de paquetes publicada actualmente
uaix-authority-theme-v2.8.0.zipes el tema de lanzamiento público activo y lleva la superficie de publicación actual.uaix-theme-v2.8.0.zippermanece empaquetado y probado como un tema de compatibilidad instalable, pero no es la superficie de lanzamiento pública actual.uaix-core-v2.8.0.ziplleva el tiempo de ejecución de los estándares principales y la superficie de registro REST.uaix-modules-v2.8.0.ziplleva el paquete de módulos redistribuibles utilizado por las implementaciones UAIX.uaix-bridge-v2.8.0.ziptransporta el puente de referencia WordPress-to-.NET para la pista del puente nombrada.UAIX.UAIes la actual familia de paquetes.NET propiedad de UAIX para soporte de transferencia de mensajes, memoria, .uaix y tiempo de ejecución de UAI-1.uaix-locale-router-v3.0.0.ziptransporta enrutamiento con prefijo local para que las rutas de lanzamiento públicas permanezcan en rutas/en-us/...limpias.uaix-seo-sweep-v2.8.0.zipincluye SEO canónico, limpieza de cadenas de consulta, generación de mapas del sitio, salida de robots y la superficie del manifiesto de descubrimiento de raíz.
Alcance de implementación pública actual
La actual historia de implementación pública es intencionalmente estrecha y explícita. Las pistas publicadas sonWordPress Pista de publicaciónyPista del puente.NET.
- No implica soporte para Python, JavaScript, SDK, CLI u otro tiempo de ejecución a menos que se hayan publicado una página de implementación pública, evidencia respaldada por un validador y una entrada de seguimiento de lanzamiento.
- Utilice UAI-1, esquemas, entradas de registro, ejemplos y evidencia del validador como base portátil al evaluar un entorno que aún no tiene un seguimiento publicado.
Apoyo a los registros públicos
- Referencias y colaboradorespara enlaces de descubrimiento, atribución y orientación sobre citas.
- ElRegistro de cambiosyNoticiasarchivo para notas de migración, resúmenes de versiones y actualizaciones de implementación.
- Prensacuando el trabajo de implementación necesita lenguaje público aprobado para directorios, notas de socios o cobertura de estándares.
¿Qué se considera evidencia de implementación creíble?
- Uso de perfiles, esquemas, identificadores de registro yEjemplosen lugar de sustitutos privados.
- Salida de validación delValidadoro una verificación de conformidad equivalente.
- Accesorios, notas de compatibilidad, resultados de empaquetado y registros de lanzamiento que hacen que los cambios sean revisables después de la implementación.
- Enlaces al registro de cambios público actual y a los registros canónicos para que los lectores puedan rastrear lo que se envió.
Escalera de evidencia actual
- Elija el perfil publicado y los registros canónicos que definen el comportamiento que pretende admitir.
- Valide un mensaje de candidato o un partido y exporte el registro de resultados.
- Vincule ese resultado a la versión de implementación, la fecha de lanzamiento y el seguimiento que realizó el trabajo.
- Adjunte los enlaces de registro de cambios, noticias y descubrimiento correspondientes para que los lectores externos puedan verificar el mismo estado público.
Escala actual de reclamos de manutención
- Candidato validado:uno o más mensajes o accesorios pasan contra el registro público actual.
- Paquete listo para su lanzamiento:el registro de validación, la versión de implementación, los enlaces de descubrimiento y las notas de compatibilidad se adjuntan a un paquete liberable o compilación de tiempo de ejecución.
- Reclamo de apoyo público actual:un historial de implementación publicado y una entrada de seguimiento de lanzamiento indican qué se admite ahora, quién es el propietario y qué sigue siendo experimental.
UAIX actualmente trata solo el tercer nivel como un reclamo de apoyo público. Los dos primeros niveles son evidencia necesaria, pero no son lo mismo que el respaldo publicado.
Release readiness
How implementation evidence becomes a public support claim
Use this map when a WordPress or .NET track run is ready to move from local validation into a named public release lane.
Stage 1
Validated packet
A published fixture or candidate message passed against the current public record.
- Useful for review, debugging, and regression work right away.
- Still evidence only until the result is attached to a named release lane.
Stage 2
Release-ready packet
The passing result now travels with implementation versioning, artifact links, and discovery context.
- Keep the checked packet, validator export, artifact URLs, and compatibility notes together.
- This is the handoff point for launch review, packaging, and repeatable QA.
Stage 3
Public support claim
The named implementation track and release trail now say what is publicly supported and what is still out of scope.
- Scope the claim to the exact profiles, transport bindings, and owner path that are actually published.
- Use the current conformance level and release links so another reader can verify the same state.
Release packet
What should ship with the implementation evidence
- Implementation-track name plus package, runtime, or deployment version.
- Validated profile IDs, the checked packet, and the exact validator export used during review.
- Schema, registry, example, and discovery routes that reproduce the same public baseline.
- Compatibility notes, release date, and any affected launch-support surfaces.
Public support boundary
What must exist before a support claim belongs on the site
- A named implementation page that states owner, scope, and what remains experimental.
- Changelog and news entries that explain what changed and why another team should trust it.
- Only the highest achieved conformance level plus the exact profiles and transport bindings implemented.
- Citation and discovery links that make the claim reviewable after deployment.
Current public conformance levels: Use these levels for outward-facing language once the packet becomes part of a named release and implementation record.
L1-core-envelope
Envolvente central L1
Produzca o consuma sobres con clave UAI para perfiles con nombre sin cambiar los campos raíz canónicos.
- Conserve uai_version, perfil, message_id, fuente, destino, conversación, entrega, confianza, cuerpo, procedencia, integridad y extensiones.
- Nombra el perfil exacto y la liberación para cada reclamo de soporte.
- No reclame la ejecución del tiempo de ejecución únicamente mediante soporte de sobre.
Public claim: Puede reclamar L1 solo para los perfiles con nombre exacto cuyo sobre canónico realiza viajes de ida y vuelta con éxito.
L2-profile-validation
Validación del perfil L2
Pase las comprobaciones del esquema publicado y del validador para los perfiles exactos reclamados.
- Resuelva esquemas, entradas de registro, ejemplos y registros de campo de rutas públicas UAIX.
- Aprobar los elementos positivos y no aprobar los elementos negativos requeridos para cada perfil reclamado.
- Mantenga los controles omitidos y las advertencias del validador adjuntas a las pruebas.
Public claim: Puede reclamar L2 solo para perfiles con evidencia respaldada por un validador.
L3-trust-and-integrity
L3 Confianza e Integridad
Preserve los metadatos de confianza, las sugerencias de la ventana de reproducción, la procedencia, la integridad y la continuidad del seguimiento.
- Declarar canal de confianza y principal.
- Preservar la canonicalización de integridad y los metadatos de suma de comprobación.
- Valide los metadatos firmados, acreditados, did+vc y de seguimiento cuando se reclamen.
Public claim: Puede reclamar L3 solo por los canales de confianza y el comportamiento de integridad demostrados por los accesorios.
L4-public-record-publisher
Editor de registros públicos L4
Publicar artefactos públicos detectables necesarios para la inspección y reproducción externas.
- Publique descubrimiento, esquemas, registro, ejemplos, registro de campos, enlaces de transporte, canales de confianza, registro de errores, niveles de conformidad, orientación del validador, registro de cambios y evidencia de publicación.
- Mantenga el mapa del sitio, llms.txt y la navegación pública alineados con las rutas actuales.
- Evite registros privados o capturas de pantalla como única evidencia de respaldo.
Public claim: Puede reclamar L4 solo para la superficie de liberación pública que sea detectable y evidenciada.
L5-agent-communication-profiles
Perfiles de comunicación del agente L5
Admite los ocho perfiles uai.agent.*.v1 como registros de sobre canónicos UAI-1.
- Valide los perfiles de mensaje, confirmación, estado de tarea, bloqueador, propuesta de memoria, transferencia, informe final y corrección del agente.
- Rechace propuestas de memoria secretas, bloqueadores inseguros, promoción directa de memoria fría e informes finales incompletos.
- Llevar el límite de soporte UAIX en los registros pertinentes.
Public claim: Puede reclamar L5 solo para perfiles de agentes específicos con casos de conformidad positivos y negativos.
L6-reliable-delegation-idempotency-correlation
L6 Delegación confiable con idempotencia y correlación
Utilice reglas de idempotencia, correlación, reintento, ciclo de vida, tiempo de espera, respaldo, reconocimiento y salida esperada para el trabajo delegado.
- Requerir delivery.idempotency_key para cada operación destructiva o delegada distinta.
- Conservar conversation.correlation_id en todos los mensajes relacionados.
- Declare retry_count, secuencia, expires_at, ciclo de vida, timeout_ms, fallback_directive y expect_output_schema cuando se reclame la delegación.
Public claim: Puede reclamar L6 solo por un comportamiento de delegación confiable demostrado por dispositivos de conformidad y comportamiento del receptor.
L7-capability-negotiation
Negociación de capacidad L7
Publique y valide el descubrimiento de capacidades, afirmaciones, fallas de negociación y respuestas de capacidades no respaldadas.
- Publique declaraciones de capacidad con perfiles exactos, enlaces, canales de confianza, niveles de conformidad y códigos de error.
- Devuelve capacidad_not_supported para solicitudes de capacidad no admitidas.
- No implica certificación, estado oficial del adaptador, mensajería alojada ni orquestación en tiempo de ejecución.
Public claim: Puede reclamar L7 solo para los flujos de negociación de capacidad exactos demostrados por los dispositivos públicos y el comportamiento del validador.
Claim rules
Public language should stay inside published evidence
- Las declaraciones de soporte deben nombrar el nivel más alto alcanzado más los perfiles exactos, vinculaciones de transporte, canales de confianza y casos de conformidad implementados.
- Un proyecto solo puede reclamar perfiles, vinculaciones, canales de confianza y niveles de conformidad que demuestren los dispositivos públicos y las pruebas de validación.
- Un resultado aprobado del validador es evidencia, no certificación, respaldo, soporte oficial del adaptador, mensajería alojada, sincronización automática o ejecución en tiempo de ejecución.
- Las reclamaciones de registros públicos requieren esquemas detectables, registros de registro, ejemplos, registros de campo, códigos de error, casos de paquetes de conformidad, registros de cambios y notas de la versión.
- Revalide las reclamaciones de soporte cuando cambien los esquemas, los registros de registro, el orden de los campos, los ejemplos, el comportamiento del validador, la versión de implementación, la postura de confianza, el mapa del sitio o la navegación pública.
- La evidencia de conformidad no demuestra por sí sola la seguridad, la privacidad, la disponibilidad, el rendimiento, el cumplimiento legal, la infraestructura de confianza alojada ni las operaciones de producción.
- Keep the implementation page, release trail, and citation/discovery links attached when another team needs to verify the same public state.
Working rule: Use the conformance ladder for language, but use the named implementation track and release trail for the actual public support boundary.
Liberar paquete de evidencia
Una implementación lista para su lanzamiento debería mantener juntos el registro estándar público y la evidencia del software en lugar de dispersar las pruebas en registros de compilación privados.
- Incluya el paquete o la versión del tiempo de ejecución, los ID de perfil validados y las rutas de esquema y registro utilizadas durante la verificación.
- Adjunte los resultados del validador exportados, las referencias de dispositivos y cualquier nota de compatibilidad que afecte a los adoptantes posteriores.
- Dirija a los lectores a la entrada relevante del registro de cambios, al resumen de noticias y a los enlaces de citas antes de llamar a la implementación lista para su lanzamiento.
Paquete de conformidad pública actual
Actualmente, UAIX trata un paquete de conformidad como evidencia revisable adjunta a una versión, no como una superficie de certificación independiente.
- Mantenga juntos el resultado del validador exportado, los ID de perfil validados, el esquema y las rutas de registro, y el elemento de ejemplo o candidato utilizado durante la revisión.
- Adjunte la versión de implementación, la fecha de lanzamiento y el registro de cambios o las referencias de noticias correspondientes para que los lectores externos puedan rastrear lo que realmente sucedió.
- Reconstruya el paquete cada vez que cambien los esquemas, accesorios, comportamiento del validador o asignaciones de tiempo de ejecución.
- No presente un paquete de aprobación como insignia de certificación, respaldo de socio o garantía permanente en futuras versiones.
Seguimiento de la lista de verificación de admisión para futuro apoyo público
- Una página de implementación pública que indica el propietario, el límite de soporte y la relación con el registro normativo UAI-1.
- Evidencia respaldada por un validador o prueba de conformidad equivalente vinculada a perfiles, esquemas, entradas de registro y ejemplos publicados.
- Una entrada de seguimiento de lanzamiento que indica qué es compatible ahora, qué sigue siendo experimental y qué lectores posteriores necesitan migrar.
- Enlaces de descubrimiento, citas e implementación que permiten a lectores externos resolver la misma pista sin notas privadas ni capturas de pantalla.
Paquete de adopción inicial
Los equipos que evalúan UAIX deberían poder ensamblar un paquete público mínimo a partir del registro actual sin notas privadas, rutas no publicadas o capturas de pantalla internas.
- UAI-1, Esquemas, Registro, yEjemploscomo base normativa y legible por máquina.
- Evidencia respaldada por validadores de laValidadorpara al menos un mensaje de candidato o un partido publicado.
- Referencias y colaboradores, el
/.well-known/uaix.jsonmanifiesto y el mapa del sitio publicado aparece como la capa de descubrimiento y cita. - ElRegistro de cambiosyNoticiasentradas que explican la postura actual de migración y liberación.
Ruta actual del kit de adopción
UAIX ahora publica el paquete de primera prueba directamente a través delKit de adopciónpágina y el/wp-json/uaix/v1/adoption-kitruta.
- Comience allí cuando un equipo necesite archivos iniciales, cargas útiles listas para el validador, una respuesta de intercambio simulado de referencia y los siguientes pasos de implementación en un paquete reutilizable.
- MantenerUAI-1, Esquemas, Registro, yEjemploscomo base técnica más profunda detrás del paquete.
- Adjunte evidencia del validador exportada, el historial de implementación relevante y la coincidencia.Registro de cambiosyNoticiasentradas cuando el paquete pasa a la revisión de lanzamiento.
Cómo utilizar esta sección
Elija la ruta de implementación que coincida con su responsabilidad, luego lleve evidencia del validador, referencias de dispositivos, disciplina del registro de cambios y contexto de enlace público con esa implementación en lugar de tratarlos como tareas de documentación separadas.
Siguiente paso
Utilice elWordPress Pista de publicaciónsi necesita la ruta de publicación, empaquetado y registro de lanzamiento. Utilice elPista del puente.NETSi necesita una integración más profunda del tiempo de ejecución detrás del registro público, mantenga ambos vinculados alRegistro de cambiosyNoticias.