# 按业务域协同交付：REQ 编排提案

> 日期：2026-10-01 · v0.2.0 · 状态：能力与事实分析；wave/REQ编排见唯一活动索引。  
> 整理责任：主会话；业务取舍：项目用户；实际领域维护、运行及发布负责人待落实。  
> 本文维护公共模型优先项、政策关闭时点和场景。实际wave与候选REQ统一在[WAVE-REQ-PORTFOLIO](WAVE-REQ-PORTFOLIO.md)维护，按每轮业务增长组织；不将本轮改序解释为需求锁定或绑定。

## 1. 交付单位与三端关系

**一个 REQ 交付一段能办理、能观察、能恢复的业务能力。** 小程序、后台和控制中心按该能力共同消费领域契约，在同一增量中完成联调。领域是责任边界；模块是用户完成任务的工作面；REQ 是有限、可验收的交付范围，三者不必一一对应。

小程序面向顾客自助；后台保持完整全局管理视角和单客户下钻，提供管理动作与受托代办；控制中心承载通用监控、告警响应和受控自动化。现场称重、切配、封包和配送还有作业端，涉及这些事实时一起纳入履约 REQ，不能把后台按钮视为设备或现场能力已经完成。

各入口使用相同源对象、合法命令和恢复查询。后台与小程序不分别建立订单；控制中心不复制业务状态、不直接改源表。客户下钻只是查询与办理范围变化，不能成为另一套业务流程，也不以个人工作、接待或交班组织整个后台。

共同开发不要求每个 REQ 在三端都新增页面。比如商品发布在后台编辑、小程序消费，控制中心观察发布失败；公共契约 REQ 可以没有 UI。每端须说明实际消费能力、验证证据或有理由的不参与，不能为了凑三端重复做功能。

## 2. 当前能依赖的事实与尚不能依赖的成果

| 基础 | 当前证据 | 对编排的影响 |
| --- | --- | --- |
| 运行阶段 | `.claude/loop-state.json` 为 inactive、bound_req=null | 当前做 S0 编排；没有已绑定开发批次或正式合同可直接继承 |
| 明确业务机制 | [确认政策](../architecture/05-domain/CONFIRMATION-POLICY.md)、[定案记录](../architecture/DECISIONS.md) | 付款核验、订单成立后可提前确认多天；默认配送日北京时间16:00截止，可配置；只取消未确认安排；订单按日期/地址拆分；未切配可申请取消/换菜；实际重量计价 |
| 权威分工 | [事实源索引](../architecture/SOURCE-AUTHORITY.md)、[OWNERSHIP](../architecture/07-bounded-context/OWNERSHIP.md) | 现有十域和 Platform 是责任设计输入；未完成字段、状态和人员不能视为已冻结 |
| 交易安全 | [TRANSACTION-INTEGRITY](../architecture/08-domain-model/TRANSACTION-INTEGRITY.md) | 终态、资金/数量守恒、停止与开工、UNKNOWN 是所有交易增量的约束输入；文档为 proposed，仍需正式设计签署和实现验证 |
| 可执行模型 | [模型目录](../architecture/08-domain-model/README.md)、[六机定义](../architecture/state/fresh-delivery-machines.json) | 十个模型卡是 working-draft；六机只覆盖部分对象，不能扩称全量模型基线 |
| 共享协议实现 | [共享模型规则](../rules/shared-model-contracts.md)；仓库现有 Schema/CONTRACTS 检索 | 找到的是 `docs/examples/shared-model/` 示例及合同模板；尚未找到供实际业务多端消费的完整共享 Schema 与 SYNC 集 |
| 控制中心方向 | [通用平台](../architecture/platform/MONITORING-AUTOMATION.md)、[业务场景包](../architecture/platform/DINGWEI-SCENARIO-PACK.md) | 已明确通用内核先于专用场景设计；Prometheus 是候选，精确合同、引擎能力和运行责任见 D-15 |
| 设计成熟度 | [DESIGN](../design/DESIGN.md) v0.3.0 provisional、[project-map](../project-map.md) extended | UI 候选可以编排；正式 `UI impact=changed` REQ 进入 §A–§C 前，须完成覆盖 Surface 的 Foundation 发布。临时认可风格不等于发布 |
| 原型成熟度 | [小程序说明](../design/prototypes/customer-miniapp/README.md)、[后台信息架构](../design/prototypes/admin-console/INFORMATION-ARCHITECTURE.md) | 可用于发现习惯与场景；本地订单/支付、历史 stories 和已画入口不能充当事实、完整验收或已承诺产品范围 |

