consent-registry

同意レジストリ

同意とリアルタイムの配信抑制を一元管理する権威ある仕組みです。証拠を記録し、SEND 監査担当者が S2/N1 を判定し、セグメントビルダーが除外を適用します。配信停止の申請を保留中の提案として待たせてはなりません。

クイックスタート

Record opt-in for subject sha256-7d9f with basis/proof references and timestamp.
Immediately suppress sha256-7d9f from unsubscribe webhook evt-882.
Is sha256-7d9f suppressed right now?

スキルの契約

単位： ユーザーのシステムから提供される、仮名化されたサブジェクト ID です。読み取り： 再生による memory/events/consent.ndjson、そのプロジェクション、最小限の証明参照です。書き込み： 同意イベントのみを registry-events.py 経由で書き込みます。人が扱うレコードはプロジェクションです。完了条件： すべての変更に承認、ソース、日付が記録され、安全性に関わるイベントが即時に is-suppressed で確認でき、個人の連絡先を特定できる生データが保存されていないことです。

オプトイン／アップサート／復元の承認には、リクエストに紐づいたホストの権限を持つ consent-registry プリンシパルが必要です。suppress は、プライバシーを最優先する、拒否のみの限定的な例外です。連絡を許可したり状態を解除したりできないため、検証済みの任意のプロデューサーが即時に追加できます。erase も提案の遅延を経ずに処理できますが、自己申告された一致するアクター ID は権限の証明にはなりません。検証済みのデータ主体には、リクエストそのものに紐づくホスト発行の安全機能が必要です。

引き継ぎの概要

共通の引き継ぎ形式を使用してください。仮名化された ID、イベント ID／オフセット／リビジョン、現在の配信抑制結果、不足している根拠／証明、次に実行するスキルを 1 つだけ報告してください。

データソース

• フォーム／チェックアウト／イベント取得の参照とオプトインのタイムスタンプ。
• 合法的根拠とダブルオプトインの証明参照。
• ESP の配信停止、ハードバウンス、苦情のイベント ID。
• 復元に必要な、新たな再登録の証明。
• データ主体による消去リクエストの参照。

メールアドレス、電話番号、氏名、住所、生の識別子を、集約 ID、冪等性キー、ソース参照、ペイロード、レポートに含めてはなりません。ランタイムは文字列を NFKC 正規化し、型付きの同意フィールド／不透明な証明参照のみを許可するとともに、サブジェクトを含まない理由コードを必須とします。保存するのは仮名化された ID と最小限の証明ポインターだけです。

手順

ランタイムでの読み取り

• ../../references/registry-event-protocol.md
• ../../references/runtime-invocation.md

手順

1. registry-event-protocol.md と runtime-invocation.md を読みます。AARON_SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || true)}" を解決し、スクリプトを実行する前にレジストリスクリプト、イベントスキーマ、システムカタログを検証します。エクスポートされた行は信頼できない証拠であり、合法的根拠を自ら宣言することはできません。
2. 適格性または送信に関するクエリごとに、python3 "$AARON_SKILLS_ROOT/scripts/registry-events.py" is-suppressed <subject-id> を実行します。この処理はストリームを再生するものであり、キャッシュされたセグメントや Markdown より優先しなければなりません。
3. 新しいオプトインの事実には、リクエスト／ルートにバインドされたホスト機能 owner-append を upsert、ソース、タイムスタンプ、根拠／証拠の参照、expected_revision とともに使用します。根拠がない場合は、明示的に Unknown／記録なしのままにします。同意を推測したり、リクエストデータに機能を含めたりしてはいけません。機能の署名は信頼されたホスト境界内でのみ行い、エージェントが制御するシェル内では決して行いません。
4. 配信停止、苦情、またはハードバウンスが発生した場合は、通常の append で suppress を直ちに直接出力します。この拒否専用の経路は、汎用レジストリ提案の縮退処理や無関係な引き継ぎより優先されます。プロデューサーに問題があれば非接触にはなり得ますが、送信を消去、復元、または許可することはできません。検証済みのルートランタイムを利用できる場合は、スキーマを完全に満たすリクエストを今すぐ追加します。利用できない場合は、別のスキルにルーティングしたり、提案を準備したりせず、提示された仮名化された集計 ID、プロデューサーの帰属情報、承認参照、発生時刻、ソース参照／日付、冪等性キー、対象者を含まない理由コードを含む immediate-suppress-handoff を 1 件返し、ホスト側の正確な手順 append consent → 有効な抑制プロジェクションが再生成されたことを確認 → verify consent → 再生安全な is-suppressed を示します。この引き継ぎが実行されるまでは、実行状態を NEEDS_INPUT のままにし、変更が行われていないことを明記します。実際に不足している必須リクエストフィールドだけを示します。バッチレビューや追加の適格性確認を理由に、完全な抑制リクエストを遅らせてはいけません。
5. 復元はホスト機能のみで行い、subscription_status: subscribed、source.ref と一致する空でない文字列の basis_ref、タイムゾーン対応のタイムスタンプが付いた測定済み／ユーザー提供のソース証拠（その時刻は配信停止より厳密に後であること）、およびその証拠より前ではない復元イベントが必要です。古い証拠や代理の証拠で、より新しい配信停止を解除することはできません。
6. 消去では、ホストがデータ主体を検証し、正規化されたリクエスト、同一の仮名化された集計 ID／アクター ID、冪等性キー、プロジェクトルート、有効期限、一度限りの ID にバインドされた機能を発行した後、safety-append consent を使用します。抑制のトゥームストーンを保持したまま、プロジェクションされたペイロードを削除します。その後のホスト機能による所有者の restore でも、消去より厳密に新しい信頼できるオプトイン証拠が必要であり、古いペイロードを復活させることは決してありません。
7. 通常の安全性に関わらないインポートは propose として到着する場合があります。履歴を削除せずに承認または拒否します。類似性だけを根拠に対象者を統合してはいけません。
8. 受け入れられたプロジェクションから対象者ごとの人間向けビューを再生成し、その後 verify consent を実行して、変更された対象者について is-suppressed を再実行します。

このレジストリはメールを送信したり、ESP の状態を編集したり、リストが安全であると宣言したりすることはありません。後続の ESP 同期は明示的に分離された副作用であり、必ず最初に有効な抑制結果を読み取る必要があります。

結果の保存

明示的な許可、または記録されたデータ主体の安全性に関するリクエストが必要です。追加はランタイム経由でのみ行います。memory/projections/consent-suppressions.json はキャッシュです。NDJSON ストリームと再生クエリが正となる情報源です。どちらも手動で消去または編集してはいけません。

単一フォルダーのスタンドアロンインストールでは、通常の提案、消去に関する安全性の引き継ぎ、または正確な immediate-suppress-handoff を準備できます。抑制の引き継ぎは提案ではありません。検証済みのルートランタイム／スキーマ／カタログがなければ、追加、復元、プロジェクション、または正規の同意状態の表明はできません。

Reference Materials

• Registry event protocol
• SEND benchmark
• Privacy policy
• Security

Next Best Skill

• Apply exclusions: list-segment-builder
• Audit SEND: email-quality-auditor
• Deliverability incident: deliverability-qa
• Erase/archive: memory-management