[5ym]

e2e (2) だけが長く、全体の待ち時間を決めていたので割り直します。組を 6 つにします。マージの前に main の ruleset の必須チェックへ e2e (6) を足してください。

いま (直近 26 回の成功した run の中央値 / p90)

組	ジョブ	うち E2E
e2e (1)	200s / 215s	187s
e2e (2)	264s / 283s	258s
e2e (3)	164s / 185s	164s
e2e (4)	127s / 141s	114s
e2e (5)	206s / 235s	193s

準備 (checkout・bun install・キャッシュ・アプリのビルド) は 15〜17 秒で、残りは全部テスト。
e2e (2) は 57-jikkyo (155s) と 51-live-gaps (126s) が組の終わりのほうにあり、94 秒目・71 秒目から始まっていた
(組の中はファイル名の順にワーカーへ配られる)。

変えたこと

• 57-jikkyo (155s) の「録画の実況」を 57-jikkyo-recorded に分ける。テストの中身はそのまま
• 直近のログのスペックごとの秒数と、組の中の配られ方を入れて shards.json を割り直し、組を 6 つにする
• 50-live-pacing は 6 組に1本だけで置く。 貯める量は狙い (0.2 秒) の 1.5 倍を超えるまで詰めない作りなので、再生を始めた瞬間に組の中が混んで多めに貯まると 0.26 秒あたりで落ち着き、上限 0.25 秒を超えていた。1本だけで流すと冷えたワーカーでも 0.17〜0.19 秒 (試しの run と下の 3 回)。通った回の数字もログに残す
• 33-recordings-group は 21-onair-fallback と別の組にする (21 が延長して録り終えた録画が、同じワーカーの 33 の一覧に入って落ちた)
• 26-hwenc の H.265 のテストは、1本目を「引数を書いた順」でなく「CM 検出の材料を取る ffmpeg」で見る。3本は同時に立ち上がるので書く順は決まらず、AV1 が先に書いて落ちていた (やり直しても落ちた回がある)。26-hwenc は分けずに軽いスペックの組に置く

結果 (最後の形で 3 回続けて流したもの。e2e のジョブ)

run	最長	50-live-pacing の遅延	やり直し
1	205s	0.184	46-home-timeline (main でもある)
2	190s	0.189	なし
3	203s	0.185	49-guide-skeleton

いまの中央値 4m24s (p90 4m43s) から 3m10s〜3m25s に縮む。いま一番長いのは 26-hwenc (170s) の組。

🤖 Generated with Claude Code

https://claude.ai/code/session_01XNTXZLNBnfhFULMqQoQmmY

[claude]

Claude finished @5ym's task in 31s —— View job

---

レビュー結果

結論: 大きな問題は見つかりませんでした。

確認したこと

• shards.json は、新しく分けた 26-hwenc-hevc と 57-jikkyo-recorded を含めて、各スペックを1つの組にだけ割り当てています。26-hwenc-hevc は組4、26-hwenc は組5、57-jikkyo と 57-jikkyo-recorded はどちらも組2です。組の名前と数も変わっていません。ただし、全スペックとの突き合わせは、この環境ではスクリプトを実行できず、目視のみです。CI の「組分けの検算」で確認されます。
• 26-hwenc と 26-hwenc-hevc に分けたあとも、hwenc.ts の encodeRuns・wayOf・clearGpus・resetGpus と、fs や helpers からの import は、どちらのファイルでも使われています。GPUS 定数は 26-hwenc だけが使い、26-hwenc-hevc には置いていません。
• 両ファイルとも afterAll で resetGpus を呼び、ファイルの終わりに GPU を「無い」状態へ戻しています。分けたことで、同じワーカーに次に来るテストへ偽 GPU が残ることはありません。
• jikkyo.ts に出した setJikkyo・deviceOn・ranked は、2つのスペックから共有されています。ranked は WeakSet<Page> で、ページごとの状態がファイルをまたいで混ざることはありません。
• 分割したテストは、中身をそのまま移したものとして読めます。

要確認 (軽微)

• 個別のスペックに分けたあとでも、上の見積もり (各組 124〜145s) は過去ログから人が割り出した値です。PR 本文の「結果」欄にあるとおり、CI の実測が出たら組ごとの秒数を追記してください。偏りが残っていれば、shards.json を微調整するだけで済みます。
• この環境では node_modules が無く、型チェックと lint は実行できていません。未使用 import などは CI の lint で確認してください。

