Extensions, erreurs, contrôles et conformité

18. Profils d’extension

Les développeurs MAY définissent des commandes, des événements et des données personnalisés via des profils d’extension approuvés par Organization. Chaque profil MUST déclare un URI de profil unique au monde, une version sémantique, un URI et un hachage de schéma, les fonctionnalités requises, la criticité et la signature d’approbation Organization. Un Group épingle les versions majeures prises en charge des profils qu’il utilise.

Les types d’extension MUST utilisent l’espace de noms ext.<organization>.<profile>.<name> défini par le profil. Une extension non critique inconnue MAY doit être conservée et relayée sans interprétation. Un Agent MUST refuse la participation à une transition qui dépend d’un profil critique inconnu.

Un Extension Profile MUST NOT remplace ou affaiblit l’identité, Membership, Event ordre, idempotence, Session Epoch, époque de propriété, bail, budget, Approval, provenance Artifact, isolation Mission ou règle selon laquelle les messages n’autorisent jamais d’actions.

19. Erreurs

Les erreurs MUST être conformes à schemas/error.schema.json. Une réponse d’erreur MUST être lisible par machine, MUST indiquer si la nouvelle tentative est sûre et SHOULD identifier la frame ou l’Action ID associé sans exposer de données non autorisées. Les codes de base sont :

Codes	Signification
`UNSUPPORTED_VERSION`	Aucune version de protocole compatible
`AUTH_REQUIRED`	L’authentification est absente
`AUTH_INVALID_SIGNATURE`	Échec de la signature du document signé, de la validité de la clé, de la preuve d’admission ou du contrôle de fraîcheur
`AUTH_STALE_SESSION`	Session Epoch est clôturé
`AUTH_STALE_COORDINATOR`	Coordinator L’époque est clôturée
`AUTH_FORBIDDEN`	L’acteur n’a pas d’autorisation ou d’éligibilité aux règles
`GROUP_NOT_FOUND`	Group est absent ou intentionnellement non divulgué
`MEMBERSHIP_REQUIRED`	Non applicable Membership
`MEMBERSHIP_STALE`	Membership L’époque est clôturée
`SCHEMA_VALIDATION_FAILED`	L’objet n’est pas conforme à son schéma
`INVALID_COMMAND`	Command est bien formé mais sémantiquement invalide
`INVALID_STATE_TRANSITION`	L’état agrégé interdit la transition
`REVISION_CONFLICT`	La révision attendue ne correspond pas
`ACTION_ID_COLLISION`	Stable Action ID a été réutilisé avec un contenu différent
`UNKNOWN_CRITICAL_EXTENSION`	L’extension requise ne peut pas être interprétée
`WORK_CONTRACT_INCOMPLETE`	Les informations requises sur le contrat de travail sont manquantes
`WORK_OFFER_EXPIRED`	L’offre n’est plus valable
`WORK_ALREADY_OWNED`	Un autre candidat a obtenu la propriété exclusive
`WORK_LEASE_EXPIRED`	Le bail requis n’est plus valide
`WORK_STALE_OWNERSHIP`	L’époque de la propriété est clôturée
`APPROVAL_REQUIRED`	La porte politique n’a pas été satisfaite
`BUDGET_EXCEEDED`	Un budget ferme Mission ou WorkItem est épuisé
`RATE_LIMITED`	Le taux directeur ou le seuil de récursion a été atteint
`BACKPRESSURE`	Le récepteur ne peut actuellement pas accepter plus de trafic
`CURSOR_TOO_OLD`	Le replay en ligne ne contient plus la position demandée
`PROTOCOL_VIOLATION`	Cadrage violé par les pairs ou invariant de base
`INTERNAL_ERROR`	L’autorité a échoué sans accepter la transition

Une nouvelle tentative du Command inchangé MUST conserver l’Action ID d’origine et le contenu signé. AUTH_INVALID_SIGNATURE MUST NOT être réessayé sans modification avant que sa cause ne soit corrigée. Après correction locale de l’enveloppe de signature, de la clé faisant autorité ou de l’état d’admission, un expéditeur MAY réessayer l’Action ID d’origine uniquement pendant que tout le contenu protégé reste valide. Si la fraîcheur Command a expiré, l’expéditeur MUST créer à la place un nouveau Command avec un nouvel Action ID, un issuedAt actuel, un signature.createdAt correspondant et une nouvelle signature. ACTION_ID_COLLISION nécessite un nouveau Command avec un nouvel Action ID. Une erreur de fencing obsolète nécessite l’Epoch faisant autorité actuel et un nouveau Command avec un nouvel Action ID et une nouvelle signature.

