Wave → REQ：逐轮增长的经营能力
日期：2026-10-01 · v0.4.0 · 编排提案。
主会话维护；本文是wave/候选REQ归属与业务里程碑的唯一活动索引。
每轮描述的是完成并验收后的目标能力，当前不代表这些能力已经实现。41个候选均已有规划范围卡，只有共享基线有正式§A草案；本轮不锁定、绑定或发布。
1. 阅读和执行方式
Wave定义完成后能跑通的业务，REQ定义共同交付该业务的独立责任。 同wave的REQ先统一模型、操作/事件、时间/错误、权限、Fixture和恢复协议，再按独立分支开发；本wave所需真实实现汇合并完成共同业务验证才算结束。
小程序负责自助，后台保持全局管理与客户下钻，控制中心负责通用监控/响应/受控自动化；现场事实涉及作业端。每个业务REQ同时交付这些入口中与自身有关的能力，端侧读取/办理同一个事实和受控命令。公共技术REQ可没有用户页面，须如实说明其完成边界。
基础事实和未决政策详见公共模型与经营场景分析，现行业务规则以事实源索引和定案条件为准。编排使用清晰的新能力名称；不维护历史REQ编号映射。
2. 每轮过后，我们多了什么
| Wave | 能力增长 | 本轮结束能够跑通的业务 | REQ数 |
|---|---|---|---|
| W0 | 所有模块使用一致的身份、金额、数量/重量、时间、版本和操作结果定义；工程能构建、启动、生成和检查。 | 还没有顾客零售业务。能够在统一工程中验证一次类型合法/非法的请求，以及重复请求、冲突和UNKNOWN应如何表达；为后续独立分支提供共同输入。 | 2 |
| W1 | 账号、员工/客户关系、地址、用途同意、角色/范围和受限服务主体形成持久事实；具备幂等、审计、消息、调度恢复和模块框架。 | 通过受控领域接口登记账号/客户/地址、指派权限并验证不同作用范围；同一操作响应丢失后可以查原结果。员工和顾客的完整页面办理在W2交付。 | 4 |
| W2 | 顾客、管理人员和现场人员具备真实登录与基础办理体验；通用监控能够接入、解释策略、检测、响应和核验。 | 顾客登录维护地址与同意；管理人员在全局后台管理客户/权限并下钻；作业人员建立受控设备上下文。控制中心可对一个非零售服务故障完成检测→通知/责任→处理→核验。 | 6 |
| W3 | 商品规格/内容、首页、供给质量、物料账与可信可用性可维护；履约能力有版本；顾客可保存个人菜卡和餐次计划；通用自动化能核验非业务动作。 | 工作人员登记到货和质量决定，发布商品/内容；顾客浏览同一商品、来源摘要和可用性，选规格编排本周餐次并保存；后台有权人员可帮助调整未成交草稿。 | 7 |
| W4 | 服务端报价/权益、按日期地址拆单、购买批次、支付验真、原款分配/最小退款，以及独立逐次配送确认/费用/到期。 | 顾客购买多个餐次、一次付款覆盖多单，付款核验且订单成立后提前确认未来多次配送；未确认安排自动到期并协调关单/资金处置。后台可核对同一订单、原款和安排。 | 4 |
| W5 | 订单执行门禁、数量份额、现场作业/称重、物料分配转换、包裹/交接/交付、实际计价/退差与核算。 | 已经付款并明确确认的安排生成合法作业，经切配称重、封包追溯、交接配送到交付，再依据实际采用重量结算、核验退款及交接会计来源；钱、货、授权和原始证据可查。 | 5 |
| W6 | 取消/换菜/受控改址改时、后继订单与差额、新授权、分项售后/退款补发回收、批次召回、经营分析和客户数据处理。 | 顾客改变安排或发现交付问题，后台有权工作人员能在同一客户/对象上下文办理。质量人员能从批次找全部受影响订单并逐项处置。管理者可核对成交、执行、退款和未结责任。 | 5 |
| W7 | 真实生产拓扑/权限/密钥/环境、切换与软件回退、SLO/容量/保留、备份/灾备、真机/辅助技术/兼容及独立外部兜底。 | 在批准的业务范围中演练真实环境故障：支付回执丢失、服务/监控停机、设备失联、恢复备份或切换版本后，仍能查原目标继续未结义务，并保护已经发生的钱和实物。 | 2 |
| W8 | 锁定精确兼容的需求/合同/模型/Client/代码/配置/迁移和运行证据，形成可审查、可交接的鲜配核心版本。 | 从商品/到货、餐次安排、购买付款、逐次确认、切配称重、配送、实际结算，到取消/售后/召回和客服兜底，整条业务在同一候选版本完成；取得独立发布授权后可按已批准范围投入经营。 | 1 |
| W9 | 外部渠道观察/绑定/导入/回传/对账、团长资格/活动/同账号门户、受控分享/落地与归因；全部复用核心订单/资金/授权/履约。 | 顾客从分享/活动或已获证实能力的外部渠道进入同一购买与服务闭环；管理者核对来源和同步，渠道未知/重复/撤权可以安全恢复。 | 3 |
| W10 | 经批准的服务合同/权益/周期标准出单/暂停退出，以及有同意、解释、规则版本和实验依据的引导选购/个性推荐。 | 顾客选择批准的持续服务并管理未来周期；到期权益形成合法标准购买，仍有明确配送授权。也可按已同意的偏好获得可解释建议、修改后进入同一报价/付款/履约链。 | 2 |
三个经营里程碑：W3完成“有真实食材和生活计划”；W5完成“一笔正常成交的钱货闭环”；W6完成“正常与异常、顾客自助与人工办理的鲜配功能闭环”。W7补生产条件，W8形成获独立授权后可发布的核心版本。
W9和W10是各自有业务价值的扩展分支，功能实现共同依赖W6，可互相并行，也可与核心运行准备穿插。数字只表示阅读顺序，不强迫等待订阅再做渠道或等待增长再做推荐。首次核心发布可以不包含它们；之后每次扩展发布须追加相应完整验证、运行证据和人类发布审核。
flowchart LR
W0[W0 共同事实和工程] --> W1[W1 身份客户和可靠保存]
W1 --> W2[W2 可用系统和异常责任]
W2 --> W3[W3 上架与餐次计划]
W3 --> W4[W4 购买付款与配送确认]
W4 --> W5[W5 正常交付与结清]
W5 --> W6[W6 变化异常和客服兜底]
W6 --> W7[W7 生产运行与恢复]
W7 --> W8[W8 核心候选和发布交接]
W6 --> W9[W9 外部渠道与增长]
W6 --> W10[W10 持续服务与推荐]
图示功能前置。W9/W10上线还需对包含扩展的精确候选重新完成适用的W7/W8检查，不因功能箭头存在取得上线许可。
3. 完整Wave / REQ层次
每个wave的表格就是本轮独立REQ分支范围；各REQ编号没有先后含义。若表中任务仍涉及多个不同事实Owner，通过公开能力协作，各Owner不互改源表。表内REQ链接进入具体范围卡。目标、办理动线、必要功能、跨端工作面、目录、出口判据和依赖已在卡中展开；正式FR/AC、状态和文件级write_paths仍在需求/设计/合同中收口。
W0｜建立共同事实与可运行工程
完成后的能力： 所有模块使用一致的身份、金额、数量/重量、时间、版本和操作结果定义；工程能构建、启动、生成和检查。
共同业务演示： 工程人员启动项目 → 从唯一Schema生成或校验数据 → 合法样例通过、结构反例拒绝 → 各端输出一致的请求结果含义。此链只证明工程和契约基础，不生成销售、付款或库存效果。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-SHARED-BASELINE 共享事实与基础数据契约 |
公共ID/金额/单位/时间/版本/命令结果；核心关系和Schema消费边界；无UI | 公共原生定义、合法/结构反例、状态来源、UNKNOWN查原结果语义 |
| REQ-DW-ENGINEERING-BASE 工程地基与开发环境 |
构建/生成/CI/数据库迁移机制、可启动工程与扩展槽；暂不固定UI导航或部署单元数量 | 工具链、包边界、公共扩展接口、迁移命名/执行规范 |
进入本轮： 业务主讲、Owner边界与核心关系可定位。
先统一的事实： TypedId/SourceRef、Money、Quantity/Unit、时间、版本、命令/错误与证据引用；餐次/订单/原款/授权/执行关系骨架。
人工兜底： 尚不承诺工作人员可在页面办理经营事项；本轮完成用于业务的基础定义和工程检查。
完成判据： 唯一原生定义与样例可执行验证；根命令/生成/构建/启动可复现；公共接口和模块写入边界能交给并行分支。
当前经营边界： 精确领域状态/政策由相关REQ继续收口；公共类型不能擅自确定退款、费档、超重责任。
需收口的政策： 无新增商业政策批准；核对现行事实源及已确定交易原则。
W1｜建立真实身份、客户与可靠保存能力
完成后的能力： 账号、员工/客户关系、地址、用途同意、角色/范围和受限服务主体形成持久事实；具备幂等、审计、消息、调度恢复和模块框架。
共同业务演示： 创建客户并保存地址 → 授予员工特定区域的查询/办理权限 → 受控接口读取同一客户 → 越权请求被拒绝 → 提交成功但回执丢失时查询原操作 → 重启仍保留记录和审计。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-RELIABLE-RUNTIME 持久命令与可靠运行基础 |
幂等/持久结果、Outbox/Inbox、调度恢复、审计和证据文件基础 | 命令/消息/文件/作业端口；租约、fence及原结果查询 |
| REQ-DW-IDENTITY 身份、授权、服务范围 |
账号/成员/岗位/角色、会话、有效权限、服务主体和区域；多端同源授权 | Actor、授权输入输出、可信归属、撤权和受限恢复主体 |
| REQ-DW-CUSTOMER 客户档案、地址与用途同意 |
客户/账号关系、地址、同意/限制事实；成交快照接缝 | Customer/地址/同意来源版本；数据最小化与引用 |
| REQ-DW-SURFACE-FRAMEWORK 跨端布局与模块扩展槽 |
继承当前设计的小程序/后台/控制中心布局及作业挂载槽；全局管理与客户下钻 | 导航/注册/模块挂载/查询上下文契约；路由与层次按当前认可设计推导 |
进入本轮： W0共同输入和工程可运行；可见布局REQ须有覆盖Surface的已发布Foundation。
先统一的事实： Actor/Account与Customer独立，地址/同意有版本；AuthorizationDecision、可靠命令/结果、Outbox/Inbox、审计、文件引用及模块扩展槽。
人工兜底： 恢复已有义务的服务主体与新人工意图分别校验；受托代确认/变更的证据接口先明确，具体业务动作后续交付。
完成判据： 实际身份/客户数据能持久化与回读，账号和客户关系明确；权限/撤权/同键异载荷与重启路径验证；提供下一wave所需真实领域能力和框架槽。
当前经营边界： 本轮领域接口完成不等于多端业务工作面已完成；同wave共享实现的实际F依赖须交接。
需收口的政策： D-06受托接缝、D-13用途/最小化；身份/区域及可靠运行的实际技术合同在本轮收口。
W2｜让人能使用系统，让异常有人接住
完成后的能力： 顾客、管理人员和现场人员具备真实登录与基础办理体验；通用监控能够接入、解释策略、检测、响应和核验。
共同业务演示： 顾客登录并修改地址 → 后台有权员工检索该客户并看到相同版本 → 无权人员看不到敏感字段。独立演示服务探测失败 → 控制中心建立事件并明确响应责任 → 实际恢复后回源核验。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-CONTRACT-ADAPTERS 同源Client、Stub与故障注入 |
各入口同源Client、隔离Fixture和混合适配；未实现能力明确NOT_READY | 本wave契约/Client版本；Stub与Real共用一致性入口 |
| REQ-DW-CUSTOMER-ACCESS 顾客会话、账户与标准请求体验 |
小程序登录/会话恢复、账户/地址/同意及冲突/UNKNOWN体验 | Identity/Customer Client与框架槽，禁止复制DTO |
| REQ-DW-BACKOFFICE-ACCESS 后台权限模式与客户上下文 |
全局身份/客户管理、对象下钻、动作预告/执行/批量逐项回执 | 后台能力/字段/范围和请求状态；不新增客服接待系统 |
| REQ-DW-OPERATIONS-ACCESS 作业身份、设备与请求队列 |
作业登录、设备/作业点上下文、扫描/证据适配和弱网意图恢复 | 设备信任与队列恢复；不可逆动作不得离线自主开工 |
| REQ-DW-MONITORING-DETECTION 通用接入、检测与策略发布 |
控制中心空间/目标/信号/查询/策略/编译发布、质量/影子评估和触发 | Evaluation/Trigger/质量/代际；源Owner不由引擎替代 |
| REQ-DW-MONITORING-RESPONSE 通用告警、响应与人工兜底 |
响应计划、通知/工单/责任/升级和回源验证；后台关联同一事件 | 事件身份、响应/投递/工单的独立结果、关闭证据 |
进入本轮： W1真实身份/客户/运行能力；本wave公开Schema、SYNC与生成Client先交接。
先统一的事实： 同源Client和标准请求态；MonitoringSpace/Target/Signal/Policy/Evaluation/Trigger、Response/Incident/Notification及证据。
人工兜底： 客户端断线可查原结果；无权限给可理解的拒绝；监控无数据保持未知；通知失败、无人接手或核验未过保留责任并升级。
完成判据： 上述真实客户办理跨端实接；非业务监控响应链完整，重复观察不重复建同一事件；告警恢复、投递、接单和源结果独立；开发Fixture隔离。
当前经营边界： 此时可管理客户和运行状态，尚不能售卖生鲜；后台结构继续保持全局管理与单客户下钻。
需收口的政策： D-07责任/等待预算和D-15本轮检测/响应范围；正式运行人员在启用前落实。
W3｜能上架食材，能安排餐桌
完成后的能力： 商品规格/内容、首页、供给质量、物料账与可信可用性可维护；履约能力有版本；顾客可保存个人菜卡和餐次计划；通用自动化能核验非业务动作。
共同业务演示： 后台维护商品规格 → 登记一批真实来源食材并按证据放行 → 发布内容 → 小程序浏览/选规格 → 保存周三和周五餐次 → 员工在该客户视图看到相同草稿。批次隔离后可用性变化，保存的生活意图保留，未来购买须重新校验。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-MEDIA-ASSETS 业务媒体与用途资产 |
后台媒体维护与受控引用；各端消费同一可用性/发布依据 | W1文件能力真实可用，媒体purpose/版本/缓存失效 |
| REQ-DW-HOMEPAGE-CONTENT 首页内容编排与发布消费 |
后台草稿/预览/发布/回退，小程序同源首页，控制中心发布异常 | 快照/引用/发布代际与媒体/商品合同；同源预览 |
| REQ-DW-CATALOG-PUBLICATION 商品规格、内容与发布 |
后台商品/SKU/规格/发布，小程序发现与详情，控制中心发布异常 | SKU/规格/内容版本和顾客摘要；价格Owner仍Commerce |
| REQ-DW-SUPPLY-QUALITY 供给、质量、物料账与可用性 |
接收/批次/质量/账/更正/可用投影及最小公开追溯，多端同源消费 | Lot/质量/额度/追溯与过期结果；不默认引入仓位WMS |
| REQ-DW-FULFILLMENT-CAPACITY 最小履约能力事实 |
Fulfillment维护可承接能力版本；后台核对，Demand后续消费，控制中心数据质量 | 原始能力与Demand承诺的区别；降低能力不删已接受承诺 |
| REQ-DW-MEAL-PLANNING 个人菜卡与餐次计划 |
顾客集中编餐次，后台有权协助编辑草稿，保留历次购买引用 | 计划/餐次稳定ID与编辑版本、商品引用、购买来源；不等于订阅 |
| REQ-DW-CONTROLLED-AUTOMATION 通用受控自动化 |
控制中心套餐/预算/授权/互斥/UNKNOWN/中止/独立验证；先非业务动作 | Runbook/动作连接器/原目标查询/验收；业务接入随各wave完成 |
进入本轮： W2真实基础工作面、权限和通用监控/响应；先发布本waveSKU/媒体/Lot/餐次/能力契约。
先统一的事实： SKU/SpecVersion/Publication、FileAsset/HomepageSnapshot、Lot/质量/物料账、履约能力、PersonalRecipe/MealOccurrence；通用Runbook另有独立事实。
人工兜底： 处理资源/发布失败、过期可用量、质量待核验、计划并发编辑；质量决定和物料更正有证据与授权。不能修改已成交快照。
完成判据： 从建品/到货/质量到顾客浏览和计划保存实接；缺失/过期数据不视为充足；版本和权限一致；通用自动化先以非零售动作证明受控执行。
当前经营边界： 计划是生活意图，尚未形成购买/付款/配送授权；商品可浏览不等于可对外收款。
需收口的政策： 规格/发布/质量/物料规则、D-09质量接缝、D-15受控自动化范围；静态推荐内容不启用个性推荐。
W4｜能购买并明确安排未来配送
完成后的能力： 服务端报价/权益、按日期地址拆单、购买批次、支付验真、原款分配/最小退款，以及独立逐次配送确认/费用/到期。
共同业务演示： 顾客核对周三/周五餐次 → 获取不可变报价 → 按日期/地址形成订单集合 → 一次付款验真 → 提前确认周三时间、费用与地址 → 周五一直未确认，在配送日默认北京时间16:00由权威记录裁决到期 → 后台分别看到周三已确认和周五不配送，以及各自真实资金结果。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-QUOTE 购物意图、报价与权益 |
小程序肉篮/报价，后台价格/权益/分摊管理，控制中心报价异常 | 冻结报价、有效范围/期限、整数计价与权益占用；D-04 |
| REQ-DW-ORDER-BATCH 拆单、购买批次与商业接受 |
小程序核对购买，后台同源订单/谱系/批次，控制中心商业协调异常 | 购买来源唯一性、日/址拆分、快照、商业终态、资金/授权接缝 |
| REQ-DW-PAYMENT-FUNDS 收款验真、分配与最小退款 |
支付、查原款、额度守卫、拒收/退出退回；后台核验，控制中心UNKNOWN | Payment目标/尝试/实收、原款分配/退款、Provider证据；D-05/08 |
| REQ-DW-DELIVERY-CONFIRMATION 每日安排、确认与到期 |
多日提前确认、时间/费用同意、截止配置、授权代办、到期自动关单协调 | DeliveryInstruction/ConfirmationRecord、权威CAS/费用目标；不抢资格，D-01/06 |
进入本轮： W3商品/供给/履约能力、客户与计划真实；W4四个REQ共用报价/购买范围/资金/授权合同后并行。
先统一的事实： PriceQuote、CheckoutIntent/PurchaseBatch/Order/OrderLine、PaymentIntent/Attempt/Transaction、FundingAllocation/Refund、DeliveryInstruction/ConfirmationRecord。
人工兜底： 支付回执丢失查询原目标；客服核验原款；有符合证据范围的客户授权才可代确认；费用已付但确认失败沿原费用目标补偿；UNKNOWN保持占用和核验责任。
完成判据： 报价、订单、原款、授权四个真实适配实接；重复付款/回调、跨客户/越权、确认与截止竞争、费用失败/未知、到期关单和拒收实收的退款出口可验证。
当前经营边界： 具备购买和配送授权的隔离联调闭环；现场切配、交付和实际重量结算尚在W5，不能只凭本轮开放真实售卖。
需收口的政策： D-01计费/时段、D-04计价/分摊、D-05退款时点去向、D-06代办、D-08支付Provider及相关拆分粒度。
W5｜能把一笔正常成交送到家并结清
完成后的能力： 订单执行门禁、数量份额、现场作业/称重、物料分配转换、包裹/交接/交付、实际计价/退差与核算。
共同业务演示： 顾客提前确认的订单 → 作业端核验授权/原款/质量/唯一数量权 → 领料切配并采用实际测量 → 包裹绑定食材批次/订单行 → 双方交接并记录真实交付 → Commerce依据核验事实计算应收/退差 → 原目标退款核验 → 后台账单和Finance来源关联，顾客看到相同交付/资金结果。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-EXECUTION-WEIGHING 执行门禁、作业与实际测量 |
后台/作业端调度和真实作业/称重，顾客进展，控制中心现场未知 | ExecutionGate/数量谱系/fence/停止墓碑/Measurement；D-09 |
| REQ-DW-MATERIAL-TRANSFORMATION 物料分配、转换与追溯 |
分配、领料/损耗/产出、质量/数量守恒与追溯；现场和后台核验 | Supply账及转换、Fulfillment采用事实；不直接改余额 |
| REQ-DW-PACKAGE-DELIVERY 包裹、交接与实际交付 |
封装/标签/交接/配送/部分结果，顾客跟踪及实际Meat ID，后台异常 | Package/追溯绑定/Delivery事实/行数量结果；扫码不等于交付 |
| REQ-DW-SETTLEMENT-REFUNDS 实际计价、退差与批次结清 |
实际重量计价、分项应收/退差、退款查证、批次结清及晚到调整 | 采用重量/交付依据、Settlement/Refund/Adjustment；D-04/05 |
| REQ-DW-FINANCE-POSTING 核算来源、分录与期间 |
后台核算主体/账簿、来源、规则/期间、分录/更正/期初，控制中心遗漏 | 经济来源唯一性、过账/期间门禁、收入解释和冲销；D-14 |
进入本轮： W4已验证购买/资金/授权；执行、物料、包裹、结算、财务五个REQ共享输入/结果合同并行。
先统一的事实： ExecutionGate/ExecutionAllocation/fence、Task/Measurement、MaterialAllocation/Transformation/Ledger、Package/Delivery、Settlement/Refund/Adjustment、EconomicSource/Journal。
人工兜底： 部分交付和现场回执未知保留真实范围；工作人员核验实物/原测量，不重派同份切配；退差未知查原交易；质量阻断不能通过后台标完成绕过。复杂诉求和换菜在W6继续办理。
完成判据： 正常订单钱货闭环实接；数量/资金守恒、质量/开工竞争、设备旧fence、部分结果、退款未知和来源防重验证；成交快照不随主数据改变。
当前经营边界： 正常交易已闭环；完整取消换菜、售后/召回和客服补救尚须W6，不由正常成功路径推出可上线。
需收口的政策： D-04实际应收/超重/舍入、D-09现场门禁/离线/部分结果、D-14核算解释与期间规则。
W6｜临时变化和问题订单也能完整办结
完成后的能力： 取消/换菜/受控改址改时、后继订单与差额、新授权、分项售后/退款补发回收、批次召回、经营分析和客户数据处理。
共同业务演示： 情景一：已确认但未开工，顾客或有授权员工申请换菜 → 停止与开工裁决 → 永久关闭旧执行 → 接受后继报价/资金/新授权 → 后继履约。情景二：部分肉未送或变质 → 按行数量申请/客服代录 → 审定分项方案 → 退款/补发/回收各自核验 → 未结义务收敛后结束案件。情景三：批次召回 → 定位影响 → 拦截/通知/回收/售后逐项追证。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-ORDER-CHANGES 取消、换菜与受控改址改时 |
顾客/后台同源申请，停止与开工裁决、后继/补退差/新授权及续办 | Cancellation/Replacement、永久停止、后继来源、受托证据；D-02/03/06 |
| REQ-DW-AFTERSALES 分项售后与方案执行 |
顾客申请/证据/进度，后台裁决/逐项退款补发回收，作业端恢复任务 | AfterSaleCase/Resolution及下游命令/回执/关闭门禁；复用标准交易 |
| REQ-DW-QUALITY-RECALL 质量召回与传播闭环 |
后台定位批次影响，停止/通知/回收/售后，顾客与现场收到真实结果 | Recall影响范围/传播/逐项证据；R-only依赖同wave售后真实适配 |
| REQ-DW-ANALYTICS 经营口径、数据质量与重建 |
后台经营分析/下钻/受控导出；控制中心消费信号，质量/重算不改源事实 | 指标版本/粒度/水位/来源、构建发布/重算；基本运营视图早期逐域已有 |
| REQ-DW-CUSTOMER-DATA-LIFECYCLE 客户合并、撤回与数据处理 |
小程序提出/查看，后台影响预览/分项办理，控制中心传播失败 | 实际消费者范围、用途/保留/受控合并和删除；D-13未定不开放危险操作 |
进入本轮： W5真实钱货主链；确认取消/变更/售后/召回及客户数据处理的适用规则。
先统一的事实： Cancellation/ReplacementRequest及谱系/永久停止证据；AfterSaleCase/Resolution/逐项回执；Recall影响范围；Metric/质量/重建和客户处理传播。
人工兜底： 冻结后后继失败继续补偿/核验，不复活旧单；退款未知保留原额度；售后部分完成可以续办；未具备受托证据拒绝代确认；客户合并/删除保留资金和追溯义务。
完成判据： 全局后台与客户下钻均能完成上述合法办理；订单/资金/执行/案件结果分开；部分失败有明确续办和实际责任；各指标能回到源记录核对。
当前经营边界： 形成鲜配主业务的功能闭环候选。对外经营还需W7运行准备与W8发布审核；扩展商业模式按各自条件启用。
需收口的政策： D-02/03部分取消/费用/改址改时、D-06受托证据、D-07责任、D-13数据处理/保留；未决范围不能以管理员例外开放。
W7｜能在生产条件下持续经营和恢复
完成后的能力： 真实生产拓扑/权限/密钥/环境、切换与软件回退、SLO/容量/保留、备份/灾备、真机/辅助技术/兼容及独立外部兜底。
共同业务演示： 一次退款发出但回执丢失 → 服务中断并触发独立告警 → 按恢复方案恢复持久记录 → 向原Provider查原目标 → 保留原预留并核验结果 → 后台明确尚未结清的对象和接手责任；同时验证备份恢复不会二次退款/切配。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-PRODUCTION-INFRASTRUCTURE 生产拓扑、安全与环境固化 |
真实拓扑/权限/密钥/迁移与部署回退方案；供应商实接证据 | 已选业务范围及版本；不能直接继承旧五发布单元或develop默认 |
| REQ-DW-PRODUCTION-VERIFICATION 运行目标、恢复、负载与兼容 |
SLO/容量、备份/灾备、外部探针、真机/辅助技术、故障与对账演练 | 已批准目标、实际负责人和候选环境；环境硬依赖单列F边 |
进入本轮： W6核心办理范围；实际Provider/设备、生产环境权限、运行人员和目标获批准；W9/W10扩展已选部分另纳入该候选验证。
先统一的事实： 候选软件/配置/Schema/Client版本、数据切换水位、原操作引用、RPO/RTO/SLO与值班责任、恢复日志和外部核验。
人工兜底： 平台失联仍有独立探测/通知链；源Owner保留执行门禁；明确实际接手/升级和停止危险写操作；软件回退不回滚现实资金/物理效果。
完成判据： 在精确候选环境中通过批准的安全、隔离、容量、真机、兼容、备份恢复及故障目标；真实负责人/预算和外部接入证据齐全。
当前经营边界： 这是运行与恢复能力完成，发布交接由W8审定；不能把测试环境模拟当正式Provider/现场验收。
需收口的政策： D-07/08/09真实责任与能力、D-11迁移/恢复、D-15平台容量/隔离/灾备；生产范围与数值目标须正式确定。
W8｜把鲜配核心闭环交付为可发布版本
完成后的能力： 锁定精确兼容的需求/合同/模型/Client/代码/配置/迁移和运行证据，形成可审查、可交接的鲜配核心版本。
共同业务演示： 一位顾客安排多日餐次并购买 → 提前确认各次 → 正常交付并按实际计价；另一日期未确认到期；一项临时变更/售后由后台合法接住 → 所有资金与实物结果可查 → 管理者核对当日全局和该客户 → 控制中心追查并核验异常。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-INTEGRATED-RELEASE 精确候选验收与发布交接 |
固定已启用REQ/模型/Client/配置/迁移/运行证据，完整审查并到人类网关 | 前置实际结果及完整S7证据；候选变化不能只刷新摘要 |
进入本轮： W7运行证据和所有候选范围的有效完整验证；冻结本次实际启用的业务能力。
先统一的事实： 精确候选清单与有限验收库存、有效完整S7轮次、残余风险/Owner、恢复与发布交接包。
人工兜底： 核对每类人工干预有真实办理出口和权限依据；所有未结义务有责任与恢复路径；验收失败回对应Owner修复并重新完整验证。
完成判据： 精确候选与全面证据满足项目验收/发布审计，进入人类发布网关；部署/发布另执行明确授权。
当前经营边界： 核心版本可以先完成，不需等待全部订阅/团长/推荐商业模式。已实现不等于已发布，未授权不对外宣称运营。
需收口的政策： 实际发布范围、批准人、残余风险责任和运行交接必须明确。
W9｜扩展外部销售和增长获客
完成后的能力： 外部渠道观察/绑定/导入/回传/对账、团长资格/活动/同账号门户、受控分享/落地与归因；全部复用核心订单/资金/授权/履约。
共同业务演示： 员工审核团长资格并发布活动 → 生成有用途/有效期的分享来源 → 顾客参与形成标准购买 → 后台沿原订单核对来源。另一路：外部订单观察经验证接受 → 创建同源内部业务 → 内部履约/售后结果回传 → 对账差异按原目标追查。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-GROUP-CAMPAIGNS 团长资格、活动及门户 |
资格/活动、同账号门户隔离和多端办理；不另建订单中心 | Portal/活动/参与身份与标准交易引用；D-12与实际导航精化 |
| REQ-DW-SHARE-ATTRIBUTION 分享来源与获客归因 |
受控分享/落地/来源证据，后台归因核对，控制中心滥用与质量 | 分享令牌/用途/有效期/归因；与活动合同先收敛，活动实现与归因实现并行，不能改交易来源 |
| REQ-DW-EXTERNAL-CHANNEL 外部销售渠道协作 |
授权/能力/绑定/观察、导入/回传/售后/账单与后台受控重放 | Provider证据/内部接受/原结果查询；旧小红书名不等于已启用供应商 |
进入本轮： 功能设计/实现依赖W6；不需要等待W7/W8执行完才准备或并行开发。上线须纳入一次完整运行验证与发布审核。各渠道/增长政策先批准。
先统一的事实： Campaign/Qualification/Participation/Portal、ShareToken/Attribution、Channel能力/凭据/Observation/Binding/Cursor；内部标准交易引用。
人工兜底： 未知外部状态隔离；重放不再造内部订单/退款；外部结果未知查原请求；门户无资格拒绝且缓存隔离；未批准佣金不从活动入口默认产生。
完成判据： 每个实际选中扩展与核心真实链路实接，撤权/重复导入/回传未知/隐私边界和来源唯一性验证；未选扩展保持未启用。
当前经营边界： 渠道、团长、归因可并行，彼此没有默认整REQ串行前置；功能完成还需自身完整验收和对应版本的运行/发布审核。
需收口的政策： D-12活动/增长启用，真实Provider能力/权限，分享用途和归因窗口；如有佣金另定Owner/核算范围。
W10｜扩展持续服务和选购决策
完成后的能力： 经批准的服务合同/权益/周期标准出单/暂停退出，以及有同意、解释、规则版本和实验依据的引导选购/个性推荐。
共同业务演示： 顾客审阅批准的合同/费用/用途 → 明确签约 → 周期权益产生标准出单意图 → 支付和配送授权分别成立 → 履约结算；暂停只影响未来范围。推荐场景：明确同意 → 生成有解释的建议 → 顾客调整餐次/商品 → 交易时重新校验价格/供给。
| REQ / 模块 | 本轮完整交付范围 | 共用事实与并行边界 |
|---|---|---|
| REQ-DW-CONTINUOUS-SERVICE 批准后的持续服务 |
合同/权益/周期标准出单；小程序维护、后台异常、控制中心恢复 | 计划型购买不自动继承订阅；D-12批准后启用，复用W4/W5 |
| REQ-DW-RECOMMENDATION-DECISIONS 引导选购、推荐与实验 |
规则/同意/决策/实验，小程序解释与标准购买，后台模拟/发布 | Owner/用途/候选/版本/实验口径；静态推荐与个人计划早期已独立交付 |
进入本轮： 功能依赖W6核心能力/经营口径、个人计划和同意；可与W9并行开发，持续服务与推荐互不等待。商业政策与推荐Owner先明确。
先统一的事实： ServiceContract/Entitlement/Cycle及业务来源唯一性；Preference/Consent/RuleRevision/Decision/Experiment；标准交易与每日授权。
人工兜底： 周期失败查原意图，不重复消耗权益或收款；取消既有订单走核心机制；同意撤回阻止新越权决策；无候选/规则失效提供可理解的人工/自选出口。
完成判据： 每个选中模式与核心链路真实联调；周期唯一性、暂停/退出、支付/授权独立、同意撤回、规则/实验发布回退和异常恢复可验证。
当前经营边界： 个人周计划在W3–W6已经完成；本轮只启用经批准的持续合同和决策能力。部署前同样追加运行/完整验收和人类发布审核。
需收口的政策： D-12合同/周期/扣款授权/推荐启用、D-13用途/保留及推荐Owner，实际费用/失败恢复与实验规则。
4. 怎样判断某一轮确实增长了能力
每个wave固定一个有限业务库存：这轮新增哪些顾客任务、管理任务、现场任务、自动动作与异常出口。用以下共同验收清单判断完成，不以合并数量或某端页面存在作为替代。
| 必须证明的内容 | 判定方式 |
|---|---|
| 新业务能完整办理 | 按本轮“共同业务演示”从输入到结果实接；操作者能看清当前事实、能执行什么、完成后结果在哪里 |
| 顾客与后台同源 | 小程序操作后，全局管理/客户下钻读相同ID、版本、金额和范围；后台合法办理后顾客看到真实结果 |
| 现场事实可核对 | 涉及钱/货时采用核验后的渠道/现场事实；任务受理、设备ACK、扫码、付款回跳各保留自身含义 |
| 用户做不了的事有人能办 | 受托证据/权限清楚；人工可查询原结果、核验、合法更正/继续/升级，覆盖必要的分项与未完成义务 |
| 控制中心能接住异常 | 所需源信号/质量、检测策略、事件/响应责任、回源验证及独立平台故障兜底可查；告警关闭不伪造业务完成 |
| 竞争和恢复不会重复效果 | 重复/异载荷、版本冲突、撤权、截止/开工竞争、乱序/迟到、UNKNOWN、部分成功、重启及适用的迁移/回退逐项验证 |
| 前轮继续可用 | 在精确汇合版本回归此前真实能力；Stub只用于尚未实现能力的隔离开发，不能作为本轮闭环证据 |
基础轮次W0/W1如尚无可用业务页面，验收明确只覆盖工程/领域接口能力。后续业务轮次必须有可办理工作面和跨端实际结果，不能把前轮的接口证据累计成“客服全部工作已经支持”。
方案与原型按模块设计规则逐项推导必要性和使用习惯；后台当前功能库存还需逐REQ核对。这里列出的41个候选REQ不证明完整FR/AC/CASE、82页所有动作或全部商业模式已经完成细化。
5. 同Wave如何独立开发并立即联调
同wave先提交和审查共同Schema/SYNC、操作/事件、合法/结构样例、业务反例、生成Client和框架接口。REQ分支只读相同原生定义，分别实现自己的事实/模块/适配；已满足条件的真实实现尽早集成，wave出口才核对全部所需真实链路。
| 依赖类别 | 如何安排 |
|---|---|
| 公开契约 | 在本wave开发前共同收口；消费者据此独立实现，不等待提供者整份REQ验收 |
| 必须存在的代码/环境 | 放上游wave；确有同wave依赖就记录最小交接TASK和验收，相关TASK等待，其他独立任务继续 |
| 联调所需真实结果 | 两边可并行实现，出口必须以真实适配共同验证；Mock成功只能证明隔离协议行为 |
| 验收证据 | 绑定同一精确集成版本；各REQ通过和wave业务闭环分别判断，不能简单相加多个PASS |
例如W4报价、订单、原款、每日安排四个REQ并行；W5执行测量、物料转换、包裹交付、实际结算、财务核算五个REQ并行。共用购买旅程的页面根与组合由明确Owner合入，其他REQ交付独立组件/数据接口；公共Schema、Client、导航、lockfile、数据库迁移顺序和共享环境由队列Owner统一维护。
生成Client和实际框架须在消费方需要它们时已经存在并固定。若SDK实现尚未交付，它是实际构件依赖，不能用“已经有Schema”冒称无需等待。正式S4须展开实际文件/输出/外部资源并审查同wave重叠；本轮未创建产品目录或执行分支。
各REQ使用自己的绑定开发分支、权威checkout及Runtime；单个Runtime绑定一个REQ，不限制项目跨REQ并行。TASK成果回所属REQ，REQ成果通过已授权的开发集成进入显式指定的共同集成分支；最终发布上游另行明确，不默认develop/main。REQ主工作区之间不共享/复制活跃Runtime、journal、锁、冻结输入和凭据。
当前工作区协议的实际证据覆盖单REQ Main与Worker。多REQ主工作区并发的控制面/Hook/证据隔离须在执行前验证，不能把Git分支自动视为Runtime隔离。共享定义变更走设计/合同队列和变更控制，受影响消费者重新审查，集成分支不补第二份DTO。
Wave是规划/集成里程碑，REQ内部TASK waves-v1仍按自身阶段执行；本文不改变Runtime状态机或锁定/发布权限。每个REQ与最终候选仍需现行完整S7/S10/S11；W7/W8的运行/候选检查也适用于之后每个实际发布的扩展版本。
6. 深化入口与当前责任
当前已补齐三个深化入口：
- 41个REQ范围卡：每REQ的目标、触发/办理、必要功能、跨端工作面、Owner/目录、出口判据、异常和交接。
- 业务模块与工程目录：十个业务域与Platform、全局后台/客户下钻、拟建代码路径、公共源与生成输出归属；归因/推荐待定Owner如实保留。
- REQ执行计划：从规划到正式需求、同wave契约/构件/实接依赖、共同页面Owner、分支/Runtime隔离、持续联调与验收。
这些范围卡深化了11个wave、41个候选REQ的能力层次，不是人类已经确认的41份正式REQ。正式全量FR/AC/场景、原生业务Schema/合同、文件级write_paths、真实Provider/设备和产品联调仍待逐轮完成。
主会话负责需求/设计提案与有限覆盖库存；各事实Owner维护原生含义/命令；集成负责人组织同wave版本与资源；实际业务/运行/财务/安全/发布负责人须在启用前落实。缺政策/证据/责任时保留对应阻塞范围，不用默认配置或管理员操作抹去未知。
本轮结构检查结果：11个wave分别有2/4/6/7/4/5/5/2/1/3/2个REQ，共41个且ID不重复、归位唯一；每轮均有新增能力、共同业务演示、进入条件、事实、人工兜底、完成判据、经营边界与待定政策；编排及深化文档的本地链接经结构核对。编排中的历史编号/来源映射已移除。此检查不声明业务已经跑通或产品验收通过。共享基线§A仍为draft，本轮没有补写人类批准或锁定记录。