Merge pull request #26 from jupiterx0910/fix/runtime-scan-self-reference-false-positive

验证记录（值班室 2026-09-18 夜班，独立实跑，非复述 PR 描述）：

用仓库**真正的门禁命令**（SKILL.md:98 与 references/runtime-neutrality.md:65 两处一致的那条）实跑，
构造真红灯样本撞新增的判别表，确认新规则按「出现位置」分栏后**不会把真红灯误判成假阳性**——
这是合并前最需要排除的风险，已排除。

两点如实记录，供后续参考：
1. PR 描述里「实测复现」用的 grep 命令与仓库门禁命令不是同一条（前者少扫了 README.md），
   所以「8 处全部是假阳性」这个数字复核不上；实跑命中 5 处。
2. 「3 个 judge 3-0」无法复核，未作为合并依据。

合并依据是 diff 本身经得起对抗测试，与作者给出的证据无关。

SKILL.md

@@ -98,7 +98,7 @@ skill 应当能在 Claude Code / Codex / Cursor / OpenClaw / Hermes / Gemini CLI
 grep -nE "(在 Claude Code|Claude Code skill|Claude Code 用户|Cursor only|Codex 中|^\[!\[Claude Code|~/\.claude/skills/[a-z]|/plugin install\b)" SKILL.md README.md 2>/dev/null
 ```
 
-输出非空 = 红灯命中 → 强制把 Phase 2 第一轮定为 P0「runtime drift 修复」（写入 results.tsv 的 note 列 `runtime_warn=N`）。
+输出非空 = 红灯命中，**但须先读命中行上下文排除假阳性**（grep 命令本身/反例引用/讲解该规则的元陈述=假阳性，记 `runtime_scan=false_positive` 不改；判别表见 references/runtime-neutrality.md）→ 确认是真红灯（指令性用法）才强制把 Phase 2 第一轮定为 P0「runtime drift 修复」（写入 results.tsv 的 note 列 `runtime_warn=N`）。
 
 ### 例外（允许的「Claude Code 痕迹」）
 

references/runtime-neutrality.md

@@ -47,6 +47,17 @@
 2. **花叔生态内部联动的 skill 名引用**——如「调用 huashu-design」「跟 darwin-skill 配套」
 3. **明确标注的 runtime-specific 章节**——如「### 仅 Claude Code 优化（按需触发）」+ 解释清楚是 nice-to-have
 4. **commit message、changelog、内部脚本**——不属于用户读到的 skill 内容
+5. **引用/演示该 pattern 本身**——讲解红灯规则、列反例、给出 grep 命令时，必然要字面写出「在 Claude Code 里」「Claude Code skill」这些措辞。这是**把措辞当被描述的对象**，不是**把单 runtime 当指令要求读者用**，属假阳性。典型受害者是 darwin-skill 自己（本审查章节就含这些字样）。
+
+**真红灯 vs 假阳性判别**：
+
+| | 真红灯（须修） | 假阳性（不修） |
+|---|---|---|
+| 性质 | 把单 runtime 当**指令**：「在 Claude Code 里运行 X」「这是 Claude Code skill」 | 把这些措辞当**被描述的对象** |
+| 出现位置 | 工作流步骤、首屏定调、安装说明 | grep 命令本身、反例清单里引用的反例、「『Claude Code skill』是红灯措辞」这类元陈述、本对照表 |
+| 处理 | 进 P0 runtime drift 修复 | 记 `runtime_scan=false_positive`，不改 |
+
+**扫描后必须人工读命中行的上下文**再定性——禁止机械按 grep 命中行数定 P0，否则任何讲解 runtime 中立性的 skill（含 darwin-skill 本身）都会永远判自己红灯、陷入自审死循环。
 
 ---