本提案不更新 `DECISIONS` 的销项状态。后续出现冲突，先回对应主讲裁决；旧原型的留存资金、固定时间、订阅或“恢复订单”不得反向覆盖当前业务决定。

## 3. “全局唯一模型”首先要统一什么

唯一性指**同一事实只有一个含义和合法写入 Owner，同一跨端数据槽引用同一个原生定义**。允许源对象、成交快照、只读投影和外部观察各有表示；不把它们合成一份可任意改写的大对象。

### 3.1 第一批公共语义

以下是 R00 的分析对象，不是在本编排文档冻结的字段或 Schema。

| 事实/类型 | 必须先明确的内容 | 会暴露错误的例子 | 现行主讲/责任 |
| --- | --- | --- | --- |
| 主体与引用 | 登录账号、客户、员工、服务主体、经营范围、监控空间分别是谁；对象 ID 的类型、作用范围、外部 Provider/account 维度 | 客服传 customerId 就取得权限；不同渠道相同单号串单 | [Identity模型](../architecture/08-domain-model/model-01-identity.md)、[Customer模型](../architecture/08-domain-model/model-02-customer.md)；各 Owner 定本域唯一键 |
| 金额 Money | 币种、整数最小货币单位、可表示范围、编码；业务舍入与分摊另属计价政策 | 前端浮点累计与后台差一分；JSON 大整数越过 JS 安全精度 | [建模规则](../architecture/08-domain-model/MODELING-RULES.md)、交易/财务共同校核 |
| 数量与测量 | 件数、计划重量、实际采用重量、单位、精度及换算依据；物料、购买、执行数量不能互代 | 把两份订单行解释成两公斤；重复称重两次记消费 | 各数量 Owner；[Supply](../architecture/08-domain-model/model-04-supply.md)、[Fulfillment](../architecture/08-domain-model/model-07-fulfillment.md) |
| 时间 | 瞬时时间、当地业务日期、时区、时段、发生/接收/接受时间、端点；服务权威时间与客户端展示 | 客户端点了15:59:59就宣称确认成功；16:00边界两端不同 | [确认政策](../architecture/05-domain/CONFIRMATION-POLICY.md)、Demand；公共时间表示 |
| 版本与快照 | 对象 revision、政策版本、Schema版本、授权版本、执行 generation/fence 分开；快照保留来源 | 改地址簿使已成交单改地址；拿策略版本当订单版本 | [事实归属](../architecture/07-bounded-context/OWNERSHIP.md)、各版本 Owner |
| 请求与业务身份 | request 幂等、业务目标唯一性、事件身份、因果和关联身份；持久期限与查原结果方式 | 换请求键重复下单；超时换退款ID再退 | [交易协议](../architecture/08-domain-model/TRANSACTION-INTEGRITY.md)、Platform机制+业务Owner守卫 |
| 命令与错误结果 | 受理、处理中、已核验结果、拒绝、确定失败、UNKNOWN 的区别；原操作查询、冲突、重试与人工核验出口 | HTTP200被三端分别翻译成到账、已配送、故障已恢复 | [上下文接缝](../architecture/07-bounded-context/CONTEXT-MAP.md)、SYNC |
| 权限与证据 | 发起主体、实际执行主体、对象关系、作用范围；同意、授权决定、业务证据和技术文件引用分开 | 管理员身份被当成顾客同意；上传附件即判支付成功 | Identity和命令Owner；D-06，证据由事实Owner裁决 |
| 事件与组合视图 | 类型化来源、时间、版本、Schema、最小化载荷；字段可用/缺失/过期/未知和水位 | 缺收款数据显示未付；控制中心缺数据判正常；投影反写源表 | [一致性](../architecture/08-domain-model/CONSISTENCY.md)、Platform/投影消费者 |

不在公共库设置覆盖所有领域的 `status` 枚举。各对象状态由自身生命周期定义，公共层只统一交互与质量语义；不将业务终态、流程进度、资金结果和监控健康混成一条状态。

### 3.2 交易骨架要提前推清的关系

在 R08 接受付款前，必须联合审查下列关系和 R09/R10/R11 的输入、结果与恢复协议；实现可分增量，关系不能等后续界面出现再补。

```text
Customer/餐次意图 → CheckoutIntent → PurchaseBatch → Order/OrderLine
                                           ↑          ↓
PaymentIntent/Attempt → 已验证原款 → FundingAllocation  DeliveryInstruction/ConfirmationRecord
                                           ↓          ↓
                                       Settlement ← ExecutionGate/数量份额 → 作业/测量/包裹/交付
                                           ↓
                                      Refund / Adjustment → EconomicSource → Finance

ReplacementRequest：前驱停止证据 + 后继来源 + 新报价/分配 + 新授权
Platform：消费上述对象的信号/证据，调用上述 Owner 的获准命令
```

