拡張機能、エラー、制御、および適合性

18. 拡張プロファイル

開発者 MAY は、Organization で承認された拡張プロファイルを通じてカスタムコマンド、イベント、データを定義します。各プロファイル MUST は、グローバルに一意のプロファイル URI、セマンティックバージョン、スキーマ URI とハッシュ、必要な機能、重要度、および Organization 承認署名を宣言します。 Group は、使用するプロファイルのサポートされているメジャーバージョンを固定します。

拡張機能の種類 MUST は、プロファイルによって定義された ext.<organization>.<profile>.<name> 名前空間を使用します。未知の非クリティカル拡張子 MAY は、解釈せずに保持および中継されます。 Agent MUST は、不明な重要なプロファイルに依存する移行への参加を拒否します。

Extension Profile MUST NOT オーバーライドまたはアイデンティティの弱体化、Membership、Event 順序付け、冪等性、Session Epoch、所有権エポック、リース、予算、 Approval、Artifact 来歴、Mission 分離、またはメッセージがアクションを許可しないというルール。

19. エラー

エラー MUST は schemas/error.schema.json に準拠します。エラー応答 MUST は機械可読で、再試行が安全かどうかを MUST 示し、未認可データを開示せずに関連する frame または Action ID を SHOULD 識別します。コアエラーコードは次のとおりです。

コード	意味
`UNSUPPORTED_VERSION`	互換性のあるプロトコルバージョンがありません
`AUTH_REQUIRED`	認証がありません
`AUTH_INVALID_SIGNATURE`	Signed Document の署名、key validity、Admission proof、または freshness 検査が失敗
`AUTH_STALE_SESSION`	Session Epoch はフェンスで囲まれています
`AUTH_STALE_COORDINATOR`	Coordinator エポックはフェンスで囲まれています
`AUTH_FORBIDDEN`	アクターには許可またはポリシーの資格がありません。
`GROUP_NOT_FOUND`	Group が存在しないか、意図的に非公開です。
`MEMBERSHIP_REQUIRED`	該当なし Membership
`MEMBERSHIP_STALE`	Membership エポックはフェンスで囲まれています
`SCHEMA_VALIDATION_FAILED`	オブジェクトがそのスキーマに準拠していません。
`INVALID_COMMAND`	Command は整形式ですが、意味的には無効です。
`INVALID_STATE_TRANSITION`	集約状態は遷移を禁止します
`REVISION_CONFLICT`	予期されたリビジョンが一致しません
`ACTION_ID_COLLISION`	安定したアクション ID が別のコンテンツで再利用されました
`UNKNOWN_CRITICAL_EXTENSION`	必要な拡張子を解釈できません。
`WORK_CONTRACT_INCOMPLETE`	必要な作業契約情報が欠落しています
`WORK_OFFER_EXPIRED`	オファーはもう有効ではありません
`WORK_ALREADY_OWNED`	別の候補者が独占的所有権を獲得
`WORK_LEASE_EXPIRED`	必要なリースはもう有効ではありません
`WORK_STALE_OWNERSHIP`	所有権エポックは囲われています
`APPROVAL_REQUIRED`	ポリシーゲートが満たされていません
`BUDGET_EXCEEDED`	Mission または WorkItem のハード budget が枯渇
`RATE_LIMITED`	ポリシーレートまたは再帰のしきい値に達しました
`BACKPRESSURE`	受信機は現在、これ以上のトラフィックを受け入れることができません。
`CURSOR_TOO_OLD`	オンライン再生には要求された位置が含まれなくなりました
`PROTOCOL_VIOLATION`	ピアがフレーミングまたはコアの不変条件に違反しました。
`INTERNAL_ERROR`	権限は移行を受け入れずに失敗しました

