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

Co-authored-by: Cursor <cursoragent@cursor.com>

openspec/changes/dict-management/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-05-12

openspec/changes/dict-management/design.md

@@ -0,0 +1,53 @@
+## Context
+
+当前系统无字典管理功能。多个模块（组织管理、站点管理、角色管理等）依赖字典编码进行状态/分类映射（如 zzlbbm、bmzt、zdlx、zdywfw）。数据库表 `sys_dict_type` 和 `sys_dict_data` 已在 DDL 中定义，但后端无对应模型、CRUD、API 路由，前端无对应页面。
+
+**现有代码模式参考：**
+- 后端：`crud/tenant.py` 的独立函数模式（`list_*, get_*, create_*, update_*, soft_delete_*`），`api/admin.py` 的路由模式
+- 前端：`views/system/unit/index.vue` 标准列表模板，`api/admin.ts` 的 `request.get/post/put/del` 模式
+- 模型：`models.py` 中直接使用 `from app.core.database import Base`，公共字段顺序遵循 V0.3 约定
+
+## Goals / Non-Goals
+
+**Goals:**
+- 提供字典类型的完整 CRUD（分页列表、新增、修改、软删除）
+- 提供字典数据的完整 CRUD（按字典类型分组，支持新增、修改、软删除）
+- 前端字典类型列表页 + 字典数据配置弹窗
+- 严格遵循租户隔离、软删除、默认排序等工程规范
+- 初始化字典数据脚本（zzlbbm、bmzt、zdlx、zdywfw）
+
+**Non-Goals:**
+- 字典缓存机制（后续优化）
+- 字典数据批量导入导出
+- 字典变更审计日志
+- 小程序端字典管理
+
+## Decisions
+
+### D1: 后端 CRUD 采用独立函数模式（非 CRUDBase 泛型）
+
+**选择**: 参照 `crud/tenant.py` 的独立函数 + `_row_to_dict()` 模式
+**理由**: 现有业务模块（tenant）均使用此模式，保持一致性比引入新模式更重要
+**替代方案**: 使用 `crud/base.py` 的 `CRUDBase[Model]` 泛型 → 被弃用，因为 tenant 模块未使用，且手动函数更灵活
+
+### D2: 字典 API 路由注册在 admin.py
+
+**选择**: 在现有 `api/admin.py` 中新增字典路由组
+**理由**: 字典属于系统管理范畴，与 tenant 同属 admin 路由前缀 `/web/admin`。模块较少，无需新建文件
+**替代方案**: 新建 `api/system.py` → 可行但当前系统管理模块可集中管理
+
+### D3: 字典数据查询通过 dict_type 关联
+
+**选择**: 字典数据列表按 `dict_type` 过滤查询，前端弹窗传入 `dict_type` 获取对应字典数据
+**理由**: 需求文档明确"点击字典数据配置按钮弹出弹窗"，弹窗需知道当前字典类型
+
+### D4: 前端字典数据配置弹窗采用 Dialog + 内嵌表格
+
+**选择**: 字典类型列表页 + 点击"字典数据配置"弹出 Dialog，Dialog 内展示该类型的字典数据表格，支持行内新增/编辑/删除
+**理由**: 需求文档 2.1.2 描述的交互模式
+
+## Risks / Trade-offs
+
+- **[字典类型编码唯一性]** dict_type 在同一 tenant 下需唯一 → 通过数据库唯一索引 `uk_dict_type` + 应用层校验双重保障
+- **[字典数据量]** 某些字典类型数据较多 → 弹窗内分页查询，每页 20 条
+- **[初始化数据]** 需要确保系统初始化时有基础字典数据 → 提供独立 SQL 初始化脚本

