ant-video/ant-video/drpy-node-repo-upload

drpy-node Repo Upload

drpy-node 的仓库发布守门 skill。

目标：上传前先过红线检查，上传后结果可追踪，标签严格按用户要求执行。

本 skill 只负责什么

• 上传到仓库
• 同名替换上传
• 标签修正
• 公开 / 私密切换
• 上传前检查与上传后回报

不负责什么

• 不负责深度修源
• 不负责播放专项排查
• 不负责新建源

适用场景

当用户说这些时启用：

• 上传到仓库
• 替换上传
• 改标签
• 仓库里这个文件的信息
• 改公开/私密
• 上传前帮我检查一下

上传前 30 秒决策树（新增）

当用户说“上传仓库 / 替换上传 / 帮我先检查一下能不能传”时，优先按下面顺序快速决策：

1. 先看是不是本 skill 的边界内问题

• 如果用户其实是在要求修源 / 修播放 / 从零建源 → 先交回 workflow / play-debug / source-create

1. 先过最低校验线

• 至少跑：check_syntax + validate_spider

1. 再分 A / B / C 档

• A：建议上传
• B：技术上可传，但不建议直接传
• C：暂不应上传

1. 最后才执行上传动作

• 默认优先：house_file(action='upload', auto_replace=true)

强提醒

不要把“技术上能上传”直接说成“建议现在上传”。 如果用户目标是“修好再传 / 修到满分再传”，就必须把这层判断单独说清楚。

上传前红线（第二轮精简版）

满足任一就不要直接上传，除非用户明确要求“先传再说”：

• 语法报错
• 结构无效
• 详情为空
• 一级字段不规范
• 播放仍是假通过，但却准备当成已修好上传
• 标签规则未确认，但用户明显在意标签

新增强规则：上传前判断必须分成三档

在进入上传动作前，不要只给“能传 / 不能传”的粗判断，必须优先判断属于哪一档：

A 档：建议上传

满足示例：

• 语法通过
• 结构通过
• 关键接口已通
• 用户目标就是发布当前版本

B 档：技术上可传，但不建议直接上传

满足示例：

• 语法和结构虽然通过
• 但搜索 / 播放 / 详情仍存在明显边界问题
• fallback 搜索被当成完整搜索
• 用户明确说要“修好再传”

C 档：暂不应上传

满足示例：

• 语法报错
• 结构无效
• detail 为空
• play 仍是假通过

强约束

上传前汇报时，必须明确说清楚自己判断的是 A / B / C 哪一档，而不是笼统一句“可以上传”。

1. 上传前先校验。
2. 用户怎么要求标签，就怎么执行。
3. 默认从简，不擅自附加标签。
4. 默认优先替换同名文件。
5. 上传完成后必须回报 file_id / cid / tags。
6. “技术上能上传”不等于“现在就建议上传”。

标签规则（速查版）

总原则

• 不自己脑补标签
• 不因为文件名带 [优] 就自动加 优
• 用户没明确说要什么时，默认从简

示例

• 用户说“只要 ds” → ds
• 用户说“ds 和优” → ds,优
• 用户说“别乱打标签” → 只保留明确要求的标签

发现标签错了怎么办

• 立即 update_tags
• 回报最终标签

替换上传 vs 新建上传

默认策略

优先：

house_file(action='upload', auto_replace=true)

适合替换上传

• 同名文件已存在
• 用户要更新最新版
• 不需要保留并行新条目

只有这些情况才考虑新建

• 用户明确要求保留独立新条目
• 同名但本质是不同源
• 需要同时保留多个版本

新增 references：上传前判断参考

如涉及“这个源到底算不算修好、应不应该传”，必须参考：

• references/references-upload-decision.md

标准流程

Step 1：验证仓库连接

• house_verify

Step 2：检查是否满足上传条件

最少检查：

• check_syntax
• validate_spider

如用户要求“修好后再传”，建议补：

• evaluate_spider_source
• 或关键接口单测

强制工具检查点（新增）

在给出“A / B / C 档判断”前，至少应明确自己已经做了哪类工具验证：

• 只做了 check_syntax / validate_spider → 只能说明“语法/结构层面”
• 做了 evaluate_spider_source 或关键接口单测 → 才能进一步说明“接口可用性层面”

禁止在完全没有说明验证依据时，直接下结论“建议上传 / 不建议上传”。

Step 3：判断是否建议上传

必须明确说清楚：

• 可以上传
• 暂不建议上传

Step 4：执行上传

优先：

house_file(action='upload', auto_replace=true)

Step 5：回报结果

必须回报：

• 文件名
• file_id
• cid
• tags
• 是否公开
• 是新上传还是替换上传

Step 6：必要时修标签

house_file(action='update_tags')

推荐输出模板

## 上传前结论
-语法：通过 / 未通过
-结构：通过 / 未通过
-关键接口：...
-是否建议上传：是 / 否
-原因：...
 
## 上传结果
-文件名：...
-仓库 ID：...
-CID：...
-标签：...
-可见性：公开 / 私密
-上传类型：新上传 / 替换上传

明确禁止事项

• 不要未测就上传
• 不要标签乱打
• 不要把半成品说成最终版
• 不要用户说只要 ds 时还附加别的标签
• 不要上传后只说“传好了”，不报 file_id / cid / tags