knowledge-vault/discussions/technology/Codex/0.规划与重构/0.环境规划-writing-2026-06-15.md

# 1

阅读这里的3份文档：

1. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15\00-五库重构总纲.md
2. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15-规划总结.md
3. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15\02-writing-workbench调整意见.md

目前在`writing-workbench`中，实际上没有正式启动项目，因为写作流程跑不下去。`C:\Users\wangq\Documents\Codex\writing-workbench\projects\active`下的两个项目，可以算作只是测试验证，但是就发生了`2026-06-15-规划总结`中发现的问题。
这也是本次重构的核心原因。

有问题提出。


我读完三份规划文档，也核对了当前 `writing-workbench` 的入口文档和两个 active 项目。我的核心判断是：现在最需要问清楚的不是“怎么补流程”，而是“什么东西不再允许进入 active article project”。

我建议先回答这几组问题：

1. `projects/active` 是否只能放“正式文章项目”？
   现在 [2026-06-04-Sanguo-test-slug](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-04-Sanguo-test-slug) 只有一份讨论稿，更像测试材料，不像项目。是否要新增 `projects/sandbox/`、`projects/tests/` 或 `projects/candidates/`，把这类验证对象从 `active` 中隔离出去？

2. “已决定写作”到底需要多强？
   是用户说“这要写成文章”就够，还是必须同时有：工作标题、目标读者、材料范围、当前命题、下一步产物？如果不定义，`material_intake` 很容易继续吸入开放讨论。

3. `insight_discussion` 默认应该放哪里？
   `02-writing-workbench调整意见.md` 倾向让观点生成和隐形规则显影留在 `knowledge-vault`，但当前 Anti 项目的 handoff 又允许“项目内小范围 positioning discussion”。这里需要定默认规则：项目内只能做“服务本篇文章的定位讨论”，还是默认回 `knowledge-vault`，只把结果稿放回 `materials/`？

4. 是否需要一个“pre-project / candidate”层？
   `Anti-Overengineering-Gate` 已经有项目壳，但还在问“这篇文章真正要写什么”。这说明它介于材料包和正式文章项目之间。要不要承认这个中间态，而不是强行叫 active article project？

5. 现有模板是缩小，还是保留但降权？
   [PROJECT_STRUCTURE.md](C:/Users/wangq/Documents/Codex/writing-workbench/templates/article-project/PROJECT_STRUCTURE.md) 仍然默认包含 outline review、tribunal、model-writing 等完整链条。要不要做一个 `lite-skeleton`，只包含 `project.md / source-map.md / status.md / materials / decision-records`，把 full structure 改成扩展模板？

6. “真实调用”边界是否要写进 Writing Workbench，而不只写进 CCPE？
   现在 `WORKBENCH.md` 还写“dispatches writer or reviewer sessions”，但没有强制说明：没有真实 thread/sub-session/invocation record，就不能产生正式 reviewer report。这个规则是否要成为本仓库硬规则？

7. 当前两个 active 项目怎么处理？
   我的倾向是：`2026-06-04-Sanguo-test-slug` 移出 active，标成 test/sandbox；`2026-06-12-Anti-Overengineering-Gate` 暂留 active 或改成 candidate，但明确禁止进入立意/提纲/评审，直到用户确认命题。

8. `README / WORKBENCH / playbook` 是否要把“不要自动进入下一阶段”写成默认停止规则？
   目前文档说了进入条件，但没有足够强地说：材料承接完成后默认停止，等待用户决定，不自动 positioning、不自动 outline、不自动 review。

如果先做改造，我会建议第一刀只改边界和状态，不动大流程：新增项目类型/状态说明，降权模板，加入 no-simulation 和 material_intake stop rule，然后迁移或标记两个 active 测试项目。这样能直接针对这次失败原因，而不是继续加结构。

# 2