openspec/changes/dict-management/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+系统管理模块需要统一的字典数据管理能力。字典管理是基础设施模块——组织管理(zzlbbm、bmzt)、站点管理(zdlx、zdywfw)、角色管理等多个模块依赖字典数据进行状态、分类等编码映射。必须最先开发，其他模块才能正确引用字典值。
+
+## What Changes
+
+- 新增字典类型（sys_dict_type）完整 CRUD：新增、修改、删除（软删除）、分页列表查询
+- 新增字典数据（sys_dict_data）完整 CRUD：按字典类型分组展示，支持新增、修改、删除（软删除）
+- 后端新增 SQLAlchemy 模型、Pydantic schemas、CRUD 函数、API 路由
+- 前端新增字典管理页面：字典类型列表 + 字典数据配置弹窗，遵循 unit/index.vue 标准列表模板
+- 前端新增 API 函数、TypeScript 类型定义、路由注册
+- 遵循租户隔离（tenant_no 过滤）、默认排序（order_num ASC, create_time DESC）、软删除（del_flag）
+
+## Capabilities
+
+### New Capabilities
+- `dict-crud`: 字典类型和字典数据的完整增删改查能力，包含分页列表、详情查询、创建、更新、软删除，支持租户隔离和关键词搜索
+- `dict-frontend`: 字典管理前端页面，包含字典类型标准列表页和字典数据配置弹窗，遵循 Fresh Mint UI 规范和 web-admin 模板页约定
+
+### Modified Capabilities
+（无已有 spec 需要修改）
+
+## Impact
+
+- **后端**：`app/models/models.py` 新增 SysDictType、SysDictData 模型；`app/api/admin.py` 或新建路由文件新增字典 API；`app/crud/` 新增字典 CRUD
+- **前端**：`src/api/admin.ts` 新增字典 API 函数；`src/types/api.d.ts` 新增 Dict 类型命名空间；`src/views/system/dict/index.vue` 新建页面；`src/router/modules/sqxp.ts` 注册路由
+- **数据库**：表已定义在 `docs/sql/zkxw-requirements-v0.3-schema.sql`（sys_dict_type、sys_dict_data），无需新建表
+- **依赖关系**：组织管理、站点管理、角色管理等模块将依赖本模块提供的字典数据

openspec/changes/dict-management/specs/dict-crud/spec.md