20. Contrôles de débit, de récursivité et d’emballement

La politique Organization MUST prend en charge les limites sur Message et les taux de proposition, les cycles de clarification non résolus, les éléments de travail actifs et en file d’attente, la profondeur de la délégation, les budgets de jetons/temps/financiers et la décomposition circulaire ou en double. Ces contrôles SHOULD utilisent des seuils souples, une notification Coordinator et une escalade explicite plutôt que des plafonds de protocole bas fixes.

Une implémentation MUST rejette la délégation cyclique ou l’ascendance Mission. Lorsqu’un travail légitime nécessite plus de profondeur, de budget ou de taux, le Coordinator peut demander une approbation de politique ou MissionOwner et continuer après la subvention. Limites de la stratégie MUST NOT rejette silencieusement le travail accepté.

Une escalade de limite de coopération MUST doit être représentée par une octroi de remplacement de coopération durable et unique, et non par un booléen injecté, un résultat de rappel local ou une exemption réutilisable. L’octroi MUST lie un Mission, Group, le nom de la stratégie, le bénéficiaire Principal, le type cible Command, l’ID d’action cible, le motif, l’approbateur, l’heure d’octroi et l’expiration. Seul le MissionOwner ou un acteur de stratégie Organization autorisé peut l’émettre. La cible Command MUST cite l’ID d’octroi dans son membre d’enveloppe cooperationOverrideGrantId.

Avant d’accepter la transition cible, Group Authority MUST vérifier que la subvention citée existe, qu’elle n’est pas expirée, qu’elle n’est pas consommée et qu’elle correspond exactement à celle Commandc’est Mission, Group, acteur, genre, ID d’action et stratégie dépassée. Il MUST consommer atomiquement la subvention uniquement lorsque la transition cible est acceptée. Émission et consommation MUST être annexé au journal de politique faisant autorité, avec la consommation liée au Event. Une nouvelle tentative idempotente du même accepté Command renvoie son précédent Event; toute autre tentative d’utilisation de la subvention MUST échouer.

21. Compatibilité des schémas et des versions

Tous les schémas v0.1 utilisent JSON Projet de schéma 2020-12. Ensemble d’objets de base additionalProperties: false; l’extensibilité ne se produit que par le biais d’explicites extensions membres et profils approuvés. Implémentations MUST conserver une extension non critique inconnue de manière équivalente en octets pour le relais canonique lorsque cela est possible.

Le fil protocolVersion est 0.1. Une clarification du schéma rétrocompatible incrémente la version du correctif de spécification sans modifier la version du fil. Un changement qui modifie la sémantique principale ou les champs obligatoires nécessite une nouvelle version mineure ou majeure du fil et une négociation de prise de contact.

Les 22 schémas normatifs sont :

common.schema.json
websocket-frame.schema.json
command.schema.json
event.schema.json
agent-card.schema.json
presence-record.schema.json
mission.schema.json
group.schema.json
membership.schema.json
conversation.schema.json et message.schema.json
work-contract.schema.json et work-item.schema.json
artifact.schema.json et evidence.schema.json
lease.schema.json
approval.schema.json
context-package.schema.json
group-snapshot.schema.json
extension-profile.schema.json
first-admission-record.schema.json
error.schema.json

22. Conformité et preuve de concept requise

Une implémentation est conforme à MissionWeaveProtocol 0.1 uniquement si :