1. `projects/active` 是否只能放“正式文章项目”？
   现在 [2026-06-04-Sanguo-test-slug](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-04-Sanguo-test-slug) 只有一份讨论稿，更像测试材料，不像项目。是否要新增 `projects/sandbox/`、`projects/tests/` 或 `projects/candidates/`，把这类验证对象从 `active` 中隔离出去？
   
   这是我尝试在这里写文章，发现没法进行下去。我又回到了旧的写作流程上，在`knowledge-vault`中，我实际上已经完成了文章的撰写工作：
   * `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\article-discussions\认知截肢与无摩擦滑流\`记录全部的讨论交流：
     * 有主笔/韩愈的两次会话，比如`认知截肢与无摩擦滑流讨论1-韩愈.md`
     * 有与各提纲评审员的多次会话讨论，比如`认知截肢与无摩擦滑流评审-巨人.md`，`认知截肢与无摩擦滑流评审1-张辽.md`等
     * 有提纲的历次版本，比如`认知截肢与无摩擦滑流提纲1.0.md`
     * 有文章的metadata，`认知截肢与无摩擦滑流提纲Metadata.md`
   * `C:\Users\wangq\Documents\Codex\knowledge-vault\sayings\2026\2026-06-13-cognitive-amputation.md`是成稿
   
   我的想法：我后续还是计划在这里尝试写作，但是项目推动决策会更灵活——由我来判断，这里准确说是工具调用地，而不是生产地。帮我记录一些讨论过程，讨论结果，省一些体力活；而不是自行决定如何往下跑。

2. “已决定写作”到底需要多强？
   是用户说“这要写成文章”就够，还是必须同时有：工作标题、目标读者、材料范围、当前命题、下一步产物？如果不定义，`material_intake` 很容易继续吸入开放讨论。
   
   在这里建立项目，就意味着决定进入写作。前期工作在`knowledge-vault`中已经完成了。
   比如，`2026-06-04-Sanguo-test-slug`，实际上素材部分包括了四部分，这些完毕后，才会进入到写作阶段：
   * `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\社会学家GPT\社会学讨论.md`，实际上有历史学讨论和社会学讨论；
   * `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\短视频时代的知识论危机-思想考古过程.md`，是思想考古讨论过程；
   * `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\短视频时代的知识论危机-思想考古报告.md`，是思想考古报告

---

我考虑的，在这里的工作流程为：
1. 我在Web上完成素材，包括讨论稿、报告这些内容
2. 我在Web上完成初步提纲提炼后进入`writing-workbench`。我建立文章项目，并提供或者指出原始提纲这些文件路径。
   1. 之所以这样考虑，是因为素材内容量很大，必须使用高上下文的LLM，通盘了解后，才能有个初步提纲
   2. 即使初步提纲出来，也可能存在未充分利用现有素材的情况
3. `writing-workbench`的起始阶段从提纲评审开始：
   1. 基于初步提纲，需要对素材进行压缩，但是要考虑损失的情况，即本身提纲对素材利用不充分，在压缩时反而把素材的那部分内容去掉了
   2. 基于压缩的素材和提纲，调用评审智能体进行评审，生成评审结果
   3. 主笔智能体进行新提纲的撰写
   4. 评审可能会进行多轮
4. 撰写阶段，基于评审后的提纲和素材生成文章正文初稿

期间，所有的决策，包括是否再次评审，谁来评审，是否进入撰写，撰写是基于章还是基于节，等等，都由我/用户显示发指令进行。

---

考虑到现在的流程不完善，我考虑初期`writing-workbench`分为两个过程：
1. 定义需要的能力，包括智能体或者Skill；由CCPE System或者Skills-vault来负责完成。
2. 调用具体的智能体或者Skill完成具体的工作。

定位：对于过程1，`writing-workbench`相当于是甲方，规划自己的工作计划，调用的工具/Agent/Skill，缺失的部分由乙方（CCPE，Skills）提供。

`writing-workbench`工作过程产物，全部保留在自己的工作目录下，包括素材的加工，评审员、主笔的讨论内容，不回到`knowledge-vault`。
`knowledge-vault`中的成果正文部分，也由我自行维护。

---

基于以上内容，重新规划下`writing-workbench`，假设不考虑/不借鉴现有的规则，你有哪些问题？

基于你这版定位，我会把问题重新聚焦为：`writing-workbench` 不是“生产地”，而是用户主控写作流程中的工具调用地、记录地、临时加工地。那么关键问题如下。

**一、项目入口**

1. 一个 `writing-workbench` 项目是否必须已经有“Web 初步提纲”？
   如果必须，那么项目入口不再是 `material_intake`，而是 `outline-review-intake`。

2. 项目创建时，最低输入是什么？
   我建议至少是：原始提纲路径、素材来源清单、用户给出的当前写作目标。是否还需要工作标题、目标读者、预期文章类型？

3. 如果 Web 上只完成了素材讨论，还没形成初步提纲，是否禁止建项目？
   这会决定 `writing-workbench` 是否允许 candidate 项目。

**二、素材处理**

4. 素材压缩的目标是谁来定义？
   是“服务当前提纲评审”，还是“尽量保留全部潜在写作可能性”？这两者会导向完全不同的压缩策略。

5. 当“初步提纲可能漏掉素材重点”时，压缩产物应分几层？
   例如：`outline-aligned digest`、`unused-material candidates`、`risk-of-loss notes`。否则压缩会强化旧提纲的盲区。

6. 素材加工结果是否全部留在项目内？
   你已经倾向“全部留在 writing-workbench”，那还要不要保留 source-map 指向 knowledge-vault 原文，防止项目内压缩稿变成事实源？

**三、评审调用**

7. 评审智能体是由 `writing-workbench` 直接调用，还是只生成 invocation/prompt，由用户去 Web 或其他平台调用？
   这决定“真实调用记录”怎么保存。

8. 每次评审是否都必须保存完整讨论过程？
   你说要省体力活、记录讨论过程。需要明确最低记录：完整 session、最终 report、decision-ready summary，三者是否都必须有？

9. 评审员列表由谁决定？
   默认不自动派发，那么项目文档里应该只提供“候选评审能力清单”，每轮由用户显式点名。

**四、主笔与提纲迭代**

10. 主笔智能体重写提纲时，输入权威顺序是什么？
   用户原始提纲、素材压缩稿、评审报告、用户裁决，谁优先？如果评审意见冲突，主笔能不能自行取舍？

11. 多轮评审什么时候停止？
   既然停止由用户决定，系统是否只负责提示“可选下一步”，不能声明“已通过/应进入正文”？

12. 新提纲版本如何编号？
   需要区分 Web 初始提纲、评审后提纲、用户手修提纲、主笔修复提纲，否则后面会混。

**五、正文撰写**

13. 正文生成默认按章、按节，还是由用户每次指定？
   你已明确由用户决定，那 playbook 应禁止自动从提纲进入全文生成。

14. 正文初稿生成时，是否允许主笔补充素材外内容？
   如果允许，要标注“模型补充”；如果不允许，要强制 source-grounded。

15. 文章正文成稿是否回写 knowledge-vault？
   你说 knowledge-vault 成果正文由你自行维护，那么 `writing-workbench` 只保存项目过程和可选草稿，不负责发布归档。

**六、能力建设与调用分离**

16. “定义需要的能力”和“调用能力完成工作”是否应成为两个明确模式？
   例如：
   - `capability-request mode`：写需求，交给 CCPE / skills-vault。
   - `execution mode`：调用已有 Agent / Skill 处理当前项目。

17. 缺能力时，项目是否暂停？
   还是允许用 manual placeholder？如果允许，占位产物必须不能冒充正式 Agent 输出。

18. `writing-workbench` 作为甲方，向 CCPE / skills-vault 提需求时，需求单放在哪里？
   项目内？全局 `requirements/`？还是 `ccpe-requests/`？

**七、目录和状态**

19. `projects/active` 是否只放“用户已经决定要推进的文章工具调用项目”？
   如果是，`2026-06-04-Sanguo-test-slug` 可以不是错误，只是它缺少项目壳和 source-map。

20. 是否需要新增状态，而不是新增目录？
   例如：`outline_review_intake`、`material_compression`、`review_round`、`outline_repair`、`drafting_requested`、`paused_waiting_user_decision`。

21. 当前 `material_intake` 这个阶段名是否要废弃或降级？
   按你的新流程，真正入口不是材料进入，而是“已有 Web 提纲后的评审准备”。

我认为最核心的问题只有一个：`writing-workbench` 的第一阶段到底叫不叫“提纲评审准备”？如果答案是是，那么整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写。

# 3

**一、项目入口**

1. 一个 `writing-workbench` 项目是否必须已经有“Web 初步提纲”？   
   是的，现在的上下文窗口限制，导致`material_intake`无效，所以必须已经有“Web 初步提纲”。

2. 项目创建时，最低输入是什么？   
   我有不同的主笔，这个其实已经确定了文章的类型。比如启动时，我要求主笔是`韩愈`，那就是学术性散文；是`蒙田`，那就是随笔。
   你可以读一下这个提纲，`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\article-discussions\认知截肢与无摩擦滑流\认知截肢与无摩擦滑流提纲1.0.md`。这个就是初稿提纲的范本，其他初稿提纲都会是这个样。

3. 如果 Web 上只完成了素材讨论，还没形成初步提纲，是否禁止建项目？
   是的，如果没有提纲，不会开始项目。

**二、素材处理**

4. 素材压缩的目标是谁来定义？
   保留全部潜在写作可能性。

5. 当“初步提纲可能漏掉素材重点”时，压缩产物应分几层？
   例如：`outline-aligned digest`、`unused-material candidates`、`risk-of-loss notes`。否则压缩会强化旧提纲的盲区。
   我觉得压缩，是否体现原报告/讨论稿内容即可，不同的材料可能压缩的方式也不一样：
   * 我往往会基于`思想考古报告`来写作，这个甚至可以考虑不压缩；
   * 我提供的我自己的`过往文章`，或者`讨论稿`，这个可能会有些发散，可以考虑压缩多一些。
   如何具体压缩，可能需要试跑几轮后，才能初步确定。

6. 素材加工结果是否全部留在项目内？
   素材加工的结果全部保留在项目内。
   保留`source-map`，这样备查。至少可以查到原文，发现是否过度压缩，有损压缩。

**三、评审调用**

7. 评审智能体是由 `writing-workbench` 直接调用，还是只生成 invocation/prompt，由用户去 Web 或其他平台调用？
   这决定“真实调用记录”怎么保存。
   由 `writing-workbench` 通过子会话调用评审智能体、主笔智能体和其他技能。
   如果用户去 Web 或其他平台调用，那这个和我现在写文章没啥区别，`writing-workbench`就没有必要存在了。

8. 每次评审是否都必须保存完整讨论过程？
   是的，需要记录讨论过程，完整session，最终report都必须要。

9. 评审员列表由谁决定？   
   甚至都不需要提供“候选评审能力清单”，每轮用户自行显示点名。

**四、主笔与提纲迭代**

10. 主笔智能体重写提纲时，输入权威顺序是什么？   
   现在主笔修订提纲一般是这样的过程，可以参考：
   1. 我同时提供多份评审意见，我的反思，我的意见，让主笔汇总判断合理性
   2. 基于主笔的判断，我发出修订指令，或者继续调整方向的指令；关键决策是我做的。
   3. 主笔完成修订

11. 多轮评审什么时候停止？   
   系统可以提供建议，提示下一步。不能声明`已通过`，声明了也没意义。

12. 新提纲版本如何编号？
   保持一致的编号即可，web初始提纲就是1.0，评审后修订的，从2.0开始。
   `评审后提纲`不准确，评审只有评审意见，基于评审意见才开始修订；用户不会主动修改提纲，用户发出的也是评审意见，等同于评审员。
   个别微调的，可以起小版本号，比如`3.1`。

**五、正文撰写**

1.  正文生成默认按章、按节，还是由用户每次指定？
   绝对禁止全文生成，否则干的多错的多。这个正文生成，已经作为主笔的工作方式，内嵌到其提示词中了。主笔不会去全文生成，我们这里清楚这个逻辑就行。

2.  正文初稿生成时，是否允许主笔补充素材外内容？
   允许，本身评审意见就会要求补充案例，这个很可能超出了素材。这里可以考虑要标注。

3.  文章正文成稿是否回写 knowledge-vault？
   是的，因为knowledge-vault 成果正文是面向发布的，还有发布的相关内容要填写。这里只负责项目过程，草稿生成就行。
   当然本地留一份正文完整稿，也是可以的；因为这个是后续润色优化的基础。
   不保留，我就会指向到`knowledge-vault 成果正文`作为润色的源。

**六、能力建设与调用分离**

1.  “定义需要的能力”和“调用能力完成工作”是否应成为两个明确模式？   
   是的，应该是两个明确的模式：
   - `capability-request mode`，这个是“供应商”的工单
   - `execution mode`，这个是自己的工作工单

2.  缺能力时，项目是否暂停？   
   产生供应商工单后暂停。直到我通知配套的Agent准备好。
   绝不能冒充，因为素材多，主会话会很快超出上下文。而且尤其是专家智能体，冒充的完全没质量。

3.  `writing-workbench` 作为甲方，向 CCPE / skills-vault 提需求时，需求单放在哪里？
   全局的`requirements/`，根据我最开始提供的文档，明确是CCPE还是skills-vault的。
   然后我根据这个需求单，去到具体项目打造。

**七、目录和状态**

1.  `projects/active` 是否只放“用户已经决定要推进的文章工具调用项目”？
   如果是，`2026-06-04-Sanguo-test-slug` 可以不是错误，只是它缺少项目壳和 source-map。
   我觉得可以考虑再做一个简化，我们这个是写文章的项目，不是开发项目。所以不是特殊情况，一定会做完。简化的结果就是`projects/`不再分子文件夹了。

2.  是否需要新增状态，而不是新增目录？
   这个状态可能不一定准，实际很有可能，提纲审了几轮后，我再补充素材，需要重新压缩加工……
   我倾向于用文件夹。

3.  当前 `material_intake` 这个阶段名是否要废弃或降级？
   是的`material_intake`这个阶段实际上是评审提纲的子阶段了，对素材的加工。
   而对素材进行加工的原因就一个，现在的上下文窗口限制。

> 我认为最核心的问题只有一个：`writing-workbench` 的第一阶段到底叫不叫“提纲评审准备”？如果答案是是，那么整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写。

是的。整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写

读了你给的提纲范本。这个范本说明 `writing-workbench` 的入口确实不应该是“材料进入”，而应该是“已有 Web 初纲后的提纲评审与修订工程”。它已经包含：主笔类型、文章体裁、统摄隐喻、结构原型、核心论点、模块目标、写作协议。也就是说，项目启动时已经越过了开放观点生成阶段。

我建议把 `writing-workbench` 重规划为下面这个定位。

**核心定位**

`writing-workbench` 是文章写作的本地工具调用与过程记录场。

它不负责开放素材讨论，也不负责判断文章是否值得写。用户已经在 Web / knowledge-vault 中完成前期讨论和初纲生成后，才进入这里。进入后，它负责：

- 接收 Web 初稿提纲和素材路径。
- 围绕提纲评审准备上下文。
- 对素材做必要压缩或引用整理。
- 通过真实子会话调用主笔、评审员、Skill。
- 保存完整 session、report、提纲版本、用户裁决和草稿。
- 在缺能力时生成供应商工单，然后暂停。
- 不自行推进阶段，不冒充专家，不自动全文生成。

**推荐结构**

我会建议废掉 `projects/active / completed / abandoned` 这种开发项目式分层，改成：

```text
projects/
  2026-06-04-sanguo/
  2026-06-13-cognitive-amputation/