@@ -0,0 +1,72 @@
+## ADDED Requirements
+
+### Requirement: 字典类型分页列表
+系统 SHALL 提供字典类型分页列表查询接口，支持按关键词（dict_name 或 dict_type 模糊匹配）搜索，默认排序 order_num ASC, create_time DESC，严格按当前用户 tenant_no 过滤。
+
+#### Scenario: 查询字典类型列表
+- **WHEN** 用户请求 `GET /api/web/admin/dict-types`，携带 page=1, pageSize=10, keyword="bm"
+- **THEN** 返回当前租户下 dict_name 或 dict_type 包含 "bm" 的字典类型列表，按 order_num 升序、create_time 降序
+
+#### Scenario: 无关键词查询
+- **WHEN** 用户请求字典类型列表，不传 keyword
+- **THEN** 返回当前租户下所有字典类型，分页展示
+
+### Requirement: 字典类型新增
+系统 SHALL 提供字典类型新增接口，必须校验同一 tenant_no 下 dict_type 的唯一性（排除 del_flag=1），自动填充 tenant_no、create_by、create_dept_id。
+
+#### Scenario: 新增字典类型成功
+- **WHEN** 用户提交 dict_name="部门状态"、dict_type="bmzt"
+- **THEN** 创建成功，返回新记录，dict_type 在当前租户内唯一
+
+#### Scenario: dict_type 重复
+- **WHEN** 用户提交已存在的 dict_type（且未被软删除）
+- **THEN** 返回错误，提示"字典类型编码已存在"
+
+### Requirement: 字典类型修改
+系统 SHALL 提供字典类型修改接口，允许修改 dict_name、dict_type、order_num、remark、status。修改 dict_type 时 SHALL 校验新编码在同一 tenant_no 下的唯一性。
+
+#### Scenario: 修改字典类型名称
+- **WHEN** 用户修改 dict_name 从"旧名称"为"新名称"
+- **THEN** 更新成功，update_by 自动设置为当前用户
+
+### Requirement: 字典类型软删除
+系统 SHALL 提供字典类型软删除接口，将 del_flag 设为 1。删除字典类型时 SHALL 同时软删除该类型下所有字典数据。
+
+#### Scenario: 删除字典类型
+- **WHEN** 用户删除一个字典类型
+- **THEN** 该类型 del_flag=1，其下所有 dict_data 的 del_flag 也设为 1
+
+### Requirement: 字典数据分页列表
+系统 SHALL 提供字典数据分页列表查询接口，按 dict_type 过滤，支持按 dict_label 搜索，默认排序 order_num ASC, create_time DESC，严格按当前用户 tenant_no 过滤。
+
+#### Scenario: 按字典类型查询数据
+- **WHEN** 用户请求 `GET /api/web/admin/dict-data`，携带 dictType="bmzt"
+- **THEN** 返回该类型下所有字典数据列表
+
+### Requirement: 字典数据新增
+系统 SHALL 提供字典数据新增接口，自动继承字典类型的 tenant_no，自动填充 create_by、create_dept_id。
+
+#### Scenario: 新增字典数据
+- **WHEN** 用户为 dict_type="bmzt" 新增 dict_label="正常"、dict_value="1"
+- **THEN** 创建成功，tenant_no 与字典类型一致
+
+### Requirement: 字典数据修改
+系统 SHALL 提供字典数据修改接口，允许修改 dict_label、dict_value、order_num、remark。
+
+#### Scenario: 修改字典数据
+- **WHEN** 用户修改某条字典数据的 dict_label
+- **THEN** 更新成功，update_by 自动设置
+
+### Requirement: 字典数据软删除
+系统 SHALL 提供字典数据软删除接口，将 del_flag 设为 1。
+
+#### Scenario: 删除字典数据
+- **WHEN** 用户删除一条字典数据
+- **THEN** 该条数据 del_flag=1，不再出现在列表查询中
+
+### Requirement: 字典数据下拉查询
+系统 SHALL 提供按 dict_type 查询有效字典数据的轻量接口（不分页），用于其他模块的下拉选项。
+
+#### Scenario: 下拉查询
+- **WHEN** 前端请求 `GET /api/web/admin/dict-data/options?dictType=bmzt`
+- **THEN** 返回该类型下所有有效字典数据的 label+value 列表，用于下拉选项渲染

openspec/changes/dict-management/specs/dict-frontend/spec.md

