drpy-node-source-workflow

name	drpy-node-source-workflow
description	适用于 drpy-node 源修复、调试、测试与可用性评估。用户提到"修源""测试某个源""详情为空""播放不通""搜索异常""源无效""低分评估""源评分低""诊断""排障""修播放""源不通""规则不生效""评估低分"时使用。负责先评估、再分流、再收束上传建议；不直接执行仓库上传/替换/改标签。

⚠️ 已归档（2026-07-17）：本 skill 已被 drpy-node-coder 取代。coder 融合了 4 个旧 skill（workflow/create/play-debug/repo-upload）的全部工作流，并自带 scripts/cli.js CLI 替代 drpy-node-mcp 服务——一个 skill、无需安装 MCP。本文件保留仅供历史参考，新工作请直接用 drpy-node-coder。

drpy-node Source Workflow

快速索引

输入/问题	诊断目标	分流
已有源评估低分	判断 A 规则不通 / B 串联断 / C 播放链	本 skill 修复或转 play-debug
只有网址	判断新建还是修复	转 source-create
URL + 自动做源/修到100/上传	alive check → 建源 → evaluate → 修复 → 上传	本 skill 总控编排
detail 正常但 play 异常	播放链专项	转 play-debug
用户要求上传/替换/改标签	发布守门	转 repo-upload

执行契约

• 输入：源名/源文件/URL/评估结果/用户目标。
• 输出：证据链分级诊断、分流路线、修复后验证结果、上传建议。
• 原则：先评估 → 再分流 → 再修复 → 再验证 → 最后给上传建议/结束。

模式闸门：先判断是否允许写入

用户模式	允许动作	禁止动作
只读 / 规划 / dry-run / 不要改文件 / 不要上传	读取、诊断、拆证据链、给修复计划和验证命令	drpy_edit_file、drpy_write_file、仓库上传/替换/改标签
需要确认后再改	读取、诊断、输出拟改字段和验证计划	未确认前禁止改源或仓库元数据
明确要求执行	按 L1/L2/L3 证据链最小修复	不跳过大改确认点，不直接做仓库 mutation
自主全流程	alive check、分流建源、低风险修复、播放专项、L3=100 后转上传	坏站硬写、未达目标冒充完成、仓库目标不明时上传

如果用户说“只诊断 / 不要改 / dry-run”，本 skill 输出证据链、根因判断、拟改字段和验证计划后停止。

Reference Map

任务	首读 reference
总控分流 / 评估失败 triage	references/references-workflow-triage.md
模板摘要与 * 继承	references/references-template-summary.md
引擎调度 / evaluate 串联机制	references/references-framework-internals.md
搜索异常	references/references-search-strategies.md
async / API / detail 字典细节	../drpy-node-source-create/references/...

调度优先级

当本地环境已安装本 Skill 时：

• 本地 Skill 优先级 高于 drpy-node MCP 的通用 prompts
• 当用户只给网址、不给文件名时，总控层应主动分析站点并推导源名

强约束

如果本地 Skill 已覆盖场景，不允许让 MCP 通用 prompt 抢占主流程。

自主全流程模式

当用户明确说“自动完成”“修到100”“满分后上传”“不要中途问我”“给网址做源并上传”时，本 skill 作为总控编排器，使用 packet 贯穿子 skill：

URL → alive check → source-create → L1/L2/L3 → 按丢分最小修复 → play-debug → L3=100 → repo-upload → info核验

执行规则：

1. 先识别 autonomous=true、target_score=100、upload_preauthorized=true/false、tags、is_public。
2. 先做 alive check；broken_site、hard_anti_bot、missing_credentials 直接停止，不建源、不上传。
3. 站点可用时转 source-create 建源；source-create 返回源路径、站型、五接口结果和 L3 分数。
4. L3 未满 100 时按丢分接口拆 L2：home/category/detail/search 在 workflow/source-create 修；play 带真实 ids/play_url/flag 转 play-debug。
5. 回收 play-debug 的 autonomous_next：continue_evaluate 继续 L3；stop_for_user 停止并报告 blocker。
6. L3=100 且上传已预授权时，带本地路径、A/B/C、L1/L2/L3、tags/is_public 转 repo-upload。
7. 自主模式下普通检查点只记录证据不中断；遇到 high_risk_change、仓库目标歧义、凭据缺失时必须停手确认。

