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

Context

• 业务与数据规则入口：根 AGENTS.md 与本变更 specs/*/spec.md。既有条目最初提炼自《中科兴皖需求 V0.3》（含菜单、表模型、§3 技术要求、§2.1.11 工作流、§2.1.5 权限等）；历史需求原文已清理，章节引文仅用于说明来源，既有 SHALL 要求继续保留。
• Web 端视觉与交互权威：docs/web-admin-ui-spec-fresh-mint.md 及其中引用的 docs/fresh-mint-green.html。
• 小程序端权威：docs/miniprogram-ui-spec-sanqiang.md （其中引用的三墙历史原型已缺失，视觉细则按现存规范正文核实）。
• 工程运行与目录约定：根及各应用 AGENTS.md；四个应用入口为 backend/、web-admin/、mobile-h5/、mobile-oa-h5/。Cursor 配置仅保留入口。

本变更的 specs/*/spec.md 为可测试的规范摘要；凡涉及色值、类名、组件级布局的细则，不以本 design 重复展开，而以对应 Markdown/HTML 为准，避免双源漂移。

Goals / Non-Goals

Goals:

• 用 OpenSpec 将「架构 / 接口 / UI / 编码 / 库表 / 工作流 / 权限」七类约束写成可追溯的 SHALL 与场景。
• 明确「本变更既有技术 SHALL 要求」与「当前 UI 规范」之间的分工：前者定数据与租户/API 行为，后者定界面 Token 与页面骨架。

Non-Goals:

• 本变更仅保留已提炼的工程约束，不补写已清理历史需求中的完整表字段与业务流程叙述。
• 不规定具体 REST 路径命名或 Pydantic 字段命名（除非需求或仓库已有全局约定）；此类细节留在各功能变更的 spec 中展开。
• 不在此变更中实现工作流引擎或权限中间件代码。

Decisions

1. 规范分层

   • Normative（强制执行）：根 AGENTS.md 与本变更七项能力的既有 SHALL 要求，包括 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 细则以当前 UI 规范为准，数据约束按现有 SHALL 要求与 docs/sql/ 核验；争议时以经确认的需求/设计变更驱动增量 spec。
• [七文件维护成本] → 跨域同一概念允许多处一句话重复，优先可读性而非 DRY。

Migration Plan

• 无数据迁移。团队采纳后可将 openspec/config.yaml 增加 context 摘要指向本变更目录。
• 若后续归档：按 OpenSpec 归档流程将 specs/ 合并入 openspec/specs/。

Open Questions

• 历史需求 §3 写明的「前端 art-design-pro」与当前仓库 web-admin 若存在差异，须经产品决策确认后更新相应工程标准，不以代码现状自动改写规范。
• 工作流「SQL 模式审批人」的安全边界（只读从库、语句白名单等）待专项安全设计补充。