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

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

日期：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. 架构入口、DOMAIN、一周无忧机制。
2. 06-subdomain/sd-01至sd-10全部正文：十份仍为placeholder，不是完整业务需求层。
3. 07-bounded-context/bc-01至bc-10全部正文，以及事实归属、上下文协作、拆合取舍。
4. 08-domain-model/model-01至model-10全部正文及一致性设计。已有审查记录另作历史问题索引，不将其结论当本次验证。
5. 小程序stories、flows、周计划体验、付款后服务台账、确认与费用。
6. 后台模块设计与活动站点 modules-data.mjs、modules.mjs；品牌设计立场中的服务承诺边界。

原型与补充反证

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

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

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

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

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

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

4. 发现清单及建议

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

证据： 上下文图明确Supply/Fulfillment向Demand提供能力，但没有展开Demand/Customer的未来需求如何反馈到备货安排。Supply模型主要从接收、质量、分配开始。首页已经承诺按需备货、不留隔夜。

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

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

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

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

证据： 周计划体验§3明确“一餐不等于一次配送”；DM-06将分组列为待定。周模型目前按week-day一日一组，workbench也未提供同一数据集的完整映射。

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

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

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

证据： 协作表§5.3、DM-06§7已设计改址/改期协调，不是空白。PC-04/06仍缺换菜、改量、替代与补退差价；菜卡模型直接拒绝向已付日期重复安排，保护快照但不完成变更。

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

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

证据： OWNERSHIP§3已有平台通知、Customer已有ConsentHistory；PC-02仍未定站外渠道、授权、频率、退订。workbench有通知页，不能等同渠道接入完成。

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

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

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

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

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

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

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

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

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

证据： StudyMineDesk分别读取周计划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. 后台覆盖判断：不按页面数量计完成度

推荐工作组织为“今日承接与异常、明日备货准备、客户服务、日终核对”，现有模块保留为专业查找入口。上述是岗位组合视图建议，不新建业务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. 后续联合验证清单（未执行）

每条均需同时观察小程序、后台、权威业务结果和必要现场/支付回执；只测任意一端不算跨端通过。未来角色、数据规模、性能/可用性指标及恢复期限仍须登记实际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、不提交或推送；后续修订本报告即可恢复/更正审查结论，认可的设计快照不受影响。