# 1

阅读交接文档：[R6 Notification/Wakeup And S-16 Repair Handoff](</C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r6-notification-s16-handoff.md:1>)。

阅读调研报告：[test-1-report.md](</C:/Users/wangq/Documents/Codex/video-workbench/investigations/2026-06-24-thread-notification-wakeup/test-1-report.md>)

---

本次计划做第6轮测试，主要目标是将主会话轮询制改为唤醒制的尝试。
首先忽略workflow中的轮询等待心跳这些，而是按照我下面的实验步骤。

s16之前质量有问题，本次R6 测试计划分为两个阶段。
**第一阶段测试：**
1. 准备好s16的资料。取得主会话（当前会话）的id，生成子会话，取得子会话id；发送s16的重做指令，包括：
   1. 未达成镜头清单骨架中所描述的“横向大远景，路从画面一侧切向远方，人物极小”，与s15太接近，
   2. 子会话重新整理brief和对agent的要求
   3. 主会话id
   4. 做完后回调主会话
2. 预期主会话被激活，做相关的后续处理。我在你做完后检查s16的效果。

**第二阶段测试：**
1. 准备后续未完成的4个镜头资料（不包括s16，不论s16是否通过）发给新子会话，然后等待子会话回调。
2. 子会话回调后，做后处理。然后等我确认图片质量。

若主会话未被正常激活，我可以看到子会话的进度，我会介入。

谈谈你的思路，有问题提出。先对齐思路。

读完了。最新交接文档就是：

[2026-06-24-character-consistency-r6-notification-s16-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r6-notification-s16-handoff.md)

关键影响：

- R6 的正式入口是 `S-16` append-only 重做，建议路径 `session-09/`，预期版本 `s16-v3`，但执行前必须扫描确认。
- 主变量是 notification/wakeup，不能用隐藏轮询冒充。
- 子会话必须先写 handoff、过 completion gate，再 `send_message_to_thread(parent_thread_id)` 回调主会话。
- `S-16` 必须明确修正：横向大远景、路从画面一侧切向远方、人物极小、明显区别于 `S-15`。
- prompt 仍必须走 `gpt-image-2` Skill Advisor / host-native 流程，并记录 mode、模板/参考路径、实际读取源文件。
- review 默认关闭，不写 `s16-v3-review.md`。

和你刚才的新两阶段计划相比，唯一需要标记的是：交接文档的 Non-Goals 写了“不拓展到更多 slides，除非用户明确改变 R6 scope”。你刚才已经明确提出第二阶段 4 个镜头，所以我会把第二阶段当作**本轮新授权扩展**，不是交接文档原始范围。第一阶段仍严格按交接文档跑 `S-16`。

# 2

是的，第一阶段是原始计划，只是证明可以实现；第二阶段是扩展计划，证明将来正式运行是否可行。

若没有其他问题，可以开始执行第一阶段了，我可以保证，当前只有你的会话在活动。

# 3

s16图片通过。现在进入第二阶段测试。

第二阶段已启动并派发，主会话现在停止轮询。

- Phase 2 child thread: `019ef9d0-4914-7ea0-8935-bfd9bfc1aad4`
- Session path: `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-10/`
- Scope: `S-19`, `S-20`, `S-22`, `S-23`
- Expected versions if unchanged: `s19-v2`, `s20-v2`, `s22-v2`, `s23-v2`
- Callback target: current parent thread `019ef9b5-cc39-7a42-91b1-f9b0852dc95e`

我也已把 `s16-v3` 用户通过和 Phase 2 派发状态写入父会话记录。现在等待子会话完成后回调；我不会主动读取或轮询子会话线程。

# 4

我暂停了子会话，原因是s20的agent卡了40分钟，这个agent试图调用mcp服务minimax去理解图片，多次失败后应该被安全审计杀掉了。
我现在关闭了这个mcp服务。

所以s19图片通过，不用重做了。

我们重新做第二阶段，选择后续新的4个包，发给新的子会话测试。

# 5

S-20, S-22, S-23, S-24 4个图已经通过。

# 6

因为本会话经过了信息压缩，我回顾一下我们做了什么：
**第一阶段测试：**
1. 准备好s16的资料。取得主会话（当前会话）的id，生成子会话，取得子会话id；发送s16的重做指令，包括：
   1. 未达成镜头清单骨架中所描述的“横向大远景，路从画面一侧切向远方，人物极小”，与s15太接近，
   2. 子会话重新整理brief和对agent的要求
   3. 主会话id
   4. 做完后回调主会话
2. 预期主会话被激活，做相关的后续处理。我在你做完后检查s16的效果。

这个测试顺利完成。

**第二阶段测试：**
1. 准备后续未完成的4个镜头资料（不包括s16，不论s16是否通过）发给新子会话，然后等待子会话回调。
2. 子会话回调后，做后处理。然后等我确认图片质量。

测试失败，S-19, S-20, S-22, S-23 四个镜头，只做了s19。原因是s20的agent卡了40分钟，这个agent试图调用mcp服务minimax去理解图片，多次失败后应该被安全审计杀掉了

**第三阶段测试：**
1. 继续准备4个镜头发给新子会话，等待回调
2. 子会话回调后，做后处理。

