2026 OpenClaw MeshMac 実践：Linear Webhook で共有ビルド状態をブロードキャストし要約を返す最小再現手順

URL はプール増減で回さないのが Mesh の利点。mesh_node_id は表記用、API／チャット出站はゲートウェイ集約。

1. 手順 1. ゲートウェイに OpenClaw、OPENCLAW_CONFIG_ROOT、LaunchDaemon 等で常駐（プールは再起動しがちなので入口だけ安定）。
2. 手順 2. Linear 用 https://… でリバプロ終端、Webhook パスに本文上限（TLS 入口）。
3. 手順 3. openclaw doctor、GET /health または ヘルスプローブ で LB 排出を確認。
4. 手順 4. correlation_id とキュー遅延をログ化、同時数は レート制限 FAQ に合わせる。共有通知・OpenClaw 特集。

検証→解析の順。Linear は生ボディ署名。先パースは典型失敗要因。

1. 手順 1. Webhook 秘密を 0440 で 最小権限保管（例 …/linear/webhook.secret）。
2. 手順 2. バイト列バッファの上で HMAC-SHA256、Linear-Signature を定数時間比較。リプレイ窓は厳めに。
3. 手順 3. 不一致は 401、メタのみマスク（Teams 通知 と同衛生）。
4. 手順 4. キュー durable 後のみ 200。再送増殖を防ぐ（キュー同期）。

正規化タスク（repo・ref・issue・actor・idempotency_key）。A が忙しくても B が同じ入口を実行、Webhook は増やさない。

1. 手順 1. 対象カラム／ラベルのみ処理、他は早 200。
2. 手順 2. 共有キューへ issue ・チーム・冪等キーで投入（再試行手順）。
3. 手順 3. 全ノード同一エントリ（版固定、worktree）。
4. 手順 4. 完了に mesh_node_id 等を載せゲートウェイが Slack／Chat／Teams へ一斉送信。
5. 手順 5. GraphQL で短コメント返却、キーは最小スコープ・ローテ 同型。

GHA と併用時は Runner ルーティング でレーン分離。

受信と送信の再試行は分離、通知は一本化。

1. 手順 1. durable エンキュー後は速応答。ハンドラ時間は 同時実行 FAQ 内。
2. 手順 2. チャットは 429／一時 5xx のみ指数バックオフ、idempotency_key + state で去重。
3. 手順 3. GraphQL は errors[] ログ、401 はループしない。
4. 手順 4. 両方続けて失敗なら IM、ゲートウェイは LB／FO。

curl は通るが本番だけ署名失敗

実バイト列と curl 本文の差、gzip／WAF を疑う。マスクした生ボディで再検証。

カード移動が速いと二重ジョブ

デバウンスか「ビルド準備」ラベル必須。issue・カラム・短時間窓で冪等キー。

緑ビルドなのにコメントなし

キー権限、issueId、GraphQL errors を確認。

入口はゲートウェイ一台でよいか

はい。秘密と監査を一点に集約し、ノード追加は容量の話に留める。

ゲートウェイ・署名・共有キュー・ブロードキャスト・GraphQL の五点が多ノード最小セット。公開ナビのみ：ホーム、ブログ、ヘルプ、OpenClaw。購入 は下段 CTA。