railwaysystem/docs/current/06-DEMO-BASELINE.md

# 06 - 演示基线准则与重构要求 (Demo Baseline)

> **最高声明**：
> 1. **旧 Demo 当前不可信 (Old Demo Untrustworthy)**：历史 `docs/reports/**` 中记载的旧版端到端演示报告包含多处数据污染、历史断言遗留等问题，**其演示结果与截图绝对不得作为当前系统交付的可信证据**。
> 2. **新版 Demo 尚未开始 (New Demo Not Yet Started)**：当前系统状态标记为 `NEW_DEMO_STATUS = NOT_YET_STARTED`。
> 3. **严禁带病演示**：在纯净独立数据库重建与确定性种子数据灌入前，严禁任何人员或 Agent 启动演示脚本。

---

## 1. 下一版 Demo 七大重构铁律 (Next Edition Demo Principles)

为确保下一次业务演示达到面向铁路客户交付的黄金工业级标准，演示重构必须严格贯彻以下七大铁律：

```text
+--------------------------------------------------------------------------------------------------+
|                              NEXT-GENERATION DEMO 7 GOLDEN PRINCIPLES                             |
+--------------------------------------------------------------------------------------------------+
| 1. Fresh Clean Demo Database          | 绝对不在历史污染库上演示，必须基于全新干净独立数据库重建 |
| 2. Deterministic Seed Data            | 采用零孤儿、时间线严丝合缝、可完全确定性复现的种子数据包 |
| 3. Every demo UI contains meaningful  | 每一个受测界面必须呈现生动真实的业务数据，严禁空表与占位符 |
| 4. Real client API used whenever live | 外部接口真实可用的必须真实调用（如 DMS 只读），绝不弄虚作假 |
| 5. Mock clearly identified            | 任何模拟桩必须在界面文案与接口日志中显式标明为 [MOCK_SIMULATION] |
| 6. Gemini MCP performs real UI steps  | 由 MCP 自动化工具驱动真实无头 Chrome 浏览器执行真实用户交互 |
| 7. Every step has evidence screenshot | 每一个有业务意义的操作步骤均留存全屏证据截图与 SHA-256 账本哈希 |
+--------------------------------------------------------------------------------------------------+
```

---

## 2. 详细执行准则剖析

### 2.1 铁律 1：纯净独立演示库 (`Fresh Clean Demo Database`)
- 在 Kingbase 实例中新建独立演示数据库 `training_demo_clean`；
- 严禁包含历史测试遗留的杂乱临时表与脏记录；
- 数据库结构 100% 由 `000` 到 `010` 及 `001` 到 `015` 官方迁移脚本构建。

### 2.2 铁律 2：确定性业务种子 (`Deterministic Seed Data`)
- 种子数据必须满足“微型但全生命周期闭环”：
  - 5 名授课教师（覆盖房建、公寓、暖通、电气专业，全量绑定用户账号）；
  - 30 名参训学员（分为 2 个班级，身份证密文合规，全量绑定用户账号）；
  - 6 门标准培训课程（3 门理论、3 门实作）；
  - 4 间标准教室、2 处实训场地；
  - 8 间标准宿舍房间（严格区分男女宿舍，床位编号清晰）；
  - 2 期标准培训班（1 期已结训用于展示全流程成果与报表，1 期进行中用于现场动态交互演示）。

### 2.3 铁律 3：界面数据丰富饱满 (`Every demo UI contains meaningful data`)
- 严禁出现“点击进入排课，表格一片空白”、“点击成绩，暂无数据”等半成品现象；
- 统计分析驾驶舱必须预置足够跨度（至少连续 14 天）的打卡流水，使得趋势折线图、状态分布饼图与 Top 10 排行榜丰满生动；
- 学员成长画像必须具备饱满的课时雷达与打卡足迹。

### 2.4 铁律 4 与 5：真伪分离透明原则 (`Real vs Mock Transparency`)
- **真实调用**：DMS 只读连通接口（Token 鉴权、空间列表）调用真实外部网络，证明系统具备外部集成能力；
- **显式 Mock**：在外部无真实通电门锁的情况下，门禁密码下发与电子班牌通信在前端提示与响应报文中均加上 `[SIMULATION / MOCK]` 标识，坦诚沟通，绝不忽悠客户。

### 2.5 铁律 6 与 7：全过程证据链不可篡改 (`MCP Real Steps & Evidence Capture`)
- 演示过程必须使用真实角色账号（`qa_train_admin`、`qa_teacher_a`、`qa_student_a`）在真实浏览器中点击、输入、提交；
  - 业务管理员 `qa_train_admin` 执行排课、学员报到核验、宿舍入住、调房与退宿办理；
  - 授课教师 `qa_teacher_a` 查看个人课表并代签；
  - 参训学员 `qa_student_a` 查询个人课表、考勤与宿舍安排；
- 每一个关键交互产出一张带时间戳与 URL 的 PNG 截图，并计算 SHA-256 登记入 `evidence-ledger.csv`。