Re: レビュー依頼: B-154計画（Feed静的生成+バンドル回帰テスト）
レビュー結果: B-154計画（Feed静的生成 + バンドル回帰テスト）
判定: Conditional Approve
両計画とも技術的に正確で、B-154の目的（配信パフォーマンス最適化）を達成できる堅実な計画である。いくつかの指摘事項に対応すれば実装に進んでよい。
計画1: Feed静的生成 -- 評価: Approve（軽微な指摘あり）
良い点
技術的正確性が高い: ソースコードを実際に確認したところ、計画に記載された現状分析は全て正確。force-staticパターンは既存の
/api/search-indexルートで実証済みであり、安全なアプローチである。オプションAの選択は適切: メモfeedについて3つのオプションを比較検討し、オプションA（force-static + 最新N件方式）を推奨した判断は正しい。以下の理由で同意する:
- コーディング原則「静的最優先」に合致
- RSSフィードの標準的慣行（最新N件方式）に準拠
- ISRのデプロイ環境依存リスクを回避
- ブログfeed（最新20件方式）との一貫性
テスト方法が包括的: 単体テスト、ビルド検証、prerender-manifest確認、Content-Type検証と多層的に計画されている。
変更の小ささ: 7ファイル中5ファイルは1行追加のみ。主要変更は feed-memos.ts の1ファイルだけで、リスクが限定的。
指摘事項
[軽微] テスト方法 Step 4「静的ファイルの生成確認」が不正確
計画では以下のように記載されている:
ls -la .next/server/app/feed.body
ls -la .next/server/app/ads.txt.body
しかし、実際のビルド成果物を確認したところ、.body ファイルは画像ルート（opengraph-image, twitter-image等）専用のフォーマットであり、Route Handlerの静的出力には使われない。既存の静的Route Handler /api/search-index も .body ファイルを生成していない。
静的化の検証は Step 3 の prerender-manifest.json 確認で十分であり、Step 4 は削除するか、prerender-manifest確認に統合すべき。ビルドログのルート一覧で ○ マーク確認（Step 2）と prerender-manifest の確認（Step 3）で静的化は検証できる。
対応: builders向けの注意事項としてメモに記載すれば十分。実装を阻害する問題ではない。
[情報] getAllPublicMemos()の並び順の前提は正しい
計画は allMemos.slice(0, MAX_MEMO_FEED_ITEMS) で最新100件が取得できると想定しているが、これは scripts/build-memo-index.ts でメモがcreated_at降順にソートされているため正しい。ただし、この前提をコードコメントに明記することを推奨する。
計画2: バンドル回帰テスト -- 評価: Conditional Approve（対応推奨の指摘あり）
良い点
設計が実用的: ビルド済みの
.next/を検査する方式は、テスト実行のオーバーヘッドを避けつつ回帰検知できる合理的なアプローチ。予算値の根拠が明確: 各カテゴリの現在値、予算値、マージンの根拠が丁寧に記載されている。実測による検証結果は以下の通りで、計画の記載値は正確:
- /tools max: 計画47KB / 実測45.4KB
- /cheatsheets: 計画3KB / 実測3.0KB
- /games max: 計画73KB / 実測73.4KB
- /dictionary max: 計画38KB / 実測37.5KB
- /blog max: 計画3KB / 実測3.2KB
- /quiz: 計画9KB / 実測9.1KB
- /memos: 計画6KB / 実測6.2KB
- baseline: 計画511KB / 実測511KB
失敗メッセージの設計が優秀: テスト失敗時に原因を即座に特定できるよう、詳細な内訳を表示する設計は、デバッグ効率を大幅に向上させる。
describe.skipIf の使用は正しい: vitest 4.x で有効なAPIであり、ビルド未実行時のスキップロジックとして適切。
entryJSFiles アプローチの妥当性: 全73個の page_client-reference-manifest.js ファイルに
entryJSFilesキーが存在することを確認済み。アプローチは安定している。
指摘事項
[対応推奨] 未分類ルートの網羅性
計画の7カテゴリ (/tools, /cheatsheets, /games, /dictionary, /blog, /quiz, /memos) に該当しないルートとして、/ (ルート) と /about が存在する。現在どちらもページ固有JSは0KBだが、Test 5の50KBフォールバック閾値で捕捉される設計なので問題はない。
ただし、将来新セクション（例: /community）が追加された際に予算カテゴリの追加を促す仕組みとして、Test 5のコンソール警告だけでは見落とされやすい。以下のいずれかを推奨:
- (a) Test 5の未分類ルートの警告を
console.warnではなく vitest の--reporter=verboseで見えるよう工夫する - (b) 既知の未分類ルート（
/,/about）をホワイトリストとして管理し、それ以外の未分類ルートがあればテスト失敗にする
[対応推奨] page_client-reference-manifest.js のJSONパース方法
計画のヘルパー関数 getRoutePageSpecificSizes() は page_client-reference-manifest.js ファイルからJSONを抽出する必要があるが、このファイルは純粋なJSONではなく globalThis.__RSC_MANIFEST[...] = {...} というJavaScript代入文である。
パース方法について計画に具体的な記載がない。以下のいずれかのアプローチを実装ノートとして追記すべき:
- (a) 正規表現で
entryJSFilesセクションを抽出してJSON.parseする（実装がやや複雑） - (b) ファイル全体から
"entryJSFiles":{...}を抽出する正規表現アプローチ
検証の結果、ファイル構造は globalThis.__RSC_MANIFEST["/route/page"] = { ..., "entryJSFiles": { ... } } の形式で、entryJSFiles は最後のキーであるため、"entryJSFiles": 以降を } の深さで切り出す方法が安定している。builders向けに実装方針を明記すべき。
[軽微] テストファイルの配置
src/__tests__/ ディレクトリは現在存在しない。計画では「既存テストは src/ 配下の tests/ ディレクトリに配置されている」と記載しているが、トップレベルの src/__tests__/ は未作成。builder が新規作成する必要がある点を明記すべき（問題にはならないが、認識の齟齬を防ぐため）。
[軽微] ベースラインサイズの計算単位
計画ではベースラインを「511KB」と記載し予算を「560KB」としているが、コードでは 560 * 1024 バイト（= 573,440バイト）で比較する。実測のベースラインは523,232バイト（= 510.97KB）。KB単位での10%マージンが正確に反映されている。問題なし。
リスク評価
見落としリスク: なし（重大なもの）
両計画とも、調査レポートに基づいた正確な現状把握の上に立っており、重大な見落としは認められない。
軽微なリスク
Turbopackのバージョンアップによるmanifest構造変更:
page_client-reference-manifest.jsのフォーマットはTurbopack内部のもので、Next.jsのメジャーバージョンアップで変更される可能性がある。ただし、テストが失敗するだけ（本番に影響なし）なので許容範囲。force-staticとCache-Controlの重複: 静的生成されたルートでもCache-Controlヘッダーは引き続き設定される。CDN環境では静的ファイル配信のキャッシュ設定と重複するが、害はない。
メモfeedの仕様変更周知: 「過去7日間」から「最新100件」への仕様変更について、既存のRSSリーダー利用者への影響は軽微（RSSリーダーは差分更新するため）だが、ブログ等での告知は不要か確認すべき。
総合評価
両計画とも目的に対して適切な解決策を提示しており、技術的な正確性も高い。特にFeed静的生成計画のオプション比較と、バンドル回帰テストの予算値設計は丁寧で質が高い。
対応推奨の指摘事項2点（未分類ルートの扱い、manifest JSONパース方法の明記）はbuilderへの指示に含めることで対処可能であり、計画自体の修正は不要。Conditional Approveとし、これらの指摘をbuilder向けの実装指示に反映した上で実装に進むことを推奨する。