重要度の高い（メンション対象の）通知を見分けることが出来るようにする

[limit7412]

メンションのある通知とそうでない通知を分割して投稿するとか？

決めたこと

同一チャンネルのまま、メンション対象かどうかが切り替わる位置で投稿を区切る（コメントの案C）。
並べ替えはしないので、通知は更新時刻の昇順のまま届き、投稿の境界だけが増える。

古い順に「通常・メンション・メンション・通常」と届いた実行なら、投稿は「通常 1 件」「メンション 2 件」「通常 1 件」の 3 つになる。
これで @channel の付く投稿には自分宛ての通知だけが入る。

検討した他の案は以下。

• 案A（別チャンネルへ分離）: 環境変数 MENTION_WEBHOOK_URL を足してメンション対象だけ別チャンネルへ送る。骨格は案Cと同じで、後から拡張できる
• 案B（同一チャンネル内の強調）: 🔴 マークと赤色を付ける。流量は変わらないため単独では埋もれる。案Cと併用はできる

区切りの判定には reason だけを使い、CI によるメンション抑止（#105）は反映しない。
抑止は「レビューできない PR でチャンネル全体を叩かない」ためのもので、通知の重要度を下げるものではないため。
CI が赤い PR では @channel だけが抑止され、投稿はメンション対象側に入る。

状況

#122 で実装済み（CI green、レビュー指摘は対応済み）。

• Notify::Message#important? を追加し、Github::Usecase で reason から設定する
• Notify::Usecase#send_split が important? の連続区間ごとに投稿する。既読化に渡る累計は分割前と一致させている（Discord 分割送信の途中失敗時に通知が重複投稿されうる（既読化の atomicity） #94 / last_read_at 既読化の境界が排他的で、最新の通知が既読にならず毎分再送される #100 の前提を保つ）
• 副次的に、Discord の @everyone がメンション対象の区間のチャンクにだけ付くようになった

派生した対応。

• Slack の webhook 応答を検査していなかった問題を feat: メンション対象の通知を別の投稿に分けて送る #122 で同時に修正した。分割で投稿数が増えるぶんレート制限に当たりやすくなり、送信できていない通知が既読化される可能性が上がっていた
• 再送ロジックが Slack と Discord で重複した点は Slack と Discord で重複した webhook 再送ロジックを整理する #123 に切り出した

案B（🔴 マーク・赤色）は入れていない。
投稿の区切りだけで見分けが足りるか使ってみてから判断する。

[limit7412]

実装プランを立てました。

現状の整理

• reason が MENTION_REASONS（assign / author / comment / invitation / mention / team_mention / review_requested）に含まれる通知がメンション対象で、Slack では pretext 先頭に <!channel>、Discord では content 先頭に @everyone が付く。
• ただし PR の通知は、CI チェックが失敗中・実行中だとメンションが抑止される（CI、自動チェックが成功していないPRをメンション対象から外す #105）。
• 送信は updated_at 昇順の 1 パスで行い、チャンク送信が成功するたび「先頭からの累計送信件数」を境界に既読化する（Discord 分割送信の途中失敗時に通知が重複投稿されうる（既読化の atomicity） #94 / last_read_at 既読化の境界が排他的で、最新の通知が既読にならず毎分再送される #100）。
  この「昇順の先頭プレフィックスだけが送信済み」という前提が、途中失敗時の重複防止を支えている。

メンション対象もそれ以外も同じチャンネルに時系列で混ざって流れるため、重要な通知が埋もれる。
これがこの issue の課題と理解している。

方針の比較

• 案A：送信先の分離（推奨）：オプションの環境変数 MENTION_WEBHOOK_URL を追加し、設定時はメンション対象の通知だけを別チャンネルへ投稿する。
  未設定なら現状どおり全件を WEBHOOK_URL へ送る（後方互換）。
