# 小程序机制与后台业务支撑：架构覆盖审查

> 历史证据：保留下文编写当时的范围、发现和检查计数，不作为现行政策或未决台账。当前业务机制见[确认政策](../../architecture/05-domain/CONFIRMATION-POLICY.md)，剩余事项见[DECISIONS](../../architecture/DECISIONS.md)，来源分工见[事实源索引](../../architecture/SOURCE-AUTHORITY.md)。后续确认已部分收敛拆单、取消、计价与时间规则，不回写旧结果伪造当时已验证。

日期：2026-09-28。审查基线：`1f38177c72f52d0a5464470c3bd3b9a2c54322ed`。

性质：用户委托的设计覆盖审查，不是S5独立评审、S7清洁轮或发布验收。只新增本报告，不修改架构、原型、业务政策或Runtime。主会话维护发现；业务政策由用户确认，各领域实际实施/运营责任人尚待指定，不能以BC名称替代人员责任。

## 1. 结论

现有架构的**事实分工基本合理，最新核心服务的完整协作尚未收敛**。不建议推翻十个上下文，也不建议先扩大后台菜单。优先把“一周提前安排—付款—逐日主动确认—未确认不送—资金留存—实际交付/售后”贯穿Customer、Commerce、Demand、Supply、Fulfillment和Finance。

后台结论必须区分两份材料：

- 已纳入版本的 `admin-console/site/` 是十个上下文的代表性只读展示，支持理解职责，不足以证明运营人员能完成业务闭环。
- 本地未跟踪的 `admin-console/workbench/` 有70个页面配置、十个业务模块加Platform支撑分组，已有改期、留存跟进、费用提案、提醒、交接等操作设计。它构成“并非完全没有设计”的反证，但尚未成为本次提交基线；本地模拟动作也没有把小程序与后台接到同一条业务链。
- 因此不是“后台什么都没有”，而是**已有模块和操作素材，缺少对同一位客户、同一份已付安排、同一次配送的联合支撑与验收**。

### 判定尺度

- **语义待收敛**：已明确的新机制尚未进入原有模型，或模式边界未说明。
- **部分覆盖**：已有Owner、对象或原则，但缺动作级协议与终点。
- **候选已有**：本地/历史设计已有素材，不计为活动基线完成。
- **业务待决**：价格、期限、退出等需业务选择；不当作已批准功能直接实现。
- **未验证**：没有相应运行证据，不据此断言生产系统已经有Bug。

P1表示必须在相应交易/履约实现基线确定前解决；P2表示需要展开设计或明确首发取舍，不表示可以在实际提供该服务时省略。此次没有发现可认定的生产P0事故。

## 2. 输入与证据边界

### 活动文档

1. [架构入口](../../architecture/README.md)、[DOMAIN](../../architecture/05-domain/DOMAIN.md)、[一周无忧机制](../../architecture/05-domain/WEEKLY-CARE-PLAN.md)。
2. `06-subdomain/sd-01`至`sd-10`全部正文：十份仍为placeholder，不是完整业务需求层。
3. `07-bounded-context/bc-01`至`bc-10`全部正文，以及[事实归属](../../architecture/07-bounded-context/OWNERSHIP.md)、[上下文协作](../../architecture/07-bounded-context/CONTEXT-MAP.md)、[拆合取舍](../../architecture/07-bounded-context/BOUNDARY-DECISIONS.md)。
4. `08-domain-model/model-01`至`model-10`全部正文及[一致性设计](../../architecture/08-domain-model/CONSISTENCY.md)。已有审查记录另作历史问题索引，不将其结论当本次验证。
5. 小程序[stories](../../design/prototypes/customer-miniapp/stories.md)、[flows](../../design/prototypes/customer-miniapp/flows.md)、[周计划体验](../../design/prototypes/customer-miniapp/weekly-plan-experience.md)、[付款后服务台账](../../design/prototypes/customer-miniapp/post-payment-care.md)、[确认与费用](../../design/prototypes/customer-miniapp/confirmation-window.md)。
6. 后台[模块设计](../../design/prototypes/admin-console/MODULE-DESIGN.md)与活动站点 `modules-data.mjs`、`modules.mjs`；[品牌设计立场](../../design/brand/design-philosophy.md)中的服务承诺边界。

