---
artifact_type: handoff
name: knowledge-vault-viewpoint-runtime-handoff
source_artifact: viewpoint-discussion-distillation-creation-brief
author: CCPE System
created: 2026-06-06
status: draft
target_workspace: C:\Users\wangq\Documents\Codex\knowledge-vault
review_status: needs-user-review
next_action: confirm knowledge-vault directory convention before running source processing
---

# Knowledge Vault Handoff: Viewpoint Discussion Distillation Runtime

## 1. Purpose

这份交接文件说明：`knowledge-vault` 将来如何接收并调用 CCPE System 定义的 `Viewpoint Discussion Distillation Runtime`，把大型观点讨论稿拆分为可长期使用的观点材料包。

该 handoff 不拆分当前素材，不修改 `knowledge-vault` 文件。它只定义跨项目边界、接收目录、调用输入、输出产物和人工确认点。

## 2. Cross-Project Responsibility

### 2.1 CCPE System Responsibility

```text
ccpe-system = actor / skill / runtime factory
```

本仓库负责定义：

```text
- Viewpoint Discussion Distillation Runtime
- Topic Discovery Router Agent
- Lossless Coverage Auditor Agent
- Conversation Segmentation Skill
- Evidence Routing and Topic Document Builder Skill
- Agent Invocation Packet Protocol
- 调用协议、输入输出契约、覆盖率审计规则
```

本仓库不负责：

```text
- 长期保存用户讨论稿正文
- 直接接管 knowledge-vault 的目录规范
- 自动创建 writing-workbench 项目
- 将观点材料直接写成文章
```

### 2.2 Knowledge Vault Responsibility

```text
knowledge-vault = archive / mining / viewpoint-development workspace
```

目标仓库负责：

```text
- 保存原始 diary / discussion 文件。
- 为每次观点讨论拆分建立工作目录。
- 调用 CCPE Runtime。
- 为每个 CCPE participant 保存 invocation packet、prompt-to-send 或 Skill execution record。
- 保存 source-map、topic-map、routing-log、topic docs 和 coverage audit。
- 维护观点材料是否进入写作的判断状态。
- 在需要时生成 writing-intake-packet 给 writing-workbench。
```

Knowledge 不应把这一步直接做成文章项目。该阶段仍属于“确定观点”，不是“确定创作”。

### 2.3 Writing Workbench Responsibility

```text
writing-workbench = article production stage
```

Writing 只在用户决定进入创作后接收：

```text
- handoff/writing-intake-packet.md
- 被选中的 topic docs
- 可引用的 source-map / topic-map
- 用户的创作意向说明
```

Writing 不应直接处理原始长讨论稿，也不应负责主题发现和无损拆分。

## 3. Recommended Knowledge Directory

建议在 `knowledge-vault` 中新增或采用如下目录：

```text
discussions/viewpoint-development/{yyyy-mm-dd}-{slug}/
  README.md
  00-source-map.md
  01-topic-map.md
  02-material-routing-log.md
  03-run-notes.md
  topics/
    {topic-slug}.md
  audits/
    coverage-audit.md
    distortion-risk-log.md
  model-mining/
    candidate-models.md
  handoff/
    writing-intake-packet.md
    ccpe-runtime-run-report.md
  invocations/
    topic-discovery-router/
      agent-invocation-packet.md
      prompt-to-send.md
    lossless-coverage-auditor/
      agent-invocation-packet.md
      prompt-to-send.md
    conversation-segmentation/
      agent-invocation-packet.md
      skill-execution-record.md
    evidence-routing-and-topic-doc-builder/
      agent-invocation-packet.md
      skill-execution-record.md
```

For the current known source, a possible working path is:

```text
discussions/viewpoint-development/2026-06-05-gpt-discussion/
```

This is only a proposed path. The user should confirm the final convention before any file creation in `knowledge-vault`.

## 4. Source Handling Rule

The source file remains in place:

```text
knowledge-vault/diary/2026/2026-06/2026-06-05.md
```

The Runtime may read it, but must not move, overwrite, delete, rename, or mark it disposable unless the user explicitly confirms after coverage audit.