自主 handoff packet 必含：

autonomous: true/false
target_score: 100
upload_preauthorized: true/false
tags: 用户明确标签或空
is_public: 用户明确可见性或空
source_name/path: ...
blocker_type: none / broken_site / hard_anti_bot / missing_credentials / high_risk_change / ambiguous_upload / score_below_target
autonomous_next: continue_evaluate / return_workflow / stop_for_user

---

以下排查项对模板站/签名接口站/纯 API 站都适用。只要源中有 async function，就必须先过这个清单。

完整参考：../drpy-node-source-create/references/references-async-function-patterns.md

优先级	检查项	症状
P0	源身份一致：文件路径、源名、host、@header 类型与当前目标匹配	修错源、影视/漫画/小说类型漂移
P0	this.input 是 URL 不是响应	JSON.parse(this.input) 报错含 URL
P0	detailUrl 是否设置	二级全部为空
P0	POST 用 body 不是 data	搜索/一级 POST 请求服务端不认
P0	searchUrl 带 **	this.KEY 为空
P1	推荐完整聚合	推荐只有几条
P1	不手动拼 URL	代码冗余且易出错
P2	不写重复属性	维护混淆

强约束

不要因为"这是模板站"就跳过这些检查。只要源中有 async function，就必须先过通用清单。

---

总控闭环（5 步）

用户输入
   │
   ▼
Step 1: 识别输入类型 ──仅有网址──→ 分析站点 → 转 source-create
   │
   ├─已有源名/文件
   ▼
Step 2: 评估现状 (L1语法→L2单接口→L3 evaluate)
   │
   ▼
Step 3: 判断失败类型
   ├─ A 规则不通 → 本 skill 修复
   ├─ B 评估串联 → 本 skill 排查
   ├─ C 播放链   → 转 play-debug
   └─ 新建场景   → 转 source-create
   │
   ▼
🛑 检查点 1: 确认诊断结论
   │
   ▼
Step 4: 分流执行
   │
   ▼
Step 5: 收束 → 🛑 检查点 2 → 结束 / 转 repo-upload

Step 1：识别输入类型

• 仅有网址 → 先分析站点并推导源名
• 已有源名/源文件 → 进入修复与评估流程

Step 2：评估现状

1. drpy_read_file 读取源文件，确认源名、host、@header 类型和用户目标一致
2. drpy_check_syntax + validate_spider 基础校验
3. get_resolved_rule（模板站适用），记录继承后的 class_parse/url/searchUrl/play_json/play_parse/sniffer/isVideo
4. evaluate_spider_source 全流程评估
5. 记录证据链：每个结论必须能对应到工具输出（语法/结构/单接口/全流程）

Step 3：判断失败类型

诊断工具调用（MCP 真实字段示例）：

# 逐接口拆分验证
test_spider_interface(source_name='源名', interface='category', class_id='分类ID')
test_spider_interface(source_name='源名', interface='detail', ids='一级返回的真实 vod_id')
test_spider_interface(source_name='源名', interface='search', keyword='高频宽匹配词')
test_spider_interface(source_name='源名', interface='play', play_url='二级返回的播放地址', flag='线路名')

单接口测试必须使用上游真实返回值：category → vod_id → detail → play_url，不要手推 ID。

• A. 规则本身不通 → 单接口 test 也失败
• B. 评估器没串起来 → 单接口通但 evaluate 不通（见「专项排查参考」→「评估器失败分流」B类优先检查）
• C. 主要卡在播放链 → detail 正常但 play 异常

🛑 检查点 1：确认诊断结论

在进入分流前，向用户呈现诊断摘要：

## 诊断结论
- 首页：通/不通
- 一级（category）：通/不通
- 二级（detail）：通/不通
- 搜索：通/不通
- 播放：通/不通
- 失败类型：A（规则不通）/ B（评估串联）/ C（播放链）
- 证据链等级：L1=语法结构；L2=单接口；L3=全流程 evaluate
- 关键工具输出：...（列出支撑结论的工具和结果）
- 建议路线：继续本 skill 修复 / 转 source-create / 转 play-debug / 转 repo-upload / 结束
- 用户确认后再进入修复；自主全流程模式下，低风险最小修复不暂停，只记录本摘要并继续执行

Step 4：分流