要明确每一条关系的基数、稳定身份、来源唯一约束、快照、版本、合法写入与失败出口。例如一次付款可多单；一单可有初款和补款；每日安排不以客户+日期唯一；换菜产生后继而不复活旧单；退款UNKNOWN仍占用原款额度。精确裁决仍由主讲及各 REQ 的 S2/S3 收口。

### 3.3 模型落地顺序

1. 在现有模型卡细化本域身份、关系和规则；状态继续引用已有状态源，未覆盖的生命周期由对应 Owner 补齐。
2. 在现有 `docs/architecture/data-model/` 体系定位原生模型，公共原语先定义，领域数据随增量增加。优先复用实际已有原生定义，不建立每个 REQ 的模型副本。
3. S3 中共享模型与 SYNC 一起收敛：同一 operation/slot 的 Schema、有效样例和结构反例，以及时间、错误、并发、恢复行为；再派生 FE/BE 职责。
4. 真实消费者在边界验证或由固定工具生成；仅写 model_ref、TS手抄接口或演示 Mock 不算消费。状态/权限/并发反例属于行为验证，不能冒充结构反例。
5. 后续变更只在原生来源演进，检查当前消费者和历史对象兼容；不能把刷新指纹当模型复核。

第一批统一公共原语和核心关系约束。订阅、增长、个性推荐等晚期对象不提前冻结全部字段；相关模型只需明确启用边界和事实归属，再在对应增量前精化。

## 4. 哪些未决项先影响哪些 REQ

未决项沿用 [DECISIONS](../architecture/DECISIONS.md) 的 D 编号，本表只安排读取与关闭时点，不建立新的政策清单。

| 未决事实 | 最晚关闭的设计点 | 未决时可继续的工作与禁止开放的能力 |
| --- | --- | --- |
| D-01 时段计费基准、跨档与档位 | R09费用/接受合同；涉及R08初始承诺也先校核 | 可完成时间类型和已确定截止；不得用演示档位扣费 |
| D-02/03 部分取消、改址改时、费用和开工后处置 | R08交易范围和R10部分结果接缝先审；R12/R13详细办理前定案 | 可实施已明确的完整范围协议；部分动作未定则明确受限，不能假装客服有万能修改权 |
| D-04 应收确认、超重、舍入与费用/优惠分摊 | R08报价和付款承诺前，R10称重采用/R11结算合同前 | “按实际重量”已决定；金额类型可先定，超重责任不能由类型设计决定 |
| D-05 退款时点与去向、批次结束/退出 | R08收款后的退出/拒收补偿合同前 | 不以暂留、余额或自动原路退为默认；未决不锁相关资金行为，不开放真实收款 |
| D-06 受托证据、范围、期限与撤销 | R02定义接缝；R09代确认及R12代变更启用前 | 员工管理动作和客户自助可先做；无证据不得开放受托确认 |
| D-07 等待预算、接手人、升级 | R04责任机制合同；各业务恢复启用/上线前 | 技术机制可在明确测试责任下验证；正式无人值守流程须有实际负责人与时限 |
| D-08 Provider验真、查询、晚到证据 | R08资金合同冻结前 | 可做隔离环境适配验证；未验证不把回跳或人工勾选当到账 |
| D-09 fence、离线和质量/开工竞争 | R06供给接缝、R10执行合同冻结前 | 暂不允许无保护离线开工；后台标完成不能替代实物防重 |
| D-10 其他对象精确生命周期 | 每个拥有该对象的REQ的S2/S3 | 使用有限对象库存逐项补齐；六机通过不代表任务/售后/会计完成 |
| D-11 切换水位、未知旧数据、回滚恢复 | R01建立恢复机制；实际迁移所属REQ及上线前 | 原型localStorage不作为生产资金来源；无旧生产数据也需证据支持，不能默认迁移N/A |
| D-12 订阅、增长、推荐启用边界 | R20/R21/R22进入详细需求前 | 保留必要事实引用；候选原型入口不授权全部商业模式 |
| D-13 客户合并、隐私、保留/删除 | R02数据最小化；R19危险处理前 | 先保护历史与用途；不开放未审定的批量销毁/合并 |
| D-14 来源唯一性、规则更正、关账 | R08确定经济来源身份；R16合同前 | 交易输出可追踪来源；不以试算报表代替过账协议 |
| D-15 平台类型、转译、能力、发布、隔离/容量/灾备/人员 | R03/R04/R15分阶段各自合同及启用前 | 通用性先用非业务对象验证；指标画出来不等于检测可靠，自动写另验授权和外部效果 |

