ADR 0001: Slack 連携を Socket Mode に統一し Inngest を廃止する
この ADR は置換されました
前提としていた「Slack 連携は Socket Mode 統一」規約が noisy-crow-app の単一 Worker 化（HTTP Events API 移行・Container 常駐廃止）で変わったため、ADR 0006 で HTTP Events API + 単一 Worker 構成に置き換えた。Inngest 廃止の決定は 0006 に引き継がれている。
Context
移行元の tied-bot は Next.js の HTTP webhook (/api/slack/events) で Slack イベントを受け、非同期処理を Inngest に委譲していた。これは以下の依存・制約を持ち込む。
- 公開 HTTP エンドポイント（署名検証・URL 公開・ngrok 等のトンネリング）が必要。
- Inngest（外部 SaaS）への依存と、そのイベントキー / 署名鍵の管理。
- Vercel ホスティング前提の構成。
一方 tied-workspace の既存規約は「Slack 連携は全て Socket Mode。HTTP webhook は使わない」であり、suteki-bot / apps/slack が Bolt Socket Mode コンテナとして稼働している。Cloudflare ファーストパーティで完結させる方針とも合致する。
Decision
- Slack 連携は Bolt の Socket Mode (WebSocket) に統一する。公開 HTTP エンドポイントは作らない。
- Inngest を廃止する。非同期処理は「コンテナ内処理」と「Cloudflare Queue + Consumer」に置き換える（詳細は ADR 0003）。
- ホストは Cloudflare Containers（Bun ランタイム）。Worker shim + Durable Object のシングルトン構成（
idFromName("singleton")）とし、suteki-botの運用パターン（ヘルスサーバ先起動・起動リトライ・keepalive cron）を踏襲する。
Consequences
- 良い点: 公開エンドポイント・署名検証・外部 SaaS（Inngest）が不要になり、運用面・セキュリティ面が単純化。既存 bot と同一の運用ノウハウを再利用できる。
- 悪い点 / 注意: Socket Mode は同一トークンの多重接続で問題が出るため Container はシングルトン必須。Slack App に App-Level Token (
SLACK_APP_TOKEN) の発行と Socket Mode 有効化が必要。長時間接続の安定運用のため keepalive cron とヘルスチェックが前提。 - フォローアップ: Slack App 設定（Socket Mode ON、
connections:writeスコープ、App-Level Token 発行）を運用ドキュメントに追記する。
Alternatives
- HTTP webhook を維持: Cloudflare Workers で受ける案。署名検証は可能だが、既存規約（Socket Mode 統一）から外れ、bot ごとに公開エンドポイントが増える。却下。
- Inngest を継続利用: 外部依存と Vercel 前提を残すことになり「Cloudflare で完結」方針に反する。却下。