问题类型	分流目标
新建源	drpy-node-source-create
播放链问题	drpy-node-play-debug
上传仓库	drpy-node-repo-upload
站型判断不清	按 Step 3 重新诊断

Step 5：收束

• evaluate_spider_source 重新评估
• 给出是否有效结论
• 决定是否建议上传/替换/回滚；需要仓库动作时转 drpy-node-repo-upload，不在 workflow 内直接操作 house_file

🛑 检查点 2：确认操作方案

在收束前向用户确认：

## 修复结果摘要
- 已修复：...（接口和改动简述）
- 仍未通：...
- 建议上传：A（建议上传）/ B（技术上可传）/ C（暂不应上传）

用户确认后再转 repo-upload 处理上传/替换/标签等仓库动作，或结束；自主全流程模式下若 L3=100、A 档、upload_preauthorized=true 且 tags/is_public/目标明确，可直接转 repo-upload 执行上传核验

强约束

不要把 workflow 变成"所有事都自己做完"。它的价值在于：先评估 → 再分流 → 最后收束。

工具证据链分级

等级	已执行工具	能支持的结论	不能直接下的结论
L1	drpy_check_syntax + validate_spider	源非语法残档、rule 结构基本合法，可进入接口拆测	源可用、已修好、建议上传
L2	test_spider_interface 单接口	某个接口真实通/断、定位 failure point；必须说明接口名和真实输入	全链路稳定、可作为最终版发布
L3	evaluate_spider_source	首页→一级→二级→播放→搜索串联评分；可支持上传建议	站点长期稳定

结论必须带等级：例如“L2 证据显示 detail 通、play 断”，不要说成“整个源不通”。L1 只能作为继续拆测的门槛，不能包装成“可用/已修好/可上传”。

大改确认点

以下情况必须先给出方案并等用户确认：

• 从模板继承改为全 async。
• 删除大段已有规则或重写推荐/一级/二级/搜索。
• 需要登录态、Cookie、Token 或复杂签名逆向。
• 准备上传、替换仓库文件或回滚改动；自主全流程中，只有 L3=100、A 档、用户已预授权且目标/tags/is_public 明确的 repo-upload handoff 可免二次确认。

确认模板：

## 修复方案确认
- 当前证据链：L1 / L2 / L3
- 根因判断：A / B / C
- 拟改字段：...
- 为什么不是更小改动：...
- 验证计划：...

分流输出契约

转交子 skill 前，必须带上 handoff packet，避免子流程重新摸索；缺少关键上下文时先补上游真实值，不要空转交接。

分流目标	必带上下文	子流程完成后回收什么	缺失时先做什么
source-create	URL、推导源名、站型证据、用户目标、autonomous/target_score/upload_preauthorized/tags/is_public	新源文件路径、五接口验证结果、L3 分数、blocker_type	先确认这是新建而非修已有源
play-debug	source_name、真实 ids、play_url、flag、detail 输出摘要、继承后的 play_json/play_parse/sniffer/isVideo、autonomous	lazy 根因、修改字段、同一 play_url 复测结果、autonomous_next	缺少 ids/play_url/flag 时先测 detail，不直接转
repo-upload	本地文件路径、源名、内容类型、A/B/C 建议、L1/L2/L3 证据、用户明确 tags、upload_preauthorized/is_public	file_id、cid、tags、info 核验	缺少路径/标签意图时先确认目标

子 skill 不可用时，按本 skill 的证据链先输出诊断，不要临时拼一个不完整替代流程。

---

A/B/C 路由速判

当前证据	路由	禁止事项
L1 失败	先修语法/结构	不跑 evaluate 冒充全链路
category 失败	修一级/url/class_parse	不直接修 detail/play
category 通、detail 空	修 detailUrl/二级字典/lists	不转 play-debug
detail 通、play 假通过/空	转 play-debug	不把 play success 当可播
单接口通、evaluate 首页/一级丢分	B 类串联排查	不重写整源
五接口与 evaluate 都通过	进入上传建议；自主最终版要求 L3=100 后转 repo-upload	不绕过 repo-upload 核验

---

安全边界

动作类型	可直接做	需要确认
只读诊断	读源、语法结构校验、单接口测试、evaluate	无
最小修复	改单个字段、修 selector、补 detailUrl/searchUrl	改动前给出字段和验证计划
高风险重写	模板改全 async、删除大段逻辑、引入签名/登录态	必须等用户确认
仓库动作	自主全流程中 L3=100、A 档、upload_preauthorized=true 且目标/tags/is_public 明确时，可转 repo-upload 执行	上传、替换、改标签、公开/私密的歧义目标或非预授权操作必须确认