requirements/
  ccpe/
  skills-vault/
templates/
  article-project/
```

每个文章项目内部用状态和文件夹表达进度，而不是靠 `active` 目录表达。因为你这里的文章项目大概率都会完成，中途真正重要的是“当前停在哪个用户决策点”。

项目内建议结构：

```text
project.md
source-map.md
status.md
decision-log.md

00-intake/
  initial-outline-v1.0.md
  intake-note.md

01-materials/
  source-digests/
  source-links.md
  compression-notes.md

02-outline-review/
  round-01/
    review-brief.md
    reviewers/
      zhang-liao/
        session.md
        report.md
      giant-cognition/
        session.md
        report.md
    user-reflection.md
    synthesis-for-writer.md

03-outline-repair/
  writer-session-v2.0/
    session.md
    outline-v2.0.md
    repair-notes.md

04-drafting/
  section-sessions/
  draft-v1.md

05-revision/
  revision-sessions/
  draft-v2.md

publish/
  local-final.md
  knowledge-vault-target.md
```

**工作流**

入口固定为：

```text
Web 初稿提纲 + 素材路径 + 主笔身份 -> writing-workbench 项目
```

第一阶段不叫 `material_intake`，而叫 `outline-review-prep` 或 `outline-review-intake`。素材加工只是它的子任务，原因是上下文窗口限制，不是因为项目还没进入写作。

流程应是：

1. 用户创建项目，提供初纲和素材路径。
2. Codex 建立 `source-map`，复制或引用初纲为 `initial-outline-v1.0.md`。
3. Codex 根据评审需要处理素材：有些报告不压缩，有些讨论稿压缩，有些过往文章只摘取相关段落。
4. 用户点名评审员。
5. Codex 通过真实子会话调用评审员，保存完整 `session.md` 和 `report.md`。
6. 用户提供反思、判断和修订指令。
7. Codex 调用主笔子会话，生成 `outline-v2.0.md`。
8. 是否继续评审、是否进入正文、按章还是按节写，全部等待用户显式指令。
9. 正文草稿保留在本项目；发布成稿由用户维护到 `knowledge-vault/sayings`，项目内可记录目标路径。

**两个模式**

你提出的“甲方 / 供应商”关系很关键，应写成正式模式：

`execution mode`：当前文章项目内使用已有 Agent / Skill 完成具体工作。

`capability-request mode`：发现缺少 Agent / Skill / Runtime 时，生成需求单到：

```text
requirements/ccpe/
requirements/skills-vault/
```

生成需求单后，当前文章项目暂停，直到用户确认供应商能力已准备好。禁止用主会话模拟专家输出。

**关键规则**

我建议写进仓库的硬规则有五条：

1. 没有 Web 初稿提纲，不创建文章项目。
2. 没有用户点名，不调用评审员。
3. 没有真实子会话，不产生正式评审报告。
4. 没有用户裁决，不进入下一阶段。
5. 禁止全文生成；正文写作粒度由用户指令和主笔提示词共同决定。

**我推荐的改造路线**

有三种做法：

1. 小改：只改 README / WORKBENCH / playbook，保留现有目录。
   成本低，但旧结构里的 `active`、`material_intake`、完整 production runtime 惯性还会继续误导。

2. 中改：重写规则文档，新增 `requirements/`，项目不再分 active/completed，模板改成“初纲评审起步”。
   这是我推荐的。它能匹配你的真实流程，又不会一上来重做全部历史项目。

3. 大改：把现有项目全部迁移成新结构，重建模板、索引、状态协议、需求工单协议。
   更干净，但现在可能过重。

我的建议是走第二种：先把 `writing-workbench` 明确改成“Web 初纲后的提纲评审、主笔修订、正文草稿调用场”，再处理现有两个项目的归位。

# 4

我倾向于大改。甚至于我们重建一个新的项目都可以，因为现有的`writing-workbench`压根没用起来。
`历史项目`在过去的`writing-workbench`没做起来，但实际上我已经按旧流程完成了，所以这个`历史项目`在这里也没有存在的必要了。
且基于此，我之前已经重构了`knowledge-vault`。

这个远程仓库也只用了44KiB的存储空间。
所以，你判断下，是重建新项目还是清空本项目重写。

我的判断：**清空本项目重写，不新建仓库。**

原因很直接：

1. `writing-workbench` 这个名字仍然准确  
   新定位还是写作工作台，只是从“文章生产 Runtime”改成“Web 初纲后的本地工具调用与过程记录场”。项目名不用换。

2. 现有仓库没有值得继承的工程资产  
   当前只有 3 个 commit，远程也很小。现有 README、WORKBENCH、模板、`projects/active` 结构基本都是旧假设产物，继续保留会持续误导后续会话。

3. 新建仓库会制造无意义边界  
   你已经围绕 `writing-workbench` 做了规划讨论，路径也稳定。换新仓库反而要解释“旧 writing-workbench 和新 writing-workbench 的关系”，这是额外负担。

4. 清空重写更符合这次重构性质  
   这不是版本迭代，而是入口范式变了：从 `material_intake -> article production` 改成 `Web 初纲 -> 提纲评审准备 -> 真实调用 -> 用户裁决 -> 分段正文草稿`。

我建议操作方式是：

- 保留 `.git`、远程、仓库名。
- 删除现有工作区内容。
- 重建最小结构：

```text
README.md
WORKBENCH.md
docs/
  operating-playbook.md
  project-lifecycle.md
  invocation-policy.md
