2.9 KiB
2.9 KiB
队列 · 分析 social-auto-upload 项目，用于投放页与发布对象的判断
目标（2026-10-09 22:52 下达，已切目标）：分析
https://github.com/dreammis/social-auto-upload，产出一份分析，用来判断我们的投放页该怎么设计、要不要加「发布事件」对象。 用户口径：分析这个项目在做判断。 上一版队列（旧目标「征询 GPT 对当前七页结构与操作路径的建议」）已留痕：同目录NEXT-旧目标-征询GPT建议-已归档20261009-2252.md。
1、分析项目 → 与现版对象字典对照 → 给结论 —— 待
执行者：执行会话（本工作区，域目录 执行会话）
目标目录：执行会话/目标-分析social-auto-upload项目，用于投放页与发布对象的判断-0ec0a7/
（⚠️ 机制按 title[:20] 去空格命名 —— 开工以实际建出来的目录为准，⛔ 别因名字不完全一致就报越界。）
只读输入（⛔ 不要改）：
- 我们的现版：
执行会话/目标-导航改七项一层并重排功能归属（P8 并入复盘）-fc471a/里的2a-产品功能-新版.md（对象字典 11 个 ＋ F5／F7／F13）与2b-界面布局-新版.md§五 P5 投放页
三步：
1、分析那个项目：支持平台清单 ／ 发布抽象（它怎么建模"内容、渠道、账号、发布记录"）／ 账号管理与登录态怎么处理 ／ 定时发布 ／ 失败与重试 ／ 技术栈与扩展方式（各平台 uploader 的接口形状）。
⚠️ 取数优先 curl 抓 raw 与 GitHub API —— 公开 API 用不着浏览器，⛔ 别为这件事起浏览器。
2、与我们现版逐项对照：我们的 11 个对象里，哪些它有、哪些它多出来、哪些它没有；它的"渠道"到底怎么定义 —— 是账号、是平台，还是"账号 × 平台"的组合。
3、给结论（这是本轮的落点）：
- 我们的投放页照它有什么可改的；
- 要不要加「发布事件」对象（现在倾向不加，理由是我们「一个目标一版 ＋ 记录绑版本」已是渠道级 —— 拿它的做法验一下这个理由站不站得住）。
产物：social-auto-upload 分析与对照.md
每棒通用硬约束
- 重写 ≠ 润色：内容层必须真改；结构变了要在文末列「与上一版的实质差别」。
- 一切落盘文字过「说人话」（判据源
E:/ProgramData/.workbuddy/skills/humanizer-zh），门槛 ≥45/50，文末写明评分。 - 域目录
执行会话，抢到域锁才能写；抢不到 ⇒ 停手报告。 - 浏览器：只连不起（9223 已有实例）＋ 一类任务只开一个标签页并复用；⛔ 公开 API 优先 curl。
- 做完即停、上报：
python .workbuddy/collab/collabd.py --report <sid> --state done --artifact "<路径>"。 - 收工必跑
--release-exec释放域锁。 - 半成品按失败交付，⛔ 不许当完成上报。