### 原型与补充反证

核查了当前构建的页面覆盖方式、周计划/菜卡/确认模型、“我的”入口和普通订单配送服务；复跑两个模型验证脚本，执行内存级边界探针。它们只证明概念模型的行为，不证明真实支付、后端权限、服务可用性或联合业务闭环。

本地workbench核对了70页配置的模块/动作清单，重点读取confirmations、tariffs、retained、plans、notifications，以及通用执行模型；没有逐页执行70页浏览器验收。补充阅读旧[后台岗位动线](../../../docs_bak/product/workbench/backoffice-personas-and-daily-journeys.md)与[旧差距审查](../../../docs_bak/report/backoffice-persona-journey-review.md)，用于避免重复提出已有思考，不恢复旧政策。没有解压或改动新压缩包。

收尾发现其他工作正在持续更新后台候选。追加完整阅读[CROSS-FLOWS](../../design/prototypes/admin-console/CROSS-FLOWS.md)的CF-01～10及未决政策，核对新stories/flows的目录、覆盖边界和新REQ的draft声明；未逐条审完七千余行的新flows或执行新增web/e2e。CF-01/02/03/06等已补跨模块操作叙事与精确对象链接，故本报告不将后台跨模块故事判为完全缺失；仍缺的是新机制进入权威模型/契约以及两端同一数据链的证据。新增文档和代码均不纳入本报告的已提交基线，不覆盖其他工作的验收结论。

本地候选来源SHA-256（2026-09-28 09:38:16 UTC内存复测所读取内容；审查期间已有变更，后续版本需重新核对，不签署持续变化的目录整体）：

| 文件 | SHA-256 |
| --- | --- |
| `workbench/catalog.json` | `ab96c55b387849bb859b12eca33dc5c0409b0a88c8d5fc76bfb8fbd0ec279b76` |
| `workbench/model.js` | `159c4cc76d61b92d2bdcde760b10a3844029a03d141c23209cf941861aefe9e3` |
| `workbench/app.js` | `0f0356e91e88d58dd8f45b31f432756c5c7feae8b8ce1017afa246364453b61e` |

不声称完整检查全部docs_bak、所有原型控件、真实基础设施或第三方可行性；微信授权/消息渠道等需后续专项查证。

## 3. 从用户动线核对完整能力

