feat(plugin): 0.3.0 —— 按实跑反馈修订 research 规程

用《别住在律藏中的案例分析》实跑一遍后暴露的问题，逐条修订：

1. PATH 措辞。两个 SKILL.md 原来断言「插件启用时已在 PATH 上」，实际
   PATH 注入在会话启动时完成，装完/更新完当前会话里没有——我的终端会话
   和用户的桌面版各踩了一次。改为：command -v 为空时用
   ${CLAUDE_PLUGIN_ROOT}/bin/wikipali，并提醒用户重启会话。

2. 层次期待按章节分开说。我原本提议加一条「定义部分必须同时引 mūla」的
   铁律，被领域专家否掉：大部分名词解释本来就在义注与复注里，律藏根本中
   只有部分解释。所以查定义时前几名全是注疏是正常的，不必回头找本文，但
   也不能据此断定本文没有解释。反过来，案例（谁、何种情况、如何执行）在
   本文里，取案例那步要有意识地收窄到 mūla——否则注疏的高命中密度会把
   本文案例挤出前 50。

3. 新增 3b「留意注疏有没有枚举子类」。实跑时是靠人从义注的 catubbidho
   parivāso 挖出四种别住、再逐个数频次才拿到分类框架，规程里原本没有这
   一步。写成「留意有没有」而非「去找」——这类体例常见但不是每个词都有，
   没有就不该硬造分类。频次只报数字不下判断：高频可能只是某部注疏反复
   提及，不等于更重要。

铁律仍是 6 条，未新增。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

plugins/wikipali/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "wikipali",
   "description": "WikiPali 巴利三藏平台的客户端：检索与阅读语料做研究（词形展开、全文检索、出处分布、按坐标取原文与译本），以及以 AI 模型身份写入句子。",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "author": {
     "name": "visuddhinanda",
     "url": "https://github.com/visuddhinanda"

plugins/wikipali/skills/research/SKILL.md

@@ -7,7 +7,9 @@ description: "Use this skill to research Pali Buddhist texts with WikiPali's cor
 
 用 WikiPali 的语料做巴利文献研究：定位 → 取证 → 展开 → 交叉验证 → 成文。
 
-命令是 `wikipali <子命令>`（插件启用时已在 PATH 上）。检索与阅读全部只读，**不需要登录**。
+命令是 `wikipali <子命令>`。检索与阅读全部只读，**不需要登录**。
+
+⚠ **刚装好或刚更新插件时，`wikipali` 可能还不在 PATH 上**——PATH 注入在会话启动时完成，装完要重启会话。若 `command -v wikipali` 为空，改用绝对路径 `${CLAUDE_PLUGIN_ROOT}/bin/wikipali`，并提醒用户重启会话。
 
 **坐标、引用格式、文献层次、译文来源判定见 `references/conventions.md`——那是所有
 skill 共用的规矩，必须遵守。** 端点细节见 `references/api-read.md`。
@@ -66,9 +68,32 @@ wikipali search --lemma parivāsa --limit 50
 结果按黑体加权排序，**注释书里作为词条解释的段落会自然排在前面**。从前 50 条里挑出
 讲定义和执行流程的，用来写定义部分。
 
+**前几名全是 aṭṭhakathā / ṭīkā 是正常的，不是检索出了问题。** 大部分名词解释在义注
+（aṭṭhakathā）与复注（ṭīkā）里，律藏的根本（pāḷi / mūla）中也有部分解释。
+
+所以：不必因为看不到本文命中就怀疑检索出了错；但也**不要断定本文没有解释**——本文
+里的那部分同样要引，按铁律 4 标明层次。
+
 命中总量特别大、前 50 条噪声明显时，可以加 `--bold` 只看黑体命中来收窄——那是收窄
 手段，不是默认做法，因为不加黑体的定义段落会被它漏掉。
 
+### 3b. 留意注疏有没有枚举子类
+
+注疏解释术语时常会枚举它的子类（`catubbidho X`、`duvidho X` 这类体例很常见，但**不是
+每个词都有**）。读定义段落时**留意有没有**这种枚举——有，它就是现成的分类框架，比自己
+归纳可靠；没有就跳过，**不要硬造分类**。
+
+发现子类型后，逐个展开数频次：
+
+```bash
+wikipali forms samodhānaparivāsa
+wikipali forms paṭicchannaparivāsa
+```
+
+**只报数字，不要从频次下判断。** 例如 `parivāsa` 的四个子类：samodhāna 260 次、
+paṭicchanna 29、titthiya 18、appaṭicchanna 14。把这组数字连同出处交给用户即可——高频
+可能只是某部注疏反复提及，不等于该子类更重要，这个判断该由研究者做。
+
 ### 4. 取案例：全量检索
 
 ```bash
@@ -78,6 +103,10 @@ wikipali search --lemma parivāsa --tags vinaya --limit 200
 每条给出坐标、章节路径和高亮片段。**先用片段做初筛**，判断该段落属不属于目标案例
 类型，不要一上来就把每段全文取回来。
 
+**这一步要有意识地回到本文（mūla）。** 与定义相反，案例——谁、在什么情况下、如何
+执行、判定结果如何——在律藏本文里，注疏是对这些案例的解释。用 `dist` 输出里本文那
+几部书的 `--book` 值收窄，别让注疏的高命中密度把本文案例挤出视野。
+
 ### 5. 取原文
 
 ```bash
@@ -125,7 +154,8 @@ wikipali get 216:35 216:36 216:41
 | 现象 | 真正的原因 |
 |---|---|
 | 检索 0 条 | 多半是没展开词形，用了词典形 |
-| 结果全是义注、没有本文 | 正常——注释书解释术语的密度本来就高。用 `dist` 的层次汇总确认，别当成 bug |
+| 查定义时结果全是义注、复注 | 正常，大部分名词解释在注疏里。但本文中也有部分解释，别据此断定本文没有 |
+| 查案例时找不到本文 | 这才是问题。用 `dist` 的 `--book` 值收窄到 mūla 再搜 |
 | 某段落取不到译文 | 该 channel 在该段落没有内容。如实报告 |
 | 想按短语检索 | 平台的词组检索目前不可用（服务端 500）。把短语拆成词，分别展开词形再检索 |
 | `get` 报 500 | 忘了 channel。`get` 缺省会带巴利原文的 channel，若你手动传了参数要确保 channel 在内 |

plugins/wikipali/skills/write/SKILL.md

@@ -14,7 +14,9 @@ metadata:
 - `wikipali-login` —— 唯一接触密码的程序，**必须由用户本人在真正的终端里执行**
 - `wikipali` —— 其余全部操作
 
-命令是 `wikipali <子命令>`（插件启用时已在 PATH 上），登录是独立的 `wikipali-login`。
+命令是 `wikipali <子命令>`，登录是独立的 `wikipali-login`。
+
+⚠ **刚装好或刚更新插件时，这两个命令可能还不在 PATH 上**——PATH 注入在会话启动时完成，装完要重启会话。若 `command -v wikipali` 为空，改用 `${CLAUDE_PLUGIN_ROOT}/bin/wikipali`，并提醒用户重启会话。
 
 **坐标、引用格式、译文来源判定、凭据规矩见 `references/conventions.md`——那是所有 skill 共用的，必须遵守。** 端点细节见 `references/api-write.md`。