ページ詳細の inboundLinks が巨大サイトで実用に耐えない件（要検討: 見せ方から）
背景
数十万ページ規模（anchor_edges 数百万〜1000万行オーダー）の実アーカイブで getPageDetail() を検証したところ、サイトのトップページ相当のページの inboundLinks が 10万件超 返ってきた。サイト内のほぼ全ページがトップページにリンクしているため、被リンク集計としては正しい値だが、この件数を1レスポンスに詰めて返す現行の get-page-detail.ts の設計は、この規模のサイトでは実用的でない（レスポンスサイズ・JSON生成コスト・viewer側のレンダリングコストのいずれの面でも）。
現状の実装
packages/@nitpicker/query/src/get-page-detail.ts の inboundLinks は anchor_edges を referrer 単位で GROUP BY した全件を配列で返す。ページネーションや件数上限は無い。
検討が必要な点
- 見せ方: 上位N件のみ表示するのか、件数だけ見せて詳細は別途ページネーション付き一覧で取得させるのか、ページ詳細とは別のエンドポイント（
list-links.ts 相当）に誘導するのか
- 既存の
find_duplicate_bodies / list-links のような「一覧系は別 CLI・API」という設計原則との整合
- viewer UI 側での表示コンポーネント（テーブル化 / 折りたたみ / "○○件中先頭10件" 表記など）
- API の破壊的変更を伴うか（
inboundLinks: InboundLink[] から { items, total } 形式への変更等）
スコープ外（この issue でやらないこと）
- 具体的な上限件数・ページネーション方式の決定（このissueの本題そのもの）
outboundLinks / redirectFrom / aliasUrls 側の同種の検討（inboundLinks ほど巨大になりにくいが、将来同じ問題が起きうる点は留意）
参考
- 発見の経緯:
content_items.alias_of_id（URL正規化によるページ統合機能）の実アーカイブ検証中に、get-page-detail.ts のURL解決を redirect_dest_id / alias_of_id 双方に対応させた際、実データでこの規模を実測した
ページ詳細の inboundLinks が巨大サイトで実用に耐えない件（要検討: 見せ方から）
背景
数十万ページ規模（
anchor_edges数百万〜1000万行オーダー）の実アーカイブでgetPageDetail()を検証したところ、サイトのトップページ相当のページのinboundLinksが 10万件超 返ってきた。サイト内のほぼ全ページがトップページにリンクしているため、被リンク集計としては正しい値だが、この件数を1レスポンスに詰めて返す現行のget-page-detail.tsの設計は、この規模のサイトでは実用的でない（レスポンスサイズ・JSON生成コスト・viewer側のレンダリングコストのいずれの面でも）。現状の実装
packages/@nitpicker/query/src/get-page-detail.tsのinboundLinksはanchor_edgesを referrer 単位でGROUP BYした全件を配列で返す。ページネーションや件数上限は無い。検討が必要な点
list-links.ts相当）に誘導するのかfind_duplicate_bodies/list-linksのような「一覧系は別 CLI・API」という設計原則との整合inboundLinks: InboundLink[]から{ items, total }形式への変更等）スコープ外（この issue でやらないこと）
outboundLinks/redirectFrom/aliasUrls側の同種の検討（inboundLinks ほど巨大になりにくいが、将来同じ問題が起きうる点は留意）参考
content_items.alias_of_id（URL正規化によるページ統合機能）の実アーカイブ検証中に、get-page-detail.tsのURL解決を redirect_dest_id / alias_of_id 双方に対応させた際、実データでこの規模を実測した