• 案B：同一チャンネル内の強調：メンション対象だけ色や絵文字を変える。
  実装は最小だが、流量は変わらず埋もれる問題が残るため、本文の「分割して投稿」という意図には届かない。
• 案C：同一チャンネルへ 2 投稿に分割：メンション対象を先にまとめて投稿すると updated_at 昇順が崩れ、プレフィックス既読化の前提が壊れる。
  順序を保ったまま分割するなら案Aと同じ仕組みが必要になり、その割に流量の分離という利点が得られない。

案Aで進めたい。

設計

振り分けの判定は reason で行う

Notify::Message に important フラグを追加し、Github::Usecase#build_message で CI ゲートを掛ける前の Notification#mention?（reason ベース）を設定する。
既存の mention フラグ（@channel 付与）は CI ゲート込みの現行ロジックのまま変えない。

mention で振り分けない理由は、CI が赤い review_requested 通知が通常側チャンネルへ落ちてしまうからである。
CI ゲート（#105）は「レビューできない PR で @channel を撃たない」ための抑止であって、通知の重要度を下げるものではない。
@channel の抑止と送信先の振り分けは別の関心として分ける。

Notify::SplitPostRepository を追加する

primary / mention の 2 つの Notify::PostRepository を包む新しい実装を src/notify/ に置く。

• messages を updated_at 昇順のまま走査し、important が同じ値で連続する run ごとに委譲先の send_messages を呼ぶ。
• 内側の yield（run 内の累計）に外側の累計を足して yield し、mark_read_through のプレフィックス前提を保つ。
• run 途中の失敗は例外をそのまま伝播させ、「既読化は成功分まで、残りは次回再送」という既存の性質を維持する。

Slack は現在全件を 1 投稿で送るが、この方式では run ごとの投稿になる。
重要・通常が交互に届く実行では投稿数が増えるが、毎分実行で 1 回あたりの件数は少ないため許容する。

組み立てと設定

• main.cr：MENTION_WEBHOOK_URL が設定されていれば build_poster で mention 側 poster を作り、SplitPostRepository で包む。
  NOTIFY_MODE は両送信先に共通で適用する（Slack と Discord の混在はさせない）。
• アラート（ALERT_WEBHOOK_URL）は対象外。
• README に環境変数と挙動を追記する。

作業項目

1. Notify::Message に important を追加し、Github::Usecase で設定する（spec 含む）
2. Notify::SplitPostRepository を追加する（run 分割・累計 yield・途中失敗時の挙動の spec）
3. main.cr の組み立てと README 更新

1 本の PR で進め、上記単位でコミットを分ける。

確認したい論点

• MENTION_REASONS には comment / author も含まれる。
  振り分けもこの集合のままでよいか、mention / team_mention / review_requested あたりに絞るか。
  初回は現行集合のまま進め、絞り込みが必要なら別 issue にするつもりでいる。
• 分離先チャンネルへの投稿にも現行ロジックどおり @channel が付く。
  専用チャンネルなら Slack 側の通知設定で制御できるため、まずはこのままとしたい。

---

Generated by Claude Code

[limit7412]

案B（同一チャンネル内での強調）で方法を具体化しました。
こちらで進める場合、前コメントの案Aのプランは破棄します。

方法

メンション対象の通知だけ、見た目を 2 点変える。

• pretext へのマーク付与：reason 文言の先頭に 🔴 を付ける。
  例：🔴 [PullRequest] レビューを依頼されました（@channel 付きなら <!channel> 🔴 [PullRequest] …）。
• 色の上書き：attachment / embed の色を type 別の色ではなく赤系の固定色（#E01E5A を想定）にする。
  Slack の左バーはチャンネルを流し読みするときに最も目に入る要素なので、ここを赤にするのが埋もれ対策として効く。

どちらも Notify::Message の既存フィールド（pretext / color）に乗るため、Slack / Discord の両アダプタに変更なしで効く。
Discord では pretext が content 行として出るので、マークもそのまま表示される。

判定は reason で行う