Because `knowledge-vault` Markdown contains Chinese text, future runs should read text with explicit UTF-8 handling in PowerShell:

```powershell
Get-Content -LiteralPath '<path>' -Encoding UTF8
```

## 5. Runtime Invocation Contract

Knowledge side must use the CCPE participant invocation protocol:

```text
ccpe-system/runtimes/hybrid/agent-invocation-packet.protocol.md
```

No Runtime stage may accept a formal participant output unless it is backed by one of:

```text
- agent-invocation-packet.md plus returned real output
- prompt-to-send.md plus returned external output
- skill-execution-record.md for local Skill execution
```

`prompt_path_reference` means the executing participant can read local files. It does not mean the runtime main session may read an Agent spec and write the Agent's formal report itself.

A real local participant must be one of:

```text
- a separate Codex / Claude Code / OpenClaw participant session with the canonical artifact loaded
- a native registered agent with matching role and version
- a manual or external participant launched through prompt-to-send.md
```

For CCPE-Skill specs, local execution is allowed only when the run writes `skill-execution-record.md`.

### 5.1 Minimum Invocation Packet

When `knowledge-vault` calls the Runtime, it should provide:

```yaml
runtime_id: viewpoint-discussion-distillation
source_document_path: diary/2026/2026-06/2026-06-05.md
source_type: diary-discussion
round_boundary_rule: markdown-h1
estimated_rounds: 7
intended_use: viewpoint-development
output_workspace_path: discussions/viewpoint-development/2026-06-05-gpt-discussion
lossless_requirement: true
allow_topic_overlap: true
writing_handoff_required: optional
model_mining_required: optional
human_confirmation_required_before:
  - final_topic_map
  - source_disposable_claim
  - writing_workbench_handoff
  - downstream_task_routing
no_simulation_requirement: true
participant_invocation_protocol: ccpe-system/runtimes/hybrid/agent-invocation-packet.protocol.md
```

### 5.2 Optional Invocation Fields

```yaml
seed_topics:
  - optional user-provided topic names
forbidden_merges:
  - concepts that must not be collapsed together
known_followup_tasks:
  - tasks discovered by the user before runtime starts
target_writing_series:
  - optional known article series if user already has one in mind
external_research_paths:
  - optional Deep Research or multi-platform discussion files
```

### 5.3 Required Participant Invocation Records

Before treating any participant result as formal output, the Knowledge run must create or record:

```text
invocations/
  topic-discovery-router/
    agent-invocation-packet.md
    prompt-to-send.md                 # when external/manual execution is needed
  lossless-coverage-auditor/
    agent-invocation-packet.md
    prompt-to-send.md                 # when external/manual execution is needed
  conversation-segmentation/
    agent-invocation-packet.md
    skill-execution-record.md         # when executed locally
  evidence-routing-and-topic-doc-builder/
    agent-invocation-packet.md
    skill-execution-record.md         # when executed locally
```

If any required participant cannot be truly invoked or locally executed with a record, the run must stop with:

```text
blocked_waiting_for_participant_output
```

The main session may prepare packets and organize returned outputs. It must not write a formal Agent report or Skill result and label it as if the canonical participant produced it.

### 5.4 Source Content Requirement For Topic Discovery

`topic-discovery-router` must receive enough source content to classify topics.

It must not build `01-topic-map.md` from locator-only `00-source-map.md`.

Acceptable input patterns:

```text
Pattern A: Direct local source access
- A real participant can read source/source-map and the original source file.
- Use invocation_mode: prompt_path_reference.

Pattern B: Round-based worker participants
- Build source excerpt context packs for R01-R07.
- Each worker participant returns candidate topics and routing signals.
- A final router/synthesis pass merges the candidate topic graph.

Pattern C: External/manual participant
- Build prompt-to-send.md plus source excerpt context packs.
- User sends them to an external Agent and returns the output.
```

Recommended default for a 7-round / 50k-character discussion:

```text
Use Pattern B if local true participants are available.
Use Pattern C if no local true participant runner is available.
Do not use Pattern A unless the participant is actually separate from the runtime operator and can read the source files.
```

