Rôle des pistes de mise en œuvre
La section de mise en œuvre explique comment UAIX transforme UAI-1 d’une norme publiée en logiciel déployable et en preuves de publication. L’objectif n’est pas seulement de décrire la norme, mais de montrer où se produisent réellement la publication, la validation, l’empaquetage, l’intégration d’exécution et les enregistrements de version.
Pistes actuelles
- WordPress Piste de publicationpour la publication, la distribution, la publication de packages, l’alignement de la découverte et la documentation publique.
- Piste de pont.NETpour l’intégration du runtime et du côté service au-delà du site Web public.
- Package NuGet.NETdocumente la famille de packages C# appartenant à UAIX, les identités des packages NuGet.org, les commandes d’installation et les limites d’autorité pour les implémenteurs.NET.
- Modules portables et packages de support où les fonctionnalités partagées nécessitent une implémentation stable.
Famille de packages actuellement publiée
uaix-authority-theme-v2.8.0.zipest le thème de lancement public actif et porte la surface de publication actuelle.uaix-theme-v2.8.0.zipreste emballé et testé en tant que thème de compatibilité installable, mais ce n’est pas la surface de lancement publique actuelle.uaix-core-v2.8.0.zipcontient le temps d’exécution des normes de base et la surface d’enregistrement REST.uaix-modules-v2.8.0.zipcontient le pack de modules redistribuables utilisé par les implémentations UAIX.uaix-bridge-v2.8.0.zipporte le pont de référence WordPress-to-.NET pour la piste de pont nommée.UAIX.UAIest la famille de packages.NET actuelle appartenant à UAIX pour la prise en charge des messages, de la mémoire, de .uaix et du transfert d’exécution de UAI-1.uaix-locale-router-v3.0.0.zipcomporte un routage préfixé par les paramètres régionaux afin que les chemins de lancement publics restent sur des routes/en-us/...propres.uaix-seo-sweep-v2.8.0.zipassure le référencement canonique, le nettoyage des chaînes de requête, la génération de plan de site, la sortie des robots et la surface du manifeste de découverte racine.
Portée actuelle de la mise en œuvre publique
L’histoire actuelle de la mise en œuvre publique est intentionnellement étroite et explicite. Les morceaux publiés sontWordPress Piste de publicationetPiste de pont.NET.
- N’impliquez pas Python, JavaScript, SDK, CLI ou tout autre support d’exécution à moins qu’une page de mise en œuvre publique, des preuves appuyées par le validateur et une entrée de piste de publication n’aient été publiées.
- Utilisez UAI-1, les schémas, les entrées de registre, les exemples et les preuves du validateur comme référence portable lors de l’évaluation d’un environnement qui n’a pas encore de piste publiée.
Prise en charge des archives publiques
- Références et contributeurspour les liens de découverte, l’attribution et les conseils de citation.
- LeJournal des changementsetActualitésarchive pour les notes de migration, les résumés de versions et les mises à jour de mise en œuvre.
- Presselorsque le travail de mise en œuvre nécessite un langage public approuvé pour les annuaires, les notes des partenaires ou la couverture des normes.
Ce qui compte comme preuve crédible de mise en œuvre
- Utilisation de profils, schémas, identifiants de registre publiés etExemplesplutôt que des substituts privés.
- Sortie de validation duValidateurou un contrôle conforme équivalent.
- Appareils, notes de compatibilité, résultats de packaging et enregistrements de versions qui rendent les modifications consultables après le déploiement.
- Liens vers le journal des modifications public actuel et les enregistrements canoniques afin que les lecteurs puissent retracer ce qui a été expédié.
Échelle de preuves actuelle
- Choisissez le profil publié et les enregistrements canoniques qui définissent le comportement que vous souhaitez prendre en charge.
- Validez un message ou un appareil candidat et exportez l’enregistrement du résultat.
- Liez ce résultat à la version d’implémentation, à la date de sortie et à la piste qui a effectué le travail.
- Joignez les liens correspondants au journal des modifications, aux actualités et à la découverte afin que les lecteurs externes puissent vérifier le même état public.
Échelle actuelle de demande de pension alimentaire
- Candidat validé:un ou plusieurs messages ou appareils passent par rapport au dossier public actuel.
- Paquet prêt à être publié:l’enregistrement de validation, la version d’implémentation, les liens de découverte et les notes de compatibilité sont joints à un package publiable ou à une version d’exécution.
- Demande actuelle de soutien public:un historique de mise en œuvre publié et une entrée de piste de publication indiquent ce qui est actuellement pris en charge, qui en est propriétaire et ce qui reste expérimental.
UAIX ne traite actuellement que le troisième niveau comme une demande de soutien public. Les deux premiers niveaux constituent des preuves nécessaires, mais ils ne sont pas identiques aux supports publiés.
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.
Libérer le dossier de preuves
Une implémentation prête à être publiée doit conserver l’enregistrement public de la norme et les preuves logicielles ensemble plutôt que de disperser les preuves dans les journaux de construction privés.
- Incluez la version du package ou du runtime, les ID de profil validés ainsi que les itinéraires de schéma et de registre utilisés lors de la vérification.
- Joignez les résultats du validateur exportés, les références d’appareils et toutes les notes de compatibilité qui affectent les adoptants en aval.
- Dirigez les lecteurs vers l’entrée du journal des modifications, le résumé de l’actualité et les liens de citation pertinents avant de qualifier la version de mise en œuvre de prête.
Paquet de conformité publique actuel
UAIX traite actuellement un paquet de conformité comme une preuve révisable jointe à une version, et non comme une surface de certification autonome.
- Conservez ensemble le résultat du validateur exporté, les ID de profil validés, les itinéraires de schéma et de registre, ainsi que l’exemple ou le dispositif candidat utilisé lors de l’examen.
- Joignez la version d’implémentation, la date de sortie et le journal des modifications ou les références d’actualités correspondantes afin que les lecteurs externes puissent retracer ce qui s’est réellement passé.
- Reconstruisez le paquet chaque fois que les schémas, les appareils, le comportement du validateur ou les mappages d’exécution changent.
- Ne présentez pas de dossier de réussite comme un badge de certification, une approbation de partenaire ou une garantie permanente pour les versions futures.
Suivre la liste de contrôle d’admission pour un futur soutien public
- Une page de mise en œuvre publique qui indique le propriétaire, la limite de support et la relation avec l’enregistrement normatif UAI-1.
- Preuve appuyée par le validateur ou preuve de conformité équivalente liée aux profils, schémas, entrées de registre et exemples publiés.
- Une entrée de version qui indique ce qui est actuellement pris en charge, ce qui reste expérimental et ce que les lecteurs en aval doivent migrer.
- Liens de découverte, de citation et de mise en œuvre qui permettent aux lecteurs externes de résoudre la même piste sans notes privées ni captures d’écran.
Pack d’adoption de démarrage
Les équipes évaluant UAIX devraient être en mesure d’assembler un paquet public minimal à partir de l’enregistrement actuel sans notes privées, itinéraires non publiés ou captures d’écran internes.
- UAI-1, Schémas, Registre, etExemplescomme référence normative et lisible par machine.
- Preuves appuyées par les validateurs duValidateurpour au moins un message candidat ou un match publié.
- Références et contributeurs, le
/.well-known/uaix.jsonmanifeste, et le plan du site publié apparaît comme couche de découverte et de citation. - LeJournal des changementsetActualitésentrées qui expliquent la situation actuelle en matière de migration et de publication.
Cheminement actuel du kit d’adoption
UAIX publie désormais le premier bundle de preuves directement via leKit d’adoptionpage et le/wp-json/uaix/v1/adoption-kititinéraire.
- Commencez par là lorsqu’une équipe a besoin de fichiers de démarrage, de charges utiles prêtes pour le validateur, d’une réponse d’échange simulée de référence et des prochaines étapes de mise en œuvre dans un paquet réutilisable.
- GarderUAI-1, Schémas, Registre, etExemplescomme base technique plus profonde derrière l’offre groupée.
- Joignez les preuves du validateur exportées, les antécédents de mise en œuvre pertinents et les documents correspondants.Journal des changementsetActualitésentrées lorsque le paquet passe en revue de version.
Comment utiliser cette rubrique
Choisissez la piste d’implémentation qui correspond à votre responsabilité, puis intégrez les preuves du validateur, les références des appareils, la discipline du journal des modifications et le contexte du lien public avec cette implémentation plutôt que de les traiter comme des tâches de documentation distinctes.
Étape suivante
Utilisez leWordPress Piste de publicationsi vous avez besoin du chemin de publication, d’emballage et d’enregistrement de version. Utilisez lePiste de pont.NETsi vous avez besoin d’une intégration plus approfondie du runtime derrière le dossier public, gardez les deux liés auJournal des changementsetActualités.