## 5. 能力族库存与交付边界（非REQ执行顺序）

R00–R22保留为23个能力族的分析引用，不是23份实际执行REQ或23个串行步骤。下表职责和政策边界仍有用，原先实现前置包含过多真实结果关系；新的C/F/R/E分类、11个wave与41个候选REQ只在[wave编排](WAVE-REQ-PORTFOLIO.md)维护。主Owner指事实/协调责任，不假定同名人员已经上岗。

| 能力族 | 语义名称 / 主 Owner（不是最终REQID） | 必要业务成果 | 小程序 / 后台 / 控制中心共同交付 | 接入关系与主要待决（C/R/F须按wave重判） |
| --- | --- | --- | --- | --- |
| R00 | DW-SHARED-BASELINE / 架构+各Owner | 公共语义和核心关系有单一来源，多端不各自解释 | 无UI；输出实际消费者可验证的原生类型/样例、同源消费要求和恢复接缝 | 现有主讲；不冻结未决退款、费档等政策 |
| R01 | DW-RELIABLE-RUNTIME / Platform+Identity | 持久命令/结果、权限接缝、审计、Outbox/Inbox、调度、证据文件和恢复机制可用 | 各端适配/业务Owner真实消费；无业务页面，用通用操作验证提交、丢回执、重启和撤权 | R00；技术选型、持久化、环境/密钥、时间/恢复目标须在S2定；D-11 |
| R02 | DW-IDENTITY-CUSTOMER / Identity+Customer | 顾客与员工正确识别，区域/范围/地址/同意可管理 | 顾客登录/地址；后台全局客户与权限、单客户上下文；控制中心主体/监控空间复用授权，审计可串联 | R01；Foundation；D-06/13接口与用途。完整受托启用取决于业务命令证据合同 |
| R03 | DW-MONITORING-DETECTION / Platform | 通用对象接入、数据质量、策略解释/试算/影子、版本发布和事件检测 | 控制中心配置/观察；后台系统健康只读引用；小程序只消费必要可用性，无监控配置 | R01+R02；Foundation；D-15。先验证HTTP探测/通用计数等非零售场景 |
| R04 | DW-MONITORING-RESPONSE / Platform | 一次触发有明确响应、通知/工单/责任、核验关闭和失败升级 | 控制中心响应办理；后台业务异常以源对象关联参与；顾客只接适用且获同意的通知 | R03；D-07/15。技术值班责任不另造客服接待/交班系统 |
| R05 | DW-CATALOG-PUBLICATION / Catalog | 可维护规格、内容、发布版本，顾客看到准确且可回溯的商品 | 小程序浏览/详情；后台编辑/发布/回退；控制中心观测发布代际、失败和源新鲜度 | R02+R04；规格/发布生命周期。价格决定归Commerce，不在商品页另造权威价格 |
| R06 | DW-SUPPLY-QUALITY / Supply+Fulfillment | 接收、批次、质量、物料额度与更正有依据，形成可信供给；Fulfillment发布最小版本化履约能力 | 小程序消费可用/质量与受控追溯摘要；后台到货、放行/隔离/分配、更正及能力维护；控制中心质量/传播异常 | R05；R04；D-09/10。R09所需供给和履约能力在此实接；能力降低不删既有承诺。供给与开工接缝先定，暂不增加无依据WMS/采购结算 |
| R07 | DW-MEAL-PLANNING / Customer | 按生活习惯编餐次/个人菜卡，保留版本与购买来源 | 小程序个人计划；后台受控协助编辑未成交意图及历史查看；控制中心同步/保存故障 | R05；R02+R04；与R06可独立推进。草稿不产生商业义务 |
| R08 | DW-CHECKOUT-PAYMENT / Commerce | 报价、按日期地址拆单、购买批次、收款验真与分配、拒收/退出退款恢复 | 小程序核对/付款/原结果查询；后台订单与原款核验、差异和受限恢复；控制中心UNKNOWN/协调停滞接入 | R06+R07+R04；D-02/04/05/08/14来源；R09/10/11输入输出须预先联合设计。仅隔离联调，不单独开放真实销售 |
| R09 | DW-DELIVERY-CONFIRMATION / Demand+Commerce | 已付可提前确认、明确时间费用授权、到期互斥与关单/资金协调 | 小程序多日逐次确认/提醒直达；后台截止配置、安排核验及有授权的代办；控制中心补扫延迟/费用异常 | R08；D-01/06/10；无顾客抢资格，能力不足有明确承接出口 |
| R10 | DW-FULFILLMENT-DELIVERY / Fulfillment+Supply | 授权/资金/质量/数量门禁、实际测量、包裹追溯、交接和部分交付 | 小程序真实进展/Meat ID；后台计划/调度/异常；作业端现场证据；控制中心失联/停滞/质量接缝 | R06+R09；D-04/09/10；停止、称重更正和部分结果接缝必须齐全 |
| R11 | DW-SETTLEMENT-REFUNDS / Commerce | 实际计价、退差、退款原目标核验、批次结清和结清后调整 | 小程序明细/退款真实结果；后台范围/分项核对、UNKNOWN人工核验；控制中心差异/逾期 | R08+R10；D-04/05/08/10。R08已覆盖不能承接实收的最小退款，此REQ补完整称重结算 |
| R12 | DW-ORDER-CHANGES / Commerce+Demand+Fulfillment | 取消/换菜/改址改时有边界，新旧执行与钱货不双用 | 小程序申请/影响确认/后继展示；后台同对象办理、差额与步骤续办；控制中心冻结/停止/补款异常 | R11；D-02/03/06/09。R10已有安全停止/拒绝协议，不等待此REQ才保护旧任务 |
| R13 | DW-AFTERSALES / Commerce | 分项裁决、退款/补发/回收执行和证据闭环 | 小程序诉求/证据/进度；后台裁决、逐项续办；控制中心下游失败与未结义务 | R11+R12；D-02/03/10；补发复用标准订单/授权/履约，不再造系统 |
| R14 | DW-QUALITY-RECALL / Supply | 批次影响查询、停止/通知/回收/售后逐项回执闭环 | 小程序受影响通知与追查；后台召回/履约/售后统一关联；控制中心传播失败和未结动作 | R06+R10+R13；传播/关闭政策；质量隔离门禁已在R06/R10实现，不能拖到召回UI |
| R15 | DW-CONTROLLED-AUTOMATION / Platform | 通用套餐编排、动作互斥、权限/预算、UNKNOWN、验证与中止；再绑定鼎味动作 | 控制中心编排/执行/核验；后台人工接管同一个源动作；小程序消费真实处置结果 | R04+R01；通用动作先验证，接入某业务动作另要求该Owner实现已验证命令；D-07/15。普通到期/结算调度不依赖此REQ |
| R16 | DW-FINANCE-POSTING / Finance | 核算主体、来源、规则/期间、平衡分录、冲销与受控期初 | 后台财务核对；小程序仅消费Commerce账单；控制中心来源漏接/重复/过账异常 | R11；D-14/11；首次需核算的其他来源一并列入有限库存 |
| R17 | DW-ANALYTICS / Analytics | 指标口径、数据质量、重建/发布及受控导出 | 后台经营决策；控制中心引用登记信号；顾客数据仅按用途使用 | R11；涉及财务指标需R16；各源切片已有基本运营查询，不等大Dashboard才可运营 |
| R18 | DW-EXTERNAL-CHANNEL / Channel | 外部来源绑定、观察导入、内核接受、回传/账单对账 | 后台外部对象办理；小程序查看已被接受的同一业务；控制中心同步/UNKNOWN | R13；启用渠道及真实Provider合同；支付Provider仍归R08/11 |
| R19 | DW-CUSTOMER-DATA-LIFECYCLE / Customer+Identity | 合并、撤回、用途/保留、受控导出/删除和跨域结果传播 | 小程序提出/查看处理；后台预览影响、办理/分项续办；控制中心传播与未结责任 | R02；所有实际消费者的合同；D-13，不能删除钱/货历史 |
| R20 | DW-CONTINUOUS-SERVICE / Demand | 经批准的持续服务合同、权益、周期出单和暂停/退出 | 小程序启用/维护；后台合同与周期核对；控制中心周期/权益异常 | R13；D-12；一周规划已经由R07–R11支撑，不先默认自动续费 |
| R21 | DW-GROUP-CAMPAIGNS / Customer+Commerce | 经批准的团长资格、活动关系与标准交易来源 | 小程序参与；后台资格/活动管理；控制中心来源/权益异常 | R13；D-12；佣金若启用必须另定Owner和核算范围，不凭入口自动加入 |
| R22 | DW-RECOMMENDATION-DECISIONS / 待收敛Owner | 经批准的推荐决策/规则实验与撤回，可解释且可退出 | 小程序内容建议；后台规则/实验/影响；控制中心效果质量与执行异常 | R07+R17；D-12/隐私及Owner；R05静态推荐内容不等同此决策系统 |