@@ -0,0 +1,56 @@
+## ADDED Requirements
+
+### Requirement: 字典类型列表页
+系统 SHALL 提供字典类型标准列表页面，遵循 `unit/index.vue` 模板，包含搜索区域（关键词）、工具栏（新增按钮）、数据表格（字典名称、字典类型编码、排序号、备注、操作列）、分页器。
+
+#### Scenario: 字典类型列表展示
+- **WHEN** 用户访问字典管理页面
+- **THEN** 页面显示字典类型列表，操作列包含"字典数据配置"、"编辑"、"删除"按钮
+
+#### Scenario: 关键词搜索
+- **WHEN** 用户在搜索框输入关键词并点击搜索
+- **THEN** 列表按 dict_name 或 dict_type 模糊匹配过滤
+
+### Requirement: 字典类型新增/编辑弹窗
+系统 SHALL 提供字典类型新增/编辑弹窗，使用 `label-position="top"` + `.form-grid-2` 布局，字段包含字典名称(dict_name)、字典类型编码(dict_type)、排序号(order_num)、备注(remark)。
+
+#### Scenario: 新增字典类型
+- **WHEN** 用户点击"新增"按钮
+- **THEN** 弹窗打开，表单为空，提交后创建新字典类型
+
+#### Scenario: 编辑字典类型
+- **WHEN** 用户点击某行"编辑"按钮
+- **THEN** 弹窗打开，表单回填当前行数据，提交后更新
+
+### Requirement: 字典数据配置弹窗
+系统 SHALL 提供字典数据配置弹窗，当用户点击字典类型行的"字典数据配置"按钮时弹出。弹窗内展示该字典类型下的字典数据表格，支持新增、编辑、删除操作。
+
+#### Scenario: 打开字典数据配置
+- **WHEN** 用户点击某字典类型的"字典数据配置"按钮
+- **THEN** 弹窗打开，标题显示"XX 字典数据配置"，表格展示该类型的字典数据列表
+
+#### Scenario: 弹窗内新增字典数据
+- **WHEN** 用户在弹窗内点击"新增"按钮
+- **THEN** 表格顶部出现编辑行，用户填写 dict_label、dict_value、order_num、remark 后保存
+
+#### Scenario: 弹窗内编辑字典数据
+- **WHEN** 用户在弹窗内点击某行"编辑"
+- **THEN** 该行变为编辑状态，修改后保存
+
+#### Scenario: 弹窗内删除字典数据
+- **WHEN** 用户在弹窗内点击某行"删除"并确认
+- **THEN** 该条字典数据被软删除，从列表移除
+
+### Requirement: 路由注册
+字典管理页面 SHALL 注册到系统管理路由组下，路径为 `/system/dict`。
+
+#### Scenario: 通过菜单访问
+- **WHEN** 用户点击系统管理菜单下的"字典管理"
+- **THEN** 路由跳转到字典类型列表页
+
+### Requirement: 列表面板标题规范
+列表页面板标题 SHALL 显示"字典管理"，并使用 `::before` 伪元素显示 primary 色竖线。
+
+#### Scenario: 标题显示
+- **WHEN** 页面加载完成
+- **THEN** 面板标题区域显示带绿色竖线的"字典管理"标题

openspec/changes/dict-management/tasks.md

@@ -0,0 +1,36 @@
+## 1. 后端模型与CRUD
+
+- [ ] 1.1 在 `backend/app/models/models.py` 新增 SysDictType、SysDictData SQLAlchemy 模型，遵循 V0.3 公共字段约定（id, 业务字段, tenant_no, order_num, remark, create_by, create_dept_id, create_time, update_by, update_time, del_flag）
+- [ ] 1.2 在 `backend/app/models/__init__.py` 导出新模型
+- [ ] 1.3 创建 `backend/app/crud/dict_type.py`：实现 list_dict_types、get_dict_type、create_dict_type、update_dict_type、soft_delete_dict_type 函数，包含 _row_to_dict 转换、关键词搜索、分页、唯一性校验
+- [ ] 1.4 创建 `backend/app/crud/dict_data.py`：实现 list_dict_data、get_dict_data、create_dict_data、update_dict_data、soft_delete_dict_data 函数，包含按 dict_type 过滤、dict_label 搜索、分页
+- [ ] 1.5 实现 dict-data options 下拉查询接口的 CRUD 函数（不分页，返回 label+value 列表）
+
+## 2. 后端API路由
+
+- [ ] 2.1 在 `backend/app/api/admin.py` 新增字典类型 CRUD 路由（GET /dict-types, POST /dict-types, PUT /dict-types/{id}, DELETE /dict-types/{id}）
+- [ ] 2.2 在 `backend/app/api/admin.py` 新增字典数据 CRUD 路由（GET /dict-data, POST /dict-data, PUT /dict-data/{id}, DELETE /dict-data/{id}）
+- [ ] 2.3 新增字典数据下拉选项路由（GET /dict-data/options）
+- [ ] 2.4 验证所有路由使用 require_admin_or_super_admin 依赖注入，正确传递 tenant_no、user_id
+
+## 3. 前端API与类型
+
+- [ ] 3.1 在 `web-admin/src/types/api.d.ts` 新增 `Api.Dict` 命名空间，定义 DictTypeItem、DictDataItem 接口
+- [ ] 3.2 在 `web-admin/src/api/admin.ts` 新增字典类型 API 函数：fetchDictTypeList、fetchCreateDictType、fetchUpdateDictType、fetchDeleteDictType
+- [ ] 3.3 在 `web-admin/src/api/admin.ts` 新增字典数据 API 函数：fetchDictDataList、fetchCreateDictData、fetchUpdateDictData、fetchDeleteDictData、fetchDictDataOptions
+
+## 4. 前端页面
+
+- [ ] 4.1 创建 `web-admin/src/views/system/dict/index.vue` 字典类型列表页，参照 unit/index.vue 模板
+- [ ] 4.2 实现字典类型搜索、分页、新增/编辑弹窗
+- [ ] 4.3 实现字典数据配置弹窗（Dialog + 内嵌表格），支持弹窗内新增/编辑/删除字典数据
+- [ ] 4.4 在 `web-admin/src/router/modules/sqxp.ts` 系统管理路由组下注册字典管理路由（path: dict, component: /system/dict/index）
+
+## 5. 数据初始化
+
+- [ ] 5.1 在 `docs/sql/` 下创建字典初始化数据 SQL 脚本，包含初始字典类型（zzlbbm、bmzt、zdlx、zdywfw）及其字典数据
+
+## 6. 验证
+
+- [ ] 6.1 后端验证：启动服务，通过 Swagger /docs 测试所有字典 CRUD 接口
+- [ ] 6.2 前端验证：启动 dev server，验证字典类型列表页和字典数据配置弹窗功能完整可用

