Contact et révision

But#

Contact and Review est le chemin d’accès public dédié aux questions UAIX de la phase de lancement, aux paquets de contributions, aux propositions de modification et aux notes de révision liées à la version. Il transforme en un seul itinéraire les conseils aux contributeurs qui étaient auparavant dispersés entre les pages de gouvernance, de références, de feuille de route et de journal des modifications.

Contact direct#

Pour UAI-1, AI Memory, Project Handoff, Agent File Handoff, les paquets de contribution ou les questions d’examen de la mise en œuvre, contactez Michael Kappel directement àMichael.Kappel@Protocol5.comou1 (630) 362-7576. Vous pouvez également partir deMichaelKappel.comouLinkedIn.

Expérience professionnelle#

Michael Kappel est le mainteneur publié de UAIX et l’auteur principal du dossier public actuel de UAI-1. Il est ingénieur logiciel senior et architecte logiciel avec plus de deux décennies d’expérience dans la fourniture de systèmes Web d’entreprise, la modernisation de plates-formes existantes complexes, la conception d’architectures d’applications évolutives et l’amélioration de la qualité des logiciels dans les environnements d’ingénierie.NET, SQL Server, TypeScript, JavaScript, cloud et assistés par l’IA.

Son expérience couvre ASP.NET Core, C#, Web API, Razor Pages, EF Core, ADO.NET, SQL Server, recherche sémantique, travail de l’API OpenAI, outils LLM, tests automatisés, optimisation des performances, mentorat technique et mémoire de projet durable lisible par l’IA. Il détient également un large portefeuille de qualifications professionnelles Microsoft, notamment des certifications de développeur, de base de données, Azure et de plate-forme d’application. Ce profil public résume intentionnellement l’autorité professionnelle derrière UAIX sans énumérer les anciens employeurs ou les historiques de clients privés.

Cheminement actuel de réception des avis#

Utilisez cette page comme liste de contrôle d’admission publique avant qu’un changement ne devienne une vérité de lancement. UAIX ne publie pas encore de suivi des problèmes publics, de forum ou de file d’attente de référentiel distinct sur la surface du site, les paquets de révision doivent donc rester liés aux coordonnées ci-dessus, aux pages canoniques, aux artefacts lisibles par machine, aux preuves du validateur et à la piste de publication datée.

1. Identifiez la famille d’enregistrements concernée: spécification, schéma, registre, exemple, validateur, implémentation, gouvernance, découverte, packaging ou contenu local.
2. Liez le chemin canonique propre de la page et incluez le code d’enregistrement au niveau de la page lorsqu’il est visible dans l’en-tête du document.
3. Joignez l’artefact de machine, l’appareil, le résultat du validateur, la sortie du package ou la réponse d’itinéraire pertinent lorsque le comportement change.
4. Indiquez si le changement est additif, correctif, orienté politique, localisé uniquement ou révolutionnaire.
5. Mettez à jour ensemble la copie publique en anglais, zh-CN, français et espagnol lorsque la surface affectée est visible pour les lecteurs localisés.
6. Enregistrez les modifications liées au lancement viaJournal des changementsetActualitéslorsque les lecteurs extérieurs ont besoin d’une piste publique datée.

Lignes directrices pour les contributeurs#

• UtiliserUAI-1, Schémas, Registre, Exemples, et leValidateurcomme base technique avant de proposer un comportement de protocole.
• UtiliserFeuille de routelorsque la proposition affecte le futur langage de support, les preuves de pont, le transfert compact, la maturité de conformité, les outils de développement ou l’expansion de la gouvernance.
• UtiliserGouvernanceetPolitique et sécuritélorsque le changement affecte la propriété, la discipline de publication, la confidentialité, l’accessibilité, l’analyse, les licences ou la posture de sécurité.
• UtiliserImplémentationslorsqu’une proposition affecte un logiciel packagé, le mappage d’exécution, les preuves de version ou la portée d’une demande de support.
• Ne décrivez pas une expérience locale, un résultat de validation unique, une implémentation non publiée ou une note privée comme support public actuel jusqu’à ce que la copie de la page, l’artefact machine, les preuves et la piste de publication soient d’accord.

Modifier le modèle de proposition#

Record family:
Canonical path:
Record code:
Change type:
Expected public effect:
Evidence attached:
Validator or package result:
Locale copy impact:
Release-trail update:
Owner or reviewer:
Open questions:

Fenêtres de révision et piste de décision#

Pendant le pré-lancement, UAIX reste un enregistrement de normes axé sur un seul éditeur. L’attribution publique nommée actuelle et les enregistrements canoniques du site constituent la piste de décision; des listes plus larges d’évaluateurs, le vote du public, la certification ou la gouvernance des partenaires ne doivent pas être implicites jusqu’à leur publication.

• Droits de décision:les décisions de lancement actuelles sont publiées en mettant à jour ensemble les pages canoniques, les artefacts de machine et les enregistrements de version.
• Fenêtre de révision:un changement doit rester planifié jusqu’à ce que la page publique, la route, les attentes du validateur, la preuve du package et la copie des paramètres régionaux concernés puissent être examinées comme un seul paquet.
• Cadence de sortie:les modifications préalables au lancement sont basées sur les notes de version plutôt que sur le calendrier; les modifications affectant la compatibilité doivent recevoir une entrée datée du journal des modifications.
• Commentaires publics:un commentaire devient partie intégrante du dossier public lorsque sa disposition est reflétée dans une page canonique mise à jour, un élément de feuille de route, une entrée du journal des modifications, un résumé de l’actualité, une attente du validateur ou un enregistrement de mise en œuvre.

Ce qu’il faut inclure avant l’examen du lancement#

• Liens canoniques vers des pages et des itinéraires, jamais d’alias de chaîne de requête ou de captures d’écran comme source de vérité.
• Réponses de route orientées machine lorsque le changement affecte la référence API, la découverte, la feuille de route, le kit d’adoption, le pack de conformité, les schémas, le registre, les exemples ou la validation.
• Preuve de création de package, de test de fumée, d’audit de lancement ou de suivi de la mise en œuvre lorsque le changement affecte les logiciels distribuables.
• Contenu zh-CN mis à jour lorsque les lecteurs localisés publics verront la nouvelle page, l’itinéraire ou la déclaration de version.

Étape suivante#

Commencez parRéférences et contributeurspour le contexte de découverte et d’attribution, utilisez cette page pour assembler le dossier d’examen, puis faites passer la décision publiqueGouvernance, Feuille de route, Journal des changements, etActualitésau besoin.