### 5.1 调整后的wave与并行方式

上一版将公开结果消费画成大量REQ串行箭头，现已撤下该执行图。正式编排改为：[每个wave多REQ并行](WAVE-REQ-PORTFOLIO.md)，先统一公共契约与已有共享构件，各REQ按独立分支实现，在wave出口汇合真实适配。各REQ有自己的Runtime和绑定开发分支，单Runtime单REQ不构成项目跨REQ串行限制。

例如R08/R09按报价、订单/批次、原款、每日安排四个REQ在W4并行；R10/R11及财务按执行/测量、物料转换、包裹交付、实际结算、核算五个REQ在W5并行。先验契约和最终真实结果分别检查，不能把Stub联通当作wave完成。

### 5.2 可联调与可上线分别看证据

| 检查点 | 可交付/联调的成果 | 仍不具备的经营能力 |
| --- | --- | --- |
| R00–R04后 | 同源合同、可靠命令和通用监控/响应非业务场景可验证 | 尚无可售商品和完整鲜配；不称业务上线 |
| R05–R07后 | 后台发布/质量与小程序浏览/计划消费同源事实，控制中心能追异常 | 尚无真实付款/履约；不能将可浏览等同可买 |
| R08后 | 在隔离环境联合报价、拆单、支付、查原款和拒收退款；未来接缝有契约 | 尚不能对外承诺真实鲜配；禁止只有收钱入口没有交付出口 |
| R09后 | 多日确认、到期、费用与订单/资金协调可联调 | 尚无验证过的现场执行和完整称重结算 |
| R10–R11后 | 核验授权、实际作业、交付、计价与原款/退款在同一链路 | 此时仍须核查取消、售后、质量召回、核算及运行责任的实际最低范围，不能自动上线 |
| 首次付费业务候选 | R08–R14完整必要办理链、已启用的财务范围、R04真实兜底责任，具备迁移/灾备、真实渠道/现场证据 | 上线范围需单独批准；R15高风险自动化不作为售卖的必需前提，未启用能力明确受限 |