openspec/changes/zkxw-engineering-standards/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-05-12

openspec/changes/zkxw-engineering-standards/design.md

@@ -0,0 +1,50 @@
+## Context
+
+- 业务与数据规则来源：`docs/中科兴皖需求V0.3.md`（含菜单、表模型、§3 技术要求、§2.1.11 工作流、§2.1.5 权限等）。
+- Web 端视觉与交互权威：`docs/web-admin-ui-spec-fresh-mint.md` 及其中引用的 `docs/fresh-mint-green.html`。
+- 小程序端权威：`docs/miniprogram-ui-spec-sanqiang.md` 及其中列出的 `mobile-ui/sanqiang-*.html`。
+- 工程运行与目录约定：`AGENTS.md`、`.cursorrules`、后端 `app/` 与前端 `web-admin/`、`miniprogram/` 现状。
+
+本变更的 `specs/*/spec.md` 为**可测试的规范摘要**；凡涉及色值、类名、组件级布局的细则，**不以本 design 重复展开**，而以对应 Markdown/HTML 为准，避免双源漂移。
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- 用 OpenSpec 将「架构 / 接口 / UI / 编码 / 库表 / 工作流 / 权限」七类约束写成可追溯的 SHALL 与场景。
+- 明确「需求 §3」与「两份 UI 规范」之间的分工：前者定数据与租户/API 行为，后者定界面 Token 与页面骨架。
+
+**Non-Goals:**
+
+- 不替代需求文档中的完整表字段与业务流程叙述。
+- 不规定具体 REST 路径命名或 Pydantic 字段命名（除非需求或仓库已有全局约定）；此类细节留在各功能变更的 spec 中展开。
+- 不在此变更中实现工作流引擎或权限中间件代码。
+
+## Decisions
+
+1. **规范分层**  
+   - **Normative（强制执行）**：需求 V0.3 §3、`specs/database-conventions`、`specs/api-conventions` 中与租户/软删/排序/附件相关的条目。  
+   - **Normative（UI）**：`specs/ui-conventions` 中「以文档为权威、禁止跨端调色板混用」等；像素与类名级规则引用原文档。  
+   - **Descriptive（设计说明）**：本 `design.md` 仅解释如何阅读上述分层。
+
+2. **能力拆分粒度**  
+   按用户请求的七大主题拆为七个 capability，便于按域评审与归档；跨域条目（如「租户」同时影响 API 与库表）在相关 spec 中各写一条，避免单文件过长。
+
+3. **与实现仓库的关系**  
+   后端已为 FastAPI + `/api` 前缀等（见 `AGENTS.md`）；与需求 §3 中「前端基于 art-design-pro + `pnpm clean:dev`」「小程序 HBuilderX + uni-app + Vue3 + Vant」在 **architecture-conventions** 中记为 SHALL「须与当前仓库技术栈一致或可渐进迁移」，具体迁移不在本变更范围。
+
+## Risks / Trade-offs
+
+- [规范与代码漂移] → 大版本或基线发布时执行 `openspec archive` 将变更合入 `openspec/specs/`，并在 PR 模板中引用对应 requirement id。  
+- [摘要过粗导致落地争议] → UI/表结构仍以原文档与 `docs/sql/` 为准；争议时以需求/设计稿变更驱动增量 spec。  
+- [七文件维护成本] → 跨域同一概念允许多处一句话重复，优先可读性而非 DRY。
+
+## Migration Plan
+
+- 无数据迁移。团队采纳后可将 `openspec/config.yaml` 增加 `context` 摘要指向本变更目录。
+- 若后续归档：按 OpenSpec 归档流程将 `specs/` 合并入 `openspec/specs/`。
+
+## Open Questions
+
+- 需求 §3 写明的「前端 art-design-pro」与当前仓库 `web-admin` 若存在差异，是否以仓库为准统一需求文档（产品决策）。
+- 工作流「SQL 模式审批人」的安全边界（只读从库、语句白名单等）待专项安全设计补充。