変更されていない Command の再試行は、元の Action ID と署名内容を保持しなければなりません（MUST）。AUTH_INVALID_SIGNATURE は、原因が修正される前に同じ内容で再試行してはなりません（MUST NOT）。署名エンベロープ、権威ある key、または Admission 状態をローカルで修正した後、保護された内容がすべて有効な間に限り、送信者は元の Action ID で再試行できます（MAY）。Command freshness が期限切れの場合、送信者は代わりに、新しい Action ID、現在の issuedAt、対応する signature.createdAt、および新しい署名を持つ新しい Command を作成しなければなりません（MUST）。ACTION_ID_COLLISION には、新しい Action ID を持つ新しい Command が必要です。古い fencing error では、現在の権威ある Epoch と、新しい Action ID および署名を持つ新しい Command が必要です。

20. レート、再帰、暴走制御

Organization ポリシー MUST は、Message および提案レート、未解決の明確化ラウンド、アクティブおよびキューに入れられた作業項目、委任の深さ、トークン/時間/財務予算、および循環または重複分解の制限をサポートします。これらの制御 SHOULD は、固定の低いプロトコル上限ではなく、ソフトしきい値、Coordinator 通知、および明示的なエスカレーションを使用します。

実装 MUST は循環委任または Mission 祖先を拒否します。正当な作業にさらに深度、予算、または料金が必要な場合、Coordinator はポリシーまたは MissionOwner の承認を要求し、付与後に継続することができます。ポリシー制限 MUST NOT は、受け入れられた作業をサイレントに破棄します。

協力制限エスカレーション MUST は、注入されたブール値、ローカルコールバック結果、または再利用可能な除外ではなく、永続的なワンショット 協力オーバーライド許可 によって表されます。付与 MUST は、Mission、Group、ポリシー名、受益者 Principal、ターゲット Command の種類、ターゲットアクション ID、理由、承認者、付与時刻、および有効期限をバインドします。 MissionOwner または認可された Organization ポリシーアクターのみが発行できます。ターゲット Command MUST は、cooperationOverrideGrantId エンベロープメンバーで付与 ID を引用します。

ターゲット遷移を受け入れる前に、Group Authority MUST は、引用された付与が存在すること、期限切れおよび消費されていないこと、および Command の Mission、Group、アクター、種類、アクションと正確に一致することを検証します。 ID、およびポリシーを超過しました。 MUST は、ターゲットの遷移が受け入れられた場合にのみ、許可をアトミックに消費します。発行と消費 MUST の両方が信頼できるポリシーログに追加され、消費は受け入れられた Event にリンクされます。受け入れられた同じ Command を冪等で再試行すると、以前の Event が返されます。許可 MUST をその他に使用しようとすると失敗します。

21. スキーマとバージョンの互換性

すべての v0.1 スキーマは、JSON スキーマドラフト 2020-12 を使用します。コアオブジェクトセット additionalProperties: false;拡張性は、明示的な extensions メンバーと承認されたプロファイルを通じてのみ発生します。 MUST 実装では、可能であれば、未知の非クリティカル拡張バイトと同等の正規リレーを保存します。

ワイヤ protocolVersion は 0.1 です。下位互換性のあるスキーマの明確化により、ワイヤのバージョンを変更せずに仕様のパッチのバージョンが増加します。コアセマンティクスまたは必須フィールドを変更する変更には、新しいワイヤーマイナーバージョンまたはメジャーバージョンとハンドシェイクネゴシエーションが必要です。

22 の規範的なスキーマは次のとおりです。

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 および message.schema.json
work-contract.schema.json および work-item.schema.json
artifact.schema.json および 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. 適合性と必要な概念実証

実装は、次の場合にのみ MissionWeaveProtocol 0.1 に準拠します。

すべての耐久性のあるオブジェクトを標準スキーマに対して検証します。
conformance/manifest.json 内の 27 個の構造ベクトルを含む 58 個の構造ベクトルをすべて渡します。有効と予想される文書と無効と予想される文書 31 件。
cryptography/manifest.json のすべての評価に合格し、9 つすべてをカバーします Signed Document 検証プロファイル内のスキーマプロファイルとその正規署名バイト、ハッシュ、キーバインディング、および署名。
独立した admission/manifest.json の 30 件の評価すべてに合格します。このアドミッションバンドルは、5 件のケースにわたる初回アドミッションと履歴リプレイを対象とします。
すべての Mission および WorkItem 遷移を強制します。
リプレイ、重複排除、オプティミスティック同時実行性、およびフェンシングを示します。
認可と Message/non-authority の不変式を示します。そして
古い側または重複した側を受け入れずに障害回復テストに合格します。効果。