テストの追加は不要です。今回の変更はテストの置き場所を変えるだけで、振る舞いは変わっていません。

[claude]

PR #1921 was updated after the trigger (634bd6f -> dbe5a52). Push again or mention Claude to run on the latest version.

[claude]

Claude finished @5ym's task in 26s —— View job

---

レビュー結果

結論: 不具合は見つかりませんでした。要確認が 1 点あります。

確認したこと

• shards.json のスペックは 61 件で、tests/e2e/*.spec.ts も 61 件でした。新しい 26-hwenc-hevc (組5) と 57-jikkyo-recorded (組3) は 1 つの組にだけ入っています。組の名前と数は変わっていません。ファイル名の突き合わせは目視のみなので、最終確認は CI の「組分けの検算」に任せます。
• hwenc.ts と jikkyo.ts に出した関数は、中身が元のままでした。ranked は WeakSet<Page> なので、ファイルをまたいでもページごとの状態は混ざりません。
• resetGpus は 26-hwenc と 26-hwenc-hevc の両方で、ファイルの終わりに呼ばれています。同じワーカーの次のテストに偽 GPU は残りません。
• 動かせるツールの制約で、型チェックと lint、テストは実行していません。未使用 import などは CI で確認してください。

要確認

• shards.json 組3: 50-live-pacing と 57-jikkyo-recorded が同じ組です。
  • // の注記は、遅延を実時間で測る 50-live-pacing と 51-live-gaps を「ライブや再生を描くスペックと同じ組に入れない」としています。
  • 57-jikkyo-recorded は録画の再生に実況を重ねるスペックです。再生を描くので、この決まりに当たるかもしれません。
  • 同じ組でワーカーが並んで動くと、測った遅延が上がって落ちる恐れがあります。
  • 26-hwenc や 24-bml-network など、組3の他のスペックは、中身を見ていないので判断できていません。
  • 各組の見積もりは 124〜145s と近いので、57-jikkyo-recorded を別の組へ動かしても釣り合いは大きく崩れないはずです。ただし、組3の見積もりはこのスペックを含んだ値です。動かす前に、見積もりを差し替えて確かめてください。
  • 録画の実況が再生を描くかどうかは、スペックを読んで確かめてください。描かないなら今のままで問題ありません。
• 「結果」欄は、PR 本文にあるとおり CI の実測を追記してください。偏りが残っていれば shards.json の調整だけで済みます。

テストの追加は不要です。今回の変更はテストの置き場所を変えるだけで、振る舞いは変わっていません。

[claude]

Claude finished @5ym's task in 29s —— View job

---

レビュー結果

結論: 要修正が 1 点あります。それ以外に不具合は見つかりませんでした。

要修正

• tests/e2e/shards.json 組3 で 50-live-pacing と 57-jikkyo-recorded が同じ組に入っています。
  • // の注記と docs/development.md は、遅延を実時間で測る 50-live-pacing・51-live-gaps を「ライブや再生を描くスペックと同じ組に入れない」と定めています。
  • 57-jikkyo-recorded.spec.ts は 4 本とも goto(page, \/watch/${id}`)` で録画の再生ページを開いています (23・169・257・349 行付近)。再生を描くスペックなので、この決まりに当たります。
  • 同じ組ではワーカーが並んで動くため、50-live-pacing の測った遅延が上がって落ちる恐れがあります。
  • 直し方の案は 2 つです。見積もりは各組 124〜145s と近いので、どちらでも釣り合いは大きく崩れません。
    • 57-jikkyo-recorded を組3 から、50-live-pacing と 51-live-gaps のどちらも入っていない組 (1 か 2 か 4) へ移す。
    • 50-live-pacing を、再生やライブを描くスペックのない組へ移す。
  • 移したあとは、組ごとの見積もりを足し引きし直してください。
  • 組5 の 51-live-gaps も同じ決まりの対象です。同じ組の 03-recording や 26-hwenc-hevc など、他のスペックが再生を描くかどうかは、この環境では確かめていません。

要確認 (軽微)

• 組3 の 24-bml-network も /watch や /live を開いているか、見落としの可能性があります。この環境では確かめきれませんでした。開くなら、上の移動のときにまとめて見直してください。
• この PR で組3 の中身が変わったのか、元から 50-live-pacing と同じ組だったのかは、権限の都合で main 側の shards.json と突き合わせられていません。

確認したこと (問題なし)

• 26-hwenc と 26-hwenc-hevc、57-jikkyo と 57-jikkyo-recorded への分割は、共有の hwenc.ts・jikkyo.ts に出した関数も含め、中身がそのまま移されているように読めました。
• resetGpus は両方の hwenc スペックの afterAll で呼ばれており、偽 GPU が次のテストに残ることはありません。
• 組の名前と数 (1〜5) は変わっていません。スペックの重複や抜けは CI の「組分けの検算」で確認されます。
• 型チェック、lint、テストはこの環境では実行していません。CI で確認してください。

「結果」欄は、CI の実測が出たら追記してください。

テストの追加は不要です。今回の変更はテストの置き場所を変えるだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 21s —— View job

---

レビュー結果

結論: 問題は見つかりませんでした。 前回の「要修正」(組3 の 50-live-pacing と 57-jikkyo-recorded) は、最新のコミット (ec01061) で解消しています。

確認したこと

• 前回の指摘の解消: ec01061 は、50-live-pacing・51-live-gaps を分ける相手を「映像を長くデコードし続けるスペック」に絞りました。shards.json の注記と docs/development.md の両方に反映されています。
  • 57-jikkyo-recorded.spec.ts は、録画のストリームへのリクエストに応答せず保留します (69・156・246 行付近の page.route(/\/api\/recordings\/\d+\/(file|stream)/, () => {}))。映像は届かないので、デコードは走りません。注記の「映像を返さずに止めておく」と中身が合っています。
  • 注記に挙げたデコードし続けるスペックのうち、50-live-pacing と同じ組 (組3) にあるものはありません。51-live-gaps の組5 にもありません。57-jikkyo・20-live・40-watch-compat・58-volume は組1、22-watch・28-live-raw・43-raw-cadence は組2、38・41・44 は組4 です。
• 組分けの整合性: shards.json のスペックは 61 件で、tests/e2e/*.spec.ts も 61 件です。26-hwenc-hevc (組5) と 57-jikkyo-recorded (組3) は 1 つの組にだけ入っています。ファイル名の突き合わせは目視です。最終確認は CI の「組分けの検算」に任せます。
• 分割したスペック: hwenc.ts と jikkyo.ts に出した関数は、中身が元のままです。resetGpus は両方の hwenc スペックの afterAll で呼ばれているので、同じワーカーの次のテストに偽 GPU は残りません。ranked は WeakSet<Page> なので、ファイルをまたいでもページごとの状態は混ざりません。
• 2 回目の CI の落ち: PR 本文の 33-recordings-group を 21-onair-fallback と別の組にする対応は、組5 と組2 に分かれており、反映されています。

要確認 (軽微)

• 組3 の 24-bml-network と、組5 の 03-recording・26-hwenc-hevc が、映像を長くデコードし続けるかどうかは、中身を読んでいません。注記の一覧には入っていないので、この前提が正しいかは、CI の実測で 50-live-pacing・51-live-gaps が安定して通るかで確かめてください。
• 型チェック、lint、テストはこの環境では実行していません。CI で確認してください。
• PR 本文の「結果」欄は 3 回分の実測が入っています。最新のコミットの CI が出たら、追記してください。

テストの追加は不要です。今回の変更はテストの置き場所を変えるだけで、振る舞いは変わっていません。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 27s —— View job

---

レビュー結果

結論: 要修正が 1 点あります。 最新のコミット (0d45c23、組を 6 つにした) を中心に見ました。

要修正

• tests/e2e/shards.json 組2 で 51-live-gaps と 57-jikkyo が同じ組に入っています。
  • // の注記と docs/development.md は、50-live-pacing・51-live-gaps を「映像を長くデコードし続けるスペック」と同じ組に入れないと定めています。注記の一覧には 57-jikkyo が入っています。
  • 組2 は 19-reservation-rules、24-bml-network、51-live-gaps、53-header-float、56-transfer、57-jikkyo、57-jikkyo-recorded です。51-live-gaps と 57-jikkyo が並んで動くと、51-live-gaps が測る遅延が上がって落ちる恐れがあります。50-live-pacing が 20-live と並んで 0.26 秒で落ちたのと同じ型です。
  • 直し方の案は 2 つです。
    • 51-live-gaps を、デコードし続けるスペックのない組 (組3 か 組4) へ移す。組4 は 50-live-pacing と並ぶので、ワーカー数や長さを見て決めてください。
    • 57-jikkyo を別の組へ移す。ただし 155s あるので、組の釣り合いを見直す必要があります。
  • 組3 と組4 にデコードし続けるスペックがないことは確認しました。組3 の 38-live-compat と 43-raw-cadence は注記の一覧に入っています。51-live-gaps の移動先を組3 にするなら、この 2 本とぶつかります。移動先は組4 が妥当に見えます。
  • 移したあとは、組ごとの見積もりを引き直してください。

確認したこと (問題なし)

• 組4 (50-live-pacing) に、注記の「デコードし続ける」一覧のスペックはありません。20-live・22-watch は組1、28・40・58 は組6、38・43 は組3、41・44 は組5、57-jikkyo は組2 です。
• 33-recordings-group (組1) と 21-onair-fallback (組5) は別の組です。
• test.yml は shard: [1..6] と、検算の keys == ["1".."6"] の両方を 6 に直しています。
• 前回までの指摘どおり、hwenc.ts・jikkyo.ts への切り出しと resetGpus の呼び出しは問題ありません。
• スペックの重複・抜けは、この環境の制約で機械的な突き合わせができていません。最終確認は CI の「組分けの検算」に任せます。

要確認 (軽微)

• PR 本文が古くなっています。 「組の数・名前 (e2e (1)〜e2e (5)) は変えていません」「各組 124〜145s」は、6 組にした今は事実と合いません。組を増やしたことと、見積もりを書き直してください。
• コミットメッセージのとおり、main の ruleset の必須チェックに e2e (6) を足す必要があります。 マージ前に忘れないよう、PR 本文にも書いておくと安全です。
• 型チェック、lint、テストはこの環境では実行していません。CI で確認してください。

テストの追加は不要です。今回の変更はテストの置き場所と組分けだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 25s —— View job

---

レビュー結果

結論: 不具合は見つかりませんでした。 要確認が 2 点あります。最新コミット (f91f233) まで見ました。

前回の指摘について

• 前回の「要修正」(組2 の 51-live-gaps と 57-jikkyo が同じ組) は、f91f233 で組分けの決まりごと外れました。shards.json の注記と docs/development.md の両方から、50-live-pacing・51-live-gaps を別の組にする決まりが消えています。今の shards.json は決まりに反していません。
• 外した理由は、50-live-pacing がほぼ1本だけで流れても遅延 0.26 秒で落ちたことです。混み具合のせいとは言えない、という判断です。
• そのため 50-live-pacing の落ちは、組分けでは直らない別の原因かもしれません。この環境では CI のログを確かめていません。
• 要確認: 50-live-pacing が落ちる原因は、まだ分かっていないように読めます。最新コミットの CI で通るか見てください。

要確認

• docs/development.md 191 行付近が古いままです。 必須チェックを「e2e (1)〜(5)」と書いています。組は 6 つになったので (1)〜(6) に直してください。98 行に「組を増やしたら ruleset の必須チェックにも足す」とあるので、e2e (6) を ruleset に足す作業もマージ前に必要です。
• PR 本文が古くなっています。 「組の数・名前 (e2e (1)〜e2e (5)) は変えていません」「各組 124〜145s」は、6 組にした今は合いません。50-live-pacing を別の組に置く話も本文にはなく、決まりを外したことも反映されていません。組を増やしたことと e2e (6) を ruleset に足す必要を、本文に書いてください。

確認したこと (問題なし)

• shards.json の組は 1〜6、test.yml の shard と検算 (keys == ["1".."6"]) も 6 組で揃っています。
• tests/e2e/*.spec.ts は 61 件です。shards.json との突き合わせは目視で、最終確認は CI の「組分けの検算」に任せます。
• 33-recordings-group (組1) と 21-onair-fallback (組5) は別の組です。
• hwenc.ts・jikkyo.ts への切り出しと、resetGpus の呼び出しは、前回までと変わりありません。
• 型チェック、lint、テストはこの環境では実行していません。CI で確認してください。

テストの追加は不要です。今回の変更はテストの置き場所と組分けだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 29s —— View job

---

レビュー結果

結論: コードの不具合は見つかりませんでした。要確認が 2 点あります。 最新コミット (ded3632、50-live-pacing を 6 組に1本だけで置く) を中心に見ました。

確認したこと (問題なし)

• shards.json のスペックは tests/e2e/*.spec.ts と同じ 61 件で、組は 1〜6 です。50-live-pacing は組6に1本だけで、ほかの組には入っていません。ファイル名の突き合わせは目視です。最終確認は CI の「組分けの検算」に任せます。
• test.yml の shard: [1..6] と検算の keys == ["1".."6"] は揃っています。
• 映像を長くデコードし続けるスペックは、1組に 3 本までに収まっています。
  • 組1: 20-live・28-live-raw
  • 組2: 40-watch-compat・41-watch-compat-local
  • 組4: 22-watch・38-live-compat・43-raw-cadence
  • 組5: 57-jikkyo・58-volume
• 33-recordings-group (組2) と 21-onair-fallback (組3) は別の組です。
• hwenc.ts・jikkyo.ts への切り出しと、resetGpus の呼び出しは、前回までと変わりありません。

要確認

• docs/development.md 193 行付近が古いままです。 必須チェックを「e2e (1)〜(5)」と書いています。(1)〜(6) に直してください。
• マージ前に main の ruleset の必須チェックへ e2e (6) を足す必要があります。 PR 本文には書かれています。足し忘れると、e2e (6) が落ちてもマージできてしまいます。
• 50-live-pacing の安定性は、まだ CI で確かめられていません。
  • 1本だけで流すと 0.18〜0.19 秒だった、というコミットメッセージの数字は、試しの run 1 回分です。
  • PR 本文の「結果」欄にはこの組分けの run がありません。数回流して、やり直しが出ないか見てください。
  • 組6のジョブは、準備に 15〜17 秒かかる一方で、テストはほぼ 1 本です。ランナー 1 台をほぼ丸ごと使う代わりに、安定が得られる作りです。
• PR 本文の「いま」の表は 5 組のままで、「結果」欄の最新の run はまだ追記されていません。マージ前に、最新の実測を足してください。

型チェック、lint、テストはこの環境では実行していません。CI で確認してください。テストの追加は不要です。今回の変更はテストの置き場所と組分けだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 26s —— View job

---

レビュー結果

結論: コードの不具合は見つかりませんでした。直してほしい点が 1 つ、要確認が 2 つあります。 最新コミット (6b022c0、26-hwenc を分けるのをやめる) まで見ました。

直してほしい点

• docs/development.md 194 行目の必須チェックの書き方が古いままです。 「e2e (1)〜(5)」と書いています。組は 6 つになったので (1)〜(6) に直してください。同じファイルの 101 行目は「組を増やしたら ruleset にも足す」と書いており、194 行目とは食い違います。

確認したこと (問題なし)

• shards.json のスペックは 60 件で、tests/e2e/*.spec.ts も 60 件です。組は 1〜6 で、test.yml の shard と検算 (keys == ["1".."6"]) も 6 組に揃っています。ファイル名の突き合わせは手元で comm を流せなかったため、件数と目視までです。最終確認は CI の「組分けの検算」に任せます。
• 26-hwenc を分けるのをやめたので、26-hwenc-hevc は組にもファイルにもありません。docs/development.md もその理由に合わせて直っています。
• 33-recordings-group (組5) と 21-onair-fallback (組3) は別の組です。
• 50-live-pacing は組6に 1 本だけです。
• 57-jikkyo と 57-jikkyo-recorded の分割と、jikkyo.ts への切り出しは、前回までと変わりありません。
• live-pacing.ts の console.log は通った回の値も CI のログに残すだけで、振る舞いは変わりません。

要確認

• マージ前に main の ruleset の必須チェックへ e2e (6) を足す必要があります。 PR 本文に書かれています。足し忘れると、e2e (6) が落ちてもマージできてしまいます。
• PR 本文の「結果」欄は古いままです。 表の「いま」と「結果」が 5 組のままで、最新の組分け (6 組、26-hwenc は分けない、50-live-pacing は 1 本だけ) の run が入っていません。数回流して、50-live-pacing にやり直しが出ないか確かめ、実測を足してください。

型チェック、lint、テストはこの環境では実行していません。CI で確認してください。テストの追加は不要です。今回の変更はテストの置き場所と組分けだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 17s —— View job

---

レビュー結果

結論: コードの不具合は見つかりませんでした。 最新コミット (dff30a2) まで見ました。

前回の指摘について

• docs/development.md 194 行目の必須チェックは e2e (1)〜(6) に直っています。

確認したこと

• 分割した 57-jikkyo / 57-jikkyo-recorded と、jikkyo.ts への切り出しは、前回までと変わりありません。
• live-pacing.ts の追加は console.log だけで、振る舞いは変わりません。
• 型チェック、lint、テストはこの環境では実行していません。shards.json とスペックの突き合わせも実行できていません。CI の「組分けの検算」で確認してください。

要確認

• マージ前に main の ruleset の必須チェックへ e2e (6) を足してください。 PR 本文にも書かれています。足し忘れると、e2e (6) が落ちてもマージできます。
• 50-live-pacing の安定性は、PR 本文の説明のとおり原因が分かっていません。 最新の組分けで数回流して、やり直しが出ないか見てください。PR 本文の「結果」欄は 5 組の時点のままなので、最新の実測を足してください。

テストの追加は不要です。今回の変更はテストの置き場所と組分けだけです。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 15s —— View job

---

レビュー結果

結論: 不具合は見つかりませんでした。 最新コミット (0b7a7f9) まで見ました。

今回の変更 (0b7a7f9)

• tests/e2e/26-hwenc.spec.ts の H.265 テストで、1本目を「引数を書いた順」ではなく「引数に denpa-scan- を含むもの (CM 検出の材料を取る実行)」で選ぶように変えています。3本が同時に立ち上がるので書く順が決まらない、という理由は筋が通っています。
• expect(runs).toHaveLength(3) を残したうえで lead が ["renderD128:hevc_vaapi"] ちょうど1本になることを見ているので、denpa-scan- を含む実行が0本や2本以上になれば落ちます。検査が緩くなってはいません。
• docs/development.md の必須チェックは e2e (1)〜(6) に直っています。

要確認

• denpa-scan- が本当に CM 検出用の書き出し先にだけ付くかは、アプリ側の実装を読んで確かめていません。 他の実行の引数に同じ文字列が入る場合は、lead が複数になってこのテストが落ちます。ただし落ち方は分かりやすいので、致命的ではありません。
• マージ前に main の ruleset の必須チェックへ e2e (6) を足してください。 足し忘れると、e2e (6) が落ちてもマージできます。PR 本文にも書かれています。
• PR 本文の「結果」欄は、26-hwenc を分けるのをやめる前の run のままです。この修正を含めて、最後の組分けで数回流した実測に差し替えてください (特に 26-hwenc の H.265 と 50-live-pacing にやり直しが出ないか)。

型チェック、lint、テストはこの環境では実行していません。shards.json とスペックの突き合わせも、CI の「組分けの検算」に任せます。
· ブランチ: ci/e2e-faster

[claude]

Claude finished @5ym's task in 22s —— View job

---

レビュー結果

結論: 不具合は見つかりませんでした。 最新コミット (40ec2b7) まで見ました。

今回の変更 (40ec2b7)

• docs/development.md の 26-hwenc の説明を、「分けると落ちたので分けていない」から「まだ分けていない (一番長い 170 秒。軽いスペックの組に置いている)」に直しています。直前の 0b7a7f9 で H.265 の1本目の見方を直したため、前の理由は成り立たなくなっており、書き直しは妥当です。
• test.yml は組を 6 つにしたあとも、どの組にも入っていないスペックを 5 組へ寄せる作りのままです。docs/development.md 99 行の「5 組で流れます」と合っています。

要確認

• マージ前に main の ruleset の必須チェックへ e2e (6) を足してください。 PR 本文にも書かれています。足し忘れると、e2e (6) が落ちてもマージできてしまいます。

型チェック、lint、テストはこの環境では実行していません。shards.json とスペックの突き合わせも、CI の「組分けの検算」に任せます。テストの追加は不要です (今回は docs のみ)。
· ブランチ: ci/e2e-faster