openspec/changes/zkxw-engineering-standards/proposal.md

@@ -0,0 +1,31 @@
+## Why
+
+中科兴皖一体化门户的技术与体验约束分散在《中科兴皖需求 V0.3》、Web 管理端与小程序 UI 规范及仓库 `AGENTS.md` / `.cursorrules` 中，缺少一份可被评审、版本化且与实现检查对齐的**单一事实来源（OpenSpec）**。本变更将上述材料提炼为可测试的 SHALL 级需求与架构/设计说明，便于研发、测试与评审统一口径。
+
+## What Changes
+
+- 新增 OpenSpec 变更 `zkxw-engineering-standards`，包含提案、设计说明、**七项能力规范**及落地任务清单。
+- **不修改**业务代码；规范正文以需求 V0.3 第 3 节「技术要求」为硬约束，UI 细节以两份 UI 规范文档为权威展开（本变更中的 UI 条目为**跨端统一原则与引用约束**，像素级 Token 仍以原文档为准）。
+- 工作流/审批与权限条目直接对齐需求文档 **§2.1.11 流程管理** 与 **§2.1.5 角色管理** 等章节。
+
+## Capabilities
+
+### New Capabilities
+
+- `architecture-conventions`：仓库分层、技术栈选型（Python 后端、Web 管理端、小程序端）及与需求文档的对应关系。
+- `api-conventions`：租户隔离、数据权限过滤、列表默认排序、附件存储形态等接口与数据层统一约定。
+- `ui-conventions`：Web（Fresh Mint）与小程序（三墙体系）的权威文档、Token/骨架级统一要求及**禁止跨端混色**等约束。
+- `coding-conventions`：前后端工程化与编码风格（与 `AGENTS.md`、`.cursorrules` 一致的最小必要集合）。
+- `database-conventions`：MySQL 5.7、公共字段、软删除、字段顺序等数据库层规范。
+- `workflow-conventions`：自研工作流的目标能力、配置、运行时与待办/已办中心（对齐需求 §2.1.11）。
+- `permission-conventions`：角色-菜单-数据权限模型及多角色权限合并规则（对齐需求 §2.1.5 等）。
+
+### Modified Capabilities
+
+- （无）当前仓库 `openspec/specs/` 下尚无已归档基线能力。
+
+## Impact
+
+- **文档**：新增 `openspec/changes/zkxw-engineering-standards/` 下全部制品；可选后续将 `openspec/config.yaml` 的 `context` 指向本变更摘要以降低 AI/新人上下文漂移。
+- **代码**：无直接代码变更；后续功能开发应以本变更中的 `specs/*/spec.md` 为评审依据之一。
+- **系统**：不涉及部署与运行时行为变更。