valide chaque objet durable par rapport aux schémas normatifs ;
transmet les 58 vecteurs structurels dans conformance/manifest.json, comprenant 27 documents attendus valides et 31 documents attendus invalides ;
réussit chaque évaluation dans cryptography/manifest.json, couvrant les neuf profils de schéma dans le profil de vérification Signed Document et leurs octets de signature canoniques, hachages, liaisons de clés et signatures ;
réussit les 30 évaluations dans le admission/manifest.json indépendant ensemble comportemental, couvrant la première admission et la répétition historique de cinq cas ;
applique toutes les transitions Mission et WorkItem ;
démontre la relecture, la déduplication, la concurrence optimiste et le cloisonnement ;
démontre l’autorisation et l’invariant Message/non-autorité ; et
réussit les tests de récupération après échec sans accepter les côtés obsolètes ou en double effets.

Pour le bundle de cryptographie, manifest.fixtureSchemas identifie les schémas normatifs Registry-fixture et test-only signature-key-fixture. Un exécuteur MUST valide chaque appareil par rapport au schéma nommé avant d’appliquer les étapes sémantiques déclarées. Pour vérifier artifactDigest, un exécuteur MUST supprime exactement le membre artifactDigest de niveau supérieur, sérialise le manifeste restant avec RFC 8785 JCS, hachez ces octets avec SHA-256 et comparez sha256: suivi des 64 chiffres hexadécimaux minuscules. Chaque hachage d’artefact déclaré s’applique aux octets exacts du fichier.

Pour le bundle d’admission, manifest.fixtureSchemas identifie les schémas d’appareils First-Admission Record et Registry, et manifest.cryptography.artifactDigest épingle le bundle de cryptographie inchangé utilisé par chaque évaluation. Son artifactDigest est calculé avec la même procédure de suppression de membre de niveau supérieur, RFC 8785 JCS et SHA-256. Un exécuteur MUST vérifie tous les octets et hachages d’artefact d’admission déclarés, le résumé de cryptographie épinglé et chaque fichier référencé avant d’exécuter les résultats de l’adaptateur déclarés.

La réussite de missionweaveprotocol-conformance ou des vecteurs de Schema du dépôt démontre uniquement la conformité des Schema et des vecteurs. Il s’agit d’une preuve nécessaire mais non suffisante de la conformité complète au protocole. La réussite de cryptography/manifest.json démontre uniquement les six étapes de vérification cryptographique de la section 6.4. La réussite de admission/manifest.json démontre en outre les évaluations déclarées du First-Admission Record et de la relecture historique, mais elle ne démontre ni la fraîcheur de Command et l’application de la tolérance de décalage d’horloge, ni l’autorisation du signataire selon le rôle et la politique applicables, ni un format de preuve portable pour un Admission Log déployé. Une implémentation MUST prouver ces exigences séparément. Une implémentation de référence MUST revendiquer la conformité complète à MissionWeaveProtocol 0.1 uniquement lorsque les preuves positives et négatives automatisées couvrent chaque type principal de Command et d’Event ci-dessus, ainsi que chaque ligne de transition des sections 7.1 et 10.2 ; sinon, elle MUST signaler explicitement le sous-ensemble vérifié plus restreint.

La preuve de concept de référence v0.1 MUST utilise Python et exécute deux missions de développement logiciel simultanées avec au moins une Worker partagée. Au moins un Mission MUST exerce l’analyse des exigences, la mise en œuvre, les tests, la révision du code, l’intégration et le Approval humain en tant qu’étapes graphiques distinctes. La preuve de concept MUST démontre des files d’attente distinctes par Group, une planification globale pondérée et équitable, une isolation du contexte et des informations d’identification, plusieurs emplacements d’exécution, une préemption sécurisée des points de contrôle, une révision Coordinator et une interface humaine Approval.

Sa suite de défaillance MUST injecte la livraison Event en double, le redémarrage Worker et la reconstruction de la file d’attente, la défaillance Coordinator et le remplacement d’époque, la déconnexion temporaire Group, l’expiration du bail et WorkItem réaffectation, une arrivée hautement prioritaire et une demande de modification humaine. L’implémentation Python est une implémentation de référence, et non une spécification normative.

La preuve de concept MUST rester dans un Organization et une logique Group service. Il MUST NOT nécessitent une fédération, un routage physique peer-to-peer, un consensus distribué, Group un chiffrement de bout en bout ou des profils d’extension personnalisés pour démontrer la conformité de base.

23. Licences

La spécification, les schémas, la suite de conformité et l’implémentation de référence sont sous licence Apache License 2.0. La licence ne confère aucun droit de marque.