账号两概念定稿：用户给定义（内容账号管内容属性／平台账号＝发布渠道）；建模自决=不加对象、平台账号作内容账号子项清单

.workbuddy/memory/2026-10-09.md

@@ -609,3 +609,44 @@
 - 产物核实：`现状说明-七页结构与操作路径.md`（8916 B）、`GPT-对页面结构与操作路径的建议.md`（55978 B，§二 逐字留痕 10562 字符、§三 逐条采纳决策 32 条）。
 - 写回：`goalctl declare --kpi`（三条 → `过｜依据`，已回读）；`collabd --set-life 已完成`（16:45:44，已回读）；重写目标目录 `目标执行状态.md` 为第 40 棒版。
 - 未派新棒；未动域锁。副作用＝常驻按设计优雅退出。遗留：D1–D5 待拍板 ＋ 目录名空格口径分岔（本目标未受影响）。
+
+## 23:0x · 执行会话 `254f554c` — 目标「分析 social-auto-upload 项目，用于投放页与发布对象的判断」（类别 开源项目调研）
+
+- 产物：`执行会话/目标-分析social-auto-upload项目，用于投放页与发布对象的判断-0ec0a7/social-auto-upload 分析与对照.md`（30 045 B）。台账 `--report 254f554c … done` ✅（带**已知的**目标目录名分岔软提醒：机制口径＝`目标-分析social-auto-upload-0ec0a7`，实际用派活单全称；软提醒不拒收）。域锁已 `--release-exec` 释放并复核为空。
+- **取数通道教训（新）**：本机 `raw.githubusercontent.com` **连不通**（`curl rc=56`）⇒ 取 GitHub 文件一律走 **`api.github.com/repos/<r>/contents/<path>`**（返回 base64 内容）＋ `git/trees/<b>?recursive=1` 取目录树。公开接口够用，⛔ 不必起浏览器。
+- 被分析项目关键事实（可核）：数据层**只有两张表**（`user_info` 账号 / `file_records` 素材，`db/createTable.py` 行 17–35），**没有发布记录表**；`/postVideo` 返回「已提交」但**不落库**且**同步阻塞**执行（`sau_backend.py` 行 408–479）；发布入参＝平台（**单选**）＋ 账号（多选）（`PublishCenter.vue` 行 546／`sau_backend.py` 行 416–421）；账号**内含平台**（`user_info.type`；CLI 账号文件名 `<platform>_<account>.json`，`sau_cli.py` 行 267–270）⇒ **它没有「渠道」对象**。
+- 「定时发布」真相：**点平台自己的「定时发布」按钮填时间**（`uploader/douyin_uploader/main.py` 行 363–375），**不是本地调度** ⇒ 由此推出硬约束「定时必须晚于现在 2 小时」（`uploader/base_video.py` 行 25）。
+- 失败处理：**无统一框架**，逐步骤零散重试；唯一有界的一处是 `wait_for_upload_complete(timeout=3600, max_retries=3)`（`uploader/tencent_uploader/main.py` 行 810–880），注释留痕了改前「无出口 while True，172MB 被反复传 20 多次、循环近 2 小时」。
+- **三条结论**：① 投放页可改 5 条（目标选择补「先平台后账号」／`Account` 补**登录态**属性／⛔ 不抄批量铺排／定时要在「平台原生 vs 本地调度」里选一条／⛔ 别削发布记录）；② **不加「发布事件」对象** —— 它连发布记录都没有，样本量为零，给不出反证，我们倾向的理由**站得住**；③ 额外发现：`PublishRecord` 若一版发多渠道会分不清渠道，建议**加字段或写死「一版一路」，⛔ 不是加对象**。
+- **照出我们自己的一处内部矛盾**（本轮最实的一条）：`Account` 字典**没写平台**（F9「账号标识唯一」读起来能跨平台），而 F7 守卫写「每个版本必须绑**一个账号 ＋ 一个平台**」（两栏独立 ⇒ 能自由组合）⇒ 与它的「账号内含平台」相反。列入待拍板。
+- 待拍板 3 条（四要素齐全，见产物 §十一）：账号带不带平台（倾向带）｜要不要做定时及走哪条路（倾向先不做、B 记 Deferred）｜`PublishRecord` 要不要带渠道字段（倾向写死「一版一路」，不加字段）。
+
+## 23:2x · 部署 TrendRadar（https://github.com/SANSAN0/TRENDRADAR）到本机 Docker
+
+- **源码落在工作区外**：`E:/ProgramData/AIProject/trendradar`（`git clone --depth 1`）。选工作区外的理由＝它是独立第三方项目，放进 `contentm_agent` 仓会污染工作区 git；且工作区 `tmp/` 会被清 ⇒ 也不放 tmp。
+- 项目自带官方 Docker 方案（`docker/Dockerfile`、`docker-compose.yml`＝拉镜像 `wantcat/trendradar` ＋ `wantcat/trendradar-mcp`；`docker-compose-build.yml`＝本地构建）。走**拉镜像**路线（最小代价）。`config/` 挂 `:ro`、`output/` 可写，`.env` 在 `docker/.env`。
+- 🔴 **本次最实的坑（跨项目可复用）**：`docker compose -f docker-compose.yml pull` **卡死** —— 两个大层各自停在 56.62MB / 57.67MB，**10 分钟字节数一动不动**，被 `timeout 600` 杀掉。对照取证：`docker pull alpine:latest` **秒成** ⇒ 仓库通、不是网络慢。✅ **解法＝绕过 compose，单镜像直拉并锁架构**：`docker pull --platform linux/amd64 wantcat/trendradar:latest`（随后 mcp 镜像同法）⇒ 两三分钟内完成；之后 `docker compose up -d` 直接用本地镜像，不再拉取。⚠️ 附带：`docker manifest inspect` 走 `registry-1.docker.io` 报 Bad Gateway（它绕过 Docker Desktop 的 hubproxy），**这不算拉取失败的证据**，别拿它下结论。
+- 部署结果（进程级证据）：`trendradar` Up（127.0.0.1:8080→8080）｜`trendradar-mcp` Up（127.0.0.1:3333→3333）。首轮抓取已跑完 —— 11 个平台、报告落 `output/html/2026-10-09/23-23.html` 与 `output/html/latest/current.html`（148 652 B，`curl --noproxy '*' http://127.0.0.1:8080/` 回 **200**）。MCP 的 `/mcp` 端点可达（裸 GET 回 400 ＝ 在做协议协商，非无响应）。
+- 无凭据时的默认行为（已实测）：AI 分析与翻译**跳过并打印警告**（代码有 `if not api_key` 判空，`trendradar/ai/client.py` 行 114 等）⇒ 不填 key 也能跑，⛔ 不是致命错误；未配通知渠道 ⇒ 只抓取不推送。开启 AI 要改 `docker/.env` 的 `AI_API_KEY`＋`AI_MODEL`＋`AI_ANALYSIS_ENABLED=true` 再 `docker compose up -d`（环境变量优先级 > config.yaml）。
+- ⚠️ 本机 `env` 里有 `http_proxy=http://127.0.0.1:56210` ⇒ **探本机端口的 curl 必须带 `--noproxy '*'`**，否则走代理拿不到结果（假失败）。
+- 未启用：调度系统 `schedule.enabled: false`（默认）、S3 远程存储、任何推送渠道 —— 均按官方默认保持原样，未改 `config.yaml`。
+
+## 23:3x · 目标检查会话 第 41 棒（social-auto-upload 目标）⇒ 判「判不出来」，停手
+
+- 结论：本轮**既没派活也没改状态** —— 唯一验收依据《目标执行状态.md》读不到（机制名目录 `执行会话/目标-分析social-auto-upload-0ec0a7/` 与实际全称目录里**都没有这份文档**）⇒ 照检查会话规则三.4「判不出来 ⇒ 停手」。
+- 台账侧是干净的：`tmp/supervise-inbox/tasks.json` **18 条全 done**，本目标那条 `254f554c` = done，产物 `执行会话/目标-分析social-auto-upload项目，用于投放页与发布对象的判断-0ec0a7/social-auto-upload 分析与对照.md`。
+- 🔴 顺带查出四处机制缺陷（都不在本轮授权内，留主会话处理）：
+  · `goal.json.execution_doc` **漂移** —— 指的还是上一个目标 `…b49e02/目标执行状态.md`，⛔ 不是本目标的；
+  · `goal.json.acceptance_state` 三条值写的是 **`未过`** ⇒ 不在规范取值域（`过｜…`／`🔴 不过｜…`）⇒ 机器分不出「没判」与「判了没过」；
+  · `tmp/supervise-inbox/taskgraph.json` **文件不存在**（任务图那一路判不了）；
+  · 工作区根 `state.py` **不存在**（检查单第 1 项跑不通）。
+- 域锁：当前**无人持域** ⇒ 不存在孤儿锁，本轮无需解除。
+
+## 23:58 [检查]-目标检查-第42棒 · 收口「分析 social-auto-upload」目标
+
+- 判定：**已完成**，已跑 collabd.py --set-life 已完成（by 第42棒）。三路核对：台账 20 条全 done（无僵尸件）／任务图 taskgraph.json 不存在（该路判不了，已注明）／验收三条全**过**。
+- 依据：执行棒 254f554c 产物「social-auto-upload 分析与对照.md」（30 045 B，落本目标目录）覆盖三条判据（§二平台／§三发布抽象／§四账号与登录态／§五定时／§六失败重试／§七技术栈；§八 11 对象逐项对照；§九 投放页 5 条 ＋ §十「发布事件不加」）。
+- ✅ 补写了本目录**此前缺失**的「目标执行状态.md」（文档合同里该文档由检查会话写）。
+- ✅ 修掉第41棒留的两处：acceptance_state 三条「未过」→ 规范值「过｜依据」（走 goalctl.py declare --kpi，已回读）；execution_doc 从旧目标 b49e02 那份改回本目标（原子替换 ＋ 回读，exists=True）。
+- ⚠️ --set-life 已完成 的副作用：**常驻程序优雅退出**（pid 12784）⇒ 后续检查棒不再自动建；要恢复得主会话重起。
+- ⛔ 仍未修（不在本轮授权）：taskgraph.json 不存在；工作区根 state.py 不存在（检查单第 1 项恒跑不通）。