外向きの二系統
| 経路 | 芯 | 向く先 |
|---|---|---|
| 画面 | チャレンジ | 試作 |
| アプリ | 認可検証 | 本番 |
Monday.com Webhook のチャレンジ/認可ヘッダと外向き設定
初回チャレンジを同キーで返す。アプリ経由は認可ヘッダを署名秘密で検証し聴衆と期限を見る。画面のみは保証が弱いので本番はアプリか難読パスと監査の二層へ。
- 手順 1. 専用パス固定と証明書と本文上限の既方針合わせ。
- 手順 2. チャレンジ分岐を最上流へ。
- 手順 3. 秘密はゲートウェイのみ(最小権限)。
- 手順 4. 構築待ち列値のときだけキューへ。
- 手順 5. 冪等は配信識別子かボード識別子とアイテム識別子と分バケット。
OpenClaw ゲートウェイ受信とルーティング
検証後にパースし正規化タスクへ写す。全ノードは同一スキーマ。
- 手順 1. 種別とボード識別子から参照と相関識別子を抜く。
- 手順 2. 冪等確定し永続投入の後に応答(再試行)。
- 手順 3. 秒粒度内部イベントで深度を見せる。
- 手順 4. レート方針へ合わせ余白を残す。
- 手順 5. 失敗要約はゲートウェイのみが短く返す。
多ノード構築状態の合流テンプレート
通知はゲートウェイ一本。識別子と題名とノード識別子と状態と経過と終了コードとログ末尾上限を揃え失敗は一行要約へ。キーは三リリース後方互換で増やす。ログ末尾は二百行か三十二キロの短い方。外向きは構築識別子と結果で去重。
失敗退避と最小権限
送信直列化と指数バックオフ上限とジッタ。短命トークンへ寄せ長寿命個人鍵を廃す。共有 Mac の席は接力で固定。
- 手順 1. 上限超えは人の判断キューへ。
- 手順 2. 認可失効はローテ後に再開。
- 手順 3. 巨大ログは署名付き URL のみ。
安全運用メモ
- 資格情報を生ログに残さない。
- 検証鍵は環境分離とラベル。
- 本文再符号化しない前提で検証を設計。