| 用户要完成的事情 | 已有设计基础 | 尚未闭合的关键问题 | 后台需要承接的工作 | 发现 |
| --- | --- | --- | --- | --- |
| 看到明日鲜讯，放心预约 | Catalog发布、Supply接收与质量 | 预计到货、开放预约、实际到货、延误撤回的关联 | 按日发布与核对鲜讯；到货异常联动处置 | G05/G09 |
| 不按推荐菜，直接买肉 | Cart、Quote、Order、普通结算原型 | 与周计划共用哪些确认/资金规则，例外是什么 | 同一客户的普通订单与计划购买可关联查询 | G01/G06/G11 |
| 选克重、切法、份数 | SKU/规格版本，原型规格校验 | 合法组合、加工能力、标称与实称、计价差额 | 维护规格并形成不歧义的切配指令 | G10 |
| 记一道拿手菜，复用到多餐 | PersonalRecipe/WeeklyMealPlan、菜卡快照 | 多SKU与自由文字备忘的正式结构和变更规则 | 支撑商品下架/规格变化，不擅改用户私有菜卡 | G10/G12 |
| 一次核对并付一周 | 周计划本地支付快照、Commerce资金模型 | 一次收款怎样归属到日/餐/行，失败/未知怎样恢复 | 查周付款、分项归属及后续变更 | G02/G03/G06 |
| 每天选时间，明确确认 | WCP-03/04、确认费用体验 | 谁接受本次授权，怎样形成唯一可执行配送 | 待确认/已接受/可执行队列，保留客户授权证据 | G02/G04 |
| 没打开小程序，也无需取消 | WCP-04、演示跳过留存 | 服务端自主判定、到期并发、晚确认恢复 | 自动停送与留存待核，失败有人接手 | G02/G03/G13 |
| 临时决定今天送 | 两小时原则、预填费用 | 跨档报价、费用核验与服务接受的顺序和补偿 | 费用版本、原收款核验、承接/改时处理 | G04 |
| 已付后换菜/改量/改地址/撤回 | 变更协调、不可变快照原则 | 部分变更、差价、再次授权、不可停止边界 | 客服影响预览、变更处理及分项回执 | G07 |
| 不送的钱找得到、退得明白 | 暂留方向、Refund额度守卫 | 留存依据、再次使用/退出/结转及分摊待决 | 资金归属台账、退出诉求与执行跟踪 | G03 |
| 确认后按约收货 | Task/Package/Proof、质量门禁 | 日确认到作业、临时加单、延误/失联与补救 | 调度、现场证据、异常分派、交付核验 | G02/G05/G13 |
| 看这份肉的资料，或发起售后 | PublicTracePublication、AfterSaleCase | 预计来源与实际包裹批次区别，周计划购买关联 | 证据发布、受影响对象、退款/补发分别收尾 | G09/G11 |
| 从提醒、“我的”或另一设备回来 | Consent、Account、组合查询原则 | 直达目标、跨设备最新状态、提醒失效 | 按授权提醒、来源核验、服务案件连续跟进 | G08/G11/G12 |
| 使用收藏、权益、下周建议等 | “我的”入口、优惠/偏好候选对象 | 是否首发、积分规则、推荐决策Owner尚未收敛 | 经营配置、解释与客户支持范围 | G15 |

## 4. 发现清单及建议

### G01 · P1 · 业务语义与故事基线落后于当前作品

**证据：** WCP已明确主动逐日确认；但BC-05、DM-05仍主要推导Hold、容量承诺和SubscriptionCycle出单。stories S-004、flows F-004及场景文件仍描述自动配送、20:00停送和自动退款；文件头虽有历史提示，正文仍称“当前真相”。[构建脚本](../../design/prototypes/customer-miniapp/runtime/build-origin.mjs)覆盖Plan/Mine，但普通Checkout/Orders仍来自基础源；[配送服务](../../design/prototypes/customer-miniapp/source/dingwei-meat-market/src/services/delivery.ts)仍有旧规则。

**影响：** 下一轮可能按旧场景实现一个“测试通过但违背新机制”的产品；订阅建议、付费持续合同和一周计划也容易混同。

**建议：** 先明确单次选购与周计划的模式边界，再更新同一份活动故事/动线/场景，保留旧快照来源。普通订单例外尚待决定，不能擅自将其全部改成周计划，也不能把旧例外当批准政策。Owner建议：主设计会话组织，Customer/Demand/Commerce共同校核。

### G02 · P1 · 缺“逐次配送授权—服务接受—放行作业”的专用协议

**证据：** [BC-07](../../architecture/07-bounded-context/bc-07-fulfillment.md)已写“已支付不足以开工”，这是正确基础；但[协作表§3](../../architecture/07-bounded-context/CONTEXT-MAP.md)仍以订单确认驱动履约，没有展开周付款后独立的每日确认、无操作停送、重新恢复及各自幂等身份。原型`confirmArrival`当天确认直接记为`delivering`，只是体验简化，不是出发证明。

**需要补齐：** 每次配送目标及覆盖范围、客户明确同意的内容/版本/时刻、商家接受结果、费用依据、履约放行依据；确认、停送调度和恢复并发时唯一有效结果。确认状态不能替代备货、出发、签收。