## 6. Processing Passes

### Pass 0: Source Registration

Create or update:

```text
00-source-map.md
03-run-notes.md
```

Record:

```text
- source path
- source type
- source date
- estimated length
- round boundary rule
- known H1 round headings
- source block id convention
```

### Pass 1: Segmentation

Use the future `conversation-segmentation` Skill to produce source block IDs:

```text
R01-B001
R01-B002
...
R07-B0xx
```

Segmentation should preserve:

```text
- round id
- original heading
- local paragraph position
- speaker or role if visible
- short locator text
- source excerpt boundary
```

### Pass 2: Candidate Topic Discovery

Use the future `topic-discovery-router` Agent to create:

```text
01-topic-map.md
```

Topic discovery should be incremental. It should not pretend that the first pass taxonomy is final.

Each topic should record:

```text
- topic id
- Chinese topic name
- optional English slug
- scope
- anti-scope
- related source blocks
- merge/split candidates
- confidence
```

### Pass 3: Evidence Routing

Use the future `evidence-routing-and-topic-doc-builder` Skill to create:

```text
02-material-routing-log.md
topics/{topic-slug}.md
```

Routing may be many-to-many. If one source block supports multiple themes, choose:

```text
- primary topic
- secondary linked topics
- reason for duplication or backlink
```

### Pass 4: Topic Document Construction

Each topic document should use this minimum structure:

```md
# {Topic Name}

## 1. Status

## 2. Scope

## 3. Source Material Layer

## 4. Structured Viewpoint Layer

## 5. Models / Mechanisms

## 6. Practices / Examples

## 7. Open Questions

## 8. Links To Other Topics

## 9. Source Index
```

The `Source Material Layer` is mandatory. It should carry the original discussion material or sufficiently complete excerpts, with source block IDs. The `Structured Viewpoint Layer` may refine and reorganize, but must not replace the source layer.

### Pass 5: Coverage and Distortion Audit

Use the future `lossless-coverage-auditor` Agent to create:

```text
audits/coverage-audit.md
audits/distortion-risk-log.md
```

Audit checks:

```text
- every source block has a routing status
- no source block silently dropped
- summary-only blocks are flagged
- low-confidence routing is visible
- source block duplication is justified
- rewritten claims can be traced to source material
- unresolved questions remain separate from confirmed facts
```

### Pass 6: Optional Downstream Task Handoff

Only if the user decides that the viewpoint should enter a downstream task, generate:

```text
handoff/downstream-task-routing.md
```

Only if the user decides that the viewpoint should enter writing, also generate:

```text
handoff/writing-intake-packet.md
```

This packet is only one downstream packet type. Other downstream packets may be needed for model updates, scale extraction, system building, engineering work, todo extraction, or continued research.

This writing packet should include:

```text
- candidate article direction
- selected topic docs
- source paths to cite
- key claims and tensions
- candidate model references
- unresolved questions that affect writing
- recommended main writer / skill if known
- notes on whether this belongs to an existing series
```

## 7. Human Decision Gates In Knowledge

```text
Gate 1: Confirm working directory
- Before creating the viewpoint-development workspace.

Gate 2: Confirm topic-map
- After initial topic discovery and before bulk topic document generation.

Gate 3: Confirm audit repair
- If coverage-audit finds unplaced blocks, distortion risk, or unclear topic routing.

Gate 4: Confirm downstream task routing
- Before creating or updating any writing-workbench project, CCPE artifact plan, engineering project, model update, scale extraction, todo list, or continued-research track.

Gate 5: Confirm participant invocation boundary
- Before accepting topic-map, segmentation, routing, topic-doc-builder, or audit output as formal participant output.
- If invocation cannot be completed, stop at prompt-to-send.md or skill-execution-record gap and wait.
```

## 8. What Belongs In This CCPE Project Now

The current `ccpe-system` batch has produced:

