Mastodon v4.5.x regression sweep — baseline-drift over a release line

日付: 2026-05-21。Rigor: v0.1.8（master、[Unreleased]）。 対象: mastodon/mastodon、16タグv4.5.0-beta.1→v4.5.10。

ゴール

実際の「通常の開発フロー」に対して2つのことを検証する。

ベースラインを一度だけ取って固定したとき、通常の開発が進むにつれてプロジェクトのRigorエラー件数はどれだけ増えるのか？
rigor-project-initのacknowledgeモード環境はどれだけ現実的か — ADR-22が約束するとおりに振る舞うか（一度だけ採用し、リグレッションのみを表面化する）？

手法: rigor-regression-sweepの手順 — 最初のタグでベースラインを取り、それ以降の各タグを固定したベースライン＋固定した設定に対してrigor checkする。

セットアップ

mastodon/mastodonのblobless clone。リリース順に16タグ: v4.5.0-beta.1, -beta.2, -rc.1, -rc.2, -rc.3, v4.5.0, v4.5.1 … v4.5.10。
固定した設定（すべてのタグで同一に保つ — そうすればデルタは設定ではなくMastodonのコードに帰属させられる）: paths: [app, lib]、exclude: [vendor, tmp]、 severity_profile: lenient、signature_paths:→ rigor-activesupport-core-extのsig/バンドル（絶対パス）。 rigor-*プラグインgemは省く — v0.1.xではRubyGemsに公開されていない（ROADMAP §「Out of scope today」）ため、忠実な外部ユーザー設定はまだそれらを含められない。
v4.5.0-beta.1で生成したベースライン: 診断30件 / バケット25個（ルールIDモード）。
app + lib対象範囲: beta.1で.rbファイル1,218件、v4.5.10で1,219件。

結果 — エラー増加曲線はゼロでフラット

タグ	raw	silenced
v4.5.0-beta.1	30	30
v4.5.0-beta.2	30	30
v4.5.0-rc.1 … -rc.3	30	30
v4.5.0	30	30
v4.5.1 … v4.5.10	30	30

すべてのタグでsurfaced = 0。固定したベースラインがリリースライン全体を吸収した — beta.1→10回のパッチリリースにわたる通常の開発は、解析対象範囲において新規のRigor診断をゼロ件しか持ち込まなかったし、ベースライン化された30件のうち1件も取り除かなかった。

これはno-opによる見せかけの結果ではない。この期間に実際のチャーンが発生している。

app + lib内で.rbファイル119件が変更された（git diff v4.5.0-beta.1 v4.5.10: 603挿入 / 265削除。リポジトリ全体では762ファイル / 1.73万挿入）。
診断を抱えるベースライン化済みファイルのうち6件が編集された — activitypub/activity/create.rb、linked_data_signature.rb、 feed_manager.rb、signature_parser.rb、account.rb、 cli/statuses.rb — そしてそれらの(file, rule, count)バケットは依然として一致した。行の移動はベースラインを壊さなかった。
v4.5.10でのコールドな--no-cache --no-baseline実行が独立してraw = 30（error 9件 / warning 12件 / info 9件）を確認しており、キャッシュによるマスクを排除している。

v4.5.10のraw内訳（beta.1から不変）

重大度	ルール
error ×9	`call.undefined-method` ×9
warning ×12	`call.possible-nil-receiver` ×9、`call.argument-type-mismatch` ×3
info ×9	`flow.always-truthy-condition` ×8、`rbs.coverage.missing-gem` ×1

8件のflow.always-truthy-conditionは、まさに20260521-mastodon-cluster4-flow-folding-triage.mdでトリアージされたクラスタ4のG1/G2フローフォールディングフォルスポジティブそのもの — 依然として存在し、依然としてキューされており、ライン全体で不変。

結論

ADR-22のacknowledgeモードは経験的に検証された。v4.5.0-beta.1でRigorを採用したプロジェクトは、v4.5.xライン全体 — 10回のパッチリリース — をベースラインメンテナンスゼロ、フォルスなCI失敗ゼロで乗り切れていただろう。それはまさにrigor-project-initのacknowledgeモードが売りにする「現在の状態を採用する。通常のコーディングはエラーを増やさない」という契約である。
(file, rule, count)粒度は実践上リファクタ耐性がある。診断を抱える6ファイルがバケットを壊すことなく編集された — WD1の行移動耐性の主張は実際のチャーンでも成り立つ。
rigor-project-initのワークフロー形状は健全である。このサイズのRailsプロジェクトにとって、surfacedカウントというメトリックは意味があり安定している。

注意点 / この実行の限界

リリースタグはspecゲートを通過した母集団であり — このsweepはベースラインの安定性を測るものであって、Rigorのバグ検出を測るものではない。ここでのすべてのタグはCI後のものである: 成熟したプロジェクトのspecスイートはマージ前に明白なエラーを捕まえ、本物のバグはタグが切られる前に修正される。よってリリースタグのラインにわたるsurfaced = 0は期待される健全な結果である — Rigorが捕まえるであろうバグは、specがすでに取り除いたのと同じクラスのものだからだ。この実行はacknowledgeモードの安定性（メンテナンスチャーンによるフォルスなリグレッションがないこと）を強く検証しているが、Rigorが新しいバグを捕まえるかどうかについては何も語らない。これは、機能をまたぐかどうかにかかわらず、あらゆるリリースタグの範囲について言える。検出をテストするにはリリースタグより細かいサンプリングが必要だ — main上のコミット単位、PRヘッドのコミット、あるいはバグ混入コミット（既知の修正の直前のコミット）。rigor-regression-sweep SKILL §「Phase 1」はこれをサンプリングに関する主要なガイダンスとして記録している。
設定はrigor-*プラグインを省いている（v0.1.xでは未公開）。Railsプラグインセットを有効にすれば絶対件数は変わるだろうが、デルタ方法論は影響を受けない（設定は固定されたままだから）。
severity_profile: lenientはpossible-nil-receiver / argument-type-mismatch / flow.*をダウングレードする。error重大度の9件の診断はすべてcall.undefined-methodである。
単一プロジェクト、単一リリースライン。これが反復可能なコーパスになるよう、SKILLが存在している。

再現手順

~/repo/ruby/rigor-survey/_mastodon-sweep/にsweep.sh、 tabulate.rb、固定したbaseline.yml、reports/<tag>.jsonが置かれている。手順はrigor-regression-sweep SKILLである。