**后台：** 应可区分“待客户确认”“已接受待安排”“因异常待处理”，不能让运营随手勾选即代替顾客同意。候选workbench已有确认/恢复入口，但还没有权威证据消费及联动协议。Owner建议：Demand维护安排与授权接受，Commerce协调适用资金依据，Fulfillment验证执行门禁；最终协调者需正式定案。

### G03 · P1 · 周付款、日分摊与留存资金没有正式归属模型

**证据：** [DM-06](../../architecture/08-domain-model/model-06-commerce.md)有Payment、RefundBudget等，但未展开周收款与每日金额、已用/待履约/留存的关联。[WCP§6](../../architecture/05-domain/WEEKLY-CARE-PLAN.md)明确将扣减时点、退出等列为未决。原型`totals()`按日状态汇总食材金额，配送费另存；这是演示口径，不是交易账本。workbench的retained页已支持跟进，但仍以证据文本改变单条记录。

**需要补齐：** 原付款—分摊对象—后续使用/解除—退款目标的可追溯关系；食材、优惠、配送费及差额分别核对；留存与退款并发不能重复使用同一金额；UNKNOWN继续核验原目标。建议放在Commerce现有资金责任内，Finance消费已核实经济来源，不据“预存”另建可充值钱包。

**业务待决：** 何时计为使用、如何重用/退出/跨周及有效期。后台需显示依据与处理进度，不只一个总余额。金额策略决策人为用户，实际资金与财务负责人待指定。

### G04 · P1 · 两小时配送费只有原则与演示，没有费用—承诺联合流程

**证据：** [CW-03/06/07/08](../../design/prototypes/customer-miniapp/confirmation-window.md)已识别临近收费、未知、跨档和商家延误；候选tariffs页也已有草案。尚未确定有效确认时刻、报价期限、计费单位、收费与接受顺序。小程序和后台演示分别用两个本地函数计算，后台候选函数仅按时分计算，不能证明跨日计时一致。

**建议：** Demand提供真实可接受安排及时间语义，Commerce负责版本化费用报价和资金事实；页面位置不决定费用Owner。补“报价—用户同意—费用核验—服务接受—部分失败补偿”的协议。2小时是免费边界，不是关单线；¥3/6/9仍是预填值。未同意新报价不得静默加收，收费成功而服务未接受必须可恢复。

### G05 · P1 · “按需备货”缺从计划信号到经营决策的链路

**证据：** [上下文图](../../architecture/07-bounded-context/CONTEXT-MAP.md)明确Supply/Fulfillment向Demand提供能力，但没有展开Demand/Customer的未来需求如何反馈到备货安排。[Supply模型](../../architecture/08-domain-model/model-04-supply.md)主要从接收、质量、分配开始。[首页](../../design/prototypes/customer-miniapp/runtime/origin-home.tsx)已经承诺按需备货、不留隔夜。

**缺口：** 只有草稿的需求、已付未确认的需求、已确认的需求不能等量相加；也不能等全部确认后才考虑到货。需按日期、部位、规格/切法汇总并保留来源与置信边界，形成运营可接受/调整的备货建议，再核对实际到货、缺口、损耗/剩余。已付或预测不能直接变成物料扣减。

**取舍：** 不要求新增完整采购/WMS，不默认算法预测；可以先做可解释的需求汇总与人工确认安排。Demand负责需求承接语义，Supply负责供给准备与实际事实，Fulfillment负责加工/配送能力；派生汇总不能越权改这些事实。

**必须测试：** 大量未确认、临近新增、到货不足、质量隔离和能力降低。承诺“不抢配送资格”不能被实现成抢最后一个名额，但也不等于隐瞒真实不可承接；应有备选安排与人工服务路径。

### G06 · P1 · 餐、购买、配送、包裹之间的基数和身份未定