不存在“先收款上线，再安排退款/售后”的建议。首次付费范围若要缩小，必须具体证明所有合法取消、食品质量、资金和履约义务仍有可审计办理出口，不能仅隐藏按钮缩小验收。正式发布照现行S7/S10/S11完成，不以本表替代。

## 6. 每个模块精化时的场景和使用习惯

逐项设计继续在模块当前真相包维护，REQ只记录本次目标和验收引用。后台当前82项页面是待审查库存，不是必须逐页各开REQ，也不是41个wave候选REQ已经完整覆盖所有功能的证明。

| 业务触发/操作者习惯 | 必须能完成的任务 | 设计时要追到的事实和出口 | 首要候选 |
| --- | --- | --- | --- |
| 顾客有空时集中安排，随后几天不登录 | 一次购买后提前确认多次；回来保留真实结果 | 餐次与订单关联；确认独立；不登录不取消已确认安排 | R07–R09 |
| 顾客重复点提交、换设备、付款后页面断线 | 查询原结果，既不重复付钱也不丢安排 | 来源唯一性、幂等、UNKNOWN、服务端记录和水位 | R00/R01/R08 |
| 管理者先看全局当日确认、到货和执行，再定位范围 | 识别可承接、未确认、质量与实际调度影响 | 指标对象/日期/范围/来源；投影过期不虚报安全 | 每个业务切片同步补全局视图；R17补复杂分析 |
| 员工接到某客户关于订单/钱/送达的咨询 | 直达客户，再进入具体原款、安排或包裹办理 | 同一ID、谱系、权限、证据、可执行动作、返回定位 | R02起建立下钻；R08–R14逐域接入 |
| 顾客已确认，但临时要换菜或改址改时 | 先看当前可改范围、费用及后果，再提交或代办 | 停止与开工竞争、新授权、后继失败/差额核验 | R12；基础停止/授权协议R09/R10先齐 |
| 员工面对支付/退款未知，不知道是否已经执行 | 查原目标、提交有效核验或升级，清晰说明未结范围 | Provider证据、额度占用、核验权限、继续责任 | R08/R11/R04 |
| 作业人员扫码、称重、重传或设备断线 | 保存原始观察，采用合法测量，避免重复切配/交付 | fence/数量份额、现场未知、实物核验、更正 | R06/R10 |
| 客户只收到一部分或部分变质 | 按行/数量处理未交付、退费、补发、回收 | 分项裁决和分摊、原交易、下游结果、部分失败续办 | R10/R11/R13 |
| 质量人员追一个批次的全部受影响对象 | 停危险动作，传播并逐项核验处理 | 追溯边、影响快照、作业/售后回执，不能一键关闭 | R06/R10/R14 |
| 管理者批量办多单，过程中撤权/政策改版/部分失败 | 逐项合法办理，可知成功/拒绝/未知并继续 | 每项源版本、操作身份、权限、影响复核，不统一改状态 | 所有具备批量动作的REQ |
| 运维人员遇到告警恢复但外部动作仍未知 | 保留执行责任，核验实际效果后结束响应 | 告警/工单/执行独立，人工与自动互斥 | R03/R04/R15 |

