Github::Notification
Inherits JSON::Serializable < Reference < Object
Constants
「一度きりの出来事」を指す reason 向けの、2 回目以降の文言。
GitHub の reason は「そのスレッドを購読している理由」であってイベント種別 ではないため、一度レビュー依頼やアサインを受けた PR / Issue は、以降のコメントや 更新もすべて同じ reason で届く。REASON_MESSAGES だけだと常に「レビューを依頼 されました」「アサインされました」になり通知理由が実態と合わないので、 初回ではないと判断できる通知は文言を差し替える（issue #104）。
何が起きたか（コメントか push か状態変更か）は通知 payload から判別できない ため、文言はコメントに限定せず「動きがありました」に留める。 ここに reason を足せば他の reason にも同じ切り替えを適用できる。
切り替えの判定は Subject#commented? だけでは足りず、本文取得で得た subject 本体のコメント数も併用する（issue #116。詳細は followup? のコメント）。
reason（なぜ自分に通知されたか）ごとの表示文言。以前は update? に応じた 「更新があったみたいです」の一辺倒で通知理由が伝わらなかったため、reason を 文面に反映する（issue #96）。GitHub 側の reason 追加に耐えるよう、 未知の reason は reason_message で汎用文言にフォールバックする。
Constructors
Instance methods
CI などの自動チェックの状態でメンションを抑止する対象か（issue #105）。
レビューできる状態になっていない PR で @channel / @everyone を撃たない
ことが目的なので、PR の通知はすべて対象にする。
当初は mention / team_mention を「人が明示的に呼んだ」ものとして対象外に していたが、reason は購読理由であってイベント種別ではないため（FOLLOWUP_MESSAGES のコメント参照）、一度メンションされた PR はその後の push やコメントでも reason=mention のまま届く。これを対象外にすると、最も関与している PR でこそ チェックが赤いままチャンネル全体を叩いてしまい本末転倒なので、reason による 例外は設けない（PR #107 レビュー指摘）。
実際に今回の更新がメンションだったかは通知 payload からは判別できない。
メンションされた通知自体は従来どおり届き、@channel が付かなくなるだけ。
一目で対象が分かるよう owner/repo#番号 タイトル 形式にする。
番号が取れない（Commit など）場合はタイトルのみ、リポジトリ名が無ければ
番号のみにフォールバックする（issue #96）。
対象へ飛べるリンク。コメントの html_url を優先し、無ければリポジトリの html_url にフォールバックしてリンク無し通知を無くす（issue #96）。
通知の pretext（bot のセリフ）。[<type>] <reason 文言> 形式。
detail は reason_message にそのまま渡す（issue #116）。
reason に対応する文言。detail には本文取得で得た subject 本体（PR / Issue）を 渡す。コメントの有無の判定に使うだけなので、渡さなければ従来どおり Subject#commented? のみで判定する。