### §11 .md 输出结构 (固定章节)

按这个目录写, 顺序固定, 便于后续 dedup / 跨 case 比较。

workflow.json 是 `procedures: [P1, P2, ...]` 模型。**多工序时按 procedure 分节**; **单工序时省略 P 层级** (见末尾兼容说明)。

```
# Case N: <主题>

**Source / URL / 主题**

## 工序梗概 (人话)
### P1 · <工序名>
### P2 · <工序名>
## 引用的类型 (stdlib + 自定义)
### stdlib 类型 (直接引用)
### case-specific 类型 (type_registry)
## L1 外部函数库
## L2 抽象动作 + impl 关系
## L3 工序模板
### 模板 A：<名> (对应 P1)
### 模板 B：<名> (对应 P2)
## L4 工序实例
### P1 实例 — <名>
  - inputs (本次实际值)
  - bindings (本次工具选择, `sN.via = ...`)
  - extracted_values (本次中间产物 — prompt 原文回填)
  - trace (timing / cost / retry_log, 可空)
### P2 实例 — <名>
  - (同上四子块: inputs / bindings / extracted_values / trace)
## 这个 case 对 DSL 设计的关键启发
```

**分节规则** (多工序时):

- **共享层不拆** (`L1 外部函数库` / `L2 抽象动作`): 外部函数、抽象动作跨工序复用, 整 case 一份, 不按 procedure 切分。
- **按工序拆** (`工序梗概` / `L3 工序模板` / `L4 工序实例`): 每个 procedure 一个子节。**L3 模板与 L4 实例一一对应** (模板 A ↔ P1, 模板 B ↔ P2)。
- **L4 实例的四子块** (inputs / bindings / extracted_values / trace) 落在**各 procedure 子节内部**, 不要跨工序拍扁挤在一起 — 拍扁会丢掉"哪个值属于哪个工序", 破坏跨 case 比较。
- **引用的类型分两子节**: `stdlib 类型` (命中 §A.3 字典叶子的, 直接引用) + `case-specific 类型 (type_registry)` (走 `procedure.type_registry` 的 `extends` / `desc`)。

**单工序兼容**: 只有一个 procedure 时, 省略 `### P1` 这层 —— `## 工序梗概` / `## L3 工序模板` 直接写正文, `## L4 工序实例` 底下直接写 inputs / bindings / extracted_values / trace 四子块。

**extracted_values 是核心** — 把图里读到的 prompt 原文、工具配置、Shot 拆解、视频参数等**逐字回填**, 不要凭印象写。图里截断不全就标 `note: "图中文本截断, ..."`, 不要自补。