docs: add cell storage protocol modules design for 2.2.6–2.2.10

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-13 17:48:22 +08:00
1 parent 058811ae77
commit 246ad2228e
@@ -0,0 +1,42 @@
+## ADDED Requirements
+
+### Requirement: 租户隔离
+
+所有面向业务数据的查询接口 SHALL 仅返回 `tenant_no` 等于当前登录用户租户编号的数据；所有写入或更新类接口 SHALL 将目标业务行的 `tenant_no` 设置为当前登录用户的 `tenant_no`（与《中科兴皖需求 V0.3》§3 一致）。
+
+#### Scenario: 列表查询
+
+- **WHEN** 调用任意业务数据列表或详情接口
+- **THEN** 后端 SHALL 在查询条件中强制包含当前用户的 `tenant_no`
+
+#### Scenario: 新建业务主表
+
+- **WHEN** 创建新的业务主表记录
+- **THEN** 持久化的 `tenant_no` SHALL 等于当前登录用户租户，且不得信任客户端单独提交的租户覆盖服务端策略（除非经安全评审的多租户管理接口）
+
+### Requirement: 数据权限过滤
+
+除超级管理员等需求明确豁免的场景外，所有业务查询接口 SHALL 叠加当前登录用户**全部角色**合并后的数据权限范围进行过滤（与需求 §2.1.5「多角色取权限之和」一致）。
+
+#### Scenario: 用户绑定多角色
+
+- **WHEN** 用户拥有角色 A 与角色 B
+- **THEN** 可访问数据范围 SHALL 为两角色数据权限的并集（菜单与数据权限均适用并集语义）
+
+### Requirement: 列表默认排序
+
+在无单独产品排序要求的前提下，列表类接口返回的数据集合 SHALL 按 `order_num` 升序、`create_time` 降序排列（与需求 §3 一致）。
+
+#### Scenario: 默认分页列表
+
+- **WHEN** 接口未声明自定义排序参数且业务无例外说明
+- **THEN** 默认排序 SHALL 为 `order_num ASC, create_time DESC`
+
+### Requirement: API 前缀与工程约定
+
+对外 HTTP API SHALL 使用统一前缀（当前仓库为 `/api` 及版本/子路径，见 `AGENTS.md`）；新增路由 SHALL 注册到既有路由聚合机制，避免绕过中间件（鉴权、加解密、审计等）。
+
+#### Scenario: 新增 admin 路由
+
+- **WHEN** 在 `app/api/` 增加新的路由模块
+- **THEN** 该模块 SHALL 在 `app/api/__init__.py` 与 `app/main.py` 中完成注册，并符合现有认证与租户上下文注入模式
@@ -0,0 +1,37 @@
+## ADDED Requirements
+
+### Requirement: 仓库采用前后端分离的一体化门户形态
+
+中科兴皖一体化门户 SHALL 以「Python 后端 + Web 管理端 + 小程序端」的形态组织代码与部署单元；业务域（细胞存储、中试、系统管理等）共享同一后端与租户模型，除非需求文档明确声明独立子系统。
+
+#### Scenario: 新人识别工程边界
+
+- **WHEN** 阅读仓库根目录说明或 OpenSpec `architecture-conventions`
+- **THEN** 文档 SHALL 指明后端入口、管理端入口、小程序工程目录及 API 前缀约定（与 `AGENTS.md` 一致）
+
+### Requirement: 技术栈与需求文档 §3 对齐
+
+系统 SHALL 使用 MySQL 5.7 作为关系型数据库；后端 SHALL 使用 Python 实现；Web 管理端 SHALL 基于 Vue 技术栈在精简后的管理端模板工程上扩展；小程序 SHALL 基于 uni-app、Vue 3 与 Vant 体系实现业务界面（与《中科兴皖需求 V0.3》§3 及当前 `miniprogram` 工程一致或可文档化迁移）。
+
+#### Scenario: 技术选型评审
+
+- **WHEN** 新增服务或子工程选型
+- **THEN** 选型说明 SHALL 论证与上述栈的兼容性，或作为独立变更更新本 spec 与 `proposal.md`
+
+### Requirement: 附件与对象存储
+
+业务附件 SHALL 通过对象存储（如 MinIO）保存可访问 URL；多附件在同一字段内存储时 SHALL 使用英文逗号分隔多个 URL（与需求 §3 一致）。
+
+#### Scenario: 上传列表回显
+
+- **WHEN** 业务实体包含多个附件
+- **THEN** 持久化字段 SHALL 为逗号分隔的 URL 字符串，且接口契约与前端解析逻辑一致
+
+### Requirement: 权威文档索引
+
+实现类变更 SHALL 将 `docs/中科兴皖需求V0.3.md`、`docs/web-admin-ui-spec-fresh-mint.md`、`docs/miniprogram-ui-spec-sanqiang.md` 及 `AGENTS.md` 视为架构与规范的索引入口；OpenSpec 变更 SHALL 在 `proposal.md` / `design.md` 中保持对上述路径的引用。
+
+#### Scenario: UI 相关 PR 描述
+
+- **WHEN** 提交涉及 Web 或小程序界面的 PR
+- **THEN** PR 或关联 OpenSpec SHALL 声明遵循的 UI 规范文档路径
@@ -0,0 +1,46 @@
+## ADDED Requirements
+
+### Requirement: 最小必要改动
+
+同一功能或缺陷修复的代码变更 SHALL 仅包含完成任务所必需的修改；不得在同一提交中进行无关重构、大范围格式化或与需求无关的文件挪动。
+
+#### Scenario: 修复单接口校验
+
+- **WHEN** 修复某一接口字段校验
+- **THEN** diff SHALL 主要限于该接口、对应 schema 与必要测试，而不包含同模块无关重命名
+
+### Requirement: Web 管理端工程约定
+
+`web-admin` SHALL 遵循 `AGENTS.md` 中的栈与工具约定：包管理使用 pnpm；格式化以 Prettier（单引号、无分号、2 空格等）为准；ESLint/Stylelint 规则与仓库配置一致；Vue 与 Element Plus 依赖自动导入策略时，新增全局组件 SHALL 遵循既有 `unplugin` 配置而非随意手写重复导入（除非文件类型要求）。
+
+#### Scenario: 提交前检查
+
+- **WHEN** 提交 `web-admin` 源码
+- **THEN** 贡献者 SHALL 在本地或通过 CI 运行与仓库一致的 lint/format 门禁
+
+### Requirement: 后端工程约定
+
+`backend` SHALL 使用 Python 3.9 与既有 FastAPI、SQLAlchemy、Pydantic v2 模式；新增领域逻辑 SHALL 优先落在 `app/services/` 与 `app/crud/`，路由层保持薄；配置 SHALL 通过 `pydantic-settings` 与 `.env` 系列文件管理。
+
+#### Scenario: 新增业务接口
+
+- **WHEN** 新增一组管理端 API
+- **THEN** 路由 SHALL 放入 `app/api/` 合适模块，schema 放入 `app/schemas/`，数据库访问放入 `app/crud/` 或复用基类
+
+### Requirement: 数据库脚本与迁移
+
+涉及表结构变更时，维护者 SHALL 在 `docs/sql/` 中维护或更新与需求一致的 SQL 说明，并评估 Alembic/脚本与运行环境的同步（与 `AGENTS.md` 数据库变更约定一致）。
+
+#### Scenario: 新增业务表
+
+- **WHEN** 增加新表或字段
+- **THEN** 仓库 SHALL 包含可复现的 schema 片段或迁移，且与 OpenSpec `database-conventions` 中的公共字段规则一致
+
+### Requirement: 提交说明可读性
+
+提交信息 SHALL 使用完整句子说明「改了什么、为何」，并符合仓库 Conventional Commits / commitlint 类型约束。
+
+#### Scenario: merge request
+
+- **WHEN** 创建合并请求
+- **THEN** 描述 SHALL 使评审者无需阅读聊天历史即可理解动机与风险
@@ -0,0 +1,46 @@
+## ADDED Requirements
+
+### Requirement: MySQL 版本
+
+生产与标准开发环境的关系型数据库 SHALL 使用 MySQL 5.7（与《中科兴皖需求 V0.3》§3 一致）。
+
+#### Scenario: 新环境搭建文档
+
+- **WHEN** 编写或更新部署文档
+- **THEN** 文档 SHALL 声明 MySQL 5.7 及字符集/排序规则（如 utf8mb4）基线
+
+### Requirement: 公共字段集合
+
+除需求或 OpenSpec 明确豁免的关联/日志表外，业务表 SHALL 包含以下公共字段且语义一致：`id`（VARCHAR(64)，UUID）、`tenant_no`、`order_num`、`remark`、`create_by`、`create_dept_id`、`create_time`、`update_by`、`update_time`、`del_flag`（与需求 §3 列表一致）。
+
+#### Scenario: 新建业务表 DDL
+
+- **WHEN** 创建新表
+- **THEN** 表定义 SHALL 包含上述公共字段，且 `del_flag` 默认 `0` 表示未删除
+
+### Requirement: 字段顺序
+
+表模型定义与 DDL 中，业务字段 SHALL 位于 `id` 之后；`tenant_no`、`order_num`、`remark`、`create_by`、`create_dept_id`、`create_time`、`update_by`、`update_time`、`del_flag` SHALL 位于业务字段之后（与需求 §3 一致）。
+
+#### Scenario: Code review DDL
+
+- **WHEN** 审查新建表 SQLAlchemy 模型或 raw SQL
+- **THEN** 字段顺序 SHALL 符合本 requirement，除非评审记录中注明例外原因
+
+### Requirement: 逻辑删除
+
+应用层 SHALL NOT 对业务数据执行物理删除；删除操作 SHALL 通过将 `del_flag` 置为 `1` 实现；查询默认 SHALL 排除已删除行。
+
+#### Scenario: 删除用户可见记录
+
+- **WHEN** 用户点击删除某条业务数据
+- **THEN** 服务端 SHALL 更新 `del_flag` 而非 `DELETE FROM`，且列表接口默认不返回 `del_flag=1`
+
+### Requirement: 主键类型
+
+主键 `id` SHALL 为 `VARCHAR(64) NOT NULL`，取值策略为 UUID（与需求 §3）。
+
+#### Scenario: 插入新行
+
+- **WHEN** 应用创建新实体
+- **THEN** 写入的 `id` SHALL 为符合长度与格式的 UUID 字符串
@@ -0,0 +1,51 @@
+## ADDED Requirements
+
+### Requirement: 角色与菜单授权
+
+系统 SHALL 通过 `sys_role`、`sys_role_menu` 等模型维护角色与菜单的关联；角色管理界面 SHALL 支持为角色配置可访问菜单树，且勾选子菜单时 SHALL 自动包含必要父菜单（与《中科兴皖需求 V0.3》§2.1.5 描述一致）。
+
+#### Scenario: 勾选子菜单
+
+- **WHEN** 管理员在角色菜单配置弹窗中仅勾选叶子菜单
+- **THEN** 保存后角色 SHALL 同时获得该叶子到根路径上的父菜单权限，避免出现「有子无父」的不可达状态
+
+### Requirement: 数据权限范围
+
+角色 SHALL 具有 `data_scope` 字段，取值语义为：全部、本部门、本部门及以下、仅本人、自定义等（与需求 §2.1.5 及表注释一致）；当为自定义时，系统 SHALL 使用 `sys_role_data_scope_detail` 维护 `scope_type`（部门/用户）与 `scope_value`。
+
+#### Scenario: 配置自定义数据权限
+
+- **WHEN** 管理员将角色数据权限设为自定义并在弹窗中选择部门与用户
+- **THEN** 持久化 SHALL 写入 `sys_role_data_scope_detail`，且运行时查询 SHALL 按明细过滤
+
+### Requirement: 多角色权限合并
+
+单个用户允许绑定多个角色；其**菜单权限**与**数据权限** SHALL 分别取所有的角色的权限**并集**（与需求 §2.1.5「特别注意」一致）。
+
+#### Scenario: 两角色菜单合并
+
+- **WHEN** 用户同时具有角色 R1（菜单集合 M1）与角色 R2（菜单集合 M2）
+- **THEN** 用户可见菜单 SHALL 为 M1 ∪ M2
+
+#### Scenario: 两角色数据范围合并
+
+- **WHEN** 用户同时具有角色 R1 与 R2，各自数据权限范围不同
+- **THEN** 可访问数据 SHALL 为两角色数据权限的并集（在实现上与产品确认：取更宽或按需求文档并集语义）
+
+### Requirement: Web 与小程序菜单树
+
+菜单管理 SHALL 同时支撑 Web 端与小程序端菜单；系统 SHALL 预置两棵顶层虚拟根（需求中的 parent_id=0 的「web 端菜单」「移动端菜单」），后续菜单 SHALL 挂载其下（与需求 §2.1.6）。
+
+#### Scenario: 新增移动端菜单
+
+- **WHEN** 管理员新增小程序端一级菜单
+- **THEN** 该节点 SHALL 挂在移动端根节点之下，且 `visible`/`status` 字段符合规范枚举
+
+### Requirement: 超级管理员与租户
+
+租户管理 SHALL 仅对超级系统管理员开放（与需求 §2.1.1）；其他系统管理 SHALL 在租户上下文中执行，与 `api-conventions` 中租户隔离一致。
+
+#### Scenario: 非 superadmin 访问租户管理
+
+- **WHEN** 非超级管理员请求租户管理接口或页面
+- **THEN** 系统 SHALL 拒绝访问
@@ -0,0 +1,117 @@
+## ADDED Requirements
+
+### Requirement: Web 管理端以 Fresh Mint 规范为唯一视觉权威
+
+`web-admin` 工程的界面实现 SHALL 以 `docs/web-admin-ui-spec-fresh-mint.md` 及其中引用的 `docs/fresh-mint-green.html` 为权威来源；主色链 SHALL 使用文档定义的 Mint 绿系（如 `--primary` `#10b981` 等），不得擅自替换为小程序品牌色。
+
+#### Scenario: 新增列表页
+
+- **WHEN** 在 `web-admin` 新增标准列表/表单页
+- **THEN** 页面结构 SHALL 对齐规范中的布局顺序（筛选 → 工具栏 → 列表 → 分页等）及模板页（如 `#/demo/unit`、`#/demo/order`）所体现的模式
+
+### Requirement: 小程序以三墙 Demo 体系为唯一视觉权威
+
+`miniprogram` 工程的界面 SHALL 以 `docs/miniprogram-ui-spec-sanqiang.md` 及其中列出的 `mobile-ui/sanqiang-*.html` 为权威来源；品牌绿、大麦黄与中性色 SHALL 采用规范 §2 Token，不得直接复用 Web 端 Fresh Mint 色板作为主色。
+
+#### Scenario: 新增小程序页面
+
+- **WHEN** 新增客户端/供应商/配送端页面
+- **THEN** 页面 SHALL 遵循规范中的统一骨架（Header 渐变、卡片圆角节奏、底部固定区等）及状态标签语义色
+
+### Requirement: 禁止跨端调色板混用
+
+除非产品书面要求，Web 管理端 SHALL NOT 使用小程序规范中的 `#0a9f6d` 等作为主色；小程序 SHALL NOT 使用 `#10b981` 作为主色替代品牌绿。
+
+#### Scenario: Code review
+
+- **WHEN** PR 修改全局主题或主按钮色
+- **THEN** 审查者 SHALL 对照对应端 UI 规范文档中的 Token 表拒绝跨端拷贝色值
+
+### Requirement: 树形主数据展示规则
+
+涉及树形主数据（分类、库位、组织等）时，Web 端 SHALL 遵循：下拉/树节点展示**本级名称**，选中后在输入框、表格、导出与查看弹窗中展示**全路径**；路径分隔符 SHALL 与工程约定一致（当前为 ` / `，见 `web-admin/src/utils/tree-path.ts` 与规范 §5.6）。
+
+#### Scenario: 树选择与表格列
+
+- **WHEN** 用户在树形选择器中选择末级节点
+- **THEN** 表格与只读视图 SHALL 展示完整祖先路径而非仅末级名称
+
+### Requirement: 弹窗与遮罩
+
+Web 管理端弹窗 SHALL 遵循规范：表单 `label-position="top"`；遮罩 SHALL NOT 使用背景模糊（`backdrop-filter: none` 等与仓库既有策略一致）。
+
+#### Scenario: 新增编辑弹窗
+
+- **WHEN** 使用 Element Plus `el-dialog` 承载表单
+- **THEN** 表单标签位置与遮罩样式 SHALL 符合 `docs/web-admin-ui-spec-fresh-mint.md` 中 `el-dialog` 小节
+
+### Requirement: 小程序媒体与触控
+
+小程序列表缩略图、轮播与详情图 SHALL 遵循 `docs/miniprogram-ui-spec-sanqiang.md` §7.0 的宽高比与 `mode` 约定；可点击控件 SHALL 满足最小触控区域（规范中的 44×44 等要求）。
+
+#### Scenario: 商品列表缩略图
+
+- **WHEN** 展示商品列表缩略图
+- **THEN** 图片区域 SHALL 为 1:1 且使用 `aspectFill`（与规范 §7.0.1 一致）
+
+### Requirement: 列表面板主标题装饰
+
+`web-admin` 中列表面板 `panel-top` 下的主标题（`h2.title-bar-heading`）SHALL 在标题文案前展示 **主色竖条**（与全局 `app.scss` 中 `h2.title-bar-heading::before` 一致）；含「租户」「用户」等易歧义文案的标题 SHALL 通过 `App.vue` 中 `panelTitleBarTextRules` 显式纳入竖条样式，避免子串误匹配为其它图标。
+
+#### Scenario: 租户列表标题
+
+- **WHEN** 打开 `#/system/tenant` 租户管理页
+- **THEN** 「租户列表」标题 SHALL 显示绿色竖条装饰，且 SHALL NOT 因「租户」含「用户」子串而显示用户类图标
+
+### Requirement: 新增与编辑弹窗布局与视口留白
+
+使用 Element Plus `el-dialog` 承载新增/编辑表单时，系统 SHALL 满足：
+
+1. **水平栅格**：默认使用 **两列** 栅格（`.form-grid-2`，`grid-template-columns: repeat(2, minmax(0, 1fr))`，`gap: 12px 20px`）；字段较多时 SHALL 通过加宽 `width` 并选用 `.form-grid-3`、`.form-grid-4` 或 `.form-grid-5` 扩展列数，**列数上限为 5**；跨整行长字段 SHALL 使用 `.form-col-span-2`（`grid-column: 1 / -1`）。
+2. **窄屏回退**：视口或表单区过窄时，栅格 SHALL 回退为更少列或单列（与全局 `app.scss` 中 `@media (max-width: 900px)`、`(max-width: 560px)` 规则一致）。
+3. **定位**：弹窗 SHALL 相对视口水平与垂直居中（依赖 `ElConfigProvider` 的 `dialog.alignCenter` 及 Element Plus 默认遮罩层居中行为）。
+4. **高度与滚动**：使用 `.dialog-form-layout` 类名的弹窗壳层 SHALL `max-height: calc(100vh - 100px)`，保证相对视口上下各 **至少约 50px** 可视留白；弹窗 SHALL NOT 以固定高度占满视口；当内容超出时 **仅** `.el-dialog__body` 区域出现纵向滚动条，页头与底栏固定不滚动。
+
+#### Scenario: 租户新增弹窗
+
+- **WHEN** 在租户管理页打开新增或编辑租户弹窗
+- **THEN** 表单 SHALL 以两列栅格展示常规字段、备注跨两列；弹窗 SHALL 带 `dialog-form-layout` 且正文区在内容过多时可滚动
+
+#### Scenario: 高字段数弹窗
+
+- **WHEN** 某业务弹窗字段超过两列舒适排布
+- **THEN** 实现 SHALL 增加 `el-dialog` 的 `width` 并选用 `form-grid-3` 至 `form-grid-5` 之一，且 SHALL NOT 使用超过 5 列的栅格类
+
+### Requirement: 图标组件使用 Element Plus 图标
+
+`web-admin` 中的图标 SHALL 优先使用 Element Plus 内置图标（`@element-plus/icons-vue`），通过 `ArtSvgIcon` 组件的 EP 图标映射（`src/utils/ui/ep-icon-map.ts`）渲染；SHALL NOT 在新增代码中直接使用 Iconify 远程图标名（如 `ri:xxx`、`fluent:xxx`）。仅在 Element Plus 无等价图标时，方可保留 Iconify 图标名作为例外。
+
+#### Scenario: 新增菜单路由
+
+- **WHEN** 在 `src/router/modules/` 中新增路由并设置 `meta.icon`
+- **THEN** `icon` 值 SHALL 使用 `ep-icon-map.ts` 中已注册的名称（如 `setting`、`grid`），SHALL NOT 使用 `ri:` 前缀的 Iconify 名
+
+#### Scenario: 新增界面图标
+
+- **WHEN** 在页面或组件中新增图标
+- **THEN** SHALL 使用 `<ArtSvgIcon icon="ep-icon-name" />` 或 `<el-icon><XxxIcon /></el-icon>`，SHALL NOT 使用 `<ArtSvgIcon icon="ri:xxx" />` 除非 Element Plus 无等价图标
+
+#### Scenario: 新增 Element Plus 图标
+
+- **WHEN** Element Plus 提供了新的所需图标但 `ep-icon-map.ts` 尚未注册
+- **THEN** 开发者 SHALL 先在 `ep-icon-map.ts` 中注册映射条目，再在业务代码中使用
+
+### Requirement: 表格操作列固定在右侧
+
+`web-admin` 中所有业务列表页（系统管理、业务模块等，不含 Demo 参考页）的 `el-table` 操作列 SHALL 使用 `fixed="right"` 固定在表格右侧。宽度规则：2 个按钮时 `width="260"`，3 个按钮时 `width="320"`，4 个及以上按钮时 `width="400"`。全局 CSS 通过 `.el-table-fixed-column--right` 选择器（注意：Element Plus 使用单短横线，非双下划线）提供固定列样式。
+
+#### Scenario: 新增系统管理列表页
+
+- **WHEN** 在系统管理模块下新增列表页面（如用户管理、角色管理等）
+- **THEN** 表格操作列 SHALL 设置 `fixed="right"`，宽度按按钮数设置：≤ 2 按钮用 `width="260"`，3 按钮用 `width="320"`，≥ 4 按钮用 `width="400"`
+
+#### Scenario: Code review 表格列
+
+- **WHEN** PR 包含新增或修改的 `el-table-column` 且 `label="操作"`
+- **THEN** 审查者 SHALL 确认该列包含 `fixed="right"` 属性，且宽度与按钮数量匹配（2 按钮 260px，3+ 按钮 320px）
+
@@ -0,0 +1,55 @@
+## ADDED Requirements
+
+### Requirement: 工作流由后端 Python 实现
+
+中科兴皖一体化门户的工作流引擎 SHALL 使用 Python 在后端实现为**独立、可配置**的审批/流程子系统，目标能力对标简易低代码流程（与《中科兴皖需求 V0.3》§2.1.11 一致）。
+
+#### Scenario: 技术栈检查
+
+- **WHEN** 引入流程执行、待办存储或节点调度代码
+- **THEN** 实现 SHALL 位于后端 Python 工程内，而非由前端独占承担流程状态机
+
+### Requirement: 图形化流程配置
+
+系统 SHALL 支持以图形化方式配置流程，包含节点与连线；节点类型 SHALL 至少覆盖：开始、结束、审批人、条件分支（支持多分支）等（与需求 §2.1.11 列举一致，允许实现阶段扩展更多类型但不得破坏已发布定义）。
+
+#### Scenario: 配置新流程
+
+- **WHEN** 管理员在「流程配置管理」中保存一条流程
+- **THEN** 持久化模型 SHALL 能还原节点、连线及版本信息以供运行时解释执行
+
+### Requirement: 流程变量
+
+引擎 SHALL 支持系统内置流程变量（如申请人部门 id）与发起时注入的动态变量；条件分支 SHALL 能读取这些变量进行判断（与需求 §2.1.11）。
+
+#### Scenario: 金额分支
+
+- **WHEN** 流程变量包含金额字段且条件配置为多个区间
+- **THEN** 运行时 SHALL 根据变量值选择对应分支出线
+
+### Requirement: 审批人解析策略
+
+审批人节点 SHALL 支持：指定单个/多个用户、指定单个/多个角色、以及基于 SQL 结合流程变量解析审批人集合；同一节点 SHALL 支持配置「一人通过即通过」或「全部通过才通过」（与需求 §2.1.11）。
+
+#### Scenario: SQL 模式解析主管
+
+- **WHEN** 节点配置为 SQL 模式且流程变量包含申请人部门 id
+- **THEN** 引擎 SHALL 在受控数据源上执行预定义查询逻辑并解析出审批人列表（具体 SQL 安全策略由专项设计补充）
+
+### Requirement: 流程版本
+
+每条流程定义 SHALL 具备版本号；由旧版本发起的实例 SHALL 继续按发起时所绑定版本执行；新版本 SHALL 仅影响新发起的实例（与需求 §2.1.11）。
+
+#### Scenario: 升级流程定义
+
+- **WHEN** 发布流程新版本
+- **THEN** 运行中旧实例 SHALL 不自动迁移到新版本节点布局，除非专项迁移工具与规范另有说明
+
+### Requirement: 办理中心
+
+系统 SHALL 提供「待办中心」与「已办中心」，供业务用户在配置好的流程上处理任务（与需求 §2.1.11「流程办理中心」）。
+
+#### Scenario: 审批人登录
+
+- **WHEN** 审批人登录门户
+- **THEN** 其 SHALL 能在待办中心看到待处理任务，处理后任务 SHALL 出现在已办中心且流程实例状态正确推进