Reference 使用规则

本 skill 引用两类资料：

• 本地总控 reference：references/references-workflow-triage.md、references/references-template-summary.md、references/references-framework-internals.md、references/references-search-strategies.md。
• 子 skill reference：../drpy-node-source-create/references/...，用于 async、纯 API、二级字典等细节。

如果某个 reference 文件不可达，不要中断诊断；按本文件内的 P0/P1 清单继续最小排查，并在输出中标注“reference 未读取，依据本 skill 内置规则处理”。

---

子 skill 不可用时的兜底

场景	本 skill 可兜底完成	必须停止的边界
URL-only 新建	完成站型判断、源名推导、建源方案草案	实际写新源应回到 source-create 或等用户确认
播放链异常	确认 detail 稳定、提取 play_url/flag、判定是否假通过	lazy 多分支重写交给 play-debug
上传/标签	给出 A/B/C + L1/L2/L3 建议	仓库元数据变更必须交给 repo-upload

这样即使子 skill 暂不可用，也能完成“诊断与分流”，但不冒充完成专门实现。

---

专项排查参考

模板站排查路线

当站点命中内置模板但评估不顺时，严禁直接大面积手写覆盖。

排查顺序（按此顺序逐项检查）

1. 查模板默认定义 → references/references-template-summary.md
2. class_parse 是否残留覆盖？→ 补 class_parse: ''
3. double 是否导致推荐空？→ 补 double: false
4. 真实分类 url → 必须验证真实分类页和翻页
5. 真实搜索 searchUrl
6. 删除手写 一级/搜索，优先验证模板内置规则
7. test_spider_interface 拆开验证各接口
8. 最后才允许最小覆盖

强禁止

未完成 1~7 之前，禁止一口气重写 推荐/一级/搜索/二级。

关键原则

不要把模板问题、分类 URL 问题、评估器串联问题，误当成单纯的一级选择器问题。

---

纯 API 站排查路线

当页面源码为空、所有数据走 JSON API 时，走此路线（不套用模板站 checklist）。

完整参考：../drpy-node-source-create/references/references-pure-api-async-site.md

排查顺序

1. this.input 是否被误当响应 → 必须 await request(this.input)
2. detailUrl 是否设置 → 纯数字 vod_id 必须设
3. 搜索 searchUrl 是否带 ** → 否则 KEY 为空
4. POST 是否用了 body 而非 data
5. 外部 API 是否需要 Authorization
6. 推荐是否完整聚合

强约束

纯 API 站排障路线与模板站完全不同，不要混用模板站的 checklist。

---

评估器失败分流

类型	表现	处理
A. 规则不通	单接口 test 也失败	修复规则本身
B. 评估没串起来	单接口通，评估不通	检查首页 class / class_parse / double / url / searchUrl

B 类分数速映

evaluate_spider_source 各接口分数可快速映射到排查步骤：

丢失分数段	指向问题	对应步骤
首页 20 分 + 一级 20 分同时丢失	class_parse 未命中导致 class 为空	Step 2-3
仅首页 20 分丢失，一级正常	double 配置不匹配	Step 4
仅搜索 10 分丢失	searchUrl 错误或搜索页 DOM 独立	Step 5
二级 25 分丢失	detailUrl 缺失或二级字段映射错误	见「二级 detail 规范」
播放 25 分丢失	lazy 逻辑异常	转 drpy-node-play-debug

B 类优先检查（顺序执行，逐项排查）

Step 1. 查 get_resolved_rule(path) → 看模板继承后的 class_parse/double/url 是否被覆盖
Step 2. 查首页 class 是否为空 → class_parse 是否命中（未命中 → 补 class_parse）
Step 3. 查 class_parse 是否残留覆盖 → 显式设 class_parse: ''
Step 4. 查 double 是否导致推荐为空 → 单层推荐优先 double: false
Step 5. 查分类 url / 搜索 searchUrl 是否真实
Step 6. 查手写 一级/搜索 是否反而扰乱模板内置链路（删除手写，先用模板内置）

B 类深层机制理解

B 类失败的根本原因在于评估器串联机制与模板继承机制的交互。排查时先记住完整初始化链：