**证据：** [周计划体验§3](../../design/prototypes/customer-miniapp/weekly-plan-experience.md)明确“一餐不等于一次配送”；DM-06将分组列为待定。周模型目前按`week-day`一日一组，workbench也未提供同一数据集的完整映射。

**需要补齐：** 菜卡实例/餐次→商品购买明细→收款分摊→本次配送安排→履约行→包裹/实际批次；一天多餐、多SKU、多包裹及部分取消的关联。普通购买与计划购买是否合送、不同地址是否拆分、配送费算几次须明确，不从UI直接推出一天一单。

**建议：** 先定业务基数与自然幂等身份，再定表/API；不强制一周一张商业订单或一天一张订单。原计划修改不能破坏已接受明细。Owner建议：Customer/Commerce/Demand/Fulfillment联合设计。

### G07 · P1 · 已付安排变化已有通用协调原则，缺周计划专属差量处理

**证据：** [协作表§5.3](../../architecture/07-bounded-context/CONTEXT-MAP.md)、DM-06§7已设计改址/改期协调，不是空白。[PC-04/06](../../design/prototypes/customer-miniapp/post-payment-care.md)仍缺换菜、改量、替代与补退差价；菜卡模型直接拒绝向已付日期重复安排，保护快照但不完成变更。

**建议：** 明确受影响行/餐/配送，预览差额与新旧条件，取得客户确认后协调，不重付整周。缺货替代须保留客户选择与新规格；已开始切配、已交接、部分配送需要不同处置。变更失败保留既有义务或明确升级，不静默释放旧承诺。后台应有同一变更请求的步骤回执与责任人。费用及撤回政策待业务决定。

### G08 · P2 · 提醒机制有技术归属，尚缺一周计划的服务策略

**证据：** OWNERSHIP§3已有平台通知、Customer已有ConsentHistory；[PC-02](../../design/prototypes/customer-miniapp/post-payment-care.md)仍未定站外渠道、授权、频率、退订。workbench有通知页，不能等同渠道接入完成。

**需要补齐：** 谁在什么条件下生成提醒意图、按什么授权发送、何时去重/停止、用户已确认后怎样撤销旧提醒；登录后直达原配送目标、旧链接显示最新事实、退订后继续可正常确认。业务策略归业务Owner，投递归Platform，个人同意归Customer。

提醒失败或用户未读均不能变成默认同意；自动停送不能依赖用户打开应用。渠道真实可行性待专项验证，不在本次捏造微信权限能力。

### G09 · P2 · 品牌新鲜承诺与公开追溯尚未接到实际证据链

**证据：** Catalog已有发布和首页编排，Supply已有接收/质量/公开追溯，Fulfillment已有包裹。不能说缺少这些模块；缺的是首页“明早7:30到店”及“不留隔夜”的服务范围、生效日、时区、依据、失效和异常更正链。

**建议：** 区分预计到货与实际接收，鲜讯跨日自动失效/重新发布，延误明确承接；对未到货商品展示什么来源依据、何时绑定实际批次，不能预先把推荐/样例批次当作本单实物。售后和肉品档案应回到包裹实际绑定。日末剩余的处置证据需能支撑品牌表述，但具体政策待运营明确，不在此擅定食品安全标准。

### G10 · P2 · SKU与菜卡的体验已成熟，领域细节尚未同等成熟

**证据：** DM-02/03已有PersonalRecipe、WeeklyMealPlan、SKUVersion；[菜卡模型](../../design/prototypes/customer-miniapp/runtime/study-cards-model.mjs)已保护模板/餐次快照，调味备忘不转采购。现有模型没有把多商品明细、自由文字用量、规格失效、合并采购与切配要求展开成正式契约。

**需要补齐：** 商品关联项与备忘项分别建模；版本引用和已付快照边界；单品份数与菜谱人数区别；克重×切法的合法组合；是否足重定价/实称结算及容差规则。后台维护可销售/可加工组合和菜谱映射，现场拿到确定指令。不要因为称重能力存在，就默认顾客必须接受事后补差价。

