2026 OpenClaw MeshMac 實戰：Mattermost Incoming Webhook廣播多節點建置狀態的最小可複現步驟

痛點速覽：① 節點直連 Webhook 導致同一建置多條通知；② 密鑰 bake 進映像檔難稽核；③ 未去重的成功／失敗交替洗版。

先在邊界暴露單一 TLS 端點（或既有反向代理），WAF 允許 POST 與 application/json。Mattermost 後台「整合」→「Incoming Webhook」建立連結，取得含 token 的完整 URL；網關出站時 body 使用官方慣例欄位（如 text 或 attachments），並以 username／icon_url 區分環境前綴（例：staging-buildbot）。勿讓 Runner 直接持有該 URL。

1. 關聯鍵：CI 產生 build_id／correlation_id，寫入共享佇列（佈局可參考 部署與佇列同步）。
2. 節點上報：各 MeshMac 僅向網關送 mesh_node_id、workflow、state、commit、run_url，不直連 Mattermost。
3. 滑動視窗：網關以約 30～60 秒視窗摺疊同 build_id 的細粒度事件，保留最後一次「進行中／成功／失敗」。
4. 冪等出站：以 build_id 加 state 為鍵，僅在狀態變更時呼叫 Webhook；避免成功訊息被重試成雙行。
5. 健康與重試：出站遇 429／5xx 採指數退避＋抖動；與 多節點通知加固中的重試策略對齊。

可引用基準：視窗上限建議 60 秒內合併；重試上限 3～5 次；單一建置單頻道單時間軸為預設。

將入站驗證（HMAC、長隨機標頭或 mTLS 用戶端憑證）與 Mattermost Webhook URL 分檔存放，檔案權限 0440、目錄僅 root／網關帳號可列。網關行程啟動時載入，嚴禁將 Webhook 字串注入 Runner 環境變數預設值。輪替時採雙讀重疊：新舊 token 並存一個 TTL 後再刪舊檔。進階可對照 節點秘密最小權限與 IM 綁定與權杖輪替。

問：HTTP 200 但頻道空白？
答：確認 URL 未截斷、未混用「訊息輸入 API」與 Incoming Webhook；在伺服器端以 curl -v 重放完全相同 body。檢查頻道是否存檔或機器人被移出。

問：403／401？
答：多為 token 被管理員重設或複製到剪貼簿時遺失查詢字串；更新密鑰檔後重啟網關，避免舊行程快取 URL。

問：429 或間歇失敗？
答：Mattermost 與反向代理皆有速率限制；下調並發出站、拉長退避，並在網關側做全域權杖桶，與多節點 burst 解耦。

問：與 Slack／Teams 做法差在哪？
答：語意皆為「網關向聊天 URL 出站」，差在 JSON 欄位與附件格式；可併讀 Teams 篇對照表格式。

把 Mattermost 當成狀態廣播尾端而非 Runner 相依套件，就能在 MeshMac 池維持單一時間軸與可稽核密鑰面。若佇列仍塞車，應先檢視節點槽位與網關限流，再考慮加節點或拆環境頻道。

MeshMac 公開頁可免登入瀏覽：購買／方案、首頁、幫助中心、OpenClaw 專欄、部落格列表。