docs: retire conflicting UI baselines
This commit is contained in:
Codex
@@ -1,35 +0,0 @@
|
||||
# 善缘丹阳 V1.1 双端高保真 UI 修订设计
|
||||
|
||||
## 目标
|
||||
|
||||
以《前端 UI-UX 高保真原型修订说明》和《页面级功能清单与交互流程修订版》为唯一 UI/交互验收依据，在保留现有业务能力的前提下，完成微信小程序端与响应式运营后台的可见界面校正，并提供可运行预览与截图。
|
||||
|
||||
## 设计原则
|
||||
|
||||
- 品牌气质：温暖、可信、公益、本地、现代；避免商业婚恋滑卡感与政务门户感。
|
||||
- 小程序：暖白 `#FAFAF8` 页面背景、珊瑚红 `#E96B6B` 主色、白色卡片、轻阴影、16px 页面边距、24px 模块间距、至少 44px 点击区。
|
||||
- 后台：220px 浅色侧栏、清晰工作台、白色内容卡片、中等信息密度；在 1366×768 与 1440×900 下可用。
|
||||
- 只复用现有原生小程序与 Vue 3 + Element Plus 技术栈，不引入新 UI 框架或在线字体。
|
||||
- 所有可见入口、页面结构、空状态和提示文案必须使用简体中文。
|
||||
|
||||
## 小程序信息架构
|
||||
|
||||
底部固定为：首页、找对象、消息、活动、我的。
|
||||
|
||||
首页固定顺序为：品牌区、用户状态、Banner、8 个核心入口、今日推荐、善缘公益服务、近期公益活动、善缘服务站、婚恋课堂、安全提醒。8 个入口固定两行四列，依次为找对象、公益红娘、公益活动、婚恋咨询、婚恋课堂、婚前辅导、婚恋反诈、善缘服务站。
|
||||
|
||||
首批可见闭环覆盖 U18、U19、U21、U23、U24、U27、U28、U33、U37、U50、U55、U60；补齐服务预约、婚恋课堂、内容详情、我的咨询、婚前辅导、本地资格、公益服务记录等二级入口。每页具备加载、空、错误三类状态的统一视觉。
|
||||
|
||||
## 管理后台信息架构
|
||||
|
||||
布局使用固定品牌侧栏、顶部上下文栏和主内容区。菜单依权限显示，并按工作台、资料与用户、婚恋服务、活动运营、内容与 Banner、服务阵地、安全治理、组织与系统、数据统计分组。
|
||||
|
||||
工作台首屏根据角色显示“今天需要处理的事项”，不再使用面向所有角色的通用大盘。Reviewer、Matchmaker、Counselor、Service Station Operator、Activity Manager、Risk Operator 各自看到与职责对应的待办卡、快捷入口和最近任务。
|
||||
|
||||
## 状态与演示
|
||||
|
||||
真实接口成功时展示接口数据；开发预览接口不可用时，页面使用明确标注为“界面预览数据”的本地演示数据，保证无需生产账号即可审查 UI，不把演示数据写入后端。最终验收包含静态契约检查、类型检查、构建和实际浏览器截图；小程序通过微信开发者工具或本地渲染预览检查 320/375/390/430px 宽度。
|
||||
|
||||
## 非目标
|
||||
|
||||
本次不重写后端业务、不改变权限规则、不增加付费/VIP/外链 Banner/陌生人私信等被禁止功能，也不扩展两份文档之外的页面模块。
|
||||
@@ -1,38 +0,0 @@
|
||||
# Codex 基线归并与旧环境清理设计
|
||||
|
||||
## 目标
|
||||
|
||||
以 `codex/ui-v11-fidelity` 的 `ac2327b` 为唯一代码基线，清除 ZCode 遗留、旧 Phase 分支、临时依赖与本项目历史 Docker 环境，并从空环境验证启动。
|
||||
|
||||
## 保留
|
||||
|
||||
- Codex 分支、冻结标签和完整 Git 历史；
|
||||
- `artifacts/backups/*.dump` 数据库备份；
|
||||
- Flyway 全部迁移文件；
|
||||
- 当前 V1.1 客户需求文档与 Codex 已完成代码。
|
||||
|
||||
## 清理
|
||||
|
||||
- `.zcode/`；
|
||||
- 旧 `phase/02-rbac-datascope` 分支；
|
||||
- 已跟踪的临时 Maven 包、临时 POM、小程序 `.bak`；
|
||||
- `node_modules`、`target`、`dist`、pytest 缓存等可重建产物；
|
||||
- 仅属于本项目的旧容器、镜像、网络和数据卷。
|
||||
|
||||
其他项目的 Docker 资源不在本次范围内。
|
||||
|
||||
## 归并与重建
|
||||
|
||||
1. 将 `main` 快进到 Codex 基线，保留 `codex/ui-v11-fidelity` 作为审计分支。
|
||||
2. 数据卷删除前创建 PostgreSQL 备份。
|
||||
3. 清理后按锁文件重新安装依赖，从空 PostgreSQL 执行 Flyway。
|
||||
4. 修复妨碍纯净启动的配置冲突，但不重构业务架构。
|
||||
|
||||
## 验收
|
||||
|
||||
- Git 工作区仅保留预期变更和备份；
|
||||
- 后端测试及构建通过；
|
||||
- 管理端类型检查、构建及页面访问通过；
|
||||
- 小程序 TypeScript 检查通过，并能由微信开发者工具打开；
|
||||
- PostgreSQL、Redis、MinIO、Backend 健康，管理端可访问；
|
||||
- 不删除或停止其他项目的容器、网络、卷和镜像。
|
||||
@@ -1,215 +0,0 @@
|
||||
# 善缘丹阳 V1.1 双端全量 UI 重设计规格
|
||||
|
||||
日期：2026-09-11
|
||||
状态：已获用户方案批准，待规格复核
|
||||
视觉来源：
|
||||
|
||||
- `ChatGPT Image 2026年9月11日 10_34_34 (1).png`：管理端视觉基准；
|
||||
- `ChatGPT Image 2026年9月11日 12_46_40.png`：小程序导航页与 Tab 页视觉基准。
|
||||
|
||||
## 1. 目标
|
||||
|
||||
在不改变 V1.1 业务能力、接口契约、权限边界和核心不变量的前提下，重设计管理端全部现有页面及小程序全部 63 个页面，使双端具有统一品牌识别、清晰信息层级、完整交互状态和可验证的参考图还原度。
|
||||
|
||||
## 2. 已确认范围
|
||||
|
||||
1. 只实现参考海报中的实际软件界面，不实现外围宣传标题、标语或城市背景画布。
|
||||
2. 保留 V1.1 全部功能、页面、路由、权限和接口。
|
||||
3. 小程序首页保留固定 8 个核心入口及现行文档规定的完整模块顺序。
|
||||
4. 管理端保留全部模块，通过一级分组与二级菜单整理，不隐藏或删除功能。
|
||||
5. 管理端全部现有业务路由、小程序全部 63 个页面均纳入本次重设计。
|
||||
6. 允许制作原创 Logo、Banner、丹阳城市插画、活动和内容封面、匿名演示头像及状态插画。
|
||||
7. 页面继续读取真实 API；参考图中的人物、活动和统计数字仅用于确定布局密度，不硬编码进业务页面。
|
||||
|
||||
## 3. 设计方向
|
||||
|
||||
### 3.1 统一品牌
|
||||
|
||||
双端共用“善缘丹阳”品牌名称、心形识别符号、字体层级、图标笔画语言和公益、真实、安全、温暖的表达原则。
|
||||
|
||||
正式视觉资产必须使用可交付图片或现有图标库。不得使用 Emoji、文字方块、CSS 拼图、临时占位框或手写 SVG 冒充正式资产。
|
||||
|
||||
### 3.2 管理端主题
|
||||
|
||||
- 暖白页面背景；
|
||||
- 珊瑚红作为主操作和强调色；
|
||||
- 深蓝灰侧栏；
|
||||
- 浅粉、浅蓝、浅绿、浅紫用于状态卡片；
|
||||
- 信息密度接近参考图中央后台窗口；
|
||||
- 风格专业、可信、克制，避免霓虹化和过度装饰。
|
||||
|
||||
### 3.3 小程序主题
|
||||
|
||||
- 紫蓝夜景作为品牌氛围；
|
||||
- 粉色作为主要操作和选中状态；
|
||||
- 内容区使用高对比白色或浅色卡片；
|
||||
- 保留参考图的温暖陪伴感和丹阳城市意象；
|
||||
- 长文本、表单、安全提示和敏感操作页优先保证可读性，不使用高饱和背景承载正文。
|
||||
|
||||
## 4. 技术边界
|
||||
|
||||
- 管理端继续使用 Vue 3、TypeScript、Vite、Pinia 和 Element Plus。
|
||||
- 小程序继续使用微信原生框架和现有 TypeScript/JavaScript 页面，不迁移跨端框架。
|
||||
- 优先改造现有主题变量和公共组件，不引入大型 UI 依赖。
|
||||
- 默认不修改后端、数据库、API 和业务规则。
|
||||
- 如视觉流程暴露缺失接口或缺失业务路由，先记录并请求确认，不擅自扩展产品范围。
|
||||
- Mutual Match、Block、活动互选二阶段确认、Capability、数据范围和敏感信息权限保持不变。
|
||||
|
||||
## 5. 管理端信息架构
|
||||
|
||||
现有页面按权限动态显示，并归入以下导航组：
|
||||
|
||||
1. 工作台；
|
||||
2. 用户与资料审核；
|
||||
3. 匹配与活动服务；
|
||||
4. 公益咨询与转介；
|
||||
5. 服务站、预约与专项服务；
|
||||
6. Banner 与内容运营；
|
||||
7. 举报、申诉与审计；
|
||||
8. 组织、人员与权限；
|
||||
9. 数据统计。
|
||||
|
||||
管理端整体框架包含品牌侧栏、分组菜单、顶部搜索、通知、当前操作员、面包屑、内容区和响应式收起状态。登录页、工作台、列表、详情、编辑、筛选、弹窗、分页和危险操作确认必须使用同一设计系统。
|
||||
|
||||
## 6. 小程序信息架构
|
||||
|
||||
底部导航固定为：
|
||||
|
||||
1. 首页；
|
||||
2. 找对象；
|
||||
3. 消息；
|
||||
4. 活动；
|
||||
5. 我的。
|
||||
|
||||
首页 8 个入口固定为：
|
||||
|
||||
1. 找对象；
|
||||
2. 公益红娘；
|
||||
3. 公益活动；
|
||||
4. 婚恋咨询；
|
||||
5. 婚恋课堂；
|
||||
6. 婚前辅导；
|
||||
7. 婚恋反诈；
|
||||
8. 善缘服务站。
|
||||
|
||||
63 个页面按以下领域统一改造：
|
||||
|
||||
- 登录、手机号、实名、本地资格；
|
||||
- 用户资料、照片、兴趣、择偶条件和审核状态；
|
||||
- 推荐、人物详情、喜欢、匹配和聊天；
|
||||
- 活动、报名、签到、反馈和活动互选；
|
||||
- 公益红娘；
|
||||
- 婚恋咨询与婚前辅导；
|
||||
- 服务中心、服务站、预约、专项服务和服务记录；
|
||||
- 婚恋课堂、内容详情和婚恋反诈；
|
||||
- 举报、申诉、黑名单、隐私和账号生命周期；
|
||||
- 通知、帮助、关于及异常状态页。
|
||||
|
||||
## 7. 公共组件与状态
|
||||
|
||||
### 7.1 管理端
|
||||
|
||||
- 页面标题与操作区；
|
||||
- 数据概览卡；
|
||||
- 筛选栏；
|
||||
- 数据表格；
|
||||
- 状态标签；
|
||||
- 详情分区；
|
||||
- 表单与弹窗；
|
||||
- 空数据、错误、无权限和加载状态；
|
||||
- 二次确认与操作结果反馈。
|
||||
|
||||
### 7.2 小程序
|
||||
|
||||
- 品牌导航栏；
|
||||
- 自定义 Tab Bar；
|
||||
- 用户、推荐和活动卡片；
|
||||
- 服务入口与功能宫格；
|
||||
- 会话列表和聊天气泡；
|
||||
- 表单、上传和步骤状态；
|
||||
- 底部固定操作栏；
|
||||
- 加载骨架、空状态、网络错误、权限不足、审核中和服务不可用状态。
|
||||
|
||||
## 8. 素材策略
|
||||
|
||||
- 制作独立 Logo 与小尺寸品牌图标，不从展示海报裁切。
|
||||
- Tab 图标提供普通态和选中态，并适配微信安全区。
|
||||
- Banner、活动封面、课堂封面和服务插画按实际组件尺寸生成。
|
||||
- 匿名演示头像只用于本地测试和验收，不冒充真实用户。
|
||||
- 真实用户头像、活动数据和统计值继续由 API 提供。
|
||||
- 素材在小程序包体限制内优化；需要远程托管的业务图片走现有私有对象存储。
|
||||
|
||||
## 9. 响应式与可访问性
|
||||
|
||||
- 管理端验证 1280、1366、1440、1920 宽度，窄屏采用真实重排而非整体缩放。
|
||||
- 小程序验证 320、375、390、430 像素宽度及底部安全区。
|
||||
- 正文、按钮和状态标签满足可读对比度。
|
||||
- 状态不能只依赖颜色表达。
|
||||
- 交互目标尺寸、键盘焦点、表单标签、错误恢复和重要结果反馈均需验证。
|
||||
- 截图只能发现视觉风险，最终仍需真机、键盘和交互测试。
|
||||
|
||||
## 10. 实施阶段与门禁
|
||||
|
||||
### Phase 01：基线冻结
|
||||
|
||||
建立完整页面矩阵，记录路由、角色、接口、状态和改造前截图；发现缺口只登记，不扩展功能。
|
||||
|
||||
门禁：页面覆盖率 100%，缺口均有归属。
|
||||
|
||||
### Phase 02：品牌资产与设计系统
|
||||
|
||||
完成双端令牌、Logo、Tab 图标、核心插画和公共组件规范。
|
||||
|
||||
门禁：用户审核素材样张与设计令牌。
|
||||
|
||||
### Phase 03：样板页面
|
||||
|
||||
管理端完成登录、框架、工作台、用户列表和用户详情；小程序完成首页、找对象、消息、活动、我的和 Tab Bar。
|
||||
|
||||
门禁：参考图与实现图同尺寸并排对比，用户确认视觉方向。
|
||||
|
||||
### Phase 04：管理端全量页面
|
||||
|
||||
按导航业务域逐组完成全部页面和全部状态。
|
||||
|
||||
门禁：类型检查、构建、权限路由与核心操作流程通过。
|
||||
|
||||
### Phase 05：小程序五个 Tab 页面
|
||||
|
||||
完成五个一级页面、导航联动、未读红点和安全区适配。
|
||||
|
||||
门禁：微信开发者工具编译无错误，多尺寸截图通过。
|
||||
|
||||
### Phase 06：小程序其余页面
|
||||
|
||||
按业务领域分批完成其余页面，每批复用已批准组件和视觉令牌。
|
||||
|
||||
门禁：63 个页面均可进入、返回并正确展示主要状态。
|
||||
|
||||
### Phase 07：全量验证与交付
|
||||
|
||||
完成构建、类型检查、接口联调、核心业务回归、视觉对比、响应式和可访问性检查。
|
||||
|
||||
门禁：输出页面完成矩阵、视觉验收报告、测试结果和剩余限制。
|
||||
|
||||
每个 Phase 完成后输出 Completion Report，未通过门禁不得自动进入下一阶段。
|
||||
|
||||
## 11. 验收标准
|
||||
|
||||
1. 管理端全部现有路由有统一设计且权限行为不变。
|
||||
2. 小程序 63 个页面无遗漏，五个 Tab 与 8 个首页入口保持固定。
|
||||
3. 参考图中的颜色关系、卡片层次、圆角、间距、图标风格和信息密度得到一致实现。
|
||||
4. 页面不使用硬编码演示数据冒充接口成功。
|
||||
5. 加载、空数据、错误、无权限、不可用和危险操作状态完整。
|
||||
6. 管理端构建与类型检查通过。
|
||||
7. 小程序 TypeScript 检查及微信开发者工具编译通过。
|
||||
8. 核心业务不变量和权限矩阵无回归。
|
||||
|
||||
## 12. 非目标
|
||||
|
||||
- 不删除或缩减 V1.1 功能；
|
||||
- 不新增参考图和现行需求之外的业务；
|
||||
- 不重写后端或数据库；
|
||||
- 不迁移前端框架；
|
||||
- 不引入微服务或额外基础设施；
|
||||
- 不为追求截图相似度牺牲隐私、安全、权限或真实数据流。
|
||||
Reference in New Issue
Block a user