### G11 · P1 · 用户与客服尚无统一的购买—履约—售后事实视图

**证据：** [StudyMineDesk](../../design/prototypes/customer-miniapp/runtime/study-mine.tsx)分别读取周计划localStorage与旧订单，并明确披露两套记录未合并。周计划支付不写普通订单；售后入口仍查旧订单。后台活动站点关联按钮只跳模块，未承诺精确对象关联。workbench增加了ID关联，但本地操作只改各自记录。

**需要补齐：** 周计划购买必须能定位相应购买明细、付款、配送和售后对象；用户不用猜从哪个入口查钱，客服也不能让用户重新描述整周。建立受权组合查询，保留来源状态与新鲜度，而非造一个万能总状态或第二个订单库。付款成功、服务接受、出发、签收、退款均各有依据。

### G12 · P2 · 授权/隐私原则充分，具体服务动作与顾客身份流程未落地

**证据：** Identity、Customer和CONTEXT-MAP§2已覆盖主体、范围、撤权、字段最小化，不能判为无安全设计。候选workbench只是operator/reviewer/readonly的演示，证据和门禁多为输入字段，不是后端凭证。

**需落地：** 顾客登录/外部身份绑定、跨设备计划归属与恢复；客服能看哪些私人菜卡/偏好、能否代录明确确认、按什么依据；资金复核、质量复核、导出与地址访问的动作级权限和职责分离。测试跨客户ID、跨区域、旧提醒、撤权后在途任务、同一人切换角色绕过复核。账户恢复/隐私保留政策待定。

### G13 · P2 · 后台应按工作结果组织，跨岗位恢复还缺落地合同

**证据：** CONTEXT-MAP§5.2/5.5已有正常待办、接收交接、恢复义务；历史岗位动线J01–J10及workbench的handoffs/exceptions/jobs也已有设计。活动只读后台不能跑完，候选通用执行器也主要推进当前行，不能据“全部回执齐全”的下拉值证明源领域完成。

**需要补齐：** 每类待办的业务产生/解除条件、责任人/期限、跨页同一对象上下文；确认后未生成作业、已停送仍有任务、资金已付但服务未接受等异常的检测、恢复命令、重放权限及终点核对。后台负责调度/复核，现场负责采证，后台不得伪造出发或签收。

### G14 · P1 · 活动规范链尚不能直接派生可实施、可验证的系统

**证据：** 十个SD正文仍占位；活动`architecture/data-model`、`state`、`dataflow`及`dev/contracts`只见模板/规则，没有本次业务链的正式模型、迁移表与跨端契约。架构已列幂等、Outbox、并发原则，但缺动作级错误、权限、消息顺序、服务时限和恢复依据。

**需补：** 业务状态表与技术回执分层；明确时间/金额/单位/版本；同一经济目标和配送目标唯一性；本地事务及跨域补偿；投影延迟/回源；未确认关闭与确认并发；支付/退款UNKNOWN；定时任务宕机补扫；容量/质量失效传播；审计与告警责任。为这些场景定可测指标，而不是本报告虚构SLA数值。

迁移时保留历史模式/政策版本，不把旧自动配送或自动退款映射为用户新授权；已发生资金/物理事实用核验和补偿，不靠回滚删除。本次演示localStorage不迁成生产资金账。正式实现策略、历史数据范围和恢复演练仍未完成。

### G15 · P2 · 非核心入口与长期架构范围尚需一次明确取舍

**证据：** 当前“我的”有收藏、权益积分、家庭偏好、订阅建议；Commerce有CouponGrant等，Customer有偏好，架构已有推荐实验/增长Owner未决项。后台候选覆盖了部分价格/关系，不能证明积分获取/使用/退回或推荐解释都已设计。

