docs: 记录两项待办——短语检索改走 v3/search，按章节聚合分布待定方案

短语检索：/v3/search 已实现（OpenSearch），仍在调试。所以 §3.1 记的两条
修法（修 tulip / 接 pali() 降级）都不必做，等 v3 稳定后把客户端指过去，
届时需重新盘点 v3 的参数与返回形状。

按章节聚合：服务端只有按书聚合的端点，按章节要客户端拉全量再按 path
聚合，几千段的常见词成本高。方案待定。

docs/wikipali-research-agent-design.md

@@ -223,6 +223,30 @@ Samantapāsādikā, Pārivāsikavattakathā (SP-aṭṭ 141:63)
 
 **⬜ TODO（服务端）**：给 `channels` 加一个来源字段（如 `provenance`: `human` / `machine` / `mixed`），让判定有据。注意写入型 skill 产生的数据天然带模型署名（`editor_uid` = 模型 uid），所以这个问题只存在于存量数据。
 
+## 3.6 待办：短语检索改走 /v3/search（OpenSearch）
+
+§3.1 记的「词组/短语检索 500」有下文：**`/v3/search` 已实现，改用 OpenSearch，2026-08-08
+时点仍在调试**（用户告知）。
+
+所以 §3.1 的两条修法（修 tulip / 接 `SearchController::pali()` 降级）都不必做了——等 v3
+稳定后，客户端把短语检索指过去即可。届时要重新盘点 v3 的参数与返回形状，它大概率与
+v2 的 `search-pali-wbw` 不同。
+
+在那之前，`research` 规程里「把短语拆成词分别展开词形」的绕行办法继续有效。
+
+## 3.7 待办：按章节聚合分布（`dist --by chapter`）
+
+现在 `dist` 只能按**书**聚合。实跑「别住」时，「命中集中在第 2 犍度（规矩）与第 3 犍度
+（授予程序）」这个结构性判断是人看 `search` 结果的 `path` 字段看出来的，工具没帮忙。
+
+做法上有个成本问题：按书聚合服务端有现成端点（`search-pali-wbw-books`），按章节没有，
+客户端得**拉全量命中**再按 `path` 的某一层聚合。`parivāsa` 是 281 段还好，几千段的常见词
+就要分页拉很多次。
+
+方案待定（用户 2026-08-08 要求稍后给）。可选方向：客户端全量拉 + 本地聚合（简单但慢）、
+服务端加一个按章节 group by 的端点（快但要改服务端）、或者只对 `--book` 限定后的结果做
+（把量压下来再聚合）。
+
 ---
 
 ## 4. 设计要点（端点清单看不出来的那些）