openspec/changes/zkxw-engineering-standards/specs/api-conventions/spec.md

@@ -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` 中完成注册，并符合现有认证与租户上下文注入模式

openspec/changes/zkxw-engineering-standards/specs/architecture-conventions/spec.md

@@ -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 规范文档路径

openspec/changes/zkxw-engineering-standards/specs/coding-conventions/spec.md

@@ -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 使评审者无需阅读聊天历史即可理解动机与风险

openspec/changes/zkxw-engineering-standards/specs/database-conventions/spec.md

@@ -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 字符串

openspec/changes/zkxw-engineering-standards/specs/permission-conventions/spec.md

@@ -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 拒绝访问

openspec/changes/zkxw-engineering-standards/specs/ui-conventions/spec.md

@@ -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）
+

openspec/changes/zkxw-engineering-standards/specs/workflow-conventions/spec.md

@@ -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 出现在已办中心且流程实例状态正确推进

openspec/changes/zkxw-engineering-standards/tasks.md

@@ -0,0 +1,16 @@
+## 1. 评审与采纳
+
+- [ ] 1.1 产品/研发共同评审 `proposal.md` 中的七项能力划分是否与中科兴皖项目阶段匹配
+- [ ] 1.2 对照 `docs/中科兴皖需求V0.3.md` §3 校验 `database-conventions` 与 `api-conventions` 中的 SHALL 条目
+- [ ] 1.3 对照 `docs/web-admin-ui-spec-fresh-mint.md` 与 `docs/miniprogram-ui-spec-sanqiang.md` 校验 `ui-conventions` 是否覆盖团队最关心的门禁（色板、树路径、弹窗）
+
+## 2. 与仓库治理对齐
+
+- [ ] 2.1 可选：在 `openspec/config.yaml` 增加 `context` 字段，指向本变更目录或 `openspec/specs/` 归档后的基线说明
+- [ ] 2.2 在 PR 模板或评审清单中增加一条：涉及租户/软删/排序的改动必须对照 `api-conventions` 与 `database-conventions`
+- [ ] 2.3 工作流专项启动前，将 `workflow-conventions` 中 SQL 审批人、版本迁移等「Open Questions」拆成独立变更
+
+## 3. 归档（实现稳定后）
+
+- [ ] 3.1 按 OpenSpec 归档流程将 `zkxw-engineering-standards` 合并入 `openspec/specs/`，使基线规范与活跃变更分离
+- [ ] 3.2 归档后更新 `AGENTS.md` 或贡献指南中的「规范入口」链接，指向上游 spec 路径

openspec/config.yaml

@@ -0,0 +1,18 @@
+schema: spec-driven
+
+# Project context (optional)
+# This is shown to AI when creating artifacts.
+context: |
+  zkxw（陇耘鲜达 / 中科兴皖一体化门户）：FastAPI 后端 + Vue3 web-admin + uni-app 小程序。
+  工程规范摘要见 OpenSpec 变更：openspec/changes/zkxw-engineering-standards/（含 architecture、api、ui、coding、database、workflow、permission 七类 spec）。
+  需求与 UI 权威文档：docs/中科兴皖需求V0.3.md、docs/web-admin-ui-spec-fresh-mint.md、docs/miniprogram-ui-spec-sanqiang.md；仓库约定见 AGENTS.md、.cursorrules。
+
+# Per-artifact rules (optional)
+# Add custom rules for specific artifacts.
+# Example:
+#   rules:
+#     proposal:
+#       - Keep proposals under 500 words
+#       - Always include a "Non-goals" section
+#     tasks:
+#       - Break tasks into chunks of max 2 hours