Commandes, événements et ordre

15. Commandes, événements et concurrence

15.1 Commandes

Un Command est une demande signée pour une unique transition d’état structurée. Chaque enveloppe Command MUST contenir un Action ID stable, une version de protocole, un acteur, un type, une charge utile, un ID de corrélation, une heure d’émission et une signature. Un Command de portée Group MUST contenir son Group ID. Un Agent Command qui modifie l’état MUST contenir en plus les Session Epoch et Membership Epoch actuels. Un Command humain dans un Group existant MUST contenir le Membership Epoch actuel et MUST NOT contenir d’Agent Session Epoch. Un Command émis par un service Organization MUST NOT inventer d’Agent Session Epoch ni de Membership Epoch.

mission.create et mission.create_follow_up porter la pièce d’identité du Group en cours de création mais omettre Membership et les époques de session parce que le nouveau Group Membership n’existe pas encore et les commandes humaines n’utilisent pas Agent séances. Un plan de contrôle peut authentifier, relayer et valider mission.create, mais le signé Command acteur et racine résultante MissionOwner reste cet humain; le plan de contrôle ne devient pas le MissionOwner. Le Organization-possédé ext.missionweaveprotocol.registry.agent_card_register et ext.missionweaveprotocol.identity.session_open Commandes d’amorçage omises Group ID et les trois époques de rôle/session.

Un Agent Command dont l’autorité dérive du bail Coordinator actuel MUST contenir l’époque Coordinator actuelle. Ceci est requis pour mission.renew_coordinator, mission.submit_for_approval, mission.create_child, membership.grant_delegation et work.accept_result, ainsi que pour un Agent mission.terminate émis par un Agent. Un mission.terminate émis par un service est autorisé par la stratégie Organization et ne porte pas d’époque Coordinator. Un Command SHOULD contenir la révision globale attendue lors de la modification de l’état structuré existant. Un Command utilisant une escalade de coopération ponctuelle MUST contenir également cooperationOverrideGrantId.

Le même (actor ID, Action ID) avec un contenu signé canonique équivalent en octets MUST renvoyer le reçu original et MUST NOT ajouter une deuxième transition d’état. La réutilisation du même ID d’action avec un contenu canonique différent MUST échoue avec ACTION_ID_COLLISION.

Le Group Authority MUST authentifier l’acteur, valider Session Epoch et Membership Epoch, le Schema, la révision agrégée actuelle, le rôle, la délégation, le budget, la politique et le bail, puis soit rejeter le Command, soit ajouter atomiquement les Event résultants dans ce Group.

Les types principaux Command sont :

mission.create                 mission.assign_coordinator
mission.renew_coordinator      mission.submit_for_approval
mission.approve                mission.request_changes
mission.cancel                 mission.terminate
mission.create_child           mission.create_follow_up
membership.change             membership.end
membership.grant_delegation
message.post                   message.correct
message.retract                message.redact
work.propose                   work.authorize
work.offer                     work.accept_offer
work.start                     work.checkpoint
work.block                     work.unblock
work.submit                    work.accept_result
work.fail                      work.cancel
artifact.publish               approval.grant_execution
policy.grant_cooperation_override

Le noyau de référence définit en outre les commandes ext.missionweaveprotocol.* appartenant à Organization pour l’enregistrement Agent Card, l’activation de session, l’insertion de dépendances, le renouvellement du bail d’exécution, l’enregistrement faisant autorité de l’utilisation des ressources et l’archivage Group. Un futur Extension Profile pourrait standardiser des commandes pratiques telles que le refus explicite d’une offre, la clarification ou la pause Mission, mais ces noms ne sont pas des transitions principales de la v0.1.

15.2 Événements et commande Group

Un Event est un fait accepté et immuable. Une enveloppe Group Event MUST contenir l’Event ID, le Group ID, une séquence Group strictement croissante, la révision agrégée, le type, l’acteur, la cause, le correlation ID, l’heure d’occurrence, la charge utile et la signature du Group Authority. Les faits de portée Organization ext.missionweaveprotocol.registry.agent_card_registered et ext.missionweaveprotocol.identity.session_opened contiennent les champs communs Event d’identité, d’acteur, de cause, de corrélation, de charge utile, d’heure, d’autorité d’acceptation et de signature, mais MUST NOT contenir de Group ID, de séquence Group ni de révision agrégée Group.

Le Group Authority attribue une séquence monotone à chaque Group Event durable. Cette séquence fournit un affichage déterministe, une récupération et un ordre d’audit. Les messages ordinaires peuvent être logiquement simultanés même si le service attribue un ordre d’affichage. Les transitions structurées s’appuient sur l’ordre Event et les révisions agrégées.

