103 lines
5.7 KiB
Markdown
103 lines
5.7 KiB
Markdown
# 1
|
||
|
||
阅读交接文档：[handoff/2026-06-24-character-consistency-r5-brief-ownership-handoff.md](</C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r5-brief-ownership-handoff.md>)
|
||
|
||
谈谈你的想法，先对齐思路。
|
||
|
||
我读完后的判断：R5 应该被定义成“机制回归测试”，不是新一轮图像质量测试。R4 的图已经被接受，但 brief/packet 所有权错了，所以 R5 的成败标准要压在边界上：可见子会话先写并确认 brief/packet，再启动 one-shot Agent；Agent 只读 brief/packet，然后写 prompt/image/return。这个规则如果再破，即使图好看也只能是 `warning` 或 `failed`。见 [handoff](</C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r5-brief-ownership-handoff.md:57>) 和 [brief ownership rule](</C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r5-brief-ownership-handoff.md:66>)。
|
||
|
||
我同意推荐范围：先只跑 `S-07`，通过后再同一个 clean child session 继续 `S-08/S-09`。这三张目前都只有 broad-run `v1` 图，未作为最终接受版本；新跑 `v2` 符合 append-only 规则，也能覆盖远景小人、身体细节、桥下压力三类不同负载。对应状态在 [slides.md](</C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/slides.md:36>)。
|
||
|
||
我会特别卡两个点：
|
||
|
||
1. `packet` 路径要按现有模板理解为 `tasks/.../session-xx/packets/sNN-vN-slide-agent-packet.md`，不要误建一个新的 slide-local `sNN-vN-packet.md`。handoff 里的 `sNN-vN-packet` 我会当作逻辑简称。
|
||
2. 需要把“brief/packet 所有权”和“host image generation 是否由谁实际执行”分开记录。如果 Agent 因可见图片引用限制不能自己完成生成，而由可见子会话补完生成，这至少要在 handoff 里显式标成机制状态，不能糊成 pass。否则 R4 的问题会换一种形式回来。
|
||
|
||
下一步如果执行，我的默认做法是：创建一个 clean visible child session，只发 Package 1 `S-07`；等 10 分钟后查 compact handoff；只看 handoff 的 completion gate、brief owner、worker id、artifact path/hash、review suppressed 结果。只有它报 `warning/blocked/failed`，我才打开 prompt/return/ledger 细查。Package 2 必须等 `S-07` 的 brief-ownership gate 过，并且你接受图后再继续。这个和 [workflow production default](</C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-orchestration.md:127>)、[R5 package split](</C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-r5-brief-ownership-handoff.md:123>) 一致。
|
||
|
||
所以我的对齐结论是：R5 不要追求多产图，先证明“可见子会话真的能拥有 brief/packet，并顺序驱动 one-shot slide Agent”。这个过了，再谈扩大；不过，就先停下来修 contract。
|
||
|
||
# 2
|
||
|
||
好的，没问题。现在开始S-07。
|
||
|
||
# 3
|
||
|
||
现在子会话Context 103K，s07耗时12m22s
|
||
1. 通用状态更新的时间有问题，改到5分钟吧。
|
||
2. S-07的图片已经通过，开始发第二包。
|
||
|
||
|
||
# 4
|
||
|
||
中间网断了一下，你退出了；但是子会话没有退出。
|
||
S08，S09已经返回了。
|
||
图片没有问题，通过。
|
||
|
||
---
|
||
|
||
> 通用状态更新的时间有问题，改到5分钟吧
|
||
|
||
这个理解错了。
|
||
|
||
workflow里的等待时间是多少？ 本项目的等待时间是多少？
|
||
|
||
第二回合两个镜头花了35m3s，中间有重连。
|
||
|
||
规则部分干脆还是改成：
|
||
1个镜头的包首次sleep10分钟，之后每1分钟检查一次，上限15分钟；
|
||
2个镜头的包首次sleep20分钟，之后每1分钟检查一次，上限30分钟；
|
||
3个镜头的包首次sleep30分钟，之后每1分钟检查一次，上限45分钟；
|
||
|
||
---
|
||
|
||
你说的通用状态更新的时间，就是你前面执行每次30s的这个。
|
||
我让你改的是这个，改成5分钟。这个能改么？
|
||
|
||
# 5
|
||
|
||
之前的子会话Context 用到了187K。
|
||
|
||
现在开启新的子会话，选择后续未完成的3个镜头，发到新的子会话里，这次直接测试3个镜头的包。
|
||
这次测试主要是一次3个镜头，并看下Context的消耗。
|
||
之前从未一次发3个镜头出来。
|
||
|
||
# 6
|
||
|
||
本次3镜头子会话Context为157k，时间30m5s。
|
||
所有图片通过。
|
||
|
||
---
|
||
|
||
再测一组，选择后续未完成的4个镜头，发到新会话里。直接测试4个镜头的包。
|
||
|
||
# 7
|
||
|
||
本轮试运行测试，流程部分基本结束。
|
||
|
||
s16的图片不通过，没有达成：`横向大远景，路从画面一侧切向远方，人物极小`。与s15的区别不大。
|
||
|
||
但是你只记录结果就行，不在本次会话修复了。
|
||
|
||
我计划启动第6轮的测试，将会话的轮询制替换成通知形式：主会话发送任务后退出，子会话完成任务后，激活主会话。
|
||
同时顺便重做s16。
|
||
|
||
你做一个交接文档。
|
||
之后我会做全项目的提交。然后开启新会话。
|
||
|
||
已完成交接文档：[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>)。
|
||
|
||
我只记录了结果，没有修复 `s16`。交接里明确写了：`s16-v2` 不通过，失败点是没有达成“横向大远景，路从画面一侧切向远方，人物极小”，且与 `s15` 区别不大；R6 要测试真实 notification/wakeup 机制，不能用隐藏轮询冒充通知，同时用 append-only 方式重做 `S-16`。
|
||
|
||
同步更新了项目控制文件：`project.md`、`execution-plan.md`、`slides.md`、`task-plan.md`、`task-log.md`。验证结果：R6/S16 记录检索命中；硬性生命周期扫描通过，无 `production-ready` / `released` 越界；`git diff --check` 只有 CRLF 提示，没有 whitespace error。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|