暗号バンドルの場合、manifest.fixtureSchemas は、標準の Registry フィクスチャスキーマとテスト専用署名キーフィクスチャスキーマを識別します。ランナー MUST は、宣言されたセマンティックステージを適用する前に、名前付きスキーマに対して各フィクスチャを検証します。 artifactDigest を検証するには、ランナー MUST が最上位の artifactDigest メンバーを正確に削除し、残りのマニフェストを RFC 8785 JCS でシリアル化し、それらのバイトを次のようにハッシュします。 SHA-256 を比較し、sha256: に続く 64 個の小文字 16 進ダイジェスト桁を比較します。宣言された各アーティファクトハッシュは、正確なファイルバイトに適用されます。

Admission バンドルの場合、manifest.fixtureSchemas は First-Admission Record および Registry フィクスチャスキーマを識別し、manifest.cryptography.artifactDigest はすべての評価で使用される変更されていない暗号バンドルを固定します。その artifactDigest は、同じ最上位メンバーの削除、RFC 8785、JCS、および SHA-256 プロシージャを使用して計算されます。ランナー MUST は、宣言されたアダプターの結果を実行する前に、宣言されたすべてのアドミッションアーティファクトのバイトとハッシュ、固定された暗号ダイジェスト、およびすべての参照ファイルを検証します。

missionweaveprotocol-conformance またはリポジトリの Schema ベクターに合格しても、Schema とベクターへの適合性だけが証明されます。これは完全なプロトコル適合性のために必要ですが、十分な証拠ではありません。 cryptography/manifest.json への合格は、セクション 6.4の 6 つの暗号検証段階だけを証明します。admission/manifest.json への合格は、宣言された First-Admission Record と履歴リプレイ評価も証明しますが、Command の鮮度とクロックスキューの強制、適用されるロールとポリシーに基づく署名者の認可、またはデプロイ済み Admission Log のポータブルな証明形式を証明するものではありません。実装は、これらの要件を個別に証明しなければなりません（MUST）。参照実装は、自動化された肯定的および否定的な証拠が上記のすべてのコア Command と Event の種類、およびセクション 7.1 と10.2のすべての遷移行を網羅する場合に限り、MissionWeaveProtocol 0.1 への完全適合を主張しなければなりません（MUST）。それ以外の場合は、より狭い検証済みサブセットを明示的に報告しなければなりません（MUST）。

v0.1 参照概念実証 MUST は Python を使用し、少なくとも 1 つの共有 Worker を使用して 2 つのソフトウェア開発ミッションを同時に実行します。少なくとも 1 つの Mission MUST 演習要件分析、実装、テスト、コードレビュー、統合、および個別のグラフステージとしての人間の Approval 。概念実証 MUST は、Group ごとの個別のキュー、グローバル加重公平スケジューリング、コンテキストと資格情報の分離、複数の実行スロット、安全なチェックポイントのプリエンプション、Coordinator レビュー、および人間による Approval インターフェイスを示しています。

その障害スイート MUST は重複した Event 配信の挿入、Worker の再起動とキューの再構築、Coordinator の障害とエポックの置換、一時的な Group の切断、リース期限切れ、およびWorkItem の再割り当て、高優先度の到着、および人間による変更リクエスト。 Python 実装は参照実装であり、標準仕様ではありません。

概念実証 MUST は、1 つの Organization および 1 つの論理 Group サービス内に残ります。 MUST NOT には、フェデレーション、物理ピアツーピアルーティング、分散コンセンサス、Group エンドツーエンド暗号化、またはコア準拠を実証するためのカスタム拡張プロファイルが必要です。

23. ライセンス

仕様、スキーマ、適合スイート、およびリファレンス実装は、Apache License 2.0 に基づいてライセンスされています。このライセンスは商標権を付与するものではありません。