diff --git a/Cend-MiniProgram-Prototype/docs/01-文档导航与实施顺序.md b/Cend-MiniProgram-Prototype/docs/01-文档导航与实施顺序.md
index 7f9edb2..9abc347 100644
--- a/Cend-MiniProgram-Prototype/docs/01-文档导航与实施顺序.md
+++ b/Cend-MiniProgram-Prototype/docs/01-文档导航与实施顺序.md
@@ -12,14 +12,30 @@
- `docs/02-信息架构与路由.md`
- `docs/03-全局业务规则.md`
+### 第一步补充：如果当前目标是重新按租户后台真实能力校正文档
+- 先看 `docs/12-租户管理员功能重构梳理/00-总览.md`
+- 再按批次看 `docs/12-租户管理员功能重构梳理/`
+- 当前已完成批次包括：
+ - `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
+ - `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
+ - `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
+ - `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
+ - `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
+ - `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md`
+ - `docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md`
+- 对已完成批次，以该目录下文档结论优先
+
### 第二步：再理解链路
- `docs/04-核心用户流程.md`
- `docs/05-页面清单总表.md`
-### 第三步：再理解版本与映射
+### 第三步：再理解版本、映射与当前执行顺序
- `docs/08-全周期版本规划与范围分层.md`
- `docs/09-租户后台与C端功能映射总表.md`
- `docs/10-全周期研发实施顺序与交付清单.md`
+- `docs/11-V1.0页面开发执行清单与验收标准.md`
+
+> 如果你发现 `docs/09` 的描述和 `docs/12-租户管理员功能重构梳理/` 已完成批次冲突，以 `docs/12` 为准。
### 第四步：开始搭页面
- `docs/06-通用组件清单.md`
@@ -63,11 +79,18 @@
- 秒杀活动页
- 限时折扣活动页
+如果当前目标是对齐正式 `Taro` 仓库的 `V1.0` 落地顺序，则以：
+- `docs/11-V1.0页面开发执行清单与验收标准.md`
+
+作为更细的页面执行顺序依据。
+
## 4. 文档使用规则
### 4.1 页面规格优先
如果某个页面的单页规格文档与总文档描述不同，以单页规格为准。
+但如果该页面所属范围已经在 `docs/12-租户管理员功能重构梳理/` 中完成重构批次，则以 `docs/12` 的结论优先。
+
### 4.2 结构先于视觉
本套文档优先定义：
- 页面区块顺序
@@ -86,6 +109,10 @@
- `docs/08-全周期版本规划与范围分层.md`
- `docs/09-租户后台与C端功能映射总表.md`
- `docs/10-全周期研发实施顺序与交付清单.md`
+- `docs/11-V1.0页面开发执行清单与验收标准.md`
+
+如果争议来自“旧原型设计”和“后台真实能力”不一致，再优先参考：
+- `docs/12-租户管理员功能重构梳理/`
## 5. 交付标准
@@ -96,4 +123,3 @@
- 每个区块具备文档要求的字段与交互
- 页面具备默认态、空态、异常态、禁用态等必要状态
- 业务对象和后台配置关系清晰可追溯
-
diff --git a/Cend-MiniProgram-Prototype/docs/02-信息架构与路由.md b/Cend-MiniProgram-Prototype/docs/02-信息架构与路由.md
index e11401a..f65c28e 100644
--- a/Cend-MiniProgram-Prototype/docs/02-信息架构与路由.md
+++ b/Cend-MiniProgram-Prototype/docs/02-信息架构与路由.md
@@ -8,10 +8,10 @@
| 编码 | 页面名称 | 路由建议 | 页面层级 | 说明 |
| --- | --- | --- | --- | --- |
-| `T01` | 首页 | `pages/tab/home/index` | Tab | 选店、活动导流、推荐 |
+| `T01` | 首页 | `pages/tab/home/index` | Tab | 当前门店摘要、动态活动导流、推荐 |
| `T02` | 点餐 | `pages/tab/menu/index` | Tab | 商品浏览、加购、结算入口 |
-| `T03` | 订单 | `pages/tab/orders/index` | Tab | 订单列表、履约、售后 |
-| `T04` | 我的 | `pages/tab/me/index` | Tab | 资产、消息、服务、复购 |
+| `T03` | 订单 | `pages/tab/orders/index` | Tab | 顾客视角订单列表、履约、售后 |
+| `T04` | 我的 | `pages/tab/me/index` | Tab | 身份、资产、服务、复购聚合 |
### 1.2 二级页面
@@ -43,7 +43,7 @@
| `C01` | 商品详情抽屉 | 底部抽屉 / 右滑抽屉 | 点餐页 | 规格、加料、数量选择 |
| `C02` | 购物车抽屉 | 底部抽屉 | 点餐页 | 已选商品清单 |
| `C03` | 登录授权弹层 | 中央弹窗 / 底部弹层 | 全局 | 订单与资产前拦截 |
-| `C04` | 优惠选择弹层 | 底部抽屉 | 结算页 | 券、积分、余额选择 |
+| `C04` | 手动资产选择弹层 | 底部抽屉 | 结算页 | 优惠券、余额、次卡选择 |
| `C05` | 支付方式弹层 | 底部抽屉 | 结算页 | 微信支付 / 余额支付 |
| `C06` | 地址选择抽屉 | 底部抽屉 | 结算页 | 快捷切换地址 |
@@ -70,17 +70,34 @@
## 4. 页面显示规则
### 4.1 Tab 页面
+
- 保持底部 TabBar 可见
- 顶部导航不显示返回按钮
- 页面滚动位置可按产品需要保留
### 4.2 二级页面
+
- 显示顶部导航和返回按钮
- 进入后覆盖当前 Tab 内容
- 返回时回到来源页面
### 4.3 抽屉与弹层
+
- 不应中断当前页面上下文
- 应支持手势关闭 / 点击遮罩关闭（支付与关键确认除外）
- 关闭后保留当前页面已选状态
+## 5. 当前使用规则
+
+- 如 `docs/07-页面规格/` 与本文件冲突，以单页规格为准
+- 如 `docs/12-租户管理员功能重构梳理/` 已完成批次与本文件冲突，以 `docs/12` 为准
+- 当前已冻结的关键边界包括：
+ - 首页活动区是动态精选，不是固定八宫格
+ - 场景切换必须受门店 `serviceTypes` 约束
+ - 结算页手动资产选择当前只确认：
+ - 优惠券
+ - 余额
+ - 次卡
+ - `积分抵扣` 当前不作为已冻结结算能力
+ - 消息中心页当前保留页面职责，但未冻结完整 inbox 结构
+
diff --git a/Cend-MiniProgram-Prototype/docs/03-全局业务规则.md b/Cend-MiniProgram-Prototype/docs/03-全局业务规则.md
index da56526..d219ca0 100644
--- a/Cend-MiniProgram-Prototype/docs/03-全局业务规则.md
+++ b/Cend-MiniProgram-Prototype/docs/03-全局业务规则.md
@@ -3,20 +3,24 @@
## 1. 用户身份与登录
### 1.1 可匿名浏览的范围
+
- 首页
- 门店选择页
- 点餐页基础浏览
- 商品详情查看
+- 活动会场基础浏览
### 1.2 必须登录 / 绑定手机号的动作
+
- 提交订单
-- 使用优惠券、积分、储值、次卡
+- 使用优惠券、余额、次卡
- 查看“我的”资产
-- 查看消息中心
+- 查看订单与售后
- 提交退款申请
- 提交评价
### 1.3 登录拦截方式
+
- 优先使用 `C03 登录授权弹层`
- 拦截后登录成功，应返回原业务场景继续执行
@@ -31,11 +35,14 @@
| `dine_in` | 堂食扫码 | 需要门店和桌号 |
### 2.2 门店选择规则
+
- 顾客必须在“某一家门店”下点单
- 同一时间购物车只属于一个门店 + 一个场景
-- 切换门店时，应提示当前购物车可能清空
+- 场景切换必须受门店真实 `serviceTypes` 约束
+- 切换门店或切换场景时，应提示当前购物车可能清空
### 2.3 堂食规则
+
- 堂食优先由扫码进入
- 扫码后自动识别门店与桌号
- 堂食场景默认不展示配送地址与配送费模块
@@ -43,7 +50,9 @@
## 3. 商品与价格规则
### 3.1 商品展示规则
+
- 商品按分类展示
+- 商品与类目展示必须按当前场景过滤
- 支持热销、招牌、新品、推荐等标签
- 商品在以下情况下显示不可售：
- 售罄
@@ -52,13 +61,17 @@
- 当前场景不可售
### 3.2 SKU 与规格规则
+
- 规格做法与加料均在商品详情抽屉中完成
- 当商品启用多规格时，价格与库存以 SKU 为准
+- 简单商品可直接加购
+- 套餐商品必须先完成套餐组选择
- 如果规格变化导致库存不足，应立即提示
### 3.3 费用结构
结算时至少展示以下金额项：
+
- 商品金额
- 打包费
- 餐具费
@@ -73,62 +86,88 @@
| 类型 | 说明 |
| --- | --- |
| 优惠券 | 满减券、折扣券、免配送费券 |
-| 积分 | 获取、抵扣、兑换 |
+| 积分 | 获取、兑换；是否支持订单抵扣当前不冻结 |
| 储值余额 | 充值后可支付订单 |
| 次卡 | 对特定商品或分类核销 |
| 会员等级 | 折扣、积分倍率、生日权益、会员日权益 |
-### 4.2 资产使用原则
-- 顾客端只负责展示可用资产和命中结果
+### 4.2 使用原则
+
+- 顾客手动选择的资产当前只确认：
+ - 优惠券
+ - 余额
+ - 次卡
+- 自动命中的结果当前主要包括：
+ - 满减
+ - 新客优惠
+ - 会员折扣
+ - 免配送费
- 具体叠加、互斥、优先级由后台规则决定
- 若资产不可用，必须给出原因说明
### 4.3 典型不可用原因
+
- 未达到金额门槛
- 不适用当前门店
- 不适用当前场景
- 不适用当前商品
- 已过期
- 已使用
+- 余额不足
## 5. 订单状态规则
-### 5.1 订单状态定义
+### 5.1 顾客视角状态分组
-| 状态值 | 中文名称 | 说明 |
-| --- | --- | --- |
-| `pending_pay` | 待支付 | 已提交订单，未完成支付 |
-| `paid_wait_accept` | 已支付待接单 | 等待商家处理 |
-| `preparing` | 制作中 | 商家已接单，正在备餐 |
-| `delivering` | 配送中 | 外卖场景履约中 |
-| `wait_pickup` | 待自提 | 自提场景等待到店取餐 |
-| `dine_in_serving` | 堂食进行中 | 堂食场景订单进行中 |
-| `finished` | 已完成 | 订单已履约完成 |
-| `refunding` | 退款中 | 售后处理中 |
-| `refunded` | 已退款 | 退款已完成 |
-| `closed` | 已关闭 | 超时取消或主动取消 |
+订单页顶层统一使用顾客任务语言：
+
+- 全部
+- 待支付
+- 进行中
+- 已完成
+- 售后
+
+### 5.2 顾客可感知的细分状态
+
+- 商家处理中
+- 制作中
+- 配送中
+- 待取餐
+- 已完成
+- 退款中
+- 已退款
+- 已取消
+
+### 5.3 订单动作与状态对应
-### 5.2 订单动作与状态对应
- `待支付`：可继续支付、取消订单
-- `已支付待接单 / 制作中`：可查看详情、催单、部分场景可申请退款
-- `配送中 / 待自提 / 堂食进行中`：可查看履约信息
+- `进行中`：以查看详情和查看履约信息为主
- `已完成`：可评价、再来一单
-- `退款中 / 已退款`：可查看退款详情
+- `售后`：可查看退款详情
+- `已取消` 等结果态：以查看信息为主
-## 6. 消息通知规则
+当前不把以下能力冻结为所有订单的固定动作：
-### 6.1 消息分类
+- 催单
+- 取餐码查看
+- 骑手轨迹
-| 类型 | 内容范围 |
-| --- | --- |
-| 订单消息 | 支付成功、接单、出餐、配送、退款处理 |
-| 营销消息 | 发券提醒、活动开始、会员日提醒 |
-| 系统通知 | 门店公告、规则更新、服务通知 |
+## 6. 消息与服务规则
-### 6.2 消息行为
-- 未读消息需要角标或红点提示
-- 进入消息详情或打开消息中心后，消息可置为已读
-- 消息应能跳转到对应业务页面
+### 6.1 消息中心边界
+
+- `P16 消息中心页` 当前保留页面职责
+- 当前已知后台事实源更接近“运营发送中心”，不是顾客 inbox
+- 因此下列能力暂不冻结为正式前台契约：
+ - 完整消息分类
+ - 未读 / 已读状态流转
+ - 消息点击跳转规则
+ - 消息角标数量
+
+### 6.2 帮助中心边界
+
+- `P17 帮助中心页` 当前作为服务兜底页保留
+- FAQ 分类、帮助文章 CMS、在线客服、电话客服等动态能力当前不冻结
## 7. 页面通用状态
@@ -141,13 +180,15 @@
- 网络重试态
### 7.1 典型空态
+
- 无门店可选
- 当前分类无商品
-- 无可用优惠券
+- 无可见券模板
- 无历史订单
-- 无消息
+- 暂无可展示消息
### 7.2 典型错误态
+
- 网络异常
- 定位失败
- 支付失败
@@ -161,4 +202,5 @@
- 结算相关页面必须把金额明细解释清楚
- 场景切换、门店切换、地址切换属于高风险动作，需要在必要时提示购物车清空
- 同一页面的主要操作按钮文案要稳定，不同页面不要频繁变形
+- 活动页必须导流回商品、购物车、结算主链路，不单独生长成一套交易系统
diff --git a/Cend-MiniProgram-Prototype/docs/04-核心用户流程.md b/Cend-MiniProgram-Prototype/docs/04-核心用户流程.md
index 97f9482..7cd65ef 100644
--- a/Cend-MiniProgram-Prototype/docs/04-核心用户流程.md
+++ b/Cend-MiniProgram-Prototype/docs/04-核心用户流程.md
@@ -1,113 +1,241 @@
# 核心用户流程
+- 文档目标：把顾客在小程序中的核心路径梳理成稳定流程，供页面设计、路由设计、状态设计和验收使用。
+- 使用边界：本文件描述的是“顾客流程”，不是“商家后台流程”，也不是“后端字段清单”。
+
+---
+
## 1. F01 外卖下单流程
### 流程目标
-让用户从“选门店”顺利进入“外卖点餐”，完成地址校验、优惠结算和支付。
-### 流程步骤
-1. 用户进入首页
-2. 系统尝试定位并推荐最近门店
-3. 用户确认或切换门店
-4. 用户选择 `外卖` 场景
-5. 用户进入点餐页浏览商品
-6. 用户打开商品详情抽屉选择规格、加料、数量
-7. 用户加入购物车
-8. 用户打开购物车并点击去结算
-9. 进入结算确认页
-10. 选择或新增配送地址
-11. 系统校验配送范围、起送价、配送费
-12. 用户选择优惠券 / 积分 / 储值等资产
-13. 用户确认金额并支付
-14. 进入支付成功页
-15. 跳转订单详情查看履约进度
+让顾客从进入小程序开始，完成门店确认、外卖点餐、地址确认、结算支付和订单查看。
+
+### 主流程
+
+1. 顾客进入首页。
+2. 系统展示当前门店和可用场景。
+3. 顾客确认当前门店，或进入门店选择页切店。
+4. 顾客切换到 `外卖` 场景。
+5. 顾客进入点餐页浏览分类和商品。
+6. 简单商品直接加购，复杂商品进入商品详情抽屉选择规格或组合。
+7. 顾客打开购物车抽屉确认已选商品。
+8. 顾客进入结算确认页。
+9. 顾客选择或新增配送地址。
+10. 系统展示配送相关校验结果和金额试算结果。
+11. 顾客确认手动资产选择：
+ - 优惠券
+ - 余额
+ - 次卡
+12. 系统展示自动优惠命中结果：
+ - 满减
+ - 新客优惠
+ - 会员折扣
+ - 免配送费
+13. 顾客确认订单并支付。
+14. 进入支付成功页。
+15. 顾客进入订单页或订单详情页查看状态。
### 核心判断点
-- 地址是否在配送范围内
-- 是否达到起送门槛
-- 优惠是否可用
-- 当前门店是否营业
+
+- 当前门店是否支持外卖。
+- 地址是否有效，是否需要补全。
+- 配送范围、配送费、起送条件是否满足。
+- 简单商品和复杂商品是否走了正确加购路径。
+- 结算页是否区分了手动资产和自动优惠。
+
+### 当前冻结边界
+
+- `积分抵扣` 当前不作为已冻结结算能力写入主流程。
+- 支付方式页面表达当前只先冻结为 `微信支付` 和 `余额支付`。
+
+---
## 2. F02 自提下单流程
### 流程目标
-让用户选择门店和自提时间，完成到店取餐订单。
-### 流程步骤
-1. 用户进入首页或点餐页
-2. 选择 `自提` 场景
-3. 浏览商品并加入购物车
-4. 进入结算确认页
-5. 选择自提时间段
-6. 填写取餐人信息
-7. 使用优惠资产
-8. 完成支付
-9. 支付成功页展示取餐时间与取餐入口
-10. 订单详情页展示取餐码和门店信息
+让顾客在当前门店支持自提时，完成自提场景下的点餐、结算和支付。
+
+### 主流程
+
+1. 顾客进入首页或点餐页。
+2. 顾客确认当前门店支持 `自提`。
+3. 顾客切换到 `自提` 场景。
+4. 顾客浏览商品并完成加购。
+5. 顾客进入购物车抽屉确认商品。
+6. 顾客进入结算确认页。
+7. 页面展示自提门店信息和自提场景说明。
+8. 顾客确认联系人信息、备注信息和可用资产。
+9. 系统展示自动优惠命中结果和应付金额。
+10. 顾客完成支付。
+11. 进入支付成功页。
+12. 顾客进入订单详情页查看订单状态和取餐说明。
### 核心判断点
-- 当前门店是否支持自提
-- 所选时间段是否可预约
-- 是否满足活动与优惠使用条件
+
+- 当前门店是否支持自提。
+- 自提场景下是否错误要求顾客填写配送地址。
+- 结算页是否正确展示自提门店信息而不是外卖地址卡。
+
+### 当前冻结边界
+
+- 自提后续展示要以“顾客下一步怎么做”为中心，不把商家后台履约动作直接搬到顾客端。
+- `取餐码` 当前不作为所有版本都必须先写死的固定能力。
+
+---
## 3. F03 堂食扫码点餐流程
### 流程目标
-让顾客通过扫码快速绑定桌号，进入堂食点餐和加菜流程。
-### 流程步骤
-1. 用户扫码进入小程序
-2. 进入堂食扫码确认页
-3. 系统展示门店、桌号、当前桌台信息
-4. 用户确认进入堂食点餐
-5. 点餐页切换为 `堂食` 场景
-6. 用户选择商品、规格、加料并加入购物车
-7. 进入结算确认页
-8. 页面默认带出堂食门店与桌号
-9. 用户确认订单并支付
-10. 订单详情展示桌号和堂食状态
-11. 用户可再次进入点餐页继续加菜
+让顾客通过扫码进入堂食上下文，确认桌台后开始点餐，并在后续可以继续加菜。
+
+### 主流程
+
+1. 顾客扫码进入小程序。
+2. 系统进入堂食扫码确认页。
+3. 页面展示门店、桌台或扫码结果信息。
+4. 顾客确认进入堂食点餐。
+5. 系统切换当前场景为 `堂食`。
+6. 顾客进入点餐页浏览商品并完成加购。
+7. 顾客进入购物车抽屉和结算确认页。
+8. 结算页展示堂食桌台信息和堂食场景说明。
+9. 顾客完成支付。
+10. 支付成功页和订单详情页展示当前订单结果。
+11. 顾客需要继续加菜时，再次回到点餐页。
### 核心判断点
-- 桌号是否有效
-- 当前桌是否可继续点单
-- 当前场景是否需要合单或追加订单展示
-## 4. F04 售后与评价流程
+- 扫码结果是否有效。
+- 当前门店是否支持堂食。
+- 堂食上下文是否能从确认页稳定带到点餐页和结算页。
+
+### 当前冻结边界
+
+- 当前优先冻结的是“扫码确认 + 桌台上下文 + 进入堂食点餐”。
+- 是否需要合单、追加单、更多桌台状态，不在当前最小冻结范围内。
+
+---
+
+## 4. F04 订单查看与结果承接流程
### 流程目标
-让用户在订单完成后可以评价，在履约异常时可以申请退款。
-### 流程步骤 A：退款
-1. 用户进入订单详情页
-2. 点击申请退款
-3. 进入退款申请页
-4. 填写退款原因与说明
-5. 提交退款申请
-6. 跳转退款详情页查看处理状态
+让顾客在支付后能快速找到订单、理解当前状态，并进入下一步操作。
-### 流程步骤 B：评价
-1. 用户进入订单详情页
-2. 点击去评价
-3. 进入评价页
-4. 选择星级、输入评价、上传图片、选择匿名
-5. 提交评价
-6. 评价成功后返回订单详情或订单列表
+### 主流程
-## 5. F05 会员与资产流程
+1. 顾客支付完成后进入支付成功页。
+2. 页面展示订单摘要和当前场景关键信息。
+3. 顾客可选择：
+ - 查看订单详情
+ - 进入订单页
+ - 继续点餐
+4. 顾客进入订单页查看自己的订单列表。
+5. 顾客按顾客视角状态筛选订单。
+6. 顾客进入订单详情页查看订单状态、商品清单、费用明细和下一步动作。
+
+### 核心判断点
+
+- 支付成功页是否具备稳定回流路径。
+- 订单页状态表达是否是顾客语言。
+- 订单详情页是否能解释“订单当前走到哪一步”。
+
+### 当前冻结边界
+
+- 订单页不直接照搬商家后台看板列。
+- 商家动作不属于顾客端页面。
+- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定必做按钮写死。
+
+---
+
+## 5. F05 售后与评价流程
### 流程目标
-让用户在“我的”中查看和使用所有可用资产，并引导复购。
-### 流程步骤
-1. 用户进入我的页
-2. 查看会员等级、优惠券、积分、储值、次卡摘要
-3. 按需进入二级页面
- - 领券中心
- - 会员中心
- - 积分商城
- - 储值充值
+让顾客在订单完成或异常时，能够进行最小售后申请和评价反馈。
+
+### 子流程 A：退款
+
+1. 顾客进入订单详情页。
+2. 在符合条件时点击申请退款。
+3. 进入退款申请页。
+4. 选择退款原因并补充说明。
+5. 提交退款申请。
+6. 进入退款详情页查看当前状态和结果。
+
+### 子流程 B：评价
+
+1. 顾客进入订单详情页。
+2. 在符合条件时点击去评价。
+3. 进入评价页。
+4. 顾客选择星级并填写评价内容。
+5. 提交评价。
+6. 页面回流到订单详情页或订单页。
+
+### 核心判断点
+
+- 退款入口是否只在合适状态下出现。
+- 退款结果页是否能讲清当前处理结果。
+- 评价流程是否保持最小闭环，不过早叠加复杂玩法。
+
+---
+
+## 6. F06 我的、资产与复购流程
+
+### 流程目标
+
+让顾客在“我的”页看到自己的身份、资产、订单入口和服务入口，并回流到交易链路。
+
+### 主流程
+
+1. 顾客进入我的页。
+2. 页面展示用户头部信息。
+3. 页面展示资产摘要和订单快捷入口。
+4. 顾客按需进入以下二级页面：
+ - 会员中心页
+ - 积分商城页
+ - 储值充值页
- 次卡页
-4. 用户领取、充值、兑换或购买资产
-5. 返回点餐页或结算页使用资产
+5. 顾客完成查看、充值、兑换或购买后回流到点餐页或结算页。
+### 核心判断点
+
+- 我的页是否保持“聚合页”定位。
+- 资产页是否能回流到交易链路，而不只是静态展示。
+- 是否把不稳定数量字段过早写成强依赖。
+
+### 当前冻结边界
+
+- 我的页不是资产真源页。
+- 优惠券数、未读消息数、次卡实例数等当前不先冻结为强依赖字段。
+
+---
+
+## 7. F07 活动导购流程
+
+### 流程目标
+
+让顾客通过活动页进入标准交易链路，而不是停留在孤立活动页面。
+
+### 主流程
+
+1. 顾客在首页、点餐页或我的页看到活动入口。
+2. 顾客进入以下活动导购页之一：
+ - 领券中心页
+ - 秒杀活动页
+ - 限时折扣活动页
+3. 顾客查看活动规则和活动商品。
+4. 顾客进入商品详情抽屉或点餐页加购。
+5. 顾客进入购物车、结算和支付流程。
+
+### 核心判断点
+
+- 活动是否真正导流到点餐和结算。
+- 活动页是否绕开了标准交易主链路。
+
+### 当前冻结边界
+
+- 当前值得独立页面承接的活动只冻结为 `领券中心 / 秒杀 / 限时折扣`。
+- 满减和新客优惠当前主要在结果区表达，不先扩成重页面。
diff --git a/Cend-MiniProgram-Prototype/docs/05-页面清单总表.md b/Cend-MiniProgram-Prototype/docs/05-页面清单总表.md
index 403d21a..28d04ba 100644
--- a/Cend-MiniProgram-Prototype/docs/05-页面清单总表.md
+++ b/Cend-MiniProgram-Prototype/docs/05-页面清单总表.md
@@ -2,71 +2,90 @@
## 1. 页面总表
-| 编码 | 页面名称 | 层级 | 优先级 | 场景 | 规格文件 |
-| --- | --- | --- | --- | --- | --- |
-| `T01` | 首页 | Tab | P0 | 全场景 | `docs/07-页面规格/01-Tab-首页.md` |
-| `T02` | 点餐页 | Tab | P0 | 外卖 / 自提 / 堂食 | `docs/07-页面规格/02-Tab-点餐页.md` |
-| `T03` | 订单页 | Tab | P0 | 全场景 | `docs/07-页面规格/03-Tab-订单页.md` |
-| `T04` | 我的页 | Tab | P0 | 全场景 | `docs/07-页面规格/04-Tab-我的页.md` |
-| `P01` | 门店选择页 | 二级页 | P1 | 全场景 | `docs/07-页面规格/05-门店选择页.md` |
-| `P02` | 地址管理页 | 二级页 | P1 | 外卖 | `docs/07-页面规格/06-地址管理页.md` |
-| `C01` | 商品详情抽屉 | 抽屉 | P0 | 点餐 | `docs/07-页面规格/07-商品详情抽屉.md` |
-| `C02` | 购物车抽屉 | 抽屉 | P0 | 点餐 | `docs/07-页面规格/08-购物车抽屉.md` |
-| `P03` | 结算确认页 | 二级页 | P0 | 外卖 / 自提 / 堂食 | `docs/07-页面规格/09-结算确认页.md` |
-| `P04` | 支付成功页 | 二级页 | P0 | 全场景 | `docs/07-页面规格/10-支付成功页.md` |
-| `P05` | 订单详情页 | 二级页 | P0 | 全场景 | `docs/07-页面规格/11-订单详情页.md` |
-| `P06` | 退款申请页 | 二级页 | P1 | 订单售后 | `docs/07-页面规格/12-退款申请页.md` |
-| `P07` | 退款详情页 | 二级页 | P1 | 订单售后 | `docs/07-页面规格/13-退款详情页.md` |
-| `P08` | 评价页 | 二级页 | P1 | 已完成订单 | `docs/07-页面规格/14-评价页.md` |
-| `P09` | 领券中心页 | 二级页 | P1 | 会员营销 | `docs/07-页面规格/15-领券中心页.md` |
-| `P10` | 秒杀活动页 | 二级页 | P1 | 营销活动 | `docs/07-页面规格/16-秒杀活动页.md` |
-| `P11` | 限时折扣活动页 | 二级页 | P1 | 营销活动 | `docs/07-页面规格/17-限时折扣活动页.md` |
-| `P12` | 会员中心页 | 二级页 | P1 | 会员 | `docs/07-页面规格/18-会员中心页.md` |
-| `P13` | 积分商城页 | 二级页 | P1 | 积分 | `docs/07-页面规格/19-积分商城页.md` |
-| `P14` | 储值充值页 | 二级页 | P1 | 储值 | `docs/07-页面规格/20-储值充值页.md` |
-| `P15` | 次卡页 | 二级页 | P1 | 次卡 | `docs/07-页面规格/21-次卡页.md` |
-| `P16` | 消息中心页 | 二级页 | P1 | 全场景 | `docs/07-页面规格/22-消息中心页.md` |
-| `P17` | 帮助中心页 | 二级页 | P2 | 全场景 | `docs/07-页面规格/23-帮助中心页.md` |
-| `P18` | 堂食扫码确认页 | 二级页 | P0 | 堂食 | `docs/07-页面规格/24-堂食扫码确认页.md` |
+| 编码 | 页面名称 | 层级 | 优先级 | 主要场景 | 当前定位 | 规格文件 |
+| --- | --- | --- | --- | --- | --- | --- |
+| `T01` | 首页 | Tab | P0 | 全场景 | 当前门店摘要、动态活动导流、推荐 | `docs/07-页面规格/01-Tab-首页.md` |
+| `T02` | 点餐页 | Tab | P0 | 外卖 / 自提 / 堂食 | 商品浏览、活动价表达、加购入口 | `docs/07-页面规格/02-Tab-点餐页.md` |
+| `T03` | 订单页 | Tab | P0 | 全场景 | 顾客视角订单列表、履约、售后 | `docs/07-页面规格/03-Tab-订单页.md` |
+| `T04` | 我的页 | Tab | P0 | 全场景 | 身份、资产、服务、复购聚合页 | `docs/07-页面规格/04-Tab-我的页.md` |
+| `P01` | 门店选择页 | 二级页 | P1 | 全场景 | 切店与当前场景可服务性判断 | `docs/07-页面规格/05-门店选择页.md` |
+| `P02` | 地址管理页 | 二级页 | P1 | 外卖 | 地址管理与配送可用性前置 | `docs/07-页面规格/06-地址管理页.md` |
+| `C01` | 商品详情抽屉 | 抽屉 | P0 | 点餐 | 规格、加料、套餐选择 | `docs/07-页面规格/07-商品详情抽屉.md` |
+| `C02` | 购物车抽屉 | 抽屉 | P0 | 点餐 | 已选商品确认与结算入口 | `docs/07-页面规格/08-购物车抽屉.md` |
+| `P03` | 结算确认页 | 二级页 | P0 | 外卖 / 自提 / 堂食 | 结算确认、手动资产选择、支付前确认 | `docs/07-页面规格/09-结算确认页.md` |
+| `P04` | 支付成功页 | 二级页 | P0 | 全场景 | 支付结果页与后续导流 | `docs/07-页面规格/10-支付成功页.md` |
+| `P05` | 订单详情页 | 二级页 | P0 | 全场景 | 状态解释、履约信息、订单结果 | `docs/07-页面规格/11-订单详情页.md` |
+| `P06` | 退款申请页 | 二级页 | P1 | 订单售后 | 最小售后申请页 | `docs/07-页面规格/12-退款申请页.md` |
+| `P07` | 退款详情页 | 二级页 | P1 | 订单售后 | 退款结果查看页 | `docs/07-页面规格/13-退款详情页.md` |
+| `P08` | 评价页 | 二级页 | P1 | 已完成订单 | 最小评价提交页 | `docs/07-页面规格/14-评价页.md` |
+| `P09` | 领券中心页 | 二级页 | P1 | 活动导购 | 可见券模板聚合与导流 | `docs/07-页面规格/15-领券中心页.md` |
+| `P10` | 秒杀活动页 | 二级页 | P1 | 活动导购 | 强时效秒杀会场 | `docs/07-页面规格/16-秒杀活动页.md` |
+| `P11` | 限时折扣活动页 | 二级页 | P1 | 活动导购 | 限时折扣商品会场 | `docs/07-页面规格/17-限时折扣活动页.md` |
+| `P12` | 会员中心页 | 二级页 | P1 | 会员 | 当前等级、权益、等级说明 | `docs/07-页面规格/18-会员中心页.md` |
+| `P13` | 积分商城页 | 二级页 | P1 | 积分 | 积分余额、可兑换内容、兑换记录 | `docs/07-页面规格/19-积分商城页.md` |
+| `P14` | 储值充值页 | 二级页 | P1 | 储值 | 余额、充值方案、充值记录 | `docs/07-页面规格/20-储值充值页.md` |
+| `P15` | 次卡页 | 二级页 | P1 | 次卡 | 模板说明与使用结果记录 | `docs/07-页面规格/21-次卡页.md` |
+| `P16` | 消息中心页 | 二级页 | P2 | 服务 | 页面职责预留，未冻结完整 inbox | `docs/07-页面规格/22-消息中心页.md` |
+| `P17` | 帮助中心页 | 二级页 | P2 | 服务 | 服务兜底页 | `docs/07-页面规格/23-帮助中心页.md` |
+| `P18` | 堂食扫码确认页 | 二级页 | P0 | 堂食 | 扫码上下文确认与入桌前置页 | `docs/07-页面规格/24-堂食扫码确认页.md` |
## 2. 组件级清单
-| 编码 | 名称 | 优先级 | 规格文件 |
-| --- | --- | --- | --- |
-| `C01` | 商品详情抽屉 | P0 | `docs/07-页面规格/07-商品详情抽屉.md` |
-| `C02` | 购物车抽屉 | P0 | `docs/07-页面规格/08-购物车抽屉.md` |
+| 编码 | 名称 | 优先级 | 当前定位 | 规格文件 |
+| --- | --- | --- | --- | --- |
+| `C01` | 商品详情抽屉 | P0 | 规格、加料、套餐选择 | `docs/07-页面规格/07-商品详情抽屉.md` |
+| `C02` | 购物车抽屉 | P0 | 已选商品确认与结算入口 | `docs/07-页面规格/08-购物车抽屉.md` |
## 3. 推荐实现顺序
-### 第一阶段：交易闭环
+### 第一阶段：交易主链路
+
- `T01` 首页
+- `P01` 门店选择页
+- `P02` 地址管理页
+- `P18` 堂食扫码确认页
- `T02` 点餐页
- `C01` 商品详情抽屉
- `C02` 购物车抽屉
- `P03` 结算确认页
- `P04` 支付成功页
-- `T03` 订单页
-- `P05` 订单详情页
### 第二阶段：履约与售后
+
+- `T03` 订单页
+- `P05` 订单详情页
- `P06` 退款申请页
- `P07` 退款详情页
- `P08` 评价页
-### 第三阶段：资产与增长
+### 第三阶段：我的与资产
+
- `T04` 我的页
-- `P09` 领券中心页
-- `P10` 秒杀活动页
-- `P11` 限时折扣活动页
- `P12` 会员中心页
- `P13` 积分商城页
- `P14` 储值充值页
- `P15` 次卡页
-### 第四阶段：辅助页
-- `P01` 门店选择页
-- `P02` 地址管理页
+### 第四阶段：活动导购
+
+- `P09` 领券中心页
+- `P10` 秒杀活动页
+- `P11` 限时折扣活动页
+
+### 第五阶段：服务与预留页
+
- `P16` 消息中心页
- `P17` 帮助中心页
-- `P18` 堂食扫码确认页
+
+## 4. 当前使用规则
+
+- 本表用于做页面层级、优先级和实现分组总览
+- 单页职责、字段、状态和边界以 `docs/07-页面规格/` 为准
+- 如本表与 `docs/12-租户管理员功能重构梳理/` 冲突，以 `docs/12` 已完成批次结论为准
+- 当前必须记住的几条边界：
+ - `T04` 是聚合页，不是资产真源
+ - `P09` 是券模板导购页，不是“我的优惠券”页
+ - `P10` 和 `P11` 都是导购会场，不能绕开正常商品与结算主链路
+ - `P16` 当前只保留页面职责，不冻结完整消息 inbox
+ - `P17` 当前是服务兜底页，不冻结 FAQ / 客服后台动态能力
diff --git a/Cend-MiniProgram-Prototype/docs/06-通用组件清单.md b/Cend-MiniProgram-Prototype/docs/06-通用组件清单.md
index 34031cb..037f5cc 100644
--- a/Cend-MiniProgram-Prototype/docs/06-通用组件清单.md
+++ b/Cend-MiniProgram-Prototype/docs/06-通用组件清单.md
@@ -1,69 +1,158 @@
# 通用组件清单
-## 1. 说明
+- 文档目标：整理跨页面可复用的 UI 组件和业务组件，避免每个页面重复定义结构，也避免把未来能力过早做成当前刚性组件。
+- 使用方式：页面规格优先定义“页面职责”，本文件定义“可复用部件”；如果两者冲突，以页面职责和全局业务规则为准。
-以下组件建议在实现时先抽象出来，避免每个页面重复拼装。
-页面规格文档会引用这些通用组件。
+---
-## 2. 全局组件
+## 1. 使用原则
-| 编码 | 组件名称 | 用途 | 必备状态 |
-| --- | --- | --- | --- |
-| `G01` | 顶部导航栏 | 二级页面返回、标题展示 | 默认态 |
-| `G02` | 底部 TabBar | Tab 页面切换 | 选中 / 未选中 |
-| `G03` | 页面空态卡片 | 列表为空时提示 | 图标 / 文案 / CTA |
-| `G04` | 页面错误卡片 | 网络错误、加载失败时提示 | 错误文案 / 重试 |
-| `G05` | 状态标签 Tag | 订单状态、活动状态、会员状态 | 多色标签 |
+### 1.1 先抽共性，不抽幻觉
+
+- 只有跨页面稳定复用的结构，才进入通用组件清单。
+- 还没有冻结的能力，不做刚性组件。
+
+### 1.2 先抽职责，不先抽字段
+
+- 组件先定义“解决什么问题”。
+- 字段可以随接口阶段调整，不应反过来驱动组件设计。
+
+### 1.3 先服务当前阶段，再预留未来阶段
+
+- `V1.0` 交易主链路相关组件优先级最高。
+- `V1.1 / V2.0 / V2.1 / V3.0` 组件可以预留，但要明确阶段边界。
+
+---
+
+## 2. 全局基础组件
+
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G01` | 顶部导航栏 | 二级页返回、标题、右侧操作占位 | 全部二级页 | `V1.0+` |
+| `G02` | 底部 TabBar | 四个 Tab 页面切换 | `T01 / T02 / T03 / T04` | `V1.0+` |
+| `G03` | 页面空态卡片 | 列表无数据时统一提示和 CTA | 列表页、结果页 | `V1.0+` |
+| `G04` | 页面错误卡片 | 网络失败、数据异常、重试 | 全部业务页 | `V1.0+` |
+| `G05` | 状态标签 | 订单状态、活动状态、会员状态等语义标签 | 订单、活动、会员页 | `V1.0+` |
+| `G06` | 固定底部主操作栏 | 承载主 CTA，处理安全区和禁用态 | 结算页、订单详情页 | `V1.0+` |
+
+---
## 3. 门店与场景组件
-| 编码 | 组件名称 | 用途 | 使用页面 |
-| --- | --- | --- | --- |
-| `G10` | 门店切换条 | 显示当前门店，点击切换 | 首页、点餐页 |
-| `G11` | 场景切换条 | 外卖 / 自提 / 堂食切换 | 首页、点餐页 |
-| `G12` | 门店信息卡 | 地址、营业、距离、电话 | 首页、结算页、堂食确认页 |
-| `G13` | 服务规则条 | 起送价、配送费、自提规则等 | 首页、点餐页、结算页 |
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G10` | 门店切换条 | 展示当前门店并进入切店流程 | 首页、点餐页 | `V1.0+` |
+| `G11` | 场景切换条 | 在门店支持范围内切换外卖 / 自提 / 堂食 | 首页、点餐页 | `V1.0+` |
+| `G12` | 门店信息卡 | 展示门店地址、营业状态、电话、基础服务信息 | 首页、结算页、堂食确认页 | `V1.0+` |
+| `G13` | 服务规则条 | 展示起送价、配送费、自提说明、堂食提示等简要规则 | 首页、点餐页、结算页 | `V1.0+` |
+| `G14` | 场景结果卡 | 展示当前场景的前置信息，如地址、自提门店、桌台 | 地址页、堂食确认页、结算页 | `V1.0+` |
+
+---
## 4. 商品与购物车组件
-| 编码 | 组件名称 | 用途 | 使用页面 |
-| --- | --- | --- | --- |
-| `G20` | 分类侧边栏 / 顶部分类条 | 分类浏览商品 | 点餐页 |
-| `G21` | 商品卡片 | 展示图片、价格、标签、加购按钮 | 点餐页、活动页 |
-| `G22` | 数量步进器 | 商品数量增减 | 点餐页、商品详情、购物车 |
-| `G23` | 规格选项组 | 规格做法单选/多选 | 商品详情抽屉 |
-| `G24` | 加料选项组 | 附加项选择 | 商品详情抽屉 |
-| `G25` | 底部购物车栏 | 已选数量、金额、去结算按钮 | 点餐页 |
-| `G26` | 购物车商品行 | 展示已选商品和规格组合 | 购物车抽屉 |
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G20` | 类目导航 | 承接分类切换、当前类目高亮、吸顶表达 | 点餐页 | `V1.0+` |
+| `G21` | 商品卡片 | 展示商品图、标签、价格、活动摘要、加购入口 | 点餐页、活动页 | `V1.0+` |
+| `G22` | 数量步进器 | 商品数量加减和禁用态表达 | 点餐页、抽屉、购物车 | `V1.0+` |
+| `G23` | 商品详情头部 | 展示商品图、标题、描述、销量、价格、售罄态 | 商品详情抽屉 | `V1.0+` |
+| `G24` | 规格选项组 | 承接规格、做法、套餐组等选择 | 商品详情抽屉 | `V1.0+` |
+| `G25` | 加料选项组 | 承接附加项和加价项选择 | 商品详情抽屉 | `V1.0+` |
+| `G26` | 底部购物车栏 | 展示已选件数、金额和去结算入口 | 点餐页 | `V1.0+` |
+| `G27` | 购物车商品行 | 展示已选商品、规格摘要、数量编辑、删除动作 | 购物车抽屉 | `V1.0+` |
+| `G28` | 凑单 / 优惠提示条 | 展示凑单距离、优惠提示、配送门槛说明 | 购物车抽屉、结算页 | `V1.0+` |
+
+---
## 5. 结算与订单组件
-| 编码 | 组件名称 | 用途 | 使用页面 |
-| --- | --- | --- | --- |
-| `G30` | 地址卡片 | 展示收货地址或取餐信息 | 结算页 |
-| `G31` | 费用明细卡 | 展示金额构成 | 结算页、订单详情页 |
-| `G32` | 优惠资产单元格 | 展示优惠券 / 积分 / 余额入口 | 结算页 |
-| `G33` | 订单摘要卡 | 展示门店、商品、金额、状态 | 订单页 |
-| `G34` | 订单时间轴 | 展示履约节点 | 订单详情页、退款详情页 |
-| `G35` | 固定底部操作栏 | 继续支付、催单、退款、评价等 CTA | 结算页、订单详情页 |
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G30` | 履约信息卡 | 根据场景展示配送地址、自提门店或堂食桌台信息 | 结算页、订单详情页 | `V1.0+` |
+| `G31` | 手动资产选择单元格 | 展示并进入手动资产选择入口 | 结算页 | `V1.0+` |
+| `G32` | 自动优惠命中列表 | 展示自动命中的优惠结果和说明 | 结算页 | `V1.0+` |
+| `G33` | 费用明细卡 | 展示商品金额、配送费、优惠、应付金额 | 结算页、订单详情页 | `V1.0+` |
+| `G34` | 订单摘要卡 | 展示订单门店、状态、金额、时间和主动作 | 订单页、支付成功页 | `V1.0+` |
+| `G35` | 履约时间轴 | 展示顾客可理解的订单阶段和进展 | 订单详情页、退款详情页 | `V1.1+` |
+| `G36` | 退款原因选择区 | 退款原因和补充说明输入 | 退款申请页 | `V1.1+` |
+| `G37` | 评价输入区 | 星级、文本输入和最小评价反馈区 | 评价页 | `V1.1+` |
-## 6. 资产与服务组件
+---
-| 编码 | 组件名称 | 用途 | 使用页面 |
-| --- | --- | --- | --- |
-| `G40` | 用户头部卡 | 头像、昵称、会员等级 | 我的页、会员中心 |
-| `G41` | 资产总览卡 | 券、积分、余额、次卡摘要 | 我的页 |
-| `G42` | 资产列表项 | 进入券、积分、储值、次卡详情 | 我的页 |
-| `G43` | 活动券卡片 | 满减券、折扣券、免配送费券 | 领券中心 |
-| `G44` | 充值方案卡 | 展示充值金额、赠送金额、到账金额 | 储值充值页 |
-| `G45` | 次卡卡片 | 展示次卡名称、剩余次数、有效期 | 次卡页 |
-| `G46` | 消息列表项 | 展示消息标题、摘要、时间、未读状态 | 消息中心 |
+## 6. 我的、资产与增长组件
-## 7. 通用实现要求
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G40` | 用户头部卡 | 展示头像、昵称、会员信息摘要 | 我的页、会员中心页 | `V1.0+` |
+| `G41` | 资产摘要卡 | 展示会员、积分、余额、次卡等摘要信息 | 我的页 | `V2.0+` |
+| `G42` | 订单快捷入口组 | 展示待支付、进行中、已完成等快捷入口 | 我的页 | `V1.0+` |
+| `G43` | 资产入口列表 | 承接会员、积分、储值、次卡等二级页入口 | 我的页 | `V2.0+` |
+| `G44` | 活动券卡片 | 展示券模板名称、门槛、有效期和领取 CTA | 领券中心页 | `V2.1+` |
+| `G45` | 活动商品卡 | 展示秒杀或限时折扣商品及活动状态 | 秒杀页、限时折扣页 | `V2.1+` |
+| `G46` | 充值方案卡 | 展示充值金额、赠送说明和到账结果 | 储值充值页 | `V2.0+` |
+| `G47` | 次卡卡片 | 展示次卡名称、权益摘要、剩余次数和有效期 | 次卡页 | `V2.0+` |
+| `G48` | 服务入口组 | 展示帮助、消息、客服等服务入口 | 我的页、帮助中心页 | `V3.0+` |
-- 所有卡片组件需要支持禁用态或不可点击态
-- 列表项需要支持右侧箭头、辅助文案、角标等变化
-- 底部固定操作栏需要考虑安全区
-- 金额展示组件统一格式化
-- 状态标签颜色语义在整个应用中保持一致
+---
+## 7. 服务与预留组件
+
+| 编码 | 组件名称 | 主要职责 | 适用页面 | 适用阶段 |
+| --- | --- | --- | --- | --- |
+| `G50` | 消息列表项 | 展示消息标题、摘要、时间和已读状态 | 消息中心页 | `V3.0+` |
+| `G51` | 帮助问题列表项 | 展示问题标题、分类和跳转入口 | 帮助中心页 | `V3.0+` |
+| `G52` | 服务兜底卡 | 展示客服电话、在线客服、售后指引等信息 | 帮助中心页、我的页 | `V3.0+` |
+
+---
+
+## 8. 当前必须守住的组件边界
+
+### 8.1 场景切换条
+
+- `G11` 必须跟随门店 `serviceTypes` 控制可用场景。
+- 不能做固定三按钮硬编码。
+
+### 8.2 商品卡和商品详情抽屉
+
+- `G21` 必须区分简单商品和复杂商品。
+- 简单商品可直接加购。
+- 复杂商品必须进入 `G23 / G24 / G25` 组合后的商品详情抽屉流程。
+
+### 8.3 结算资产组件
+
+- `G31` 当前只冻结：
+ - 优惠券
+ - 余额
+ - 次卡
+- `积分抵扣` 当前不进入该组件的已冻结范围。
+
+### 8.4 自动优惠组件
+
+- `G32` 当前只展示自动命中结果。
+- 当前冻结范围包括：
+ - 满减
+ - 新客优惠
+ - 会员折扣
+ - 免配送费
+
+### 8.5 订单操作组件
+
+- `G06` 不应把商家动作直接变成顾客动作。
+- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定组件按钮写死。
+
+### 8.6 消息与帮助组件
+
+- `G50` 当前只是未来职责预留，不代表已经冻结完整消息 inbox。
+- `G51 / G52` 当前用于服务兜底，不默认假设 FAQ CMS 或客服系统已经成熟存在。
+
+---
+
+## 9. 通用实现要求
+
+- 所有可点击组件都要有禁用态或不可点击态。
+- 所有异步主按钮都要有 `loading` 反馈。
+- 金额显示格式在全应用保持一致。
+- 状态标签颜色语义在全应用保持一致。
+- 固定底部组件需要处理小程序安全区。
+- 组件文案优先使用顾客语言，不使用商家后台字段名。
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/01-Tab-首页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/01-Tab-首页.md
index de5a44d..89301e0 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/01-Tab-首页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/01-Tab-首页.md
@@ -2,100 +2,244 @@
- 页面编码：`T01`
- 页面层级：`Tab`
-- 适用场景：`外卖 / 自提 / 堂食导流`
-- 页面目标：完成选店、选场景、看活动、快速进入点餐
-- 主要依赖组件：`G02`、`G10`、`G11`、`G12`、`G13`、`G21`
+- 适用场景：`全场景导流页`，当前可切换场景由当前门店 `serviceTypes` 决定
+- 页面目标：完成“选对门店 + 进入正确场景 + 感知当前有效活动 + 用最短路径进入点餐或活动会场”
+- 主要依赖组件：`G02`、`G10`、`G11`、`G12`、`G13`、`G21`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`02-菜单浏览与加购链路.md`、`05-我的资产消息复购链路.md`、`06-活动导购与增长链路.md` 回写
## 1. 页面结构（从上到下）
-1. 顶部信息区
-2. 门店切换条
-3. 场景切换条
-4. Banner 活动区
-5. 快捷入口区
-6. 推荐商品区
-7. 门店服务信息区
+1. 顶部上下文区
+2. 当前门店卡
+3. 动态场景切换条
+4. 当前场景服务摘要条
+5. 动态活动 Banner 区
+6. 精选活动入口区
+7. 推荐商品摘要区
+8. 门店服务轻信息区
## 2. 区块说明
-### 2.1 顶部信息区
-- 左侧显示当前位置 / 当前门店简称
-- 右侧显示消息入口
-- 点击门店或位置进入 `P01 门店选择页`
-- 点击消息入口进入 `P16 消息中心页`
+### 2.1 顶部上下文区
-### 2.2 门店切换条
-- 使用 `G10`
-- 显示当前门店名称、营业状态、距离
-- 支持点击切换门店
+- 左侧显示当前上下文摘要，不再简单写成“当前位置 / 门店简称”
+- 文案跟随当前场景变化：
+ - `delivery`：当前配送地址或“请选择配送地址”
+ - `pickup`：当前门店名称 / 商圈摘要
+ - `dine_in`：当前门店名称与“支持堂食”提示
+- `delivery` 场景点击左侧摘要，优先进入 `P02 地址管理页`
+- `pickup / dine_in` 场景点击左侧摘要，优先进入 `P01 门店选择页`
+- 右侧动作位不再强制写死为“消息入口”
+- 如产品仍需保留右侧服务入口，可承接：
+ - `P16 消息中心页`
+ - 其他服务页入口
+- 当前不冻结：
+ - 首页消息未读红点
+ - 首页消息数量角标
+
+### 2.2 当前门店卡
+
+- 使用 `G10` + `G12`
+- 展示当前门店的核心事实：
+ - 门店名称
+ - 当前营业状态
+ - 地址摘要 / 距离摘要
+ - 联系电话或联系门店入口
+- 点击门店卡主体进入 `P01 门店选择页`
+- 门店卡不需要一次性展开配送、自提、堂食三整套规则
+- 门店卡内只保留当前场景强相关摘要：
+ - `delivery`：当前地址是否可配送、预计送达、起送价
+ - `pickup`：当前是否可自提、最近可约时段
+ - `dine_in`：当前是否开启堂食、是否支持扫码入桌
+- 门店卡应提供一个主导流动作：
+ - `delivery / pickup`：进入 `T02 点餐页`
+ - `dine_in`：优先提示“扫码入桌后点餐”，不强行虚构手动入桌链路
+
+### 2.3 动态场景切换条
-### 2.3 场景切换条
- 使用 `G11`
-- 固定提供 `外卖`、`自提`、`堂食` 三项
-- 切换后刷新下方活动和推荐内容
+- 不再固定提供 `外卖 / 自提 / 堂食` 三项
+- 场景项必须由当前门店真实 `serviceTypes` 动态生成
+- 默认策略：
+ - 支持的场景正常展示并可切换
+ - 不支持的场景默认不展示
+- 如果产品需要保留固定槽位，也只能用禁用态展示，并明确原因
+- 切换场景后必须同步刷新：
+ - 顶部上下文摘要
+ - 门店卡中的服务摘要
+ - 活动内容
+ - 推荐商品
-### 2.4 Banner 活动区
-- 展示门店主推活动轮播
-- Banner 点击可跳转：
- - `P09 领券中心页`
+### 2.4 当前场景服务摘要条
+
+- 使用 `G13`
+- 这一条只展示“当前场景的一层摘要”，不承担完整规则页职责
+- `delivery` 场景至少展示：
+ - 是否可配送
+ - 预计送达
+ - 起送价
+ - 配送费
+- `pickup` 场景至少展示：
+ - 当前营业状态
+ - 最近可约时段
+ - 是否支持当日自提
+- `dine_in` 场景至少展示：
+ - 是否开启堂食
+ - 堂食点餐提示
+ - 扫码入桌提示
+- 不在首页平铺以下后台细节：
+ - `polygonGeoJson`
+ - `hourlyCapacityLimit`
+ - `platformServiceRate`
+ - 员工排班
+
+### 2.5 动态活动 Banner 区
+
+- Banner 区展示的是“当前门店 + 当前场景 + 当前资格 + 当前生效状态”下的精选活动
+- Banner 不固定写死活动类别，内容由当前有效活动动态生成
+- 首页优先承接的活动类型只有：
- `P10 秒杀活动页`
- `P11 限时折扣活动页`
- - `P12 会员中心页`
+ - `P09 领券中心页`
+ - 当前资格成立的新客活动
+- Banner 点击跳转规则：
+ - 秒杀：进入 `P10`
+ - 限时折扣：进入 `P11`
+ - 领券：进入 `P09`
+ - 新客活动：进入 `T02 点餐页` 对应落点或活动说明落点，不单独虚构一页“新客会场”
+- Banner 区没有有效活动时可整体隐藏
-### 2.5 快捷入口区
-- 建议 2 行网格或 1 行宫格
-- 包含以下入口：
- - 新客有礼
+### 2.6 精选活动入口区
+
+- 这一块从“固定八宫格”改为“动态精选入口”
+- 默认只展示少量高价值入口，建议控制在 `2-4` 个
+- 入口内容只从当前有效活动里选，不再把所有服务入口混到首页同一层
+- 可展示的入口类型：
- 领券中心
- - 满减活动
- 秒杀专区
- 限时折扣
+ - 资格成立时的新客入口
+- 当前不应占首页核心活动位的内容：
- 储值充值
- 次卡专区
- 会员中心
+ - 帮助中心
+- 满减活动可以作为摘要感知存在，但不单独做首页固定入口
-### 2.6 推荐商品区
-- 按顺序展示：
- - 热销推荐
- - 套餐推荐
- - 复购推荐
- - 猜你喜欢
-- 每个区块使用横滑或纵向卡片列表
-- 商品卡点击进入 `C01 商品详情抽屉`
+### 2.7 推荐商品摘要区
-### 2.7 门店服务信息区
-- 使用 `G12` + `G13`
-- 展示：
- - 营业时间
- - 配送范围 / 起送价 / 配送费
- - 自提规则
- - 堂食规则
+- 这一块只做轻量商品导流，不复刻点餐页分类与筛选能力
+- 推荐分组不再固定写死为“热销 / 套餐 / 复购 / 猜你喜欢”四段
+- 推荐内容可以来自：
+ - 热销商品
+ - 当前活动商品
+ - 常点商品 / 复购推荐
+ - 门店主推商品
+- 页面实现时建议最多保留少量分组，避免首页过长
+- 商品卡 `G21` 至少展示：
+ - 商品图
+ - 商品名
+ - 当前售价
+ - 划线价（如有）
+ - 商品标签
+ - 当前活动标识（如有）
+- 商品卡点击规则：
+ - 默认进入 `C01 商品详情抽屉` 或跳转 `T02` 对应商品位置
+ - 如果商品为“无规格、无加料、非套餐”的简单商品，可选做快速加购
+ - 快速加购不是首页必备结构
+- 首页商品卡不承载：
+ - 分类切换
+ - 复杂选配
+ - 大段优惠解释
+
+### 2.8 门店服务轻信息区
+
+- 这一块只保留轻信息，不再做一个长篇“门店服务信息区”
+- 可展示内容：
+ - 今日营业时间摘要
- 联系门店
- 到店导航
+ - 当前场景相关补充说明
+- 展示原则：
+ - 只展示当前场景直接相关内容
+ - 不把配送、自提、堂食三套规则一次性全部平铺
+- 如果后续需要承接更完整的门店规则，优先做抽屉或详情承接；本页不先写重
## 3. 页面主动作
-- 切换门店
-- 切换场景
-- 进入点餐页
-- 进入活动页
-- 打开商品详情
+- 切换门店，进入 `P01 门店选择页`
+- 在 `delivery` 场景切换或补充配送地址，进入 `P02 地址管理页`
+- 切换当前下单场景
+- 进入 `T02 点餐页`
+- 进入 `P09 领券中心页`
+- 进入 `P10 秒杀活动页`
+- 进入 `P11 限时折扣活动页`
+- 打开 `C01 商品详情抽屉` 或跳转点餐页对应商品
+- 联系门店或打开导航
## 4. 页面状态
### 默认态
-- 有门店、有活动、有推荐商品
-### 空态
-- 无可用门店时展示空态，并提供重新定位
-- 无活动时隐藏活动区，保留推荐区
+- 已确定门店
+- 当前场景可用
+- 有活动或有推荐商品
+- 可以顺畅进入点餐链路
-### 异常态
-- 定位失败时提示手动选店
-- 门店休息时展示“休息中”，但可保留浏览
+### 无门店态
+
+- 无可用门店时展示 `G03`
+- 明确告知当前无法进入点餐
+- 提供重新定位或手动选店动作
+
+### 无地址 / 不可配送态
+
+- 仅在 `delivery` 场景下出现
+- 当未选择地址时：
+ - 顶部摘要提示选择地址
+ - 不默认假设“当前门店可配送”
+- 当地址不可配送时：
+ - 明确展示“超出配送范围 / 不在配送区域 / 当前不支持配送”
+ - 允许切换地址或切换门店
+
+### 场景不可用态
+
+- 当前门店不支持某场景时，不应继续展示可点选主动作
+- 如使用禁用态展示场景项，需要给出禁用原因
+
+### 门店休息态
+
+- 允许浏览门店和活动摘要
+- 主动作需要降级：
+ - 可提示“休息中”
+ - 如允许预订，则按对应场景展示最近可用时间
+
+### 无活动态
+
+- 隐藏 Banner 区和精选活动入口区
+- 页面仍保留门店摘要与推荐商品摘要
+
+### 无推荐商品态
+
+- 推荐商品区可隐藏
+- 不影响门店切换、场景切换和活动导流
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重新加载当前门店、场景与活动数据
## 5. 实现备注
-- 首页优先是“导流页”，不是深度浏览页
-- 推荐商品只展示摘要，不在首页直接承载复杂选配
+- 首页首先是“上下文建立 + 导流页”，不是完整点餐页
+- 首页不能再做固定八宫格目录页
+- 首页不能把资产入口、服务入口、营销入口混成同一层级
+- 场景切换必须跟随门店真实 `serviceTypes`
+- 活动内容必须服从：
+ - 当前门店
+ - 当前场景
+ - 当前活动状态
+ - 当前用户资格
+- 首页不冻结消息未读数、券数量、次卡数量等聚合角标
+- `dine_in` 场景不在首页虚构“合单 / 加菜 / 先付款”等后台未证实规则
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/02-Tab-点餐页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/02-Tab-点餐页.md
index 8489f71..293c352 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/02-Tab-点餐页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/02-Tab-点餐页.md
@@ -2,93 +2,294 @@
- 页面编码：`T02`
- 页面层级：`Tab`
-- 适用场景：`外卖 / 自提 / 堂食`
-- 页面目标：完成商品浏览、选配、加购和进入结算
-- 主要依赖组件：`G10`、`G11`、`G20`、`G21`、`G22`、`G25`
+- 适用场景：`delivery / pickup / dine_in`，当前可切换场景由当前门店 `serviceTypes` 决定
+- 页面目标：在“当前门店 + 当前场景”的交易上下文内完成商品浏览、搜索、选配分流、加购、查看购物车并进入结算
+- 主要依赖组件：`G10`、`G11`、`G13`、`G20`、`G21`、`G22`、`G25`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`02-菜单浏览与加购链路.md`、`03-结算与支付链路.md`、`06-活动导购与增长链路.md` 回写
## 1. 页面结构（从上到下）
-1. 顶部门店条
-2. 场景切换条
-3. 搜索与活动提示条
-4. 菜单主区域
-5. 底部购物车栏
+1. 顶部交易上下文区
+2. 动态场景切换条
+3. 搜索区
+4. 轻量活动摘要条
+5. 菜单主区域
+6. 底部购物车栏
## 2. 区块说明
-### 2.1 顶部门店条
-- 显示当前门店名称、营业状态
-- 点击进入 `P01 门店选择页`
-- 门店切换需要提示购物车风险
+### 2.1 顶部交易上下文区
-### 2.2 场景切换条
-- 显示 `外卖 / 自提 / 堂食`
-- 切换时刷新：
+- 这一块不是纯标题区，而是当前交易上下文的事实入口
+- 使用 `G10`，并补充当前场景关键信息
+- 至少展示：
+ - 当前门店名称
+ - 当前营业状态
+ - 当前场景
+ - 当前场景下的关键上下文
+- 场景差异：
+ - `delivery`：当前配送地址、是否可送、预计送达或配送摘要
+ - `pickup`：当前门店、是否支持自提、营业摘要
+ - `dine_in`：当前门店、桌号
+- 点击行为：
+ - 点击门店主体进入 `P01 门店选择页`
+ - `delivery` 场景点击地址摘要进入 `P02 地址管理页`
+ - `dine_in` 场景如桌号缺失或上下文失效，应引导重新扫码或返回 `P18`
+- 切换门店属于高风险动作，需要提示：
+ - 当前购物车属于单门店 + 单场景
+ - 切店可能清空购物车
+
+### 2.2 动态场景切换条
+
+- 使用 `G11`
+- 不再固定展示 `外卖 / 自提 / 堂食` 三项
+- 场景项必须按当前门店真实 `serviceTypes` 动态生成
+- 切换场景后必须同步刷新：
+ - 顶部上下文
+ - 分类导航
+ - 商品列表
- 商品可售状态
- - 服务规则说明
- - 价格与优惠提示
+ - 活动摘要
+ - 购物车可用性
+- 切换场景时同样属于高风险动作，需要处理跨场景购物车问题：
+ - 若购物车为空，可直接切换
+ - 若购物车非空，应提示清空风险
+- 不支持的场景不应继续以可点击主入口出现
-### 2.3 搜索与活动提示条
-- 搜索框：按商品名搜索
-- 活动条：显示当前命中的满减、秒杀、折扣等活动摘要
+### 2.3 搜索区
-### 2.4 菜单主区域
-- 左侧或顶部为分类导航 `G20`
-- 右侧或主体为商品列表
-- 每个商品卡 `G21` 展示：
- - 图片
- - 名称
- - 描述摘要
- - 标签
- - 价格 / 划线价
- - 加购按钮
-- 点击商品卡进入 `C01 商品详情抽屉`
-- 直接点击步进器可快速加购默认 SKU
+- 搜索只在“当前门店 + 当前场景 + 当前时段”内生效
+- 支持按商品名称、商品关键词做搜索
+- 搜索结果必须保持和主列表一致的可售口径
+- 搜索结果页或搜索态中仍需保留：
+ - 商品标签
+ - 当前价格
+ - 当前可售状态
+ - 快速加购 / 打开详情的分流逻辑
+- 搜索不应绕开分类和场景限制，不能搜出当前场景不可售商品再允许加购
+
+### 2.4 轻量活动摘要条
+
+- 这一块保留，但只做轻量摘要，不做营销主区
+- 只承接会影响当前购买决策的高价值活动结果：
+ - 满减摘要
+ - 新客命中摘要
+ - 秒杀进行中
+ - 限时折扣进行中
+- 表达形式建议是单行摘要或少量标签化提示
+- 允许点击进入对应活动页或定位活动商品，但不能把这里做成“活动公告栏堆栈”
+- 页面内活动口径必须同时服从：
+ - 当前门店
+ - 当前场景
+ - 当前活动状态
+ - 当前用户资格
+- 当前不在点餐页强写：
+ - 顾客手动选择满减
+ - 新客完整会场
+ - 营销日历入口
+
+### 2.5 菜单主区域
+
+- 这一块是页面主区，优先级高于活动摘要
+- 结构由两部分组成：
+ - 分类导航 `G20`
+ - 商品列表区
+
+#### 分类导航
+
+- 分类不是全场景通用一套，必须受后台 `channels` 约束
+- 前台展示统一使用顾客语言：
+ - `外卖`
+ - `自提`
+ - `堂食`
+- 当前场景下没有商品的分类不应误导性展示为正常可点主分类
+- 分类切换与滚动定位需要稳定，不被活动条插队打乱
+
+#### 商品列表区
+
+- 商品列表按当前门店、当前场景、当前时段展示可售商品
+- 商品卡 `G21` 至少展示：
+ - 商品图
+ - 商品名
+ - 摘要描述
+ - 商品标签
+ - 当前售价
+ - 划线价（如有）
+ - 月售等弱经营信息
+ - 商品可售状态
+ - 加购入口
+- 商品卡必须支持区分三类购买形态：
+ - 简单单品：无规格、无加料、非套餐
+ - 复杂单品：有规格 / 做法 / 加料
+ - 套餐商品：带套餐分组
+
+#### 快速加购规则
+
+- 只有“简单单品”允许直接使用 `G22` 快速加购
+- 复杂单品点击加购时，必须打开 `C01 商品详情抽屉`
+- 套餐商品点击加购时，必须打开 `C01` 并进入套餐分组选择
+- 不允许再写“默认 SKU 一键快速加购”作为通用规则
+
+#### 商品详情打开规则
+
+- 点击商品卡主体默认打开 `C01 商品详情抽屉`
+- 抽屉负责处理：
+ - 规格做法
+ - 加料组
+ - 套餐分组
+ - SKU 价格与库存联动
+- 点餐页本体不直接承担复杂选配
+
+#### 商品可售状态表达
+
+- 不可售不能只写成“售罄”
+- 至少要翻译成顾客可理解的几类原因：
+ - 已售罄
+ - 已下架
+ - 当前时段不可售
+ - 当前场景不可售
+ - 临时沽清
+- 不可售商品可以浏览，但不可直接加购
+
+### 2.6 底部购物车栏
-### 2.5 底部购物车栏
- 使用 `G25`
-- 展示：
+- 始终是页面唯一明确的“去结算”主路径
+- 至少展示：
- 已选商品件数
- 当前总金额
- - 差多少起送 / 差多少免配送费
- - 去结算按钮
+ - 主按钮“去结算”
+- 差额提示必须按场景收敛：
+ - `delivery`：可展示差多少起送、差多少免配送费
+ - `pickup`：不展示配送费和免配送费差额
+ - `dine_in`：不展示配送相关差额
- 点击购物车区域打开 `C02 购物车抽屉`
+- 点击“去结算”进入 `P03 结算确认页`
+- 未登录时，点击去结算应按全局规则先走 `C03 登录授权弹层`
## 3. 场景差异规则
-### 外卖场景
-- 突出显示配送费、起送价、预计送达
+### `delivery`
-### 自提场景
-- 突出显示自提优惠、自提时段说明
+- 强调地址与配送可达性
+- 分类和商品必须按外卖渠道过滤
+- 页面可展示配送相关轻摘要：
+ - 是否可送
+ - 预计送达
+ - 起送价 / 配送费提示
+- 购物车栏可显示起送差额与免配送费差额
-### 堂食场景
-- 突出显示桌号、当前门店、可加菜提示
+### `pickup`
+
+- 强调当前门店与自提可用性
+- 分类和商品必须按自提渠道过滤
+- 页面只做自提轻摘要，不提前让用户在点餐页选复杂取餐时间
+- 自提时间的正式确认放到 `P03 结算确认页`
+
+### `dine_in`
+
+- 强调门店与桌号上下文
+- 分类和商品必须按堂食渠道过滤
+- 页面不展示配送地址、配送费、免配送费相关模块
+- 页面不虚构以下规则：
+ - 合单
+ - 加菜
+ - 先付款
+- 如桌号上下文丢失或失效，应优先提示重新扫码或重新确认桌位
## 4. 页面主动作
- 切换门店
-- 切换场景
+- 切换当前下单场景
+- 在 `delivery` 场景选择或变更配送地址
- 搜索商品
-- 打开商品详情抽屉
-- 打开购物车抽屉
-- 进入结算确认页
+- 切换分类
+- 打开 `C01 商品详情抽屉`
+- 对简单单品直接加购
+- 打开 `C02 购物车抽屉`
+- 进入 `P03 结算确认页`
## 5. 页面状态
### 默认态
-- 有分类、有商品、有活动提示
-### 空态
-- 某分类无商品时，右侧显示空态
-- 搜索无结果时，提供清空搜索入口
+- 已确定门店与当前场景
+- 有分类、有商品
+- 活动摘要可有可无
+- 购物车栏按当前选择实时变化
-### 异常态
-- 当前门店休息：商品可浏览但不能结算
-- 商品售罄：显示禁用状态，不能加购
+### 分类空态
+
+- 当前分类无商品时，商品区展示 `G03`
+- 提示切换分类或清空筛选 / 搜索
+
+### 搜索无结果态
+
+- 搜索结果为空时展示 `G03`
+- 提供清空关键词、返回分类浏览动作
+
+### 当前场景无商品态
+
+- 当前门店在该场景下没有可售商品时，不能继续伪装成正常菜单页
+- 需要明确提示：
+ - 当前场景暂无可售商品
+ - 可切换其他场景或切换门店
+
+### 门店休息态
+
+- 商品允许浏览
+- 不可直接把“可浏览”误写成“可正常下单”
+- 主结算路径需要降级或提示：
+ - 当前休息中
+ - 如支持预约，后续在结算页继续确认
+
+### 地址缺失 / 不可配送态
+
+- 仅 `delivery` 场景出现
+- 当地址缺失时：
+ - 顶部上下文明确提示选择地址
+ - 不默认放行正常配送预期
+- 当地址不可配送时：
+ - 要明确说明原因
+ - 允许切换地址或切换门店
+
+### 堂食上下文失效态
+
+- 仅 `dine_in` 场景出现
+- 当桌号不存在、失效或不可用时：
+ - 提示重新扫码
+ - 禁止继续按正常堂食上下文下单
+
+### 商品失效态
+
+- 商品状态变化后要能即时反馈：
+ - 已下架
+ - 已售罄
+ - 当前时段不可售
+ - 当前场景不可售
+- 失效商品不能继续加购
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重新加载：
+ - 分类数据
+ - 商品数据
+ - 当前场景状态
+ - 活动摘要
## 6. 实现备注
-- 点餐页是整套小程序最核心页面，需要优先保证信息密度和操作效率
-- 商品详情、购物车应通过抽屉承载，尽量不跳转新页面
+- 点餐页是整套小程序的核心交易页，但主区必须始终让位给“商品浏览与加购”
+- 分类展示必须受当前场景渠道约束，不能做全场景通用菜单
+- 只有简单单品允许快速加购；复杂单品和套餐统一走 `C01`
+- 活动摘要条只做轻导流和轻提示，不前移结算和优惠解释
+- 购物车抽屉优先解决商品确认、失效清理和去结算，不做复杂优惠主战场
+- 点餐页不承接：
+ - 优惠券选择
+ - 储值选择
+ - 次卡核销
+ - 积分抵扣
+ - 复杂支付方式选择
+- `dine_in` 场景不在本页承诺后台未证实的堂食规则
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/03-Tab-订单页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/03-Tab-订单页.md
index 48f0f33..5901d73 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/03-Tab-订单页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/03-Tab-订单页.md
@@ -3,62 +3,153 @@
- 页面编码：`T03`
- 页面层级：`Tab`
- 适用场景：`全场景`
-- 页面目标：让用户快速找到订单，并查看履约、售后和复购入口
-- 主要依赖组件：`G05`、`G33`
+- 页面目标：让顾客快速找到自己的订单，先看懂“现在进行到哪一步”，再执行当前状态下最有价值的动作
+- 主要依赖组件：`G05`、`G33`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
## 1. 页面结构（从上到下）
-1. 顶部状态筛选区
-2. 场景筛选区（可选）
+1. 顶部主筛选区
+2. 场景二级筛选区
3. 订单列表区
## 2. 区块说明
-### 2.1 顶部状态筛选区
-- 建议分段控件或横向标签
-- 至少包含：
+### 2.1 顶部主筛选区
+
+- 这一块必须使用顾客任务语言，不复用商家看板分栏
+- 顶部主筛选固定为：
- 全部
- 待支付
- 进行中
- 已完成
- - 退款售后
+ - 售后
+- 这些页签用于帮助顾客快速判断“我现在最可能要处理哪一类单”
+- 后台更细的状态如：
+ - 待接单
+ - 制作中
+ - 配送中
+ - 待取餐
+- 不直接上翻成顶层页签，而是下沉到卡片状态文案和详情页表达
-### 2.2 场景筛选区
-- 可按 `外卖 / 自提 / 堂食` 进行二次筛选
-- 也可与状态整合为一个过滤区
+### 2.2 场景二级筛选区
+
+- 场景筛选 `外卖 / 自提 / 堂食` 可以保留，但只能作为二级筛选
+- 这一块不能取代顶部主筛选成为主信息架构
+- 场景筛选的作用是帮助顾客在同一状态下继续缩小范围，例如：
+ - 查看进行中的外卖单
+ - 查看已完成的堂食单
+- 当前不在订单页继续叠加后台管理筛选，如：
+ - 支付方式
+ - 日期区间
+ - 关键词搜索
### 2.3 订单列表区
+
- 每张订单卡使用 `G33`
-- 订单卡必须展示：
+- 订单卡的目标是让顾客一眼看懂：
+ - 哪家门店
+ - 什么状态
+ - 什么场景
+ - 买了什么
+ - 金额多少
+ - 下一步该做什么
+- 订单卡至少展示：
- 门店名称
- - 订单状态
+ - 当前状态文案
- 场景标签
- 商品摘要
- 订单金额
- 下单时间
- - 主要操作按钮
-- 订单卡点击进入 `P05 订单详情页`
+- 可按状态补充一条轻辅助说明，例如：
+ - 商家处理中
+ - 制作中
+ - 配送中
+ - 待到店取餐
+- 点击订单卡主体进入 `P05 订单详情页`
## 3. 订单卡动作规则
-- `待支付`：继续支付、取消订单
-- `进行中`：查看详情、催单、查看取餐码
-- `已完成`：评价、再来一单
-- `退款售后`：查看退款详情
+### `待支付`
-## 4. 页面状态
+- 主动作：
+ - 继续支付
+ - 取消订单
+- 这是和第 3 批结算支付链路直接衔接的状态
+
+### `进行中`
+
+- 主动作收敛为：
+ - 查看详情
+- 不把以下能力冻结为所有进行中订单的固定按钮：
+ - 催单
+ - 查看取餐码
+ - 骑手轨迹
+
+### `已完成`
+
+- 主动作：
+ - 去评价
+ - 再来一单
+
+### `售后`
+
+- 主动作：
+ - 查看退款详情
+
+### 其他结果态
+
+- 如为已取消等只读结果态：
+ - 以查看详情为主
+ - 不堆叠无意义动作
+
+## 4. 状态翻译原则
+
+- 后台订单状态不能原样以商家术语抛给顾客
+- 订单页顶层统一使用顾客视角页签：
+ - 全部
+ - 待支付
+ - 进行中
+ - 已完成
+ - 售后
+- 更细的后台状态只用于驱动卡片文案，例如：
+ - 待接单 / 商家处理中
+ - 制作中
+ - 配送中
+ - 待取餐
+
+## 5. 页面状态
### 默认态
+
- 有订单列表
+- 顾客可以快速扫读状态、门店、金额与下一步动作
### 空态
-- 某筛选条件下无订单时，展示空态和“去点餐” CTA
-### 异常态
-- 加载失败时展示重试
+- 某个筛选条件下无订单时，展示 `G03`
+- 提供“去点餐” CTA
+- 空态文案应跟当前筛选条件相关，例如：
+ - 暂无待支付订单
+ - 暂无进行中订单
+ - 暂无售后订单
-## 5. 实现备注
+### 未登录态
-- 订单页重点是列表可扫读性
-- 一屏内要能快速看懂状态、门店、金额和下一步动作
+- 订单页属于顾客本人数据页
+- 未登录时不直接展示空订单列表
+- 应先走登录授权，再进入本人订单查询
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示残缺列表
+
+## 6. 实现备注
+
+- `T03` 的重点是列表可扫读性，不是后台查单控制台
+- 不要复用商家订单看板四列布局
+- 不要把 `支付方式 / 日期区间 / 关键词` 这类后台管理筛选搬到顾客端
+- 不要把 `催单 / 取餐码 / 再来一单` 做成所有订单都存在的固定按钮
+- 列表页负责“找单和看懂状态”，完整履约、售后和基础信息下沉到 `P05`
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/04-Tab-我的页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/04-Tab-我的页.md
index 4ca05f2..b1bf4b2 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/04-Tab-我的页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/04-Tab-我的页.md
@@ -3,76 +3,134 @@
- 页面编码：`T04`
- 页面层级：`Tab`
- 适用场景：`全场景`
-- 页面目标：集中展示用户身份、资产、服务和复购入口
-- 主要依赖组件：`G40`、`G41`、`G42`
+- 页面目标：作为顾客身份、资产、订单、服务和复购的聚合页，帮助顾客快速进入高频任务，而不是承接完整资产明细
+- 主要依赖组件：`G40`、`G41`、`G42`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
-1. 用户头部卡
-2. 资产总览区
+1. 身份头部卡
+2. 资产摘要区
3. 订单快捷入口区
-4. 会员与增长入口区
-5. 服务入口区
-6. 复购推荐区
+4. 核心入口区
+5. 复购区
+6. 底部辅助入口区
## 2. 区块说明
-### 2.1 用户头部卡
-- 使用 `G40`
-- 展示：
- - 头像
- - 昵称
- - 会员等级
- - 成长值进度摘要
+### 2.1 身份头部卡
+
+- 使用 `G40`
+- 这一块只承接最稳的顾客身份信息，不扩展成会员规则详情页
+- 至少展示：
+ - 头像
+ - 展示名
+ - 当前会员等级
+ - 入会信息
+- 可提供进入 `18-会员中心页.md` 的入口
+- 当前不把成长值进度、距离下一等级差值写成强必做能力
+
+### 2.2 资产摘要区
-### 2.2 资产总览区
- 使用 `G41`
-- 展示：
- - 优惠券数量
- - 积分余额
+- 这一块只做轻摘要，不做资产真源
+- 优先展示当前已证实、顾客可直接感知的资产：
+ - 积分
- 储值余额
- - 次卡数量 / 剩余次数摘要
+ - 会员权益入口
+- 如后续顾客资产聚合接口补齐，可继续补充更多摘要项
+- 当前不把以下内容冻结为首页必须显示的精确数字：
+ - 优惠券数量
+ - 次卡数量
+ - 次卡剩余次数总览
### 2.3 订单快捷入口区
-- 展示：
+
+- 这一块用于帮助顾客从“我的”快速回到订单任务
+- 快捷入口直接继承 `T03 订单页` 的顾客视角状态分组：
- 待支付
- 进行中
- 已完成
- - 售后 / 退款
-- 点击后跳转 `T03 订单页` 对应筛选状态
+ - 售后
+- 点击后跳转 `T03` 对应状态
+- 当前不把状态角标数量冻结为正式能力
+
+### 2.4 核心入口区
-### 2.4 会员与增长入口区
- 使用 `G42`
-- 入口包含：
+- 这一块承接高价值资产入口和服务入口
+- 可包含：
- 会员中心
- - 领券中心
- 积分商城
- 储值充值
- 次卡页
-
-### 2.5 服务入口区
-- 包含：
- 地址管理
- 消息中心
- 帮助中心
- - 联系客服
- - 协议与隐私
+- `领券中心` 可以作为导流入口保留，但当前只定义入口，不在本页解释完整活动规则
+- `消息中心` 当前也只保留入口，不在本页预设未读数和消息摘要列表
-### 2.6 复购推荐区
-- 展示最近订单和常点商品
-- 提供“再来一单”入口
+### 2.5 复购区
+
+- 这一块承接轻量复购，不做复杂推荐系统首页
+- 可承接的内容包括：
+ - 最近订单
+ - 常点商品
+ - 再来一单入口
+- 目标是帮助顾客快速重复购买，不解释复杂算法推荐逻辑
+- 当前以轻推荐为主，不冻结多层推荐策略
+
+### 2.6 底部辅助入口区
+
+- 这一块放低频但合理存在的辅助入口
+- 可保留：
+ - 协议与隐私
+ - 平台说明类入口
+- 当前不把客服系统能力写成后台已证实的正式前台契约
## 3. 页面状态
### 登录态
-- 展示完整资产与服务
+
+- 展示完整身份摘要、资产摘要、订单快捷入口和复购入口
+- 页面目标是帮助顾客快速进入下一步，而不是在当前页消费全部明细
### 未登录态
-- 展示基础入口
-- 资产卡片改为“登录后查看”
-## 4. 实现备注
+- 展示基础结构，但资产与订单相关内容应提示登录后查看
+- 主 CTA 应收敛为登录 / 授权
+- 不展示伪造的资产数字和订单数据
-- “我的”页要兼顾资产页和服务页
-- 顶部头部卡与资产总览区需要在视觉上形成核心焦点
+### 空态
+
+- 当复购区暂无最近订单或常点商品时，使用 `G03`
+- 可提供“去点餐”入口
+- 不因为某个区块无数据就让整个 `T04` 失效
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残资产信息
+
+## 4. 当前明确不冻结的能力
+
+- 优惠券数量与我的券包详情
+- 我的次卡实例清单
+- 订单快捷入口角标数量
+- 未读消息数
+- 到下一等级的精确差值
+- 首页直接展开完整消息列表
+- 首页直接展开完整帮助内容
+
+这些能力不是判定为永远不做，而是当前后台事实源还不足以把它们写成 `T04` 的正式前台契约。
+
+## 5. 实现备注
+
+- `T04` 的本质是聚合页，不是会员页、资产页、消息页或帮助页的替代品
+- 视觉重心应放在：
+ - 身份识别
+ - 高频资产摘要
+ - 高频任务入口
+- 页面不应因为想“看起来丰富”就堆太多数字、说明和规则
+- 复购区先强调最近订单和再来一单，不先扩成复杂推荐系统
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/05-门店选择页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/05-门店选择页.md
index e0f91cf..8943588 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/05-门店选择页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/05-门店选择页.md
@@ -2,51 +2,92 @@
- 页面编码：`P01`
- 页面层级：`二级页`
-- 页面目标：让用户选择合适门店，并明确当前场景是否可服务
-- 主要依赖组件：`G01`、`G12`
+- 页面目标：切换当前门店，并在当前场景下明确门店是否可下单、当前最关键的履约摘要是什么
+- 主要依赖组件：`G01`、`G12`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
2. 搜索区
-3. 场景筛选区
-4. 当前定位结果区
-5. 门店列表区
+3. 当前定位 / 地址结果区
+4. 门店列表区
## 2. 区块说明
### 2.1 搜索区
-- 支持按门店名称、商圈关键词搜索
-### 2.2 场景筛选区
-- 按 `外卖 / 自提 / 堂食` 过滤门店
+- 支持按门店名称、商圈或地址关键词搜索
+- 搜索的目标是快速找到门店，不是做后台式多条件筛选
-### 2.3 当前定位结果区
-- 显示当前定位城市 / 坐标结果
-- 提供重新定位动作
+### 2.2 当前定位 / 地址结果区
-### 2.4 门店列表区
-- 每个门店卡展示：
+- 这一块用于告诉顾客当前判断门店可服务性的依据是什么
+- 外卖场景下，应优先展示：
+ - 当前定位结果或当前收货地址
+ - 重新定位 / 切换地址入口
+- 自提场景下，可弱化定位，强调当前门店范围和营业信息
+- 堂食场景下，手动选店只是兜底，不是主入口
+
+### 2.3 门店列表区
+
+- 每张门店卡必须先回答“当前场景下能不能下单”
+- 至少展示：
- 门店名称
- - 距离
- - 营业状态
- 地址
- - 场景支持标签
- - 起送价 / 配送费 / 自提 / 堂食提示
-- 点击门店即切换当前门店并返回来源页
+ - 营业状态
+ - 当前支持的服务方式
+ - 当前场景下的关键履约摘要
+- 外卖场景下，门店卡至少要能表达：
+ - 是否可配送
+ - 预计送达
+ - 配送费
+ - 起送门槛
+- 自提场景下，门店卡至少要能表达：
+ - 是否支持自提
+ - 当前是否营业
+ - 最早可预约时段
+- 堂食场景下，门店卡应强调：
+ - 是否支持堂食
+ - 手动选店只是扫码失败时的兜底
+- 点击门店后不应默认无条件直接返回
+- 如存在购物车、地址不兼容或场景不兼容，应先给出确认和结果提示
## 3. 页面状态
### 默认态
-- 有门店列表
+
+- 有门店列表时，页面重点是帮助顾客判断“哪家店现在能服务我”
### 空态
-- 搜索无结果或当前区域无门店
-### 异常态
-- 定位失败时只展示手动选店模式
+- 搜索无结果或当前范围无可用门店时，使用 `G03`
+- 可提供重新定位、切换地址或清空筛选入口
-## 4. 实现备注
+### 定位失败态
-- 门店列表要把“能否下单”说清楚，不仅展示名字
+- 如定位失败，应退回手动选店模式
+- 不因为定位失败就阻断整页使用
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残门店信息
+
+## 4. 当前明确不冻结的能力
+
+- 直接向顾客暴露后台审核状态
+- 只凭门店名称和距离就默认可下单
+- 无条件点门店即切换并返回
+
+这些能力不是判定为永远不做，而是当前后台事实源更明确支持“按当前场景判断是否可服务”，不支持把门店选择页简化成纯列表切换器。
+
+## 5. 实现备注
+
+- `P01` 的重点是“选门店前先把当前场景下能否服务讲清楚”
+- 页面至少要让顾客看清楚：
+ - 当前依据什么在判断门店可用性
+ - 当前门店能不能下单
+ - 切店后会不会影响当前购物车和场景上下文
+- 堂食默认走扫码，不要把手动选店反写成堂食主入口
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/06-地址管理页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/06-地址管理页.md
index fce82cc..b050569 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/06-地址管理页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/06-地址管理页.md
@@ -2,46 +2,83 @@
- 页面编码：`P02`
- 页面层级：`二级页`
-- 页面目标：管理顾客常用收货地址，并服务外卖结算
-- 主要依赖组件：`G01`
+- 页面目标：管理顾客常用收货地址，并在外卖场景下前置说明当前地址对当前门店是否可配送
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
2. 地址列表区
-3. 新增地址按钮
+3. 新增地址入口区
## 2. 区块说明
### 2.1 地址列表区
-- 每个地址项展示：
+
+- 这一块不是普通通讯录，而是交易前置页
+- 每个地址项至少展示：
- 收货人姓名
- 手机号
- 详细地址
- 默认地址标签
- - 适用范围提示（可选）
+ - 当前门店下的配送适用状态
+- 配送适用状态不是可选说明，而是核心字段
+- 至少应支持表达：
+ - 可配送
+ - 超出最大距离
+ - 不在配送范围
+ - 其他不满足当前门店服务条件的提示
- 支持动作：
- 设为默认
- 编辑
- 删除
- 选择用于本次结算
+- 从结算进入时，应支持“选择地址后立即回传配送校验结果”
-### 2.2 新增地址按钮
-- 固定在页面底部或列表底部
-- 点击后进入编辑态（可独立页或表单弹层）
+### 2.2 新增地址入口区
+
+- 提供新增地址入口
+- 新增后应尽快回到“地址是否可配送”的判断结果上
+- 当前文档只冻结地址管理职责，不展开独立地址编辑页细节
## 3. 页面状态
### 默认态
-- 展示已有地址
+
+- 展示已有地址，并明确每个地址对当前门店是否可用
+- 页面重心不是存地址，而是让顾客知道“这个地址现在能不能送”
### 空态
-- 无地址时展示空态和新增 CTA
-### 异常态
-- 地址保存失败 / 删除失败时需要提示
+- 无地址时使用 `G03`
+- 提供新增地址 CTA
+- 不伪造默认地址和适配状态
-## 4. 实现备注
+### 保存或删除失败态
-- 如果另一位 AI 需要拆成“地址列表页 + 地址编辑页”，可以追加子页面，但当前文档以一个管理页为主
+- 明确提示失败原因
+- 不让列表停留在不确定状态
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残地址和配送状态
+
+## 4. 当前明确不冻结的能力
+
+- 把适用范围提示当成可有可无的文案
+- 延迟到支付前才告诉顾客地址不可配送
+- 把地址页写成通用通讯录页
+
+这些能力不是判定为永远不做，而是当前后台事实源已经明确表明“地址是否可配送”是外卖交易前置条件，必须在地址页和结算页前置处理。
+
+## 5. 实现备注
+
+- `P02` 的重点是“地址管理 + 配送可用性前置”
+- 页面至少要让顾客看清楚：
+ - 我有哪些地址
+ - 哪个地址现在能送
+ - 选中后是否可以直接用于本次订单
+- 如果后续拆成“列表页 + 编辑页”，也不能把配送状态判断从主列表里拿掉
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/07-商品详情抽屉.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/07-商品详情抽屉.md
index 2ed5933..7ddb03c 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/07-商品详情抽屉.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/07-商品详情抽屉.md
@@ -2,57 +2,209 @@
- 页面编码：`C01`
- 页面层级：`组件级抽屉`
-- 页面目标：完成商品选配，并把用户送入购物车
-- 主要依赖组件：`G22`、`G23`、`G24`
+- 页面目标：在不离开当前点餐上下文的前提下，完成商品选配、校验价格与库存、加入购物车
+- 主要依赖组件：`G22`、`G23`、`G24`、`G05`
+- 本页已按 `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md` 回写
## 1. 抽屉结构（从上到下）
-1. 商品图片区
+1. 商品媒体区
2. 商品基础信息区
-3. 规格做法区
-4. 加料区
-5. 数量与金额区
-6. 底部主操作区
+3. 当前可售与活动提示区
+4. 套餐分组区（套餐商品时出现）
+5. 规格做法区
+6. 加料区
+7. 数量与金额区
+8. 底部主操作区
## 2. 区块说明
-### 2.1 商品图片区
-- 展示主图，允许左右切换附图（可选）
+### 2.1 商品媒体区
+
+- 展示商品主图
+- 如商品存在多图，可支持轮播或横滑查看附图
+- 这一块只做商品感知补充，不扩展成长详情页
+- 抽屉头部应始终保留关闭动作
### 2.2 商品基础信息区
-- 展示：
+
+- 至少展示：
- 商品名称
- - 标签
- - 描述
- - 售价
- - 划线价
- - 月售 / 热销信息（可选）
+ - 商品标签
+ - 商品摘要描述
+ - 当前售价
+ - 划线价（如有）
+- 可选展示：
+ - 月售等弱经营信息
+ - 商品级包装费提示
+- 商品标签必须来自后台启用状态的标签配置，不手写运营词
+- 商品基础信息区不展示后台内部字段：
+ - `SPU`
+ - 同步平台状态
+ - 预警库存
+
+### 2.3 当前可售与活动提示区
+
+- 这一块用于解释当前商品在“当前门店 + 当前场景 + 当前时段”下的可购买状态
+- 可展示的状态提示包括：
+ - 已售罄
+ - 已下架
+ - 当前时段不可售
+ - 当前场景不可售
+ - 临时沽清
+- 如商品当前带有活动价，可在这里或价格区做轻提示：
+ - 秒杀价
+ - 限时折扣价
+ - 当前活动标签
+- 这一块不承接复杂优惠解释，满减、新客、会员折扣仍以页面级轻提示或结算页结果为主
+
+### 2.4 套餐分组区
+
+- 仅套餐商品出现
+- 套餐商品不能套用普通单品结构，必须单独承接套餐分组选择
+- 每个分组至少展示：
+ - 分组名称
+ - 必选 / 非必选
+ - `minSelect`
+ - `maxSelect`
+ - 当前已选状态
+- 如分组选项本身还带规格或加料，后续选择仍需纳入统一价格计算
+- 分组未满足最少选择数时，底部主按钮不可用
+
+### 2.5 规格做法区
-### 2.3 规格做法区
- 使用 `G23`
-- 支持单选 / 多组单选
-- 选择后实时刷新价格和库存
+- 规格做法区必须承接后台模板配置：
+ - `spec`
+ - `method`
+ - `single / multi`
+ - `isRequired`
+- 每组选项需要清楚展示：
+ - 选项名称
+ - 选项加价
+ - 当前选中状态
+- 选择规格或做法后，必须实时刷新：
+ - 当前价格
+ - 当前 SKU 结果
+ - 当前库存状态
+- 必选项未完成时，底部主按钮不可用
+
+### 2.6 加料区
-### 2.4 加料区
- 使用 `G24`
-- 支持多选和附加价格
+- 加料区必须承接后台约束：
+ - `required`
+ - `minSelect`
+ - `maxSelect`
+ - 选项价格
+ - 选项库存
+- 每个加料组选项至少展示：
+ - 名称
+ - 加价
+ - 可选状态
+- 当加料项库存不足或不可选时，需要明确禁用，不允许形成非法组合
+- 必选加料未满足最少选择数时，底部主按钮不可用
+
+### 2.7 数量与金额区
-### 2.5 数量与金额区
- 使用 `G22`
-- 实时展示当前组合总价
+- 实时展示当前合法组合下的金额结果
+- 至少包含：
+ - 当前数量
+ - 当前组合总价
+- 如果价格由以下因素变化，必须实时联动：
+ - SKU
+ - 规格做法
+ - 加料
+ - 套餐分组
+- 数量步进器需要受库存与当前可售状态约束
+- 不允许在非法组合未完成时，先放开数量增加再报错
-### 2.6 底部主操作区
-- 主按钮：加入购物车
-- 次按钮：立即购买（可选）
+### 2.8 底部主操作区
-## 3. 状态规则
+- 主按钮统一为：`加入购物车`
+- 不再保留 `立即购买` 分支
+- 主按钮文案与状态需要跟随当前选择结果变化：
+ - 规格未选全
+ - 加料未满足
+ - 套餐分组未完成
+ - 当前不可售
+ - 库存不足
+- 加入购物车成功后：
+ - 关闭抽屉
+ - 返回原点餐上下文
+ - 不应导致列表滚动位置丢失
-- 规格未选全时，主按钮不可用
-- 商品售罄时，显示不可售状态
-- 库存不足时，数量步进器受限
+## 3. 商品形态差异
-## 4. 实现备注
+### 简单单品
-- 抽屉应保留当前点餐页上下文
-- 关闭抽屉不应导致列表位置丢失
+- 无规格、无加料、非套餐
+- 这类商品通常可以在点餐页直接快速加购
+- 但当用户主动点开商品卡时，仍可使用本抽屉查看信息并加购
+
+### 复杂单品
+
+- 有规格 / 做法 / 加料
+- 必须通过本抽屉完成合法组合后才能加入购物车
+
+### 套餐商品
+
+- 带套餐分组
+- 必须通过本抽屉完成套餐分组选择
+- 不能按普通单品默认 SKU 逻辑处理
+
+## 4. 状态规则
+
+### 默认态
+
+- 商品可售
+- 当前价格和选项正常显示
+- 用户可继续选择规格、加料或套餐内容
+
+### 必选未完成态
+
+- 规格、做法、加料或套餐分组未选全时：
+ - 主按钮不可用
+ - 需要明确提示缺少的选择项
+
+### 库存不足态
+
+- 当前 SKU 或某加料项库存不足时：
+ - 对应选项禁用或提示库存不足
+ - 数量步进器受限
+ - 不允许继续提交非法组合
+
+### 当前不可售态
+
+- 商品因以下原因不可售时：
+ - 已售罄
+ - 已下架
+ - 当前时段不可售
+ - 当前场景不可售
+ - 临时沽清
+- 允许查看信息，但主按钮不可用
+
+### 价格联动态
+
+- 用户每次修改规格、加料、套餐分组或数量时：
+ - 总价立即刷新
+ - 不允许等到加入购物车后再结算
+
+### 加载失败态
+
+- 商品详情数据加载失败时，需要在抽屉内展示错误状态
+- 支持重试，不强行保留半残状态
+
+## 5. 实现备注
+
+- `C01` 是“选配抽屉”，不是完整商品详情页
+- 抽屉必须始终依附当前门店 + 当前场景上下文，不能跨上下文复用旧选择
+- 抽屉内不承接：
+ - 优惠券选择
+ - 储值选择
+ - 次卡核销
+ - 积分抵扣
+ - 支付动作
+- 点餐页负责决定“是否需要打开 C01”，`C01` 负责把不合法商品组合挡在购物车之外
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/08-购物车抽屉.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/08-购物车抽屉.md
index 139c678..de37301 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/08-购物车抽屉.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/08-购物车抽屉.md
@@ -2,50 +2,176 @@
- 页面编码：`C02`
- 页面层级：`组件级抽屉`
-- 页面目标：集中展示当前已选商品，并提供进入结算的最后一步确认
-- 主要依赖组件：`G22`、`G26`
+- 页面目标：汇总当前门店 + 当前场景下已选商品，支持快速改量，暴露失效商品并清理，提供唯一的去结算主路径
+- 主要依赖组件：`G22`、`G26`、`G03`、`G04`、`G05`
+- 本页已按 `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`、`03-结算与支付链路.md` 回写
## 1. 抽屉结构（从上到下）
1. 购物车头部
-2. 商品列表区
-3. 优惠与凑单提示区
-4. 底部结算区
+2. 失效商品提示区（有失效项时出现）
+3. 商品列表区
+4. 轻量提示区
+5. 底部结算区
## 2. 区块说明
### 2.1 购物车头部
-- 显示当前门店名
-- 显示“已选商品”标题
-- 提供清空购物车按钮
-### 2.2 商品列表区
+- 至少展示：
+ - 当前门店名称
+ - 当前场景
+ - “已选商品”标题
+- 右侧提供：
+ - 关闭抽屉
+ - 清空购物车按钮
+- 清空购物车属于高风险动作，需要二次确认或明显的防误触处理
+- 购物车头部不承接：
+ - 优惠券选择
+ - 支付方式选择
+ - 会员权益详细说明
+
+### 2.2 失效商品提示区
+
+- 当购物车内存在失效商品时，必须显式展示这一块
+- 这是购物车抽屉的核心职责之一，优先级高于优惠提示
+- 至少需要告诉用户：
+ - 有哪些商品已失效
+ - 为什么失效
+ - 当前是否还能去结算
+- 失效原因统一翻译成顾客可理解的口径：
+ - 已下架
+ - 已售罄
+ - 当前时段不可售
+ - 当前场景不可售
+- 建议提供：
+ - 一键清理失效商品
+ - 手动逐项删除
+- 在失效商品未处理前：
+ - 默认不允许直接去结算
+ - 或至少需要强提示先清理
+
+### 2.3 商品列表区
+
- 每个商品行使用 `G26`
-- 展示：
+- 商品列表只展示当前门店 + 当前场景下的购物车项
+- 不允许出现跨门店、跨场景混装逻辑
+- 每个商品行至少展示：
- 商品名
- 规格摘要
- 加料摘要
+ - 套餐选择摘要
- 单价
- 数量步进器
+ - 小计金额
+- 如果某项没有规格、加料或套餐摘要，可省略对应字段，但不能把已有组合信息丢掉
+- 数量步进器 `G22` 的职责：
+ - 快速增减当前购物车项数量
+ - 不改变已选规格、加料、套餐组合
+- 如用户需要修改商品组合，不应在购物车内直接重做复杂选配：
+ - 优先删除后重新选
+ - 或回到 `C01 商品详情抽屉` 重新选择
-### 2.3 优惠与凑单提示区
-- 展示：
- - 满减差额
- - 起送差额
- - 免配送费差额
- - 已命中活动摘要
+### 2.4 轻量提示区
-### 2.4 底部结算区
-- 展示总金额
-- 主按钮：去结算
+- 这一块只承接轻量提示，不做复杂优惠解释区
+- 可承接的内容：
+ - `delivery` 场景下差多少起送
+ - `delivery` 场景下差多少免配送费
+ - 当前已命中的轻量活动摘要
+- 已命中的活动摘要只允许做结果提示，例如：
+ - 已命中满减
+ - 当前有新客优惠
+ - 当前商品含秒杀 / 折扣商品
+- 这一块不承接：
+ - 优惠券列表
+ - 储值余额选择
+ - 次卡核销选择
+ - 积分抵扣
+ - 复杂叠加规则说明
+- `pickup / dine_in` 场景下不展示配送费与免配送费差额提示
-## 3. 状态规则
+### 2.5 底部结算区
-- 空购物车时展示空态
-- 商品失效时需标记并禁止结算，或提示清理失效商品
+- 这一块必须始终保持“唯一去结算主路径”
+- 至少展示：
+ - 已选商品总件数
+ - 当前总金额
+ - 主按钮“去结算”
+- 如当前是 `delivery` 场景且未达到起送门槛：
+ - 明确展示还差多少起送
+ - 主按钮不可用
+- 如存在失效商品未清理：
+ - 主按钮不可用或先引导清理
+- 点击主按钮后进入 `P03 结算确认页`
+- 未登录时，结算动作应按全局规则先走 `C03 登录授权弹层`
-## 4. 实现备注
+## 3. 场景差异规则
-- 购物车抽屉必须支持快速修改数量
-- 去结算按钮应只保留一个主路径，不做复杂分支
+### `delivery`
+
+- 可展示起送差额和免配送费差额
+- 需要跟当前地址与门店配送可用性保持一致
+- 如地址变更导致当前购物车商品不可正常结算，需要回到页面级状态处理
+
+### `pickup`
+
+- 不展示配送费、起送价、免配送费差额
+- 只保留商品确认、金额确认和去结算路径
+
+### `dine_in`
+
+- 不展示配送相关提示
+- 保持门店 + 桌号上下文一致
+- 不在购物车内虚构堂食规则：
+ - 合单
+ - 加菜
+ - 先付款
+
+## 4. 状态规则
+
+### 默认态
+
+- 存在有效商品
+- 商品行可以正常改量
+- 可以查看轻量提示并进入结算
+
+### 空购物车态
+
+- 空购物车时展示 `G03`
+- 提示返回点餐继续选择商品
+- 此时不显示去结算主按钮
+
+### 失效商品态
+
+- 购物车内存在失效商品时，必须高亮提示
+- 失效商品默认不能继续参与结算
+- 允许用户：
+ - 单个删除
+ - 一键清理失效项
+
+### 未达起送态
+
+- 仅 `delivery` 场景出现
+- 明确展示差额
+- 主按钮不可用
+
+### 数量受限态
+
+- 当数量受库存限制时：
+ - 步进器不可继续增加
+ - 需要给出明确提示
+
+### 加载失败态
+
+- 购物车数据异常时展示 `G04`
+- 支持重试，不直接显示过期或半残数据
+
+## 5. 实现备注
+
+- `C02` 首要解决的是“已选商品确认 + 失效清理 + 去结算”，不是优惠结算主战场
+- 商品组合的合法性应主要在 `C01` 完成，`C02` 负责承接结果并处理后续状态变化
+- 购物车里的活动提示只做轻结果，不提前解释完整优惠计算
+- 优惠券、储值、次卡、积分、支付方式统一放到 `P03` 或后续弹层承接
+- 去结算按钮必须只保留一个主路径，不做复杂分支
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/09-结算确认页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/09-结算确认页.md
index 5a1237d..86dc16b 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/09-结算确认页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/09-结算确认页.md
@@ -2,71 +2,241 @@
- 页面编码：`P03`
- 页面层级：`二级页`
-- 适用场景：`外卖 / 自提 / 堂食`
-- 页面目标：让用户确认履约信息、优惠和金额，并完成支付
-- 主要依赖组件：`G01`、`G30`、`G31`、`G32`、`G35`
+- 适用场景：`delivery / pickup / dine_in`
+- 页面目标：承接门店、场景和商品组合后的最终确认，向顾客解释金额来源，并完成提交订单与支付前确认
+- 主要依赖组件：`G01`、`G30`、`G31`、`G32`、`G35`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`、`03-结算与支付链路.md`、`05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 场景信息卡
+2. 场景履约信息卡
3. 商品清单区
-4. 优惠资产区
-5. 备注与附加信息区
-6. 费用明细区
-7. 底部支付栏
+4. 手动资产区
+5. 自动优惠与权益结果区
+6. 备注与附加信息区
+7. 费用明细区
+8. 支付方式区
+9. 底部提交栏
## 2. 区块说明
-### 2.1 场景信息卡
-- 外卖：展示收货地址、预计送达
-- 自提：展示门店、自提时间、取餐人信息
-- 堂食：展示门店、桌号、堂食说明
+### 2.1 场景履约信息卡
+
+- 使用 `G30`
+- 这一块的职责不是展示静态说明，而是确认“本单到底如何履约”
+- 场景差异：
+ - `delivery`
+ - 收货地址
+ - 是否可配送
+ - 预计送达
+ - 当前配送费
+ - 是否满足起送门槛
+ - `pickup`
+ - 门店名称
+ - 自提时间
+ - 取餐人信息
+ - `dine_in`
+ - 门店名称
+ - 桌号
+- 核心约束：
+ - `pickup` 不做自由文本时间输入
+ - 自提时间必须基于后台预览结果和时段配置生成可选时间
+ - `dine_in` 不展示配送相关模块
+- 点击行为：
+ - `delivery` 可进入 `P02 地址管理页`
+ - `pickup` 可重新选择自提时间
+ - `dine_in` 仅在桌号失效等异常下引导回扫码确认
### 2.2 商品清单区
-- 展示商品、规格、加料、数量、小计
-### 2.3 优惠资产区
+- 承接来自 `T02 / C01 / C02` 的合法商品组合结果
+- 至少展示：
+ - 商品名称
+ - 规格摘要
+ - 加料摘要
+ - 套餐选择摘要
+ - 数量
+ - 商品小计
+- 这一块只展示已确认的结果，不再重做商品选配
+- 如用户需要修改商品组合，优先返回购物车或点餐页，不在结算页内重新做复杂选配
+
+### 2.3 手动资产区
+
- 使用 `G32`
-- 入口包含：
- - 优惠券选择
- - 积分抵扣
+- 这一块只承接真正需要顾客主动选择的资产
+- 当前冻结为三类：
+ - 优惠券
- 储值余额支付
- - 次卡核销（适用时）
+ - 次卡核销
+- 每一类都需要展示：
+ - 当前是否可用
+ - 已选择结果或当前默认状态
+ - 不可用原因
+- 典型不可用原因：
+ - 不适用当前门店
+ - 不适用当前场景
+ - 不适用当前商品
+ - 未达到门槛
+ - 已过期 / 已用完
+- 当前不在本页冻结为正式主流程能力：
+ - 积分抵扣
+- 如后续需要承接更细的选择交互，应由 `C04 优惠选择弹层` 处理，不在本页直接展开长列表
-### 2.4 备注与附加信息区
-- 订单备注
-- 餐具选择
-- 其他补充字段（按场景可选）
+### 2.4 自动优惠与权益结果区
+
+- 这一块专门承接“系统自动命中”的结果，不让顾客手动勾选规则
+- 可承接的结果包括：
+ - 满减命中结果
+ - 新客有礼命中结果
+ - 会员折扣
+ - 会员免配送费权益
+ - 会员日额外折扣
+- 展示原则：
+ - 清楚告诉用户“已为你优惠多少”
+ - 必要时说明不叠加或已自动选择最优
+- 这一块不是优惠规则详情页，不展开后台活动配置细节
+
+### 2.5 备注与附加信息区
+
+- 可承接的输入项：
+ - 订单备注
+ - 餐具相关选择
+ - 场景需要的少量补充字段
+- 这里不扩展为大而杂的表单区
+- `pickup` 场景的核心仍是时间与取餐信息，不应混入无证据的附加规则
+- `dine_in` 场景不在这里新增“合单 / 加菜 / 先付款”等后台未证实项
+
+### 2.6 费用明细区
-### 2.5 费用明细区
- 使用 `G31`
-- 必须清楚展示所有金额构成
+- 这一块必须明确回答“为什么付这个金额”
+- 至少拆清楚：
+ - 商品金额
+ - 包装费
+ - 餐具费
+ - 配送费
+ - 自动优惠减免
+ - 手动资产减免
+ - 实付金额
+- 费用明细只展示顾客需要理解的收费项和减免项，不展示后台记账字段
+- 如果某项费用或减免来自门店规则、商品组合或资产使用，必须用顾客能理解的文案解释
+
+### 2.7 支付方式区
+
+- 这一块只展示本单当前支付方式摘要，不做复杂收银台
+- 当前小程序支付方式先收敛为：
+ - 微信支付
+ - 余额支付
+- `alipay / cash / card` 虽然存在于后台订单或交易口径中，但不前置为小程序支付方式选项
+- 如需切换支付方式，由 `C05 支付方式弹层` 承接
+- 当余额不足时，需要明确提示：
+ - 当前余额不足以完成支付
+ - 可切换微信支付或前往充值
+
+### 2.8 底部提交栏
-### 2.6 底部支付栏
- 使用 `G35`
-- 左侧显示实付金额
-- 右侧主按钮：提交订单并支付
+- 左侧展示：
+ - 实付金额
+ - 可选的优惠结果摘要
+- 右侧主按钮统一为：
+ - `提交订单并支付`
+- 主按钮点击后：
+ - 先完成结算校验
+ - 再进入支付方式确认
+- 未登录时，提交动作应先触发 `C03 登录授权弹层`
-## 3. 场景差异
+## 3. 场景差异规则
-### 外卖
-- 必须完成地址校验、起送价校验
+### `delivery`
-### 自提
-- 必须完成自提时间选择和取餐人信息校验
+- 必须完成地址校验
+- 必须完成配送可用性校验
+- 必须完成起送门槛校验
+- 页面中应明确展示：
+ - 收货地址
+ - 预计送达
+ - 配送费
+ - 是否满足起送
-### 堂食
-- 必须展示桌号，不展示配送相关字段
+### `pickup`
+
+- 必须选择有效自提时间
+- 自提时间来自后台可预约结果，不允许自由输入文本时间
+- 页面中应明确展示：
+ - 门店
+ - 自提时间
+ - 取餐人信息
+
+### `dine_in`
+
+- 必须展示门店与桌号
+- 不展示配送相关字段
+- 不在本页扩展堂食业务增强规则
## 4. 页面状态
-- 优惠不可用时展示原因
-- 地址超范围时禁止提交
-- 门店休息时禁止支付
+### 默认态
+
+- 场景信息完整
+- 商品组合合法
+- 费用明细完整
+- 可正常进入支付确认
+
+### 资产不可用态
+
+- 某项手动资产不可用时：
+ - 保留入口或结果位
+ - 明确展示不可用原因
+- 不允许只显示灰态而不给原因
+
+### 地址异常 / 不可配送态
+
+- 仅 `delivery` 场景出现
+- 当地址超出范围或当前不可配送时：
+ - 禁止提交订单
+ - 明确引导切换地址或切换门店
+
+### 未达起送态
+
+- 仅 `delivery` 场景出现
+- 明确展示还差多少起送
+- 禁止提交订单
+
+### 自提时间未完成态
+
+- 仅 `pickup` 场景出现
+- 当未选择或已失效时段时：
+ - 禁止提交订单
+ - 引导重新选择可用时间
+
+### 门店休息态
+
+- 当前门店休息或当前场景不可下单时：
+ - 禁止提交订单
+ - 明确说明原因
+
+### 余额不足态
+
+- 当顾客选中余额支付但余额不足时：
+ - 明确提示余额不足
+ - 引导切换微信支付或前往充值
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重新加载结算预览数据
## 5. 实现备注
-- 结算页核心是“信息确认 + 金额确认”
-- 所有会影响实付金额的项目都必须可见
+- `P03` 的核心不是“列很多入口”，而是让顾客确认履约方式、理解金额来源、完成必要选择
+- 结算页必须明确区分：
+ - 手动资产
+ - 自动优惠
+ - 权益结果
+- `积分抵扣` 当前不冻结为正式主流程能力
+- 结算页不应把所有优惠都做成同级可切换入口
+- 小程序支付方式先收敛为微信支付和余额支付
+- 结算页里的金额解释必须和门店规则、商品组合、资产使用结果保持一致
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/10-支付成功页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/10-支付成功页.md
index e6b5eba..9afa001 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/10-支付成功页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/10-支付成功页.md
@@ -2,41 +2,104 @@
- 页面编码：`P04`
- 页面层级：`二级页`
-- 页面目标：明确告诉用户支付已完成，并引导后续查看订单或继续点单
+- 页面目标：明确告诉顾客本次支付已经完成，并把顾客送往当前场景下最有价值的下一步动作
- 主要依赖组件：`G01`
+- 本页已按 `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`、`04-履约订单与售后链路.md` 回写
## 1. 页面结构（从上到下）
1. 成功状态区
2. 订单摘要区
3. 场景关键信息区
-4. 后续动作区
+4. 下一步动作区
## 2. 区块说明
### 2.1 成功状态区
-- 成功图标
-- 标题：支付成功
-- 副文案：订单已提交，等待商家处理
+
+- 展示支付成功的明确结果
+- 至少包含：
+ - 成功图标
+ - 标题：`支付成功`
+ - 副文案：订单已提交，等待商家处理
+- 这一区块只确认支付完成，不重新解释整套优惠计算过程
### 2.2 订单摘要区
-- 展示订单号、门店名称、支付金额
+
+- 至少展示：
+ - 订单号
+ - 门店名称
+ - 支付金额
+ - 支付方式
+- 支付方式口径与结算页保持一致：
+ - 微信支付
+ - 余额支付
+- 这一块的职责是帮助顾客快速确认“哪一单、付了多少、用什么付的”
### 2.3 场景关键信息区
-- 外卖：预计送达时间
-- 自提：取餐时间和取餐说明
-- 堂食：桌号与用餐状态
-### 2.4 后续动作区
-- 查看订单详情
-- 继续点餐 / 再逛逛
+- 这一块必须继承结算结果中的场景核心信息，不能做成一套通用空模板
+
+#### `delivery`
+
+- 至少展示：
+ - 预计送达时间或预计送达区间
+ - 当前履约进入下一步的简短说明
+- 当前不在本页冻结：
+ - 骑手轨迹
+ - 精确骑手位置地图
+
+#### `pickup`
+
+- 至少展示：
+ - 取餐时间
+ - 取餐提示
+- 当前不在本页强写：
+ - 取餐码一定存在
+ - 取餐号一定存在
+
+#### `dine_in`
+
+- 至少展示：
+ - 门店名称
+ - 桌号
+ - 当前用餐上下文提示
+- 当前不在本页扩展：
+ - 合单
+ - 加菜
+ - 先付款等堂食增强规则
+
+### 2.4 下一步动作区
+
+- CTA 必须收敛为少量高价值动作
+- 当前主动作保留：
+ - 查看订单详情
+ - 继续点餐 / 再逛逛
+- 不在本页堆过多次级操作，避免结果页变成控制面板
+- 如后续要补消息提醒、发票申请、客服等能力，应优先进入订单详情页再承接，而不是直接塞到成功页
## 3. 页面状态
-- 支付成功为唯一主状态
-- 若返回支付结果异常，应回退到结算页或订单详情页校验状态
+### 默认成功态
+
+- 支付成功是页面唯一主状态
+- 页面应立即告诉顾客：
+ - 支付已经完成
+ - 这是一张什么订单
+ - 下一步该看什么
+
+### 结果异常态
+
+- 若返回支付结果异常或状态不一致：
+ - 不停留在错误成功页
+ - 应回退到结算页或订单详情页做状态校验
## 4. 实现备注
-- 成功页停留时间不宜过长，应明确给出下一步 CTA
+- `P04` 是结果承接页，不是优惠解释页，也不是履约详情页
+- 成功页必须按场景给出最关键的信息：
+ - 外卖看送达
+ - 自提看取餐
+ - 堂食看桌号上下文
+- 页面停留不宜过长，但必须有明确 CTA，避免顾客成功后失去方向
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/11-订单详情页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/11-订单详情页.md
index f1ab0e8..722cb54 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/11-订单详情页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/11-订单详情页.md
@@ -2,70 +2,221 @@
- 页面编码：`P05`
- 页面层级：`二级页`
-- 页面目标：完整承接订单履约、售后和复购动作
-- 主要依赖组件：`G01`、`G31`、`G34`、`G35`
+- 页面目标：把订单完整讲清楚，让顾客理解当前状态，并在当前状态下执行唯一有价值的下一步动作
+- 主要依赖组件：`G01`、`G31`、`G34`、`G35`、`G05`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部状态头图区
-2. 场景信息区
+2. 场景履约信息区
3. 履约时间轴区
4. 商品清单区
5. 费用明细区
6. 订单基础信息区
-7. 底部操作栏
+7. 售后结果摘要区（有售后时出现）
+8. 底部操作栏
## 2. 区块说明
### 2.1 顶部状态头图区
-- 展示当前状态文案与辅助说明
-- 示例：
+
+- 这一块是强状态表达区，必须让顾客一眼知道：
+ - 这单现在是什么状态
+ - 接下来最可能发生什么
+- 状态文案必须使用顾客任务语言，不复用商家后台术语
+- 可承接的状态表达包括：
- 待支付
- - 商家已接单
+ - 商家处理中
- 制作中
- 配送中
- - 待自提
+ - 待取餐
- 已完成
- 退款中
+ - 已退款
+ - 已取消
+- 状态头图区可以带一条简短辅助说明，但不扩展成长说明页
-### 2.2 场景信息区
-- 外卖：收货地址、骑手状态、预计送达
-- 自提：取餐码、取餐时间、门店信息
-- 堂食：桌号、门店、是否可继续加菜
+### 2.2 场景履约信息区
+
+- 这一块按场景拆开表达，不用一套字段硬套三种履约
+
+#### `delivery`
+
+- 至少展示：
+ - 收货地址
+ - 收货人
+ - 联系方式
+- 可展示当前履约提示或预计送达信息
+- 当前不在本页冻结：
+ - 骑手轨迹
+ - 精确骑手地图
+
+#### `pickup`
+
+- 至少展示：
+ - 门店信息
+ - 取餐提示
+- 如后端后续补出取餐码 / 取餐号，可在本区承接
+- 当前不强制写死：
+ - 取餐码一定存在
+ - 取餐号一定存在
+
+#### `dine_in`
+
+- 至少展示：
+ - 门店信息
+ - 当前堂食上下文说明
+- 如订单快照中具备桌号，可回显桌号
+- 当前不把“完整桌号回显”冻结为所有堂食订单的必有字段
+- 当前不在本页引入：
+ - 继续加菜
+ - 合单
+ - 先付款
### 2.3 履约时间轴区
+
- 使用 `G34`
-- 展示订单关键节点时间
+- 展示订单关键时间节点
+- 时间轴目标是帮助顾客理解“进展到哪里了”，不是复刻商家履约操作流
+- 可展示的节点包括：
+ - 下单
+ - 支付成功
+ - 商家处理中 / 制作中
+ - 配送中 / 待取餐 / 堂食进行中
+ - 已完成
+ - 退款处理结果
+- 时间轴节点数量和名称不在当前文档里写死过细，以后端结果为准
### 2.4 商品清单区
-- 展示商品、规格、加料、数量
+
+- 这一块完整承接订单中的商品结果
+- 至少展示：
+ - 商品名称
+ - 规格摘要
+ - 加料摘要
+ - 套餐选择摘要
+ - 数量
+ - 商品小计
+- 这是订单结果区，不再允许编辑商品组合
+- 如后续支持“再来一单”，也应基于这里的结果回流到点餐页，而不是在本区直接改单
### 2.5 费用明细区
+
- 使用 `G31`
-- 展示所有金额构成
+- 至少展示顾客可理解的金额构成：
+ - 商品金额
+ - 包装费
+ - 餐具费
+ - 配送费
+ - 优惠减免
+ - 实付金额
+- 金额口径需与结算页保持一致
+- 不展示后台财务记账字段
### 2.6 订单基础信息区
-- 展示订单号、下单时间、支付方式、支付时间等
-### 2.7 底部操作栏
+- 至少展示：
+ - 订单号
+ - 下单时间
+ - 支付方式
+ - 支付时间
+ - 备注
+- 如后续存在更多稳定的基础字段，可继续扩展，但不在当前把后台筛选字段直接暴露给顾客
+
+### 2.7 售后结果摘要区
+
+- 当订单已进入退款中 / 已退款等售后状态时，显示这一块
+- 至少展示：
+ - 当前退款状态
+ - 退款金额
+ - 退款原因摘要
+- 这一块只做摘要和导流
+- 需要查看更完整售后结果时，进入 `P07 退款详情页`
+
+### 2.8 底部操作栏
+
- 使用 `G35`
-- 动作随状态变化：
+- 动作必须按状态收敛，不做商家控制面板
+
+#### `待支付`
+
+- 可保留：
- 继续支付
- 取消订单
+
+#### `进行中`
+
+- 主动作以“查看履约信息”为主
+- 如后续退款申请能力补齐，可在允许时显示“申请退款”
+- 当前不把以下能力冻结为固定按钮：
- 催单
- - 申请退款
+ - 骑手轨迹
+ - 取餐码查看
+
+#### `已完成`
+
+- 可保留：
- 去评价
- 再来一单
+#### `售后`
+
+- 可保留：
+ - 查看退款详情
+
+#### 结果态
+
+- 已取消等只读结果态，以查看信息为主
+- 不堆叠无意义操作
+
## 3. 页面状态
-- 待支付态
-- 履约进行态
-- 已完成态
-- 退款中态
-- 已退款态
+### 待支付态
+
+- 明确告诉顾客：
+ - 订单尚未支付
+ - 是否还能继续支付
+- 底部操作以继续支付为主
+
+### 履约进行态
+
+- 明确告诉顾客订单正在被处理
+- 重点在状态解释和履约信息，不在页面里堆大量动作
+
+### 已完成态
+
+- 重点回到评价和复购
+- 页面不再强调履约过程焦虑信息
+
+### 退款中态
+
+- 明确告诉顾客售后正在处理中
+- 提供查看退款结果的稳定入口
+
+### 已退款态
+
+- 明确告诉顾客退款已经完成
+- 保留查看退款详情动作
+
+### 已取消态
+
+- 页面以结果展示为主
+- 不再展示与履约相关的动作
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不直接停留在半残状态
## 4. 实现备注
-- 订单详情页是强状态页面，顶部状态区必须足够明确
+- `P05` 是强状态详情页，核心是“讲清状态 + 讲清订单 + 给出当前唯一有价值的动作”
+- 订单详情页不复用商家侧动作：
+ - 接单
+ - 拒单
+ - 出餐完成
+ - 确认送达
+- 外卖、自提、堂食三种场景要分别表达，但当前不把未证实能力写死
+- 完整售后结果进入 `P07`，最小退款申请进入 `P06`，评价进入 `P08`
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/12-退款申请页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/12-退款申请页.md
index ab411c4..530105e 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/12-退款申请页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/12-退款申请页.md
@@ -2,45 +2,104 @@
- 页面编码：`P06`
- 页面层级：`二级页`
-- 页面目标：让用户提交退款原因与说明，进入售后流程
-- 主要依赖组件：`G01`
+- 页面目标：在订单允许申请售后时，低阻力提交一份最小可用退款申请，并把顾客送入稳定的退款结果查看链路
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
2. 可退款订单摘要区
-3. 退款原因区
-4. 补充说明区
-5. 提交按钮区
+3. 可退金额区
+4. 退款原因区
+5. 补充说明区
+6. 提交按钮区
## 2. 区块说明
### 2.1 可退款订单摘要区
-- 展示门店、订单号、商品摘要、当前可退金额
-### 2.2 退款原因区
-- 提供预设原因列表
-- 例如：
- - 商品与描述不符
- - 配送超时
- - 少送漏送
- - 不想要了
- - 其他原因
+- 这一块用于先确认“你正在给哪一单发起退款申请”
+- 至少展示：
+ - 门店名称
+ - 订单号
+ - 商品摘要
+- 这一区块只做摘要确认，不重复展开完整订单详情
-### 2.3 补充说明区
-- 文本输入框
-- 可选上传凭证图片（如另一位 AI 需要扩展）
+### 2.2 可退金额区
-### 2.4 提交按钮区
-- 主按钮：提交退款申请
+- 明确展示当前可退金额
+- 如果后端后续补充更多退款范围解释，可在这里扩展
+- 当前不把以下能力冻结为正式必有：
+ - 部分退款逐商品明细
+ - 复杂退款规则解释
+
+### 2.3 退款原因区
+
+- 页面需要提供退款原因选择
+- 当前只冻结“需要有退款原因”这一能力，不冻结具体原因枚举体系
+- 也就是说：
+ - 可以有预设原因列表
+ - 也可以保留“其他原因”
+- 但不在本页把原因分类、售后责任判定、复杂规则写死
+
+### 2.4 补充说明区
+
+- 提供文本输入框，允许用户补充说明
+- 目标是帮助顾客补一句必要背景，而不是做复杂售后表单
+- 当前不把以下能力冻结为正式必做：
+ - 图片凭证上传
+ - 多段说明
+ - 按商品逐项问题说明
+
+### 2.5 提交按钮区
+
+- 主按钮统一为：`提交退款申请`
+- 提交后应进入 `P07 退款详情页`
+- 页面不做复杂多分支售后流转
## 3. 页面状态
-- 原因未选时按钮不可提交
-- 提交中显示 loading
+### 默认态
+
+- 订单允许申请退款
+- 顾客可以看到订单摘要、可退金额，并填写最小必要信息
+
+### 原因未完成态
+
+- 未选择退款原因时，按钮不可提交
+- 不允许只提示报错而不明确缺少项
+
+### 提交中态
+
+- 提交按钮显示 loading
+- 避免重复提交
+
+### 提交成功态
+
- 提交成功后跳转 `P07 退款详情页`
+- 不停留在申请页反复确认
+
+### 不可申请态
+
+- 当当前订单不允许申请退款时：
+ - 不继续展示正常申请表单
+ - 明确提示当前不可申请
+ - 引导回订单详情或退款结果页
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残申请表单
## 4. 实现备注
-- 页面目标是低阻力提交，不宜放过多冗余字段
+- `P06` 的目标是“低阻力申请”，不是完整售后系统
+- 当前不冻结以下复杂能力：
+ - 部分退款
+ - 按商品逐项退款
+ - 处理 SLA 展示
+ - 固定原因枚举体系
+ - 图片凭证上传为必做
+- 页面是否显示入口，应由 `P05` 中的订单状态和后端能力标记共同决定
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/13-退款详情页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/13-退款详情页.md
index f881fdd..9a7be48 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/13-退款详情页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/13-退款详情页.md
@@ -2,8 +2,9 @@
- 页面编码：`P07`
- 页面层级：`二级页`
-- 页面目标：展示退款申请的当前处理状态、时间轴和处理结果
-- 主要依赖组件：`G01`、`G34`
+- 页面目标：给顾客一个稳定的退款结果查看页，承接退款状态、退款金额、退款原因、处理时间线和关联订单信息
+- 主要依赖组件：`G01`、`G34`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 回写
## 1. 页面结构（从上到下）
@@ -12,36 +13,83 @@
3. 退款金额与原因区
4. 退款时间轴区
5. 订单关联信息区
+6. 后续动作区
## 2. 区块说明
### 2.1 退款状态头图区
-- 展示当前退款状态：
+
+- 这一块首先回答“这笔退款现在进行到哪一步了”
+- 状态文案应使用顾客能理解的结果语言
+- 可展示的结果包括：
- 已提交
- 处理中
- 已退款
- 已拒绝
-- 同时展示简要说明文案
+- 可搭配一条简短辅助说明，但不展开成复杂审核系统说明
+- 当前不把后台内部处理节点和商家处理动作直接暴露给顾客
### 2.2 退款金额与原因区
-- 展示退款金额
-- 展示退款原因与用户补充说明
+
+- 至少展示：
+ - 退款金额
+ - 退款原因
+ - 顾客补充说明摘要（如有）
+- 如果后端后续补充驳回原因，可直接在这一块显示
+- 这一块只展示顾客关心的结果信息，不展示后台审批字段
### 2.3 退款时间轴区
+
- 使用 `G34`
-- 展示：申请时间、商家处理时间、退款完成时间等
+- 时间轴目标是帮助顾客理解处理进展，而不是定义一套固定售后流程图
+- 至少需要承接：
+ - 申请提交时间
+ - 后续处理结果时间
+- 如后端存在更多稳定节点，可继续补充
+- 当前不把时间线节点数量、名称、阶段数写死过细
### 2.4 订单关联信息区
-- 展示订单号、门店、商品摘要
-- 提供返回订单详情的入口
+
+- 至少展示：
+ - 订单号
+ - 门店名称
+ - 商品摘要
+- 这一块用于帮助顾客确认“这是哪一单的退款”
+- 可提供返回订单详情的入口
+
+### 2.5 后续动作区
+
+- CTA 应收敛为结果查看后的高价值动作
+- 可保留：
+ - 返回订单详情
+ - 返回订单列表
+- 不在本页扩展复杂售后客服流转
## 3. 页面状态
-- 处理中
-- 已退款
-- 已拒绝
+### 处理中
+
+- 明确告诉顾客退款仍在处理
+- 保留时间线和订单关联信息，减少不确定感
+
+### 已退款
+
+- 明确告诉顾客退款已经完成
+- 保留退款金额和关联订单信息
+
+### 已拒绝
+
+- 如后端提供驳回原因，应明确展示
+- 不只显示“已拒绝”结果，不给原因
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残结果页
## 4. 实现备注
-- 拒绝状态必须明确展示驳回原因
+- `P07` 是结果查看页，不是退款申请页，也不是完整售后工作台
+- 页面职责重点是“稳定解释结果”，不是提前冻结复杂售后阶段
+- 如后续后端补充更多退款节点或驳回信息，可在当前结构内扩展，不需要重新改页面职责
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/14-评价页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/14-评价页.md
index 8a92463..11df594 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/14-评价页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/14-评价页.md
@@ -2,55 +2,99 @@
- 页面编码：`P08`
- 页面层级：`二级页`
-- 页面目标：完成订单评价，并引导商家回复与评价奖励闭环
-- 主要依赖组件：`G01`
+- 页面目标：让顾客在订单完成后提交最小可用评价，完成评分、评价内容和晒单上传闭环
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md` 与 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
2. 订单摘要区
-3. 星级评分区
-4. 快捷评价标签区
-5. 文本评价区
-6. 图片上传区
-7. 匿名开关区
-8. 提交按钮区
+3. 评分区
+4. 文本评价区
+5. 图片上传区
+6. 提交操作区
## 2. 区块说明
### 2.1 订单摘要区
-- 展示门店名称和商品摘要
-### 2.2 星级评分区
-- 选择 1-5 星
-- 星级变化可联动文案提示
+- 这一块先帮助顾客确认“我正在评价哪一单”
+- 至少展示：
+ - 门店名称
+ - 商品摘要
+ - 下单时间或完成时间
+- 这一块只做识别，不扩展成订单详情页替代品
-### 2.3 快捷评价标签区
-- 根据评分展示标签
-- 例如：
- - 味道不错
- - 包装精致
- - 配送很快
- - 分量足
+### 2.2 评分区
-### 2.4 文本评价区
-- 支持自由输入评价内容
+- 评分是本页最核心的输入项
+- 支持 1 到 5 星
+- 评分后可配一条轻量文案辅助顾客理解当前选择
+- 当前不把评分后联动的复杂标签体系写成正式能力
-### 2.5 图片上传区
-- 支持晒单图片上传
+### 2.3 文本评价区
-### 2.6 匿名开关区
-- 允许用户匿名评价
+- 支持顾客输入自由评价内容
+- 目标是补充对本次消费体验的主观反馈
+- 当前文档只冻结“可输入评价内容”这一能力
+- 文本长度限制、敏感词处理、是否必填等规则以后端提交契约为准
-### 2.7 提交按钮区
-- 主按钮：提交评价
+### 2.4 图片上传区
+
+- 支持上传晒单图片
+- 这一能力已有后台文件上传类型支撑，可以作为正式页面能力保留
+- 图片上传用于补充真实消费反馈，不扩展成复杂内容社区
+- 上传数量上限、压缩规则、审核规则当前不在本页写死
+
+### 2.5 提交操作区
+
+- 主按钮：`提交评价`
+- 页面只保留一个主提交流程，不叠加复杂分支动作
+- 提交成功后应返回稳定结果反馈，不在本页扩展营销弹窗闭环
## 3. 页面状态
-- 未评分时按钮不可提交
-- 提交成功后提示是否返回订单详情或继续浏览
+### 未评分态
-## 4. 实现备注
+- 未完成评分前，提交按钮不可用
+- 页面应优先引导顾客先完成星级选择
-- 评价成功后可弹出“获得积分”提示，但不应阻塞主流程
+### 可提交态
+
+- 完成评分后允许提交
+- 文本和图片在当前冻结范围内默认按可选输入处理
+
+### 提交成功态
+
+- 明确提示评价已提交成功
+- 可提供：
+ - 返回订单详情
+ - 返回订单列表
+- 如果后台配置了评价奖励积分，可使用轻提示说明获得奖励
+- 奖励提示不能反过来主导页面，也不做复杂营销弹窗
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残页面
+
+## 4. 当前明确不冻结的能力
+
+- 快捷评价标签
+- 匿名评价开关
+- 商家回复展示与回复闭环
+- 评价后分享裂变玩法
+- 复杂积分任务说明
+
+这些能力不是判定为永远不做，而是当前后台事实源还不足以把它们写成正式前台契约。
+
+## 5. 实现备注
+
+- `P08` 是最小评价提交页，不是内容社区页，也不是营销奖励页
+- 页面重点只有三件事：
+ - 让顾客确认订单
+ - 让顾客完成评价输入
+ - 让顾客稳定提交成功
+- 评价奖励积分只作为成功反馈中的轻提示，与 `我的` 或积分资产联动即可
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/15-领券中心页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/15-领券中心页.md
index 4b7e161..4bbe40f 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/15-领券中心页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/15-领券中心页.md
@@ -2,41 +2,91 @@
- 页面编码：`P09`
- 页面层级：`二级页`
-- 页面目标：集中展示可领取优惠券，并引导回到点餐使用
-- 主要依赖组件：`G01`、`G43`
+- 页面目标：集中展示当前门店、当前场景下可见的券模板，并引导顾客回到点餐主链路使用
+- 主要依赖组件：`G01`、`G43`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 券分类筛选区
-3. 优惠券列表区
-4. 底部引导区
+2. 轻筛选区
+3. 券模板列表区
+4. 底部导购区
## 2. 区块说明
-### 2.1 券分类筛选区
-- 可按全部、满减券、折扣券、免配送费券筛选
+### 2.1 轻筛选区
+
+- 这一块用于帮助顾客快速收缩券模板范围
+- 可保留的类型筛选包括：
+ - 全部
+ - 满减券
+ - 折扣券
+ - 免配送费券
+- 筛选的目标是提升列表可扫读性，不是做复杂券管理后台
+
+### 2.2 券模板列表区
-### 2.2 优惠券列表区
- 使用 `G43`
-- 每张券卡必须展示：
+- 这一块是本页核心内容，展示当前可见券模板
+- 每张券卡至少展示：
- 券名称
- - 金额 / 折扣
+ - 金额或折扣
- 使用门槛
- 有效期
- - 适用门店 / 场景
- - 领取状态
+ - 适用门店
+ - 适用场景
+- 如后台具备每人限领、开放领取、暂停领取等模板状态，可用于结果说明
+- 当前页面重点是“这张券是什么、能不能领、适合什么场景”
-### 2.3 底部引导区
-- 提供“去点餐”入口
+### 2.3 底部导购区
+
+- 这一块用于把顾客从领券中心导回主交易链路
+- 可保留：
+ - 去点餐
+ - 返回首页活动区
+- 领券中心是导购页，不应在本页内形成封闭玩法
## 3. 页面状态
-- 默认态：有可领取券
-- 空态：无券可领
-- 已领取态：按钮改为已领取或去使用
+### 默认态
-## 4. 实现备注
+- 有可见券模板时，优先展示券列表
+- 页面目标是让顾客快速理解“现在有哪些券值得领”
-- 领取动作应尽量轻量，领取成功后不强制跳转
+### 空态
+
+- 当当前门店、当前场景下没有可见券模板时，使用 `G03`
+- 可提供返回点餐或返回首页的导购入口
+- 不伪造券模板数据
+
+### 已领取结果提示态
+
+- 如后续领券动作契约补齐，可展示轻量领取成功提示
+- 结果提示应导流回点餐或我的资产页
+- 当前不把个人领取状态流写成强依赖页面结构
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残券数据
+
+## 4. 当前明确不冻结的能力
+
+- 顾客个人已领取状态
+- 剩余可领次数
+- 去使用状态按钮
+- 我的券包详情
+- 完整领券动作接口细节
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“券模板聚合”，还不足以把顾客个人券资产状态写成正式前台契约。
+
+## 5. 实现备注
+
+- `P09` 的重点是“券模板聚合 + 导流回点餐”
+- 页面至少要让顾客看清楚：
+ - 这是什么券
+ - 适用什么门店和场景
+ - 领完之后去哪里用
+- 不要把领券中心误写成“我的优惠券”资产页
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/16-秒杀活动页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/16-秒杀活动页.md
index 5d1e577..b402694 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/16-秒杀活动页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/16-秒杀活动页.md
@@ -2,40 +2,102 @@
- 页面编码：`P10`
- 页面层级：`二级页`
-- 页面目标：承接强时效抢购活动，提升转化
-- 主要依赖组件：`G01`、`G21`
+- 页面目标：承接强时效、强库存、强场次的秒杀活动会场，并把顾客导回标准商品购买链路
+- 主要依赖组件：`G01`、`G21`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 秒杀头图区
+2. 活动头部区
3. 场次切换区
4. 秒杀商品列表区
## 2. 区块说明
-### 2.1 秒杀头图区
-- 展示活动标题、主视觉、倒计时
+### 2.1 活动头部区
+
+- 这一块负责先建立秒杀会场的时间紧迫感
+- 至少突出：
+ - 当前场次
+ - 倒计时
+ - 是否预热
+- 头部区目标是帮助顾客理解“现在能不能抢、还剩多少时间”
### 2.2 场次切换区
-- 展示当前场次、即将开始场次、已结束场次
+
+- 秒杀页必须保留场次概念，不能被写成普通折扣页
+- 可展示：
+ - 当前进行中场次
+ - 即将开始场次
+ - 已结束场次
+- 场次切换是秒杀页核心信息架构，不建议删掉
### 2.3 秒杀商品列表区
-- 商品卡展示：
+
+- 每张商品卡至少展示：
- 商品图片
+ - 商品名称
- 秒杀价
- 原价
- - 剩余库存 / 已售比例
- - 每单限购
- - 立即抢购
+ - 剩余库存或抢购进度
+ - 每人限购
+ - 抢购按钮
+- 商品卡必须强化“抢”的信息密度：
+ - 时间
+ - 库存
+ - 限购
+- 点击商品后仍然进入正常商品详情、加购、购物车、结算主链路
## 3. 页面状态
-- 未开始态
-- 进行中态
-- 已结束态
+### 预热态
-## 4. 实现备注
+- 明确告诉顾客秒杀尚未开始
+- 可展示开始时间和当前场次信息
+- 不允许伪装成可购买状态
-- 秒杀页要突出时间紧迫感和库存稀缺感
+### 进行中态
+
+- 强调倒计时和库存变化
+- 这是页面的核心转化状态
+
+### 已售罄态
+
+- 如商品库存已空，应明确提示售罄
+- 不继续给出误导性的抢购按钮
+
+### 已结束态
+
+- 明确告诉顾客当前场次已经结束
+- 可引导查看其他场次或返回点餐
+
+### 空态
+
+- 当当前门店、当前场景下暂无秒杀活动时，使用 `G03`
+- 不伪造活动场次和商品列表
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残活动信息
+
+## 4. 当前明确不冻结的能力
+
+- 独立秒杀收银台
+- 绕开商品详情直接成交的特殊交易链路
+- 复杂抢购资格体系页
+- 秒杀分享裂变闭环
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“场次、库存、秒杀价、限购”，还不足以把更多营销扩展写成正式前台契约。
+
+## 5. 实现备注
+
+- `P10` 的重点是“场次 + 倒计时 + 库存 + 限购”
+- 页面应该优先回答顾客四个问题：
+ - 现在是哪一场
+ - 还有多久结束
+ - 还有没有库存
+ - 我最多能抢多少
+- 秒杀页是活动会场，不是独立下单系统
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/17-限时折扣活动页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/17-限时折扣活动页.md
index 026199f..383894d 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/17-限时折扣活动页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/17-限时折扣活动页.md
@@ -2,42 +2,93 @@
- 页面编码：`P11`
- 页面层级：`二级页`
-- 页面目标：承接限时折扣活动，集中展示折扣商品
-- 主要依赖组件：`G01`、`G21`
+- 页面目标：承接限时折扣商品会场，让顾客快速浏览当前时段更省的商品集合，并导回标准商品购买链路
+- 主要依赖组件：`G01`、`G21`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 活动头图区
-3. 活动时间筛选区
+2. 活动头部区
+3. 时间窗口区
4. 折扣商品列表区
## 2. 区块说明
-### 2.1 活动头图区
-- 展示活动标题、当前折扣主题、时间说明
+### 2.1 活动头部区
-### 2.2 活动时间筛选区
-- 当前进行中
-- 即将开始
-- 已结束
+- 这一块先建立限时折扣的活动认知
+- 至少展示：
+ - 活动名称
+ - 日期范围
+ - 当前时段说明
+- 如果是循环活动，可补充周几信息
+- 头部区要突出“现在买更省”，而不是“现在必须抢”
+
+### 2.2 时间窗口区
+
+- 限时折扣页要强调时间窗口，而不是秒杀场次
+- 可表达：
+ - 当前进行中
+ - 即将开始
+ - 已结束
+- 如果后端提供循环时段，可在这一块承接周期信息
### 2.3 折扣商品列表区
-- 商品卡展示：
- - 图片
+
+- 每张商品卡至少展示：
+ - 商品图片
- 商品名称
- 折扣价
- 原价
- 折扣力度
- - 立即购买
+ - 每人限购
+ - 去购买按钮
+- 商品卡重点表达“省了多少、现在值不值得买”
+- 点击商品后仍然进入正常商品详情、加购、购物车、结算主链路
## 3. 页面状态
-- 进行中：可购买
-- 未开始：展示开始时间
-- 已结束：置灰展示
+### 进行中态
-## 4. 实现备注
+- 当前活动生效，顾客可以正常进入购买链路
+- 页面应优先突出折扣价和折扣力度
-- 与秒杀页相比，限时折扣页要弱化“抢”，强化“省”
+### 未开始态
+
+- 明确展示开始时间或即将开始信息
+- 不误导顾客认为当前可直接成交
+
+### 已结束态
+
+- 明确展示活动已结束
+- 可引导返回点餐页或查看其他活动
+
+### 空态
+
+- 当当前门店、当前场景下暂无折扣活动时，使用 `G03`
+- 不伪造折扣列表和时间窗口
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残活动数据
+
+## 4. 当前明确不冻结的能力
+
+- 与秒杀共用一套会场结构
+- 独立折扣下单系统
+- 复杂活动分享裂变页
+- 超出商品主链路的特殊交易流程
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“折扣价、时间窗口、周期规则、限购”，还不足以把更多活动扩展写成正式前台契约。
+
+## 5. 实现备注
+
+- `P11` 的重点是“折扣强度 + 时间窗口 + 商品集合”
+- 页面应该优先回答顾客三个问题：
+ - 现在哪些商品更省
+ - 折扣持续到什么时候
+ - 我点进去之后怎么买
+- 限时折扣页和秒杀页必须分开表达，不要用一套模板糊过去
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/18-会员中心页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/18-会员中心页.md
index 2756984..bdc9557 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/18-会员中心页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/18-会员中心页.md
@@ -2,46 +2,103 @@
- 页面编码：`P12`
- 页面层级：`二级页`
-- 页面目标：展示会员等级、成长值、权益和升级路径
-- 主要依赖组件：`G01`、`G40`
+- 页面目标：告诉顾客自己当前是什么会员等级、当前能享受什么权益，以及会员等级体系如何运作
+- 主要依赖组件：`G01`、`G40`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 会员头部卡
-3. 成长值进度区
-4. 权益总览区
-5. 等级说明区
-6. 会员日 / 生日权益区
+2. 会员头部区
+3. 当前权益区
+4. 等级说明区
+5. 专项权益说明区
## 2. 区块说明
-### 2.1 会员头部卡
-- 展示头像、昵称、当前会员等级、等级标识
+### 2.1 会员头部区
-### 2.2 成长值进度区
-- 展示当前成长值
-- 展示距离下一等级差值
+- 这一块先回答顾客“我现在是什么等级”
+- 至少展示：
+ - 当前会员等级
+ - 等级标识
+ - 入会时间
+- 如身份信息需要补充，可展示头像和展示名
+- 这一块不扩展成复杂成长值分析页
-### 2.3 权益总览区
-- 展示当前可享权益：
+### 2.2 当前权益区
+
+- 这是本页最核心的内容区，重点表达“我现在能享受什么”
+- 可承接的权益包括：
- 会员折扣
- 积分倍率
+ - 生日权益
+ - 每月赠券
+ - 免配送费
+ - 优先配送
+ - 会员日额外权益
+- 权益文案要用顾客能直接理解的结果语言
+- 不把后台配置项原样暴露成顾客不可理解的规则字段
+
+### 2.3 等级说明区
+
+- 这一块用于说明会员体系如何运作
+- 至少说明：
+ - 各等级名称
+ - 各等级核心权益差异
+ - 升级条件
+ - 降级窗口或有效周期规则
+- 这一块的目标是让顾客理解等级体系，不是做复杂成长任务页
+
+### 2.4 专项权益说明区
+
+- 对需要单独解释的权益做补充说明
+- 当前优先承接：
- 生日权益
- 会员日权益
-
-### 2.4 等级说明区
-- 展示各等级及对应权益
-
-### 2.5 会员日 / 生日权益区
-- 单独说明会员日和生日特权
+- 如果后续还有稳定的专项权益，也可在这一块扩展
+- 这一块用于解释权益口径，不扩展成活动导购页
## 3. 页面状态
-- 已登录会员态
-- 未登录提示态
+### 已登录会员态
-## 4. 实现备注
+- 展示完整等级信息、当前权益和等级说明
+- 页面重心是帮助顾客理解可用权益，而不是刺激顾客研究复杂成长路径
-- 会员中心要重点突出“当前能享受什么”和“如何升级”
+### 已登录非会员态
+
+- 如业务存在“已登录但未入会”状态，应明确提示入会价值
+- 可展示会员权益摘要和入会引导
+- 不展示伪造的等级与权益数据
+
+### 未登录态
+
+- 会员中心属于顾客身份页
+- 未登录时应先引导登录 / 授权，再查看正式会员信息
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残等级数据和权益说明
+
+## 4. 当前明确不冻结的能力
+
+- 当前成长值数值展示
+- 距离下一等级的精确差值
+- 强依赖成长进度条的主视觉
+- 复杂任务制升级路径
+- 与活动导购深度耦合的动态营销模块
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“等级与权益”，还不足以把复杂成长进度写成正式前台契约。
+
+## 5. 实现备注
+
+- `P12` 的重点是“当前等级 + 当前权益 + 等级说明”
+- 页面应优先回答顾客最关心的三个问题：
+ - 我是什么等级
+ - 我现在能享受什么
+ - 不同等级差别是什么
+- 不要让成长值进度条、差值提示和升级倒计时反过来喧宾夺主
+- 会员中心不是消息页、活动页，也不是积分任务页
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/19-积分商城页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/19-积分商城页.md
index b44d497..f18981c 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/19-积分商城页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/19-积分商城页.md
@@ -2,43 +2,121 @@
- 页面编码：`P13`
- 页面层级：`二级页`
-- 页面目标：展示积分余额、可兑换商品和兑换记录
-- 主要依赖组件：`G01`
+- 页面目标：展示顾客当前积分余额、积分可兑换内容和历史兑换结果，回答“我的积分能干什么”
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 积分余额头部区
+2. 积分摘要头部区
3. Tab 切换区
4. 兑换商品列表区 / 兑换记录区
+5. 规则说明入口区
## 2. 区块说明
-### 2.1 积分余额头部区
-- 展示当前积分余额
-- 展示积分获取说明入口（可选）
+### 2.1 积分摘要头部区
+
+- 这一块先回答顾客“我现在有多少积分”
+- 至少展示：
+ - 当前积分余额
+ - 积分获取方式摘要
+- 积分获取方式只做轻说明，例如：
+ - 消费赠分
+ - 评价赠分
+ - 注册赠分
+ - 签到赠分
+- 当前不把积分规则展开成复杂任务中心
### 2.2 Tab 切换区
-- 兑换商品
-- 兑换记录
+
+- 页面主结构建议分成两个视图：
+ - 可兑换
+ - 兑换记录
+- 这样可以把“现在能换什么”和“已经换过什么”分开表达，减少页面拥挤
### 2.3 兑换商品列表区
-- 商品卡展示：
+
+- 这一块承接后台真实商品模型
+- 可兑换内容可包括：
+ - 券兑换
+ - 商品兑换
+ - 实物兑换
+- 每张兑换卡至少展示：
- 商品图片
- 商品名称
+ - 兑换类型
- 所需积分
- - 库存 / 数量说明
- - 立即兑换
+ - 库存或限购提示
+ - 兑换按钮
+- 如果后端支持混合兑换 `points / mixed`，页面可以承接结果展示
+- 页面重点是帮助顾客理解兑换成本和兑换对象，不展开后台核销逻辑
### 2.4 兑换记录区
-- 展示兑换时间、兑换内容、状态
+
+- 这一块承接顾客历史兑换结果
+- 至少展示：
+ - 兑换时间
+ - 兑换内容
+ - 积分消耗
+ - 当前状态
+- 如后端后续补充核销方式、核销备注等结果字段，可作为记录详情补充展示
+- 当前不把商家侧核销动作前置给顾客
+
+### 2.5 规则说明入口区
+
+- 这一块只做轻量规则说明或跳转入口
+- 可说明：
+ - 积分如何获得
+ - 积分有效期
+ - 兑换后如何查看结果
+- 不把后台通知渠道配置、营销推送配置写成顾客可操作项
## 3. 页面状态
-- 默认态：有商品可兑
-- 空态：暂无可兑换商品
+### 默认态
-## 4. 实现备注
+- 有可兑换商品时，重点展示积分余额和兑换列表
+- 让顾客快速理解“我现在可以换什么”
-- 积分商城强调“积分能干什么”，不要只展示数值
+### 商品空态
+
+- 当暂无可兑换商品时，使用 `G03`
+- 可以保留积分余额和规则说明入口
+- 不因为商品为空就让整个积分页失效
+
+### 记录空态
+
+- 当顾客还没有兑换记录时，显示轻空态说明
+- 不伪造历史记录
+
+### 未登录态
+
+- 积分商城属于顾客资产页
+- 未登录时应先引导登录 / 授权，再查看积分和兑换记录
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残积分数据
+
+## 4. 当前明确不冻结的能力
+
+- 商家侧核销动作
+- 通知渠道设置项
+- 订单结算积分抵扣总入口
+- 复杂积分任务体系页
+- 顾客自定义消息提醒配置
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“积分余额、积分商品、兑换记录”，还不足以把其他扩展能力写成正式前台契约。
+
+## 5. 实现备注
+
+- `P13` 的重点是“积分余额 + 可兑换内容 + 兑换记录”
+- 页面应该让顾客清楚知道：
+ - 我有多少积分
+ - 积分能换什么
+ - 我换过什么
+- 不要把积分商城反向扩成积分任务大厅、消息配置页或结算抵扣总入口
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/20-储值充值页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/20-储值充值页.md
index 3711ff1..58ae86e 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/20-储值充值页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/20-储值充值页.md
@@ -2,43 +2,101 @@
- 页面编码：`P14`
- 页面层级：`二级页`
-- 页面目标：展示储值余额、充值方案和充值记录
-- 主要依赖组件：`G01`、`G44`
+- 页面目标：展示顾客当前储值资产，支持选择充值方案、发起充值，并回看充值记录
+- 主要依赖组件：`G01`、`G44`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 储值余额区
+2. 储值资产摘要区
3. 充值方案区
4. 充值记录区
-5. 底部支付区
+5. 底部提交区
## 2. 区块说明
-### 2.1 储值余额区
-- 展示当前可用余额
-- 可补充说明实充与赠送余额（如有）
+### 2.1 储值资产摘要区
+
+- 这一块先回答顾客“我现在还有多少储值余额”
+- 至少展示：
+ - 总储值余额
+ - 实充余额
+ - 赠送余额
+- 这样可以避免顾客把余额来源和可用结构混在一起理解
+- 当前不把后台更复杂的财务记账字段直接暴露给顾客
### 2.2 充值方案区
+
- 使用 `G44`
-- 每张方案卡展示：
+- 这是本页最核心的操作区，负责让顾客快速比较不同充值方案
+- 每张方案卡至少展示：
- 充值金额
- 赠送金额
- 到账金额
+- 如存在排序、推荐方案或活动标识，可以作为轻提示展示
+- 页面重点是帮助顾客理解“充多少、送多少、实际到账多少”
### 2.3 充值记录区
-- 展示最近充值记录
-- 包含：时间、支付方式、到账金额
-### 2.4 底部支付区
-- 主按钮：立即充值
+- 这一块用于回看顾客已经发生的充值结果
+- 至少展示：
+ - 充值时间
+ - 支付方式
+ - 到账金额
+- 如后续需要补充赠送金额、订单号等稳定字段，可在记录详情里扩展
+- 当前不把后台财务流水明细直接搬到顾客页
+
+### 2.4 底部提交区
+
+- 主按钮：`立即充值`
+- 页面只保留一个明确主动作，不扩展成复杂收银台
+- 发起充值后，具体前台支付方式应以后续充值支付契约为准
+- 当前明确不直接镜像后台交易记录中的全部支付枚举
## 3. 页面状态
-- 默认态：有方案可选
-- 空态：暂无充值方案
+### 默认态
-## 4. 实现备注
+- 有充值方案时，重点展示资产摘要和方案列表
+- 顾客应能快速完成方案比较和充值发起
-- 充值金额、赠送金额、到账金额三者必须同时可见
+### 方案空态
+
+- 当暂无可用充值方案时，使用 `G03`
+- 可以继续展示当前储值资产和历史充值记录
+- 不因为方案为空就隐藏整页资产信息
+
+### 记录空态
+
+- 当顾客还没有充值记录时，显示轻空态说明
+- 不伪造历史记录
+
+### 未登录态
+
+- 储值充值页属于顾客资产页
+- 未登录时应先引导登录 / 授权，再查看余额和充值方案
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残余额信息和方案数据
+
+## 4. 当前明确不冻结的能力
+
+- 把后台 `alipay / cash / card / balance / wechat` 直接作为小程序前台支付方式列表
+- 复杂财务流水明细页
+- 自动续充或周期充值能力
+- 充值优惠叠加到复杂营销任务体系
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“余额、方案、记录”，还不足以把更多支付和财务扩展写成正式前台契约。
+
+## 5. 实现备注
+
+- `P14` 的重点是“余额看清楚、方案比明白、充值发得起、记录回得去”
+- 页面至少要让顾客明确看到三组数字：
+ - 充值金额
+ - 赠送金额
+ - 到账金额
+- 前台充值支付方式需要和后台记账支付方式分层看待，不能直接把后台枚举原样搬到小程序
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/21-次卡页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/21-次卡页.md
index 0414e76..e03145f 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/21-次卡页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/21-次卡页.md
@@ -2,37 +2,95 @@
- 页面编码：`P15`
- 页面层级：`二级页`
-- 页面目标：展示可购买次卡、已购次卡和核销记录
-- 主要依赖组件：`G01`、`G45`
+- 页面目标：解释当前有哪些次卡、适用什么范围、如何使用，并展示已经发生的次卡使用结果
+- 主要依赖组件：`G01`、`G45`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. Tab 切换区
-3. 次卡列表区
+2. 次卡模板区
+3. 使用记录区
+4. 规则说明区
## 2. 区块说明
-### 2.1 Tab 切换区
-- 可购买次卡
-- 我的次卡
-- 使用记录（可选）
+### 2.1 次卡模板区
-### 2.2 次卡列表区
- 使用 `G45`
-- 次卡卡片展示：
- - 次卡名称
+- 这一块先告诉顾客“当前有哪些次卡可以理解或选择”
+- 每张次卡卡片至少展示：
+ - 卡名称
+ - 售价
+ - 次数
- 适用范围
- 有效期
- - 剩余次数 / 总次数
- - 购买或查看详情按钮
+- 如业务已支持购买入口，可在卡片上保留购买动作
+- 页面重点是把适用范围和核心规则讲清楚，而不是把实例系统写满
+
+### 2.2 使用记录区
+
+- 这一块承接顾客已经发生的次卡使用结果
+- 至少展示：
+ - 使用商品
+ - 使用时间
+ - 剩余次数
+ - 补差金额
+- 这一区块帮助顾客回看次卡实际怎么被使用，而不是做商家核销工作台
+
+### 2.3 规则说明区
+
+- 这一块用于解释次卡的基本使用规则
+- 可说明：
+ - 适用商品或适用品类
+ - 有效期规则
+ - 是否需要补差
+- 当前只说明顾客侧能理解的使用规则
+- 不把商家侧后台配置细项原样暴露给顾客
## 3. 页面状态
-- 默认态：有可购或已购次卡
-- 空态：暂无次卡
+### 默认态
-## 4. 实现备注
+- 有次卡模板或使用记录时，优先展示模板说明和已发生记录
+- 页面重心是帮助顾客理解“怎么买、怎么用、用到了哪里”
-- 次卡页需要把“适用什么商品”和“还剩几次”表达清楚
+### 模板空态
+
+- 当暂无次卡模板时，使用 `G03`
+- 可以继续保留使用记录区，避免整页失效
+
+### 记录空态
+
+- 当顾客还没有次卡使用记录时，显示轻空态说明
+- 不伪造剩余次数和历史实例数据
+
+### 未登录态
+
+- 次卡页属于顾客资产页
+- 未登录时应先引导登录 / 授权，再查看正式次卡信息
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残次卡信息
+
+## 4. 当前明确不冻结的能力
+
+- 我的次卡实例完整列表
+- 次卡转赠流程
+- 次卡退款流程
+- 购买后的实例详情页
+- 复杂核销操作页
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“模板信息和使用结果”，还不足以把完整实例体系写成正式前台契约。
+
+## 5. 实现备注
+
+- `P15` 的重点是“次卡是什么、适用什么、怎么用过”
+- 页面至少要把三件事说清楚：
+ - 可选次卡有哪些
+ - 这些次卡适用什么范围
+ - 我已经发生过哪些使用结果
+- 不要把 `P15` 误写成完整的“我的次卡资产总账”或商家核销后台
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/22-消息中心页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/22-消息中心页.md
index 50cbc06..3df3833 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/22-消息中心页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/22-消息中心页.md
@@ -2,38 +2,68 @@
- 页面编码：`P16`
- 页面层级：`二级页`
-- 页面目标：集中查看订单消息、营销消息和系统通知
-- 主要依赖组件：`G01`、`G46`
+- 页面目标：保留顾客消息收件中心的页面职责，用于未来承接订单、营销和系统消息
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 消息分类切换区
-3. 消息列表区
+2. 消息内容区
## 2. 区块说明
-### 2.1 消息分类切换区
-- 全部
-- 订单消息
-- 营销消息
-- 系统通知
+### 2.1 消息内容区
-### 2.2 消息列表区
-- 使用 `G46`
-- 每条消息展示：
- - 标题
- - 摘要
- - 时间
- - 未读状态
-- 点击消息跳转到对应业务页面
+- 这一块的页面职责可以保留，用于未来承接顾客收到的：
+ - 订单消息
+ - 营销消息
+ - 系统消息
+- 但在当前冻结范围内，只确认“消息中心页应存在”
+- 不把以下内容写成已经稳定的正式能力：
+ - 完整消息分类切换
+ - 顾客消息列表字段模型
+ - 未读 / 已读状态
+ - 消息点击后的跳转规则
## 3. 页面状态
-- 默认态：有消息
-- 空态：暂无消息
+### 预留态
-## 4. 实现备注
+- 当前阶段，这一页更像信息架构预留页
+- 页面职责是保住“顾客收消息”这个入口位置，而不是强行定义一套未经证实的 inbox 结构
-- 消息要支持按读写状态区分，但不需要复杂会话系统
+### 空态
+
+- 如当前没有可展示消息内容，使用 `G03`
+- 可提示顾客暂无消息
+- 不伪造消息分类、未读数和历史消息数据
+
+### 未登录态
+
+- 消息中心属于顾客本人服务页
+- 未登录时应先引导登录 / 授权，再查看正式消息内容
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残消息结构
+
+## 4. 当前明确不冻结的能力
+
+- 完整消息分类 Tab
+- 未读 / 已读状态流转
+- 消息点击跳转规则
+- 消息角标数量
+- 顾客消息列表字段结构
+- 把后台 `message-reach` 的发送状态、阅读率、转化率直接展示给顾客
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“运营发送中心”，还不足以把顾客收件中心写成正式前台契约。
+
+## 5. 实现备注
+
+- `P16` 当前是保留页面职责，不是冻结完整消息产品
+- 最重要的边界只有一条：
+ - 后台 `message-reach` 是发送中心，不是顾客消息中心
+- 后续如果补齐顾客侧消息契约，可以在当前页面职责下继续扩展，不需要重新改信息架构定位
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/23-帮助中心页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/23-帮助中心页.md
index 414bd1a..cbb9ca0 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/23-帮助中心页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/23-帮助中心页.md
@@ -2,43 +2,74 @@
- 页面编码：`P17`
- 页面层级：`二级页`
-- 页面目标：承接常见问题、规则说明和客服联系
-- 主要依赖组件：`G01`
+- 页面目标：作为顾客服务兜底页，承接常见问题、基础规则说明和后续服务引导
+- 主要依赖组件：`G01`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 常见问题区
-3. 专题帮助区
-4. 联系客服区
+2. 帮助内容区
+3. 服务引导区
## 2. 区块说明
-### 2.1 常见问题区
-- 以折叠列表形式展示
-- 建议覆盖：
- - 如何下单
- - 如何使用优惠券
- - 如何申请退款
- - 如何查看取餐码
+### 2.1 帮助内容区
-### 2.2 专题帮助区
-- 支付帮助
-- 配送帮助
-- 自提帮助
-- 堂食帮助
-- 会员与资产帮助
+- 这一块用于承接顾客常见问题和基础规则说明
+- 可覆盖的帮助主题包括：
+ - 下单相关
+ - 支付相关
+ - 售后相关
+ - 自提 / 堂食相关
+ - 会员与资产相关
+- 当前页面只保留“帮助内容可以存在”这一职责
+- 不把以下内容写成已经稳定的后台动态能力：
+ - 完整 FAQ 分类体系
+ - 帮助文章 CMS
+ - 后台动态配置的专题帮助内容
-### 2.3 联系客服区
-- 在线客服入口
-- 电话客服入口
+### 2.2 服务引导区
+
+- 当顾客未能从帮助内容中解决问题时，这一块负责继续导向服务兜底能力
+- 可保留：
+ - 联系平台说明
+ - 查看相关业务页入口
+- 当前不把完整在线客服、电话客服、工单系统写成后台已证实能力
## 3. 页面状态
-- 默认态即可
-- 若帮助内容为空，则展示联系客服入口
+### 默认态
-## 4. 实现备注
+- 有帮助内容时，页面承担轻量解释和服务兜底角色
+- 页面重点是降低顾客找答案的成本，不是做复杂内容平台
-- 帮助中心主要作为兜底服务页，不需要复杂交互
+### 内容空态
+
+- 当暂无可展示帮助内容时，使用 `G03`
+- 可保留基础服务引导区
+- 不伪造帮助分类和文章数据
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残帮助内容
+
+## 4. 当前明确不冻结的能力
+
+- 完整 FAQ 后台配置体系
+- 帮助文章 CMS
+- 在线客服系统
+- 电话客服配置
+- 工单流转系统
+
+这些能力不是判定为永远不做，而是当前后台事实源还不足以把帮助中心写成完整动态服务产品。
+
+## 5. 实现备注
+
+- `P17` 当前是服务兜底页，不是内容运营后台的前台镜像
+- 页面重点只有两件事：
+ - 帮助顾客快速找到基础说明
+ - 在说明不足时给出合理的后续服务引导
+- 不要因为想把页面做满，就假设后台已经具备完整 FAQ / 客服 / CMS 契约
diff --git a/Cend-MiniProgram-Prototype/docs/07-页面规格/24-堂食扫码确认页.md b/Cend-MiniProgram-Prototype/docs/07-页面规格/24-堂食扫码确认页.md
index 023ae06..b5d8333 100644
--- a/Cend-MiniProgram-Prototype/docs/07-页面规格/24-堂食扫码确认页.md
+++ b/Cend-MiniProgram-Prototype/docs/07-页面规格/24-堂食扫码确认页.md
@@ -2,46 +2,91 @@
- 页面编码：`P18`
- 页面层级：`二级页`
-- 页面目标：在扫码后确认门店与桌号，并把用户送入堂食点餐页
-- 主要依赖组件：`G01`、`G12`
+- 页面目标：确认扫码得到的门店、区域和桌号是否有效，并把顾客送进堂食点餐上下文
+- 主要依赖组件：`G01`、`G12`、`G03`、`G04`
+- 本页已按 `docs/12-租户管理员功能重构梳理/01-门店前置链路.md` 回写
## 1. 页面结构（从上到下）
1. 顶部导航栏
-2. 扫码结果确认卡
-3. 堂食规则说明区
-4. 当前桌台状态区（可选）
-5. 主操作区
+2. 扫码结果确认区
+3. 场景说明区
+4. 主操作区
## 2. 区块说明
-### 2.1 扫码结果确认卡
-- 展示：
+### 2.1 扫码结果确认区
+
+- 这一块先回答顾客“我扫到的是哪一家店、哪一张桌”
+- 至少展示：
- 门店名称
- - 桌号 / 桌台编号
- - 是否可点餐
+ - 区域信息
+ - 桌号
+ - 桌位状态是否可用
+ - 堂食是否开启
+- 这一块的重点是校验当前扫码上下文是否成立，而不是展示复杂堂食规则
-### 2.2 堂食规则说明区
-- 展示：
- - 是否先付款
- - 是否支持加菜
- - 是否支持合单
- - 结账方式说明
+### 2.2 场景说明区
-### 2.3 当前桌台状态区
-- 如已有订单，可提示当前桌存在进行中订单
+- 这一块只做必要的轻说明，帮助顾客理解接下来会进入堂食点餐上下文
+- 可说明：
+ - 当前点餐门店
+ - 当前桌位信息
+ - 入桌后的点餐提示
+- 当前不把复杂堂食规则整块堆进本页
-### 2.4 主操作区
-- 主按钮：进入堂食点餐
-- 次按钮：重新扫码 / 切换桌号（如需要）
+### 2.3 主操作区
+
+- 当扫码结果有效时：
+ - 主按钮：`进入堂食点餐`
+- 当扫码结果无效或桌位不可用时，应给出明确兜底动作：
+ - 重新扫码
+ - 联系门店
+- 页面不需要顾客二次输入复杂信息，应优先自动确认扫码上下文
## 3. 页面状态
-- 正常可入桌
-- 桌号失效
-- 当前桌不可用
+### 正常可入桌态
-## 4. 实现备注
+- 明确展示门店、区域、桌号和可入桌状态
+- 主动作收敛为进入堂食点餐
-- 该页要尽量减少用户输入，优先自动确认门店和桌号
+### 桌位不可用态
+
+- 明确提示当前桌位不可继续入桌
+- 提供重新扫码或联系门店的兜底动作
+
+### 堂食未开启态
+
+- 明确提示当前门店暂不支持堂食扫码入桌
+- 不让顾客继续进入错误堂食上下文
+
+### 码失效态
+
+- 明确提示当前二维码无效或已失效
+- 提供重新扫码入口
+
+### 加载失败态
+
+- 使用 `G04`
+- 支持重试，不展示半残门店和桌号信息
+
+## 4. 当前明确不冻结的能力
+
+- 先付款规则说明
+- 合单规则说明
+- 继续加菜规则说明
+- 完整当前桌进行中订单详情
+- 顾客手动切换桌号流程
+
+这些能力不是判定为永远不做，而是当前后台事实源更稳定支持“堂食开关、桌位、扫码入桌上下文”，还不足以把更多堂食扩展规则写成正式前台契约。
+
+## 5. 实现备注
+
+- `P18` 的重点是“扫码上下文确认成功，再进堂食点餐”
+- 页面应该优先回答顾客三个问题：
+ - 我扫到的是哪家店
+ - 我现在对应哪张桌
+ - 这张桌现在能不能点餐
+- 不要把堂食扫码确认页扩写成堂食规则大全或订单处理页
diff --git a/Cend-MiniProgram-Prototype/docs/08-全周期版本规划与范围分层.md b/Cend-MiniProgram-Prototype/docs/08-全周期版本规划与范围分层.md
index c431bc1..2baed2c 100644
--- a/Cend-MiniProgram-Prototype/docs/08-全周期版本规划与范围分层.md
+++ b/Cend-MiniProgram-Prototype/docs/08-全周期版本规划与范围分层.md
@@ -1,46 +1,54 @@
# 全周期版本规划与范围分层
- 文档版本：`V1.0`
+- 基线日期：`2026-03-16`
- 适用项目：`TakeoutSaaS` 小程序 C 端
-- 文档目标：基于现有租户后台能力与 C 端页面规格，定义小程序从原型期到成熟期的完整版本路径
+- 文档目标：基于当前已冻结页面职责和当前正式仓库基线，定义小程序从当前阶段到后续成熟阶段的版本路径。
---
-## 1. 文档目的
+## 1. 这份文档现在解决什么问题
-本文件不再只回答“一期先做什么”，而是回答以下 3 个问题：
+本文件回答 4 个问题：
-1. 小程序 C 端全周期应该按什么节奏推进
-2. 每个版本解决什么用户问题、承接什么后台能力
-3. 哪些能力属于当前页内实现，哪些能力属于未来扩展
+1. 小程序应该分几期推进。
+2. 每一期重点解决什么顾客问题。
+3. 每一期应该前置哪些页面和能力。
+4. 哪些租户后台能力当前不应该直接前置到 C 端。
-本文件与 `docs/05-页面清单总表.md`、`docs/09-租户后台与C端功能映射总表.md`、`docs/10-全周期研发实施顺序与交付清单.md` 配合使用。
+这份文档与以下文档配合使用：
+
+- `docs/05-页面清单总表.md`
+- `docs/09-租户后台与C端功能映射总表.md`
+- `docs/10-全周期研发实施顺序与交付清单.md`
+- `docs/11-V1.0页面开发执行清单与验收标准.md`
---
## 2. 全周期总览
-| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 对应价值 |
+| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 当前重点 |
| --- | --- | --- | --- | --- |
-| G0 | 原型规划期 | 文档与原型收口 | 把页面、路由、组件、流程、业务规则定清楚 | 降低后续返工 |
-| G1 | `V1.0` 核心交易版 | 先跑通交易主闭环 | 顾客能完成选店、点餐、结算、支付、查订单 | 建立基础下单能力 |
-| G2 | `V1.1` 履约服务版 | 补全场景与售后 | 顾客能退款、评价、自提、堂食扫码点餐 | 提升服务完整度 |
-| G3 | `V2.0` 会员资产版 | 建立复购资产池 | 顾客能使用会员、优惠券、积分、储值、次卡 | 提升留存与复购 |
-| G4 | `V2.1` 营销增长版 | 做活动承接与增长 | 顾客能参与新客礼、满减、秒杀、限时折扣等活动 | 提升转化与拉新 |
-| G5 | `V3.0` 精细运营版 | 进入精细化经营 | 做消息触达、个性化推荐、服务中心、深度数据联动 | 提升 LTV 与运营效率 |
+| `G0` | 原型收口期 | 文档、规格、边界冻结 | 把页面职责、路由、规则和映射关系定清楚 | 已基本完成 |
+| `G1` | `V1.0` 交易闭环收口版 | 收口当前已注册页面和组件 | 让顾客稳定完成选店、点餐、结算、支付、查单 | 当前主阶段 |
+| `G2` | `V1.1` 履约与售后版 | 补齐支付后的服务链路 | 让顾客看懂订单进展、申请退款、完成评价 | 下一阶段 |
+| `G3` | `V2.0` 我的与资产版 | 建立长期留存资产承接 | 让顾客查看并使用会员、积分、储值、次卡 | 中期阶段 |
+| `G4` | `V2.1` 活动导购版 | 把活动能力前置成导流页面 | 让活动真正导流到商品、购物车和结算 | 中后期阶段 |
+| `G5` | `V3.0` 服务与精细运营版 | 进入服务化和精细化经营 | 让顾客获得消息、帮助和更长期的经营体验 | 长期阶段 |
---
## 3. 各阶段详细范围
-## 3.1 G0 原型规划期
+## 3.1 `G0` 原型收口期
### 阶段目标
-- 完成 C 端页面地图、交互流、页面规格、业务规则与组件清单
-- 对齐租户后台已有能力与 C 端承接关系
-- 为后续 UI 设计、开发实现、接口对接提供统一母文档
-### 当前应交付内容
+- 收口页面地图、业务规则、页面规格、组件清单和后台映射关系。
+- 统一哪些能力要前置到 C 端，哪些能力不前置。
+
+### 核心交付
+
- `docs/01-文档导航与实施顺序.md`
- `docs/02-信息架构与路由.md`
- `docs/03-全局业务规则.md`
@@ -48,217 +56,301 @@
- `docs/05-页面清单总表.md`
- `docs/06-通用组件清单.md`
- `docs/07-页面规格/`
-- `docs/08-10` 规划类文档
+- `docs/08-11` 规划和执行文档
+- `docs/12-租户管理员功能重构梳理/`
-### 阶段完成标准
-- 产品、设计、开发对页面范围与先后顺序没有歧义
-- 每个页面都有明确入口、出口和状态要求
-- 页面与后台能力关系可追溯
+### 完成标准
+
+- 页面职责和版本边界已经明确。
+- 设计、开发、测试对“先做什么、后做什么”没有歧义。
---
-## 3.2 G1 `V1.0` 核心交易版
+## 3.2 `G1` `V1.0` 交易闭环收口版
### 阶段定位
-先做“顾客下单主闭环”，目标不是一次做全，而是先把最核心的交易能力跑通。
-### 目标用户问题
-- 顾客能否快速找到门店并进入正确点餐场景
-- 顾客能否快速选品、加购、结算、支付
-- 顾客付款后能否看到自己的订单和状态
+当前正式仓库已经有 10 个页面路由和 2 个关键抽屉组件，不再是“从零起页”的阶段。
+这一期的重点是把当前已存在页面和组件，对齐到新的冻结规格，形成稳定交易闭环。
+
+### 重点解决的问题
+
+- 顾客能不能进入正确门店和正确场景。
+- 顾客能不能稳定完成加购、结算和支付。
+- 顾客支付后能不能找到订单和下一步操作。
### 版本范围
-#### 核心页面
-- `T01 首页`
-- `T02 点餐页`
-- `T03 订单页`
-- `T04 我的页（基础版）`
-- `C01 商品详情抽屉`
-- `C02 购物车抽屉`
-- `P03 结算确认页`
-- `P04 支付成功页`
-- `P05 订单详情页`
-- `P18 堂食扫码确认页`
+#### 必须收口的页面与组件
-#### 必要支撑页
-- `P01 门店选择页（轻量版）`
-- `P02 地址管理页（基础版）`
+- `P01` 门店选择页
+- `P18` 堂食扫码确认页
+- `P02` 地址管理页
+- `T02` 点餐页
+- `C01` 商品详情抽屉
+- `C02` 购物车抽屉
+- `P03` 结算确认页
+- `P04` 支付成功页
+- `T03` 订单页
+- `P05` 订单详情页
+- `T01` 首页
+- `T04` 我的页
#### 核心能力
-- 门店选择与场景切换
-- 商品分类浏览与商品详情选择
-- 规格、加料、数量联动
-- 购物车与金额汇总
-- 结算页金额明细展示
-- 微信支付占位与支付成功回流
-- 订单列表、订单详情、基础状态表达
-### 本阶段不追求
-- 完整会员资产闭环
-- 全部营销会场与复杂优惠组合
-- 售后评价全部细节
-- 精细化消息与推荐系统
+- 门店和场景上下文前置。
+- 渠道和场景驱动的菜单浏览。
+- 简单商品直接加购，复杂商品走规格或组合选择。
+- 购物车编辑与结算入口。
+- 结算页中手动资产与自动优惠分开展示。
+- 支付成功页、订单页、订单详情页形成结果承接闭环。
+- 首页与我的页形成聚合和导流能力。
+
+### 当前必须守住的边界
+
+- 首页是导流页，不是固定八宫格活动页，不是资产目录页。
+- 点餐页类目和商品必须跟随场景、渠道和门店能力。
+- 结算页手动资产当前只确认：
+ - 优惠券
+ - 余额
+ - 次卡
+- 自动优惠当前只确认结果展示：
+ - 满减
+ - 新客优惠
+ - 会员折扣
+ - 免配送费
+- `积分抵扣` 当前不作为已冻结结算能力。
+- 当前支付方式页面表达只冻结：
+ - 微信支付
+ - 余额支付
+- 订单页和详情页使用顾客语言，不使用商家后台看板语言。
+
+### 本阶段不做
+
+- 退款、评价的完整页面闭环。
+- 领券中心、秒杀、限时折扣等独立活动页。
+- 会员、积分、储值、次卡等完整资产页。
+- 完整消息中心和帮助中心能力。
### 成功标准
-- 顾客可以从首页进入交易链路并形成订单
-- 外卖、自提、堂食 3 种场景至少完成基础差异表达
-- 下单后可在订单页和订单详情页找到订单
+
+- 顾客可稳定完成 `选店 -> 点餐 -> 结算 -> 支付 -> 查单`。
+- 外卖 / 自提 / 堂食 3 种场景完成基础差异表达。
+- 当前仓库注册页面与冻结规格基本对齐。
---
-## 3.3 G2 `V1.1` 履约服务版
+## 3.3 `G2` `V1.1` 履约与售后版
### 阶段定位
-在 `V1.0` 基础上，把履约透明度与售后能力补齐，让小程序具备完整服务体验。
+
+在交易闭环稳定后，补齐支付后的订单进展、售后和评价体验。
### 版本范围
-- `P06 退款申请页`
-- `P07 退款详情页`
-- `P08 评价页`
-- 回补 `T03 订单页`
-- 回补 `P05 订单详情页`
+
+- 回补 `T03` 订单页
+- 回补 `P05` 订单详情页
+- `P06` 退款申请页
+- `P07` 退款详情页
+- `P08` 评价页
### 核心能力
-- 待支付继续支付 / 取消订单
-- 订单履约时间轴
-- 外卖配送、自提取餐码、堂食桌号展示
-- 退款申请、退款状态查询
-- 订单评价、匿名评价、晒图评价
-- 再来一单入口
+
+- 顾客视角订单状态表达。
+- 更完整的履约时间轴。
+- 最小退款申请和退款结果查询。
+- 最小评价提交闭环。
+- 再来一单等回流动作。
+
+### 当前必须守住的边界
+
+- 不把商家后台履约动作直接搬到顾客端。
+- `催单 / 骑手轨迹 / 取餐码` 不提前写成所有版本固定必做按钮。
+- 评价页先做最小闭环，不叠加复杂运营玩法。
### 成功标准
-- 顾客知道订单当前走到哪一步
-- 顾客能看见退款入口、处理进度和结果
-- 已完成订单能评价，评价后能回流到订单或复购场景
+
+- 顾客知道订单走到哪一步。
+- 顾客知道售后在哪里、结果怎么看。
+- 支付后体验不再只停在订单列表的最小展示层。
---
-## 3.4 G3 `V2.0` 会员资产版
+## 3.4 `G3` `V2.0` 我的与资产版
### 阶段定位
-从“做完订单”升级到“让顾客愿意回来”，建立用户资产和长期关系。
+
+从“完成一次交易”升级到“形成复购和留存承接”。
### 版本范围
-- `T04 我的页（完整版）`
-- `P09 领券中心页`
-- `P12 会员中心页`
-- `P13 积分商城页`
-- `P14 储值充值页`
-- `P15 次卡页`
+
+- 回补 `T04` 我的页完整版
+- `P12` 会员中心页
+- `P13` 积分商城页
+- `P14` 储值充值页
+- `P15` 次卡页
### 核心能力
-- 展示会员等级、成长值、权益、会员日信息
-- 展示并领取优惠券
-- 展示积分余额、积分获取与兑换能力
-- 展示储值方案、充值记录、余额支付入口
-- 展示次卡购买、核销、剩余次数
-- 让资产在结算页有实际承接入口
+
+- 我的页承接身份、资产、服务和复购入口。
+- 展示会员等级、权益说明和成长信息。
+- 展示积分余额、兑换内容和兑换记录。
+- 展示余额、充值方案和充值结果。
+- 展示次卡说明、购买结果和使用结果。
+
+### 当前必须守住的边界
+
+- 我的页是聚合页，不是资产真源页。
+- 不把不稳定数量字段写成强依赖。
+- 不把积分商城反向扩成结算页积分抵扣主入口。
### 成功标准
-- “我的”页不再只是资料页，而是复购与留存中心
-- 顾客能理解自己拥有哪些资产、如何使用这些资产
-- 会员资产与结算页面存在清晰闭环
+
+- 顾客能理解自己拥有哪些资产。
+- 资产页能回流到交易链路，而不是只做静态展示。
+- 我的页形成稳定的身份和复购聚合中心。
---
-## 3.5 G4 `V2.1` 营销增长版
+## 3.5 `G4` `V2.1` 活动导购版
### 阶段定位
-从“顾客可复购”升级到“商家可持续做增长”，让后台营销能力在前台有承接页和转化路径。
+
+让后台营销能力在顾客端形成真正的活动导流页，而不是孤立展示。
### 版本范围
-- `P10 秒杀活动页`
-- `P11 限时折扣活动页`
-- 回补首页活动区与点餐页活动承接
-- 回补领券中心与结算优惠展示
-- 接入新客有礼、满减活动、活动日历类运营能力
+
+- 回补首页动态活动区
+- 回补点餐页活动摘要和活动价表达
+- 回补结算页自动优惠命中说明
+- `P09` 领券中心页
+- `P10` 秒杀活动页
+- `P11` 限时折扣活动页
### 核心能力
-- 新客礼包导流
-- 满减自动命中与说明
-- 秒杀会场与倒计时表达
-- 限时折扣专区与商品承接
-- 首页 Banner、活动宫格、专题入口
-- 老客复购推荐、最近下单商品推荐
+
+- 券模板聚合和领取导流。
+- 秒杀会场和倒计时表达。
+- 限时折扣会场和活动商品承接。
+- 首页、点餐页、结算页形成活动结果闭环。
+
+### 当前必须守住的边界
+
+- 当前值得独立页面承接的活动只冻结为：
+ - 领券中心
+ - 秒杀活动
+ - 限时折扣活动
+- 满减和新客优惠主要在结果区表达，不先扩成重页面。
+- 活动页不能绕开标准交易主链路。
### 成功标准
-- 商家配置的营销活动能在 C 端被顾客感知并参与
-- 活动不只是“展示”，而是能引导进店、加购、结算和支付
+
+- 顾客能在活动页完成导流，不是停留在静态会场。
+- 商家配置的活动能真实影响加购、结算和支付。
---
-## 3.6 G5 `V3.0` 精细运营版
+## 3.6 `G5` `V3.0` 服务与精细运营版
### 阶段定位
-从“有交易、有增长”升级到“有精细化经营能力”，让 C 端不仅承接交易，也承接服务和用户经营。
-### 建议范围
-- `P16 消息中心页`
-- `P17 帮助中心页`
-- 回补首页个性化推荐与用户画像相关模块
-- 回补“我的”页服务区、消息区、客服区
-- 规划未来扩展：发票、客服、投诉、电子会员码、常购清单、个性化券包
+在交易、售后、资产和活动都稳定后，进入服务化和精细化经营阶段。
+
+### 版本范围
+
+- `P16` 消息中心页
+- `P17` 帮助中心页
+- 回补我的页服务区
+- 回补首页和我的页的个性化推荐模块
+- 预留未来扩展入口：
+ - 发票
+ - 客服
+ - 投诉建议
+ - 个性化券包
### 核心能力
-- 订单消息、营销消息、系统通知的聚合触达
-- FAQ、客服、售后帮助、自助指引
-- 基于顾客历史订单和会员标签的商品推荐
-- 基于活动日历与用户标签的个性化营销承接
-- 为未来 CRM、财务票据、顾客洞察留前台入口
+
+- 订单消息、营销消息、系统通知的页面职责承接。
+- FAQ、售后帮助、服务兜底入口。
+- 基于顾客历史和标签的推荐与经营模块。
+
+### 当前必须守住的边界
+
+- `消息中心页` 当前是职责页，不默认等于成熟的完整 inbox。
+- `帮助中心页` 当前是服务兜底页，不默认等于成熟的 FAQ CMS 或客服系统。
+- `发票` 当前更适合作为未来从订单详情页扩出的能力，不在前几期抢主线。
### 成功标准
-- 小程序从“下单工具”升级为“用户经营载体”
-- 顾客在 C 端能获取服务、消息、活动、资产、订单等全维度体验
+
+- 小程序不只是下单工具，也能承担服务和长期经营入口。
+- 顾客在 C 端能找到消息、帮助和个性化服务承接。
---
## 4. 全周期能力分层
-| 能力域 | 说明 | 主要版本 |
+| 能力域 | 主要内容 | 主要版本 |
| --- | --- | --- |
-| 交易域 | 选店、点餐、购物车、结算、支付、订单 | `V1.0` |
-| 履约域 | 配送、自提、堂食、时间轴、退款、评价 | `V1.1` |
-| 资产域 | 会员、优惠券、积分、储值、次卡 | `V2.0` |
-| 增长域 | 新客礼、满减、秒杀、限时折扣、复购推荐 | `V2.1` |
-| 服务域 | 消息、帮助、客服、服务入口 | `V3.0` |
-| 经营域 | 个性化推荐、顾客标签、票据与更多增值能力 | `V3.0+` |
+| 交易域 | 选店、场景切换、点餐、购物车、结算、支付、查单 | `V1.0` |
+| 履约售后域 | 订单进展、退款、评价、结果说明 | `V1.1` |
+| 资产域 | 会员、积分、储值、次卡、我的聚合 | `V2.0` |
+| 增长域 | 领券、秒杀、限时折扣、活动导流 | `V2.1` |
+| 服务域 | 消息、帮助、服务入口、个性化承接 | `V3.0` |
---
-## 5. 各版本之间的依赖关系
+## 5. 明确不前置到 C 端的后台能力
-1. `V1.0` 是所有后续版本的底座，没有交易闭环，后续资产和营销没有承接意义
-2. `V1.1` 解决“下单后怎么办”，否则订单体验不完整
-3. `V2.0` 解决“顾客为什么愿意回来”，是复购的基础
-4. `V2.1` 解决“商家如何主动做增长”，是运营放大的关键
-5. `V3.0` 解决“如何长期经营顾客关系”，是品牌化和精细运营的关键
+以下能力当前属于租户后台的经营支撑能力，不应该直接推导成顾客端页面：
+
+- CRM、顾客分析、客户分群
+- 财务概览、结算、报表、成本分析
+- 商家经营看板、驾驶舱、数据总览
+- 后台消息触达中心本身
+- 后台 FAQ CMS、本地客服系统本身
+
+这些能力的关系是：
+
+- 可以支撑 C 端页面展示结果。
+- 但不直接等于 C 端要做一个同名页面。
---
-## 6. 推荐落地原则
+## 6. 版本依赖关系
-### 6.1 不要按页面数量推进，要按闭环推进
-- 优先级不取决于页面多不多，而取决于是否能形成业务闭环
-
-### 6.2 不要把所有后台能力一次前置到 C 端
-- 后台配置能力很多，但前台承接必须按用户价值和转化优先级上线
-
-### 6.3 每个版本都要有明确“上线后可验证的结果”
-- `V1.0` 看下单成功率与订单可见性
-- `V1.1` 看退款与评价路径是否清晰
-- `V2.0` 看资产使用率与复购率
-- `V2.1` 看活动参与率与转化率
-- `V3.0` 看消息触达率、留存和用户活跃度
+1. `V1.0` 没有稳定交易闭环，后续资产和活动没有承接意义。
+2. `V1.1` 没有履约和售后，交易体验是不完整的。
+3. `V2.0` 没有资产承接，复购和留存没有抓手。
+4. `V2.1` 没有活动导流，后台营销能力很难在顾客端转化。
+5. `V3.0` 没有服务和精细运营，C 端很难成为长期经营入口。
---
-## 7. 与现有文档的关系
+## 7. 当前推荐落地原则
-- `docs/02-信息架构与路由.md` 负责定义“页面怎么挂”
-- `docs/03-全局业务规则.md` 负责定义“业务怎么跑”
-- `docs/04-核心用户流程.md` 负责定义“顾客怎么走”
-- `docs/05-页面清单总表.md` 负责定义“有哪些页面”
-- `docs/08` 负责定义“整个项目分几期做”
-- `docs/09` 负责定义“后台能力如何映射到 C 端”
-- `docs/10` 负责定义“研发实施时先做什么、交付什么”
+### 7.1 按闭环推进，不按页面数量推进
+
+- 优先级取决于是否能形成完整顾客闭环。
+
+### 7.2 先收口当前已存在页面，再扩新页面
+
+- 当前正式仓库已经有基础页面，不应继续用“未实现很多页面”的思路推进。
+
+### 7.3 先冻结边界，再扩复杂能力
+
+- 先把当前顾客真正会遇到的页面做稳定。
+- 再扩资产、活动、服务等中后期能力。
+
+---
+
+## 8. 当前结论
+
+当前阶段不是“继续发散页面”，而是：
+
+1. 完成 `V1.0` 当前注册页面和组件的规格收口。
+2. 再进入 `V1.1` 的订单履约与售后。
+3. 然后依次推进 `V2.0 / V2.1 / V3.0`。
+
+一句话说清楚：
+
+这套小程序的版本路径应该是 `先把交易主闭环做稳，再补订单后链路，再做资产，再做活动，最后做服务与精细运营`。
diff --git a/Cend-MiniProgram-Prototype/docs/09-租户后台与C端功能映射总表.md b/Cend-MiniProgram-Prototype/docs/09-租户后台与C端功能映射总表.md
index 4fb3608..acac06e 100644
--- a/Cend-MiniProgram-Prototype/docs/09-租户后台与C端功能映射总表.md
+++ b/Cend-MiniProgram-Prototype/docs/09-租户后台与C端功能映射总表.md
@@ -2,76 +2,103 @@
- 文档版本：`V1.0`
- 适用项目：`TakeoutSaaS` 租户后台 / 小程序 C 端
-- 文档目标：把租户后台现有模块，按“直接承接 / 间接支撑 / 未来扩展”映射到 C 端小程序
+- 文档目标：把租户后台真实业务域，按“直接承接 / 间接支撑 / 未来扩展 / 明确不前置”映射到 C 端小程序
---
## 1. 文档目的
-租户后台回答的是“商家如何配置与运营”，C 端回答的是“顾客如何感知与使用这些配置”。
+租户后台回答的是“商家如何配置与运营”，C 端回答的是“顾客如何感知、选择和完成任务”。
因此，本文件的作用是：
-1. 明确后台每个模块对 C 端的影响范围
-2. 明确哪些能力应该直接前置给顾客
-3. 明确哪些能力只作为 C 端背后的数据或配置支撑
-4. 为接口对接、页面设计、版本规划提供统一映射依据
+1. 明确后台每个业务域对 C 端到底有没有直接顾客价值
+2. 明确哪些能力应直接前置到页面、入口或状态表达
+3. 明确哪些能力只作为 C 端背后的规则、排序和结果支撑
+4. 避免把后台菜单机械映射成前台页面
---
## 2. 映射原则
### 2.1 直接承接
-后台能力在 C 端有明确页面、入口或状态表达，例如：门店营业时间、商品规格、订单状态、优惠券。
+
+后台能力在 C 端有明确页面、入口、状态或结果表达，例如：
+
+- 门店可服务性
+- 商品规格
+- 订单状态
+- 会员权益
+- 秒杀会场
### 2.2 间接支撑
-后台能力不会单独出现在 C 端页面上，但会影响推荐、展示、状态或运营策略，例如：顾客画像、财务结算报表。
+
+后台能力不会独立出现在 C 端页面上，但会影响排序、推荐、资格判断、结果展示或运营节奏，例如：
+
+- 客户画像
+- 营销日历
+- 交易流水记账结构
### 2.3 未来扩展
-当前文档未单独建设对应页面，但未来可规划 C 端能力，例如：电子发票、客服工单、精细化标签券包。
+
+当前不进入正式主链路，但未来存在较自然的顾客动作闭环，例如：
+
+- 订单详情里的电子发票入口
+
+### 2.4 明确不前置
+
+后台能力属于商家经营、财务管理、驾驶舱或 CRM 语言，不应该直接翻译成顾客页面，例如：
+
+- 财务概览
+- 到账查询
+- 成本分析
+- 顾客版 Dashboard
---
-## 3. 总映射矩阵
+## 3. 当前冻结总矩阵
-| 后台域 | 后台能力 | C 端承接页面 / 组件 | 承接方式 | 主要版本 | 说明 |
+| 后台域 | 后台能力 | C 端承接页面 / 组件 | 承接方式 | 当前结论 | 说明 |
| --- | --- | --- | --- | --- | --- |
-| 商户域 | 商户中心、品牌设置 | 首页、我的、帮助中心 | 间接支撑 | `V1.0` / `V3.0` | 影响品牌名、Logo、门店说明、客服电话、品牌文案 |
-| 门店域 | 门店列表 | 首页、门店选择页、点餐页头部 | 直接承接 | `V1.0` | 顾客必须先选门店再点餐 |
-| 门店域 | 营业时间 | 首页、门店卡、点餐页、订单页 | 直接承接 | `V1.0` | 影响营业中、休息中、即将打烊等状态 |
-| 门店域 | 配送设置 | 首页、结算页、地址选择 | 直接承接 | `V1.0` | 影响配送范围、起送门槛、配送方式 |
-| 门店域 | 自提设置 | 首页、结算页、订单详情 | 直接承接 | `V1.0` / `V1.1` | 影响自提时间、取餐说明、取餐规则 |
-| 门店域 | 费用设置 | 商品详情、结算页 | 直接承接 | `V1.0` | 影响打包费、餐具费、配送费、起送价 |
-| 门店域 | 堂食管理 | 堂食扫码确认页、点餐页、订单详情 | 直接承接 | `V1.0` / `V1.1` | 影响桌号、堂食规则、是否可加菜 |
-| 门店域 | 员工排班 | 订单时效、帮助中心说明 | 间接支撑 | `V1.1` / `V3.0` | 不单独前置，但影响顾客对服务时效感知 |
-| 商品域 | 商品列表 | 点餐页、首页推荐区 | 直接承接 | `V1.0` | 形成点餐主列表 |
-| 商品域 | 分类管理 | 点餐页左侧分类 / 顶部分类 | 直接承接 | `V1.0` | 决定菜单组织方式 |
-| 商品域 | 规格做法 | 商品详情抽屉 | 直接承接 | `V1.0` | 决定 SKU 价格与库存表现 |
-| 商品域 | 加料管理 | 商品详情抽屉 | 直接承接 | `V1.0` | 决定加料项、价格变化 |
-| 商品域 | 商品标签 | 首页推荐卡、商品卡片、详情抽屉 | 直接承接 | `V1.0` / `V2.1` | 热销、新品、招牌等标签直接影响转化 |
-| 商品域 | 时段供应 | 点餐页、商品详情抽屉 | 直接承接 | `V1.0` | 决定商品是否可售 |
-| 商品域 | 批量工具 | 无独立 C 端页面 | 间接支撑 | - | 只影响商家运营效率，不前置给顾客 |
-| 订单域 | 订单大厅 | 订单页、订单详情页 | 直接承接 | `V1.0` / `V1.1` | C 端看到的是顾客维度订单状态表达 |
-| 订单域 | 全部订单 | 订单页、订单搜索、订单详情 | 直接承接 | `V1.0` | 承接顾客找单、查单、继续支付 |
-| 营销域 | 优惠券 | 领券中心、结算页优惠选择、我的页资产摘要 | 直接承接 | `V2.0` | 领券与用券是资产与增长的共同入口 |
-| 营销域 | 满减活动 | 首页活动入口、结算页自动命中 | 直接承接 | `V2.1` | 顾客未必单独配置，但必须感知结果 |
-| 营销域 | 新客有礼 | 首页新客入口、结算页自动带入 | 直接承接 | `V2.1` | 新用户拉新核心抓手 |
-| 营销域 | 秒杀 | 秒杀活动页、首页会场、点餐页商品卡 | 直接承接 | `V2.1` | 强时效型营销场景 |
-| 营销域 | 限时折扣 | 限时折扣页、首页专区、点餐页标签 | 直接承接 | `V2.1` | 影响商品展示和结算价格 |
-| 营销域 | 集点 / 打卡 | 次卡页、活动页、我的页资产区 | 直接承接 / 未来扩展 | `V2.1` / `V3.0` | 当前可先做活动表达，后续做完整任务体系 |
-| 营销域 | 营销日历 | 首页 Banner、活动日程、消息提醒 | 间接支撑 | `V2.1` / `V3.0` | 主要影响前台活动编排与触达节奏 |
-| 会员域 | 会员管理 | 我的页、会员中心页、结算页会员权益提示 | 直接承接 | `V2.0` | 顾客感知的是等级、折扣、权益 |
-| 会员域 | 积分商城 | 积分商城页、结算积分抵扣、我的页摘要 | 直接承接 | `V2.0` | 形成积分获取与消耗闭环 |
-| 会员域 | 储值卡 | 储值充值页、结算余额支付、我的页摘要 | 直接承接 | `V2.0` | 支撑充值和余额消费 |
-| 会员域 | 消息触达 | 消息中心、我的页红点、活动提醒 | 直接承接 / 间接支撑 | `V3.0` | 支撑订单消息、营销消息、系统通知 |
-| 顾客域 | 顾客列表 | 无独立顾客页 | 间接支撑 | `V3.0` | 主要服务后台运营和标签管理 |
-| 顾客域 | 顾客画像 | 首页推荐、复购推荐、券包推荐 | 间接支撑 | `V3.0` | 不直接给顾客看“画像”，但会影响推荐结果 |
-| 顾客域 | 顾客分析 | 首页个性化、我的页推荐服务 | 间接支撑 | `V3.0` | 作为精细化运营的推荐输入 |
-| 财务域 | 财务概览 | 无直接前台页 | 间接支撑 | - | 服务后台经营分析，不直接前置 |
-| 财务域 | 交易流水 | 订单金额、余额记录、储值记录 | 间接支撑 | `V2.0` / `V3.0` | 顾客可见的是“订单金额 / 储值记录”子集 |
-| 财务域 | 发票管理 | 订单详情未来入口 | 未来扩展 | `V3.0+` | 当前文档未建设，可作为后续增值服务 |
-| 财务域 | 成本 / 结算 / 报表 | 无直接前台页 | 间接支撑 | - | 只服务商家与平台管理 |
-| 仪表盘域 | 经营概览 | 无直接前台页 | 间接支撑 | - | 不对顾客展示，但可反哺推荐和活动策略 |
+| 商户域 | 商户中心、品牌设置 | `T01`、`T04`、`P17` | 间接支撑 | 间接支撑 | 影响品牌名、门店说明、联系信息、品牌文案 |
+| 门店域 | 门店列表 | `T01`、`P01`、`T02`头部 | 直接承接 | 直接承接 | 顾客必须在正确门店与场景下开始交易 |
+| 门店域 | 营业时间 | `T01`、`P01`、`T02`、`P03` | 直接承接 | 直接承接 | 影响营业中、休息中、可预约时段 |
+| 门店域 | 配送设置 | `P01`、`P02`、`P03`、`T01`摘要 | 直接承接 | 直接承接 | 影响配送范围、起送门槛、配送费、预计送达 |
+| 门店域 | 自提设置 | `T01`摘要、`P03`、`P05` | 直接承接 | 直接承接 | 影响最早可约时段、同日自提等规则结果 |
+| 门店域 | 费用设置 | `C02`、`P03`、`P05` | 直接承接 | 直接承接 | 只承接顾客可理解的费用项 |
+| 门店域 | 堂食管理 | `P18`、`T02`头部、`P03`、`P05` | 直接承接 | 直接承接 | 只承接堂食开关、桌号、入桌上下文，不扩成复杂堂食规则页 |
+| 门店域 | 员工排班 | 无独立前台页 | 间接支撑 | 间接支撑 | 只影响忙闲感知和 ETA，不前置页面 |
+| 商品域 | 商品列表 | `T02`、`T01`推荐区 | 直接承接 | 直接承接 | 形成点餐主列表 |
+| 商品域 | 分类管理 | `T02` | 直接承接 | 直接承接 | 分类必须按当前场景过滤 |
+| 商品域 | 规格做法 | `C01` | 直接承接 | 直接承接 | 决定 SKU、价格、库存表现 |
+| 商品域 | 加料管理 | `C01` | 直接承接 | 直接承接 | 决定加料项和价格变化 |
+| 商品域 | 商品标签 | `T01`推荐卡、`T02`商品卡、`C01` | 直接承接 | 直接承接 | 热销、新品、招牌等标签直接影响转化 |
+| 商品域 | 时段供应 | `T02`、`C01`、`C02` | 直接承接 | 直接承接 | 决定商品是否可售 |
+| 商品域 | 批量工具 | 无独立前台页 | 间接支撑 | 间接支撑 | 只影响后台运营效率 |
+| 订单域 | 全部订单 / 订单详情 | `T03`、`P05` | 直接承接 | 直接承接 | C 端必须翻译成顾客任务语言，不复用商家看板口径 |
+| 订单域 | 履约结果 | `T03`、`P05` | 直接承接 | 直接承接 | 承接商家处理中、制作中、配送中、待取餐等结果表达 |
+| 订单域 | 退款结果 | `P06`、`P07`、`P05`摘要 | 直接承接 | 直接承接 | 当前以最小申请页和结果页为主 |
+| 订单域 | 评价图片上传 | `P08` | 直接承接 | 直接承接 | 当前只冻结最小评价闭环 |
+| 营销域 | 优惠券模板 | `P09`、`T01`活动位、`T04`入口、`P03` | 直接承接 | 直接承接 | 当前承接的是券模板聚合，不是顾客完整券包 |
+| 营销域 | 满减活动 | `T02`活动摘要、`P03`自动命中、`T01`轻摘要 | 直接承接 | 结果直承接 | 强感知、弱页面，不独立成页 |
+| 营销域 | 新客有礼 | `T01`资格入口、`P03`自动命中 | 直接承接 | 结果直承接 | 强资格、弱会场，分享链路未冻结 |
+| 营销域 | 秒杀 | `P10`、`T01`、`T02` | 直接承接 | 直接承接 | 强时效活动会场，仍回到标准交易主链路 |
+| 营销域 | 限时折扣 | `P11`、`T01`、`T02` | 直接承接 | 直接承接 | 强调折扣和时间窗口，仍回到标准交易主链路 |
+| 营销域 | 次卡模板 / 打卡 | `P15`、`T04`入口、`P03`次卡选择 | 直接承接 | 有限直接承接 | 当前重点是模板说明和使用结果，不夸大完整实例体系 |
+| 营销域 | 营销日历 | 无独立前台页 | 间接支撑 | 间接支撑 | 主要影响首页活动编排和提醒节奏 |
+| 会员域 | 会员管理 / 等级权益 | `T04`、`P12`、`P03`权益提示 | 直接承接 | 直接承接 | 顾客感知的是等级、权益和已享受结果 |
+| 会员域 | 积分商城 | `P13`、`T04`摘要 | 直接承接 | 直接承接 | 当前承接积分余额、可兑换内容、兑换记录 |
+| 会员域 | 积分规则 | `P13`、`P08`成功提示 | 直接承接 | 直接承接 | 主要承接获取和兑换，不冻结订单积分抵扣 |
+| 会员域 | 储值卡 | `P14`、`T04`摘要、`P03`余额支付 | 直接承接 | 直接承接 | 充值方案、余额和记录都可前置，但支付方式要收敛 |
+| 会员域 | 消息触达 | `P16`来源层、活动提醒 | 间接支撑 | 间接支撑 | 后台是发送中心，不等于顾客消息中心 |
+| 顾客域 | 顾客列表 | 无独立前台页 | 间接支撑 | 间接支撑 | 仅服务后台运营和标签管理 |
+| 顾客域 | 顾客画像 | `T01`、`T02`、`T04`复购区 | 间接支撑 | 间接支撑 | 影响推荐排序，不直接显示画像概念 |
+| 顾客域 | 顾客分析 | 无独立前台页 | 间接支撑 | 间接支撑 | 影响活动定向和推荐策略 |
+| 财务域 | 财务概览 | 无直接前台页 | 明确不前置 | 不前置 | 属于后台经营驾驶舱 |
+| 财务域 | 交易流水 | `P05`、`P07`、`P14`、`P13`结果子集 | 间接支撑 | 间接支撑 | 只抽取顾客能理解的订单、退款、充值、积分结果 |
+| 财务域 | 发票管理 | `P05` 未来扩展位 | 未来扩展 | 未来扩展 | 最自然入口是订单详情页，不做独立财务中心 |
+| 财务域 | 到账查询 / 结算 / 报表 / 成本 | 无直接前台页 | 明确不前置 | 不前置 | 只服务商家经营与财务管理 |
+| 仪表盘域 | 工作台 / 分析页 | 无直接前台页 | 明确不前置 | 不前置 | 当前不能作为小程序设计事实源 |
---
@@ -80,6 +107,7 @@
## 4.1 商户与门店域
### 后台来源
+
- 商户中心
- 门店列表
- 营业时间
@@ -89,24 +117,28 @@
- 堂食管理
### C 端主要承接点
+
- `T01 首页`
-- `T02 点餐页`
+- `T02 点餐页`头部
- `P01 门店选择页`
- `P02 地址管理页`
- `P03 结算确认页`
- `P05 订单详情页`
- `P18 堂食扫码确认页`
-### 说明
-- 这是 C 端最基础的配置域
-- 没有门店域能力，商品、订单、营销都无法成立
-- 该域直接决定三场景差异：`delivery`、`pickup`、`dine_in`
+### 当前结论
+
+- 门店域是 C 端主链路前提，必须先于商品、订单和活动成立
+- 首页和点餐页的场景切换必须跟随门店真实 `serviceTypes`
+- 地址可配送性必须前置，不允许拖到支付前才提示
+- 堂食页当前只承接扫码入桌上下文，不承接先付款、合单、加菜等未证实规则
---
## 4.2 商品域
### 后台来源
+
- 商品列表
- 分类管理
- 规格做法
@@ -115,132 +147,179 @@
- 时段供应
### C 端主要承接点
+
- `T02 点餐页`
- `C01 商品详情抽屉`
- `C02 购物车抽屉`
-- 首页推荐区 / 活动区
+- `T01` 推荐区 / 活动商品分组
+
+### 当前结论
-### 说明
- 商品域决定“顾客能买什么、怎么买、什么时候能买”
-- 规格、加料、标签、时段供应必须在 C 端有明确视觉反馈
+- 商品、类目和活动价展示都必须受当前场景过滤
+- 简单商品可直接加购，套餐商品必须先完成套餐组选择
---
-## 4.3 订单与履约域
+## 4.3 订单、履约与售后域
### 后台来源
-- 订单大厅
+
- 全部订单
-- 订单状态流转
+- 订单大厅
+- 订单详情
+- 退款交易结果
+- 评价图片上传
### C 端主要承接点
+
- `T03 订单页`
- `P05 订单详情页`
- `P06 退款申请页`
- `P07 退款详情页`
- `P08 评价页`
-### 说明
-- 后台关心接单、出餐、配送；C 端关心“我现在要做什么、还要等多久、能不能退款”
-- 因此，同一个订单状态，在 C 端需要翻译成顾客可理解的文案与动作按钮
+### 当前结论
+
+- 后台看板和商家处理动作不直接前置给顾客
+- C 端只承接顾客可理解的状态、履约结果和售后结果
+- `催单`、`骑手轨迹`、`取餐码`、`完整消息通知闭环` 当前都不冻结为正式前台能力
---
## 4.4 营销域
### 后台来源
-- 优惠券
+
+- 优惠券模板
- 满减活动
- 新客有礼
- 秒杀
- 限时折扣
-- 集点 / 打卡
+- 次卡模板 / 打卡
- 营销日历
### C 端主要承接点
+
- `T01 首页`
- `T02 点餐页`
- `P09 领券中心页`
- `P10 秒杀活动页`
- `P11 限时折扣活动页`
- `P03 结算确认页`
-- `T04 我的页`
+- `T04` 相关入口
-### 说明
-- 营销域不是“独立存在”的，它必须嵌入首页、点餐、结算、我的这几个核心页面
-- 真正的设计重点不是活动页本身，而是活动如何导流到商品和支付
+### 当前结论
+
+- 活动内容必须服从“当前门店 + 当前场景 + 当前资格”
+- 首页活动位必须动态化，不做固定八宫格
+- 满减和新客活动主要是规则结果展示，不独立成重页面
+- 秒杀和限时折扣都属于正式活动会场，但必须导流回标准商品、购物车、结算主链路
+- `P09` 当前只承接可见券模板，不把顾客个人券包状态写死
---
-## 4.5 会员资产域
+## 4.5 会员与资产域
### 后台来源
+
- 会员管理
+- 会员等级体系
- 积分商城
- 储值卡
- 消息触达
### C 端主要承接点
+
- `T04 我的页`
- `P12 会员中心页`
- `P13 积分商城页`
- `P14 储值充值页`
- `P15 次卡页`
-- `P16 消息中心页`
- `P03 结算确认页`
+- `P16 消息中心页` 预留职责
-### 说明
-- 会员资产域是“我的”页成为留存中心的关键
-- 所有资产页都不能只做展示，必须回流到点餐页或结算页形成使用闭环
+### 当前结论
+
+- `T04` 是聚合页，不是资产真源
+- 会员中心重点是当前等级、当前权益和等级说明，不强调复杂成长进度条
+- 积分商城重点是余额、可兑换内容和兑换记录，不反向扩成订单积分抵扣总入口
+- 储值页要和后台记账支付方式分层看待，不能直接照搬后台支付枚举
+- `message-reach` 是后台发送中心，不等于顾客消息中心
---
-## 4.6 顾客、财务、分析域
+## 4.6 顾客、财务与分析域
### 后台来源
+
- 顾客列表
- 顾客画像
- 顾客分析
- 财务概览
- 交易流水
-- 报表、结算、成本、发票
+- 发票
+- 到账查询
+- 经营报表
+- 成本管理
+- 工作台 / 分析页
### C 端承接方式
-- 当前以间接支撑为主
-- 未来可扩展的顾客可见能力包括：
- - 个性化推荐
- - 常购商品
- - 专属券包
- - 消费记录摘要
- - 电子发票入口
-### 说明
-- 这部分不建议在早期版本大量前置
-- 它更适合作为 `V3.0` 之后的精细化经营能力输入源
+- 当前以间接支撑和未来扩展为主
+
+### 当前结论
+
+- `customer / finance / dashboard` 主要是后台运营、财务和分析层
+- 不建议新增以下正式顾客页面：
+ - 客户列表页
+ - 客户画像页
+ - 客户分析页
+ - 财务概览页
+ - 交易流水总账页
+ - 到账查询页
+ - 成本分析页
+ - 顾客版 Dashboard
+- 发票能力可以保留未来扩展位，但最自然入口是订单详情页，不单独建设财务中心
---
-## 5. 当前文档范围内的直接映射优先级
+## 5. 当前直接映射优先级
### 第一优先级：必须先映射到 C 端
+
- 门店域
- 商品域
- 订单域
### 第二优先级：交易闭环稳定后映射
-- 会员资产域
+
+- 会员与资产域
- 核心营销域
### 第三优先级：后续精细化再映射
+
- 顾客分析域
- 财务增值域
-- 更复杂的消息触达与个性化能力
+- 更复杂的消息触达和个性化能力
---
-## 6. 设计与研发使用建议
+## 6. 当前明确边界
+
+- `积分商城` 当前不等于“订单积分抵扣”正式能力
+- `message-reach` 当前不等于顾客消息中心
+- `满减 / 新客有礼` 当前主要是结果展示，不是重页面
+- `营销日历` 当前不是顾客活动日历页
+- `customer / finance / dashboard` 当前默认不前置成顾客页面
+- `dashboard` 当前不作为小程序设计事实源
+
+---
+
+## 7. 设计与研发使用建议
+
+1. 做页面设计时，不要只看后台菜单名，要先判断顾客是否真的有任务价值。
+2. 做接口对接时，不要把后台对象原封不动搬到前台，要翻译成顾客任务语言。
+3. 做版本规划时，优先上线影响下单、履约、复购和活动转化的映射项。
+4. 如果某个后台能力当前没有自然顾客动作闭环，就先归为“间接支撑”或“未来扩展”，不要强行造前台页面。
-1. 做页面设计时，不要只看后台名称，要看顾客是否真的需要感知这个能力
-2. 做接口对接时，不要把后台对象原封不动搬到前台，要翻译成顾客任务语言
-3. 做版本规划时，优先上线能影响下单、履约、复购的映射项
-4. 如果某个后台能力当前没有对应的顾客价值，就先作为支撑能力，不强行做前台页面
diff --git a/Cend-MiniProgram-Prototype/docs/10-全周期研发实施顺序与交付清单.md b/Cend-MiniProgram-Prototype/docs/10-全周期研发实施顺序与交付清单.md
index 1c51ce1..cef042f 100644
--- a/Cend-MiniProgram-Prototype/docs/10-全周期研发实施顺序与交付清单.md
+++ b/Cend-MiniProgram-Prototype/docs/10-全周期研发实施顺序与交付清单.md
@@ -2,7 +2,7 @@
- 文档版本：`V1.0`
- 适用项目：`TakeoutSaaS` 小程序 C 端
-- 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但不知道先做什么”
+- 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但阶段混乱、边界失控”
---
@@ -12,8 +12,8 @@
1. 全周期应该按什么实施顺序推进
2. 每一阶段需要产出什么交付物
-3. 每一阶段达到什么标准才算可以进入下一阶段
-4. 如果是 AI 或个人开发，也能按什么顺序稳步落地
+3. 每一阶段达到什么标准，才算可以进入下一阶段
+4. 如何让实现顺序和当前已经冻结的页面职责保持一致
---
@@ -21,216 +21,304 @@
| 阶段 | 名称 | 主要目标 | 核心交付 |
| --- | --- | --- | --- |
-| S0 | 范围收口 | 定边界、定版本、定文档母版 | 08/09/10 规划文档、页面优先级 |
-| S1 | 信息架构与设计基线 | 定路由、定组件、定设计规则 | 低保真、组件清单、状态矩阵 |
-| S2 | 交易主链路开发 | 跑通首页到支付成功 | 首页、点餐、抽屉、结算、订单 |
-| S3 | 履约与售后开发 | 补齐订单服务链路 | 退款、评价、状态时间轴 |
-| S4 | 我的与资产开发 | 形成复购资产闭环 | 会员、积分、储值、次卡、领券 |
-| S5 | 增长与活动开发 | 把营销能力前置到顾客端 | 秒杀、折扣、新客礼、活动入口 |
-| S6 | 服务与消息开发 | 补齐服务能力和长期经营能力 | 消息、帮助、推荐、服务区 |
-| S7 | 联调验收与上线准备 | 全局走查和交付 | 联调清单、验收清单、演示脚本 |
+| `S0` | 范围收口 | 定边界、定版本、定母版文档 | `08 / 09 / 10` 规划文档、页面优先级 |
+| `S1` | 信息架构与设计基线 | 定路由、定组件、定状态与场景差异 | 路由、低保真、状态矩阵、组件清单 |
+| `S2` | 交易主链路开发 | 跑通选店、点餐、结算、支付主闭环 | 首页、门店、点餐、抽屉、结算、支付成功 |
+| `S3` | 履约与售后开发 | 补齐订单后半段体验 | 订单页、订单详情、退款、评价 |
+| `S4` | 我的与资产开发 | 形成身份、资产、复购聚合闭环 | 我的、会员、积分、储值、次卡 |
+| `S5` | 活动导购开发 | 把活动导流能力前置到顾客端 | 领券、秒杀、限时折扣、首页活动位 |
+| `S6` | 服务与预留补位 | 补齐服务兜底和预留职责页 | 帮助中心、消息中心职责页、服务入口 |
+| `S7` | 联调验收与上线准备 | 全局走查、联调和上线准备 | 联调清单、验收清单、演示脚本 |
---
## 3. 各阶段实施顺序
-## 3.1 S0 范围收口
+## 3.1 `S0` 范围收口
### 目标
-- 把“要做什么”和“先做什么”收口
+
+- 把“本期做什么、不做什么、先做什么”收口
### 必做事项
-1. 确认版本分期：`V1.0` / `V1.1` / `V2.0` / `V2.1` / `V3.0`
-2. 确认页面优先级：P0 / P1 / P2
-3. 确认三场景：外卖 / 自提 / 堂食
-4. 确认后台到前台映射关系
+
+1. 确认版本分期：`V1.0 / V1.1 / V2.0 / V2.1 / V3.0`
+2. 确认页面优先级：`P0 / P1 / P2`
+3. 确认三场景：`delivery / pickup / dine_in`
+4. 确认后台到前台的功能映射层级：
+ - 直接承接
+ - 间接支撑
+ - 未来扩展
+ - 明确不前置
### 必交付物
+
- `docs/08-全周期版本规划与范围分层.md`
- `docs/09-租户后台与C端功能映射总表.md`
- `docs/10-全周期研发实施顺序与交付清单.md`
- 页面优先级结论
### 完成标准
+
- 团队已明确“本期不做什么”
-- 没有人再按自己理解任意扩散页面
+- 不再有人按后台菜单数量直接推导前台页面数量
---
-## 3.2 S1 信息架构与设计基线
+## 3.2 `S1` 信息架构与设计基线
### 目标
-- 让后续页面开发不再重复讨论结构问题
+
+- 让后续页面开发不再反复讨论结构边界
### 必做事项
-1. 确认 4 个 Tab 与全部二级页路由
+
+1. 确认 `4` 个 Tab 与全部二级页、抽屉、弹层路由
2. 确认页面模板：Tab 页、二级页、抽屉、弹层
-3. 确认全局设计 Token：颜色、字号、间距、圆角、按钮层级
-4. 确认页面状态矩阵：默认态、空态、加载态、错误态、禁用态
-5. 确认三场景差异矩阵：外卖 / 自提 / 堂食
+3. 确认全局状态矩阵：
+ - 默认态
+ - 空态
+ - 加载态
+ - 错误态
+ - 禁用态
+4. 确认三场景差异矩阵：外卖 / 自提 / 堂食
+5. 确认页面职责边界：
+ - 聚合页
+ - 导购页
+ - 结果页
+ - 预留职责页
### 必交付物
+
+- 路由与页面层级总表
- 页面低保真骨架
- 全局设计基线
- 页面状态矩阵
- 场景差异矩阵
-- 通用组件清单的可实现版本
+- 通用组件清单
### 完成标准
+
- 任意页面都能用统一模板快速搭出骨架
-- 新页面设计不会脱离现有模式
+- 新页面设计不会再脱离现有模式和边界
---
-## 3.3 S2 交易主链路开发
+## 3.3 `S2` 交易主链路开发
### 目标
-- 先跑通“选店 → 点餐 → 结算 → 支付 → 查单”
+
+- 先跑通“当前门店上下文建立 → 点餐 → 结算 → 支付成功”
### 开发顺序
+
1. `T01 首页`
2. `P01 门店选择页`
-3. `T02 点餐页`
-4. `C01 商品详情抽屉`
-5. `C02 购物车抽屉`
-6. `P02 地址管理页`
-7. `P03 结算确认页`
-8. `P04 支付成功页`
-9. `T03 订单页`
-10. `P05 订单详情页`
-11. `T04 我的页（基础版）`
-12. `P18 堂食扫码确认页`
+3. `P02 地址管理页`
+4. `P18 堂食扫码确认页`
+5. `T02 点餐页`
+6. `C01 商品详情抽屉`
+7. `C02 购物车抽屉`
+8. `P03 结算确认页`
+9. `P04 支付成功页`
### 必交付物
-- 路由可跳转的交易闭环
-- 商品与购物车 mock 数据
-- 结算金额计算占位逻辑
-- 订单状态 mock 数据
+
+- 路由可跳转的交易主闭环
+- 当前门店 / 当前场景上下文闭环
+- 商品与购物车 mock 或服务层数据
+- 金额试算与结算结果占位逻辑
- 三场景基础差异展示
### 验收重点
-- 能否从首页顺利进入点餐和结算
-- 能否看清价格、优惠和实付金额
-- 能否支付成功后找到订单
+
+- 能否在正确门店和场景下进入点餐
+- 能否看清费用来源、优惠结果和实付金额
+- 能否从支付成功页进入正确后续动作
+
+### 当前阶段必须守住的边界
+
+- `P03` 手动资产当前只确认：
+ - 优惠券
+ - 余额
+ - 次卡
+- `积分抵扣` 当前不作为已冻结结算能力
+- `C05` 支付方式当前只收敛为：
+ - 微信支付
+ - 余额支付
---
-## 3.4 S3 履约与售后开发
+## 3.4 `S3` 履约与售后开发
### 目标
-- 补齐订单后半段体验
+
+- 补齐支付之后的订单、履约、售后和评价体验
### 开发顺序
-1. 回补 `T03 订单页` 状态筛选
-2. 回补 `P05 订单详情页` 履约时间轴与操作区
+
+1. `T03 订单页`
+2. `P05 订单详情页`
3. `P06 退款申请页`
4. `P07 退款详情页`
5. `P08 评价页`
### 必交付物
-- 状态时间轴
-- 退款链路
-- 评价链路
+
+- 顾客视角订单状态分组
+- 履约时间轴与场景信息区
+- 最小退款申请与退款结果页
+- 最小评价闭环
- 再来一单入口
### 验收重点
-- 用户能否快速理解订单当前状态
-- 用户能否找到退款入口和评价入口
+
+- 顾客是否能快速看懂“这单现在到哪一步了”
+- 售后入口和售后结果是否清楚
+- 评价页是否保持最小闭环，不夹带复杂运营玩法
+
+### 当前阶段必须守住的边界
+
+- 不把商家看板四列直接搬到订单页
+- 不把商家动作直接前置给顾客
+- 不把 `催单 / 骑手轨迹 / 取餐码` 写成固定必做按钮
---
-## 3.5 S4 我的与资产开发
+## 3.5 `S4` 我的与资产开发
### 目标
-- 把“我的”页做成留存与复购中心
+
+- 把“我的”做成身份、资产、服务、复购的聚合页
### 开发顺序
-1. 回补 `T04 我的页`
+
+1. `T04 我的页`
2. `P12 会员中心页`
-3. `P09 领券中心页`
-4. `P13 积分商城页`
-5. `P14 储值充值页`
-6. `P15 次卡页`
+3. `P13 积分商城页`
+4. `P14 储值充值页`
+5. `P15 次卡页`
### 必交付物
-- 我的页用户头部与资产摘要
+
+- 我的页身份头部卡、资产摘要、订单快捷入口、服务入口、复购区
- 会员权益表达
-- 券、积分、储值、次卡结构页
-- 与结算页联动入口
+- 积分余额、兑换内容与兑换记录
+- 储值余额、充值方案与充值记录
+- 次卡模板说明与使用结果记录
### 验收重点
-- 资产页是不是只“展示”没有“回流”
-- 结算页能否承接资产的使用语境
+
+- `T04` 是否仍然是聚合页，而不是资产真源
+- 资产页是否能回流到交易链路，而不只是静态展示
+- 次卡和储值是否按当前证据边界表达，没有写成过满系统
+
+### 当前阶段必须守住的边界
+
+- 不把 `优惠券数量 / 次卡数量 / 未读消息数` 写死成首页强依赖
+- 不把积分商城反向扩成订单积分抵扣总入口
+- 不把消息中心当成已经成型的完整收件箱
---
-## 3.6 S5 增长与活动开发
+## 3.6 `S5` 活动导购开发
### 目标
-- 把后台营销能力转化为前台可感知、可转化的页面能力
+
+- 把活动能力前置为“导购页 + 导流结果”，而不是活动孤岛
### 开发顺序
-1. 回补首页活动区
-2. `P10 秒杀活动页`
-3. `P11 限时折扣活动页`
-4. 回补点餐页活动标签与活动商品专区
-5. 回补结算页优惠命中说明
-6. 回补我的页活动与券入口
+
+1. 回补 `T01` 首页动态活动区
+2. 回补 `T02` 点餐页活动摘要和活动价表达
+3. `P09 领券中心页`
+4. `P10 秒杀活动页`
+5. `P11 限时折扣活动页`
+6. 回补 `P03` 结算页自动优惠命中说明
### 必交付物
-- 活动承接页
-- 活动入口与活动状态表达
-- 新客礼 / 满减 / 秒杀 / 折扣的页面承接逻辑
+
+- 首页动态活动位
+- 点餐页活动条与活动价商品表达
+- 券模板聚合页
+- 秒杀活动会场
+- 限时折扣活动会场
+- 活动导流回商品和结算的链路说明
### 验收重点
-- 活动是否能真正导流进商品和结算，而不只是展示横幅
+
+- 活动是否真正导流进商品、购物车和结算
+- `P09` 是否保持“券模板导购页”定位
+- `P10` 和 `P11` 是否明确分开，不再用一套活动页糊过去
+
+### 当前阶段必须守住的边界
+
+- 满减和新客活动主要做规则结果展示，不做重页面
+- 首页活动位必须动态化，不做固定八宫格
+- 活动页不能绕开标准交易主链路
---
-## 3.7 S6 服务与消息开发
+## 3.7 `S6` 服务与预留补位
### 目标
-- 把小程序补齐为可长期经营的用户服务端
+
+- 补齐服务兜底能力和当前只保留职责的预留页
### 开发顺序
-1. `P16 消息中心页`
-2. `P17 帮助中心页`
-3. 回补首页推荐区与我的服务区
-4. 预留未来发票、客服、投诉与个性化券包入口
+
+1. `P17 帮助中心页`
+2. `P16 消息中心页`
+3. 回补 `T04` 服务入口与说明文案
+4. 预留未来发票、客服等扩展入口位
### 必交付物
-- 消息分类页
-- FAQ / 客服 / 帮助中心
-- 红点、未读、服务入口表达
+
+- 帮助中心页
+- 消息中心职责页
+- 服务入口表达
+- 未来扩展入口位规划
### 验收重点
-- 顾客是否能在订单之外获得通知与帮助
+
+- 顾客是否能找到基础帮助和服务兜底入口
+- 是否没有把后台发送中心、FAQ CMS、客服系统直接假定为已完整存在
+
+### 当前阶段必须守住的边界
+
+- `P16` 当前只保留页面职责，不冻结完整消息 inbox
+- `P17` 当前是服务兜底页，不冻结后台 FAQ / 客服动态能力
---
-## 3.8 S7 联调验收与上线准备
+## 3.8 `S7` 联调验收与上线准备
### 目标
+
- 把前面阶段串成一套真正可演示、可交付、可联调的版本
### 必做事项
+
1. 检查所有页面路由跳转
2. 检查所有主 CTA 是否闭环
3. 检查三场景差异是否完整
-4. 检查所有金额、优惠、状态文案是否一致
+4. 检查金额、优惠、状态文案是否一致
5. 检查登录拦截与回跳逻辑
6. 检查空态、错误态、禁用态
-7. 整理演示脚本、验收清单、联调顺序
+7. 检查导购页是否都正确回流到交易主链路
+8. 整理演示脚本、验收清单、联调顺序
### 必交付物
+
- 联调清单
- 验收清单
- 演示路径脚本
- 版本发布说明
### 完成标准
+
- 业务、设计、开发、测试都能按同一套路径演示
-- 新接手的 AI 或工程师可以快速理解全局结构
+- 新接手的 AI 或工程师可以快速理解全局结构和边界
---
@@ -238,30 +326,33 @@
| 阶段 | 必交付物 |
| --- | --- |
-| S0 | 分期文档、映射文档、实施文档 |
-| S1 | 低保真、状态矩阵、场景矩阵、组件清单 |
-| S2 | 交易主链路页面、mock 数据、跳转脚本 |
-| S3 | 售后页面、状态时间轴、订单操作脚本 |
-| S4 | 我的页与资产页、资产回流脚本 |
-| S5 | 活动页、活动入口、活动承接脚本 |
-| S6 | 消息与帮助页、红点逻辑、服务入口 |
-| S7 | 联调文档、验收清单、演示说明 |
+| `S0` | 分期文档、映射文档、实施文档 |
+| `S1` | 低保真、状态矩阵、场景矩阵、组件清单 |
+| `S2` | 交易主链路页面、mock 数据、跳转脚本 |
+| `S3` | 履约售后页面、状态时间轴、订单操作脚本 |
+| `S4` | 我的页与资产页、资产回流脚本 |
+| `S5` | 活动页、活动入口、活动承接脚本 |
+| `S6` | 服务页、预留职责页、服务入口规划 |
+| `S7` | 联调文档、验收清单、演示说明 |
---
## 5. 如果是个人或 AI 独立推进，建议这样执行
-### 模式 A：先原型后代码
-1. 先补齐文档与低保真
-2. 再实现点击原型
-3. 再把点击原型转成真实小程序代码
+### 模式 A：先文档后代码
+
+1. 先补齐文档、边界和低保真
+2. 再实现可点击原型或页面骨架
+3. 最后把原型骨架转成真实小程序代码
+
+### 模式 B：边文档边代码
-### 模式 B：边原型边代码
1. 每完成一个页面规格，就同步搭建页面骨架
-2. 每完成一个阶段，就统一走查路由和状态
-3. 不要跨阶段跳做复杂资产或复杂营销
+2. 每完成一个阶段，就统一走查路由、状态和边界
+3. 不要跨阶段抢做复杂资产、复杂营销或分析页
### 模式 C：只做 MVP
+
1. 只做 `S0 + S1 + S2 + S3`
2. 上线后再根据业务反馈扩展 `S4-S7`
@@ -269,39 +360,45 @@
## 6. 阶段切换门槛
-### 从 S1 进入 S2 前
+### 从 `S1` 进入 `S2` 前
+
- 页面结构、路由、组件模板已稳定
-### 从 S2 进入 S3 前
+### 从 `S2` 进入 `S3` 前
+
- 主交易闭环可完整演示
-### 从 S3 进入 S4 前
+### 从 `S3` 进入 `S4` 前
+
- 订单与售后体验清晰，没有主流程断点
-### 从 S4 进入 S5 前
-- 资产页能回流到结算页
+### 从 `S4` 进入 `S5` 前
+
+- 资产页已能回流到交易链路
+
+### 从 `S5` 进入 `S6` 前
-### 从 S5 进入 S6 前
- 活动页不是孤岛，已能导流到交易闭环
-### 从 S6 进入 S7 前
-- 页面、消息、服务、活动、资产已基本成套
+### 从 `S6` 进入 `S7` 前
+
+- 页面、服务、活动、资产已基本成套
---
## 7. 实施时最容易踩的坑
-1. 一开始就想把所有资产和活动一起做完
-2. 先画很多视觉稿，却没有先收口状态和流程
-3. 把后台字段原样搬到前台，没有翻译成顾客语言
-4. 只做页面，不做版本边界
-5. 只做静态图，不做关键跳转与交互闭环
+1. 一开始就想把所有资产、活动、服务一起做完。
+2. 先画很多视觉稿，却没有先收口状态和流程。
+3. 把后台字段原样搬到前台，没有翻译成顾客语言。
+4. 把后台发送中心、财务驾驶舱、分析页直接当成前台设计来源。
+5. 只做页面，不做关键跳转与交互闭环。
---
## 8. 最终建议
-这套项目最稳的推进方式不是“按页面一个个做”，而是：
+这套项目最稳的推进方式不是“按页面零散推进”，而是：
1. 先按版本收口
2. 再按闭环推进
@@ -309,3 +406,4 @@
4. 最后统一联调与上线准备
只有这样，租户后台到 C 端小程序的关系才会清晰，整个项目也不会越做越散。
+
diff --git a/Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md b/Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md
new file mode 100644
index 0000000..7bd24f2
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md
@@ -0,0 +1,500 @@
+# V1.0 页面开发执行清单与验收标准
+
+- 文档版本：`V1.0`
+- 基线日期：`2026-03-16`
+- 适用项目：`TakeoutSaaS` 小程序 C 端
+- 对应前端仓库：`D:\HAZCode\TakeoutSaaS\TakeoutSaaS.C-Side-Mini-Program-V1`
+- 对应原型目录：`D:\HAZCode\TakeoutSaaS\TakeoutSaaS.Prototypes\Cend-MiniProgram-Prototype`
+- 对应冻结文档：
+ - `docs/05-页面清单总表.md`
+ - `docs/07-页面规格`
+ - `docs/09-租户后台与C端功能映射总表.md`
+ - `docs/10-全周期研发实施顺序与交付清单.md`
+- 文档目标：把“当前正式仓库真实已有内容”与“当前已经冻结的新页面职责”对齐，形成可以直接拿来排开发顺序、做验收的执行版清单。
+
+---
+
+## 1. 这份文档现在负责什么
+
+这份文档只解决 4 件事：
+
+1. 当前正式小程序仓库到底已经有了哪些页面、组件、服务和 store。
+2. 这些已有内容距离当前冻结规格还差什么。
+3. 这一轮应该按什么顺序补，不再按旧文档里的过期状态推进。
+4. 每一项补到什么程度，才算可以进入下一项。
+
+这份文档不再做两类事情：
+
+- 不再把“运行时是 mock 还是真接口”写死成长期结论。
+- 不再把“页面文件是否存在”和“页面职责是否完成”混成一件事。
+
+---
+
+## 2. 当前正式仓库真实基线
+
+本节基于以下代码现状整理：
+
+- `src/app.config.ts`
+- `src/pages/**`
+- `src/components/**`
+- `src/services/mini.ts`
+- `src/stores/**`
+
+### 2.1 已注册页面路由
+
+当前 `src/app.config.ts` 已注册 10 个页面，说明这些页面都已经进入正式仓库，而不是“未实现”。
+
+| 编码 | 页面名称 | 路由 | 当前成熟度 | 当前主要缺口 |
+| --- | --- | --- | --- | --- |
+| `T01` | 首页 | `pages/home/index` | 已有业务化骨架 | 还未完全收口为“门店上下文 + 动态活动 + 推荐导流”首页 |
+| `T02` | 点餐页 | `pages/menu/index` | 主交易页最小闭环已具备 | 还需严格对齐新规格中的渠道类目、商品分流、活动摘要 |
+| `T03` | 订单页 | `pages/orders/index` | 最小订单列表已具备 | 还需改成顾客任务语言和状态动作闭环 |
+| `T04` | 我的页 | `pages/profile/index` | 已有占位和联调页能力 | 还未收口为聚合页，不应继续维持“开发说明页”形态 |
+| `P01` | 门店选择页 | `pages/store/select/index` | 最小可用 | 还缺搜索、场景过滤、不可用门店表达、最近门店表达 |
+| `P02` | 地址管理页 | `pages/address/index` | 已有最小地址表单 | 还不是完整地址列表与选择页 |
+| `P03` | 结算确认页 | `pages/trade/checkout/index` | 已有试算、校验、建单、模拟支付链路 | 还需按新规格收口场景卡、优惠结构、备注区、支付表达 |
+| `P04` | 支付成功页 | `pages/trade/success/index` | 已有最小结果页 | 还需加强订单摘要、场景差异和兜底回流 |
+| `P05` | 订单详情页 | `pages/order/detail/index` | 已有最小详情页 | 还需补齐履约时间轴、费用明细和状态动作区 |
+| `P18` | 堂食扫码确认页 | `pages/dinein/confirm/index` | 已有最小桌号确认页 | 还不是冻结后的“扫码确认页”结构 |
+
+### 2.2 已存在的关键组件
+
+旧文档把 `C01 / C02` 写成了“未实现”，这一点已经不准确。当前正式仓库中两者都已经存在，并且已经接入点餐页。
+
+| 编码 | 组件名称 | 代码入口 | 当前成熟度 | 当前主要缺口 |
+| --- | --- | --- | --- | --- |
+| `C01` | 商品详情抽屉 | `src/components/spec-popup/index.vue` | 已存在并接入点餐页 | 还需按新规格补齐商品详情信息、组合商品选择、禁选逻辑 |
+| `C02` | 购物车抽屉 | `src/components/cart-drawer/index.vue` | 已存在并接入点餐页 | 还需按新规格补齐凑单提示、优惠摘要、空态联动和结算承接 |
+
+补充说明：
+
+- `点餐页` 当前已经不是“只有商品列表，没有抽屉组件”的阶段。
+- 当前更准确的判断是：`已有最小组件和接入关系，但还没有完全对齐冻结规格`。
+
+### 2.3 当前服务层能力
+
+当前 `src/services/mini.ts` 已具备以下前端服务封装：
+
+| 服务函数 | 能力说明 | 当前结论 |
+| --- | --- | --- |
+| `getMiniBootstrap()` | 启动引导、租户和场景上下文 | 已具备 |
+| `getStores()` | 门店列表 | 已具备 |
+| `getCategories()` | 类目列表 | 已具备 |
+| `getMenu()` | 菜单列表 | 已具备 |
+| `getProductDetail()` | 商品详情 | 已具备 |
+| `estimatePrice()` | 金额试算 | 已具备 |
+| `checkoutValidate()` | 结算校验 | 已具备 |
+| `createOrder()` | 创建订单 | 已具备 |
+| `mockPayOrder()` | 模拟支付 | 已具备 |
+| `getOrders()` | 订单列表 | 已具备 |
+| `getOrderDetail()` | 订单详情 | 已具备 |
+
+这里要明确两个边界：
+
+1. “服务函数已存在”不等于“所有后端接口都已经联真”。
+2. 本文只冻结前端 repo 的能力基线，运行时是否走 mock 以环境和后端 readiness 为准，不再写成会过期的绝对结论。
+
+### 2.4 当前 store 分工
+
+旧文档只写了 `appStore / cartStore`，这也已经过期。当前仓库已经有 4 个核心状态域。
+
+| store | 当前职责 | 当前结论 |
+| --- | --- | --- |
+| `appStore` | 租户、门店、场景、bootstrap、全局上下文 | 已具备 |
+| `cartStore` | 购物车商品、数量、金额汇总 | 已具备 |
+| `customerStore` | 顾客基础信息，如姓名、手机号 | 已具备 |
+| `fulfillmentStore` | 履约上下文，如地址、桌号 | 已具备 |
+
+当前更合理的判断不是“还没有地址和顾客状态 store”，而是：
+
+- 已经有 `customerStore / fulfillmentStore` 作为最小状态承接。
+- 还没有把它们扩成完整的地址簿、身份中心、履约域模型。
+
+---
+
+## 3. 当前冻结结论下，必须守住的实现边界
+
+这一节不是重复 `docs/07`，而是提炼成编码和验收时不能再跑偏的硬边界。
+
+### 3.1 首页边界
+
+- 首页是 `门店上下文 + 场景切换 + 动态导流 + 推荐承接` 页面。
+- 首页不是固定八宫格活动页。
+- 首页不是资产目录页。
+- 首页不是规则说明页。
+
+### 3.2 点餐与商品边界
+
+- 场景切换必须受门店 `serviceTypes` 约束，不做固定三按钮硬编码。
+- 类目展示必须跟随当前渠道和场景，不做静态类目。
+- 简单商品才允许直接加购。
+- 套餐或复杂商品必须经过规格 / 组合选择，不得直接跳过。
+
+### 3.3 结算边界
+
+- 结算页必须拆开：
+ - `手动资产`：优惠券、余额、次卡
+ - `自动优惠`：满减、新客、会员折扣、免配送费
+- `积分抵扣` 当前不是已冻结结算能力，不能先写死进主流程。
+- 当前支付方式页面表达只冻结：
+ - `微信支付`
+ - `余额支付`
+
+### 3.4 订单与售后边界
+
+- 订单页必须用顾客任务语言，而不是商家看板列名。
+- 商家操作不属于顾客端页面。
+- `催单 / 骑手轨迹 / 取餐码` 当前都不作为固定必做能力写死。
+
+### 3.5 我的页与资产边界
+
+- 我的页是聚合页，不是资产真源页。
+- 优惠券数、未读消息数、次卡实例数等不稳定字段不先冻结为首页级硬依赖。
+- 后台的“消息触达中心”不是顾客端“消息收件箱”。
+
+### 3.6 活动与增长边界
+
+- 当前值得独立页面承接的活动只冻结：
+ - 领券中心
+ - 秒杀活动
+ - 限时折扣活动
+- 满减和新客礼更偏规则结果展示，不先做重页面。
+
+---
+
+## 4. 本轮执行范围
+
+本轮执行范围只覆盖“当前正式仓库已注册页面 + 已接入关键组件”的收口工作。
+
+### 4.1 本轮必须收口
+
+- `T01` 首页
+- `T02` 点餐页
+- `T03` 订单页
+- `T04` 我的页
+- `P01` 门店选择页
+- `P02` 地址管理页
+- `P03` 结算确认页
+- `P04` 支付成功页
+- `P05` 订单详情页
+- `P18` 堂食扫码确认页
+- `C01` 商品详情抽屉
+- `C02` 购物车抽屉
+
+### 4.2 本轮明确不扩
+
+以下内容仍然在全周期规划内，但不应该在当前这份执行清单里抢主线：
+
+- `P06` 退款申请页
+- `P07` 退款详情页
+- `P08` 评价页
+- `P09` 领券中心页
+- `P10` 秒杀活动页
+- `P11` 限时折扣活动页
+- `P12` 会员中心页
+- `P13` 积分商城页
+- `P14` 储值充值页
+- `P15` 次卡页
+- `P16` 消息中心页
+- `P17` 帮助中心页
+
+这些页面不是删掉，也不是否定，而是要等当前注册页面和主交易链路先收口。
+
+---
+
+## 5. 推荐执行顺序
+
+本轮推荐顺序不再沿用旧文档的“谁文件不存在就先做谁”，而是按依赖关系推进。
+
+### 5.1 第一组：先收口上下文前置页
+
+1. `P01` 门店选择页
+2. `P18` 堂食扫码确认页
+3. `P02` 地址管理页
+
+原因：
+
+- 顾客进入点餐和结算前，必须先把 `门店 / 场景 / 履约信息` 这三个前置上下文稳定下来。
+- 当前这三页虽然都已有最小实现，但都还没有达到冻结后的页面职责。
+
+### 5.2 第二组：收口点餐与加购链路
+
+1. `T02` 点餐页
+2. `C01` 商品详情抽屉
+3. `C02` 购物车抽屉
+
+原因：
+
+- 点餐页已经是当前仓库里最接近真实业务的主链路页面。
+- 现在更值得做的是“对齐冻结规格”，而不是重新从零搭页。
+- 商品详情抽屉和购物车抽屉已经接入点餐页，应该和 `T02` 一起收口，而不是分离推进。
+
+### 5.3 第三组：收口结算与支付结果
+
+1. `P03` 结算确认页
+2. `P04` 支付成功页
+
+原因：
+
+- 当前 repo 已经有建单和模拟支付能力。
+- 真正缺的是“页面职责表达”和“支付后承接”是否与冻结结论一致。
+
+### 5.4 第四组：收口订单后链路
+
+1. `T03` 订单页
+2. `P05` 订单详情页
+
+原因：
+
+- 订单页和详情页已经有最小能力，适合在支付闭环收口后继续精修。
+- 这一步的目标是让顾客能看懂、找得到、做得了下一步动作。
+
+### 5.5 第五组：最后回补聚合页
+
+1. `T01` 首页
+2. `T04` 我的页
+
+原因：
+
+- 首页和我的页目前都已有入口骨架，但都还不是最终职责形态。
+- 它们依赖前面几组页面的上下文、动作和可跳转目标，适合最后统一回补。
+
+---
+
+## 6. 逐项执行清单与验收标准
+
+### 6.1 `P01` 门店选择页
+
+- 当前状态：
+ - 已有页面文件和最小切店能力。
+ - 已能承接基础门店列表展示。
+- 本轮必须补齐：
+ - 门店搜索。
+ - 按当前场景或门店 `serviceTypes` 过滤 / 标记可用性。
+ - 最近使用门店或定位门店的结构占位。
+ - 切店后的全局上下文刷新和回跳逻辑。
+- 验收标准：
+ - 切店后 `首页 / 点餐页 / 结算页` 上下文同步变化。
+ - 当前场景不支持的门店不能被误选。
+ - 页面具备加载态、空态、异常态。
+
+### 6.2 `P18` 堂食扫码确认页
+
+- 当前状态：
+ - 已有最小桌号输入和保存能力。
+ - 目前更像“桌号保存页”，还不是扫码确认页。
+- 本轮必须补齐：
+ - 扫码结果确认卡。
+ - 桌台信息区和堂食规则说明区。
+ - 确认后切换场景为 `dine_in`。
+ - 确认后进入点餐页，不再只是保存后返回。
+- 验收标准：
+ - 有扫码参数时能正确承接。
+ - 无扫码参数时有明确兜底路径。
+ - 确认后点餐页进入堂食上下文。
+
+### 6.3 `P02` 地址管理页
+
+- 当前状态：
+ - 已有最小地址表单。
+ - 依赖 `customerStore + fulfillmentStore` 保存单地址信息。
+- 本轮必须补齐：
+ - 地址列表态。
+ - 当前选中地址态。
+ - 默认地址标记。
+ - 新增 / 编辑入口占位。
+ - 从结算页进入、选择后返回的链路。
+- 验收标准：
+ - 外卖场景可进入并带回选中地址。
+ - 自提 / 堂食场景不误导进入地址选择。
+ - 空地址时有明确引导。
+
+### 6.4 `T02` 点餐页
+
+- 当前状态：
+ - 已有分类、菜单、场景切换、加购、抽屉联动等基础能力。
+ - 是当前仓库最接近交易主链路完成态的页面。
+- 本轮必须补齐：
+ - 类目展示严格跟随当前渠道和场景。
+ - 搜索区、活动摘要区、类目高亮与吸顶表达。
+ - 简单商品直接加购。
+ - 复杂商品进入 `C01`，不直接跳过选择过程。
+ - 底部购物车栏与 `C02` 的联动收口。
+- 验收标准：
+ - 切换门店或场景后菜单和类目刷新正确。
+ - 售罄商品不能误加购。
+ - 页面结构与 `docs/07-页面规格/02-Tab-点餐页.md` 一致。
+
+### 6.5 `C01` 商品详情抽屉
+
+- 当前状态：
+ - `spec-popup` 组件已存在并接入点餐页。
+ - 已不是“未实现”状态。
+- 本轮必须补齐：
+ - 商品图、描述、标签、销量、价格表达。
+ - 规格组、做法、加料、套餐组合选择。
+ - 金额实时变化。
+ - 售罄、禁选、默认选中规则。
+ - 复杂商品加购写入 `cartStore`。
+- 验收标准：
+ - 从点餐页商品卡能稳定打开。
+ - 选择项变化后金额即时刷新。
+ - 关闭再打开时状态重置策略明确且一致。
+
+### 6.6 `C02` 购物车抽屉
+
+- 当前状态：
+ - `cart-drawer` 组件已存在并接入点餐页。
+ - 已具备最小购物车编辑基础。
+- 本轮必须补齐：
+ - 商品行编辑、数量增减、清空动作。
+ - 优惠摘要或凑单提示区。
+ - 空购物车联动关闭或空态提示。
+ - 去结算动作与 `P03` 的承接。
+- 验收标准：
+ - 数量和金额变化实时同步。
+ - 清空后底部栏和抽屉状态同步清零。
+ - 无商品时不能继续进入结算。
+
+### 6.7 `P03` 结算确认页
+
+- 当前状态：
+ - 已有金额试算、结算校验、建单、模拟支付。
+ - 已具备最小闭环能力。
+- 本轮必须补齐：
+ - 外卖 / 自提 / 堂食三场景差异卡片。
+ - 地址区 / 自提门店区 / 堂食桌台区。
+ - `手动资产` 与 `自动优惠` 分开展示。
+ - 备注区和附加说明区。
+ - 支付方式表达只先收口为 `微信支付 / 余额支付`。
+- 验收标准：
+ - 无商品不能提交。
+ - 金额明细、优惠明细、应付金额逻辑一致。
+ - 不把 `积分抵扣` 先写死进主结算流程。
+
+### 6.8 `P04` 支付成功页
+
+- 当前状态：
+ - 已有最小结果页。
+ - 已支持跳订单详情、订单列表、继续点餐。
+- 本轮必须补齐：
+ - 订单摘要区。
+ - 场景差异信息区，如配送预计、自提提示、桌台信息。
+ - 缺少订单上下文时的兜底回流。
+ - 与 `P03` 的稳定跳转关系。
+- 验收标准：
+ - 结算成功后稳定进入。
+ - 从结果页可继续进入详情、订单页或点餐页。
+ - 直接打开时不会停留在无意义空白页。
+
+### 6.9 `T03` 订单页
+
+- 当前状态：
+ - 已有最小订单列表和状态切换基础。
+- 本轮必须补齐：
+ - 顾客视角状态筛选。
+ - 场景信息和核心动作区。
+ - 去支付、查看详情、再来一单等动作承接。
+ - 空态回流点餐页。
+- 验收标准：
+ - 订单状态表达是顾客语言，不是后台列名。
+ - 各卡片 CTA 与详情页动作一致。
+ - 不强行冻结 `催单 / 骑手轨迹 / 取餐码`。
+
+### 6.10 `P05` 订单详情页
+
+- 当前状态：
+ - 已有最小详情页和基础状态展示。
+- 本轮必须补齐：
+ - 履约时间轴。
+ - 商品清单和费用明细。
+ - 基础信息区，如订单号、时间、支付方式、备注。
+ - 按状态显示底部动作。
+- 验收标准：
+ - 未支付、履约中、完成、关闭等状态动作不混乱。
+ - 未找到订单时有空态和回流。
+ - 页面结构与 `docs/07-页面规格/11-订单详情页.md` 对齐。
+
+### 6.11 `T01` 首页
+
+- 当前状态：
+ - 已有门店上下文、场景切换、部分业务展示骨架。
+ - 当前仍残留较多“项目说明型”表达。
+- 本轮必须补齐：
+ - 按门店支持能力驱动的场景切换。
+ - 动态活动区，而不是固定八宫格。
+ - 推荐商品区、服务信息区、导流入口区。
+ - 减少开发说明模块对主视觉的占用。
+- 验收标准：
+ - 首页首先服务交易导流，而不是展示开发说明。
+ - 页面结构与 `docs/07-页面规格/01-Tab-首页.md` 一致。
+ - 首页能稳定导流到点餐、订单、活动和服务页。
+
+### 6.12 `T04` 我的页
+
+- 当前状态：
+ - 已有页面和占位模块。
+ - 当前仍偏联调 / 演示页。
+- 本轮必须补齐：
+ - 用户头部卡。
+ - 资产摘要区。
+ - 订单快捷入口区。
+ - 会员增长入口区。
+ - 服务入口区和复购推荐区。
+- 验收标准：
+ - 我的页是聚合页，不把资产值写成唯一真源。
+ - 不把不稳定数量字段写死成强依赖。
+ - 页面结构与 `docs/07-页面规格/04-Tab-我的页.md` 一致。
+
+---
+
+## 7. 跨页面统一验收标准
+
+只要进入本轮执行范围，每个页面 / 组件都至少满足以下统一标准。
+
+### 7.1 状态标准
+
+- 有默认态。
+- 有加载态。
+- 有空态。
+- 有异常态。
+- 有禁用态。
+
+### 7.2 触控与交互标准
+
+- 主点击区域不小于 `44px`。
+- 异步按钮必须有 `loading` 或禁用反馈。
+- 错误信息尽量贴近问题区域显示。
+- 不允许通过隐藏规则让顾客猜下一步怎么做。
+
+### 7.3 上下文一致性标准
+
+以下上下文跨页必须一致：
+
+- 当前门店
+- 当前场景
+- 购物车内容
+- 当前地址或桌台信息
+- 结算金额口径
+
+### 7.4 文案标准
+
+- 用顾客语言，不用商家后台语言。
+- 用动作导向文案，不用系统字段名堆砌文案。
+- 同一种状态在不同页面不要出现冲突叫法。
+
+---
+
+## 8. 当前这份文档的使用方式
+
+如果现在继续推进正式小程序仓库，建议直接按下面节奏执行：
+
+1. 先做 `P01 + P18 + P02`，把前置上下文补稳。
+2. 再做 `T02 + C01 + C02`，把点餐和加购链路收口。
+3. 再做 `P03 + P04`，把支付前后闭环收口。
+4. 再做 `T03 + P05`，把订单后链路收口。
+5. 最后回补 `T01 + T04`，把聚合页改成最终职责形态。
+
+一句话结论：
+
+当前正式仓库已经不是“很多页面还不存在”的阶段，而是“多数关键页面都已有最小实现，现在要按新冻结规格逐项收口”的阶段。
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/00-总览.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/00-总览.md
new file mode 100644
index 0000000..69f4283
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/00-总览.md
@@ -0,0 +1,111 @@
+# 租户管理员功能重构梳理总览
+
+## 1. 这套文档解决什么问题
+
+这套文档不是重新发明一套“小程序理想结构”，而是把：
+
+1. `TenantUI` 里已经真实存在的租户管理员能力
+2. 旧版小程序原型文档里的页面与链路设计
+
+重新做一遍对齐、裁剪和纠偏。
+
+目标是把后台能力翻译成顾客任务语言，并明确：
+
+- 哪些能力应该直接映射到小程序
+- 哪些能力只作为小程序背后的规则支撑
+- 哪些旧页面设计不合理，应该收敛、拆分或延后
+
+---
+
+## 2. 事实源优先级
+
+### 第一优先级：真实后台实现
+
+以 `TakeoutSaaS.TenantUI/apps/web-antd/src/views` 与 `src/api` 为主源。
+
+当前已确认的后台业务域包括：
+
+- `merchant`
+- `store`
+- `product`
+- `order`
+- `marketing`
+- `member`
+- `customer`
+- `finance`
+- `dashboard`
+
+### 第二优先级：旧版小程序原型文档
+
+旧文档继续保留，但只作为“待校正参考”，重点参考：
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/05-页面清单总表.md`
+- `docs/09-租户后台与C端功能映射总表.md`
+- `docs/07-页面规格/`
+
+### 覆盖规则
+
+从本目录开始，凡是已经完成的批次，其结论优先级高于旧版总表和旧版单页规格中对应范围的描述。
+
+---
+
+## 3. 分批方式
+
+本轮不按后台菜单一块块讲，也不按小程序页面一页页散着讲，而是按顾客真实链路拆批次。
+
+| 批次 | 链路主题 | 主要后台域 | 主要小程序承接页 | 当前状态 |
+| --- | --- | --- | --- | --- |
+| `B01` | 店铺进入与可下单前提链路 | `merchant` + `store` | `T01`、`P01`、`P02`、`T02`头部、`P03`、`P18` | 已完成 |
+| `B02` | 菜单浏览与加购链路 | `product` | `T02`、`C01`、`C02`、首页推荐区 | 已完成 |
+| `B03` | 结算与支付链路 | `order` + `marketing` + `member` + `store` | `P03`、`P04`、优惠/支付弹层 | 已完成 |
+| `B04` | 履约、订单、售后链路 | `order` + `store` | `T03`、`P05`、`P06`、`P07`、`P08` | 已完成 |
+| `B05` | 我的、资产、消息、复购链路 | `member` + `marketing` | `T04`、`P12`、`P13`、`P14`、`P15`、`P16` | 已完成 |
+| `B06` | 活动导购与增长链路 | `marketing` | `T01`、`T02`、`P09`、`P10`、`P11` | 已完成 |
+| `B07` | 精细化运营与不前置能力 | `customer` + `finance` + `dashboard` | 间接支撑 / 未来扩展 | 已完成 |
+
+---
+
+## 4. 每一批固定输出模板
+
+后续每一批都按同一结构整理，避免越做越乱：
+
+1. 批次范围与证据源
+2. 后台真实功能清单
+3. 小程序承接页面与组件
+4. 不合理设计点
+5. 调整后的页面职责与映射结论
+6. 对下一批的依赖与冻结项
+
+---
+
+## 5. 当前已落地成果
+
+- `01-门店前置链路.md`
+- `02-菜单浏览与加购链路.md`
+- `03-结算与支付链路.md`
+- `04-履约订单与售后链路.md`
+- `05-我的资产消息复购链路.md`
+- `06-活动导购与增长链路.md`
+- `07-精细化运营与不前置能力.md`
+
+已完成批次：
+
+- `01-门店前置链路.md`：梳理 `merchant/store` 对首页、选店、地址、结算、堂食扫码的影响
+- `02-菜单浏览与加购链路.md`：梳理 `product` 对点餐页、商品详情抽屉、购物车抽屉的影响
+- `03-结算与支付链路.md`：梳理 `order/marketing/member/store` 对结算页、支付方式、支付成功页的影响
+- `04-履约订单与售后链路.md`：梳理 `order/store` 对订单页、订单详情、退款结果、评价页的影响，并明确商家看板能力与顾客端页面的边界
+- `05-我的资产消息复购链路.md`：梳理 `member/marketing` 对我的页、会员中心、积分商城、储值充值、次卡、消息入口和复购入口的影响，并明确聚合页与真实资产源的边界
+- `06-活动导购与增长链路.md`：梳理 `marketing` 对首页活动区、点餐页活动提示、领券中心、秒杀页、限时折扣页的影响，并明确哪些活动适合独立成页、哪些只应作为规则结果存在
+- `07-精细化运营与不前置能力.md`：梳理 `customer/finance/dashboard` 对小程序的间接支撑边界，并明确哪些后台运营、财务、驾驶舱能力不应直接前置成顾客页面
+
+---
+
+## 6. 当前工作规则
+
+- 优先做“功能映射 + 合理性审查”，暂不直接下钻到字段级页面规格
+- 一个批次冻结后，再进入下一批
+- 如果旧文档和后台真实能力冲突，以后台真实能力为准
+- 如果后台能力当前对顾客没有清晰价值，就先归为“间接支撑”或“未来扩展”，不强行前置
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/01-门店前置链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/01-门店前置链路.md
new file mode 100644
index 0000000..557290d
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/01-门店前置链路.md
@@ -0,0 +1,375 @@
+# B01 门店前置链路
+
+## 1. 批次目标
+
+本批次只解决一件事：
+
+在顾客真正开始点餐之前，哪些租户管理员配置会决定“能不能下单、在哪下单、按什么场景下单、费用和履约规则怎么感知”。
+
+这一批覆盖的不是“商品怎么卖”，而是“顾客能不能进入正确的点餐上下文”。
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/merchant/center`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/hours`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/delivery`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/pickup`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/fees`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/dine-in`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/store/staff`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/merchant`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/store*`
+
+### 旧版小程序参考
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/01-Tab-首页.md`
+- `docs/07-页面规格/05-门店选择页.md`
+- `docs/07-页面规格/06-地址管理页.md`
+- `docs/07-页面规格/09-结算确认页.md`
+- `docs/07-页面规格/24-堂食扫码确认页.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 商户中心 | 商户名称、经营模式、联系电话、邮箱、注册地址、地理定位、门店关联 | 部分可感知 | 首页品牌信息、门店信息、帮助中心/联系商家 | 间接支撑为主 |
+| 门店列表 | 门店名称、地址、负责人、联系方式、封面图、营业状态、审核状态、服务方式 | 是 | 首页当前门店、门店选择页、点餐页头部 | 直接承接 |
+| 营业时间 | 每周营业时段、配送时段、自提时段、节假日/特殊营业 | 是 | 首页服务摘要、门店选择页、点餐页头部、结算页 | 直接承接 |
+| 配送设置 | `polygon/radius` 两种配送模式，范围、梯度、配送费、起送门槛、ETA、容量、最大距离 | 是 | 门店选择页、地址管理、结算页、首页服务摘要 | 直接承接 |
+| 自提设置 | 基础规则、`big/fine` 两种时间模式、预约天数、同日自提、容量、截止时间、预览时段 | 是 | 首页服务摘要、结算页自提时间、点餐前场景可用性 | 直接承接 |
+| 费用设置 | 起送价、基础配送费、免配送门槛、包装费模式、包装费阶梯、餐具费、其他费用 | 是，但不是全部字段都直出 | 首页摘要、结算页费用明细 | 部分直接承接 |
+| 堂食管理 | 堂食开关、默认用餐时长、超时提醒、区域、桌位、批量生成桌位 | 是 | 堂食扫码确认页、堂食点餐页头部、结算页堂食信息卡 | 直接承接 |
+| 员工排班 | 员工、班次模板、周排班、复制排班 | 否 | 无独立页面，仅影响 ETA/服务稳定性 | 间接支撑 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+### 4.1 可以直接前置给顾客的字段
+
+- 门店名称
+- 门店地址
+- 联系电话
+- 当前营业状态
+- 当前支持的服务方式：`delivery / pickup / dine_in`
+- 当前场景下的营业时间或可用时段
+- 当前场景下的履约信息：
+ - 外卖：配送范围、预计送达、起送门槛、配送费
+ - 自提：可预约时间、是否支持当天自提
+ - 堂食：门店、桌号、是否可入桌
+- 费用相关顾客可见项：
+ - 起送金额
+ - 配送费
+ - 打包费
+ - 餐具费
+
+### 4.2 只作为计算或状态支撑，不直接裸露给顾客的字段
+
+- 门店审核状态 `draft / pending / rejected`
+- 地理定位失败原因、后台重试定位动作
+- 配送容量上限 `hourlyCapacityLimit`
+- 配送模式实现细节 `polygonGeoJson`
+- 平台服务费率 `platformServiceRate`
+- 员工权限、班次模板、周排班结构
+
+### 4.3 当前不应直接做成顾客功能的能力
+
+- 商户合同
+- 商户审核日志 / 变更日志
+- 员工排班页面
+- 堂食桌位批量生成
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `T01 首页`
+
+### 这一页真正该承接什么
+
+- 当前商户品牌信息
+- 当前门店摘要
+- 当前可用场景切换
+- 当前场景下的简版服务信息
+- 进入点餐、切店、看活动的导流动作
+
+### 应该怎么表达
+
+- 首页场景切换不能固定死为三个按钮，而应由当前门店的 `serviceTypes` 决定
+- 首页只显示“当前场景相关”的一层摘要：
+ - 外卖：营业状态、预计送达、起送价、配送费
+ - 自提：营业状态、最近可约时段、是否支持当日取餐
+ - 堂食：营业状态、是否支持扫码入桌
+- 详细规则不要整块堆在首页，统一进入一个“门店服务详情抽屉”或“门店详情页”
+
+### 这一页不该承担什么
+
+- 不应同时完整展开配送、自提、堂食三套规则
+- 不应展示后台式字段，如平台服务费率、排班信息、审核信息
+
+## 5.2 `P01 门店选择页`
+
+### 这一页真正该承接什么
+
+- 切换当前门店
+- 在当前场景下判断门店是否可下单
+- 给出最关键的履约摘要
+
+### 应该怎么表达
+
+- 外卖场景下，门店卡必须结合当前地址或定位结果判断：
+ - 是否可配送
+ - 预计送达
+ - 配送费
+ - 起送门槛
+- 自提场景下，门店卡需要展示：
+ - 当前是否营业
+ - 是否支持自提
+ - 最早可预约时段
+- 堂食场景下，门店选择不是主入口，默认应由扫码绑定；手动选店只作为兜底
+
+### 这一页不该承担什么
+
+- 不应把后台审核状态直接翻译给顾客看
+- 不应只展示门店名字和距离，然后默认认为“可下单”
+
+## 5.3 `P02 地址管理页`
+
+### 这一页真正该承接什么
+
+- 管理顾客地址
+- 让顾客知道“这个地址对当前门店是否可配送”
+
+### 应该怎么表达
+
+- 地址项上的“适用范围提示”不是可选项，而是核心状态
+- 至少需要支持：
+ - 可配送
+ - 超出最大距离
+ - 不在配送区域
+ - 未达到门店服务条件时的提示
+- 从结算进入时，应支持“选择用于本次订单”并立即回传配送结果
+
+### 这一页不该承担什么
+
+- 不应只做通用通讯录
+- 不应把配送范围校验延迟到最后支付前才告诉用户
+
+## 5.4 `T02 点餐页头部`
+
+### 这一页真正该承接什么
+
+- 当前门店
+- 当前场景
+- 当前场景可售状态
+
+### 应该怎么表达
+
+- 头部需要给出顾客当前上下文：
+ - 外卖：配送到哪、是否可送
+ - 自提：当前门店、所选取餐方式
+ - 堂食：门店 + 桌号
+- 这部分是交易上下文，不是纯视觉标题
+
+## 5.5 `P03 结算确认页`
+
+### 这一页真正该承接什么
+
+- 把门店规则翻译成顾客能确认的履约信息和费用信息
+
+### 应该怎么表达
+
+- 外卖：
+ - 展示选中的地址
+ - 展示当前配送费、预计送达、是否满足起送
+- 自提：
+ - 不做自由文本时间输入
+ - 必须基于后台 `previewDays` / 时段配置生成顾客可选时间
+- 堂食：
+ - 展示门店与桌号
+ - 不展示配送相关模块
+- 费用明细只展示顾客应理解的金额项，不展示后台结算字段
+
+## 5.6 `P18 堂食扫码确认页`
+
+### 这一页真正该承接什么
+
+- 确认扫码得到的门店、区域、桌号是否有效
+- 把用户送进堂食点餐上下文
+
+### 应该怎么表达
+
+- 必须围绕后台已有能力展示：
+ - 门店名称
+ - 桌号
+ - 桌位状态是否可用
+ - 堂食是否开启
+- 如当前桌不可用，应给出明确兜底动作：
+ - 重新扫码
+ - 联系门店
+
+### 这一页不该承担什么
+
+- 不应承诺后台当前并不存在的规则，如“是否先付款”“是否支持合单”“是否支持加菜”
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 首页固定提供 `外卖 / 自提 / 堂食` 三个场景，不合理
+
+原因：
+
+- 后台门店是按 `serviceTypes` 配置场景支持范围
+- 不是所有门店都同时支持三种场景
+
+调整：
+
+- 首页和点餐页头部的场景切换必须动态生成
+- 不支持的场景不展示，或展示为禁用并给出原因
+
+### 6.2 首页把配送、自提、堂食规则一起堆在“门店服务信息区”，不合理
+
+原因：
+
+- 后台这三套规则已经足够复杂
+- 同时平铺会把首页做成“规则展示页”，而不是导流页
+
+调整：
+
+- 首页只保留当前场景摘要
+- 增加统一的“门店服务详情”承接更完整规则
+
+### 6.3 地址管理页把“适用范围提示”写成可选，不合理
+
+原因：
+
+- 后台配送有 `polygon/radius` 模式、最大距离、起送门槛、梯度费用
+- 地址是否能送，是点单前置条件，不是附加说明
+
+调整：
+
+- 地址列表必须内建配送可用性判断
+- 结算页也必须复用同一套校验结果
+
+### 6.4 结算页把自提时间理解成普通字段，不够准确
+
+原因：
+
+- 后台自提不是简单时间输入，而是两种配置模式：
+ - `big` 大时段
+ - `fine` 精细时段
+- 还带有预约天数、同日自提、容量和截止时间
+
+调整：
+
+- 结算页应做“可选时段选择器”
+- 时间数据必须由后台可预约结果驱动，不能前端自造
+
+### 6.5 堂食扫码确认页包含“先付款/合单/加菜”等规则说明，不合理
+
+原因：
+
+- 当前后台堂食管理只提供：
+ - 开关
+ - 默认用餐时长
+ - 超时提醒
+ - 区域
+ - 桌位
+- 没有“先付款/合单/加菜”配置来源
+
+调整：
+
+- 本期删除这类说明
+- 需要时作为后续堂食业务增强单独规划
+
+### 6.6 费用设置中的 `platformServiceRate` 不应前置给顾客
+
+原因：
+
+- 这是后台经营或结算字段，不是顾客决策字段
+- 顾客只需要理解最终产生的费用项
+
+调整：
+
+- 小程序只承接：
+ - 起送价
+ - 配送费
+ - 打包费
+ - 餐具费
+ - 其他真实对顾客收费的项目
+
+### 6.7 员工排班不应映射为顾客页面能力
+
+原因：
+
+- 顾客不需要看到后台排班结构
+- 它只影响服务稳定性和等待感知
+
+调整：
+
+- 仅作为 ETA、门店忙闲提示或帮助说明的间接输入
+- 不建设“排班相关前台页”
+
+### 6.8 门店选择页“点击门店即切换并返回”过于理想化
+
+原因：
+
+- 外卖场景下还要结合当前地址是否可配送
+- 全局规则里已约束：切店、切场景可能导致购物车清空
+
+调整：
+
+- 当存在购物车或地址不兼容时，必须加确认和结果提示
+- 不能默认无条件返回
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+### 7.1 直接承接
+
+- 商户品牌基础信息
+- 门店选择与门店状态
+- 场景可用性
+- 营业时间和特殊营业状态
+- 配送范围、费用、ETA、起送门槛
+- 自提可预约时段与规则摘要
+- 堂食门店与桌号有效性
+- 顾客可见费用项
+
+### 7.2 间接支撑
+
+- 商户定位状态
+- 门店审核状态
+- 配送容量上限
+- 员工排班
+- 后台复制配置能力
+
+### 7.3 本批次新增约束
+
+- 首页仍然是导流页，不变成规则总览页
+- 场景切换必须受门店配置约束
+- 地址可配送性必须前置
+- 自提时间必须来源于后台可预约结果
+- 堂食扫码确认页只承接后台真实存在的配置
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做商品链路时，需要直接继承本批次的前提：
+
+- 点餐页先有正确的门店和场景上下文，再谈商品可售
+- 商品的“不可售”状态要能接住本批次的门店/时段/场景限制
+- 购物车只能绑定一个门店 + 一个场景
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md
new file mode 100644
index 0000000..4f71b39
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md
@@ -0,0 +1,360 @@
+# B02 菜单浏览与加购链路
+
+## 1. 批次目标
+
+本批次解决的是：
+
+顾客进入点餐页后，商品该如何按场景展示、按什么规则可售、什么情况下允许快速加购、什么情况下必须进商品详情抽屉，以及购物车抽屉到底该承接哪些动作。
+
+这一批不处理支付、优惠结算和订单状态，只处理“能买什么、怎么买进购物车”。
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/detail`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/category`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/specs`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/addons`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/labels`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/schedule`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/product/batch`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/product`
+
+### 旧版小程序参考
+
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/02-Tab-点餐页.md`
+- `docs/07-页面规格/07-商品详情抽屉.md`
+- `docs/07-页面规格/08-购物车抽屉.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 商品列表 | 商品名称、副标题、主图、价格、划线价、月售、状态、库存、标签、分类、单品/套餐类型 | 是 | 点餐页、首页推荐商品卡 | 直接承接 |
+| 商品详情 | 多图、描述、排序、包装费、标签、规格模板、加料组、SKU、套餐分组、上下架/定时上架、沽清信息 | 部分直接可感知 | 商品详情抽屉、购物车、结算前价格计算 | 直接承接为主 |
+| 分类管理 | 分类名称、排序、启停、图标、描述、商品绑定、展示渠道 `wm/pickup/dine_in` | 是 | 点餐页分类导航 | 直接承接 |
+| 规格做法 | `spec/method` 模板、单选/多选、是否必选、选项加价、关联商品 | 是 | 商品详情抽屉、SKU定价 | 直接承接 |
+| 加料管理 | 加料组、必选/非必选、最少/最多可选、选项价格与库存、关联商品 | 是 | 商品详情抽屉、购物车规格摘要 | 直接承接 |
+| 商品标签 | 标签名称、颜色、排序、启停 | 是 | 商品卡、商品详情抽屉、首页推荐卡 | 直接承接 |
+| 时段供应 | 规则名称、开始结束时间、星期、启停、关联商品；未被规则覆盖商品默认全天供应 | 是 | 点餐页商品可售状态、商品详情抽屉 | 直接承接 |
+| 批量工具 | 批量调价、上下架、移动分类、多门店同步、导入导出 | 否 | 无独立前台承接 | 间接支撑 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+### 4.1 可以直接前置给顾客的字段
+
+- 商品名称
+- 商品副标题或摘要描述
+- 商品主图与附图
+- 当前售价与划线价
+- 商品标签
+- 月售等弱经营数据
+- 商品类型：单品 / 套餐
+- 当前可选规格、做法、加料
+- SKU 对应的价格与库存结果
+- 套餐分组与每组可选规则
+- 商品是否可售及原因：
+ - 下架
+ - 售罄
+ - 临时沽清
+ - 当前场景不可售
+ - 当前时段不可售
+- 商品级包装费提示（如最终确实影响顾客支付）
+
+### 4.2 只作为计算或后台配置支撑，不直接裸露给顾客的字段
+
+- `spuCode`
+- `sortWeight`
+- `warningStock`
+- `notifyManager`
+- `syncToPlatform`
+- SKU 异步保存任务状态
+- 后台批量工具范围、预览、导入导出能力
+
+### 4.3 当前不应直接做成顾客功能的能力
+
+- 批量调价
+- 批量上下架
+- 批量移动分类
+- 多门店同步商品
+- Excel 导入导出
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `T02 点餐页`
+
+### 这一页真正该承接什么
+
+- 基于当前门店 + 当前场景展示可售分类和商品
+- 快速浏览价格、标签、基本卖点
+- 对“可直接加购”和“必须先选配”的商品做分流
+- 提供搜索、分类切换、打开商品详情、打开购物车
+
+### 应该怎么表达
+
+- 分类导航不能是全场景通用一套，必须受后台分类 `channels` 约束：
+ - `wm` 对应外卖
+ - `pickup` 对应自提
+ - `dine_in` 对应堂食
+- 商品列表至少要区分三种可购买形态：
+ - 无规格无加料的单品：允许直接步进器加购
+ - 有规格/做法/加料的单品：点击加购先打开商品详情抽屉
+ - 套餐商品：默认进入商品详情抽屉做套餐分组选择
+- 商品卡上的“可售状态”不能只显示“售罄”：
+ - 要区分当前不可售原因
+ - 顾客需要知道是时段问题、场景问题还是库存问题
+- 搜索结果也必须遵守当前门店、当前场景、当前时段的可售口径
+
+### 这一页不该承担什么
+
+- 不应把营销活动条作为商品域主结构核心
+- 不应把复杂优惠解释塞进商品列表主区
+- 不应对所有商品一律显示“+”并默认快速加购
+
+## 5.2 `C01 商品详情抽屉`
+
+### 这一页真正该承接什么
+
+- 完成商品选配
+- 让顾客在一个上下文里看清楚价格、选项、库存结果
+- 把正确的商品组合加入购物车
+
+### 应该怎么表达
+
+- 抽屉需要覆盖三种商品配置形态：
+ - 单品 + 规格做法
+ - 单品 + 加料组
+ - 套餐 + 套餐分组 + 规格/加料组合
+- 规格做法区必须继承后台模板配置：
+ - `spec`
+ - `method`
+ - `single / multi`
+ - `isRequired`
+- 加料区必须继承后台约束：
+ - `required`
+ - `minSelect`
+ - `maxSelect`
+ - 选项价格
+ - 选项库存
+- 价格显示必须实时跟随 SKU 和加料变化
+- 如果商品有多图，可以轮播；但重点仍是“选择并加购”，不是做详情长页
+
+### 这一页不该承担什么
+
+- 不应保留“立即购买”分支作为默认设计
+- 不应只支持“规格 + 加料”两种模型，遗漏套餐分组
+- 不应把后台字段如 `SPU`、同步平台、预警库存暴露给顾客
+
+## 5.3 `C02 购物车抽屉`
+
+### 这一页真正该承接什么
+
+- 汇总当前门店 + 当前场景下已选商品
+- 允许快速修改数量
+- 暴露失效商品并做清理
+- 提供唯一的“去结算”主路径
+
+### 应该怎么表达
+
+- 商品行至少需要显示：
+ - 商品名
+ - 规格摘要
+ - 加料摘要
+ - 套餐选择摘要
+ - 单价
+ - 数量
+- 如果某个购物车商品因状态变化失效，要能标出原因：
+ - 已下架
+ - 已售罄
+ - 当前时段不可售
+ - 当前场景不可售
+- 购物车里的提示应以“凑单 / 起送 / 失效清理”为主
+- 去结算按钮只保留一个主动作，不再在购物车里做复杂分流
+
+### 这一页不该承担什么
+
+- 不应把它做成优惠券和营销活动的主战场
+- 不应在这里承接与商品选择无关的大量说明文字
+
+## 5.4 首页推荐商品区
+
+### 这一页真正该承接什么
+
+- 做轻量商品导流
+- 展示少量代表性商品卡
+- 把顾客送入点餐页或商品详情抽屉
+
+### 应该怎么表达
+
+- 首页推荐卡只展示摘要，不复刻点餐页分类与筛选能力
+- 如果商品需要选配，应直接拉起商品详情抽屉或跳转点餐页对应商品
+- 首页推荐商品卡上的标签必须来自后台启用状态的商品标签，不应手写运营词
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 点餐页把分类理解成一套固定菜单，不合理
+
+原因：
+
+- 后台分类管理已经有展示渠道 `wm / pickup / dine_in`
+- 同一门店不同场景下，不一定展示同一套分类
+
+调整：
+
+- 点餐页分类必须按当前场景过滤
+- 前台展示文案统一使用 `外卖 / 自提 / 堂食`，不要直接暴露后台渠道值
+
+### 6.2 旧文档默认“直接点击步进器可快速加购默认 SKU”，范围过宽
+
+原因：
+
+- 后台商品存在：
+ - 多规格 SKU
+ - 加料组
+ - 套餐分组
+- 这些商品并没有安全的“默认组合”
+
+调整：
+
+- 只有无规格、无加料、非套餐商品允许直接加购
+- 其余情况统一先开商品详情抽屉
+
+### 6.3 商品详情抽屉只写“规格做法 + 加料”，遗漏套餐分组，不合理
+
+原因：
+
+- 后台商品明确支持 `combo`
+- 套餐有 `comboGroups`、每组 `minSelect/maxSelect`
+
+调整：
+
+- 商品详情抽屉必须增加套餐分组选择区
+- 套餐商品不能套用普通单品详情结构
+
+### 6.4 点餐页把“活动提示条”放成主区块，职责混杂
+
+原因：
+
+- 活动命中结果来自营销域，不是商品域本身
+- 商品域本批次要先把可售性、分类、选配、加购做稳
+
+调整：
+
+- 点餐页允许保留轻量活动摘要
+- 但不把它当成页面主结构，不影响商品主区的信息组织
+
+### 6.5 购物车抽屉把“已命中活动摘要”作为核心结构，不合理
+
+原因：
+
+- 购物车的首要任务是确认已选商品和失效项
+- 真正完整的优惠选择与命中结果应该在结算页收口
+
+调整：
+
+- 购物车只保留轻量凑单与命中提示
+- 复杂优惠解释延后到结算与支付批次处理
+
+### 6.6 商品不可售规则写得过粗，不够贴近后台真实状态
+
+原因：
+
+- 后台有 `on_sale / off_shelf / sold_out`
+- 还有 `today / timed / permanent` 等沽清模式
+- 再叠加时段供应和场景分类限制
+
+调整：
+
+- 前台要统一翻译成顾客能理解的几类原因
+- 但底层仍需保留不同不可售来源，避免错误加购
+
+### 6.7 商品标签不能被当成任意运营文案插槽
+
+原因：
+
+- 后台标签是独立配置域，带启停、排序、颜色
+- 如果前台随意自造标签，会和后台配置失真
+
+调整：
+
+- 商品卡和详情页只展示启用状态的有效标签
+- 推荐区与点餐页共用同一套标签来源
+
+### 6.8 商品详情抽屉的“立即购买”在当前链路里不合适
+
+原因：
+
+- 当前全局规则强调单门店 + 单场景购物车上下文
+- 规格、加料、套餐、起送和费用都需要进入统一结算链路
+
+调整：
+
+- V1 去掉“立即购买”
+- 主动作统一为“加入购物车”
+
+### 6.9 批量工具不该继续出现在任何 C 端映射里
+
+原因：
+
+- 它们只服务商家运营效率
+- 对顾客没有直接任务价值
+
+调整：
+
+- 从顾客映射中明确降级为“纯间接支撑”
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+### 7.1 直接承接
+
+- 商品列表与基础商品卡
+- 场景化分类导航
+- 规格做法选择
+- 加料选择
+- 套餐分组选择
+- 商品标签
+- 商品可售状态与原因提示
+- 购物车商品汇总与失效清理
+
+### 7.2 间接支撑
+
+- 商品排序权重
+- 预警库存
+- 沽清同步平台、通知店长等后台动作
+- 批量工具
+- SKU 异步保存机制
+
+### 7.3 本批次新增约束
+
+- 分类展示必须受场景渠道约束
+- 只有简单单品可以直接快速加购
+- 套餐必须有独立选择模型
+- 购物车抽屉优先解决商品确认，不承接复杂优惠解释
+- 商品不可售原因必须能被顾客理解
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做结算与支付链路时，需要直接继承本批次前提：
+
+- 购物车中的商品组合已经是合法组合
+- 每个购物车项都有明确的规格、加料、套餐选择结果
+- 商品可售校验结果需要继续传递到结算页
+- 商品级包装费如果参与支付金额，需要在结算页统一解释清楚
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/03-结算与支付链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/03-结算与支付链路.md
new file mode 100644
index 0000000..eeaaae1
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/03-结算与支付链路.md
@@ -0,0 +1,394 @@
+# B03 结算与支付链路
+
+## 1. 批次目标
+
+本批次解决的是：
+
+顾客从购物车进入结算后，哪些信息必须确认、哪些优惠和资产应该手动选择、哪些只是后台自动命中结果、支付方式应该如何收口，以及支付成功页该如何承接后续动作。
+
+这一批不处理订单列表和售后，也不再讨论商品怎么选配，只处理“怎么结算、怎么支付、支付后看到什么”。
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/full-reduction`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/new-customer`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/punch-card`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/index`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/stored-card`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/store-fees`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/full-reduction`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/new-customer`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/punch-card`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/stored-card`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
+
+### 已完成批次依赖
+
+- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
+- `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
+
+### 旧版小程序参考
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/09-结算确认页.md`
+- `docs/07-页面规格/10-支付成功页.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 门店费用设置 | 起送价、基础配送费、免配送门槛、包装费模式、餐具费、其他费用 | 是 | 结算页费用明细、购物车凑单提示 | 直接承接 |
+| 优惠券 | 券类型 `amount_off / discount / free_delivery`、门槛、有效期、渠道、门店范围、每人限领 | 是 | 领券中心、结算页优惠选择 | 直接承接 |
+| 满减活动 | 满减/满赠/第二份优惠、适用渠道、门店范围、商品范围、是否与券叠加 | 结果可感知 | 结算页自动命中结果、商品页轻量摘要 | 直接承接为主 |
+| 新客有礼 | 新客券包、直减、邀请奖励、欢迎券、分享渠道 | 结果可感知 | 首页新客入口、结算页自动命中结果 | 直接承接为主 |
+| 会员等级权益 | 折扣、积分倍率、生日券、每月券、免配送费、优先配送、会员日额外折扣 | 部分可感知 | 结算页权益提示、会员中心 | 直接承接为主 |
+| 储值卡 | 充值方案、余额资产、充值记录、支付方式记录 | 是 | 结算页余额支付、储值充值页、我的资产摘要 | 直接承接 |
+| 积分商城 | 积分规则、兑换商品、兑换记录 | 主要用于兑换，不是明确订单抵扣契约 | 积分商城页、我的资产摘要 | 间接支撑为主 |
+| 次卡 | 次卡模板、适用范围、使用上限、额外补差、使用记录 | 是，但使用条件强依赖商品范围 | 结算页次卡可用提示/核销、次卡页 | 直接承接为主 |
+| 订单支付结果 | 订单金额、优惠金额、配送费、支付方式、支付时间、订单时间线 | 是 | 支付成功页、订单详情页 | 直接承接 |
+| 支付方式口径 | 订单/交易记录中已有 `wechat / alipay / balance / card / cash` 等类型 | 部分可感知 | 小程序支付方式弹层 | 有限直接承接 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+### 4.1 可以直接前置给顾客并允许手动操作的项
+
+- 配送地址 / 自提时间 / 堂食桌号确认
+- 订单备注
+- 餐具费相关选项
+- 优惠券选择
+- 储值余额支付开关或选择
+- 次卡核销选择
+- 支付方式选择
+
+### 4.2 可以前置给顾客，但更适合作为自动命中结果展示的项
+
+- 满减活动命中结果
+- 新客有礼命中结果
+- 会员等级折扣
+- 会员免配送费权益
+- 会员日额外折扣
+
+这些能力可以在结算页展示“已为你优惠多少”或“已享受某权益”，但不应都做成用户手动逐个开关。
+
+### 4.3 当前证据不足，不应先写成确定可用的前台能力
+
+- 订单级积分抵扣
+
+原因：
+
+- 当前能看到的积分后台主要是“积分获取规则 + 积分商城兑换”
+- 还没有看到明确的“订单结算抵扣积分”契约
+
+结论：
+
+- 结算页可以保留“积分权益提示”预留位
+- 但不要在当前梳理中把它冻结成确定的 `C04` 手动抵扣能力
+
+### 4.4 不应直接暴露给顾客的后台字段
+
+- 券模板编辑状态
+- 活动统计指标
+- 存储卡充值后台写入记录结构
+- 会员等级升级规则阈值明细
+- 次卡后台通知渠道和过期策略内部字段
+- 订单后台筛选值和财务结算渠道字段
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `P03 结算确认页`
+
+### 这一页真正该承接什么
+
+- 承接门店、场景、商品组合后的最终确认
+- 向顾客清楚解释“你为什么付这个金额”
+- 只暴露必要的可操作资产和支付动作
+
+### 应该怎么表达
+
+- 场景信息区继续继承第 1 批结论：
+ - 外卖：地址、预计送达、配送费、起送校验
+ - 自提：门店、自提时间、取餐人信息
+ - 堂食：门店、桌号
+- 商品清单区继续继承第 2 批结果：
+ - 商品
+ - 规格
+ - 加料
+ - 套餐选择摘要
+ - 商品小计
+- 优惠资产区要按“手动选择”和“自动命中”分层：
+ - 手动选择：
+ - 优惠券
+ - 储值余额支付
+ - 次卡核销
+ - 自动命中结果：
+ - 满减
+ - 新客有礼
+ - 会员折扣
+ - 免配送费权益
+- 费用明细区必须拆清楚：
+ - 商品金额
+ - 包装费
+ - 餐具费
+ - 配送费
+ - 自动优惠减免
+ - 手动资产减免
+ - 实付金额
+
+### 这一页不该承担什么
+
+- 不应把所有优惠都做成同等级可切换入口
+- 不应在金额区只给结果，不解释来源
+- 不应在当前证据不足时直接加入“积分抵扣”主流程
+
+## 5.2 `C04 优惠选择弹层`
+
+### 这一页真正该承接什么
+
+- 只承接少数真正需要“由顾客主动选择”的资产
+
+### 应该怎么表达
+
+- 第一层只做三类能力：
+ - 优惠券
+ - 储值余额支付
+ - 次卡核销
+- 每一类都需要展示不可用原因：
+ - 不适用当前门店
+ - 不适用当前场景
+ - 不适用当前商品
+ - 未达到门槛
+ - 已过期 / 已用完
+- 自动命中的活动不要塞进这个弹层让用户手动勾选
+
+### 当前冻结结论
+
+- `积分抵扣` 暂不在本弹层冻结为正式能力
+
+## 5.3 `C05 支付方式弹层`
+
+### 这一页真正该承接什么
+
+- 在用户点击“提交订单并支付”后，给出支付方式的最终确认
+
+### 应该怎么表达
+
+- 当前小程序优先只承接：
+ - 微信支付
+ - 余额支付
+- `alipay / cash / card` 虽然出现在后台交易口径里，但不应默认带入微信小程序支付方式选择
+- 如余额不足，要明确回退到微信支付或提示充值
+
+### 这一页不该承担什么
+
+- 不应展开后台财务通道配置说明
+- 不应做成复杂收银台
+
+## 5.4 `P04 支付成功页`
+
+### 这一页真正该承接什么
+
+- 明确支付完成
+- 把顾客送往下一步最关键动作
+
+### 应该怎么表达
+
+- 订单摘要必须包含：
+ - 订单号
+ - 门店名
+ - 支付金额
+ - 支付方式
+- 场景关键信息要继续继承结算结果：
+ - 外卖：预计送达
+ - 自提：取餐时间 / 取餐提示
+ - 堂食：桌号 / 当前用餐上下文
+- CTA 只保留高价值动作：
+ - 查看订单详情
+ - 继续点餐 / 再逛逛
+
+### 这一页不该承担什么
+
+- 不应停留在空泛“支付成功”文案
+- 不应再重新解释一整套优惠计算过程
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 旧结算页把“优惠券 / 积分 / 储值 / 次卡”并列成同级手动入口，不合理
+
+原因：
+
+- 当前后台证据显示：
+ - 优惠券有明确模板和选择逻辑
+ - 储值余额有明确资产属性
+ - 次卡有明确适用范围和使用记录
+ - 积分当前更偏“积分商城兑换”而不是明确订单抵扣
+
+调整：
+
+- 手动入口先收敛为：
+ - 优惠券
+ - 储值余额
+ - 次卡
+- 积分不在本批次冻结为确定抵扣能力
+
+### 6.2 满减、新客有礼、会员折扣不该都做成顾客手动选择项
+
+原因：
+
+- 这些能力在后台更像规则命中
+- 顾客真正需要的是“命中了什么、少了多少钱”，不是自己配置规则优先级
+
+调整：
+
+- 统一在结算页做自动命中展示
+- 只在必要时说明不可叠加或已自动选择最优方案
+
+### 6.3 结算页“优惠资产区”职责太宽，容易变成规则堆场
+
+原因：
+
+- 旧文档没有区分：
+ - 用户主动选择
+ - 系统自动命中
+ - 仅提示的会员权益
+
+调整：
+
+- 分成三个层次：
+ - 手动资产
+ - 自动优惠
+ - 权益提示
+
+### 6.4 `C05` 不能直接展开成通用多支付方式收银台
+
+原因：
+
+- 当前小程序信息架构明确写的是 `微信支付 / 余额支付`
+- 后台记录里虽然存在 `alipay / cash / card`，但那是后台订单/交易口径，不等于小程序都支持
+
+调整：
+
+- 小程序支付方式先收敛到微信支付和余额支付
+- 其他支付方式只保留后台记录兼容，不前置到小程序
+
+### 6.5 次卡不应在结算页做成“无差别通用抵扣”
+
+原因：
+
+- 后台次卡有明确适用范围：
+ - 全部
+ - 分类
+ - 商品
+ - 标签
+- 还带单日上限、单单上限、补差金额
+
+调整：
+
+- 结算页只在命中商品时展示可用次卡
+- 并明确“使用后剩余次数 / 是否需要补差”
+
+### 6.6 会员等级权益不应只在会员中心展示，不进入结算
+
+原因：
+
+- 后台会员权益明确包含：
+ - 折扣
+ - 免配送费
+ - 月券
+ - 生日券
+ - 会员日额外折扣
+
+调整：
+
+- 会员中心解释规则
+- 结算页展示当前订单已享受的权益结果
+
+### 6.7 结算页如果不解释金额来源，会和前两批链路断裂
+
+原因：
+
+- 第 1 批已经确认门店费用会影响支付金额
+- 第 2 批已经确认商品级包装费和商品组合会影响金额
+- 如果结算页只显示一个总价，顾客无法理解为什么变了
+
+调整：
+
+- 费用明细必须把门店费用、商品费用、优惠减免拆清楚
+
+### 6.8 支付成功页过于轻，会丢失场景关键上下文
+
+原因：
+
+- 自提用户需要立即知道取餐时间
+- 堂食用户需要回到当前桌号上下文
+- 外卖用户最关心预计送达
+
+调整：
+
+- 支付成功页必须按场景给出下一步最关键的信息
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+### 7.1 直接承接
+
+- 结算页履约信息确认
+- 商品清单与费用明细
+- 优惠券选择
+- 储值余额支付
+- 次卡核销
+- 自动优惠命中结果
+- 微信支付 / 余额支付
+- 支付成功结果页
+
+### 7.2 间接支撑
+
+- 满减活动配置细节
+- 新客有礼邀请机制
+- 会员等级升级规则
+- 后台财务支付渠道与记账口径
+- 储值卡充值后台记录结构
+
+### 7.3 暂不冻结为正式前台能力
+
+- 订单级积分抵扣
+
+需要后续补充明确的订单侧接口或规则来源后，再决定是否进入结算主流程。
+
+### 7.4 本批次新增约束
+
+- 结算页必须区分手动资产和自动优惠
+- 小程序支付方式先收敛为微信支付和余额支付
+- 次卡只在命中商品范围时出现
+- 会员权益主要展示“已享受结果”，不是让用户手动配置
+- 金额明细必须可解释
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做履约、订单、售后链路时，需要直接继承本批次前提：
+
+- 订单详情里要能回看支付方式、支付时间、优惠金额和实付金额
+- 订单状态页要能承接支付成功后的不同场景信息
+- 待支付订单要沿用本批次支付方式口径
+- 退款和售后要基于本批次已经确定的金额结构做解释
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md
new file mode 100644
index 0000000..c85cc89
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md
@@ -0,0 +1,489 @@
+# B04 履约、订单与售后链路
+
+## 1. 批次目标
+
+本批次解决的是：
+
+顾客支付完成后，订单页该怎么组织、订单详情该承接哪些履约信息、退款和评价哪些能直接落到小程序页面、哪些只是后台支撑，以及旧版原型里哪些动作设计得过满、过早、过像商家后台。
+
+这一批不再讨论“怎么结算”，而是讨论：
+
+- 顾客怎么看自己的订单
+- 顾客能看到哪些履约状态
+- 售后结果如何承接
+- 评价入口应该收敛到什么程度
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/order-hall/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/transaction.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/files.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/order/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/order/hall`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/transaction`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
+
+### 已完成批次依赖
+
+- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
+- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
+
+### 旧版小程序参考
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/03-Tab-订单页.md`
+- `docs/07-页面规格/11-订单详情页.md`
+- `docs/07-页面规格/12-退款申请页.md`
+- `docs/07-页面规格/13-退款详情页.md`
+- `docs/07-页面规格/14-评价页.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 全部订单列表 | 按 `storeId` 查询订单；支持 `status / channel / paymentMethod / keyword / date` 筛选；返回订单号、商品摘要、金额、下单时间、状态 | 是，但后台是商家视角、门店视角 | `T03` | 直接承接结构，但不能原样复用接口 |
+| 全部订单统计 | 返回 `totalOrders / totalAmount / averageAmount / refundCount` | 部分可感知 | `T03` 轻量统计或空态辅助 | 间接支撑为主 |
+| 全部订单详情 | 返回顾客信息、地址、商品明细、配送费、优惠金额、实付金额、支付方式、时间线、备注 | 是 | `P05` | 直接承接 |
+| 订单大厅看板 | 四列状态 `pending / making / delivering / completed`，并按 `deliveryType` 区分外卖/自提/堂食 | 结果可感知，但表达方式是商家操作视角 | `T03`、`P05` 状态翻译支撑 | 间接支撑为主 |
+| 商家履约动作 | `accept / reject / complete-preparation / confirm-delivery` | 否 | 不应直接前置 | 间接支撑 |
+| 履约辅助字段 | 看板卡片包含 `tableNo / isUrged / urgeCount`，并按履约类型展示不同状态文案 | 部分可感知 | `P05` 场景信息区、状态头图预留 | 有价值，但当前顾客侧契约不完整 |
+| 退款交易记录 | 订单统计有 `refundCount`，交易详情包含 `refundNo / refundReason` | 是，至少退款结果可见 | `P05`、`P07` | 结果承接成立 |
+| 评价图片上传 | 文件上传类型包含 `review_image` | 是 | `P08` | 直接承接 |
+| 评价奖励积分规则 | 积分规则包含 `reviewRewardPoints` | 结果可感知 | `P08` 成功反馈、`我的资产` 联动 | 间接支撑为主 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+## 4.1 可以直接前置给顾客的信息
+
+- 订单状态
+- 履约场景类型
+- 商品摘要与金额
+- 下单时间、支付时间、完成时间
+- 配送地址、收货人、联系电话
+- 优惠减免、配送费、实付金额
+- 订单时间线
+- 备注
+- 退款结果信息
+
+这些信息都已经在后台订单列表、订单详情或交易详情里有明确结构，小程序可以直接承接为：
+
+- `T03` 的订单卡扫读信息
+- `P05` 的详情主体内容
+- `P07` 的退款结果页
+
+## 4.2 订单状态翻译规则
+
+后台的订单状态本身已经比较完整，但小程序不能把商家管理口径原样扔给顾客，而要翻译成顾客任务语言。
+
+| 后台来源 | 后台状态口径 | 小程序表达 | 归属页签 | 说明 |
+| --- | --- | --- | --- | --- |
+| `order-hall` 状态映射 | `待付款` | `待支付` | `待支付` | 与第 3 批继续支付链路直接衔接 |
+| `order/all` 状态筛选 | `pending` | `待接单 / 商家处理中` | `进行中` | 顾客能看懂即可，不需要暴露后台枚举值 |
+| `order/all` 状态筛选 | `making` | `制作中` | `进行中` | 全场景可复用 |
+| `order/all` 状态筛选 | `delivering` | `配送中` | `进行中` | 外卖主场景 |
+| `order/all` 状态筛选 | `pickup` | `待取餐` | `进行中` | 自提主场景 |
+| `order/all` 状态筛选 | `completed` | `已完成` | `已完成` | 承接评价与复购 |
+| `order/all` 状态筛选 | `cancelled` | `已取消` | `全部` | 结果态，只读为主 |
+| `order/all` 状态筛选 | `refunded` | `退款完成 / 售后完成` | `售后` | 承接退款详情 |
+
+结论：
+
+- 小程序顶层筛选仍然建议保持顾客视角：`全部 / 待支付 / 进行中 / 已完成 / 售后`
+- 后台更细的 `pending / making / delivering / pickup` 用于驱动卡片文案和详情头图，不直接全部上翻为一级页签
+
+## 4.3 只能作为后台支撑，不应直接复制到顾客端的能力
+
+- 看板四列布局
+- 接单
+- 拒单
+- 出餐完成
+- 确认送达 / 确认取餐
+- 看板连接状态
+- 看板语音提醒
+- 今日总单数等商家运营统计
+
+这些能力是商家处理订单用的，不是顾客任务。
+
+小程序只需要承接这些动作执行后的结果，例如：
+
+- 商家已接单
+- 商品制作中
+- 已可取餐
+- 已送达
+
+而不是让顾客看到商家后台的操作按钮。
+
+## 4.4 当前证据不足，不应先写成确定的前台能力
+
+- 骑手轨迹
+- 精确预计送达时间
+- 自提取餐码 / 取餐号
+- 完整堂食订单详情桌号回显
+- 顾客主动催单接口
+- 顾客退款申请接口及其可退范围规则
+- 评价提交接口
+- 评价标签、匿名、商家回复等扩展契约
+
+原因不是这些能力一定不存在，而是当前在 `TenantUI` 中看到的是：
+
+- 商家履约结果
+- 后台订单查看结构
+- 退款交易结果
+- 评价图片上传与评价奖励规则
+
+但还没有看到完整的顾客端提交契约。
+
+因此本批次可以冻结“页面职责”，但不把这些扩展动作冻结成已经被后台完全证实的正式前台能力。
+
+## 4.5 当前从 `TenantUI` 映射到小程序还缺的关键订单契约
+
+这一步是本批最重要的一个结论：
+
+`TenantUI` 的订单接口可以作为小程序设计事实源，但不能直接当成小程序最终接口复用。
+
+原因有四个：
+
+1. `order/all` 是商家按 `storeId` 查单，小程序应是顾客按本人订单查单
+2. 订单列表和详情当前默认建立在“后台已选门店”前提上，因此不天然携带完整门店快照
+3. 订单详情当前没有明确的顾客动作标记，例如：
+ - 是否还能继续支付
+ - 是否允许退款
+ - 是否已评价 / 可评价
+4. 场景补充字段还不完整，例如：
+ - 自提的取餐号
+ - 堂食的桌号回显
+ - 外卖的配送进度扩展信息
+
+所以本批次对小程序的正确做法不是“照搬后台接口”，而是：
+
+- 沿用后台已确认的数据结构和状态口径
+- 补一层顾客视角的聚合与动作字段
+- 让 `T03 / P05 / P06 / P07 / P08` 围绕顾客任务建模，而不是围绕商家查单表建模
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `T03 订单页`
+
+### 这一页真正该承接什么
+
+- 让顾客快速找到自己的订单
+- 先看懂“现在进行到哪一步”
+- 再决定下一步动作
+
+### 应该怎么表达
+
+- 顶部主筛选建议固定为：
+ - 全部
+ - 待支付
+ - 进行中
+ - 已完成
+ - 售后
+- 场景筛选 `外卖 / 自提 / 堂食` 可以保留，但应该是二级过滤，不是主信息架构
+- 订单卡片至少展示：
+ - 门店名称
+ - 订单状态
+ - 场景标签
+ - 商品摘要
+ - 订单金额
+ - 下单时间
+- 卡片动作必须按状态收敛：
+ - `待支付`：继续支付、取消订单
+ - `进行中`：查看详情
+ - `已完成`：去评价、再来一单
+ - `售后`：查看退款详情
+
+### 这一页不该承担什么
+
+- 不应直接复制商家后台的 `待接单 / 制作中 / 配送中 / 待取餐` 四列看板
+- 不应把后台 `支付方式`、`日期区间`、`关键字` 等管理筛选照搬给顾客
+- 不应把 `催单 / 取餐码 / 再来一单` 做成所有订单都出现的固定按钮
+
+## 5.2 `P05 订单详情页`
+
+### 这一页真正该承接什么
+
+- 把订单完整讲清楚
+- 让顾客理解当前状态
+- 给出当前状态下唯一有价值的动作
+
+### 应该怎么表达
+
+- 顶部状态头图区必须明确表达当前状态，不用后台术语堆字典
+- 履约信息区按场景拆开：
+ - 外卖：
+ - 收货地址
+ - 收货人
+ - 联系方式
+ - 状态时间线
+ - 自提：
+ - 门店信息
+ - 取餐提示
+ - 状态时间线
+ - 堂食：
+ - 门店信息
+ - 桌号回显
+ - 状态时间线
+- 商品区、费用区、订单基础信息区继续继承第 3 批结论：
+ - 商品明细
+ - 优惠减免
+ - 配送费
+ - 实付金额
+ - 支付方式
+ - 支付时间
+ - 备注
+- 底部操作栏按状态与场景组合判断：
+ - `待支付`：继续支付、取消订单
+ - `进行中`：查看履约信息
+ - `已完成`：去评价、再来一单
+ - `售后`：查看退款进度
+
+### 当前必须收住的地方
+
+- 外卖详情页不要先冻结成“骑手轨迹页”
+- 自提详情页不要强制写死“取餐码一定存在”
+- 堂食详情页不要重新引入“继续加菜 / 合单 / 先付款”这类第 1 批已判定不稳的能力
+- 订单详情页不要复用商家侧 `接单 / 拒单 / 出餐完成 / 确认送达` 按钮逻辑
+
+## 5.3 `P06 退款申请页`
+
+### 这一页真正该承接什么
+
+- 在订单允许申请售后时，低阻力提交一份退款申请
+
+### 应该怎么表达
+
+- 页面内容先收敛到最小闭环：
+ - 可退款订单摘要
+ - 可退金额
+ - 退款原因
+ - 补充说明
+ - 提交按钮
+- 图片凭证上传可以保留预留位，但当前不冻结为必做
+
+### 当前冻结方式
+
+- `P06` 可以保留为正式页面
+- 但退款原因枚举、部分退款、按商品逐项退款、处理 SLA 等复杂规则，当前不冻结
+- 页面是否显示入口，应由订单详情里的状态和后端能力标记决定
+
+## 5.4 `P07 退款详情页`
+
+### 这一页真正该承接什么
+
+- 给顾客一个稳定的退款结果查看页
+
+### 应该怎么表达
+
+- 结果页至少包括：
+ - 退款状态
+ - 退款金额
+ - 退款原因
+ - 处理时间线
+ - 关联订单信息
+- 如果后端后续补充驳回原因，应直接进入该页展示
+
+### 当前冻结方式
+
+- `P07` 是可以成立的，因为后台已经有：
+ - 退款统计
+ - 退款交易明细
+ - 退款单号 / 退款原因
+- 但时间线节点名称和处理阶段数量暂时不写死
+
+## 5.5 `P08 评价页`
+
+### 这一页真正该承接什么
+
+- 让顾客在订单完成后提交最小可用评价
+
+### 应该怎么表达
+
+- 当前最稳妥的页面能力是：
+ - 订单摘要
+ - 评分
+ - 文本评价
+ - 晒图上传
+ - 提交按钮
+- 评价成功后可以轻提示“获得积分奖励”，但不能让奖励提示反过来主导页面
+
+### 当前必须收住的地方
+
+- 快捷评价标签不冻结为必做
+- 匿名开关不冻结为必做
+- 商家回复闭环不冻结为本批范围
+- 评价成功奖励样式可以做轻提示，但不应做成复杂营销弹窗
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 旧订单页把顾客页做得太像商家订单看板，不合理
+
+原因：
+
+- 商家关心的是处理效率
+- 顾客关心的是“我这单现在怎么样、下一步做什么”
+
+调整：
+
+- 小程序订单页用顾客任务语言分组
+- 更细的履约阶段下沉到卡片文案和详情页
+
+### 6.2 商家履约动作不应进入顾客端动作栏
+
+原因：
+
+- `接单 / 拒单 / 出餐完成 / 确认送达` 都是商家动作
+
+调整：
+
+- 顾客只看结果，不看操作按钮
+
+### 6.3 旧订单详情把外卖、自提、堂食能力写得过满
+
+原因：
+
+- 当前真实详情结构没有完全覆盖：
+ - 骑手轨迹
+ - 自提码
+ - 堂食桌号
+
+调整：
+
+- 先冻结“场景信息区必须有”
+- 但具体字段以当前已证实结构和后续补充契约为准
+
+### 6.4 `T03` 不能直接照搬后台筛选器
+
+原因：
+
+- 后台筛选器服务的是商家查单
+- 小程序订单页服务的是顾客找单
+
+调整：
+
+- 小程序主筛选只保留高频状态页签
+- 管理型筛选全部收掉
+
+### 6.5 `order/all` 的 `storeId` 查询前提，不适合直接当 C 端查单接口
+
+原因：
+
+- 顾客会跨门店下单
+- 订单页必须能展示门店名称
+- 顾客不应该先选门店再查自己的订单
+
+调整：
+
+- 小程序订单接口应改为顾客维度聚合查询
+- 后台现有结构只作为字段和状态参考
+
+### 6.6 退款页当前不能写成完整售后系统
+
+原因：
+
+- 现有后台证据更偏向退款结果记录
+- 还没看到完整顾客退款申请契约
+
+调整：
+
+- `P06 / P07` 保留
+- 但页面职责收敛到“申请入口 + 结果查看”
+
+### 6.7 评价页当前不能预设太多运营玩法
+
+原因：
+
+- 当前能确认的是：
+ - 可上传评价图片
+ - 可配置评价奖励积分
+- 不能确认的是：
+ - 评价提交结构
+ - 标签体系
+ - 匿名规则
+ - 商家回复
+
+调整：
+
+- `P08` 先做最小评价闭环
+- 扩展玩法后补
+
+### 6.8 `催单 / 取餐信息 / 再来一单` 不能做成固定动作
+
+原因：
+
+- 这些动作强依赖订单状态和场景
+- 有些还有接口契约缺口
+
+调整：
+
+- 所有动作都由状态机控制显示
+- 不做“每张卡片一套固定按钮”
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+## 7.1 直接承接
+
+- 订单页顾客视角筛选与订单卡
+- 订单详情的状态、商品、金额、时间线、支付信息
+- 退款结果页
+- 最小评价提交页
+- 基于状态的继续支付 / 去评价 / 查看退款详情
+
+## 7.2 间接支撑
+
+- 商家订单看板四列与履约统计
+- 商家接单、拒单、出餐、确认动作
+- 催单状态痕迹
+- 退款交易明细结构
+- 评价奖励积分规则
+
+## 7.3 暂不冻结为正式前台能力
+
+- 骑手轨迹
+- 精确送达时间
+- 自提码 / 取餐号
+- 顾客催单
+- 复杂退款规则
+- 评价标签、匿名、商家回复
+
+其中堂食桌号回显属于“业务上应该有，但当前详情契约证据不足”的字段，后续需要补到顾客侧订单详情结构中。
+
+## 7.4 本批次新增约束
+
+- `T03` 必须用顾客任务语言分组，不镜像商家看板
+- `P05` 动作栏必须由状态和场景共同决定
+- `P05` 要能回看第 3 批已冻结的支付与金额结构
+- `P06 / P07 / P08` 可以保留正式页面，但先做轻量闭环
+- 小程序订单能力应基于顾客维度聚合，不直接照搬后台 `storeId` 查单模式
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做“我的、资产、消息、复购链路”时，需要直接继承本批次结论：
+
+- 我的页要能承接最近订单、退款结果、待评价入口
+- 资产页里的积分奖励提示要和评价结果联动
+- 消息中心如果后续承接履约通知、退款通知，要沿用本批次订单状态翻译口径
+- 如果后续补齐顾客侧订单契约，应优先补：
+ - 门店快照
+ - 顾客动作标记
+ - 自提 / 堂食补充字段
+ - 退款 / 评价状态字段
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md
new file mode 100644
index 0000000..241a52e
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md
@@ -0,0 +1,620 @@
+# B05 我的、资产、消息与复购链路
+
+## 1. 批次目标
+
+本批次解决的是：
+
+顾客进入“我的”之后，哪些内容应该作为身份与资产总览集中展示，哪些资产页可以独立成立，哪些消息与服务入口现在只能保留轻入口，哪些复购信息可以直接承接，哪些还只是后台运营或客户分析能力，不能直接写成小程序正式页面契约。
+
+这一批不讨论活动导购和拉新曝光，那部分留给下一批。
+
+本批重点处理：
+
+- `T04 我的页`
+- 会员中心
+- 积分商城
+- 储值充值
+- 次卡页
+- 消息中心入口与页面边界
+- “最近订单 / 常点商品 / 再来一单”这一类复购承接
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/stored-card.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/points-mall.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/member/message-reach.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/punch-card.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/stored-card`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/points-mall`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/member/message-reach`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/punch-card`
+
+### 辅助来源
+
+以下来源不是本批主源，但对“成长值”和“复购推荐”有补充价值：
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/customer/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/profile`
+
+### 已完成批次依赖
+
+- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
+- `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
+
+### 旧版小程序参考
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/04-Tab-我的页.md`
+- `docs/07-页面规格/18-会员中心页.md`
+- `docs/07-页面规格/19-积分商城页.md`
+- `docs/07-页面规格/20-储值充值页.md`
+- `docs/07-页面规格/21-次卡页.md`
+- `docs/07-页面规格/22-消息中心页.md`
+- `docs/07-页面规格/23-帮助中心页.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 会员详情 | 会员名、入会时间、等级、积分余额、储值余额、最近订单、累计消费、标签 | 是 | `T04`、会员中心、复购区 | 直接承接 |
+| 会员等级体系 | 等级列表、升级规则、折扣、积分倍率、生日券、每月赠券、免配送费、优先配送、会员日 | 是 | 会员中心、结算权益提示 | 直接承接为主 |
+| 储值卡方案 | 充值金额、赠送金额、到账金额、状态、排序、统计 | 是 | 储值充值页 | 直接承接 |
+| 储值充值记录 | 会员、充值金额、赠送金额、到账金额、支付方式、时间 | 是 | 储值充值页、资产记录 | 直接承接 |
+| 积分规则 | 消费赠分、评价赠分、注册赠分、签到赠分、有效期规则 | 规则可感知 | 积分商城说明、评价后奖励提示 | 直接承接为主 |
+| 积分商城商品 | 兑换商品、兑换类型 `coupon / product / physical`、兑换方式 `points / mixed`、库存、限购 | 是 | 积分商城页 | 直接承接 |
+| 积分兑换记录 | 兑换记录、状态、核销方式、核销备注 | 是 | 积分商城页记录 Tab | 直接承接 |
+| 消息触达 | 消息模板、发送渠道 `inapp / sms / wechat-mini`、目标人群、发送状态、阅读率、转化率 | 顾客最终可能感知，但当前看到的是运营发送后台 | 消息中心来源层 / 未来扩展 | 间接支撑为主 |
+| 优惠券模板 | 券类型、门槛、有效期、适用门店、适用渠道、限领规则 | 顾客可感知结果，但当前主要是模板管理 | 我的页券入口、领券中心入口 | 间接支撑为主 |
+| 次卡模板 | 售价、总次数、适用范围、有效期、可转赠、补差规则 | 是 | 次卡页、结算页次卡选择 | 直接承接为主 |
+| 次卡使用记录 | 次卡实例号、使用商品、剩余次数、使用时间、补差金额 | 是 | 次卡记录页 / 订单联动 | 结果承接成立 |
+| 客户画像辅助信息 | 成长值、常购商品、复购率、偏好、最近订单 | 是，但来源属于客户分析域 | `T04` 复购区、会员成长说明 | 辅助支撑 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+## 4.1 `T04 我的页` 应该是聚合页，不是资产真源
+
+这是本批最重要的一个结构结论。
+
+“我的页”不应该自己定义一套完整资产规则，它真正的职责是：
+
+- 汇总当前身份
+- 汇总高频资产
+- 汇总订单快捷入口
+- 汇总高价值服务入口
+- 汇总复购入口
+
+也就是说：
+
+- 会员等级信息来自会员域
+- 积分与积分商品来自积分商城域
+- 储值余额与充值方案来自储值卡域
+- 次卡信息来自次卡域
+- 订单快捷入口来自订单域
+- 消息和帮助更像服务入口，不是“我的页”自己拥有的数据模型
+
+因此：
+
+- `T04` 只做“聚合 + 导航 + 轻摘要”
+- 不做复杂规则解释页
+- 不做完整记录页
+- 不做后台配置镜像
+
+## 4.2 当前可以直接前置给顾客的信息
+
+- 当前会员等级
+- 入会时间
+- 积分余额
+- 储值余额
+- 储值实充 / 赠送拆分
+- 最近订单
+- 当前可享会员权益
+- 积分商城商品与兑换记录
+- 储值充值方案与充值记录
+- 次卡模板信息
+- 次卡使用结果信息
+
+这些信息都已经在后台接口或辅助画像接口里有较清晰结构，小程序可以直接承接成：
+
+- `T04` 的头部摘要与入口区
+- 会员中心页
+- 积分商城页
+- 储值充值页
+- 次卡页中的模板与记录区
+
+## 4.3 当前只能保留入口或摘要，不应先冻结数量/明细的项
+
+- 优惠券数量
+- 我的优惠券列表
+- 我的次卡实例列表
+- 我的次卡剩余次数总览
+- 订单快捷入口上的状态角标数量
+- 消息未读数
+
+原因：
+
+- 当前后台能看到的是优惠券模板，不是顾客已领取券包
+- 当前后台能看到的是次卡模板和使用记录，不是顾客持有的完整实例清单
+- 当前后台订单域已支持列表和详情，但还没有顾客维度的快捷计数摘要
+- 当前后台消息触达是发送中心，不是顾客 inbox
+
+因此：
+
+- `T04` 可以保留这些入口
+- 但不要先把数量角标冻结为正式能力
+
+## 4.4 当前从 `TenantUI` 映射到小程序，还缺的关键聚合契约
+
+如果未来要把 `T04` 做稳，至少还需要一层“顾客资产聚合接口”。
+
+理想上需要补出的字段包括：
+
+- 顾客基础信息：
+ - 昵称 / 展示名
+ - 头像
+ - 当前会员等级
+ - 入会时间
+- 资产摘要：
+ - couponCount
+ - pointsBalance
+ - storedBalance
+ - storedGiftBalance
+ - punchCardCount
+ - punchCardRemainSummary
+- 订单快捷摘要：
+ - pendingPayCount
+ - inProgressCount
+ - completedCount
+ - afterSaleCount
+- 服务摘要：
+ - unreadMessageCount
+- 复购摘要：
+ - recentOrders
+ - topProducts
+
+在当前证据下：
+
+- 会员、积分、储值、最近订单分别都有来源
+- 但它们分散在多个后台页面和业务域里
+- 还没有一个面向顾客的统一聚合契约
+
+## 4.5 会员成长值与升级进度，当前不能写得太满
+
+旧原型把会员中心写成：
+
+- 当前等级
+- 成长值
+- 距离下一等级差值
+- 升级路径说明
+
+这里需要收住。
+
+当前已确认的事实是：
+
+- 会员域有等级规则和等级权益
+- 客户画像辅助域里有 `growthValue`
+- 会员详情里有当前等级与入会时间
+
+但当前没有看到一个专门面向顾客的“当前进度 -> 下一等级差多少”的成型契约。
+
+所以本批次冻结为：
+
+- 会员中心一定可以展示当前等级和当前权益
+- 升级规则可以展示为等级体系说明
+- “距离下一等级还差多少”保留为可扩展能力，不冻结为强必做
+
+## 4.6 消息触达不等于顾客消息中心
+
+这是本批第二个必须写死的边界。
+
+`member/message-reach` 当前真实表达的是：
+
+- 运营人员创建消息
+- 选择渠道
+- 选择目标人群
+- 定时或立即发送
+- 看送达、阅读、转化结果
+
+这和顾客在小程序里看到的“消息中心”不是一回事。
+
+顾客端真正需要的是：
+
+- 收到什么消息
+- 有没有未读
+- 点开后跳去哪个业务页面
+
+而不是：
+
+- 消息发送状态
+- 受众估算
+- 模板分类
+- 阅读率、转化率
+
+所以：
+
+- `P16 消息中心` 这个页面可以保留
+- 但不能拿 `message-reach` 页面直接映射过去
+- `message-reach` 只能作为未来消息内容来源、通知渠道来源和后台运营配置来源
+
+## 4.7 帮助中心当前没有明确后台事实源
+
+当前在 `TenantUI` 中没有看到成型的：
+
+- FAQ 配置
+- 帮助分类配置
+- 客服联系方式配置
+- 帮助文章 CMS
+
+因此：
+
+- 帮助中心在信息架构上可以保留为服务兜底页
+- 但本批次不能把它写成有完整后台支撑的正式能力
+
+## 4.8 领券中心完整导购链路不在本批冻结
+
+`T04` 可以有领券入口，但本批不展开完整领券中心细节。
+
+原因：
+
+- 本批是“我的 / 资产 / 消息 / 复购”
+- 领券中心更偏“活动导购与增长”
+- 当前后台能确认的是券模板和发券规则
+- 顾客已领取券包、券资产角标、券使用闭环，还没有在本批作为稳定主线收口
+
+结论：
+
+- `T04` 保留领券入口
+- 完整领券中心映射继续放在下一批处理
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `T04 我的页`
+
+### 这一页真正该承接什么
+
+- 身份摘要
+- 资产摘要
+- 订单快捷入口
+- 服务入口
+- 复购入口
+
+### 应该怎么表达
+
+- 头部卡先展示最稳的身份信息：
+ - 头像
+ - 展示名
+ - 当前会员等级
+ - 入会信息
+- 资产总览区先收敛到已证实的项：
+ - 积分
+ - 储值余额
+ - 会员权益入口
+- 订单快捷入口直接继承第 4 批：
+ - 待支付
+ - 进行中
+ - 已完成
+ - 售后
+- 服务入口以跳转为主：
+ - 地址管理
+ - 消息中心
+ - 帮助中心
+- 复购区以轻推荐为主：
+ - 最近订单
+ - 常点商品
+ - 再来一单
+
+### 当前必须收住的地方
+
+- 不要把“优惠券数量 / 次卡数量 / 未读消息数”全都写死在首页
+- 不要把“我的页”做成每个资产的完整记录页
+- 不要在头部卡过度强调成长值进度条
+
+## 5.2 会员中心
+
+### 这一页真正该承接什么
+
+- 告诉顾客自己现在是什么等级
+- 告诉顾客当前能享受什么权益
+- 告诉顾客等级体系如何运作
+
+### 应该怎么表达
+
+- 头部区：
+ - 当前等级
+ - 等级标识
+ - 入会时间
+- 权益区：
+ - 折扣权益
+ - 积分倍率
+ - 生日权益
+ - 每月赠券
+ - 免配送费
+ - 优先配送
+ - 会员日额外权益
+- 规则说明区：
+ - 升级条件
+ - 降级窗口
+ - 各等级权益差异
+
+### 当前冻结方式
+
+- 当前等级与权益是确定能力
+- 会员日和生日权益是确定能力
+- “距离下一等级还差多少”暂不冻结为强必做
+
+## 5.3 积分商城
+
+### 这一页真正该承接什么
+
+- 展示积分余额
+- 展示积分能换什么
+- 展示已经换过什么
+
+### 应该怎么表达
+
+- 顶部先说明：
+ - 当前积分余额
+ - 积分获取方式摘要
+- 商品列表承接真实商品模型：
+ - 商品兑换
+ - 券兑换
+ - 实物兑换
+- 记录页承接真实记录模型：
+ - 兑换时间
+ - 兑换内容
+ - 积分消耗
+ - 当前状态
+
+### 当前必须收住的地方
+
+- 核销动作是商家侧能力，不是顾客侧主操作
+- `notifyChannels` 是通知渠道配置，不是顾客手动设置项
+- 积分商城不要反向扩成“订单积分抵扣总入口”
+
+## 5.4 储值充值
+
+### 这一页真正该承接什么
+
+- 展示当前储值资产
+- 让顾客选择充值方案
+- 回看充值记录
+
+### 应该怎么表达
+
+- 顶部余额区展示：
+ - 总储值余额
+ - 实充余额
+ - 赠送余额
+- 方案区展示：
+ - 充值金额
+ - 赠送金额
+ - 到账金额
+- 记录区展示：
+ - 充值时间
+ - 支付方式
+ - 到账金额
+
+### 当前冻结方式
+
+- 页面结构可以正式成立
+- 但后台记录里的 `alipay / cash / card / balance / wechat` 不是小程序前台支付方式全量清单
+- 从小程序场景推断，充值前台支付应先收敛，不能直接镜像后台记账方式
+
+## 5.5 次卡页
+
+### 这一页真正该承接什么
+
+- 解释当前有哪些次卡
+- 解释次卡适用范围和使用规则
+- 查看已发生的使用结果
+
+### 应该怎么表达
+
+- 可购买次卡区可以承接：
+ - 卡名称
+ - 售价
+ - 次数
+ - 适用范围
+ - 有效期
+- 记录区可以承接：
+ - 使用商品
+ - 使用时间
+ - 剩余次数
+ - 补差金额
+
+### 当前必须收住的地方
+
+- “我的次卡实例列表”当前没有完整后台事实源
+- 转赠、退款、购买后实例详情不要先写满
+- 次卡页可以保留，但不要把“我的次卡”部分冻结得比证据更重
+
+## 5.6 消息中心
+
+### 这一页真正该承接什么
+
+- 顾客查看自己收到的订单、营销、系统消息
+
+### 当前正确结论
+
+- 信息架构上可以保留该页
+- 但当前后台证据不足以支撑：
+ - 顾客消息列表
+ - 未读已读状态
+ - 消息点击跳转规则
+- `message-reach` 只能作为未来内容源，不是这个页面本身
+
+### 当前冻结方式
+
+- `T04` 可以保留消息入口
+- `P16` 页面职责保留
+- 但具体字段和交互暂不冻结为正式契约
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 旧“我的页”把所有资产都当成已存在且可精确计数，不合理
+
+原因：
+
+- 当前后台事实源是分散的
+- 有些是模板
+- 有些是记录
+- 有些是后台运营页
+- 不是所有项都已经形成顾客资产摘要
+
+调整：
+
+- `T04` 先做聚合入口
+- 数量角标只对已证实字段开放
+
+### 6.2 旧会员中心把成长值升级路径写得太满
+
+原因：
+
+- 当前能稳定确认的是等级规则和权益
+- 当前用户成长进度的顾客侧契约并不完整
+
+调整：
+
+- 会员中心重心放在“当前等级 + 当前权益 + 等级说明”
+- 升级进度条不先写成强依赖
+
+### 6.3 旧消息中心容易和后台“消息触达”混淆
+
+原因：
+
+- 一个是后台发消息
+- 一个是顾客收消息
+
+调整：
+
+- 明确拆成“发送中心”和“收件中心”两套模型
+- 当前只确认前者存在
+
+### 6.4 旧储值充值页如果照搬后台支付方式，会让前台收银口径失控
+
+原因：
+
+- 后台支付方式同时承担记账兼容
+- 小程序前台支付方式应该更收敛
+
+调整：
+
+- 充值页承接充值方案和充值记录
+- 支付方式前台不镜像后台枚举
+
+### 6.5 旧次卡页把“可购买次卡”和“我的次卡”都写成已完全成型，不合理
+
+原因：
+
+- 当前模板和使用记录是清楚的
+- 但顾客实例清单和购买契约没有在后台页中清晰暴露
+
+调整：
+
+- 次卡页保留
+- 但先以模板说明和结果记录为主
+
+### 6.6 旧“我的页”复购区过像推荐系统首页，不合理
+
+原因：
+
+- 当前最稳的是：
+ - 最近订单
+ - 常购商品
+- 不是复杂算法推荐
+
+调整：
+
+- 复购区先做“最近买过什么、再来一单”
+- 不先做复杂推荐解释
+
+### 6.7 帮助中心和客服入口当前缺少真实后台来源
+
+原因：
+
+- 没有看到帮助内容管理或客服配置
+
+调整：
+
+- 先作为静态或轻运营页看待
+- 不把它写成后台强支撑能力
+
+### 6.8 `T04` 上的领券入口与领券中心详细页，不应在本批混做一件事
+
+原因：
+
+- 我的页上的领券入口是资产/增长入口
+- 领券中心本身更偏活动导购与拉新
+
+调整：
+
+- 本批只冻结入口位置和摘要边界
+- 下一批再冻结完整领券导购页
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+## 7.1 直接承接
+
+- 我的页作为聚合页
+- 会员等级与权益页
+- 积分商城商品与兑换记录
+- 储值充值方案与充值记录
+- 最近订单 / 常购商品 / 再来一单
+
+## 7.2 间接支撑
+
+- 优惠券模板配置
+- 次卡模板配置与后台使用记录
+- 消息触达后台
+- 客户画像里的成长值、偏好、复购率
+
+## 7.3 暂不冻结为正式前台能力
+
+- 优惠券数量与我的券包详情
+- 我的次卡实例详情
+- 订单快捷角标数量
+- 未读消息数与完整 inbox
+- 到下一等级的精确差值展示
+- 帮助中心的后台动态内容
+
+## 7.4 本批次新增约束
+
+- `T04` 只能做聚合摘要，不做资产真源
+- 消息中心不能拿后台 `message-reach` 直接复用
+- 会员中心先强调当前权益，不强调复杂成长值进度
+- 次卡页先强调模板与记录，不夸大“我的次卡实例”
+- 领券中心完整导购留到下一批，不在本批冻结
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做“活动导购与增长链路”时，需要直接继承本批结论：
+
+- 我的页上的领券入口只负责导流，不负责解释完整活动规则
+- 会员权益里赠券、免配送费、新客礼等增长能力，需要和活动页统一口径
+- 消息触达如果后续要给活动页做通知承接，应沿用“后台发送中心 vs 顾客消息中心”分层
+- 如果要把我的页资产卡做完整，还需要后续补：
+ - 顾客券包聚合
+ - 顾客次卡实例聚合
+ - 顾客消息 inbox 聚合
+ - 顾客首页资产摘要聚合
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md
new file mode 100644
index 0000000..1122ca2
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md
@@ -0,0 +1,554 @@
+# B06 活动导购与增长链路
+
+## 1. 批次目标
+
+本批次解决的是：
+
+租户后台里的营销活动，哪些应该在首页和点餐页作为“导购内容”出现，哪些值得独立成活动页，哪些只适合作为自动命中的规则结果存在，以及旧版原型里活动入口过多、页面职责过满、把后台运营能力误当前台页面的地方，应该怎么收住。
+
+这一批重点处理：
+
+- `T01 首页` 的活动区与快捷入口
+- `T02 点餐页` 的活动提示与活动价商品表达
+- `P09 领券中心页`
+- `P10 秒杀活动页`
+- `P11 限时折扣活动页`
+
+同时会把以下能力明确放到“规则支撑”或“未来补契约”：
+
+- 满减活动
+- 新客有礼
+- 营销日历
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/full-reduction.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/new-customer.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/seckill.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/flash-sale.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/marketing/calendar.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/coupon`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/full-reduction`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/new-customer`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/seckill`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/flash-sale`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/marketing/calendar`
+
+### 已完成批次依赖
+
+- `docs/12-租户管理员功能重构梳理/01-门店前置链路.md`
+- `docs/12-租户管理员功能重构梳理/02-菜单浏览与加购链路.md`
+- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
+- `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
+
+### 旧版小程序参考
+
+- `docs/02-信息架构与路由.md`
+- `docs/03-全局业务规则.md`
+- `docs/04-核心用户流程.md`
+- `docs/07-页面规格/01-Tab-首页.md`
+- `docs/07-页面规格/02-Tab-点餐页.md`
+- `docs/07-页面规格/15-领券中心页.md`
+- `docs/07-页面规格/16-秒杀活动页.md`
+- `docs/07-页面规格/17-限时折扣活动页.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实配置内容 | 对顾客是否直接可感知 | 小程序承接位置 | 结论 |
+| --- | --- | --- | --- | --- |
+| 优惠券模板 | 券类型、门槛、有效期、适用门店、适用渠道、每人限领、开放/暂停领取 | 是，但当前看到的是模板与总量统计，不是顾客券包 | `P09`、`T01`、`T04` 入口 | 直接承接为主 |
+| 满减活动 | `reduce / gift / second_half`，适用门店、渠道、商品范围、可否叠券 | 结果可感知 | `T02` 活动摘要、`P03` 自动命中 | 直接承接结果，不建议独立页 |
+| 新客有礼 | 欢迎礼包、直减、新客券、邀请人/被邀请人奖励、分享渠道、邀请记录 | 资格和结果可感知 | `T01` 新客入口、`P03` 自动命中、分享入口预留 | 直接承接为主，但顾客分享契约未完整 |
+| 秒杀活动 | `hourly / timed`，场次、库存、秒杀价、限购、预热、适用渠道 | 是 | `T01`、`T02`、`P10` | 直接承接 |
+| 限时折扣 | `once / recurring`，日期、时段、周几循环、折扣价、限购、适用渠道 | 是 | `T01`、`T02`、`P11` | 直接承接 |
+| 营销日历 | 汇总活动来源、活动冲突、月度排期、活动详情字段 | 否，主要是后台运营编排能力 | 首页内容编排、消息提醒节奏 | 间接支撑 |
+
+---
+
+## 4. 后台字段到 C 端的映射结论
+
+## 4.1 活动内容必须服从“当前门店 + 当前场景 + 当前资格”
+
+这是本批最重要的冻结结论。
+
+营销活动不是一个独立系统，它必须服从前面几批已经冻结的主线前提：
+
+- 第 1 批已经确认：首页和点餐页的场景切换必须跟随门店真实 `serviceTypes`
+- 第 2 批已经确认：商品展示和类目展示必须按当前渠道过滤
+- 第 3 批已经确认：满减、新客、会员权益在结算侧主要以自动命中结果存在
+- 第 5 批已经确认：我的页上的领券入口只是导流，不代表顾客券包契约已经完整
+
+因此在小程序里，所有活动展示都要同时满足：
+
+1. 当前门店可用
+2. 当前场景可用
+3. 当前用户资格成立
+4. 当前活动状态成立
+
+不能把后台营销列表里的活动直接原样铺到首页。
+
+## 4.2 首页活动区必须做“动态精选”，不能做固定八宫格
+
+旧版首页把：
+
+- 新客有礼
+- 领券中心
+- 满减活动
+- 秒杀专区
+- 限时折扣
+- 储值充值
+- 次卡专区
+- 会员中心
+
+全部做成固定入口，这个结构现在已经不合理。
+
+原因有三个：
+
+1. 这些入口不属于同一层级
+2. 有些是营销活动，有些是资产页，有些是服务页
+3. 当前营销后台本身就是动态活动，不应该被固定成静态菜单
+
+调整后：
+
+- `T01` 的活动区应该以“动态精选活动”形式出现
+- 高优先展示：
+ - 当前有效的秒杀
+ - 当前有效的限时折扣
+ - 当前可见的新客活动
+ - 当前可领取的券活动
+- 储值充值、次卡、会员中心继续留在 `T04` 为主，不再占首页核心活动位
+
+## 4.3 哪些活动适合独立成页，哪些不适合
+
+### 适合独立成页
+
+- 秒杀
+- 限时折扣
+- 领券中心
+
+原因：
+
+- 秒杀本身有场次、倒计时、库存和限购，适合做活动会场
+- 限时折扣本身有周期、时段和折扣商品集合，适合做折扣会场
+- 优惠券模板天然可以聚合成“领券中心”
+
+### 不适合独立成页
+
+- 满减活动
+- 新客有礼
+- 营销日历
+
+原因：
+
+- 满减活动本质上是规则命中，不是顾客需要手动配置的活动页
+- 新客有礼本质上是资格活动和首单激励，不适合做通用长期活动页
+- 营销日历是后台排期与冲突管理能力，不是顾客看活动日历
+
+## 4.4 满减活动应该“强感知、弱页面”
+
+满减活动的真实后台能力很强，包括：
+
+- 满减
+- 满赠
+- 第二份优惠
+- 商品范围
+- 渠道范围
+- 门店范围
+- 是否可与券叠加
+
+但这类能力在顾客侧最合理的表达，不是独立页，而是：
+
+- 首页活动摘要
+- 点餐页活动条摘要
+- 结算页自动命中结果
+
+也就是说：
+
+- 顾客应该强烈感知“现在有满减 / 第二份优惠”
+- 但不需要跳入一个复杂的“满减活动页”
+
+## 4.5 新客有礼应该“强资格、弱会场”
+
+新客有礼后台配置包括：
+
+- 礼包类型 `coupon / direct`
+- 欢迎券
+- 邀请人券
+- 被邀请人券
+- 分享渠道
+- 邀请记录
+
+这说明它更像“资格式拉新机制”，而不是一个常规会场。
+
+因此顾客侧更合理的表达是：
+
+- 首页只在资格成立时出现新客入口或新客 Banner
+- 点餐和结算时展示新客已命中结果
+- 已注册老用户如满足邀请机制，可看到分享入口
+
+但当前还不能冻结的部分是：
+
+- 邀请分享落地页
+- 邀请码 / 分享链路
+- 新客礼包领取页
+
+因为当前后台看到的是配置和记录，不是完整的顾客侧分享契约。
+
+## 4.6 领券中心可以成立，但“个人领取状态”不要先写死
+
+后台优惠券模板里已经能确认：
+
+- 券类型
+- 使用门槛
+- 有效期
+- 适用门店
+- 适用渠道
+- 每人限领
+- 开放领取 / 暂停领取
+
+但当前还没有看到明确的顾客侧：
+
+- 领取动作接口
+- 本人是否已领取
+- 本人剩余可领次数
+- 券包列表
+
+所以：
+
+- `P09` 作为“可领券模板聚合页”是成立的
+- 但 `已领取 / 去使用 / 已抢完 / 我的券包` 这类强个人状态暂时不能冻结得太重
+
+## 4.7 秒杀与限时折扣的页面职责必须分开
+
+这两个活动在后台里是完全不同的能力，不应在前台写成同一种“活动页”。
+
+### 秒杀
+
+- 有场次
+- 有库存上限
+- 有预热
+- 更强调抢购和紧迫感
+
+### 限时折扣
+
+- 有日期区间
+- 有时段
+- 可能按周循环
+- 更强调折扣强度和时间窗口
+
+所以：
+
+- `P10` 要突出场次、倒计时、库存、限购
+- `P11` 要突出折扣价、折扣力度、周期、时间窗口
+
+## 4.8 秒杀和限时折扣都不能绕开主交易链路
+
+即使有独立活动页，也不能演变成一套单独下单系统。
+
+统一原则是：
+
+- 活动商品点击后仍然进入商品详情 / 加购 / 购物车 / 结算主链路
+- 活动页只是导流页和筛选页
+- 交易解释仍回归第 2 批和第 3 批已经冻结的商品、结算、支付链路
+
+## 4.9 营销日历是“编排事实源”，不是顾客页面
+
+营销日历当前能够说明三件事：
+
+- 后台把多个营销模块整合到了统一时间轴上
+- 后台能发现活动冲突
+- 后台活动条自带 `sourceType / sourceId / detail.fields`
+
+这说明它对小程序很有价值，但价值在于：
+
+- 首页活动区排序与编排
+- 同期活动冲突避免
+- 消息提醒时机
+
+而不是在小程序里给顾客做一页“营销日历”。
+
+---
+
+## 5. 小程序页面重映射
+
+## 5.1 `T01 首页`
+
+### 这一页真正该承接什么
+
+- 当前门店当前场景下最值得展示的活动
+- 一条最短的进入点餐或活动会场的路径
+
+### 应该怎么表达
+
+- Banner 区：
+ - 优先展示当前有效活动，不固定写死类别
+ - 可承接：
+ - 秒杀会场
+ - 限时折扣会场
+ - 新客活动
+ - 领券中心
+- 快捷入口区：
+ - 从“固定菜单”改为“精选活动入口”
+ - 建议最多保留少数高价值入口
+- 推荐商品区：
+ - 可以插入活动商品分组
+ - 但仍然只是轻摘要，不直接展开复杂规则
+
+### 当前必须收住的地方
+
+- 不要固定八宫格
+- 不要把储值、次卡、会员中心继续混入首页核心营销位
+- 不要把营销日历误做成顾客活动日程
+
+## 5.2 `T02 点餐页`
+
+### 这一页真正该承接什么
+
+- 把活动结果翻译成顾客看得懂的价格和优惠提示
+- 把活动导流回商品和结算
+
+### 应该怎么表达
+
+- 顶部活动条只承接高价值摘要：
+ - 满减
+ - 新客有礼
+ - 秒杀进行中
+ - 限时折扣进行中
+- 商品卡必须支持活动表达：
+ - 秒杀价
+ - 折扣价
+ - 原价划线
+ - 限购提示
+ - 活动标签
+- 活动商品进入详情后，仍走正常选配和加购流程
+
+### 当前必须收住的地方
+
+- 不要把点餐页活动条做成所有活动的堆栈公告栏
+- 不要把满减和新客活动做成需要顾客手动开关的入口
+- 不要在点餐页里复刻整套活动会场逻辑
+
+## 5.3 `P09 领券中心页`
+
+### 这一页真正该承接什么
+
+- 集中展示当前可见的券模板
+- 引导回点餐使用
+
+### 应该怎么表达
+
+- 列表至少展示：
+ - 券名称
+ - 金额或折扣
+ - 使用门槛
+ - 有效期
+ - 适用门店
+ - 适用场景
+- 类型筛选可以保留：
+ - 满减券
+ - 折扣券
+ - 免配送费券
+
+### 当前冻结方式
+
+- 页面可以成立
+- 但用户个人领取状态和“去使用”状态不先写死
+- 领券结果最好回流到点餐页或我的页资产页，而不是停留在活动页内闭环
+
+## 5.4 `P10 秒杀活动页`
+
+### 这一页真正该承接什么
+
+- 承接强时效、强库存、强场次的活动会场
+
+### 应该怎么表达
+
+- 头部区强调：
+ - 场次
+ - 倒计时
+ - 是否预热
+- 商品卡强调：
+ - 秒杀价
+ - 原价
+ - 剩余库存 / 已抢进度
+ - 每人限购
+
+### 当前冻结方式
+
+- `P10` 是正式页面
+- 会场入口可来自首页 Banner、快捷入口、点餐页活动条
+- 但点击商品后应回到正常商品链路，不做独立活动收银台
+
+## 5.5 `P11 限时折扣活动页`
+
+### 这一页真正该承接什么
+
+- 承接折扣商品会场
+- 让顾客快速浏览“现在买更省”的商品集合
+
+### 应该怎么表达
+
+- 头部区强调：
+ - 活动名称
+ - 日期范围
+ - 时段
+ - 若为循环活动则展示周几
+- 商品卡强调：
+ - 折扣价
+ - 原价
+ - 折扣力度
+ - 每人限购
+
+### 当前冻结方式
+
+- `P11` 是正式页面
+- 要弱化“抢”的表达，强化“省”的表达
+- 也必须回到正常商品、购物车、结算主链路
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 旧首页把活动入口、资产入口、服务入口混成一层，不合理
+
+原因：
+
+- 营销入口和资产入口不是一类任务
+- 首页活动位应优先服务转化，不应变成全站目录
+
+调整：
+
+- 首页只保留动态精选活动
+- 资产和服务入口回归 `T04`
+
+### 6.2 旧首页固定 `外卖 / 自提 / 堂食` 下的活动内容，没有明确按渠道过滤，不合理
+
+原因：
+
+- 后台营销活动都有 `delivery / pickup / dine_in` 渠道范围
+
+调整：
+
+- 首页和点餐页活动必须随当前场景过滤
+
+### 6.3 旧点餐页容易把活动提示条做成“营销公告栏”，不合理
+
+原因：
+
+- 点餐页主任务是选商品，不是读活动说明
+
+调整：
+
+- 活动条只显示会影响当前购买决策的摘要
+
+### 6.4 旧原型容易默认“满减活动页”存在，但后台事实不支持这样做
+
+原因：
+
+- 满减后台是规则配置页，不是会场页
+
+调整：
+
+- 满减只做结果感知，不做独立会场
+
+### 6.5 旧原型容易默认“新客有礼页”对所有人都成立，不合理
+
+原因：
+
+- 新客活动天然依赖资格
+- 邀请分享还缺完整顾客链路
+
+调整：
+
+- 新客入口只在资格成立时展示
+- 分享和邀请链路暂不冻结为正式页面
+
+### 6.6 `P09` 不能因为后台有“开放领取 / 暂停领取”就直接假定小程序已具备完整领券状态流
+
+原因：
+
+- 当前看到的是模板管理和总量统计
+- 不是顾客个人券包状态
+
+调整：
+
+- 领券中心先聚焦“可见券模板”
+- 个人状态后补
+
+### 6.7 秒杀和限时折扣不能用一套通用活动页糊过去
+
+原因：
+
+- 秒杀强调场次、库存、预热
+- 限时折扣强调周期、时间窗口、折扣强度
+
+调整：
+
+- 两页职责分开，视觉与文案重点也要分开
+
+### 6.8 营销日历不应被误当前台功能页
+
+原因：
+
+- 它是编排后台，不是顾客任务页面
+
+调整：
+
+- 只把它作为首页和活动区编排依据
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+## 7.1 直接承接
+
+- 首页动态活动区
+- 点餐页活动摘要与活动价商品表达
+- 领券中心
+- 秒杀活动页
+- 限时折扣活动页
+
+## 7.2 间接支撑
+
+- 满减规则配置
+- 新客资格与邀请配置
+- 营销日历排期与冲突信息
+
+## 7.3 暂不冻结为正式前台能力
+
+- 满减独立活动页
+- 新客邀请分享完整链路
+- 顾客个人领券状态与券包详情
+- 顾客营销日历页
+- 由营销消息直接驱动的顾客 inbox 交互
+
+## 7.4 本批次新增约束
+
+- 首页活动位必须动态化，不做固定八宫格
+- 秒杀与限时折扣都要按当前门店和场景过滤
+- 满减和新客活动主要做规则结果展示，不做重页面
+- 活动页必须导流回商品、购物车、结算主链路
+- 领券中心先展示券模板，不先夸大用户个人状态
+
+---
+
+## 8. 对下一批的依赖
+
+下一批做“精细化运营与不前置能力”时，需要直接继承本批结论：
+
+- 营销日历、客户分析、消息触达应作为首页活动编排和提醒时机的支撑层，不直接前置给顾客
+- 如果后续要把首页活动排序做得更智能，需要补：
+ - 顾客资格判断
+ - 顾客活动点击与领取行为
+ - 顾客个性化推荐
+- 如果后续要把领券中心做完整，需要补：
+ - 顾客领券接口
+ - 券包查询接口
+ - 个人领取状态与剩余可领次数
diff --git a/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md
new file mode 100644
index 0000000..5632503
--- /dev/null
+++ b/Cend-MiniProgram-Prototype/docs/12-租户管理员功能重构梳理/07-精细化运营与不前置能力.md
@@ -0,0 +1,443 @@
+# B07 精细化运营与不前置能力
+
+## 1. 批次目标
+
+本批次解决的是：
+
+租户后台里已经存在一批很重要、但不适合直接翻译成顾客页面的能力，包括：
+
+- `customer` 的客户列表、客户画像、客户分析
+- `finance` 的财务概览、交易流水、发票、到账、成本、经营报表
+- `dashboard` 的工作台、分析页
+
+这一批不是为了再多造几个小程序页面，而是要把这类能力的边界收住，明确：
+
+- 哪些只能作为顾客体验背后的运营输入
+- 哪些只允许抽取少量结果给顾客看
+- 哪些可以留作未来扩展，但现在不能强行前置
+
+如果这一批不收口，后面很容易继续出现两个问题：
+
+1. 把后台运营视角直接搬到 C 端
+2. 误以为后台每个菜单都应该有一个对应的小程序页面
+
+---
+
+## 2. 证据源
+
+### 后台真实来源
+
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/customer/index.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/list`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/customer/analysis`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/overview.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/transaction.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/invoice.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/settlement.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/report.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/api/finance/cost.ts`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/overview`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/transaction`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/invoice`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/settlement`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/report`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/finance/cost`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/dashboard/workspace/index.vue`
+- `TakeoutSaaS.TenantUI/apps/web-antd/src/views/dashboard/analytics/index.vue`
+
+### 已完成批次依赖
+
+- `docs/12-租户管理员功能重构梳理/03-结算与支付链路.md`
+- `docs/12-租户管理员功能重构梳理/04-履约订单与售后链路.md`
+- `docs/12-租户管理员功能重构梳理/05-我的资产消息复购链路.md`
+- `docs/12-租户管理员功能重构梳理/06-活动导购与增长链路.md`
+
+### 旧版小程序参考
+
+- `docs/09-租户后台与C端功能映射总表.md`
+
+---
+
+## 3. 后台真实功能清单
+
+| 后台能力 | 真实内容 | 对顾客是否直接可感知 | 小程序承接方式 | 结论 |
+| --- | --- | --- | --- | --- |
+| 客户列表 | 客户标签、下单次数、注册周期、活跃/流失/高价值筛选、客单价、复购率、最近下单 | 否 | 推荐、分层、运营策略输入 | 间接支撑 |
+| 客户画像 / 客户详情 | 偏好品类、偏好配送方式、偏好支付方式、常购商品、订单趋势、会员摘要 | 否 | 个性化推荐、权益提示、复购推荐输入 | 间接支撑 |
+| 客户分析 | 新老客构成、客单价分布、RFM 分层、Top 客户、增长趋势、分群明细 | 否 | 活动定向、推荐排序、会员运营输入 | 间接支撑 |
+| 财务概览 | 今日营收、净收入、退款金额、可提现余额、收入构成、成本构成、利润趋势、Top 商品 | 否 | 仅后台经营驾驶舱 | 不前置 |
+| 交易流水 | 收入、退款、储值充值、积分抵扣、支付方式、到账金额、备注、交易详情 | 只有极少数字段可感知 | 订单金额说明、充值记录、退款记录、积分变动说明 | 间接支撑 |
+| 发票管理 | 发票设置、申请、开票、作废、记录详情、自动开票阈值 | 部分可感知 | 未来可从订单详情延伸出发票申请 | 未来扩展 |
+| 到账查询 | 到账统计、到账日期、渠道、商户号掩码、结算周期、到账明细 | 否 | 无前台页 | 不前置 |
+| 经营报表 | 营收、成本、利润率、退款率、日报周报月报、PDF/Excel/ZIP 导出 | 否 | 无前台页 | 不前置 |
+| 成本管理 | 成本录入、成本分类、成本率、趋势、月度明细 | 否 | 无前台页 | 不前置 |
+| 工作台 / 分析页 | 通用导航、示例项目、访问量、下载量、来源图表等 | 否，且业务证据弱 | 不应作为小程序设计依据 | 不前置 |
+
+---
+
+## 4. 后台能力到 C 端的映射结论
+
+## 4.1 不是后台每个菜单都需要一个顾客页面
+
+这是本批最重要的冻结结论。
+
+前面几批已经把顾客主链路基本收齐了：
+
+- 店铺前置
+- 菜单浏览与加购
+- 结算与支付
+- 履约与售后
+- 我的与资产
+- 活动导购与增长
+
+这一批看到的 `customer / finance / dashboard`，大多数都属于：
+
+- 运营分析层
+- 财务结算层
+- 后台驾驶舱层
+
+它们当然重要，但重要不等于应该前置成顾客页面。
+
+正确做法是：
+
+- 先确认它到底是顾客任务，还是商家任务
+- 如果只是运营和经营支撑，就留在后台
+- 只有当顾客真的需要发起动作、查看结果、完成闭环时，才考虑前台承接
+
+## 4.2 客户列表、画像、分析是商家 CRM 语言，不是顾客任务语言
+
+`customer` 域里已经能确认很多能力：
+
+- 客户标签
+- 活跃 / 沉睡 / 流失 / 高价值分层
+- 客单价与复购率
+- 偏好品类
+- 偏好配送方式
+- 偏好支付方式
+- 常购商品
+- RFM 分层
+- Top 客户
+
+这些能力对小程序当然有价值，但价值主要体现在幕后：
+
+- 首页推荐排序
+- 点餐页推荐商品
+- 券和活动的定向投放
+- 会员运营策略
+
+不合理的做法是把这些后台概念直接翻译成顾客可见页面，比如：
+
+- “我的客户画像”
+- “我的 RFM 分层”
+- “高价值顾客标签展示”
+
+这类表达对顾客没有自然任务价值，反而会把后台运营语言泄露到前台。
+
+## 4.3 RFM、Top 客户、客群明细不应直接成为前台可见概念
+
+后台客户分析里已经出现：
+
+- 新老客构成
+- 客单价分布
+- RFM 矩阵
+- Top 客户排行
+- 各种分群明细
+
+这说明系统已经具备精细化运营输入源，但它支持的是：
+
+- 谁该看到什么活动
+- 谁更适合被推荐什么商品
+- 谁应该收到什么权益提醒
+
+而不是让顾客自己看一页分析报表。
+
+因此这一批需要明确：
+
+- 客群标签不做前台字段
+- RFM 不做顾客可见解释
+- Top 客户不做排行榜页面
+- 客户分析只作为个性化和自动运营的支撑层
+
+## 4.4 财务概览、到账、成本、报表是典型后台经营面板，不应顾客化
+
+`finance/overview`、`settlement`、`cost`、`report` 已经很清楚地表明：
+
+- 财务概览看的是营收、净收入、退款金额、可提现余额、利润趋势
+- 到账查询看的是到账渠道、到账日期、商户账户、结算周期
+- 成本管理看的是食材、人工、包装、固定成本及成本率
+- 经营报表看的是利润率、退款率、日报周报月报及导出
+
+这些能力对应的是：
+
+- 商家算账
+- 商家对账
+- 商家经营分析
+
+不是顾客任务。
+
+所以小程序里不应该出现：
+
+- 顾客版财务驾驶舱
+- 顾客版到账中心
+- 顾客版经营报表
+- 顾客版成本分析
+
+这类设计会把商家视角和顾客视角完全混淆。
+
+## 4.5 交易流水只允许抽取“顾客真实会关心的那一小部分”
+
+`finance/transaction` 是这一批里最容易被误用的一块。
+
+因为它确实包含了顾客能感知到的一些东西：
+
+- 退款
+- 储值充值
+- 积分抵扣
+- 支付方式
+- 订单号
+- 金额变化
+
+但它本质上仍然是后台财务流水。
+
+因此更合理的做法不是做一页“顾客交易流水中心”，而是把少量必要结果拆回原来的链路里：
+
+- 订单金额、支付方式、退款信息，回到订单详情
+- 储值充值记录，回到储值页
+- 积分变动说明，回到积分相关页
+
+也就是说：
+
+- 可以借它做解释
+- 不能把整张后台流水表原样前置
+
+## 4.6 发票管理是少数可以保留前台扩展入口的财务能力
+
+`finance/invoice` 和其他财务模块不一样。
+
+这里已经能确认：
+
+- 发票申请
+- 发票记录
+- 发票详情
+- 发票开具
+- 发票作废
+- 发票设置
+- 自动开票阈值
+
+这说明系统里确实存在一条“顾客申请发票”的业务事实，而不只是后台内部表格。
+
+但当前仍然不能直接把后台发票管理页搬成顾客财务中心，原因是：
+
+- 后台页面包含发票设置、开票、作废等商家动作
+- 这些动作不是顾客主链路
+- 目前主文档也还没有完整冻结前台发票交互
+
+因此更合理的结论是：
+
+- 电子发票入口可以作为未来扩展保留
+- 最自然的入口位置是订单详情页
+- 当前不单独拉出一套正式前台发票中心
+
+## 4.7 `dashboard` 当前不能作为小程序页面设计的事实源
+
+`dashboard/workspace` 和 `dashboard/analytics` 当前看到的内容更接近：
+
+- 脚手架示例数据
+- 通用工作台
+- 通用访问量图表
+
+而不是外卖业务里的稳定事实模型。
+
+这意味着：
+
+- 它可以作为后台壳层参考
+- 不能反推 C 端页面设计
+- 不能拿“访问量、下载量、来源图表”去推导小程序顾客页结构
+
+这一点需要明确写住，避免后续继续把示例页当业务源。
+
+---
+
+## 5. 小程序页面与能力重映射
+
+## 5.1 `T01 首页` 与 `T02 点餐页`
+
+这两页可以继续被 `customer` 域间接增强，但增强方式只能是：
+
+- 更合理的推荐排序
+- 更贴近用户偏好的商品分组
+- 更合适的活动曝光
+- 更贴近会员状态的权益提示
+
+不能新增成：
+
+- 客户画像页入口
+- 顾客标签展示区
+- 客群等级说明区
+
+## 5.2 `T04 我的页`、资产页、订单详情页
+
+这几页可以继续从 `finance/transaction` 抽取顾客可理解的结果，但要坚持“结果页”思路：
+
+- 我的页只做摘要入口，不做财务总账
+- 储值页看充值计划、余额和充值记录，不看后台流水维度
+- 积分页看积分来源和使用结果，不看财务记账视角
+- 订单详情页看支付结果、退款结果、可能的发票入口
+
+不能演变成：
+
+- 顾客交易流水驾驶舱
+- 顾客财务对账中心
+
+## 5.3 `P05 订单详情页` 的未来扩展位
+
+如果后续要承接 `finance/invoice`，最合理的是在订单详情页里增加：
+
+- 申请发票入口
+- 发票申请结果
+- 发票状态查看
+
+但当前不先冻结：
+
+- 完整发票中心首页
+- 发票设置页
+- 开票 / 作废等商家动作页
+
+## 5.4 当前明确不新增的正式前台页面
+
+这一批明确不建议新增以下顾客页：
+
+- 客户列表页
+- 客户画像页
+- 客户分析页
+- 财务概览页
+- 交易流水总账页
+- 到账查询页
+- 经营报表页
+- 成本分析页
+- 顾客版仪表盘页
+
+---
+
+## 6. 当前发现的不合理设计点
+
+### 6.1 把后台功能表机械地一一映射成前台页面，不合理
+
+原因：
+
+- 后台回答的是“商家怎么管”
+- 前台回答的是“顾客怎么用”
+
+调整：
+
+- 以后不再按后台菜单数量推导前台页面数量
+
+### 6.2 把 CRM 标签、RFM 分层、Top 客户直接前置给顾客，不合理
+
+原因：
+
+- 这属于后台分析语言，不是顾客任务语言
+
+调整：
+
+- 只把它们转译成推荐、权益、活动曝光，不直接展示原始概念
+
+### 6.3 把财务驾驶舱、到账、报表、成本直接做成顾客可见页，不合理
+
+原因：
+
+- 这些页面服务的是商家经营和财务核对
+
+调整：
+
+- 只保留顾客真实会发起或会关心的结果查看能力
+
+### 6.4 把交易流水误当成顾客可用的完整资产中心，不合理
+
+原因：
+
+- 后台流水是记账视角，不是顾客任务视角
+
+调整：
+
+- 只抽取订单、充值、退款、积分这类与顾客行为直接对应的结果
+
+### 6.5 把 `dashboard` 示例页当成业务事实源，不合理
+
+原因：
+
+- 当前内容明显包含示例项目、通用访问图表和脚手架数据
+
+调整：
+
+- 后续做小程序梳理时，不再把 `dashboard` 当成强事实源使用
+
+### 6.6 发票能力如果直接照搬后台，会把商家动作误塞给顾客
+
+原因：
+
+- 后台发票页同时包含设置、开票、作废等管理动作
+
+调整：
+
+- 只保留未来可落在订单详情里的申请与结果查看方向
+
+---
+
+## 7. 本批次冻结后的映射结论
+
+## 7.1 本批不新增正式前台页面
+
+和前六批不同，这一批的主要结论不是“新增承接页”，而是明确：
+
+- 当前主链路已经足够
+- `customer / finance / dashboard` 主要作为后台支撑层存在
+
+## 7.2 间接支撑
+
+- 客户列表、客户画像、客户分析
+- 交易流水中的退款、充值、积分、支付方式等事实子集
+- 营销和推荐排序所需的客群分层能力
+
+## 7.3 未来扩展
+
+- 订单详情页中的电子发票申请入口
+- 发票申请状态与结果查看
+- 基于客户分析的更精细推荐与专属活动排序
+
+## 7.4 明确不前置
+
+- 客户管理后台概念页
+- 财务概览驾驶舱
+- 到账查询与结算账户页
+- 成本录入与成本分析页
+- 经营报表导出页
+- 顾客版 Dashboard
+
+## 7.5 本批次新增约束
+
+- 后台运营分析能力默认先归入“间接支撑”，不要先做顾客页
+- 后台财务结算能力默认先归入“不前置”，不要用报表思维设计顾客端
+- 只有顾客真的会发起的动作，才允许从后台能力中抽取前台入口
+- `dashboard` 当前不作为小程序设计事实源
+- 发票能力保留扩展位，但不进入当前主链路冻结范围
+
+---
+
+## 8. 本轮梳理收口
+
+到这里，`docs/12-租户管理员功能重构梳理/` 这一轮按顾客链路拆批次的重构梳理已经完成。
+
+这一轮最终收口后的原则是：
+
+- 顾客页只承接顾客任务
+- 后台页只作为事实源，不天然等于前台页
+- 规则、分析、结算、报表优先放在后台支撑层
+- 未来扩展只保留有明确顾客动作闭环的能力
+
+如果后面继续往下做，下一阶段就不应该再回到“大而泛的页面猜想”，而应该进入：
+
+- 单页规格回写
+- 字段级状态收敛
+- 接口契约补齐
+
diff --git a/Cend-MiniProgram-Prototype/docs/before-home.png b/Cend-MiniProgram-Prototype/docs/before-home.png
deleted file mode 100644
index ddaac2d..0000000
Binary files a/Cend-MiniProgram-Prototype/docs/before-home.png and /dev/null differ
diff --git a/Cend-MiniProgram-Prototype/index.html b/Cend-MiniProgram-Prototype/index.html
deleted file mode 100644
index cd9cfcf..0000000
--- a/Cend-MiniProgram-Prototype/index.html
+++ /dev/null
@@ -1,1511 +0,0 @@
-
-
-
-
-
- TakeoutSaaS C端小程序原型
-
-
-
-
-
-
-
-