每个模块先按[模块设计规则](../rules/module-design.md)写任务必要性和八项设计卡，再做用户故事、正常/异常/边界路径和页面意群。重点审查真实动作，不以故事数量或页面数量作为完成标准。

同一故事至少说明触发、已有上下文、要作出的判断、信息来源、权限、输入与影响、正常结果、拒绝/失败/未知下一步、再次进入如何续办。顾客和工作人员故事分别覆盖，各有习惯；不把员工故事提升成整个后台的信息架构。

## 7. 每个 REQ 的共同交付包与验收方式

以下是本计划建议纳入每个REQ的完成范围，不替代现有阶段合同。

| 成果 | 需要证明什么 |
| --- | --- |
| 有限范围与事实库存 | 本增量有哪些任务、对象、操作、字段/状态及消费者；哪些是有依据的非参与，哪些UNKNOWN仍阻塞 |
| 模型与SYNC | 操作/数据槽的单一Schema、实际消费者、正常/结构反例；权限、时序、错误、并发、补偿和查原结果 |
| 模块设计 | 受影响模块当前故事/流程/CASE/原型同步；必要性、真实使用习惯、全局/客户上下文与异常出口清楚 |
| 后台兜底 | 合法管理/受托动作的条件、拒绝理由、证据、逐项结果、查询及恢复可办理；禁止通用改状态按钮 |
| 控制中心接入 | 当范围需要检测时，信号/质量/版本、策略、响应责任、回源链接和关闭证据齐；源Owner保持自动到期/结算责任 |
| 实接证据 | 小程序操作后后台读同一对象，现场/自动事实回传后各视图一致；控制中心故障检测与源恢复相互可查 |
| 故障及并发 | 每个新增命令含重复/异载荷、冲突、撤权、失联、迟到/重放、部分完成、重启；高风险另验证真实渠道/现场 |
| 演进与运行 | 历史对象与政策版本、数据迁移库存、兼容、备份/软件回滚、义务恢复及实际责任；软件回滚不抹现实资金/物理事实 |

原生数据校验、协议时序验证和端到端联调各自证明不同事情。结构PASS、Mock成功或后台列表出现不能替代实际持久化、跨端授权、外部效果和恢复证据。每个REQ的S7仍按其全量声明覆盖，不把定向检查称为clean round。

首条经营联调骨架建议固定为：后台维护真实来源商品/批次 → 顾客规划并接受报价 → 付款验真 → 后台核对同一订单/原款 → 顾客明确确认 → 作业端校验门禁并记录真实测量/交付 → Commerce实际计价与退差 → 各端查看同一结果。伴随故障轨迹：付款回执丢失、确认与截止竞争、隔离与开工竞争、现场回执未知、退款未知、重启后续办。它是共同验收输入，各模块新增路径再叠加，不能一直只测这一条。

## 8. 完整域库存、方案取舍与剩余责任

| 现有域/平台 | 候选覆盖 | 边界与尚需展开 |
| --- | --- | --- |
| Identity | R00/R01/R02/R19 | 主体、权限/范围、服务身份、任职；具体人员与撤权窗口待合同 |
| Customer | R02/R07/R19/R21 | 档案/地址/同意、个人菜卡/计划、生命周期/团长；组合Customer360随各域接入 |
| Catalog | R05 | 规格、内容/推荐菜谱、发布；在线推荐决策另R22、价格另Commerce |
| Supply | R06/R10/R14 | 来源、质量、账、转换/追溯、召回；单位容差/更正政策待精化 |
| Demand | R09/R12/R20 | 时段/承诺、配送授权、改期/撤销、批准后持续服务；能力输入归实际Owner |
| Commerce | R08/R11/R12/R13/R18/R21 | 报价/权益、交易/资金、换菜、售后与标准来源；优惠复杂范围须在对应REQ有限盘点，不能默认全部促销 |
| Fulfillment | R06/R10/R12/R13/R14 | 能力、执行门禁、作业/测量/包裹、交付/回收与停止；包括作业端 |
| Finance | R16 | 主体、期间、来源、规则、分录/更正/期初；实际核算启用范围待定 |
| Channel | R18 | 销售渠道授权/映射/导入/回传/账单；不是支付适配 |
| Analytics | R17/R22（仅按批准归属） | 指标/质量/构建/导出；推荐决策Owner不能默认交Analytics |
| Platform | R01/R03/R04/R15 +各域接入 | 文件/审计/传输/调度、参数/字典的技术壳、能力目录、监控/响应/自动化；业务政策仍各归Owner |

