ccpe-system/workbench/analysis/article-outline-development-runtime-creation-brief.md

---
artifact_type: ccpe-creation-brief
name: article-outline-development-runtime-creation-brief
requested_artifact: Article Outline Development Runtime v0
author: CCPE System
created: 2026-06-04
status: draft
based_on: CCPE System
---

# CCPE Creation Brief: Article Outline Development Runtime v0

## 1. User Request

```text
Original Request:
在深度创作流程中，建立“观点素材进入韩愈立意与提纲生成，再进入提纲评审”的标准写作闭环。需要创建和调整 CCPE 工件：Creation Brief、Article Context Architect Agent、Article Outline Development Runtime，以及 Agent Invocation Packet Protocol。

User Goal:
把过去由用户手工传递的大上下文、观点素材、立意、提纲、评审意见、修复请求，转化为 Agentic 架构下可调度、可记录、可复盘的观点到提纲评审闭环。

Known Constraints:
- 已有散文主笔：韩愈。
- 已有评审专家：张辽、认知显影、巨人认知。
- 这些专家已有 Lite 或 Kernel 版，并经过相关测试。
- 新建三件工件不是专家提示词，不需要 Lite 版。
- 新建工件应服务于 Agentic 工作流，而不是单智能体手工传递。
- 标准写作流程从观点素材文件开始，而不是从已有提纲开始。
- 韩愈输出立意前，必须先获得经过压缩拆分的观点素材包。
- 用户确认韩愈立意后，韩愈再输出提纲。
- 上下文可能非常大，不能默认一股脑塞进 Codex 当前会话。
- Runtime operator 不得模拟 canonical agent 的正式输出；不能真实调用时必须生成可投递启动包并等待外部结果。
- 用户仍是最终导演、编辑和决策门。
```

## 2. Intended Use

### 2.1 Primary Use Case

当用户在 writing-workbench 项目中放入观点素材文件并发起“写文章，观点在哪儿，让韩愈看立意和切入”时，Runtime 先调用 Article Context Architect 压缩拆分材料，生成 premise-context-pack；再调用韩愈输出立意；用户确认立意后，再调用韩愈输出初稿提纲；随后进入提纲评审闭环：构建提纲对齐上下文包，分发给多个评审员，保存独立会话与报告，综合评审意见，生成给主笔的修复请求，并由用户决定是否进入下一轮或确认提纲。

### 2.2 Secondary Use Cases

```text
- 为未来正文写作阶段、正文评审阶段、建模委员会阶段提供可复用的上下文分层模式。
- 降低大上下文对单次模型窗口的依赖。
- 支持补充素材进入后的增量压缩、影响范围判断和上下文包刷新。
- 把用户过去手工整理材料、复制上下文、汇总评审意见的工作转为文件化流程。
- 为韩愈、三位评审员、Article Context Architect 建立统一的 invocation packet / prompt-to-send 接口。
- 为 writing-workbench 的项目目录细化提供 CCPE 侧运行依据。
```

### 2.3 Non-Goals

```text
- 不创建新的文学主笔专家。
- 不重写韩愈、张辽、认知显影、巨人认知的专家内核。
- 不一次性覆盖完整文章生产流程。
- 不启动审判庭或建模委员会。
- 不自动决定文章立意、最终提纲或正文走向。
- 不模拟韩愈、张辽、认知显影、巨人认知或 Article Context Architect 的正式输出。
- 不把所有上下文复制进每个阶段目录形成散乱副本。
```

## 3. Target User

```text
Primary User:
深度创作流程的作者本人。

Secondary Users:
未来协助运行 writing-workbench 的 Codex / Claude Code / OpenClaw 类 agentic coding 或知识工作智能体。

Human Role:
最终导演、编辑、上下文优先级裁决者、评审结论采纳者。
```

## 4. Target Platform

```text
Codex
Claude Code
OpenClaw
Platform-neutral Markdown
Manual workflow
```

Platform notes:

```text
第一版以 Codex 文件工作流为主要目标，但文件结构和协议必须保持平台中立。评审专家可以在 GPT、Gemini、Claude 或其他平台运行，Runtime 通过文件化 dispatch pack、session.md、report.md 进行跨平台交接。
```

## 5. Artifact Classification

### 5.1 Primary Classification

```text
Hybrid Artifact
```

### 5.2 Secondary Components

```text
- CCPE-Agent: Article Context Architect
- CCPE-Runtime: Article Outline Development Runtime
- Candidate Workflow Skills: context-pack builder, review synthesis, repair request builder
```

### 5.3 Why This Classification?

```text
该阶段不是单个专家提示词，而是一个多角色、多人类决策门、文件化状态、上下文分发和评审综合流程。它需要 Agent Spec 和 Runtime，而不是 Lite。
```

## 6. Operating Mode

```text
Hybrid Mode
```

Explanation:

