你是一名资深前端原型工程师。你的任务是：在既有“/specs/prototypes/ 原型工程”基础上，聚焦生成/更新“申请（Apply）”链路的页面原型，使其可运行、可演示、可按角色差异操作。

输入信息包含：
- 角色与任务（/specs/background/roles.md）
- 功能清单（/specs/functions/*，尤其是 core.md，且每行说明以 `端=...；入口=...；` 开头）
- 数据模型（/specs/models/*.md）
- 场景与流程（/specs/background/scenarios.md、/specs/flows/*.puml）

范围（必须）：
1. 仅实现 “申请”相关模块与工作台（Dashboard）差异渲染：
   - 申请列表（含筛选/分段视图）
   - 新建申请（必须用 Drawer 承载）
   - 申请详情（状态、字段、操作日志、变更记录占位）
   - 申请侧的取消/撤回、变更/修改（必须真实生效：更新 mock + 刷新列表）
2. 不生成“审批/执行/报表/配置”模块的页面与菜单入口（除非 functions 明确标注属于本范围且 `端=Web`）。

工程与输出要求（必须）：
1. 若 `/specs/prototypes/` 已存在可运行工程：在其上增量修改；不要重建工程骨架；仅新增/修改本范围相关页面、路由、mock 与导航。
2. 若不存在：创建一个最小可运行工程（Vue 3 + Vite + TS + Ant Design Vue），并保证首页可打开、路由可跳转。
3. 页面与路由必须遵循功能清单的端分配：
   - 仅实现 `端=Web` 的申请页面；路由以 `入口=/...` 为准。

必须实现的关键体验（必须）：
1. 三段式布局：Header + 左侧 Menu + 主内容区（router-view）。
2. Header 必须提供“当前身份/角色切换”（Select），切换后不刷新页面且立即影响：
   - 菜单可见性/置灰
   - 申请列表默认视图与默认筛选（基于 session）
   - 详情页动作按钮可见/禁用
3. 工作台（Dashboard）不在本指令内描述，必须另行按 `prompts/vspec_verify/prototype_dashboard.md` 执行。
4. 必须补齐系统工具页（不进左侧菜单）：
   - `/tools/introduction`：产品介绍/使用指引（含主链路 Steps 概览与快速入口）
   - `/tools/config`：原型配置/模拟开关（scheme 读取展示、失败注入、session 展示/重置、mock 数据重置/造数）
   - `/tools/data-dict`：数据字典/字段预览
   - `/tools/qr-code`：二维码工具（生成 + 扫码模拟）
   - `/tools/video`：视频/演示材料页
   - `/profile`：个人中心（从 Header 用户菜单进入）
   - `/agreement/confirm`：协议确认（用于提交/关键动作前）

申请模块页面规则（必须）：
1. 申请列表页：
   - 必须通过 Tab/Segmented/筛选视图区分：草稿/待提交、待审批、已通过待执行（如适用）、已驳回、已取消/已终止等
   - 工具栏必须包含“新建”按钮：点击后打开“新建申请 Drawer”
   - 列表每行 Action 必须包含：查看详情、变更、取消（按状态/角色控制可用性）
2. 新建申请 Drawer：
   - 表单字段来自模型（可裁剪），能从 session 推断的字段不得让用户重复填写
   - 若表单包含 1:N 明细（模型字段出现 `items[]/details[]/lines[]/segments[]/participants[]` 等数组，或场景出现多段/多资源/多时间段/多参与人）：必须用“可动态增减”的方式输入（Add/Remove 行），可演示新增/删除/编辑，禁止用单个文本框/JSON 粘贴代替
   - 必须提供 1:N 快捷输入能力（至少命中 1 类即可）：
     - 常用信息一键带入：提供“常用申请信息”下拉/按钮（例如常用联系人、常用地址、常用费用科目、常用事由等），点击后自动填充对应字段与若干明细行（可用 mock）
     - 单次输入展开为多段：当场景/字段语义命中“往返/多段/多参与人/多时间段”等时，必须提供“展开/生成”能力，将一次输入展开成多条明细行（例如：行程选择“往返”后，自动生成去程+返程两段 segments，并允许分别编辑起止点与时间）
     - 明细行复用：提供“复制上一行/复制当前行”能力，支持对某一行进行快速复制并局部修改
     - 批量生成：提供“按规则批量生成”能力（例如输入起点、终点、日期范围后自动生成 N 段；或选择人员列表后一键生成多条参与人明细）
   - 提交后必须生成一条申请记录并进入“待审批”（或需求对应的下一状态），并从草稿视图移出
3. 申请详情页：
   - 必须展示：基础信息（Descriptions）、状态 Tag、操作区（按角色+状态渲染）
   - 必须展示：操作日志/最近活动（Timeline 或 Table，由 mock 的日志生成）
   - 若发生变更：必须展示变更记录占位（变更前后对比 mock 即可）
4. Steps（步骤条）必须可见：
   - 详情页必须有“流程进度”Steps，按状态映射高亮当前节点
   - 至少 1 个抽屉表单使用步骤式表单（向导），进度由表单状态驱动

协议确认联动（必须）：
1. “申请提交”必须要求协议已确认（至少 1 个协议，含名称/版本 mock）：
   - 未确认时：先跳转/打开 `/agreement/confirm` 完成确认，再允许提交
   - 已确认时：允许直接提交并写入操作日志

商品列表/详情（按需裁剪，命中则必须）：
1. 若功能清单/模型命中“商品/SKU/库存/价格”等关键词：必须补齐 `/products` 与 `/products/:id`，并在申请新建/详情中提供商品选择/关联占位入口（可选但推荐）。

取消/变更阶段区分（必须）：
1. 必须按“是否已审批通过/是否已进入执行”区分文案与处理逻辑，不能用同一套行为糊弄：
   - 申请后（未审批）取消：文案为“撤回/取消申请”，确认后直接取消（无需补充信息），状态更新为“已取消”
   - 审批后（已通过）取消：文案为“终止/作废”，确认后必须打开 Drawer 填写终止原因，状态更新为“已终止”，并写入日志
   - 变更：按阶段选择“修改/变更申请”文案；提交后必须进入“待审批”（生成变更记录并写入日志）

联动与自检（必须）：
1. 所有按钮必须真实改变 mock 数据（状态/关键字段/日志），并触发列表刷新与可见的 message/notification。
2. 若 functions 的申请相关条目缺失 `端=` 或 `入口=`：必须在首页“设置/说明”区域用可见文本提示错误，并采用最保守策略回退（默认 `端=Web` + 推断入口）。
3. 1:N 设计自检（必须，原型生成完成后执行并修正到通过为止）：
   - 先判定本申请是否存在 1:N：检查模型字段是否出现 `items[]/details[]/lines[]/segments[]/participants[]` 等数组；或场景语义是否出现“多段/多资源/多时间段/多参与人/往返”等。
   - 若判定为存在 1:N：新建申请 Drawer 中必须有对应的“动态增减”组件区（Add/Remove 行），且能演示新增 ≥2 行、删除任意行、编辑每行字段；禁止用单一文本框或 JSON 粘贴代替。
   - 必须存在且可用的 1:N 快捷操作（至少 1 个）：
     - “常用申请信息”一键带入能自动填充若干明细行，或
     - “往返/展开/生成”能将一次输入展开为多行（例如去程+返程），或
     - “复制上一行/复制当前行”能生成新行并可局部修改，或
     - “按规则批量生成”能一次生成 N 行。
   - 自检操作步骤（必须可在页面上完成，不依赖开发者工具）：
     - 打开申请列表 → 点击“新建”打开 Drawer
     - 使用上述快捷操作生成多行 → 再手动新增/删除 1 行 → 填写必填项 → 提交
     - 回到列表：能看到新记录；进入详情：能看到 1:N 明细的展示（至少能看见行数或行内容摘要），并且操作日志记录了“快捷生成/新增/删除/提交”等关键动作
   - 若判定为不包含 1:N：必须在“新建申请 Drawer”中用可见文本说明“本申请无 1:N 明细（基于模型/场景判断）”，并确保不出现无意义的明细增减区；但仍应保留“常用信息一键带入”用于提升录入效率（可只填充单条记录字段）。
