fix(wiki): wiki poller never reaches pages past the per-run probe cap, so most Decision Structure entries are unindexed

[liplus-lin-lay]

@

目的

liplus-language wiki の判断構造（Decision Structure）エントリが RAG 索引にほぼ入っていない。wiki 走査が全ページに到達するようにし、索引カバレッジを回復する。

前提（2026-07-31 実測）

現状の数

	数
liplus-language wiki の実ページ（_Sidebar / _Footer を除く）	77
search_docs に type = wiki_doc で入っているページ	35
未索引	50
改名前のページ名のまま残っている孤児行	8

未索引 50 件には判断構造エントリの大半が含まれる（l1-brake2-root-criteria-evaluator / liplus-judgment-learning-telos / hook-driven-gate-trigger / subtractive-structural-beauty-framing / implementation-always-delegated / memory-graphrag-sqlite-exploration ほか）。

孤児 8 件 = C.-Bootstrap / Decision-Log / a.-Decision-Log / f.-sheepdog-engineering-concept / g.-prerelease-tag-recovery-procedure / h.-release-flip-drift-patterns / i.-li-plus-long-term-vision-feedback-only / j.-master-role-as-client-architect。いずれも改名済みで現 wiki には存在しない。

なぜ効くか

Li+ の skills/evolution-judgment-learning は過去判断の取得経路を「RAG MCP が一次、gh search が fallback」と定義している。判断構造エントリの本体は wiki にしか無い（docs/Decision-Structure.md は運用インデックスのみ）。したがって現状は、一次経路から判断記録だけが抜け落ちている。

実測: brake 2 の根拠を問うクエリ（brake 2 L1 root criteria evaluator PASS が human approval を代替する）を投げると issue #1478 / PR レビュー / adapter/claude/agents/l1-gate-eval.md / rules/operations/execution-mode.md の diff は返るが、判断本体を書いた wiki エントリ l1-brake2-root-criteria-evaluator は返らない。周辺の痕跡から判断を再構成させる形になっている。欠損が黙って 0 件として現れるため、利用側からは観測できない。

確認済みの原因

原因 A（主因）— probe cap に再開位置が無く、毎 run 同じ先頭 20 件しか見ていない

src/poller.ts の pollWikiRepo は毎 cron run で pageSlugs を先頭から走査し、カーソルを持たない。未変更ページでも hash 比較のため raw content を fetch するので、skip したページも MAX_WIKI_PAGES_PROBED_PER_REPO_PER_RUN = 20 を消費する。結果、列挙順 21 件目以降には構造的に永久到達しない。

_pages の実際の列挙順（大小文字を区別しない辞書順）と索引状況を突き合わせた結果:

列挙位置	索引状況
1	_new（GitHub の UI リンク。実ページではない）
2〜20	19 件すべて索引済み
21 以降	大半が未索引。索引済みの 8 件（current-architecture-as-concession / D.-Installation / Decision-Structure / decision-structure-industry-positioning / decision-structure-rename-rationale / dialogue-evaluator-scoring-redesign / F.-Behavior-First / G.-Sheepdog-Engineering）は、wiki がまだ小さくウィンドウ内に入っていた時期の残留

境界が probe cap とちょうど一致する。単一原因として確定してよい。

原因 B — _new が 20 枠の 1 つを毎 run 消費する

スラッグ抽出の正規表現 href="/{repo}/wiki/([^"#?]+)" は GitHub の新規作成リンク _new を拾う。実ページではないので raw fetch は全拡張子 404 になり、failed として毎 run 捨てられる。実効的な probe 予算は 19。

原因 C — Home が _pages に列挙されない

_pages の一覧に Home は現れない（実測 77 スラッグ中に不在）。一方 https://raw.githubusercontent.com/wiki/{repo}/Home.md は 200 を返す。列挙経路に依存する限り Home は永久に索引されない。

原因 D — タイトルに + を含むページはスラッグが不可逆に壊れる

E.-Li+language.md に対し _pages が返すスラッグは E.-Li-language（+ が - に潰れる）。

URL	結果
raw.../E.-Li-language.md	404
raw.../E.-Li%2Blanguage.md	200

スラッグをそのまま raw URL に組み立てる現行実装では、このページは到達不能。ウィンドウ内に入った場合は毎 run probe を 1 枠消費して失敗し続ける。

原因 E（未確定、実装時に検証すること）— 孤児が削除経路に乗っていない

削除判定は deleted = existing.filter((w) => !currentSlugs.has(w.pageName)) で、existing は IssueStore の wiki-doc レコード。孤児 8 件が search_docs に残っているということは、store 側のレコードが先に消えて existing に現れず、deleted に載らないまま search_docs / Vectorize / doc_edges に取り残された可能性が高い。実装前に store の wiki-doc レコードを実際に確認すること。

制約

• subrequest 予算（hotfix: wiki ingestion exhausts Worker subrequest budget on initial bulk poll #130）。1 invocation あたり 1000。cap はこの予算を守るために置かれたものなので、単純な引き上げは同じ壁に当たる。cap を保ったまま全ページに到達する設計にすること
• hash 一致なら再 embed しない現行の挙動は保つ（既存索引の再生成コストを発生させない）
• MAX_WIKI_EMBEDDINGS_PER_RUN = 30 は Workers AI の embed 予算側の上限で、probe cap とは別軸。混同しないこと
• 走査対象は複数 repo（現在 8 repo）。1 repo の wiki が深いことで他 repo の走査が止まらないこと

受け入れ条件

• liplus-language wiki の全ページが、有限回の cron run で索引に到達する。到達したことを SQL（search_docs の type = wiki_doc 行と _pages 列挙の突き合わせ）で確認できること
• _new のような UI リンクが probe 枠を消費しない
• Home が索引される
• E.-Li+language が索引される
• 孤児 8 件が search_docs / Vectorize / doc_edges から消える
• 1 run あたりの wiki 由来 fetch 数が上限内に収まることをテストで固定する
• 即時復旧経路（全ページを cron 待ちせずに索引する手段）があること。既存の /admin/backfill-* と同形の admin endpoint を置くのが素直だが、実装時に判断してよい

別軸（本 issue の対象外、記録のみ）

MAX_EMBEDDING_INPUT_CHARS = 8000 により長いページは切り詰められる。Decision-Structure インデックス頁は現在ちょうど 8000 で頭打ちになっており、カバレッジを直しても後半は索引に入らない。分割索引が要るかは別 issue で判断する。

想定変更箇所

• src/poller.ts（pollWikiRepo の走査順・再開カーソル・スラッグ除外・raw URL 組み立て・孤児削除経路）
• 進捗（カーソル）の保存先
• src/index.ts（即時復旧用 admin endpoint を置く場合）
• 対応するテストと docs（同一 PR 内）
  @

[liplus-lin-lay]

実装完了、PR #185 を作成。CI 完了待ち（このリポジトリには waiting ラベルが無いため in-progress のまま保持）。CI green を確認後、セルフレビューを記録して done へ移す。マージ判断と本番反映は親が持つ。