```text
提纲评审依赖深度判断、文学方向、论证结构和用户意图，不能全自动化。但上下文整理、评审分发、报告归档、修复请求生成等环节可以由 Agentic 工作流稳定执行。
```

## 7. Depth vs Automation Orientation

```text
Hybrid
```

Explanation:

```text
深度部分包括立意保护、提纲质量判断、评审意见取舍、最终进入下一阶段的决定。自动化部分包括文件路径约定、上下文分层、评审包裁剪、会话/报告归档和状态更新。
```

## 8. Cognitive Models Involved

### 8.1 Existing Models

```text
- model_id: cognitive-imaging
  model_name: 认知显影
  model_card_path: model-cards/intermediate/cognitive-imaging-model.md

- model_id: giant-cognition
  model_name: 巨人认知
  model_card_path: optional / not required for this v0 if not yet promoted

- model_id: zhang-liao-red-team
  model_name: 张辽式红队与建设性苏格拉底评审
  model_card_path: optional / not required for this v0
```

### 8.2 New or Candidate Models

```text
- provisional_model_name: Outline-Aligned Context Packing
  reason: 这是一种把原始材料按提纲点重排的上下文工程方法，可能稳定复用。
  should_create_model_card: no
```

### 8.3 Model Card Need

```text
optional
```

Explanation:

```text
v0 阶段不创建新 Model Card。先通过真实试跑确认 Outline-Aligned Context Packing 是否是稳定方法、Skill、Runtime 子程序，还是只是目录约定。
```

## 9. Skills Needed

### 9.1 Existing Skills

```text
- skill_id: ccpe-forge
  path: .codex/skills/ccpe-forge/SKILL.md
  purpose: 创建、分类和维护本批 CCPE 工件。
```

### 9.2 New Skills to Create

```text
- skill_name: context-pack-builder
  skill_type: workflow skill
  reason: 如果试跑证明提纲对齐上下文包构建步骤稳定，可抽为 Skill。

- skill_name: review-synthesis
  skill_type: evaluation / workflow skill
  reason: 如果多评审报告综合规则稳定，可抽为 Skill。

- skill_name: repair-request-builder
  skill_type: transformation skill
  reason: 如果从评审综合到主笔修复请求的转化规则稳定，可抽为 Skill。
```

### 9.3 Skill Need

```text
optional
```

Explanation:

```text
v0 不先创建 Skill，避免把未试跑的方法过早固化。先用 Agent + Runtime 明确流程，试跑后再抽稳定能力。
```

## 10. Runtime Need

```text
required
```

### 10.1 Runtime Type

```text
interactive-runtime
```

### 10.2 Runtime Explanation

```text
该流程包含多轮提纲修复、多评审员、上下文分发、状态记录、人工裁决和可恢复会话，必须由 Runtime 管理。它不是全自动流程，关键判断由用户确认。
```

## 11. Human Decision Gates

```text
Gate 1:
- Trigger: 用户准备启动一轮提纲评审。
- Decision: 指定本轮评审员、目标提纲版本、可用材料范围。
- Possible outcomes: 启动评审 / 补充材料 / 延后评审。

Gate 2:
- Trigger: Article Context Architect 完成提纲对齐上下文包。
- Decision: 用户确认上下文包是否足以分发给评审员。
- Possible outcomes: 分发评审 / 修改上下文包 / 添加或排除材料。

Gate 3:
- Trigger: 各评审员报告完成并生成 synthesis。
- Decision: 用户选择采纳、拒绝、保留或延后哪些评审意见。
- Possible outcomes: 生成 repair-request / 追加评审 / 确认提纲。

Gate 4:
- Trigger: 主笔修复提纲后。
- Decision: 用户决定是否进入下一轮评审或确认 outline-final。
- Possible outcomes: 下一轮 / 终稿确认 / 暂停项目。
```

## 12. Authority and Automation Boundary

### 12.1 Allowed Autonomous Actions

```text
- 根据 source-map 和用户指定材料生成 source digest 草案。
- 根据当前提纲生成 outline-aligned context pack 草案。
- 为不同评审员生成 dispatch pack 草案。
- 汇总 report.md 中的明确结论和冲突点。
- 生成 repair-request 草案。
- 更新本轮运行报告草案。
```

### 12.2 Actions Requiring Confirmation

```text
- 改变可用材料范围。
- 排除用户指定材料。
- 将某个评审意见标记为最终采纳或最终拒绝。
- 改写文章立意。
- 确认 outline-final。
- 修改 writing-workbench 项目模板或 canonical 目录结构。
```

### 12.3 Forbidden Actions

```text
- 自动覆盖原始材料。
- 自动删除会话记录或评审报告。
- 自动把评审员报告混写成一个不可追溯文本。
- 在没有用户确认时改变主笔风格或文章类型。
- 在 v0 试跑前创建过重的全流程文章生产 Runtime。
```

## 13. Input / Output Contract

### 13.1 Inputs