此表证明十域+Platform已纳入编排思考，不证明82项原型功能、全部商业模式或所有状态已完成细化。后续REQ必须把实际选中模块的功能必要性、现有页面/动作、模型/协议、故事/CASE/测试证据逐项核对，不为了覆盖旧菜单启用未批准功能。

| 方案 | 结论与代价 |
| --- | --- |
| 按小程序/后台/控制中心分别排整套工程 | 不采纳：交易/权限/状态各自解释，真实办理和异常出口延后才发现缺口 |
| 先冻结全系统所有表和所有模式，再做第一业务切片 | 不采纳：未决政策被迫预设，模型缺真实消费者反馈，迟迟不能验证协作 |
| 公共语义与关键关系先行，按域/业务能力增量协同，每个REQ实接 | 推荐：每次交付都要承担三端与异常合同的成本，但可持续验证事实、习惯与兜底，不积累三套系统 |

当前主要剩余风险是资金政策/实际计价尚未定、模型非全量、Foundation未发布、真实Provider/设备能力与负责人未落实。主会话负责组织提案与反证；业务用户批准商业取舍；相应事实Owner负责语义和契约；实际运行/财务/安全负责人在启用前须指派。当前未指派不降级为非阻塞风险。

恢复路线：设计语义冲突回唯一主讲；已锁定需求变化走变更控制；实现缺陷走S8/S9再完整S7；外部能力不足保持相关写操作关闭并提供有证据的原目标核验；历史资金/物理事实追加更正，不用回档“恢复”。控制中心不可用时源业务仍保持门禁与持久恢复意图，启用前验证独立告警/兜底，而非依靠平台自身报告健康。

### 8.1 本轮编排自审与反证

| 反证 | 编排中的处理 | 证据边界 |
| --- | --- | --- |
| R09依赖R10才有履约能力，R10又依赖R09授权，形成实现环 | 最小能力发布放入R06，由Fulfillment合法维护，R10扩展现场执行 | 这是职责/依赖修正，尚无真实能力实现或承诺压力验证 |
| R08收了钱，R11未开发就无法退 | R08必须具备拒收/退出的最小退款及原目标查询；资金政策先定，整条经营链未齐不开放真实销售 | 相关合同和Provider故障证据仍未完成 |
| 商业到期等待R15自动化实现才处理 | 持久到期/结算调度在R01及源Owner实现；R15只增加通用受控套餐 | 监控与源执行的边界可从现行主讲核对，运行恢复仍待验证 |
| 商品/质量页面先画完，实际开工可以绕过隔离 | R06与R10合同需先联审质量/分配/执行门禁，开工只认有效源事实 | 设备fence、隔离传播时效和物理竞争未验证，不能上线宣称安全 |
| 能力族被当成固定串行REQ或已批准业务 | 保留23个能力族分析，实际按11个wave/41个候选REQ重排，扩展先关D-12，R00仅有§A | 后续完整范围仍须逐REQ漏斗收口；同wave公开关系不自动成为F依赖 |

2026-10-01首版曾检查23个能力条目与24条串行主依赖的结构；那只说明图无环，不证明串行安排合理。现行安排由能力增长、公开契约/实际构件/实接结果/证据分类和wave并行编排解释，检查边界见[当前提案状态](WAVE-REQ-PORTFOLIO.md#6-当前提案状态与剩余责任)。未运行产品测试，不声称完整架构或交付验收通过。

## 9. 当前可审阅结果与下一步

已完成：现有事实和成熟度核查、公共模型优先库存、D项关闭时点、23个能力族分析；实际重编为11个wave/41个候选REQ，逐轮写明新增能力与可办理业务，维护独立分支边界、三端/作业端职责、经营检查点及共同交付包。未完成：各候选正式§A/§B/§C、全量模块详细场景、原生业务Schema、合同或实现验证。

建议首个正式需求为[R00：共享事实与基础数据契约](REQ-DW-SHARED-BASELINE.md)，本轮只展开§A。它没有UI影响，可先形成正式理念基线；Foundation发布准备与后续界面范围另按现有设计规则办理。只有用户明确锁定并授权绑定后才进入正式运行，不从本次编排指令推导锁定或发布授权。