diff --git a/.workbuddy/memory/2026-10-09.md b/.workbuddy/memory/2026-10-09.md
index 673832f..46e9fca 100644
--- a/.workbuddy/memory/2026-10-09.md
+++ b/.workbuddy/memory/2026-10-09.md
@@ -469,6 +469,20 @@
 
 **剩余待定**：第 4 条的**加不加「发布事件」对象**（★ 需用户定）、第 5 条的**分类维度**（执行棒先出方案）。
 
+## 22:50 · 用户订正措辞：主体是内容，对象是渠道（顺带推翻 GPT 加对象的理由）
+
+**用户口径（逐字）**：「应该说**一条内容对应多个发布渠道**」。
+⇒ 这是针对我 22:4x 那句"一次任务本来就能对多个目标（账号）"的订正：主体是**内容**，一条内容对应**多个发布渠道**；渠道＝在哪个账号的哪个平台发。
+
+**顺带查出一个结论（按此口径核实后）**：**GPT 要加「发布事件」的理由在现版站不住** ——
+`2a` F7 的口径是「一份母版到**多账号多平台**版本」＋ `2b` 投放页第 2 块逐字「**一个目标一版**」，且每个版本绑「一个账号 ＋ 一个平台」；
+而 `PublishRecord` 记的就是"哪一版" ⇒ **记录本来就是渠道级粒度**，不存在"多个渠道的结果压在一个记录里"（GPT 那个担心＝它没看到"一个目标一版"这条）。
+⇒ 加 `PublishEvent` 真正多买到的只有**尝试级留痕**（每次尝试、时间戳），渠道级区分能力现版已有。
+
+**要一并落的措辞订正**：`2a` 对象字典里 `PublishTask` 的定义写的是「含目标账号与平台」⇒ 按用户口径改成「含**发布渠道**（账号 × 平台的组合）」；`2b` 投放页数据摘要区的「目标账号数／目标平台数」同理对齐。落地时随其他口径一起改。
+
+**已改**：`用户口径裁决-5条回应.md` §四（按订正重写，含"理由站不住"的核实结论与要落的措辞）。
+
 ## 07:12 · 结果检查第 33 棒 —— 阻碍换人（旧孤儿锁已解、新持锁会话在保护期），本轮零派活
 
 - 本棒（自动化 `cdf24e8d`，第 33 棒）现取五样：`state.py` 仍不存在、`taskgraph.json` 仍不存在、台账 16 条（15 done ＋ 1 blocked）、`lifecycle`＝进行中、`acceptance` 3 过 ＋ 1 不过。
diff --git a/执行会话/目标-征询GPT对当前七页结构与操作路径的建议-b49e02/用户口径裁决-5条回应.md b/执行会话/目标-征询GPT对当前七页结构与操作路径的建议-b49e02/用户口径裁决-5条回应.md
index 1036edd..5a9a3fe 100644
--- a/执行会话/目标-征询GPT对当前七页结构与操作路径的建议-b49e02/用户口径裁决-5条回应.md
+++ b/执行会话/目标-征询GPT对当前七页结构与操作路径的建议-b49e02/用户口径裁决-5条回应.md
@@ -57,18 +57,25 @@
 
 ## 四、第 4 条：为什么要分「发布事件」，好处是什么
 
-这是用户问的原因分析，⛔ 不是要执行。
+这是用户问的原因分析，⛔ 不是要执行。（2026-10-09 22:50 按用户措辞订正后重写。）
 
-**GPT 想加的对象**：在 `PublishTask`（发布任务）与 `PublishRecord`（发布记录）之间，再插一个 `PublishEvent`（发布事件）。
+**用户订正（逐字）**：「应该说**一条内容对应多个发布渠道**」。
+⇒ 主体是**内容**，一条内容对应**多个发布渠道**；渠道＝在哪个账号的哪个平台发。⛔ 不用"一次任务对多个目标账号"这种说法。
 
-**好处（它担心的具体场景）**：
-- 现版 `PublishTask` 的定义是「一次『把这些版本发出去』的任务，**含目标账号与平台**」⇒ 一次任务**本来就可能对多个目标**；
-- 而结果现在压在一个 `PublishRecord` 里 ⇒ 出现「账号 A 发成功了、账号 B 失败了」时，**一个记录说不清两个结果**；
-- 分成"事件"之后：每个目标的发布各自留痕，能分别记成功/失败/时间，复盘可以精确到「哪个账号的哪一次发布」。
+**GPT 想加的**：在 `PublishTask`（发布任务）与 `PublishRecord`（发布记录）之间插一个 `PublishEvent`（发布事件）。它给的理由是"一次任务对多目标，结果压在一个记录里说不清"。
+
+**核实现版之后：它这个理由在现版站不住。**
+- `2a` F7 的口径是「一份母版到**多账号多平台**版本」，且投放页第 2 块逐字写着**「一个目标一版」**；
+- 每个版本绑「一个账号 ＋ 一个平台」（`2a` F7 守卫那条）；
+- 而 `PublishRecord` 发布记录记的就是"哪一版" ⇒ **记录本来就是渠道级粒度**，不存在"多个渠道的结果压在一个记录里"。
+
+**所以加"发布事件"真正能多买到的，只有一件事**：把"发出去之前的任务"与"发之后的实录"分得更细，细到每次尝试、每个时间戳。渠道级区分能力现版已经有。
 
 **代价**：对象字典 11 → 12；`2a` 功能清单要补条目；`2b` 的 20 条流转契约要重过一遍。
 
-**一句话**：好处是**多目标分发时的粒度**，代价是**对象与契约都要扩一遍**。值不值取决于这个产品**实不实打实地一次发多个目标**。
+**一句话**：它要解决的那件事，现版用「一个目标一版」已经解决了。
+
+**顺带要落的措辞订正**（落地时一并改）：`2a` 对象字典里 `PublishTask` 的定义现在写的是「含目标账号与平台」，按用户口径改成「含**发布渠道**（账号 × 平台的组合）」；`2b` 投放页数据摘要区的「目标账号数／目标平台数」同理对齐。
 
 ---