```text
- workbench/analysis/viewpoint-discussion-distillation-creation-brief.md
- workbench/analysis/knowledge-vault-viewpoint-runtime-handoff.md
- runtimes/hybrid/viewpoint-discussion-distillation.runtime.md
- runtimes/hybrid/agent-invocation-packet.protocol.md
- agents/agent-specs/topic-discovery-router.agent.md
- agents/agent-specs/lossless-coverage-auditor.agent.md
- skills/workflow/conversation-segmentation.skill.md
- skills/workflow/evidence-routing-and-topic-doc-builder.skill.md
```

## 9. What Belongs In Knowledge Later

After CCPE specs are approved, a future `knowledge-vault` session should:

```text
1. Read knowledge-vault README / VAULT / local handoff docs.
2. Confirm the target viewpoint-development directory.
3. Read the source file with UTF-8.
4. Create the working directory.
5. Run source registration and segmentation.
6. Generate source excerpt context packs for topic discovery.
7. Generate required participant invocation records.
8. Generate candidate topic-map.
9. Pause for user review.
10. Generate topic documents.
11. Run coverage audit.
12. Decide whether to generate downstream-task-routing.md and any specific packet such as writing-intake-packet.md.
```

## 10. What Belongs In Writing Later

Only after user confirmation:

```text
1. Create or update a writing-workbench project.
2. Reference the Knowledge viewpoint packet in source-map.md.
3. Use selected topic docs as viewpoint materials.
4. Ask the main writer / article workflow to produce positioning.
5. Continue into outline only after positioning is accepted.
```

## 10.1 What Belongs In Other Downstream Tracks Later

Only after user confirmation, the Knowledge packet may route selected material to:

```text
- CCPE System: model update, Model Card, Skill, Agent, Runtime, or Model Index work.
- Engineering workspace: system/project build plans, implementation tasks, architecture notes.
- Knowledge Vault itself: continued research, source enrichment, unresolved-question backlog, or durable reference docs.
- Personal task system: explicit todo extraction and follow-up actions.
- Evaluation workbench: scale/rubric extraction, checklist design, or testing protocol creation.
```

## 11. No-Repeat Rules

Future sessions should not:

```text
- Re-argue whether this belongs to writing-workbench first. It belongs to knowledge-vault until the user decides a specific downstream route.
- Treat the source diary file as disposable before coverage audit.
- Collapse the task into a summary prompt.
- Create a new inbox or redundant capture lane in knowledge-vault.
- Move confirmed facts into unresolved-question files.
- Simulate canonical CCPE Agent outputs if a real invocation boundary is required.
- Accept topic-map, audit, segmentation, or topic-doc-builder outputs as formal participant outputs without an invocation packet, returned external output, or Skill execution record.
```

## 12. Ready-To-Use Start Prompt For Knowledge

```text
请在 knowledge-vault 中接收 CCPE 的 Viewpoint Discussion Distillation Runtime 设计。

源文件：
diary/2026/2026-06/2026-06-05.md

目标：
把这份 7 回合、约 5 万字符的 GPT 观点讨论稿，按“无损观点拆分”方式整理为 viewpoint-development 工作目录。先建立 source-map、候选 topic-map 和 routing plan，不要直接生成全部主题文档，也不要移动或改写源文件。

请先读取 knowledge-vault 的 README / VAULT / 相关 handoff，再提出目标目录、source excerpt context pack 方案、participant invocation records 方案和第一批文件计划，等待确认。
```

## 13. Open Decisions

```text
1. 是否采用 discussions/viewpoint-development/{date}-{slug}/ 作为新目录。
2. 是否允许一个 source block 多主题归档。
3. topic docs 的原文承载层需要保留完整段落，还是允许高完整度摘录。
4. coverage-audit 通过后，原始 diary 是否仍保留为原始档案。
5. writing-intake-packet 的格式是否要与 writing-workbench 现有 source-map / project.md 对齐。
6. downstream-task-routing.md 是否需要为 CCPE、工程、量表、待办和继续研究提供统一 schema。
```

## 14. Current Status

```text
Status:
handoff draft and CCPE participant specs created in ccpe-system.

Next Action:
User confirms the Knowledge Vault target directory and invocation mode. Only after that should a knowledge-vault session run the source file processing.
```