补充conda环境规则

AGENTS.md

@@ -13,6 +13,26 @@ Select-String -Path <path> -Pattern <pattern> -Encoding UTF8
 
 When writing text files, preserve UTF-8. Do not rely on PowerShell encoding defaults for Chinese Markdown.
 
+## Python / Conda Environment
+
+For local Python automation, validation, indexing, and helper scripts in this repository, default to the shared `skills-vault` Conda environment.
+
+Preferred command pattern:
+
+```powershell
+& 'C:\Users\wangq\miniconda3\Scripts\conda.exe' run -n skills-vault python -B <script-or-module>
+```
+
+If `conda` is already available on PATH, this may be shortened to:
+
+```powershell
+conda run -n skills-vault python -B <script-or-module>
+```
+
+Do not treat missing packages in the system Python, such as `yaml` / PyYAML, as project evidence failures. Use the `skills-vault` environment first.
+
+Do not install project dependencies into the system Python as the default fix. Create or use a separate Conda environment only when a task has special dependencies, dependency conflicts, or an explicit project-local environment contract.
+
 ## CCPE Interface
 
 The default external CCPE entrypoint is:

docs/cases/on-the-road-project-evolution-material.md

@@ -0,0 +1,440 @@
+# 《在路上》项目从无到有到全量 slide 完成：文章素材文案
+
+## 文档定位
+
+- 类型：文章素材底稿 / case material。
+- 用途：为未来写一篇关于 `video-workbench` 和《在路上》项目实践过程的文章提供素材、时间线、案例细节和可引用表述。
+- 状态：素材草稿，不是工作流规则，不替代 `VIDEO_WORKBENCH.md`、`project.md`、`execution-plan.md` 或 `slides/slides.md`。
+- 项目路径：`projects/2026-06-23-在路上`。
+- 当前项目状态：当前 51-shot 表的 shot-image production 已完成，项目进入 assembly / closeout 待启动阶段。
+
+## 一句话主线
+
+这个项目的关键，不只是“用 AI 生成了 51 个画面”，而是从一个还没有稳定形状的视频工作台开始，把一套 GPT 前期策划，逐步压缩成本地可执行的项目骨架、视觉系统、参考图规则、slide 生产流水线、子会话协作机制和生产轻量化规则，最后完成了《在路上》当前 51-shot 表的全部图片生产。
+
+更准确地说，它完成了两件事：
+
+1. 《在路上》作为一个 MV / slide-image 项目，从策划文本变成了有视觉系统、有角色锚点、有 51 个画面单元、有完整图片产物的本地生产包。
+2. `video-workbench` 作为一个工作台，从“需要摸索机制”演化成了“能用 production-light 直接批量生产，并靠 handoff / callback 可靠续跑”的工作流。
+
+## 可直接放进文章的开场素材
+
+一开始，`video-workbench` 并不是一个已经完全定型的生产系统。它更像一个本地工作间：有方向，有一些相邻仓库，有 GPT 输出的前期规划，也有 Codex 可以执行的本地文件系统，但真正的问题是，怎样把这些东西变成一个可持续生产的视频项目。
+
+《在路上》就是这个工作台的第一个完整压力测试。
+
+它不是从一张 prompt 开始的，也不是从“批量生成 51 张图”开始的。它从一组已经被接受的 GPT V2 策划材料开始：MV 总纲、通用表达与视觉系统设计、人物锚点板说明、风格锚点板结构、51-shot 镜头骨架、核心单镜扩展。Codex 的任务不是再写一遍策划，而是把这些材料转成仓库能持续执行的控制文件。
+
+这一步很关键。因为真正能把项目带到结尾的，不是更长的灵感文本，而是几个能被反复读取、被子会话继承、被任务记录续接的文件：`project.md`、`execution-plan.md`、`visual-system/visual-system.md` 和 `slides/slides.md`。
+
+从那一刻开始，《在路上》不再只是一个构想，而变成了一个本地生产项目。
+
+## 阶段一：工作台先定边界
+
+在项目早期，`video-workbench` 最先解决的不是图片，而是边界。
+
+仓库被明确成一个“本地视频 / slide 执行工作台”，不是深度文章写作区，不是长期知识库，不是 CCPE canonical agent 存放地，也不是可复用自动化源码仓库。它和周边仓库的关系被切清楚：
+
+- `knowledge-vault` 提供长期知识和来源材料。
+- `writing-workbench` 负责深度文章生产。
+- `ccpe-system` 提供正式 agent / runtime / model / interface。
+- `skills-vault` 提供可复用自动化技能。
+- `video-workbench` 只负责把已接受的策划和来源材料，落地成视频 / slide 项目的本地执行文件、素材、prompt、图片和 handoff。
+
+这个边界后来非常重要。它避免了一个常见问题：把 GPT 的规划文本、Agent 机制、Prompt 模板、项目产物、工具源码全部塞进一个目录，最后谁也不知道哪个文件才是当前事实。
+
+最终形成的规则是：真实项目都进入 `projects/<project-id>/`；项目状态写在文件里，不靠移动目录表达；跨阶段交接写在 `handoff/`；可复用能力缺失时写 supplier request，而不是在项目里临时发明一套不可复用工具。
+
+## 阶段二：从 GPT 策划到本地执行骨架
+
+《在路上》的输入不是空白 prompt，而是一批前期策划文件。Codex 先把它们安置在 `intake/`，再从中抽取本地执行骨架。
+
+这一步形成了四个核心文件：
+
+- `project.md`：项目地图，记录状态、阶段、已接受输入、核心方向、当前执行重点和下一步。
+- `execution-plan.md`：执行控制文件，记录当前 medium branch、小批量策略、已完成轮次、当前默认生产路线。
+- `visual-system/visual-system.md`：视觉系统权威文件，记录人物、风格、色光、构图、母题和关键镜头规则。
+- `slides/slides.md`：51-shot 的执行事实表，记录每个 `sNN` 单元的来源、功能、风格锚点、状态和产物。
+
+这里有一个方法论转折：GPT 策划不是被复制成新的“真相文件”，而是被保留为来源。Codex 维护的是执行控制层。
+
+这套骨架让项目有了长期可读性。后续无论主会话压缩、子会话切换、任务中断、图片失败、prompt 重试，都可以回到这几个文件上继续，而不是依赖某一段聊天记忆。
+
+## 阶段三：视觉系统先于批量生产
+
+《在路上》的视觉核心后来被凝练成一句话：
+
+> 世界比人更大，路比人更长，人只是持续前行的坐标。
+
+英文控制句是：
+
+> World before face; road before pose; the traveler is a small coordinate that keeps moving.
+
+这个规则决定了整个项目不是 portrait MV，也不是旅行宣传片，而是 landscape-led road documentary / poetic realism。
+
+视觉系统被拆成几个稳定部件：
+
+- 人物：50 岁男性旅人，疲惫但没有垮掉，旧长外套、旧背包、旧靴子，形象要能持续走下去。
+- 风格 A：清晨泥泞旷野，世界先于人出现。
+- 风格 B：高位观察和城市边缘，表现系统压力。
+- 风格 C：泥泞里的星空，低处看见宇宙，是项目的灵魂画面。
+- 风格 D：夜路小火，远方也有人在走，但不是团聚、胜利或露营。
+
+第一批真正重要的生产不是全量镜头，而是锚点验证：
+
+- 人物锚点板 accepted。
+- 从人物锚点板切出的透明人物切片 accepted。
+- 风格锚点板 accepted。
+- C 风格修复样本 accepted。
+- 五个核心镜头 S-01、S-10、S-46、S-47、S-51 accepted。
+
+这一步证明了项目的视觉方向：画面可以保持现实质感，也可以有诗性，但不能变成广告、英雄海报、赛博城市、魔法宇宙、露营团建或胜利结尾。
+
+## 阶段四：第一次大问题不是审美，而是引用路径
+
+项目早期曾经出现过一个关键问题： broad generation 的画面能出，但缺少可追溯的 per-shot prompt、真实参考图加载证据和稳定的身份控制。尤其是人物一致性场景，不能靠文字描述去维持身份。
+
+这促成了 S14 reference-capable generation investigation。
+
+最后沉淀下来的规则是：
+
+```text
+gpt-image-2 Skill Advisor prompt/spec
+-> 把真实参考图加载进对话可见上下文
+-> 使用宿主 image_gen 生成
+-> 把结果复制进项目目录
+-> 在 prompt / handoff / slides.md 中记录参考角色和产物路径
+```
+
+这个结论非常重要。它把问题从“AI 能不能参考图片”转成了“项目文件怎样记录参考图片被如何使用”。也就是说，技术可行性不再反复争论，后续重点转向生产追踪和工作流清洁度。
+
+从这里开始，`gpt-image-2` 在项目中承担的是 prompt/spec Advisor，而不是默认 Garden / API 出图路径。身份关键画面必须加载真实参考图；在 prompt 里写本地路径只算 traceability，不算真正加载。
+
+## 阶段五：从单张试验到 slide task orchestration
+
+为了让长生产可控，项目把每个画面、页面、镜头单元统一叫 `slide`。每个 slide 有自己的目录：
+
+```text
+slides/sNN/
+  sNN-vN-brief.md
+  sNN-vN-prompt.md
+  sNN-vN-image.png
+  sNN-vN-review.md   # 只在 test/audit 或显式 review 时出现
+```
+
+这里又形成了一个重要原则：append-only。
+
+每次新执行都扫描已有 `sNN-v*-*` 文件，选择下一个未占用版本。旧版本即使失败，也保留为历史证据。默认 `Overwrite allowed: no`。
+
+这个规则不是形式主义。它是从实际失败里长出来的。早期有 broad-run 候选、覆盖缺陷、重复 worker、transport failure、 rejected image、incomplete evidence。只要允许“为了让目录好看而覆盖旧文件”，项目历史就会被抹掉，后续根本无法判断哪个 prompt 生成了哪个图，哪个失败被修复过，哪个版本是用户真正接受的。
+
+所以最终形成的共识是：失败不是垃圾，失败是生产系统的一部分证据。
+
+## 阶段六：Agent 流程的试错
+
+角色一致性阶段最早使用的是主会话、可见子会话和内部 one-shot slide Agent 的组合。
+
+这个阶段产生了很多有效结果，也暴露了机制问题：
+
+- S-05 单张试验证明了 reference-capable route 可以跑起来，但也留下了 overwrite defect 的历史记录。
+- S-21、S-14、S-25 等画面视觉上被接受，但 S-14 出现了 duplicate worker 问题。
+- session-04 处理 S-33 和 S-06，形成更干净的 visible child session + one-shot SubAgent 模式。
+- R4 处理 S-02、S-03、S-04 时，图片被接受，但 brief / packet ownership 出现偏差：文件由 slide Agent 写，而不是由 visible child session 预先拥有。
+- R5 处理 S-07、S-08、S-09 时，修正了 brief ownership，让成功输出在 worker 启动前已有 child-owned brief / packet。
+
+这一段的意义在于：项目并不是一次设计出完美工作流，而是用实际画面生产暴露机制缺陷，再把缺陷转成规则。
+
+早期的 Agent 并不是失败。它们帮助证明了 per-slide isolation、返回 receipt、reference role、review suppression、append-only retry 等机制。但当项目进入正式生产时，这套机制显得太重。
+
+## 阶段七：callback-only 和父子会话关系定型
+
+长任务真正可持续，还需要解决一个上下文问题：主会话不能一直盯着子会话轮询，也不能把所有生产细节都塞回父线程。
+
+R6 阶段把 callback-only 流程验证出来：
+
+- 子会话完成所有允许的项目写入。
+- 子会话更新 `slides/slides.md`。
+- 子会话写 compact `child-session-handoff.md`。
+- 子会话最后一步 callback 父会话。
+- callback 后子会话不再写文件、不再检查项目。
+
+这改变了主会话的职责。主会话不再是细节审计员，而是调度者和用户接口。它只需要读 callback 和 handoff 中的关键字段：
+
+- status；
+- topology；
+- resolved versions；
+- image paths；
+- problems；
+- needs_user。
+
+如果 clean completion，没有问题，父会话就不再打开 prompt、图片细节、return ledger 重新审一遍。
+
+这一步对后来的批量生产非常关键。它把生产从“人盯着每个 worker 过程”变成“文件状态 + callback 驱动的可续跑流程”。
+
+## 阶段八：从 test/audit 到 production-light
+
+项目真正提速发生在 R7。
+
+在 R7 之前，很多生产还围绕 Agent / packet / return / review / completion gate 展开。这适合 test/audit，但不适合正式批量生产。
+
+R7 的核心优化是 production-light：
+
+- normal production 由 clean child session 直接完成。
+- 不默认启动 Agent / SubAgent。
+- 不默认写 packet / return。
+- 不默认写 review 文件。
+- 不做 routine final audit。
+- 保留必要的写入保护：版本扫描、append-only、no overwrite、slides.md 更新、compact handoff、callback final action。
+
+这个优化不是偷懒，而是把已经被证明的流程从“测试形态”压缩成“生产形态”。
+
+session-12 先生成 S-26、S-27、S-28，用户接受，记录约 25m48s / 134K tokens。
+
+session-13 再生成 S-29、S-30、S-31，直接 child session、无 Agent/SubAgent，用户接受，记录约 10m32s / 114K tokens。
+
+从 session-13 开始，direct-child production-light 成为正式默认模型。
+
+## 阶段九：容量验证
+
+生产路线定型后，项目继续做容量验证，而不是立刻假设可以无限扩张。
+
+先是 5-slide validation：
+
+- 范围：S-32、S-34、S-35、S-36、S-37。
+- topology：direct child。
+- review：none。
+- 结果：五张图被用户接受。
+- 用户观察：callback 时约 152K tokens / 58% context；最终约 164K tokens / 63% context。
+- 发现：callback-order defect，子会话在 callback 后仍做了部分文档 / 检查工作。
+- 修正：未来 child prompt 必须明确 callback 是最终动作。
+
+然后是 8-slide compression validation：
+
+- 范围：S-38 到 S-45。
+- topology：direct child。
+- review：none。
+- 结果：8 张图进入 production-pass。
+- 用户观察：174K tokens / 67% context / 38m37s。
+- 机制结果：callback-final contract 被验证，callback 后没有再观察到 child project writes 或 checks。
+
+这一步把普通 production-light 子会话容量提升到最多 8 个 ordinary slides，同时保留降级规则：身份重、修复重、核心风险高或上下文昂贵的任务仍然用 1 到 3 个 slide。
+
+## 阶段十：最后一包 S48-S50 收口
+
+最后的默认生产范围只剩 S-48、S-49、S-50。
+
+这一包已经不再是工作流发明，也不是机制辩论。它按已经定型的 production-light route 直接执行：
+
+- direct child session；
+- no Agent/SubAgent；
+- review mode none；
+- 写 brief、prompt、image；
+- 更新 `slides/slides.md`；
+- 写 `child-session-handoff.md`；
+- callback 父会话作为最终动作。
+
+最终记录：
+
+- S-48 -> `s48-v1-image.png`；
+- S-49 -> `s49-v1-image.png`；
+- S-50 -> `s50-v1-image.png`；
+- child reported `complete`；
+- `problems: none`；
+- `needs_user: none`；
+- parent verification found expected files present, review files absent, slide rows updated, and no post-callback child writes。
+
+到这里，当前 51-shot 表的 shot-image production 完成。项目状态进入 assembly-closeout。
+
+## 素材时间线
+
+### 0. 工作台定位期
+
+- 明确 `video-workbench` 是本地视频 / slide 执行工作台。
+- 确立 `projects/` 为唯一真实项目根。
+- 确立 `project.md`、`execution-plan.md`、`visual-system/`、`slides/`、`tasks/` 的职责。
+- 确立 GPT / User / Codex 分工。
+
+### 1. 《在路上》项目初始化
+
+- 接收 GPT V2 前期策划文件。
+- 清理 intake。
+- 提取四文件执行骨架。
+- 建立 51-shot `slides/slides.md` 事实表。
+- 确立核心视觉方向：landscape-led road documentary / restrained poetic realism。
+
+### 2. 视觉锚点建立
+
+- 人物锚点板 accepted。
+- 透明人物切片 accepted。
+- A/B/C/D 风格锚点建立。
+- C 风格修复 accepted。
+- 五个 anchor-test shots accepted：S-01、S-10、S-46、S-47、S-51。
+
+### 3. 参考图机制证明
+
+- S14 investigation 证明 host visible-context reference path 可用。
+- 项目规则更新为 `gpt-image-2 Advisor + loaded reference image + host image_gen`。
+- identity-critical shots 不允许 text-only 身份生成。
+
+### 4. 角色一致性和 per-slide traceability
+
+- 从 S-05、S-21、S-14、S-25、S-33 等试验开始。
+- 发现并记录 overwrite、duplicate worker、brief ownership、transport failure 等问题。
+- 固化 append-only、no overwrite、one-shot worker、review suppression、visible-reference evidence 等规则。
+
+### 5. callback-only 定型
+
+- 子会话完成写入和 handoff 后 callback 父会话。
+- 父会话不再 routine polling。
+- clean callback 后父会话只消费 compact handoff。
+
+### 6. production-light 定型
+
+- session-12：S-26、S-27、S-28 accepted。
+- session-13：S-29、S-30、S-31 direct-child accepted。
+- direct-child, no-Agent, review none 成为正式生产默认路线。
+
+### 7. 容量验证
+
+- 5-slide validation：S-32、S-34、S-35、S-36、S-37 accepted，发现 callback-order defect。
+- 8-slide validation：S-38 到 S-45 production-pass，验证 callback-final contract。
+- 默认 ordinary package size 提升到最多 8 slides。
+
+### 8. 完成当前 51-shot 表
+
+- final package：S-48、S-49、S-50 complete。
+- 当前 51-shot shot-image production complete。
+- 下一阶段转入 assembly / export / closeout。
+
+## 可以支撑文章的几个观点
+
+### 观点一：AI 生产不是 prompt 工程，而是本地执行系统工程
+
+《在路上》不是靠一条万能 prompt 完成的。它靠的是文件结构、版本策略、参考图规则、子会话边界、callback、handoff 和生产线轻量化。
+
+Prompt 很重要，但 prompt 只有在能被追溯、能被续跑、能和参考图 / 版本 / 输出路径绑定时，才真正成为生产资产。
+
+### 观点二：失败记录比成功截图更有价值
+
+项目里保留了 rejected image、incomplete evidence、transport failure、duplicate worker、sequencing warning、callback-order defect。它们没有被清掉，而是被转化为规则。
+
+这些失败让系统知道：
+
+- 不能覆盖旧文件；
+- 不能把 text-only 当身份参考；
+- 不能让 worker 抢写 brief；
+- 不能 callback 后继续写文件；
+- 不能每次都重开完整 audit。
+
+### 观点三：正式生产不是更复杂，而是把复杂度收回去
+
+早期 `test/audit` 需要 Agent、packet、return、review、completion gate。它适合发现问题。
+
+但正式生产阶段，复杂度必须被压缩。`production-light` 的价值就是在保留必要安全线的前提下，去掉 routine review、routine audit、packet / return 和默认 Agent，把生产变成 direct-child package。
+
+这不是降低标准，而是把“已经证明过的标准”变成更低成本的执行方式。
+
+### 观点四：长任务续跑靠文件，不靠记忆
+
+从 `project.md` 到 `production-run-status.md`，从 `slides/slides.md` 到 `child-session-handoff.md`，整个项目不断把聊天过程固化为可读文件。
+
+这使得主会话压缩、子会话切换、上下文中断都不再是灾难。下一轮只要按 load order 读文件，就能继续。
+
+### 观点五：人的角色不是每张图都 review，而是决定何时相信生产线
+
+在 `production-light` 阶段，用户不再逐张 image review。用户做的是更高层的判断：
+
+- 核心路线是否成立；
+- 哪些包可以进入 production-pass；
+- 默认生产容量能不能从 3 张提升到 5 张、再到 8 张；
+- 什么时候停止生产，转入 assembly / closeout。
+
+这改变了人机协作的焦点：人不是流水线质检员，而是生产路线的 owner。
+
+## 可引用句子
+
+- 《在路上》的完成，不是“生成 51 张图”的故事，而是“把一个不稳定的 AI 生产现场，逐步压成可续跑生产线”的故事。
+- GPT 给了方向，Codex 把方向变成文件系统里的执行秩序。
+- 真正让项目继续下去的，不是某一次聊天记忆，而是 `project.md`、`execution-plan.md`、`slides.md` 和 handoff。
+- 失败没有被抹掉。失败被留在版本里，变成下一条规则。
+- 从 test/audit 到 production-light，核心变化不是更大胆，而是更克制。
+- 生产线成熟的标志，不是记录越来越多，而是知道哪些记录可以不写。
+- 当 callback 成为子会话的最后动作，长任务才真正从“盯进度”变成了“等状态”。
+- 人不必 review 每张图，但必须决定什么时候一条路线已经值得信任。
+- 这个项目的经验是：AI 创作要规模化，必须先把创作过程变成可追溯的本地工程。
+
+## 文章可展开的结构建议
+
+### 写法 A：项目复盘型
+
+1. 开头：为什么不是 prompt 成功，而是工作流成功。
+2. 第一部分：`video-workbench` 为什么要先定边界。
+3. 第二部分：《在路上》如何从 GPT 策划变成四文件执行骨架。
+4. 第三部分：视觉系统如何用 A/B/C/D 和人物锚点稳定下来。
+5. 第四部分：reference-capable generation 为什么是关键转折。
+6. 第五部分：从 Agent-heavy 到 production-light 的演化。
+7. 第六部分：容量验证和全量完成。
+8. 结尾：AI 视频生产的真正对象，是“可续跑生产线”。
+
+### 写法 B：方法论型
+
+1. 输入不是 prompt，是 accepted intake。
+2. 输出不是图片，是 append-only project state。
+3. 审美不是感觉，是 visual-system rule。
+4. 失败不是删掉，是版本化。
+5. 协作不是等人盯，是 callback。
+6. 批量不是并行，而是轻量生产线。
+
+### 写法 C：人机协作型
+
+1. GPT 负责想象和策划。
+2. 用户负责决定与接受。
+3. Codex 负责本地化、执行、记录和续跑。
+4. 子会话负责小批量生产。
+5. 文件系统负责记忆。
+6. 最后形成的不是一个 prompt，而是一套可被复用的生产经验。
+
+## 关键证据路径
+
+项目状态与结论：
+
+- `projects/2026-06-23-在路上/project.md`
+- `projects/2026-06-23-在路上/execution-plan.md`
+- `projects/2026-06-23-在路上/slides/slides.md`
+- `handoff/2026-06-25-on-the-road-formal-production-handoff.md`
+
+视觉系统：
+
+- `projects/2026-06-23-在路上/visual-system/visual-system.md`
+- `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
+- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
+
+工作流规则：
+
+- `VIDEO_WORKBENCH.md`
+- `docs/workflows/project-lifecycle.md`
+- `docs/workflows/slide-task-orchestration.md`
+- `docs/workflows/slide-task-templates.md`
+
+关键 handoff：
+
+- `handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md`
+- `handoff/2026-06-24-character-consistency-r6-notification-s16-handoff.md`
+- `handoff/2026-06-25-on-the-road-formal-production-handoff.md`
+
+后期生产任务：
+
+- `projects/2026-06-23-在路上/tasks/2026-06-25-production-capacity-validation/production-run-status.md`
+- `projects/2026-06-23-在路上/tasks/2026-06-25-8slide-compression-validation/production-run-status.md`
+- `projects/2026-06-23-在路上/tasks/2026-06-25-final-production-s48-s50/production-run-status.md`
+
+## 待补充素材
+
+这些内容如果未来写正式文章，建议再补：
+
+- 选几张关键图片作为插图：人物锚点板、C 修复样本、S-16 rejected / accepted 对照、8-slide validation 中的一组连续画面。
+- 补一段用户视角：为什么《在路上》的主题需要“世界先于人”。
+- 补一段操作截图或目录截图：展示 `slides/sNN/sNN-vN-*` 的 append-only 结构。
+- 如果文章面向工程读者，可加入 callback-only 子会话流程图。
+- 如果文章面向创作者，可弱化 Agent / token 细节，强化“从灵感到生产线”的叙事。
+