**建议：** 明确首发保留、简化或后置，不靠入口存在自动扩大范围，也不擅自删除。把“订阅建议”与付费持续合同分开。外部渠道、团长佣金、复杂推荐实验和完整会计范围按实际需要决定，不为了十个模块齐全先做满；一旦保留入口承诺，就补对应故事、Owner、规则和后台支撑。

## 5. 后台覆盖判断：不按页面数量计完成度

| 业务责任 | 活动后台 | 本地workbench候选反证 | 仍需证明的联动终点 |
| --- | --- | --- | --- |
| 商品/价格/发布 | 只读规格与内容样本 | products/pricing/content/publications/recipes | 同一版本实际在小程序可见且可成交，失效可解释 |
| 计划/确认/费用 | 已付与未确认样本 | confirmations/reservations/tariffs/retained/plans | 每次确认关联正确范围、资金依据与履约放行 |
| 需求/供给准备 | 供给/能力概念 | receiving/supply-capacity/capacity | 计划需求→备货决定→实际到货→缺口处置 |
| 质量/追溯 | 待放行/绑定样本 | quality/allocations/trace/recalls | 隔离确实阻断受影响执行，实际包裹可追溯 |
| 切配/交付 | 作业、交接样本 | tasks/measurements/packages/deliveries | 规格、测量、包裹、顾客确认及签收证据相互对应 |
| 客服/售后/资金 | 只读事项与资金未知 | changes/aftersales/refunds/payments/service-cases | 周计划与普通购买均可定位、部分处理和跨端回显 |
| 财务 | 来源待核与未过账 | sources/journals/periods/reconciliation | 原收款、分摊、留存、费用和退款可核对，不重复记经济效果 |
| 权限/工作交接/通知 | 权限与延迟演示 | roles/privacy/handoffs/notifications/exceptions/jobs | 有权的人处理正确对象；离开/撤权后责任与恢复不中断 |
| 经营分析 | 作业率/签收缺数据样本 | reports/metrics/data-quality | 已付待确认、承诺未执行、留存待核、备货偏差可解释；不把未确认当违约 |

推荐工作组织为“今日承接与异常、明日备货准备、客户服务、日终核对”，现有模块保留为专业查找入口。上述是岗位组合视图建议，不新建业务Owner，也不要求把现场操作全搬进后台。

## 6. 优先补齐的设计顺序与备选

1. **先对齐机制和适用模式（G01）**：保留当前视觉，确定周计划与普通买肉的共同规则和明确例外，更新活动故事/动线。不是先做API。
2. **用一组贯穿样例确定关系（G02/G03/G06）**：同一用户，一周三天、其中一天两餐、一次周付款、一天跳过、一天临近确认、一项售后。讲清每份东西、每笔钱、每次授权和每次交付怎样对应。
3. **补经营与服务协议（G04/G05/G07/G08/G09）**：只把确实需业务决定的项交用户；其余先做明确备选、失败与恢复设计。精确费率可后定，报价/授权/补偿边界不能空着。
4. **后台按同一组样例闭环（G11/G12/G13）**：复用workbench已有操作素材，不再从零画70页；验收对象是工作结果而非点击数。
5. **回写现有架构层与契约（G10/G14/G15）**：补SD使用链、更新BC/模型与协作表，再落正式状态/数据/接口/事件和场景；不另外建第二份需求事实库。

保留十个候选BC、补内部流程，较整体重拆风险低；但若统一模型证明确有独立的长期合同/计费不变量，再重开Demand内部拆分。把所有钱与状态塞进WeeklyMealPlan虽直观，却会制造第二套交易中心，因此不推荐。仅给后台增加“确认/退款”按钮成本较小，但无法保护授权、资金与实体动作，因此不能作为闭环完成方案。

## 7. 后续联合验证清单（未执行）

