zlwu
b220298f89
为减少仓库噪声和重复规则，整理当前开发入口并移除已废弃资料。 - 精简根 AGENTS，补充四个应用规则与 README，统一规范入口 - 归整部署文件、SOP 原稿和参考资源，修正迁移后的脚本路径 - 取消虚拟环境、工具状态、业务导出及备份的跟踪，本机所需原件保留 - 移除停用的 graphify 配置、脚本与产物 - 删除历史业务文档、执行计划、OpenSpec 业务变更和移动 UI 原型 - 清理失效引用，历史细胞产品导入改为必须显式指定 --file 验证：git diff --cached --check、OpenSpec 严格校验、导入参数隔离检查 3/3 通过； 迁移文件完整性和现行链接已核对。未执行部署、业务数据导入或服务启停。
51 lines
3.8 KiB
Markdown
51 lines
3.8 KiB
Markdown
## 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 模式审批人」的安全边界（只读从库、语句白名单等）待专项安全设计补充。
|