判断すること
latex.json の lockFileMaintenance.schedule を、窓全体（金・土）より狭くするかどうか。
現状の整理
窓を金・土の 2 日に広げた根拠は latex.json の description に書いてある。
Two days costs nothing to widen to, because the caps below are unlimited: the first job that lands inside the window drains the queue, and the eleven that follow it find nothing left to create.
この「キューが枯れる」前提を lockFileMaintenance だけが満たさない。
バージョン更新は対象が有限で、d7e1218 に上げてしまえばその項目は消える。lock file maintenance は「main の lockfile と registry の現在値の差」であって項目ではない。マージすれば差はゼロになるが、npm registry は数時間で動くので、次の job には再び差がある。自分がマージした結果を材料に次を作るので、窓が開いている限り止まらない。
観測（2026-08-27 〜 08-29 の窓）
3 リポジトリで 9 本。
| リポジトリ |
PR |
作成 (UTC) |
マージ (UTC) |
差分 |
| ai-academic-paper-reviewer |
#76 |
08-27 16:36 |
08-27 23:17 |
+98/-98 |
| ai-academic-paper-reviewer |
#77 |
08-27 23:18 |
08-28 05:05 |
+3/-3 |
| ai-academic-paper-reviewer |
#79 |
08-28 17:55 |
08-28 21:53 |
+20/-20 |
| ai-academic-paper-reviewer |
#81 |
08-29 01:08 |
OPEN |
+3/-3 |
| texlive-ja-textlint |
#145 |
08-27 16:03 |
08-28 07:07 |
+9/-9 |
| texlive-ja-textlint |
#146 |
08-28 20:45 |
08-29 00:44 |
+3/-3 |
| texlive-ja-textlint |
#147 |
08-29 00:45 |
OPEN |
+3/-3 |
| .github |
#154 |
08-28 02:47 |
08-28 13:50 |
+1/-1 |
| .github |
#156 |
08-29 01:01 |
08-29 09:15 |
+1/-1 |
決定的なのは ai-academic-paper-reviewer の #77 で、#76 のマージ 36 秒後に作られている。 同一 job が「マージ → 直後に再作成」を実行した跡。
texlive-ja-textlint #147 の中身は transitive の zod が 4.5.1 → 4.5.2 の 1 パッケージだけ。#146 も同規模。
コスト
実害は自動マージされるので小さいが、ゼロではない。texlive-ja-textlint は 1 PR ごとに build-alpine / build-debian / build-debian-arm64 の 3 ビルドが走る。窓 1 回で 3 本 = Docker ビルド 9 回。窓を 2 日に広げた判断は「costs nothing」の見積もりで下されたので、その見積もりが 1 箇所で外れている。
もう一つ、窓が閉じた時点で残った PR は翌週まで OPEN で残る。現在 #147 と #81 がその状態に向かっている。
選択肢
A. lockFileMaintenance に狭い schedule を与える（推奨）
"lockFileMaintenance": {
"enabled": true,
"schedule": ["before 6am on friday"]
}lockFileMaintenance は既に独自 schedule を持っている（トップレベルが上書きしないため description で明記済み）ので、変更点はその 1 行だけ。JST 金 0:00–6:00 は job 間隔 4 時間の 1.5 倍幅なので、Avoid schedules like "Run Renovate for an hour each Sunday" の失敗モード（窓が job 間隔より狭くて 1 つも入らない）には戻らない。窓に入る job は 1〜2 回に収まる。
B. 現状維持
自動マージされるので放置しても破綻しない。ただし毎週 3〜4 本の 1 パッケージ PR と、その CI が回り続ける。
補足
この観測は texlive-ja-textlint #141（2026e リリース）の準備中に見つけたもの。リリース判断そのものには影響しない。
判断すること
latex.jsonのlockFileMaintenance.scheduleを、窓全体（金・土）より狭くするかどうか。現状の整理
窓を金・土の 2 日に広げた根拠は
latex.jsonの description に書いてある。この「キューが枯れる」前提を
lockFileMaintenanceだけが満たさない。バージョン更新は対象が有限で、
d7e1218に上げてしまえばその項目は消える。lock file maintenance は「main の lockfile と registry の現在値の差」であって項目ではない。マージすれば差はゼロになるが、npm registry は数時間で動くので、次の job には再び差がある。自分がマージした結果を材料に次を作るので、窓が開いている限り止まらない。観測（2026-08-27 〜 08-29 の窓）
3 リポジトリで 9 本。
決定的なのは ai-academic-paper-reviewer の #77 で、#76 のマージ 36 秒後に作られている。 同一 job が「マージ → 直後に再作成」を実行した跡。
texlive-ja-textlint #147 の中身は transitive の
zodが4.5.1→4.5.2の 1 パッケージだけ。#146 も同規模。コスト
実害は自動マージされるので小さいが、ゼロではない。texlive-ja-textlint は 1 PR ごとに
build-alpine/build-debian/build-debian-arm64の 3 ビルドが走る。窓 1 回で 3 本 = Docker ビルド 9 回。窓を 2 日に広げた判断は「costs nothing」の見積もりで下されたので、その見積もりが 1 箇所で外れている。もう一つ、窓が閉じた時点で残った PR は翌週まで OPEN で残る。現在 #147 と #81 がその状態に向かっている。
選択肢
A.
lockFileMaintenanceに狭い schedule を与える（推奨）lockFileMaintenanceは既に独自 schedule を持っている（トップレベルが上書きしないため description で明記済み）ので、変更点はその 1 行だけ。JST 金 0:00–6:00 は job 間隔 4 時間の 1.5 倍幅なので、Avoid schedules like "Run Renovate for an hour each Sunday"の失敗モード（窓が job 間隔より狭くて 1 つも入らない）には戻らない。窓に入る job は 1〜2 回に収まる。B. 現状維持
自動マージされるので放置しても破綻しない。ただし毎週 3〜4 本の 1 パッケージ PR と、その CI が回り続ける。
補足
この観測は texlive-ja-textlint #141（2026e リリース）の準備中に見つけたもの。リリース判断そのものには影響しない。