测试完成，S-20, S-22, S-23, S-24四个镜头图片通过，回调顺利。

---

基于以上，你看看有没有你遗漏的。
下一步，我们将修改workflow的规则，从轮询制改为订阅制（通知唤醒）
你判断下，需要修改哪些内容。

你的复盘基本完整。我补充 3 个容易遗漏的点：

1. 第一阶段不只是回调成功，还验证了“回调后父会话只读本地 handoff/文件证据做后处理”，没有恢复广泛轮询。
2. 第二阶段失败要记录为两件事：`s19-v2` 已通过；`s20-v2/s22-v2/s23-v2` 是不完整历史证据，不能补写或原地续做。
3. 第三阶段成功的关键差异是 `session-11` 把 MiniMax/MCP/外部图像理解写成了 worker stop condition，而不是只靠“默认不调用”的软规则。

我建议按“订阅制默认，轮询降级为显式例外”修改，范围如下：

1. [AGENTS.md](C:/Users/wangq/Documents/Codex/video-workbench/AGENTS.md:99)  
   把 `Production orchestration defaults` 里的 sleep/poll 规则替换成 callback-only：父会话发送任务后停止等待；子会话完成 gate 后写 handoff，再用 `send_message_to_thread` 回调父会话。原 wait schedule 改成 legacy/fallback，仅在用户明确要求或回调机制不可用时使用。

2. [slide-task-orchestration.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-orchestration.md:127)  
   这是主 workflow 规则，必须改。新增“Notification / Wakeup Contract”：父线程 id、callback required、handoff-before-callback、callback payload、父会话只在回调后读 handoff。保留 child capacity 规则，但不再把等待/轮询作为生产默认。

3. [slide-task-templates.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-templates.md:62)  
   模板要补字段，否则后续子会话会漏协议。  
   `Child Session Plan` 增加 `Parent Callback Contract`。  
   `Child Session Handoff` 增加 `Callback Status`。  
   callback payload 固定为：status、completion gate、resolved versions、handoff path、image paths、problems/decisions needed。

4. [slide-task-templates.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-templates.md:119)  
   `Slide Agent Packet` 的 stop/completion 规则要硬化：禁止 MiniMax MCP、external image understanding、external review、web search、CCPE、GPT V2，除非任务显式授权。第二阶段失败说明这不能只写在 review rule 里。

5. [VIDEO_WORKBENCH.md](C:/Users/wangq/Documents/Codex/video-workbench/VIDEO_WORKBENCH.md:224)  
   更新高层角色描述：main session 不再“等待并读取 handoff”，而是“发送任务、记录回调目标、被唤醒后读取 handoff”。同时把 external vision 禁令从 review 场景扩展到“图像理解/生成辅助/审查”全链路。

我不建议改当前项目状态文件作为 workflow 规则来源；`task-log.md/project.md/execution-plan.md/slides.md` 已经记录 R6 结果，适合作为证据，不适合作为默认协议入口。

推荐方案是：**callback-only 成为生产默认；manual/user intervention 是回调丢失时的异常路径；自动轮询不再是默认兜底。** 这样最贴合这次 R6 的实验目标，也避免“订阅制”名义下又保留一套隐形轮询。

请确认是否按这个方案改，我收到确认后开始修改这些规则文件。

# 7

[slide-task-templates.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-templates.md:119)  
   `Slide Agent Packet` 的 stop/completion 规则硬化
这一条不同意，我将MiniMax MCP已经关掉了，不影响后续；在后续实际应用中，还是有可能会用到其他的。
不用增加硬化规则。

其他没有问题，按这个修订。


# 8

接下来我还会做R7的试运行。
主因是，现在的这套机制运行起来已经没有问题，但是“治理”过重，有大量的日志、审计、交接。
作为我参与的测试、试运行，这个没问题，需要回溯问题的能力，但是作为正式运行，有大量的tokens被用在了生产之外。

下一轮，主要目标是为这个正式运行，做治理的简化。

你写一份交接文档。之后，我会手动提交所有的文档。在新会化里开启R7。

已写好 R7 交接文档：

[2026-06-25-character-consistency-r7-governance-simplification-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-25-character-consistency-r7-governance-simplification-handoff.md)

内容重点：
- R6 三阶段结果和当前状态。
- callback-only 已经证明可用，不再默认轮询。
- R7 目标是建立 `production-light mode`，减少正式生产中的日志、审计、长交接和父会话复核。
- 明确保留你的意见：不增加 MiniMax MCP / 外部视觉工具的全局硬禁用规则。
- 建议 R7 新会话先确认：先改 docs 再跑，还是先跑一个小包再从结果修订 docs。
- 默认建议试运行范围写成 `S-26/S-27/S-28`，4 镜头压力选项是 `S-26/S-27/S-28/S-29`，但要求新会话不能静默选择，必须先与你确认。

校验：交接中引用的核心文件都存在；关键词检查覆盖了 R7、callback、polling fallback、production-light、MiniMax 边界和候选镜头范围。`lifecycle-status-guard-scan` 的脚本因当前可见 Python 缺 `yaml` 且 shell 里没有 `conda` 未能运行，我改做了手动状态词检索。新 handoff 当前是未跟踪文件，未 staging、未 commit。