```text
- writing-workbench article project path
- project.md
- source-map.md
- status.md
- 观点素材文件路径或 source-map src mapping
- 用户发起语义：写文章，观点在哪儿，让韩愈看立意和切入
- 用户指定或确认的材料范围
- 韩愈立意确认结果
- 韩愈初稿提纲路径
- 用户指定的评审员列表
- 主笔与用户的立意 / 提纲生成会话记录或报告
```

### 13.2 Outputs

```text
- project-level context manifest
- source digest drafts
- premise-context-pack.md
- han-yu positioning invocation packet and prompt-to-send.md when needed
- han-yu positioning report.md
- positioning-final.md
- han-yu outline invocation packet and prompt-to-send.md when needed
- outline-v1.md
- outline-aligned context pack
- per-reviewer dispatch packs
- per-reviewer agent invocation packets
- prompt-to-send.md when any participant runs on an external platform
- article-context-architect invocation packet and prompt-to-send.md when needed
- han-yu repair invocation packet and prompt-to-send.md when needed
- review brief
- per-reviewer session.md and report.md
- synthesis.md
- repair-request.md
- updated status.md recommendation
```

### 13.3 Output Format Notes

```text
所有输出均以 Markdown 文件保存。Runtime 默认读取结构化 report.md，不默认读取完整 session.md，除非需要追溯争议或上下文断裂。
```

## 14. Evaluation Criteria

```text
- 能否避免大上下文一次性塞入模型。
- 能否区分 Runtime operator 的调度输出和 canonical agent 的正式输出。
- 能否在不能真实调用 agent 时停止并生成 prompt-to-send.md，而不是模拟结果。
- 能否在韩愈立意前先完成观点素材压缩拆分。
- 能否让韩愈基于 premise-context-pack 输出立意，而不是只基于用户一句话。
- 能否在用户确认立意后再生成提纲。
- 能否在补充素材进入时增量更新 source digest、premise pack、outline pack 或 dispatch pack。
- 能否按提纲点保留观点、论据、例子、引用、禁止展开内容。
- 能否明确区分读者可见材料与内部材料。
- 能否让评审员在足够上下文下评审，而不是只看孤立提纲。
- 能否保留每个评审员的独立会话与报告。
- 能否为所有被调用角色生成足以真正启动 canonical CCPE agent 的 invocation packet，而不是只生成给 orchestrator 看的任务索引。
- 当评审员在 Gemini/GPT/Claude 等外部平台运行时，能否生成可直接复制的 prompt-to-send.md。
- 能否把冲突意见综合为用户可决策的问题。
- 能否生成韩愈可执行的修复请求。
- 能否被 writing-workbench 试验项目实际运行。
```

## 15. Proposed Files

```text
- workbench/analysis/article-outline-development-runtime-creation-brief.md
  artifact_type: ccpe-creation-brief
  purpose: 明确提纲评审 Runtime v0 的场景、边界、分层和人类决策门。
  priority: high

- workbench/upgraded/article-context-architect.agent.md
  artifact_type: ccpe-agent
  purpose: 定义提纲对齐上下文包构建助手。
  priority: high

- workbench/upgraded/article-outline-development.runtime.md
  artifact_type: ccpe-runtime
  purpose: 定义从初稿提纲进入多评审、综合、修复请求、下一轮决策的交互式 Runtime。
  priority: high

- workbench/upgraded/agent-invocation-packet.protocol.md
  artifact_type: ccpe-runtime-subprotocol
  purpose: 定义 Writing Workbench 如何真实调用 canonical CCPE participant，避免模拟输出混入正式流程。
  priority: high
```

## 16. Open Questions

```text
1. writing-workbench 的 project template 是否要在 v0 试跑前先按本 Brief 调整，还是先在单个试验项目中临时落地？
2. source digest 的压缩深度是否需要区分“快速试跑版”和“正式深度创作版”？
3. 韩愈是否只要求输出稳定提纲编号，还是需要补一个轻量的 outline handoff 格式约定？
```

## 17. Acceptance Criteria

The creation is acceptable when:

```text
Classification is correct.
Artifact is not over-engineered.
Artifact is not under-specified.
Human decision gates are clear.
Output format is usable.
Target platform constraints are respected.
The workflow preserves the user's role as final director and editor.
The context design supports large-material workflows without requiring one huge prompt.
No formal output is accepted from a canonical agent unless a real invocation is recorded.
```

## 18. Recommended Next Action

```text
先用这批 CCPE 草案指导 writing-workbench 的单个真实 article project，不立刻改全局模板。流程从“观点素材文件”开始，先建立 context/、context/premise/、01-positioning/han-yu/，生成 premise-context-pack 和韩愈立意调用包；用户确认立意后，再生成 02-outline/main-writer-sessions/han-yu/outline-generation/ 与 outline-v1.md；然后进入 02-outline/review-rounds/round-01/，跑一轮提纲对齐上下文包和三评审分发。
```