36 KiB
4.2 APP 首页
本文件是【APP 首页与导航 HOM】模块需求的编辑入口。 主文件
../Continental-Retail-APP-PRD.md第 4.2 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。 两者不一致时以本文件为准。 目录约定见README.md。
| 项 | 值 |
|---|---|
| 模块码 | HOM |
| V1.0 章节 | 4.2 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 设计稿 3 版 |
| 现状承载系统 | ROOS / O2O / 延保（三套 tabbar 待废弃） |
| 需求条数 | 14（待确认 11，完成度 21%） |
| 本次新增待确认 | 1（REQ-HOM-016 见附-5） |
| 配图 | 5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1） |
模块概要
APP 首页是用户登录成功后展示的第一个页面。不同角色因权限不同，展示的信息和菜单不一样。
页面内容 —— 店长首页目标形态，自上而下为门店名 + 问候语 + 铃铛（角标 9）的头部、橙色「今日预计营收」卡、快速核销与车牌扫码两张卡、待办事项五项计数、动态预警与促销横幅，底部五 tab 为 首页 / 入库 / 采购 / 延保 / 我的。
关键交互 —— ①点门店名 → 切换门店（本稿未画下拉箭头，见下方说明）；②点眼睛图标 → 隐藏 / 显示金额类指标（REQ-HOM-011）；③点铃铛 → 进入消息列表，角标清零；④「快速核销-扫码 / 输码」→ 核销流程；⑤「车牌扫码-扫码 / 车牌」→ 接车进销售流程；⑥点待办任一项 → 进对应订单列表；⑦「查看全部」→ 全量预警列表；⑧点促销横幅 → 活动详情；⑨底部 tab 切换模块。
可用角色 —— 店长 ✅ 全量。本稿的金额类分区（预计营收 / 毛利 / 客单价）对技工 ✗，见 4.2.4。
需求关联 —— REQ-HOM-001 门店切换、REQ-HOM-002 问候语、REQ-HOM-003 消息公告、REQ-HOM-005/006 扫码与输码接车、REQ-HOM-007 快速核销、REQ-HOM-008 待办、REQ-HOM-009 动态预警、REQ-HOM-011 今日经营卡片
本稿的三处状态缺失（属设计稿补稿，不新增需求）：①门店名旁未画下拉箭头，而功能宫格版画了
▾—— 切店器的表现形式两版不一致，随 REQ-HOM-001 统一；②动态预警角标写「2 项待处理」，但列表区只画了 1 条（低库存），第 2 条未画；③金额隐藏后的形态（打码还是留空）未画。
页面内容 —— 技工首页目标形态，头部无门店名与铃铛、橙色卡改为「今日已完工 8 单」且不含任何金额，快速核销与车牌扫码两张卡同店长版，其下是技工独有的「当前施工队列（共 2 单）」工单卡，底部五 tab 与店长版一致。
关键交互 —— ①「查看绩效明细」→ 技工个人绩效页（该页无设计稿）；②「开始施工」→ 工单转「安装中」；③「完工并结算」→ 结算（去 F6 结算页还是 App 内页未定 TODO(REQ-HOM-012)）；④快速核销与车牌扫码同店长版。本稿未画消息铃铛、待办事项、动态预警、促销位。
可用角色 —— 技工 ✅。「当前施工队列」为技工独有，店长 ✗。技工是否应有消息 / 待办 / 预警三个分区，业务需求说有、本稿未画 —— TODO(REQ-HOM-003) / TODO(REQ-HOM-008) / TODO(REQ-HOM-009)。
需求关联 —— REQ-HOM-011（技工只看完工单数，本稿是该规则的直接落地）、REQ-HOM-012 当前施工队列
卡片一的施工内容写作「更正品查验 + 动平衡 + 轮胎号延保绑定」，疑为「更换 / 正品查验」的文案笔误，补稿时一并核对。
页面内容 —— 首页备选方案（对应三版底部导航的方案 C），自上而下为内嵌核销码输入框的橙色头部、限时活动三张商品卡、待办事项五项计数、八宫格功能入口与经营业绩区（四个时间 tab + 三项指标，数值为占位），底部五 tab 为 首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心。
关键交互 —— ①输核销码 → 点「核销」直接核销（比店长版少一步进卡片）；②「限时活动-更多」→ 活动列表；③点商品卡 → 目标未定，见 REQ-HOM-016；④点八宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）任一 → 进对应模块；⑤切换当日/当周/当月/当季 → 刷新经营指标；⑥「经营业绩-更多」→ 经营报表。
可用角色 —— 本稿未区分角色，仅作导航方案备选。若采用，需补技工版 —— 稿中「经营业绩」含 O2O 成交金额，属金额类，对技工应不可见（TODO(REQ-PRF-001)）。
需求关联 —— REQ-HOM-010 角色化导航（本稿即方案 C 的实体）、REQ-HOM-007 快速核销、REQ-HOM-016 促销位形态与来源
本稿与店长版的两处口径不一致，需在 REQ-HOM-008 / REQ-HOM-016 一并裁决：①待办首项，店长版写「待接单」、本稿写「待订单」；②促销位，店长版是底部活动横幅、本稿是顶部三商品卡、技工版没有 —— 三版稿画了三种形态；且本稿三张商品卡直接用了京东站内推广创意（可见「京东JOY」「JD.COM」「爱奇艺」等第三方水印），正式稿须换成马牌自有素材。
4.2.1 需求描述
业务目标 —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏，让门店开工第一眼就知道「今天有什么要做、有什么要盯」，解决痛点 2.1 与 2.5
目标角色 —— 店长、技工（内容差异见 4.2.3、4.2.4）
入口 —— 登录成功后默认落地；任意页面点击底部「首页」tab
前置条件 —— 已登录且已确定当前门店上下文
主流程：
- 进入首页
- 并行拉取门店信息、待办、预警、促销、经营卡片
- 分区渲染，任一分区失败不阻塞其它分区
- 用户点击分区进入对应模块
异常流程：
- 单个数据源超时/失败 → 该卡片显示占位与「重试」，其余正常展示（局部降级，见《后端跨域协作与聚合文档》）
- 门店未接 F6 → 隐藏依赖 F6 的分区与 tab
- 无待办 → 显示空态而非隐藏分区
业务规则 —— 见 4.2.6
权限规则 —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发，客户端不硬编码，见 4.2.5
访问链路 —— App → App Backend（聚合）→ 并行 fan-out 至 O2O / ROOS / 延保 / CDMS / F6
逻辑数据来源 —— 见 4.2.7
回写目标 —— 消息已读状态回写 App Backend；其余为只读聚合
状态变化 —— 消息：未读 → 已读；待办项计数随源系统单据状态变化
验收标准 —— 见 4.2.8
4.2.2 现状导航与目标导航的差异
整合前，三套小程序各带一套底部导航，且互相之间用「首页放友链」的方式跳转（见 2.7.1）。整合后全部小程序 tabbar 一律废弃，App 只保留一套底部导航。
| 现状入口 | 现状位置 | App 归属 |
|---|---|---|
| ROOS 首页 / 商品 / 购物车 | ROOS tabbar | 合并进「采购」tab（4.6） |
| ROOS 我的 | ROOS tabbar | 拆分：账务类进「我的」（4.8），对账单进财务，业绩进经营业绩 |
| ROOS 扫码出库 / 扫码入库 | ROOS 首页 | 「入库」tab（4.7） |
| O2O 核销码输入 + 核销 | O2O 首页顶部 | 首页「快速核销」卡片 |
| O2O 订单管理五状态 | O2O 首页 | 首页「待办事项」+ 4.3 销售的订单列表 |
| O2O 两组功能宫格（13 项） | O2O 首页 | 分派至 4.9 / 4.10 / 4.11 / 4.12 / 4.13 |
| 延保 首页 / 工作台 / 待办事项 / 我的 | 延保 tabbar | 合并进「延保」tab（4.5） |
| 「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格 | ROOS + O2O 首页 | 取消——整合后无需互跳；其中「积分兑换」保留为 4.14 福利兑换入口 |
现状入口 → App 导航映射
4.2.3 店长首页
自上而下分区（见本节店长首页设计稿）：
一、门店切换
当前用户旗下如果有多家店，可以通过顶部的下拉选择项切换至不同的门店。切换后所有业务数据按新门店重新加载。
二、问候语
用户成功登录首页后，在左上方展示用户信息以及问候。系统读取当前用户的姓氏、角色以及当前时间段，整合成合适的问候语，如「张店长，上午好」。
三、消息公告
右上角铃铛图标的角标展示当前未读消息条数；点击图标以列表形式展示系统站内信；点击后角标数字消失。促销信息展示往期马牌的所有促销活动；通知消息由管理员在后台管理平台发布。
页面内容 —— ROOS 小程序「公告列表」页，本图为空态（「暂无公告」占位），故公告条目的字段构成无法从本图确认。
关键交互 —— ①左上返回；②有数据时点条目进详情（本图无法确认）。本页除返回外无任何筛选、搜索或标记已读的控件。
可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-HOM-003)。ROOS 侧现状不区分角色。
需求关联 —— REQ-HOM-003 消息公告、REQ-HOM-004 促销信息（往期促销即在本列表中承载）
页面内容 —— O2O 接单宝「消息」页，按日期分组的卡片流，本图可见的消息全部是同一类（【门店违规】提醒），且最新一条已是 2023-04-13。
关键交互 —— ①上下滑动按日期倒序浏览。未见已读标记、删除、分类筛选或点击进详情的控件 —— 本页是纯只读消息流。
可用角色 —— 店长 ✅（违规会导致「禁止接单」，属店长必须知悉的治理类消息）；技工 ❓ TODO(REQ-HOM-003)。
需求关联 —— REQ-HOM-003。本图是「消息分类体系」这条待确认的核心证据：O2O 侧是会阻断经营的治理类消息，ROOS 侧是促销与通知类公告，两者的紧急程度、是否需强提醒、能否删除完全不同，合并进一个消息中心时必须分类承载。本图的违规原因样例为「车牌号已超出年度最大下单量」「同一手机号下多笔订单超过限制数量」「门店单日销量超过限制数量」，均由风控规则触发，正文写「门店触发违规条件，已被禁止接单」并附「如有异议，请联系门店相应的销售代表」。
现状消息分散在 ROOS「公告」与 O2O「消息」两处，且类型不同（ROOS 为促销/通知公告，O2O 含门店违规提醒等治理类消息）。整合后需在一个消息中心内分类承载 —— 消息分类体系
TODO(REQ-HOM-003)。补充：附录 A.2 已定义消息列表「支持查看、标记已读、删除」，但上面两张现状图都没有这三个控件 —— 这三项是 App 的新增能力，不是现状迁移，开发时需明确它们作用于哪一侧数据（App 自有消息表还是回写 ROOS / O2O）。
四、促销信息
提醒用户当前马牌轮胎有促销活动，系统展示马牌最近一次举行的促销活动；点击促销区域展示具体活动内容。促销活动内容来自 ROOS 提供的接口；APP 后台定时调用促销活动接口，拉取促销信息并推至用户首页；往期促销信息在右上角铃铛对应的列表页中展示。
设计稿中该区域为首页底部的横幅广告位（「马牌高端系列 买三送一」）。
⚠️ 三版设计稿对促销位画了三种形态 —— 形态与来源需一并裁决，见 REQ-HOM-016。
五、扫码接车
当客户车开进马牌门店时，用户可以直接点击「扫码」按钮，对准客户车头识别车辆号牌，进入销售流程。
扫码由 App 原生能力实现（
native_scan），非 F6 提供的扫码页，见 C5。车牌识别走云端 OCR 服务：拍一张照上传识别，不是取景框里的实时识别，因而依赖网络——「输码」不是失败后的降级，而是与「扫码」并列的常驻入口。见第 10 章风险 R9。
六、输码
在做客户接车时，因特殊原因无法正确通过「扫码」识别客户车牌时，可以通过「车牌」按钮手工输入客户的车辆号牌，进入销售流程。
七、快速核销
设计稿在「车牌扫码」之外并列了一组「快速核销」（扫码 / 输码），对应 O2O 接单宝首页顶部的核销码输入框 —— 消费者到店出示线上订单核销码，门店扫码或手工输码完成核销。
扫码核销的详细流程待确认 ——
TODO(REQ-SAL-010)，详见 4.3.4。
八、待办事项
待办事项在首页中扮演用户助手的角色，方便用户随时查看自己的工作列表。每项提醒的上方显示该项对应的待办事项总数。
现有两套并存的待办口径，两者不冲突，是两个层次：
| 层次 | 项目 | 来源 | 说明 |
|---|---|---|---|
| 跨系统提醒（业务层） | O2O 订单接单提醒、CDMS 采购单支付提醒、延保视频上传提醒、问卷提醒、过期门店信息更新提醒 | O2O / CDMS / 延保 / 待定 | 按来源系统聚合的业务提醒 |
| 订单流转状态（单据层） | 待接单、待调货、待安装、待配送、待服务 | O2O 订单管理 | 设计稿口径；对应 O2O 现状的「待接订单 / 调货中 / 待安装 / 待配送 / 配送中」 |
待办事项两层口径
设计稿的五项与 O2O 现状五状态一一对应但措辞不同（「待调货」vs「调货中」、「待服务」vs「配送中」）。首页最终展示哪一层、或两层如何合并展示 ——
TODO(REQ-HOM-008)，见 C2。补充：措辞不一致不止存在于「设计稿 vs O2O 现状」，两版设计稿之间也不一致 —— 店长版首项写「待接单」，功能宫格版写「待订单」。取哪一套措辞随本条一并定稿。
九、动态预警
动态预警在首页中扮演用户管家的角色，随时帮用户检查目标任务达成情况、库存数量预警、时效订单预警等。系统按紧急程度在动态预警右边展示需要及时处理的事件数量，并提供「查看全部」入口浏览所有需要及时处理的事件。
预警项全集：
| 预警项 | 数据来源 | 备注 |
|---|---|---|
| 总预警数 | APP 后台计算 | 各项之和 |
| 月度签约达成预警 | TODO(REQ-HOM-009) |
达成口径与阈值待定 |
| 库存预警（低库存） | F6 | ⚠️ 未接 F6 不显示此项；设计稿示例为「低库存 马牌 205/55R16 剩余 5 条」 |
| 时效订单预警 | O2O | 临近履约时限的订单 |
动态预警项
各项预警的触发阈值（如低库存的条数门槛、时效订单的提前量）均未定义 ——
TODO(REQ-HOM-009)，见 C3。
十、今日经营卡片
设计稿在问候语下方设有营收卡片：今日预计营收（¥34,500）、毛利率（88%）、成交单数（24 单）、客单价（¥1,437），并带「眼睛」图标支持一键隐藏金额。
该卡片仅见于设计稿。「预计营收」的口径（是否含未结算订单、是否含延保与返利、毛利率的成本口径）未定义 ——
TODO(REQ-HOM-011)，见 C8。金额隐藏功能对应痛点 2.2 中「技工可查看门店财务数据」的风险控制诉求。
十一、底部导航
见 4.2.5。
4.2.4 技工首页
技工首页与店长首页的分区差异（见本节技工首页设计稿）：
| 分区 | 店长 | 技工 | 说明 |
|---|---|---|---|
| 门店切换 | ✅ 下拉切换 | ⚠️ 仅显示门店名 | 拥有多门店权限的用户可切换门店；设计稿技工版无门店名与切换器 —— TODO(REQ-HOM-001) 需确认技工是否允许多门店 |
| 问候语 | 「张店长，上午好」 | 「韩师傅 · 技师」 | 设计稿技工版为「姓氏 + 师傅 · 角色」格式，无时段问候 |
| 消息公告 | ✅ 铃铛 + 角标 | ⚠️ 设计稿未出现 | 业务需求中技工应有消息公告 —— TODO(REQ-HOM-003) 需确认 |
| 促销信息 | ✅ | ✅ | 技工可见 |
| 今日经营卡片 | 今日预计营收 / 毛利 / 成交单数 / 客单价 | 今日已完工 N 单 + 「查看绩效明细」 | 技工不可见金额类数据，与痛点 2.2 一致 |
| 快速核销 / 车牌扫码 | ✅ | ✅ | 完全一致 |
| 待办事项 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有待办事项 —— TODO(REQ-HOM-008) |
| 动态预警 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有动态预警 —— TODO(REQ-HOM-009) |
| 当前施工队列 | ❌ | ✅ | 技工独有分区，仅见于设计稿 |
店长 / 技工首页分区差异
上表「促销信息 技工 ✅」与技工版设计稿不符 —— 技工版稿中没有促销位（店长版有底部横幅、宫格版有顶部商品卡）。该行按业务需求填写，实际形态随 REQ-HOM-016 一并确认。
当前施工队列（技工独有）
展示分配给当前技工的施工任务，卡片含：车牌号、订单来源渠道标（天猫订单 / 京东订单）、状态标（安装中 / 待安装）、施工内容（如「更正品查验 + 动平衡 + 轮胎号延保绑定」「更换 马牌 UC6 225/55R17 * 4 条」）、预约时间、主操作按钮（「完工并结算」/「开始施工」）；顶部显示「共 N 单」。
该分区仅见于设计稿。涉及的问题：施工任务如何分派给具体技工？状态机与 F6 工单、O2O 服务单的关系？「完工并结算」跳转到 F6 结算页还是 App 内页？——
TODO(REQ-HOM-012)，见 C13。
4.2.5 导航收敛与角色化配置
收敛原则
- 整合后 App 只有一套底部导航，所有小程序 tabbar 全部废弃；
- tab 集合不在客户端硬编码，由 App Backend 在登录/切店后下发；
- 下发依据为 角色（店长 / 技工）× 门店能力（是否接 F6、是否开通延保等）；
- 客户端对未知 tab code 做忽略处理，保证后端可灰度增删 tab 而不强制发版。
三版 tab 方案
| 方案 | tab 集合 | 来源 |
|---|---|---|
| A（业务菜单版） | 首页 / 库存 / 采购 / 我的 | 业务需求「用户主菜单」 |
| B（主设计稿） | 首页 / 入库 / 采购 / 延保 / 我的 | 设计稿 首页-店长、首页-技工、个人中心 |
| C（宫格版） | 首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心 | 设计稿 首页-功能宫格版 |
三版底部导航方案
三者的差别不只是段数：方案 A/B 是「业务动作导向」（去入库、去采购），方案 C 是「管理职能导向」（看门店、看经营、看账务），且方案 C 把业务动作全部收进首页的 8 宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）。
推荐方案：以 B 为基线（业务动作导向更贴合门店高频操作），把 C 的管理职能入口收进「我的」与首页宫格。
⚠️ 各角色的具体 tab 清单尚未确认 ——
TODO(REQ-HOM-010)，见 C1。下表为待确认的建议值：
| tab | 店长 | 技工 | 门店能力依赖 | 对应章节 |
|---|---|---|---|---|
| 首页 | ✅ | ✅ | — | 4.2 |
| 入库 | ✅ | ✅ | — | 4.7 |
| 采购 | ✅ | ⚠️ 授权可见 | — | 4.6 |
| 延保 | ✅ | ✅ | 门店已开通延保 | 4.5 |
| 我的 | ✅ | ✅ | — | 4.8 |
角色化 tab 配置（建议值，待确认）
店长版与技工版两张设计稿的底部导航完全一致（首页 / 入库 / 采购 / 延保 / 我的），即稿中并未体现角色化差异 —— 差异全在页面内容而非 tab 集合。上表把「采购」对技工标为「授权可见」，属建议值，设计稿并未画出技工少一个 tab 的形态。
门店能力开关对导航的影响
已明确一条硬规则：
⚠️ 如果当前用户所在门店未接 F6，「库存」菜单不显示；对技工还需叠加「技工无此权限则不显示」。
推广为通用规则：任一 tab 或首页分区若依赖某外围系统，而当前门店未接入该系统，则该 tab / 分区整体隐藏（而非置灰或点击后报错）。能力开关清单见 7.4。
4.2.6 业务规则
REQ-HOM-001 门店切换 —— 多门店账号可在首页顶部切换门店；切换后级联刷新全部数据，见《App 门店上下文与会话管理文档》
REQ-HOM-002 问候语 —— 由「姓氏 + 角色称谓 + 时段问候」拼接；时段划分口径 TODO(REQ-HOM-002)
REQ-HOM-003 消息公告 —— 角标为未读数；点击进入列表后清零。消息分类体系待定 TODO(REQ-HOM-003)
REQ-HOM-004 促销信息 —— 来源 ROOS 接口，APP 后台定时拉取；首页展示最近一次活动，往期在消息列表
REQ-HOM-005 扫码接车 —— App 原生扫码识别车牌 → 进入销售流程
REQ-HOM-006 输码接车 —— 扫码失败时手工输入车牌 → 进入销售流程
REQ-HOM-007 快速核销 —— 扫核销码或手工输入核销码 → 进入核销流程（4.3.4）
REQ-HOM-008 待办事项 —— 两层口径并存，最终展示形态待定 TODO(REQ-HOM-008)
REQ-HOM-009 动态预警 —— 四项预警，阈值待定 TODO(REQ-HOM-009)；库存预警依赖 F6
REQ-HOM-010 角色化导航 —— tab 集合由后端按角色 + 门店能力下发，清单待定 TODO(REQ-HOM-010)
REQ-HOM-011 今日经营卡片 —— 店长看金额类指标（可隐藏），技工看完工单数；口径待定 TODO(REQ-HOM-011)
REQ-HOM-012 当前施工队列 —— 技工独有；分派规则与状态机待定 TODO(REQ-HOM-012)
REQ-HOM-013 分区降级 —— 任一数据源失败仅该卡片降级，不影响其它分区渲染
REQ-HOM-016 促销位形态与来源 —— 三版设计稿画了三种互不相同的促销位形态（店长版底部通栏横幅、宫格版顶部三商品卡、技工版无），附录 A.2 又写作顶部滚动提示，共四种说法；宫格版素材直接用了第三方电商推广创意，正式稿须换成马牌自有素材。最终形态、数据来源、点击目标与技工可见性均待定 TODO(REQ-HOM-016)
4.2.7 业务数据列表
| # | 字段 | 字段名 | 数据来源 | 说明 |
|---|---|---|---|---|
| 1 | 门店名称列表 | StoreNameList | 马上下单 | 来自马上下单的门店列表 |
| 2 | 用户问候 | GreetingStr | APP Backend | 首页问候语，来自登录后获取的姓名和当前时间 |
| 3 | 消息公告 | Msg2PromotionList | APP 后台 + ROOS | 消息公告来自 APP 后台，促销信息来自 ROOS |
| 4 | 促销信息 | PromotionMsg | ROOS | 来自最新的 ROOS 促销信息 |
| 5 | 待办事项 | TodoList | 多源 | O2O 订单接单提醒：O2O 接口 CDMS 采购单支付提醒：CDMS 接口 延保视频上传提醒：延保接口 问卷提醒： TODO(REQ-HOM-014)过期门店信息更新提醒： TODO(REQ-HOM-015) |
| 6 | 动态预警 | PrecautionIndexList | 多源 | 总预警数：APP 后台计算 月度签约达成预警： TODO(REQ-HOM-009)库存预警：F6（⚠️ 未接 F6 不显示此项） 时效订单预警：O2O |
| 7 | 动态预警查看详情 | PrecautionAllList | 同上 | 全量预警列表 |
| 8 | 今日经营卡片 | TodayBusinessCard | TODO(REQ-HOM-011) |
预计营收 / 毛利率 / 成交单数 / 客单价（店长）；已完工单数（技工） |
| 9 | 当前施工队列 | WorkQueueList | TODO(REQ-HOM-012) |
技工独有；车牌、渠道、状态、施工内容、预约时间 |
| 10 | 底部 tab 配置 | TabConfigList | APP Backend | 按角色 + 门店能力下发 |
APP 首页信息字段
4.2.8 验收标准
- 未接 F6 的门店，登录后底部导航不出现依赖 F6 的 tab，首页不出现库存预警项；
- 多门店店长切换门店后，首页全部分区（待办、预警、经营卡片、促销）均刷新为新门店数据；
- 任意单个上游系统（O2O / CDMS / 延保 / F6）不可用时，首页仍可打开，失败分区显示占位与重试，其余分区正常；
- 技工登录后首页不出现任何金额类经营指标；
- 消息角标数字与消息列表未读条数一致；进入列表后角标归零。
附：本模块归拢信息
以下内容从主文件的其它章节归拢而来，便于本模块独立评审。回灌主文件时不处理本分界线以下的部分——主文件的附录仍是全局视图。
附-1 业务数据字典（主文件附录 A.2）
| # | 数据集 | 来源 | 安全 | 备注 |
|---|---|---|---|---|
| 1 | 切换后的店铺信息集 | App Backend | HTTPS | |
| 2 | 店铺列表结果集（用于切店） | App Backend | HTTPS | |
| 3 | 当前用户的菜单数据集 | App Backend | HTTPS | 即角色化 tab 下发（REQ-HOM-010） |
| 4 | 动态预警 | Mini Program Backend | HTTPS | 来自 ROOS 与 O2O |
| 5 | 促销信息 | Mini Program Backend | HTTPS | 首页顶部滚动提示 |
| 6 | 公告/通知列表（按发布时间倒序） | Mini Program Backend | HTTPS | 支持查看、标记已读、删除 |
| 7 | 待办事项（按优先级/截止时间排序） | Mini Program Backend | HTTPS | 来自 O2O 与延保后台 |
首页模块数据集（摘自主文件附录 A.2）。字段级清单见上方 4.2.7。
第 5 条与设计稿不符：附录 A 写促销信息是「首页顶部滚动提示」，而店长版稿把它画成底部通栏横幅、宫格版画成顶部三商品卡。三处形态互不相同 —— 随 REQ-HOM-016 统一。
第 6 条的三个动作在现状中都不存在：ROOS 公告列表与 O2O 消息页均无「标记已读 / 删除」控件（见 4.2.3 两张现状图）。这三项属 App 新增能力，需明确作用于 App 自有消息表还是回写源系统。
附-2 权限矩阵（主文件附录 B 本模块分行）
图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
|---|---|---|---|
| 门店切换 | ✅ | ❓ | 技工是否允许多门店 TODO(REQ-HOM-001) |
| 消息公告 | ✅ | ❓ | 业务需求说有、设计稿未画 TODO(REQ-HOM-003) |
| 待办事项 | ✅ | ❓ | 同上 TODO(REQ-HOM-008) |
| 动态预警 | ✅ | ❓ | 同上 TODO(REQ-HOM-009) |
| 今日经营卡片（金额类） | 🔸 | ✗ | 店长可隐藏金额；技工仅见完工单数 TODO(REQ-HOM-011) |
| 当前施工队列 | ✗ | ✅ | 技工独有 TODO(REQ-HOM-012) |
首页模块权限矩阵（摘自主文件附录 B）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经人员管理「可用系统」授予（REQ-ACC-005）；🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
本模块权限的特殊之处：四个 ❓ 全部指向「技工能不能看」，且四项都是设计稿未画所致，而非业务上已判定不可见。按 REQ-ACC-006，这四项在关闭前一律实现为技工不可见 —— 也就是说，技工首页首版会是设计稿画的那个精简版。若业务实际期望技工也有待办与预警，需尽早关闭这四条，否则会返工。
附-3 待确认项（主文件 10.2.2）
| 编号 | 待确认内容 | 建议决策方 |
|---|---|---|
| REQ-HOM-001 | 技工是否允许多门店（设计稿技工版无切店器） | 产品 |
| REQ-HOM-002 | 问候语时段划分口径 | 产品 |
| REQ-HOM-003 | 消息分类体系；技工是否有消息公告 | 产品 |
| REQ-HOM-008 | 待办两层口径的最终展示形态（C2）；技工是否有待办 | 产品 |
| REQ-HOM-009 | 四项动态预警的触发阈值（C3）；技工是否有预警 | 业务 |
| REQ-HOM-010 | 各角色的具体 tab 清单（C1，最高优先级） | 产品 |
| REQ-HOM-011 | 「今日预计营收 / 毛利率 / 客单价」口径（C8） | 财务 / 业务 |
| REQ-HOM-012 | 技工「当前施工队列」的分派规则与状态机（C13） | 产品 / 业务 |
| REQ-HOM-014 | 待办中「问卷提醒」的数据来源 | 业务 |
| REQ-HOM-015 | 待办中「过期门店信息更新提醒」的数据来源 | 业务 |
首页模块待确认项（摘自主文件 10.2.2，10 条）
本次拆分新增 1 条（回灌主文件时并入 10.2.2）：
| 编号 | 待确认内容 | 建议决策方 |
|---|---|---|
| REQ-HOM-016 | 首页促销位的形态与来源 —— 三版设计稿画了三种形态、附录 A.2 又是第四种；素材含第三方电商水印；点击目标、数据来源与技工可见性均未定，详见附-5 | 产品 / 业务 |
合计 11 条待确认（原 10 条 + 新增 1 条）。回灌时需同步附录 D.2 的 HOM 行（15 / 10 / 33% → 16 / 11 / 31%）与第 10.2 节总数。
TODO(REQ-HOM-010)是全文最高优先级的待确认项（C1），其落地前提是后台的「APP 配置」粒度TODO(REQ-ADM-002)。两者构成一条链：后台配得出来 → tab 才下发得下去 → 首页才知道画谁的版本。
附-4 配图清单（主文件附录 C 4.2 节）
| 序 | 说明 | 文件 |
|---|---|---|
| 1 | 设计稿-首页（店长）：营收卡 + 双扫码卡 + 待办五项 + 动态预警 + 促销横幅 + 五 tab | ../app-design-images/首页-店长.png |
| 2 | 设计稿-首页（技工）：完工单数卡 + 双扫码卡 + 当前施工队列，无消息/待办/预警 | ../app-design-images/首页-技工.png |
| 3 | 设计稿-首页（功能宫格版，备选方案 C）：核销码输入 + 限时活动三商品卡 + 八宫格 + 经营业绩 | ../app-design-images/首页-功能宫格版.png |
| 4 | 现状-ROOS 公告列表（空态，无已读/删除控件） | ../mini-program-images/ROOS/公告列表-空态.png |
| 5 | 现状-O2O 消息（全部为【门店违规】治理类消息，最新一条 2023-04） | ../mini-program-images/O2O/消息-门店违规提醒.png |
首页模块配图清单，5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1）。说明较主文件附录 C已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
附-5 本次拆分新增发现（待业务确认）
以下 1 条不在主文件现有 15 条 HOM 需求内，是本次逐张核看 5 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-HOM-015 顺延，尚未登记进主文件 10.2.2，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
|---|---|---|---|
| REQ-HOM-016 | 首页促销位的形态与来源：三版设计稿画了三种互不相同的形态 —— 店长版是底部通栏活动横幅（「马牌高端系列 买三送一」），宫格版是顶部「限时活动」三张商品卡（带划线价、「已售 N」、立减券，素材含京东JOY / JD.COM / 爱奇艺水印，属第三方电商推广创意），技工版没有促销位；而主文件附录 A.2 又写作「首页顶部滚动提示」，共四种说法。需裁决：①最终形态；②数据来源是 ROOS 活动接口（REQ-HOM-004 现有口径）还是第三方电商商品位；③若含商品位，点击后去哪（App 内商详 / 跳京东小程序 / 跳 ROOS 采购）；④技工是否可见（4.2.4 差异表写 ✅，但技工版稿没画）。 | 本节图 1 / 2 / 3 + 附录 A.2 | 产品 / 业务 |
本次拆分新增待确认项，1 条
另有三项不需新增编号的观察，已就地记在各图下方：①店长版门店名旁未画切店下拉箭头而宫格版画了（随 REQ-HOM-001 补稿）；②动态预警角标写「2 项待处理」但只画了 1 条（补稿）；③店长版「待接单」与宫格版「待订单」措辞不一致（随 REQ-HOM-008 定稿）。
另有一项数据观察：O2O 消息页最新一条消息的日期是 2023-04-13，距今已超三年，且全部为同一类型。可能是该测试账号无近期消息，也可能是 O2O 消息通道现状本就低频 —— 若属后者，「消息中心」在 App 内的实际价值需重新评估。本图不足以判定，建议向业务核实真实门店的消息量级。