強調するかどうかは Notification#mention?（reason ベース）で判定し、CI ゲート（#105）は掛けない。
CI が失敗中・実行中の PR では従来どおり @channel だけが抑止され、🔴 と赤色は付いたままになる。
「チャンネル全体は叩かないが、自分宛てであることは見分けられる」という状態が作れるので、CI ゲートと今回の強調は補完関係になる。

実装

判定に使う mention? と pretext の組み立てが Github::Notification に既にあるため、変更は github 層で閉じる。

# src/github/models.cr（Notification）
IMPORTANT_MARK  = "🔴"
IMPORTANT_COLOR = "#E01E5A"

def pretext(detail : Comment? = nil) : String
  base = "[#{subject.type}] #{reason_message(detail)}"
  mention? ? "#{IMPORTANT_MARK} #{base}" : base
end

# type 別の色（Subject#color）を包み、メンション対象なら赤系に上書きする。
def color : String
  mention? ? IMPORTANT_COLOR : subject.color
end

Github::Usecase#build_message は notify.subject.color の参照を notify.color に変えるだけ。
notify 層・アダプタ層・main.cr・serverless 設定は無変更で、送信順序と既読化（#94 / #100 のプレフィックス前提）にも一切触れない。
案Aと比べたときの案Bの利点はここにある（環境変数の追加も投稿数の増加もない）。

作業項目

1. Notification#pretext へのマーク付与と Notification#color の追加（models_spec）
2. Github::Usecase#build_message の色参照の差し替え（usecase_spec。CI 赤で mention が折れても強調は残るケースを含む）
3. README のメンション節に見分け方を追記

1 本の PR で進め、上記単位でコミットを分ける。

確認したい論点

• マークの絵文字は 🔴 を想定しているが、📣 ‼️ など好みがあれば合わせる。
• 色の上書きは「PR はピンク、Issue は青」という type 別の色分けをメンション対象に限り失うトレードオフがある。
  type は pretext の [PullRequest] 表記で読み取れるため許容できると考えているが、type 色を残したければマークのみ（色は現状維持）に落とす。
• 強調対象の reason 集合は案Aと同じ論点で、現行の MENTION_REASONS（comment / author を含む）のまま進め、絞り込みが必要なら別 issue とする。

---

Generated by Claude Code

[limit7412]

案C（同一チャンネルへの分割投稿）を、時系列維持を前提に検討しました。

前コメントで案Cを退けた理由と、その解消

前コメントの案Cは「メンション対象を先にまとめて 1 投稿にする」形を想定しており、updated_at 昇順が崩れてプレフィックス既読化（#94 / #100）の前提が壊れる、というのが退けた理由だった。
時系列を維持するなら、まとめ方を変えればこの問題は消える。

全体を updated_at 昇順に並べたまま、メンション対象かどうかが切り替わる位置で投稿を区切る（以下、この連続区間を run と呼ぶ）。
たとえば通知が古い順に「通常・通常・メンション・メンション・通常」なら、投稿は「通常 2 件」「メンション 2 件」「通常 1 件」の 3 つになる。
チャンネル上の並びは今までどおり時系列で、投稿の境界だけが増える。

これで得られるもの：

• @channel が付く投稿にはメンション対象の通知しか入らないため、「何に呼ばれたのか」が投稿単位で切り分けられる。
  Slack のメンションバッジからのジャンプ先も、メンション対象だけを含む投稿に正確に着地する。
• run は昇順配列の連続区間なので、「送信済みは常に先頭からのプレフィックス」という既読化の前提がそのまま保てる。

実装

Notify 層にデコレータを 1 つ足す

Notify::PostRepository を包むデコレータ（Notify::SplitPostRepository）を追加する。

• send_messages で messages を先頭から走査し、important が同じ値で連続する run ごとに、内側の poster の send_messages を呼ぶ。
• 内側の yield（run 内の累計）に、それまでの run の合計件数を足して yield する。
  mark_read_through から見える値は従来と同じ「先頭からの累計」になる。
