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
L1 Core Envelope
Produce or consume keyed UAI envelopes for named profiles without changing the canonical root fields.
- Preserve uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions.
- Name the exact profile and release for every support claim.
- Do not claim runtime execution from envelope support alone.
Public claim: May claim L1 only for the exact named profiles whose canonical envelope round-trips successfully.
L2-profile-validation
L2 Profile Validation
Pass published schema and validator checks for the exact profiles claimed.
- Resolve schemas, registry entries, examples, and field registry records from public UAIX routes.
- Pass positive fixtures and fail required negative fixtures for each claimed profile.
- Keep skipped checks and validator warnings attached to evidence.
Public claim: May claim L2 only for profiles with validator-backed evidence.
L3-trust-and-integrity
L3 Trust and Integrity
Preserve trust metadata, replay-window hints, provenance, integrity, and trace continuity.
- Declare trust channel and principal.
- Preserve integrity canonicalization and checksum metadata.
- Validate signed, credentialed, did+vc, and trace metadata when claimed.
Public claim: May claim L3 only for the trust channels and integrity behavior proven by fixtures.
L4-public-record-publisher
L4 Public Record Publisher
Publish discoverable public artifacts needed for external inspection and reproduction.
- Publish discovery, schemas, registry, examples, field registry, transport bindings, trust channels, error registry, conformance levels, validator guidance, changelog, and release evidence.
- Keep sitemap, llms.txt, and public navigation aligned with current routes.
- Avoid private logs or screenshots as the only support evidence.
Public claim: May claim L4 only for the public release surface that is discoverable and evidenced.
L5-agent-communication-profiles
L5 Agent Communication Profiles
Support the eight uai.agent.*.v1 profiles as canonical UAI-1 envelope records.
- Validate agent message, ack, task-status, blocker, memory-proposal, handoff, final-report, and correction profiles.
- Reject secret-like memory proposals, unsafe blockers, cold-memory direct promotion, and incomplete final reports.
- Carry the UAIX support boundary in relevant records.
Public claim: May claim L5 only for the specific agent profiles with passing positive and negative conformance cases.
L6-reliable-delegation-idempotency-correlation
L6 Reliable Delegation with Idempotency and Correlation
Use idempotency, correlation, retry, lifecycle, timeout, fallback, acknowledgement, and expected-output rules for delegated work.
- Require delivery.idempotency_key for each distinct delegated or destructive operation.
- Preserve conversation.correlation_id across related messages.
- Declare retry_count, sequence, expires_at, lifecycle, timeout_ms, fallback_directive, and expected_output_schema when delegation is claimed.
Public claim: May claim L6 only for reliable delegation behavior proven by conformance fixtures and receiver behavior.
L7-capability-negotiation
L7 Capability Negotiation
Publish and validate capability discovery, assertions, negotiation failures, and unsupported-capability responses.
- Publish capability statements with exact profiles, bindings, trust channels, conformance levels, and error codes.
- Return capability_not_supported for unsupported capability requests.
- Do not imply certification, official adapter status, hosted messaging, or runtime orchestration.
Public claim: May claim L7 only for the exact capability negotiation flows proven by public fixtures and validator behavior.
Claim rules
Public language should stay inside published evidence
- Support claims must name the highest achieved level plus the exact profiles, transport bindings, trust channels, and conformance cases implemented.
- A project may claim only profiles, bindings, trust channels, and conformance levels that public fixtures and validator tests prove.
- A passing validator result is evidence, not certification, endorsement, official adapter support, hosted messaging, automatic sync, or runtime execution.
- Public-record claims require discoverable schemas, registry records, examples, field registry records, error codes, conformance pack cases, changelog, and release notes.
- Revalidate support claims when schemas, registry records, field order, examples, validator behavior, implementation version, trust posture, sitemap, or public navigation changes.
- Conformance evidence does not prove security, privacy, availability, performance, legal compliance, hosted trust infrastructure, or production operations by itself.
- 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.