# Demo 验收报告（第一轮）

验收时间：2026-07-17

## 总体结果

| # | Demo | 状态 | 可运行 | 文件数 |
|---|------|------|--------|--------|
| 1 | document-approval | ✅ 通过 | ✅ | 1 (index.js) |
| 2 | npc-dialog | ✅ 通过 | ✅ | 1 (main.js) |
| 3 | etl-pipeline | ✅ 通过 | ✅ | 1 (index.js) |
| 4 | canary-deploy | ✅ 通过 | ✅ | 4 (main.js + 3 module files) |
| 5 | saga-coordinator | ✅ 通过 | ✅ | 1 (main.js) |

全部 5 个 demo 均可正常运行。关键约束全部通过：
- ✅ 无 `switchStatus(null, ...)` — 0 处违规
- ✅ 无 `(peek, state)` 旧签名 — 0 处违规
- ✅ 所有 statusDispatcher 使用 `(peek, status) => status`
- ✅ 均通过 `{ effect: 'run' }` + runParent 收尾

---

## 典型问题（可改进点）

### 1. ETL Pipeline：每个阶段分 Push/Pop 两步，过度切分（中等）

**现象**：每个处理阶段被拆成了两个状态（如 `extract` 阶段 → push handler + pop handler），通过 `writeExtra` 标记 `_phase` 字段在 statusDispatcher 中区分。一个 5 阶段的管道变成了 16 步。

**分析**：这不是 API 误用，但在概念上不够自然。statusDispatcher 应该做路由，不应该承载"我是前半段还是后半段"的状态标记。更自然的做法是每个阶段一个 handler，内部一次调 `switchStatus` 带 push 或 pop 完成操作。

### 2. Document-Approval：init 中包含大量初始化数据（轻微）

**现象**：`init` 函数中初始化了大量模拟数据（文档编号、金额、审批人姓名等），增加了阅读负担。

**建议**：init 只做最小初始化（设 status + 初始栈数据），业务数据在 handler 中指代或用常量定义。

### 3. Canary-Deploy：`stagingStack.js` 内 statusDispatcher 引用了父栈定义格式（轻微）

**现象**：子栈定义的 statusDispatcher 正确使用了 `(peek, status) => status`，但子栈内部在注释中提到了父栈的 state 格式。实际运行时没问题。

### 4. Saga-Coordinator：statusDispatcher 使用了方法简写语法（无影响）

**现象**：`statusDispatcher(peek, status) { return status; }` — 使用对象方法简写而非箭头函数。JavaScript 语义等价，运行无差异，但与其他 demo 风格不统一。

### 5. NPC-Dialog：statusDispatcher 定义在对象外部然后引用（风格差异，无影响）

**现象**：将 `statusDispatcher` 定义为顶层函数 `function statusDispatcher(peek, status)`，然后在定义对象中 `statusDispatcher,` 引用。这是合法且清晰的写法，其他 demo 使用了箭头函数内联。

---

## 各 Demo 亮点

| Demo | 亮点 |
|------|------|
| document-approval | 完整展示退回归档（pop + writeResultData）+ runParent 通知，场景一和场景二对比 |
| npc-dialog | statusDispatcher 根据 `peek().questType` 分支到 3 条不同对话线，完美演示 peek 驱动路由 |
| etl-pipeline | 完整 5 阶段管道 + error 模拟 + 详细 JSON 日志 + resultData 累积 |
| canary-deploy | 模块链三层注入（deployLogger/statusTransitionLogger/extraLogger）+ 子栈 + 渐进放量 + 回滚路径；文件拆分清晰 |
| saga-coordinator | 5 个场景（全部成功 + 4 种失败补偿链深度）+ writeExtra 时间戳 + 通知子栈 |

---

## 验收结论

**第一轮全部通过。** 5 个 demo 均满足硬性约束，可正常运行，领域语义清晰，各自展示了不同的核心特性。无需强制修正；上述典型问题为改进建议，可在后续轮次中优化。