requirements/
  ccpe/
  skills-vault/
projects/
templates/
  article-project/
```

- 不迁移两个历史项目。
- 只在新 README 里用一句话说明：旧结构已废弃，仓库于 2026-06-15 按“Web 初纲后的工具调用场”重建。
- 如果你想保留旧内容作为参考，可以先打一个 tag 或分支，例如 `archive/pre-2026-06-15-rebuild`，然后清空 master 重写。

我不建议新建项目。除非你想连名字也改，比如 `outline-review-workbench`，否则保留 `writing-workbench` 清空重写是最干净的。

# 5

好的，我们在这个项目上清空重写。
现在开始。

已在原 `writing-workbench` 仓库上清空重写，保留了 `.git` 和远程关系，没有新建仓库。

新结构现在是：

```text
README.md
WORKBENCH.md
docs/
  capability-requests.md
  invocation-policy.md
  operating-playbook.md
  project-lifecycle.md
projects/
requirements/
  ccpe/
  skills-vault/
templates/
  article-project/
  requirements/
```

核心规则已经写入：项目必须从 Web 初稿提纲进入；`material_intake` 被移除；`projects/active/completed/abandoned` 被废弃；评审员和主笔必须真实子会话调用；缺能力时生成 `requirements/ccpe/` 或 `requirements/skills-vault/` 工单并暂停；禁止默认全文生成。

验证结果：文件清单只剩新结构；旧术语扫描没有命中 `TBD/TODO/material_intake/Article Production Orchestrator/Outline Review Runtime`；`git status` 显示旧 scaffold 删除、新文档和模板新增/修改。当前变更还没有 stage 或 commit。

# 6

我们本次重构工作完成，有了一个初始化完成的环境。
现在做一次远程提交，并打上tag。



已完成远程提交和打 tag。

本次提交：

- Commit: `0721f81 rebuild: initialize writing workbench`
- Branch: `master`
- Tag: `v2026.06.15-init`

已推送到远程：

- `origin/master` -> `0721f81127e5911f7ca2c72392744bf904a353d7`
- `v2026.06.15-init` -> 已在远端存在

本地工作区现在是干净的。  
::git-stage{cwd="C:\Users\wangq\Documents\Codex\writing-workbench"}  
::git-commit{cwd="C:\Users\wangq\Documents\Codex\writing-workbench"}  
::git-push{cwd="C:\Users\wangq\Documents\Codex\writing-workbench" branch="master"}

# 7

由于目前CCPE现在主要是为本项目服务的，所以对CCPE来说，你有什么补充说明没有？
你需要一个本地项目说明么？刚改造知识库，准备了一个，你看你需要这个文件不，`C:\Users\wangq\Documents\Codex\knowledge-vault\PROJECTS.md`

需要。对 CCPE 来说，最好也有一个本地项目说明，而且我建议放在 `ccpe-system` 根目录，名字可以直接叫 `PROJECTS.md` 或 `PROJECT-RELATIONSHIPS.md`。

我看了 [PROJECTS.md](C:/Users/wangq/Documents/Codex/knowledge-vault/PROJECTS.md)。它作为五库关系总表是有用的，但对 CCPE 还不够，因为现在 `writing-workbench` 已经重写了定位：它不是泛泛的“已决定写作后的文章项目现场”，而是更具体的 **Web 初纲后的本地工具调用、真实子会话调用、过程记录场**。CCPE 需要知道这个新入口，否则它后续很容易继续按旧的 Article Production Runtime 方向过度设计。

我建议 CCPE 的本地说明补充这些点：

1. `writing-workbench` 是当前第一服务对象  
   CCPE 现在优先供应：主笔 Agent、评审 Agent、提纲评审 invocation protocol、真实子会话记录规范、素材压缩/上下文包规则。

2. CCPE 是供应商，不是项目现场  
   文章项目过程、评审 session、正文草稿不进 CCPE；CCPE 只保存可复用的 Agent / Runtime / Model Card / Protocol。

3. 从 `writing-workbench/requirements/ccpe/` 接收工单  
   CCPE 不主动猜测要造什么能力。只有当 writing-workbench 产生供应商工单，CCPE 才进入能力建设。

4. 明确禁止模拟正式输出  
   这条要写进 CCPE 根说明：packet / prompt / dispatch pack 不等于执行；正式评审和主笔输出必须来自真实 invocation。

5. CCPE 当前的优先能力清单  
   例如：韩愈主笔、张辽评审、巨人认知、认知显影、outline review packet、review report contract、writer repair packet。

6. 与 `skills-vault` 分工  
   如果是确定性脚本、文件转换、批处理，进入 `skills-vault`；如果是专家判断、Runtime、Agent、协议，进入 CCPE。

所以我的建议是：**需要这个文件，而且应该以 `writing-workbench` 为第一消费场景重写一版 CCPE 本地项目关系说明**。`knowledge-vault/PROJECTS.md` 可以作为总关系参考，但不能直接复制过去。

# 8

我的意思是：
1. 你的项目库里需要一个Projects这样的文件么，若需要，你可以构造一个自己用的。
2. 我后续要优化/重构CCPE，你有什么要给它的特殊说明，可以考虑出一个文件。我作为上下文放进初始会话中。

我新增了两个文件：

- [PROJECTS.md](C:/Users/wangq/Documents/Codex/writing-workbench/PROJECTS.md)  
  这是 `writing-workbench` 自己用的项目关系说明，明确它消费 `knowledge-vault / ccpe-system / skills-vault`，但不拥有上游知识、canonical Agent 或自动化工具源码。

- [docs/ccpe-rebuild-context.md](C:/Users/wangq/Documents/Codex/writing-workbench/docs/ccpe-rebuild-context.md)  
  这是给后续 CCPE 优化/重构会话使用的上下文文件，重点说明：CCPE 现在应作为 `writing-workbench` 的供应商，优先提供主笔、评审员、真实调用协议、no-simulation 规则、素材压缩/上下文准备规则，而不是继续设计完整自动写作 Runtime。

当前工作区只有这两个新增文件未提交。