• run 途中の失敗は例外をそのまま伝播させる。
  送信済み run は yield 済みで既読化されているため、次回は未送信分だけが再取得される（現行の分割送信と同じ性質）。

判定に使う important は、案A・案Bと同じく Notify::Message に追加する reason ベースのフラグ（CI ゲート #105 は掛けない）。
CI が赤い PR もメンション対象側の run に入り、@channel だけが従来どおり抑止される。

組み立て

main.cr で既存の poster をデコレータで包むだけにする。
環境変数は追加しない。
メンション対象が 1 件も無い実行では run が 1 つになり、投稿のされ方は現状と完全に一致する。

アダプタへの影響

Slack / Discord のアダプタは無変更。

• Slack：現在は全件 1 投稿だが、run ごとの投稿になる。
  通常・メンションが交互に届く実行では投稿数が増える（最悪で通知件数ぶん）。
  毎分実行で 1 回あたりの件数は少ないため許容できると考えている。
• Discord：run 単位で渡した後、既存の 10 embeds / 6000 文字のチャンク分割がその中で行われる。
  @everyone はメンション対象の run のチャンクにだけ付くようになり、むしろ現状（チャンク内に 1 件でもあれば付く）より正確になる。

作業項目

1. Notify::Message に important を追加し、Github::Usecase で設定する（spec 含む）
2. Notify::SplitPostRepository を追加する（run 分割・時系列維持・累計 yield・途中失敗の spec）
3. main.cr の組み立てと README 更新

1 本の PR で進め、上記単位でコミットを分ける。

案A・案Bとの関係

• 実装の骨格（important フラグ＋run 分割）は案Aと同一で、違いは委譲先が 1 つか 2 つかだけ。
  後から別チャンネルに分けたくなったら、デコレータに 2 つめの poster と環境変数を足すだけで案Aへ拡張できる。
• 案B（🔴 マーク・赤色）とは独立に併用できる。
  投稿の区切りだけでは流し読み時の視認性が足りなければ、案Bを重ねる選択肢が残る。

確認したい論点

• 投稿数の増加（run 数ぶん）を許容できるか。
• run の区切りだけで十分見分けられるか、案Bの強調も重ねるか。
• 強調対象の reason 集合は案A・案Bと同じ論点（現行の MENTION_REASONS のまま進め、絞り込みは別 issue）。

---

Generated by Claude Code

[limit7412]

案Cで実装し、#122 を作成しました（draft）。

プランからの変更が 1 点あります。
Notify::SplitPostRepository というデコレータを notify 層に足す設計はコンパイルできなかったため、Notify::Usecase#send_split に置く形にしました。

デコレータは自身も Notify::PostRepository なので、委譲先の静的型にデコレータ自身が含まれます。
Crystal は yield するブロックを常にインライン展開するため、その展開が無限再帰します（Error: recursive block expansion）。
置き場所としても、累計の正しさは既読化の境界と表裏なので、mark_read_through と同じファイルにあるほうが不変条件を追いやすくなりました。
環境変数の追加も main.cr の変更も不要です。

動作は当初の案どおりで、投稿は important? が切り替わる位置で区切られ、通知は updated_at 昇順のまま届きます。

先のコメントで挙げた確認したい論点のうち、以下は現状の実装で決め打ちにしています。
気になる点があれば PR 側で指摘してください。

• 区切りの判定は reason のみ（CI によるメンション抑止 CI、自動チェックが成功していないPRをメンション対象から外す #105 は反映しない）。CI が赤い PR は @channel だけ抑止され、投稿はメンション対象側に入る
• 対象の reason は現行の MENTION_REASONS のまま（comment / author を含む）。絞り込みが必要なら別 issue とする
• 案B（🔴 マーク・赤色）は入れていない。区切りだけで足りるかを見てから判断したい

---

Generated by Claude Code