init() → getSandbox()/vm.createContext → 执行源文件获得 rule
      → handleTemplateInheritance() → initParse() → invokeMethod()

含义：

• 源运行在沙箱中，不能假设 require/fs/process 可用；只能用沙箱注入的 request/pdfh/pd/CryptoJS/local 等能力。
• handleTemplateInheritance() 发生在正式调度前，源中显式字段会覆盖模板字段。
• initParse() 会处理 host、headers、URL 模板、预处理等运行态配置；这些异常会表现为后续接口通断问题。
• invokeMethod() 再按 推荐/一级/二级/搜索/lazy 和字段类型分流。

// 引擎 invokeMethod 分发逻辑 (drpyS.js)
switch (method) {
    case '推荐': injectVars = homeVodParse(...); break;  // 依赖 class + double
    case '一级': injectVars = cateParse(...); break;     // 依赖 url 模板渲染
    case '分类': injectVars = homeParse(...); break;      // 依赖 class_parse
}

• 首页空分类 → 后续 category 无 class_id 可用 → 全链断裂
• class_parse 未命中 → class 为空 → 评估器拿不到分类 ID
• get_resolved_rule(path) 可查看模板继承后的最终字段值，快速判断哪个字段被覆盖

详见 references/references-framework-internals.md 第七章节「调度分发机制」。

---

搜索排查

搜索词适配（高频误判点）

当自动评估仅搜索失败，其他接口正常时：

1. 不要立刻判定"搜索规则失效"
2. 不要急着改 searchUrl
3. 应先换高频宽匹配词验证（通用词 我的，动漫站 异世界，或取一级 vod_name 片段）
4. 换词后正常 → 判定为评估参数问题

搜索策略参考

处理搜索前必须先判断属于：

1. 原生搜索接口
2. suggest / 联想搜索 fallback
3. RSS fallback

参考：references/references-search-strategies.md

---

二级 detail 规范

完整参考：../drpy-node-source-create/references/references-detail-dict-and-multiep.md

测试输入

• detail 测试必须使用一级真实返回的 vod_id
• 禁止主观简化为纯数字 id 或手推 id
• 正确顺序：先跑 category → 取真实 vod_id → 再测 detail

字典槽位

• desc 五段有固定语义：备注;年份;地区;演员;导演

多集只吐 1 集

先查 lists 容器层级（从 ul 下沉到 li），用 debug_spider_rule(pdfa) 验证各层项数。不要直接切 async。

# 排查示例
debug_spider_rule(url, '.anthology-list-box ul li a', pdfa)
# 先看 ul 层返回几项 → 再看 li 层返回几项
# 若 ul 层返回1项但 li 层返回多项 → lists 容器需从 ul 下沉到 li

如果 CSS 层级调整后仍只有 1 集，再用 test_spider_interface(detail) 配合真实 vod_id 复现，确认是否 detailUrl 缺失或二级字典字段映射错误。详见 ../drpy-node-source-create/references/references-detail-dict-and-multiep.md。

最小化原则

先保证 标题/描述/详情/图片/线路/列表，不强补 年份/地区/演员/导演。

---

* 模板字段理解

当模板字段中出现 搜索: '*' 或含多个 * 的摘要写法时，必须先读：

• references/references-template-summary.md

当前理解

• 单个 *：整体继承一级
• 多个 *：按分号位置逐位继承一级对应槽位

强约束

不要在没理解 * 的源码级行为前，就机械改写成完整手写规则。

---

parser 语法边界

当规则"看起来合理但接口异常"时：

1. 是否超出 parser 已明确支持的边界？
2. 应先修规则写法，而非要求引擎兼容
3. || 优先用于同一 selector 属性 fallback（img&&data-original||src）
4. 不要生成跨 selector fallback（img&&data-original||img&&src）

收尾输出模板

## 修源结果
- 源：...
- 证据链等级：L1 / L2 / L3
- 根因类型：A 规则不通 / B 评估串联 / C 播放链 / 其他
- 已改动字段：...
- 验证结果：
  - home：...
  - category：...
  - detail：...
  - search：...
  - play：...
  - evaluate：.../100
- 上传建议：A 建议上传 / B 技术可传但不建议 / C 暂不应上传
- 下一步：转 play-debug / 转 repo-upload / 继续修复 / 结束

先尊重引擎设定，再要求更宽容的兼容。