| name | drpy-node-repo-upload |
| 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 Repo Upload
快速索引
| 用户意图 | 入口流程 | 终止条件 |
|---|
| 上传/替换源 | L1 校验 → A/B/C 档 → 用户确认 → upload → info 核验 | 上传后元数据一致 |
| 自主流程 L3=100 后上传 | house_verify → 确认 L3=100/A档/目标明确 → upload → info 核验 | file_id/cid/tags/is_public 一致 |
| 只检查不传 | L1/L2/L3 按目标验证 → 输出结论 | 不进入上传 |
| 只改标签 | house_verify → list 定位 → info 确认 → update_tags | 标签核验一致 |
| 改公开/私密 | house_verify → list 定位 → toggle_visibility → info 核验 | 可见性一致 |
执行契约
- 输入：本地源文件名/仓库文件关键词/file_id/cid/标签要求/是否公开。
- 输出：上传前 A/B/C + L1/L2/L3 依据，上传或修正后的 file_id/cid/tags/is_public。
- 原则：上传前先校验，用户怎么要求标签就怎么执行，上传后必须可追踪。
模式闸门：先判断是否允许写入
| 用户模式 | 允许动作 | 禁止动作 |
|---|
| 只读 / 规划 / dry-run / 不要上传 / 不改标签 | 读取、校验、给 A/B/C 判断、列拟调用参数 | house_file(upload/replace/update_tags/toggle_visibility) |
| 需要确认后再操作 | house_verify、定位对象、输出确认模板 | 未确认前禁止仓库 mutation |
| 明确要求执行 | 按 L1/L2/L3 和 A/B/C 规则执行 | 不跳过 house_verify、目标确认和 info 核验 |
| 自主全流程 | 用户已预授权且 L3=100/A档/路径/tags/is_public/目标明确时直接上传并核验 | L3<100、B/C 档、目标冲突或 tags/is_public 不明时上传 |
如果用户说“只检查 / dry-run / 不要真的上传”，本 skill 只能输出验证依据、风险和拟操作参数。
自主全流程上传模式
当上游 workflow/source-create 明确传来 upload_preauthorized=true，表示用户最初已经要求“修到100后自动上传”。此时满足全部条件才可免二次确认直接上传：
evaluate_spider_source == 100，证据等级为 L3，档位为 A。- 本地文件路径、源名、内容类型自洽。
- tags、is_public、auto_replace 策略明确；用户明确 tags 时严格按用户要求。
house_verify 通过。- 仓库对象无多候选、file_id/cid 冲突或同名歧义。
执行顺序固定：
house_verify → house_file(upload, auto_replace=true) → house_file(info, cid=...) → 回报 file_id/cid/tags/is_public
必须停手并回传 workflow 的情况：
| blocker_type | 表现 | 动作 |
|---|
score_below_target | 用户要求最终版/100 分，但 L3<100 | 不上传，回传继续修复或报告断点 |
ambiguous_upload | 多同名候选、file_id/cid 冲突、tags/is_public 不明确 | 不上传，列出需确认项 |
high_risk_change | 需要替换非同名对象、改公开状态或合并标签规则不清 | 不上传，等用户确认 |
自主上传也不能省略 info 核验；核验不一致时只报告差异，不静默二次修改。
|---|---|
| A/B/C 上传建议 | references/references-upload-decision.md |
| L1/L2/L3 验证深度 | references/references-upload-decision.md |
| 自动标签检测 | references/references-upload-decision.md |
| fallback 搜索 / 单接口风险 | references/references-upload-decision.md |
drpy-node 的仓库发布守门 skill。
目标：上传前先过红线检查，上传后结果可追踪，标签严格按用户要求执行。
本 skill 只负责什么
- 上传到仓库
- 同名替换上传
- 标签修正
- 公开 / 私密切换
- 上传前检查与上传后回报
不负责什么
适用场景
当用户说这些时启用：
- 上传到仓库
- 替换上传
- 改标签
- 仓库里这个文件的信息
- 改公开/私密
- 上传前帮我检查一下
上传前决策树
用户输入
│
▼
边界检查：是修源/修播放/建源？──→ 转 workflow/play-debug/source-create
│
▼
最低校验：syntax + validate + metadata 自洽
│
▼
分档判断：A(建议) / B(可传不建议) / C(暂不传)
│
▼
🛑 检查点：展示 A/B/C 依据 + 拟操作
│
▼
执行：house_file(upload/replace) → info 核验
│
▼
回报 file_id + cid + tags + is_public
快速决策
当用户说“上传仓库 / 替换上传 / 帮我先检查一下能不能传”时，优先按下面顺序快速决策：
- 先看是不是本 skill 的边界内问题
- 如果用户其实是在要求修源 / 修播放 / 从零建源 → 先交回 workflow / play-debug / source-create
- 先过最低校验线
- 至少跑：
drpy_check_syntax + validate_spider
- 同时检查源内 metadata：
@header 的 title/类型/lang/searchable/filterable/quickSearch 与实际验证能力一致
- 再分 A / B / C 档
- A：建议上传
- B：技术上可传，但不建议直接传
- C：暂不应上传
- 最后才执行上传动作
- 默认优先：
house_file(action='upload', auto_replace=true)
强提醒
不要把“技术上能上传”直接说成“建议现在上传”。
如果用户目标是“修好再传 / 修到满分再传”，就必须把这层判断单独说清楚。
只检查 vs 检查后上传
| 用户表达 | 最低验证 | 允许结论 | 下一步 |
|---|
| “先检查能不能传” | L1 | 只能说语法/结构层面可进入下一步 | 不上传，除非用户继续要求 |
| “检查没问题就上传” | L2 | 可给 A/B/C 初判；A 才建议上传 | 展示确认模板后上传 |
| “最终版/修好后上传” | L3；自主全流程要求 L3=100 | 可给完整 A/B/C 发布建议 | B/C 停止；普通模式 A 再确认上传，自主预授权且目标明确时直接上传 |
| “先传再说” | L1 | B 档可执行但必须说明风险 | 用户确认后上传 |
上传前红线
满足任一就不要直接上传，除非用户明确要求“先传再说”：
- 语法报错
- 结构无效
- 源名、host、
@header 类型或能力 metadata 与实际源不一致
- 详情为空
- 一级字段不规范
- 播放仍是假通过，但却准备当成已修好上传
- 特殊内容源没有返回对应协议或有效内容
- 标签规则未确认，但用户明显在意标签
C 档回传规则
触发 C 档、播放假通过、metadata/tags 冲突或对象不明确时，停止上传并回传：
- 文件路径 / 仓库对象
- 触发红线
- 当前验证等级：L1 / L2 / L3
- 建议下一步：workflow / play-debug / 用户确认标签或对象
上传档位与验证深度
上传建议必须同时给出 A/B/C 档和 L1/L2/L3 证据等级：
| 验证等级 | 必跑工具 | 可支持结论 | 适用场景 |
|---|
| L1 语法结构 | house_verify + drpy_check_syntax + validate_spider | 文件结构可进入下一步，不能给 A 档 | 用户只要求“先检查能不能上传” |
| L2 单接口 | L1 + test_spider_interface 关键接口 | 窄范围修复后的技术上传判断 | 用户要求“修好这个问题再传” |
| L3 全流程 | L1 + evaluate_spider_source | 可给 A/B/C 完整发布建议 | 用户要求“最终版/修好后上传” |
| 档位 | 结论 | 最低证据 | 动作 |
|---|
| A | 建议上传 | L2；最终版/自主上传要求 L3=100 | 普通模式用户确认后上传；自主预授权且目标明确时直接上传 |
| B | 技术可传但不建议 | L1 或 L2 | 说明风险，用户坚持才上传；自主最终版不上传 |
| C | 暂不应上传 | 任意等级发现红线 | 不上传，转 workflow/play-debug |
禁止在只有 L1 时给出 A 档；只能说“语法结构层面可进入下一步”。“最终版/修好后上传”必须有 L3 证据；L2 只能支撑针对某个已验证接口的技术上传判断。
标签规则（速查版）
总原则
- 不自己脑补标签
- 不因为文件名带
[优] 就自动加 优
- 用户没明确说要什么时，默认从简
示例
- 用户说“只要 ds” →
ds
- 用户说“ds 和优” →
ds,优
- 用户说“别乱打标签” → 只保留明确要求的标签
发现标签错了怎么办
- 先用
house_file(list) 按文件名搜索定位仓库文件，获取 file_id
- 再用
house_file(action='info', cid=...) 确认当前标签
- 然后
house_file(action='update_tags', file_id=..., tags='...') 修正
- 回报最终标签
独立标签修正流程（不经过上传）
当用户仅要求改标签不上传时：
house_verify 验证仓库连通性house_file(list) 搜索定位文件（源名不明确时）- 确认当前 tags
- 执行
update_tags
- 按「标签修正模板」回报结果
自动标签检测
house_file(upload) 内部有自动类型检测逻辑（详见 references/references-upload-decision.md 第三节）。
用户没有明确要求标签时，可利用自动检测作为默认值。但用户明确要求标签时，以用户要求为准。
metadata 与仓库 tags 分离
源内 @header / rule metadata 描述运行时身份和能力；仓库 tags 是上传记录的检索标签，二者不能互相替代。用户明确指定 tags 时优先执行用户要求；自动标签检测只作为默认值，上传后必须用 info 核验实际 tags。
替换上传 vs 新建上传
默认策略
优先：
house_file(action='upload', auto_replace=true)
适合替换上传
- 同名文件已存在
- 用户要更新最新版
- 不需要保留并行新条目
只有这些情况才考虑新建
- 用户明确要求保留独立新条目
- 同名但本质是不同源
- 需要同时保留多个版本
references：上传前判断参考
如涉及”这个源到底算不算修好、应不应该传”，必须参考：
references/references-upload-decision.md
仓库对象定位规则
| 用户给的信息 | 定位方式 | 需要确认 |
|---|
| 本地源名/路径 | list_sources() 或直接校验路径 | 是否就是要上传的文件 |
| 仓库关键词 | house_file(action='list', search='关键词') | 多个匹配时让用户选 file_id |
| file_id | 用于 replace/update_tags/toggle_visibility | 操作对象名称和当前 tags/is_public |
| cid | house_file(action='info', cid='...') | info 返回的 file_id 是否与目标一致 |
如果 list 返回多个同名/近似文件，不要凭排序选择；必须列出候选并确认。
如果用户同时给出 file_id 与 cid 且二者不一致，停止操作并要求确认真实目标。
如果用户同时要求“只要 ds”又要求“保留原标签”，优先提问澄清，不自行合并。
非上传变更核验
update_tags、toggle_visibility、replace 与上传一样必须核验结果：
- 操作前用
house_file(info, cid=...) 或 house_file(list) 记录当前对象。
- 操作后再次
house_file(info, cid='目标 cid')；如果只有 file_id 没有 cid，先用 list/info 找到 cid。
- 核验字段：file_id、cid、filename、tags、is_public。
- 不一致时只报告差异并询问下一步，不静默二次修改。
边界条件处理
源文件名不明确
用户只说”这个源”而不提供具体源名或路径：
- 先用
list_sources() 列出 spider/js/ 下所有源文件
- 结合用户描述（如”上次修的动漫源”）缩小范围
- 确认最终文件名后再继续
- 不要假设唯一匹配而跳过二次确认
仓库文件不明确
用户说”仓库里这个文件”但不提供 file_id：
- 先用
house_file(list) 按文件名关键词搜索仓库文件
- 获取匹配文件的 file_id 后再执行 update_tags / toggle_visibility 等操作
- 不要混淆
list_sources()（本地文件）和 house_file(list)（仓库文件）
house_verify 失败
仓库连接无法建立时：
- 检查
manage_config(get) 确认 HOUSE_TOKEN 和 HOUSER_URL 配置
- 如配置为空或错误，提示用户补充
- 不要跳过验证直接执行上传操作
上传网络错误
上传请求因网络问题失败时：
- 区分是服务端拒绝（4xx/5xx）还是连接超时
- 连接性问题：提示稍后重试，不自动重试
- 服务端拒绝：检查文件大小、格式、权限，必要时确认 TOKEN 有效性
标签更新失败
house_file(update_tags) 返回错误时：
- 检查 file_id 是否正确（用
house_file(list) 交叉验证）
- 检查 tags 格式是否合规（逗号分隔的字符串）
- 确认 TOKEN 对该文件有修改权限
快速入口选择
根据用户意图选择入口：
| 用户意图 | 入口流程 |
|---|
| 上传/替换源 | 走 Step 1 → Step 6 完整流程 |
| 只检查不传 | 走 Step 1(校验) → Step 3 → 输出结论 → 终止（不进入 Step 4 上传） |
| 只改标签 | 走 house_verify → house_file(list) 定位 → update_tags → 回报 |
| 切换公开/私密 | 走 house_verify → house_file(list) 定位 → toggle_visibility → 回报 |
标准流程
Step 1：确认源文件 + 验证仓库连接
- 源名不明确 → 先用
list_sources() 列出文件，二次确认后再继续
house_verify — 验证仓库连通性；失败时按「边界条件处理」章节排查
Step 2：检查是否满足上传条件
最少检查：
drpy_check_syntaxvalidate_spider- 源名 / host /
@header 类型 / lang / 搜索筛选能力与当前源一致
如用户要求”修好后再传”，建议补：
evaluate_spider_source- 或关键接口单测
特殊内容源不以 m3u8/mp4 为唯一上传标准：漫画看 pics:// 图片列表，小说看 novel:// 或正文内容，音乐看 mp3/m4a 直链，网盘/投屏看 push:// 或对应提取逻辑。
🛑 检查点：确认检查结果再继续
在进入 Step 3 前，先向用户呈现：
- 语法/结构校验结果
- 初步 A/B/C 档判断
- 用户确认后再继续执行或终止
强制工具检查点
在给出“A / B / C 档判断”前，至少应明确自己已经做了哪类工具验证：
- 只做了
drpy_check_syntax / validate_spider → 只能说明“语法/结构层面”
- 做了
evaluate_spider_source 或关键接口单测 → 才能进一步说明“接口可用性层面”
禁止在完全没有说明验证依据时，直接下结论“建议上传 / 不建议上传”。
Step 3：判断是否建议上传
必须输出 A/B/C 档位和 L1/L2/L3 验证依据：
- A：建议上传
- B：技术上可传，但不建议直接上传
- C：暂不应上传
根据用户意图分支：
- 用户目标是"只评估不传"或"修好再传"且当前为 B/C 档 → 输出结论后终止，不进入 Step 4
- 用户目标是立即上传且当前为 A/B 档 → 继续 Step 4
🛑 元数据变更确认点
以下操作会改变仓库可见状态或元数据，执行前必须展示目标对象并确认；自主全流程上传模式除外，但必须满足 L3=100/A档、upload_preauthorized=true、目标/tags/is_public 明确且 house_verify 通过：
update_tagstoggle_visibilityreplace- 带
auto_replace=true 的上传
确认模板：
## 仓库操作确认
- 操作：upload / replace / update_tags / toggle_visibility
- 目标：file_id=... / cid=... / 文件名=...
- 当前 tags/is_public：...
- 目标 tags/is_public：...
- 验证依据：L1 / L2 / L3
Step 4：执行仓库操作
确认后按用户目标执行：
# 上传/同名替换
house_file(action='upload', path='spider/js/源名.js', auto_replace=true, tags='用户确认的标签', is_public=true/false)
# 仅标签修正
house_file(action='update_tags', file_id=目标ID, tags='用户确认的标签')
# 仅可见性切换
house_file(action='toggle_visibility', file_id=目标ID)
Step 5：回报结果
必须回报：
- 文件名
- file_id
- cid
- tags
- 是否公开
- 是新上传还是替换上传
- 上传后核验：用返回的
cid 调 house_file(action='info', cid=...) 确认仓库记录与期望一致
Step 5.5：上传后核验
上传或替换成功后，除非工具返回已经包含完整元数据，否则补一次：
house_file(action='info', cid='上传返回的 cid')
核验重点：
- 仓库记录是否能查到
- tags 是否符合用户明确要求或自动检测预期
- is_public 是否符合用户要求
- file_id/cid 是否与上传返回一致
如果核验不一致，先回报差异，再询问是否修标签或可见性，不要静默二次修改。
Step 6：必要时修标签
house_file(action='update_tags')
🛑 检查点：确认操作结果
上传/标签修正完成后向用户呈现：
- 文件名、file_id、CID、tags
- 上传后 info 核验结果
- 是否公开
- 操作类型（新上传 / 替换上传 / 标签修正）
- 用户确认后可继续修标签或结束
推荐输出模板
上传结论模板
## 上传前结论
- 语法：通过 / 未通过
- 结构：通过 / 未通过
- 源 metadata：title/类型/lang/搜索筛选能力是否自洽
- 关键接口：home/category/detail/play/search 结果摘要
- 特殊内容：pics:// / novel:// / push:// / 音频直链等协议是否符合内容类型
- 档位判断：A（建议上传）/ B（技术上可传，不建议）/ C（暂不应上传）
- 验证依据：L1(语法结构) / L2(单接口) / L3(全流程)
- 原因：...
上传结果模板
## 上传结果
- 文件名：...
- 仓库 ID：...
- CID：...
- 标签：...
- 可见性：公开 / 私密
- 上传类型：新上传 / 替换上传
- info 核验：一致 / 不一致（差异：...）
标签修正模板
## 标签修正结果
- 文件名：...
- 仓库 ID：...
- CID：...
- 旧标签：...
- 新标签：...
- 修正方式：update_tags
明确禁止事项
- 不要未测就上传
- 不要标签乱打
- 不要把半成品说成最终版
- 不要用户说只要
ds 时还附加别的标签
- 不要上传后只说“传好了”，不报 file_id / cid / tags