Les types de base Event sont les faits au passé correspondant aux commandes de base, notamment :

mission.created                 mission.coordinator.assigned
mission.coordinator.renewed     mission.submitted_for_approval
mission.approved                mission.changes_requested
mission.cancelled               mission.terminated
mission.child.created           mission.follow_up.created
membership.changed              membership.ended
membership.delegation.granted
message.posted                  message.corrected
message.retracted               message.redacted
work.proposed                   work.authorized
work.offer.created              work.offer.accepted
work.contract.revised           work.started
work.progressed                 work.checkpointed
work.blocked                    work.unblocked
work.submitted                  work.result.accepted
work.failed                     work.cancelled
artifact.published              approval.execution.granted
policy.cooperation_override.granted
group.snapshot.created          group.archived

work.contract.revised et work.progressed sont des faits de base WorkItem émis par les commandes d’insertion de dépendance et d’exécution de bail-renouvellement appartenant à Organization. Agent Card et les faits d’activation de session conservent leurs types ext.missionweaveprotocol.* Event. group.snapshot.created et group.archived sont des faits d’archives de base émis de manière atomique par le Organization ext.missionweaveprotocol.core.group_archive Command après la validation de son instantané signé et de sa liaison avec le journal de stratégie.

Les événements automatiques MAY peuvent être provoqués par un Command accepté, un Event antérieur, un minuteur ou une décision politique. Les événements de différents groupes n’ont pas d’ordre défini.

15.3 Concurrence optimiste

Les commandes d’agrégat structuré SHOULD fournissent expectedRevision. S’il ne correspond pas à la révision actuelle, le Group Authority MUST rejette le Command avec REVISION_CONFLICT et MUST NOT l’applique partiellement. La propriété de première acceptation atomique, le renouvellement du bail, la modification Membership et Approval nécessitent toujours un traitement de comparaison et de définition, même si le champ filaire est omis par un acteur interne privilégié.

17. Liaison WebSocket

17.1 Connexion

Les serveurs MissionWeaveProtocol 0.1 MUST fournissent WebSocket sur TLS 1.3 (wss). Une seule connexion authentifiée multiplexe tous les groupes utilisés par un seul Agent. Chaque message WebSocket MUST contient exactement un cadre de texte UTF-8 JSON conforme à schemas/websocket-frame.schema.json. Les messages binaires WebSocket MUST NOT transportent des objets MissionWeaveProtocol ou du contenu Artifact dans la version 0.1.

Les types de trames principales sont HELLO, SUBSCRIBE, COMMAND, EVENT, ACK, PING et ERROR. Les trames de streaming partielles Message ne sont pas définies.

17.2 Abonnements

Après l’authentification, un client envoie SUBSCRIBE avec les ID Group, les positions de relecture par Group et les filtres d’attention facultatifs. Un filtre modifie la diffusion en direct, pas l’autorisation ou l’historique durable. Le serveur MUST applique indépendamment Membership pour chaque Group et MUST NOT révèle s’il existe un Group non autorisé.

Une connexion MAY entrelace les événements de plusieurs groupes. La séquence est garantie uniquement dans chaque Group. Un récepteur MUST est acheminé par l’ID Group avant d’appliquer la logique de séquence.

17.3 Contrôle des flux et vivacité

ACK fournit des progrès durables. PING fournit de la vivacité et MAY comporte un enregistrement de présence ; l’homologue fait écho à son nom occasionnel dans une réponse PING. Les serveurs MUST appliquent une mise en mémoire tampon limitée et une contre-pression par Group. Lorsqu’une limite est atteinte, ils SHOULD mettent ce Group en pause et émettent BACKPRESSURE avec des instructions de nouvelle tentative plutôt que de déconnecter les groupes non liés.

17.4 Encodage canonique

Le fil JSON n’a pas besoin d’arriver dans l’ordre canonique des membres, mais chaque hachage, identifiant dérivé du contenu ou signature MUST utilise RFC 8785 JCS octets. Les noms de membres d’objet en double MUST doivent être rejetés avant la validation du schéma. Les nombres et les chaînes MUST satisfont aux règles finite-binary64 et I-JSON de la Section 2 ; les implémentations conformes MUST produisent les mêmes octets JCS pour la même valeur JSON.

Le contenu volumineux est publié sous la forme Artifact et référencé par l’URI et le hachage du contenu. Les propriétés de base inconnues sont rejetées par les schémas v0.1. Les données Extension Profile non critiques inconnues sont stockées et relayées sans modification. Les extensions critiques inconnues provoquent UNKNOWN_CRITICAL_EXTENSION.