承認ワークフロー

承認は通常、公開ツールの外で行われます。スクリーンショットがクライアントに送られ、クライアントが「はい」と返信し、それから文面が変わります。承認は今や誰も持っていない下書きを指しており、ツールはそれを知らないため、最後に渡されたものをそのまま公開してしまいます。

• 承認はレビューされたまさにその内容に紐付けられます。承認済みの下書きを編集すると承認は無効になり、どのフィールドが変わったかが示されます。古い判断が静かに引き継がれることはありません。
• レビュアーは承認、変更依頼、却下ができ、承認以外はコメントが必須のため、著者は何を直すべきか分からないままになることがありません。
• このルールは共有アプリケーション層に存在するため、Webアプリ、REST API、MCPサーバー、CLI、Webhookのすべてがこれに従います。レビューを回避できる近道を持つ画面はありません。

承認状態、レビュー画面、再承認ルール、その背後の監査イベントは構築済みです。構築されていないのは最後のステップです。コネクターが完成定義を満たしていないため、承認済みの投稿にはまだ行き先がありません。

機能マトリックスにはすべてのプラットフォームとすべての機能が1つの表にまとまっています。ユースケースページでは、この製品が構築対象としているワークフローを説明しています。

ユースケース

プラットフォームごとの予定

プラットフォームの機能