| 场景 | 必须观察的结果 | 反证：出现即不通过 |
| --- | --- | --- |
| 一周三天一次付款 | 付款可核验，三天独立待确认 | 自动发三天配送、重复收整周金额 |
| 用户从未再打开应用 | 权威时间按政策停送，金额另记，后台责任可见 | 必须前端启动才停送；后台默认代确认 |
| 提前120/119分钟、跨日/跨档 | 同一权威报价与授权，免费边界一致 | 手机改时绕过费用、静默加价 |
| 配送费成功但确认超时 | 查询原目标，恢复接受或补偿 | 再收一次费或只留“已支付”无下文 |
| 确认与停送并发、两设备提交 | 唯一有效安排，可解释冲突 | 同日重复出单/出车/扣减 |
| 已付后换一道菜或改量 | 只处理影响项，客户看清差额 | 覆盖原快照、其他日被清空 |
| 多餐合送/多包裹/不同地址 | 明细、费用、交付范围准确关联 | 一次确认错误覆盖全部安排 |
| 到货延误或批次隔离 | 鲜讯、可承接、任务与受影响顾客同步处置 | 公告仍保证到店、已隔离继续分配 |
| 只含调味备忘的菜卡 | 可记忆/复用，不生成收费明细 | “少许”被强行商品化或收费 |
| 称重偏差/缺货替代 | 按明确政策和客户授权处理 | 现场改规格或补差价无依据 |
| 已确认后无法送达 | 责任人、恢复方案、资金与服务结果可查 | 直接标送达或只关闭任务 |
| 某餐售后与整周剩余款 | 目标可追溯，不超退、不影响无关日期 | 周计划无法进入售后、退款侵占其他安排 |
| 撤权/错客户/旧提醒 | 权限拒绝、最小信息、不丢既有恢复义务 | 旧链接操作别人订单；撤权遗弃退款 |
| 消息重复/乱序、宕机重启 | 不重扣、不重派；补扫与业务终点核验 | Job完成被当作业务完成 |
| 政策升级/旧数据迁移/回退 | 唯一写方、旧依据保留、在途流程可恢复 | 两套Owner同时写、把旧自动配送当新同意 |

每条均需同时观察小程序、后台、权威业务结果和必要现场/支付回执；只测任意一端不算跨端通过。未来角色、数据规模、性能/可用性指标及恢复期限仍须登记实际Owner，当前UNKNOWN不是N/A。

## 8. 本轮实际检查结果与限制

- `verify-week-model.mjs`：PASS，覆盖概念金额守恒、日隔离、主动确认、跳过留存及部分拒绝/损坏读取。
- `verify-cards-model.mjs`：PASS，覆盖模板/餐次/已付快照隔离、自由备忘、商品规格、重复/已付日拒绝。
- 内存探针：期望18:00，16:00确认费用0，16:01费用300分；当天确认模型直接成为`delivering`；食材2980分的totals不含另存配送费。前者支持两小时演示边界，后两项证明不能把模型直接当实际调度与全口径账本。
- 本地workbench内存探针：CONFIRMATIONS-003经restore→accepted变为“已确认”，关联orders、tasks、retained记录保持原样。09:38:16 UTC按表中候选内容再次复测，结果相同。说明已有操作设计但本地模拟本身不能证明跨模块闭环；这不是要求客户端直接改其他模块，而是需要服务端协调及事件/查询设计。CROSS-FLOWS已明确这些事实独立，应保留这个正确边界。
- 第一版workbench探针尝试从种子数据直接找accepted前态，没有对应记录而失败；随后按已有restore→accepted合法路径复测得到上述结果。该脚本准备错误不记为产品缺陷，也不隐去失败过程。
- 全部探针仅使用内存合成数据，没有写浏览器存储，没有调用支付/配送/业务写接口。本轮未重跑完整浏览器、生产API、安全、性能或财务验收。

结论是“需要补设计”，不是“已有生产系统验收失败”。本报告不批准业务政策、不自动迁移候选workbench、不提交或推送；后续修订本报告即可恢复/更正审查结论，认可的设计快照不受影响。