# 小程序运营支撑与后台人工兜底审查

日期：2026-09-29。性质：用户委托的当前设计审查，非 S5 独立评审、S7 全量验证或发布验收。Runtime inactive，无 bound REQ。

**结论：当前后台尚不能完整支撑小程序运营。** 它已经有较完整的领域入口及局部操作，但“发现异常 → 找到同一客户和业务对象 → 合法代办 → 分项执行 → 回源核验 → 用户可见结果”的服务闭环仍有实质缺口。不能用82个工作区、206个按钮或上一版984条局部检查，证明这些闭环已完成。

当前视觉按用户意见暂定；本轮不改视觉、业务模型、政策或原型行为。主会话维护缺口及设计修订，业务政策由用户决定；表中的Owner是职责建议，真实运营、资金、履约、质量及技术负责人尚待指定，不能把领域名称当已到岗人员。

## 1. 审查依据与有限覆盖

### 1.1 本轮实际检查

- 全量提取当前 `catalog.json` 的82个工作区、206个动作、30个创建入口，核对字段、前后状态、角色复核、对象关联及无后续动作的候选状态。
- 阅读共用 `app.js`、完整 `model.js`，重点检查跨模块执行、原请求核验、新建对象、授权与可见结果。
- 回看小程序活动构建入口、周计划/逐日确认模型、“我的”及基础订单/结算/地址/售后源码；浏览器打开4304当前小程序首页。
- 对照一周无忧、付款后陪伴、配送费、品牌经营立场、事实Owner，以及9月29日新增交易不变量/六机职责。旧报告只作问题索引，没有直接沿用旧“缺少架构设计”的结论。
- 执行10组内存级合成反例，并用4项对照确认只读、超额退款、不齐回执和非法选项的已有拦截；独立浏览器实际走“订单列表 → 陈先生订单 → 取消 → 核对 → 无后续动作”，查看客户详情。没有改用户已有浏览器记录，没有发起真实资金/外部动作。
- 形成下方36条服务结果盘点及82页附录。**不是逐页执行82页所有分支**，也未跑全量回归、真实支付、真实设备、微信真机或多端后端联调。

证据：[定向探针与全目录提取](evidence/ADMIN-2026-09-29-operations/probes.json)、[可复现探针](evidence/ADMIN-2026-09-29-operations/probe.mjs)、[浏览器观察](evidence/ADMIN-2026-09-29-operations/browser-observations.json)、[输入指纹](evidence/ADMIN-2026-09-29-operations/inputs.json)。探针只证明当前原型行为，不能上升为生产事故结论。

### 1.2 权威及成熟度

|依据|用于判断什么|成熟度与边界|
|---|---|---|
|[DOMAIN](../../architecture/05-domain/DOMAIN.md)、[一周无忧](../../architecture/05-domain/WEEKLY-CARE-PLAN.md)|纯线上、同一事实、先付后逐日主动确认、未确认不送、两小时免费边界|业务原则明确；精确政策仍有待决|
|[经营设计立场](../../design/brand/design-philosophy.md)、[周计划体验](../../design/prototypes/customer-miniapp/weekly-plan-experience.md)|用户少操心、允许变化、钱与结果可解释、按需备货|体验方向；不是实际履约证据|
|[付款后陪伴](../../design/prototypes/customer-miniapp/post-payment-care.md)、[确认与费用](../../design/prototypes/customer-miniapp/confirmation-window.md)|提醒、费用、变更、退出、异常及一致记录|包含预填值及待决项，不能自动冻结|
|[交易严谨性](../../architecture/08-domain-model/TRANSACTION-INTEGRITY.md)、[状态职责](../../architecture/state/FRESH-DELIVERY.md)、[周流程](../../architecture/05-domain/WEEKLY-CARE-FLOW.md)|终态不可逆、关联新单、资金分配、执行权、自动结算与恢复|当前候选架构；政策/guard未生产实现。自动差价退款时点等是拟议方向|
|[事实归属](../../architecture/07-bounded-context/OWNERSHIP.md)、[一致性](../../architecture/08-domain-model/CONSISTENCY.md)|Owner、门禁、组合查询、跨域回执|设计约束，不把读模型当权威写入|
|[后台目录](../../design/prototypes/admin-console/workbench/catalog.json)、[跨模块故事](../../design/prototypes/admin-console/CROSS-FLOWS.md)|当前入口、动作与声明|本地合成原型，不等于实际跨模块闭环|

新架构已经补上许多旧报告指出的对象和协议，当前问题主要是**它们尚未落入后台办理设计和两端共同场景**。后续若否决某候选政策，应调整对应提案；已明确的主动授权、资金真实性和终态约束不能因此退回人工改状态。

## 2. 完整支撑的判定标准

一条运营服务必须同时回答七个问题，才能记为“可完整办理”：

1. **发现**：用户求助或系统异常怎样进入队列？是否有等待时间与未接手提示？
2. **定位**：是哪位客户、哪次购买、哪些餐次/订单行、哪个配送尝试、哪笔原款？
3. **授权**：谁提出、谁代办、授权何时取得、允许改哪部分、金额及有效期是什么？
4. **判断**：当前真实进展及可办范围是什么？拒绝时能说明原因与替代方案吗？
5. **执行**：调用明确业务动作，显示责任方、步骤、部分成功及失败后的去向。
6. **核验**：回源取得支付、停止、交付等证据；查不到保持未知，不能人工宣称成功。
7. **交代**：工作人员与用户看到同一结果，未完成事项仍有责任人、期限和继续入口。

仅有查询、文字备注、通用证据框、跳到另一个模块列表，最多记“部分”。缺政策记“待决”，不能记“完整”或悄悄默认允许。正常自动流程不应依赖员工每天逐条点击。

## 3. 主要发现（按业务风险排序）

P1：在相应运营闭环成为可交付设计前必须补齐。P2：配套经营能力或范围待决；若首发仍展示相应承诺，也必须先补齐或明确收窄。以下均为设计/原型问题，无生产P0判断。

### G01 · P1 · 缺少按客户、购买批次和餐次贯通的服务视图

- **证据**：`customers`详情只有联系方式等4项摘要，样例 `links={}`；浏览器显示“暂无已核验的对象关联”，下方跳的是全量模块列表。顶部搜索只查功能标题/描述。订单部分样例虽有精确链接，仍无同客户聚合。
- 小程序 `study-mine.tsx:39`明确新周计划与旧订单/售后两套记录未合并；`study-week-model.mjs`与后台使用不同本地数据。单凭“未接后端”不判原型失败，但共同业务对象及用户回看路径必须先设计。
- **后果**：用户说“这周少送一餐，钱在哪里”，客服必须人工拼姓名/日期，不能可靠定位金额及后续；跨端办理后的可见结果无证据。
- **补齐**：客户服务台按受权标识检索，串联购买批次→餐次→旧/新单→授权→执行→原款/退款→服务事项；保留每域来源时点及局部不可用。两端共用一组可追踪场景数据，不要求原型接真实后台。
- **完成反证**：同名客户、一天多餐、多地址、部分投影延迟仍能定位准确；查不到不能显示未支付并催付。Owner：Customer组合视图，Commerce/Demand/Fulfillment提供事实。

### G02 · P1 · “协助客户”尚未形成明确的受托办理机制

- **证据**：`plans`只有服务备注，`personal-cards`只有问题记录与关闭；`addresses`只有更正文本及证据。`orders.change`、`confirmations.accepted`把客户依据作为文本，没有代理主体、授权范围、有效期、内容版本及客户核对回路。
- **缺失故事**：用户不熟悉操作、账号暂不可用、设备损坏、临时由客服帮改地址/改时间/提交补救。登记备注不能完成这些请求。
- **补齐**：明确“代填草稿→客户核对并授权→受控提交→双方回执”；不能操作小程序的特殊用户另设计身份核验与获准的替代授权方式。是否接受电话/其他渠道授权须业务定案，本轮不认定录音或工作人员说明自动有效。
- **边界**：允许协助不等于默认确认、代扣款或改过去的授权时间；不能假扮客户登录。原确认的核验与新取得的受托授权要分开。Owner：Customer服务、Demand授权接受、Commerce变更，Identity保护动作权限。

### G03 · P1 · 取消/改址/改期可能走入“待人工处置”，但没有办理出口

- **证据**：`orders.cancel/change → …处理中 → check → 待人工处置`无出边。P01及浏览器B01复现；没有新增协调事项，`changes`条数保持3，原配送状态也未改变。其不直接改配送是正确的Owner边界，但必须创建/关联实际协调请求。
- `changes.recover → 恢复处理中`同样没有继续动作；已有原始样例并不能承接新请求。
- **补齐**：从订单发起结构化变更，选择受影响行/日期及目标地址/时刻，预览可停止性和影响；建立唯一协调编号，逐步显示停止、承诺、授权、资金回执。拒绝/失败保留真实现状和下一步，不能把“已登记”当办理完成。
- **完成反证**：取消一餐不改其他日；开工先成功走受控处置；关闭旧单后不能复活。Owner：Commerce协调，Demand/Fulfillment回执。

### G04 · P1 · 换菜/改量缺少前驱—后继订单和差价流程

- **证据**：`substitutions`已有提案、客户决定、价差和结果动作，是可复用基础；但“替代商品与规格”是自由文本，未选订单行/数量，无冻结/永久停止、后继订单、原款分配、补款、便宜差额、失败补偿及新授权。`orders`无创建入口，通用执行也不生成后继对象。
- **补齐**：沿同一餐次展示完整替换案件；旧单永久终止后建立关联新单，明确原款何部分可用，差价和费用分列；新授权对应新内容。价格/份量和允许阶段待政策定案。
- **完成反证**：原款已被退款预留时不能承诺仅补差；补款成功新单失败不能复活旧单；开工事实未知不能重新切一份。Owner：Commerce，协作Demand/Fulfillment/Supply。

### G05 · P1 · “本次不送后恢复”沿用原ID，与新终态设计冲突

- **证据**：P02：`CONFIRMATIONS-003`由“本次不送”变“待客户确认”，没有新的安排身份。`study-care-flow.mjs:10`也接受`skipped`原记录，当天直接变`delivering`。
- **判断限定**：不是说任何暂停对象都不能恢复；问题是本次到期决定、原订单是否终态没有区分。新架构要求到期安排不可复活，原型这条路径无法解释新旧身份和执行资格。
- **补齐**：保留旧结果；“重新安排”建立新尝试，按原订单是否终态及资金状态确定是否关联新单，再取得本次授权。界面不要求客户理解多个内部对象，后台要能查清谱系。
- **完成反证**：旧确认/付款事件晚到不重新执行；原款退款未知不能再占用。Owner：Demand/Commerce/Fulfillment。

### G06 · P1 · 收退款核验被简化为人工填写成功，UNKNOWN没有完整出口

- **证据**：[model.js:70](../../design/prototypes/admin-console/workbench/model.js)的`resolvePending`只要非空证据便迁移到原目标状态；无“仍未知、核实失败、金额/对象不符、相反证据”结果。P05：尚无外部流水的待收款记录可凭文本变“已验证”；P06复现UNKNOWN单一路径。
- **可保留**：原请求ID、退款整数分额度、未知保留占用、独立复核已有局部设计。
- **补齐**：展示原目标、渠道/尝试、核验结果和可信回执；“查询”不等于“确认成功”。确定失败后的合法重试/释放、仍未知的下次查证及升级、终态相反证据另立差异。原型也应有这些分支，不只写“以后接API”。
- **完成反证**：重复回调、断网、迟到成功、员工撤权均不能重复收退；成功与来源摘要矛盾必须可见。Owner：Commerce资金及受限恢复服务。

### G07 · P1 · 留存、购买批次结算、自动退差和退出办理未闭合

- **证据**：`retained`止于“退出待评审”（P08）；82页目录未见PurchaseBatch、资金切片/分配、结算运行、结算更正工作区或对应详情。`reconciliation`是账单匹配，不等于批次结算；Finance总账也不能替代运营资金账。
- **补齐**：按原交易列实收、占用、实际消费、待结算、退款预留、实退及限制；自动结算任务可追踪，正常结果自动推进，异常接手。整周/部分退出受理后有裁决、执行、回执及用户结果。
- **政策待决**：批次结束、称重/优惠/配送费分摊、自动退款时点、无争议部分先退、原路失败替代路线。最新架构的自动退费是拟议方向，不能写成已批准随时退款或已实现钱包。
- **完成反证**：结算与换菜竞争、部分未知、结清后晚到事实，不能双退或重开已关闭批次。Owner：Commerce资金；Finance消费经济事实。

### G08 · P1 · 每日确认与费用承接缺少同一次请求的完整办理链

- **证据**：`accepted`只输入同意、期望时刻和回执选项，未绑定安排版本/地址/具体行数量/费用目标；`tariffs`止于“待业务确认”，无政策生效/失效与报价溯源。试算函数`fee()`只接受时分，跨日返回负提前量（P10）。
- 草稿¥3改¥5后正式试算不变，本身**不是缺陷**（草稿本就不应立即生效）；缺口是没有受审生效版本供正式报价引用，也没有独立提案试算说明。不可用“改了参数”证明两端已一致。
- **补齐**：客户选择→版本化报价→授权/费用核验→服务接受→执行资格，逐项可查；收费成功而确认失败、跨档、时区/跨日、商家延迟和改时的恢复或补偿路径。
- **完成反证**：两小时边界不是关单；选中时间/费用已付不等于已接受；当前不应由经办人填写“齐全”越过门禁。Owner：Demand/Commerce。

### G09 · P1 · 缺少以经营结果为中心的监控和自动流程兜底

- **证据**：`monitor`主要是服务/队列3条样例；首页是静态日期和按样例状态计数。`jobs`只有配置、启用、暂停；`confirmations.skip`是人工动作。没有未确认到期补扫、确认已接受却未派生任务、结算超时、无人接手、原款UNKNOWN年龄等业务队列。
- **补齐**：正常到期/结算由系统执行；后台按“风险/超时/金额/负责人/日期”归集异常，显示最后成功水位、影响对象、自动恢复尝试和下一步。任务技术成功后回查业务结果。
- **边界**：待确认但未到期是正常业务，不全部报警；客户拒绝提醒不应被持续催促。监控阈值和接手时限须指定，不在本审查随意设数字。
- **完成反证**：客户没打开应用、调度宕机重启、重复补扫、只部分成功都能发现并恢复。Owner：各业务Owner，Platform提供调度/工作索引。

### G10 · P1 · 作业、质量和停止依据仍可用自选字段代替权威门禁

- **证据**：`guard('gates')`只检查表单是否选择“依赖已齐全”。P03：质量隔离任务改派后选齐全即进入执行，质量源没有变化。`packages.seal`同样依赖自选门禁。
- **补齐**：现场工作台只读展示当前授权、质量/物料、依赖、执行范围与停止结果；经办人发起核验，不自己宣告它们成立。给质量隔离、开工未知、停止在途、部分已切配独立处置入口和证据。
- **完成反证**：隔离不能靠改派解除；离线旧任务/旧标签不能开工；现场发生但回执丢失先查实物不重做。Owner：Fulfillment执行，Supply质量与物料。

### G11 · P1 · 售后/补送/回收有方案，却缺实际派生与分项办理

- **证据**：`aftersales`有方案、复核、关闭，这是基础；但批准不产生关联退款、补送新单或回收任务。`refunds`无创建入口；`returns`只对种子记录派发/接收。P09可选“全部回执齐全”关闭售后而关联源未核验。
- **补齐**：按订单行/数量选择少件、品质、重量、切法、配送问题；生成独立退款/补送/回收目标并逐项跟进，必要检验/处置不丢失。客户可见方案与实际执行分别表示。
- **完成反证**：一个包裹少一件不能整单重送；重复售后不双退款；退款完成通知失败仅重投通知；已完成原单不复活。Owner：Commerce售后，Fulfillment/Supply执行。

### G12 · P1 · 异常与交接能“关单”，不代表源业务已恢复

- **证据**：P04异常“退款查询超时”能关闭，`REFUNDS-002`仍未知；`handoffs.close`只收文本证据。`service-cases.close`明确是“沟通已完成”，但无同时突出“业务仍待办”的统一服务汇总。
- **补齐**：工作事项与源事实分别收尾；只沟通完成不能撤掉退款恢复责任。每个案件有当前个人/岗位责任、下次动作、期限、交接接收、升级和关闭依据；源未恢复则保持待办或明确转出到接收者。
- **完成反证**：员工离职/轮班、无接收人、回执不全、查证仍未知时不丢案；通用异常台只能调用受控恢复动作。Owner：Platform工作索引，源领域决定完成。

### G13 · P1 · 新建记录及种子关系不足以支持真实联办

- **证据**：`perform`新建时`links={}`且摘要全“待核对”。P07新增售后选择了ORDERS-002，但仅保存在fields，没有关联导航/摘要。`detail()`以`id.split('-')[0]`推导页面，带连字符的`SERVICE-CASES-*`、`PERSONAL-CARDS-*`等类型不适用，不能作为统一引用协议。
- **样例反证**：REFUNDS-001标题/显示原交易是排骨取消及PAY-…03，却链接PAYMENTS-001（林女士¥186）；额度初始化又为¥92。PACKAGES-001说任务已验收，但链接TASKS-002仍执行中。周女士客户范围城北而订单/留存样例城南，缺少解释跨范围协作的依据。
- **补齐**：使用显式对象类型、稳定ID、范围及关联来源；新建时建立合法引用与摘要，检查权限，客户/原款/物料/金额可追踪。合成数据也要内部自洽，跨范围共享需显式规则。
- **完成反证**：从新建案件而非预制样例开始，能完整走到退款/补送与客户回看；不能靠手抄编号。Owner：主设计会话维护样例，各事实Owner定义引用。

### G14 · P1 · “按需备货、不留隔夜、明日鲜讯”缺少经营支撑链

- **证据**：当前小程序首页实际显示“明早7:30到店”“按需备货，不留隔夜”。`content`只编辑标题/文案，`receiving`从实际接收开始；`supply-capacity`只发布能力。目录没有分日期/部位/切法的需求汇总与备货计划、预计到货→实际异常→鲜讯更正、日末剩余处置的明确办理链。
- **补齐**：分开草稿意向、已付未确认、已确认需求，生成可解释备货建议并人工承接；关联预计/实际供给、到货短缺/隔离、替代或告知。鲜讯有业务日、依据、有效期、撤回/更正及受影响客户；剩余处置有证据。
- **边界**：采购准备不授权订单级切配；不要求先建设完整采购/WMS；具体隔夜/损耗政策需运营定案，不凭文案制定食品安全标准。
- **完成反证**：大量不确认、临近新增、到货延误、临时下架时，承诺与顾客页面都能更新。Owner：Supply经营准备，Demand需求，Catalog发布。

### G15 · P2 · 商品规格、个人菜卡与推荐能力的支持粒度不足

- **证据**：`products`单组克重/切法，`recipes`单SKU映射；当前菜卡模型支持多关联商品和文字备忘。`personal-cards`只登记问题，缺SKU失效/规格变化对未付餐次与已付快照的不同处理。家庭偏好/下周建议/收藏/积分部分仍是基础源演示。
- **补齐**：合法规格组合、份数/人数、多SKU映射、商品停售影响名单、替代建议与客户接受；保留私有菜卡和已付快照。工作人员协助修复要限定范围，不擅改客户全部菜卡。
- **范围待决**：积分兑换、推荐规则、增长与团长佣金Owner/首发承诺；已有优惠权益不等于积分账本，持续服务合同不等于免费建议开关。
- **完成反证**：备忘“少盐”不变采购项，改模板不修改已付明细，下架历史仍可查。Owner：Catalog/Customer，增长决策待定。

### G16 · P1 · 提醒和外呼缺少授权、直达与失败后接手闭环

- **证据**：`confirmations.remind`只修改原记录并记事件，不产生通知目标；`notifications.send`可从待发送直接到“已送达”，无已受理/已送达/无法确认区别；通知创建只有主题、对象文本和原因。
- **补齐**：按有效用途/渠道同意发送，绑定安排ID和版本；旧链接查最新事实；成功确认后停止旧提醒，退订不影响服务。失败可进入合法人工联系队列并记录结果/拒绝联系。
- **完成反证**：推送失败或未读不能转为同意、不能影响到期停送；退款成功而消息失败不得重退。真实微信通知能力待外部专项验证，本轮未宣称可接入。Owner：业务意图Owner + Customer授权 + Platform投递。

### G17 · P1 · 配送异常、部分交付、追溯与回收处置仍不完整

- **证据**：`deliveries`只有出发/送达/异常/同记录再次安排；无逐包裹部分签收、拒收、失联、错送、终止尝试后新尝试的明确设计。`packages`交接后无接收动作；“绑定受阻”无本页恢复动作，异常回执也不推进原包裹。回收“已接收”后缺质量判定/报损/物料处置路径。
- **补齐**：异常类型驱动可办方案和客户决定；保存每次尝试、实际交付数量、未交部分去向、费用责任与证明；扫描/补打标签不算交付。追溯缺失/撤回与召回需按影响对象逐一处置、核验下游，不只写总数。
- **完成反证**：一单多包、部分送达、派送员失联、客户否认收货、批次隔离、返回物料不可再用，均不重置实际事实或重复派送。Owner：Fulfillment/Supply/Commerce售后。

### G18 · P1 · 岗位、边界权限、双人复核与审计尚不能支撑真实代办

- **证据**：所有动作主要检查operator/reviewer/readonly，非业务角色矩阵；复核以role字符串比较作者而非员工身份。跨域相关对象没有逐一权限/存在性核验；新增记录默认城南。`events`主要记录接受动作，不具备完整拒绝原因、原客户/代办人、前后快照、政策版本与核验来源。
- **补齐**：客服、经营、履约、质量、资金经办/复核、系统运维、只读审计按动作/对象范围授权；金额及高风险决策职责分离，紧急授权有范围/期限/审批。离职撤权不遗弃原义务，恢复用受限主体。
- **完成反证**：只读、错区域、同人不同岗位、撤权后的旧窗口、管理员调用、批量部分失败均受同一门禁；无万能改状态。Owner：Identity及各业务Owner。

## 4. 服务结果覆盖矩阵（36项有限库存）

“部分”表示已有可复用界面/动作，但存在结果级缺口；“缺闭环”表示当前不能从入口办到目标；“冲突”表示与当前明确原则/候选新约束需对齐；“待决”表示范围/政策仍须选择。没有把技术未接入本身等同所有设计失败。

|ID|用户/经营者期望的结果|后台当前落点|审查判断与缺口|
|---|---|---|---|
|J01|找到同一客户全部购买、安排和服务事项|customers/orders/plans|缺闭环：G01/G13|
|J02|不会用手机也能在授权后获得协助|service-cases/addresses|缺闭环：G02/G18|
|J03|直接选肉与计划购买都能被同一客服解释|quotes/orders|部分：G01；旧/新模式界限待决|
|J04|商品克重、切法、数量组合可维护|products/recipes|部分：G15|
|J05|菜卡多食材复用、失效商品可修复|personal-cards/plans|部分：G02/G15|
|J06|一次付款后按餐次核对资金|payments/plans|缺闭环：G01/G07|
|J07|扣款不明时查清，不再收一次|payments/exceptions|部分且核验语义不安全：G06|
|J08|付过但未确认的正常安排不被擅自配送|confirmations/tasks|部分：G08/G10|
|J09|客户不登录，到期自动不送|confirmations/jobs|缺闭环：G09|
|J10|临近确认前知道费用，收费与承接一致|tariffs/confirmations|部分：G08|
|J11|报价跨档/跨日/过期可解释并重新同意|tariffs|缺闭环：G08|
|J12|确认与到期竞争能查权威结果|confirmations/exceptions|缺闭环：G08/G09|
|J13|不送后请求重新安排，不复活终态|confirmations.restore|冲突：G05|
|J14|只取消一餐，有最终结果|orders/changes|缺闭环：G03|
|J15|改地址/时间，已付快照不被篡改|addresses/orders/changes|部分：G02/G03/G08|
|J16|已付换菜改量，只处理合法差额|substitutions/changes|缺闭环：G04/G07|
|J17|缺货替代可拒绝，有其他处置|substitutions|部分：G04/G11|
|J18|已开工/部分已做仍能受控处理变化|tasks/changes|缺闭环：G04/G10/G17|
|J19|未配送的钱找得到、退出能办完|retained|缺闭环：G07|
|J20|范围结束自动核算退差，异常有人跟|reconciliation/refunds|缺闭环且政策待决：G07|
|J21|退款失败/未知/迟到相反证据有出口|refunds/exceptions|部分：G06/G12|
|J22|实称差额有明细、授权和退款依据|measurements/refunds|缺闭环且政策待决：G07/G10|
|J23|确认后作业获得真实授权与质量放行|fulfillment-plans/tasks|部分但可自选门禁：G10|
|J24|封包交接由对方接收，追溯正确|packages/trace/handoffs|缺闭环：G13/G17|
|J25|延误、失联、拒收、错送可补救|deliveries|部分：G17|
|J26|多包裹部分送达，不重送已交部分|deliveries/aftersales|缺闭环：G17|
|J27|质量/重量/切法/少件售后能真正完成|aftersales/refunds/returns|部分：G11|
|J28|召回定位影响客户并核清退款/回收|quality/recalls/trace|部分：G10/G11/G17|
|J29|预计到货、鲜讯、延误更正一致|content/receiving|缺闭环：G14|
|J30|按需备货、日末余料去向可解释|capacity/supply-capacity/lots|缺闭环：G14|
|J31|提醒授权、退订、旧链接和失败有人跟|notifications/confirmations|部分：G16|
|J32|隐私更正/合并/注销不遗弃在途服务|privacy/restrictions/sessions|部分且保留政策待决：G01/G12/G18|
|J33|值班发现异常、认领移交、超时升级|monitor/handoffs/exceptions/jobs|部分：G09/G12|
|J34|工作人员代办可审计且不可越权|roles/authorization/audit|部分：G02/G18|
|J35|经营与财务解释实收、消费、退款和净额|reports/sources/journals|部分：G07/G13；局部过账不证明运营资金闭合|
|J36|推荐/积分/团长等小程序入口有明确运营范围|benefits/leaders/service-contracts|待决：G15；先区分已有承诺与体验示例|

## 5. 人工代办边界：能帮助，不代替客户做决定

|事情|系统正常承担|工作人员可以办理（设计要求）|不得绕过的边界|
|---|---|---|---|
|计划、菜卡、地址|保存本人意图及版本|核验身份后代填限定草稿、发送核对；特殊受托方式待政策|不擅改所有模板，不回写已成交快照|
|每日确认|接收明确授权、费用核验、接受裁决|解释、提醒、查证原确认；按获准方式记录新的受托请求|不能默认确认或把提醒/付款当同意|
|取消、换菜、改期|协调门禁及分项执行|提交客户诉求、解释影响、取得必要授权、处理拒绝/异常|不能删除旧事实、解除终态或静默恢复旧菜|
|收款与退款|可信核验、额度守卫、正常自动结算|查询、受权裁决/复核异常、符合条件的补偿与重试|不能填“已到账”代替渠道结果，不能占用未知资金|
|供给、质量、现场|依赖、份额和执行门禁|录入实际观察，由有权角色接受；隔离、停止、核实现场|不能凭备注解除隔离、重复切配或签收|
|通知、案件、交接|持久排队、路由、重试和超时提示|接手、合法外呼、协调并告知客户、转交接收人|沟通结束不代表资金/交付完成|
|系统故障|补扫、原目标查询、受控重放|限定范围触发恢复、查看拒绝与残留风险|不能通用改业务状态、回档重放外部效果|

每次代办建议最小记录：客户与原发起者、实际经办人、代办原因、身份核验引用、授权方式/范围/版本/时效、原对象与目标、影响预览、必要复核、原请求与执行回执、客户可见说明。敏感证据采用受限引用，不能直接铺在通用日志里。具体字段与保存期限后续收敛，不在此冻结接口。

## 6. 建议的后台补齐方式

保留十个业务上下文及当前视觉；在其上增加**按业务事项办理**的组合入口，避免让客服理解全部菜单才能完成服务。

1. **客户服务台**：按客户/订单/餐次/流水/服务编号定位 → 展示同一事实链 → 可办动作、授权及影响 → 案件进展 → 用户回看。
2. **今日运营与异常队列**：正常待确认与异常分开；到期未处理、已确认未安排、变更冻结、资金未知、配送受阻、结算未完成按责任和年龄排序。
3. **变更办理详情**：旧/新内容、原单/后继、停止、差价、授权、执行门禁和补偿逐项显示；每个未完成步骤有办理入口与责任。
4. **购买与资金明细**：按批次、订单行、原交易查看分配/消费/退款，正常自动结算，例外人工跟进；Finance保持核算职责。
5. **履约与售后处置台**：按受影响行/包裹/批次处理质量、少件、部分交付、回收、补送；显示源证据而非手选“齐全”。
6. **经营准备与内容发布**：需求分层、备货安排、鲜讯依据/有效期、供应异常、剩余处置，并反馈顾客端。

这些是组合视图和受控业务命令，不新造“后台订单库”，也不增加一个拥有所有事实的万能客服领域。

### 推荐实施顺序与验收方式

|顺序|交付目标|必须走完的故事|尚未批准的政策如何处理|
|---|---|---|---|
|A|统一对象、服务案件与真实来源，先修错误闭环|J01/J02/J07/J14/J21/J33/J34；G13样例修复|身份/授权渠道未定显式标待决，先完成代填+客户核对路径|
|B|每日确认、到期、新安排、执行门禁|J08～J13/J23/J24|政策版本留参数与决策说明，不默认20:00或两小时前关单|
|C|换菜差额、批次结算、售后补救|J16～J22/J25～J28|范围/退差等以明确标注的候选方案评审，不冒充正式经营规则|
|D|经营准备、通知、观测、权益范围收敛|J29～J36及各项边界回归|当前已展示承诺优先；未确定增长能力明确首发取舍|

每轮以同一组客户数据同时走小程序、后台及模拟源结果。至少包含：正常；拒绝；无权限；重复；旧版本；并发胜负；收费成功接受失败；切配发生回执丢失；部分退款/部分送达；新单失败；退款未知；退出；调度恢复；员工交接；终态后晚到证据。

验收不是按钮有回执，而是顾客能看清“当前结果、钱在哪里、会不会送、还需谁做什么”，员工能看清“源事实、可办范围、责任、时限、恢复路径”。UNKNOWN必须保留；任何一端未有对应结果，都不能关闭该故事。

## 7. 待业务决策与剩余风险

|未决项|不能替用户决定的内容|可先推进的工作|
|---|---|---|
|受托授权|电话/其他渠道能否代理确认；核验方式、金额/范围限制|代填草稿、客户确认回路、审计/复核信息结构|
|模式边界|普通选肉是否有自动确认例外；免费建议与付费服务的区别|两端标清模式与来源，移除模糊的通用“订阅”推断|
|时间与费用|确认开放/截止、有效时刻、跨档、收费单位、商家延迟责任|版本化政策与受理/未知/拒绝设计；保留≥120分钟免费原则|
|变更与重新安排|哪些阶段允许取消/替换/部分履约，重新安排条件|旧新谱系、停止门禁、差量预览与失败恢复|
|资金结算|批次结束、分摊、实称、自动退差时点、部分先退、退出|资金去向视图、原款守恒、查询与受控恢复|
|服务运营|接手/查证/升级时限，质量关闭标准、回收余料处置、真实岗位|等待年龄、责任指派、逾期队列及分项证据结构|
|隐私与增长|证据保留/脱敏、积分/推荐/佣金首发范围|用途隔离、范围授权、明确演示与生产承诺|

长期真实负责人和政策未知仍是未完成事项。本轮提供可评审的设计方向，不要求现在一次回答所有参数；后续逐条业务闭环设计时再把必要决策收敛。

回退与迁移：本轮没有产品变更或生产迁移。后续修原型须版本化合成数据，保留原记录备份及旧ID引用；不能把旧“已验证/已完成”强映为新权威成功。真实迁移与回滚要核验外部资金和现场事实，不能用重置浏览器作为恢复方案。

## 8. 对先前“全模块覆盖”结论的修正

82页/206动作/318故事证明的是**已声明能力的目录与局部动作覆盖**，不证明经营机制无遗漏、跨模块实际协作、受托授权或两端一致。先前“已明确对象都有可见路径”的表述也需受9月29日新增对象及本轮结果审查限制。

已有局部设计值得保留：事实Owner分工、独立确认意识、退款整数额度和未知占用、逐次操作历史、独立复核入口、质量/物料/财务基本检查、精确关联样例及异常场景入口。下一步应在这些基础上补齐结果，不能把“证据框+目标状态”持续扩展成所有模块的通用办理方式。

## 附录A：82项工作区逐项盘点

此表只声明已核对配置和相应风险，不声明每项已做浏览器全路径验收。所有创建入口均受G13的新建关联问题约束；真实权限共同受G18约束。无状态出边只是检查线索：合法终态、策略待批准和跨域下一步必须区别，不能自动判成Bug。

|领域|工作区 / key|动作数 / 新建|需要补齐或继续核验的落点|
|---|---|---|---|
|交易与售后|订单台账 / `orders`|3 / 无|G01/G03/G04；取消/变更无闭合，缺订单谱系|
|交易与售后|价格与优惠 / `pricing`|4 / 有|G08/G15；价格版本与真实报价/已购快照联动待设计|
|交易与售后|收款核验 / `payments`|2 / 无|G06；核验三态、原目标和差异出口|
|交易与售后|退款与额度 / `refunds`|3 / 无|G06/G07/G11；来源、发起、失败恢复与结算关联|
|交易与售后|售后处理 / `aftersales`|4 / 有|G11/G13；新案件到分项执行和用户回看|
|交易与售后|订单变更协调 / `changes`|3 / 无|G03/G04；请求派生、冻结/停止与恢复出口|
|交易与售后|资金对账 / `reconciliation`|2 / 无|G06/G07；账单核对不能代替批次结算|
|交易与售后|购物意图与报价 / `quotes`|2 / 无|G02/G08；代填、报价变化与客户接受|
|交易与售后|优惠权益与占用 / `benefits`|4 / 有|G07/G15；权益守恒、售后返还与积分范围|
|交易与售后|缺货与替代协调 / `substitutions`|4 / 有|G04/G11；后继新单、差额、新授权与补救|
|计划与配送确认|每日配送确认 / `confirmations`|4 / 无|G05/G08/G09；新旧安排、权威裁决和自动到期|
|计划与配送确认|预约与承诺 / `reservations`|3 / 无|G03/G08；改期与新授权/原停止结果联动|
|计划与配送确认|服务能力 / `capacity`|2 / 无|G09/G14；冲突处置中无后续、影响承诺定位|
|计划与配送确认|周期服务 / `cycles`|3 / 无|G15；订阅周期与一周购买必须区分|
|计划与配送确认|配送费政策 / `tariffs`|2 / 无|G08；政策待决、生效版本与跨日报价|
|计划与配送确认|未履约金额跟进 / `retained`|2 / 无|G07；资金归属及退出办理出口|
|计划与配送确认|持续服务约定 / `service-contracts`|4 / 有|G15；明确付费约定与免费推荐区别|
|计划与配送确认|服务权益与周期占用 / `entitlements`|3 / 无|G07/G15；周期占用消费需真实订单来源|
|作业与交付|切配作业 / `tasks`|5 / 无|G10；自选门禁和改派不能解除质量/现场未知|
|作业与交付|工位与依赖 / `workstations`|2 / 无|G10；实际清洁/质量证据及在途停止|
|作业与交付|称重与现场观察 / `measurements`|2 / 无|G07/G10；实称接受、计价差额和现场未知|
|作业与交付|包裹与封装 / `packages`|3 / 无|G13/G17；绑定受阻和交接待接收无出口|
|作业与交付|配送与签收 / `deliveries`|4 / 无|G17；独立尝试、部分交付与客户决定|
|作业与交付|回收与退回 / `returns`|2 / 无|G11/G17；回收后检验/处置/物料与退款|
|作业与交付|履约能力发布 / `work-capacity`|2 / 无|G09/G14；能力降低影响已承诺安排|
|作业与交付|履约接收与计划版本 / `fulfillment-plans`|3 / 无|G08/G10；每日授权、执行范围/门禁与版本|
|商品与内容|商品与规格 / `products`|4 / 有|G14/G15；规格组合、停售影响与供给|
|商品与内容|菜谱与食材映射 / `recipes`|3 / 有|G15；多SKU映射/备忘区分及版本|
|商品与内容|首页与经营内容 / `content`|3 / 有|G14；鲜讯依据、期限、定时失效与更正|
|商品与内容|发布与回退 / `publications`|2 / 无|G14；小程序当前版本、依赖回执与失败回退|
|供给与质量|来源与接收 / `receiving`|2 / 有|G14；预计到货与实际异常关联|
|供给与质量|批次与物料账 / `lots`|2 / 无|G10/G14；追加更正与可用事实、剩余处置|
|供给与质量|质量判定 / `quality`|4 / 无|G10/G17；隔离传播、现场门禁与影响名单|
|供给与质量|物料分配 / `allocations`|3 / 无|G10；硬编码48kg守卫未消费批次可用事实|
|供给与质量|加工转换 / `transformations`|1 / 无|G10；局部数量平衡不替代跨批次扣用/质量|
|供给与质量|追溯与公开查询 / `trace`|3 / 无|G13/G17；实际包裹引用与撤回结果|
|供给与质量|质量召回 / `recalls`|3 / 无|G11/G17；受影响对象逐项处置核验|
|供给与质量|可供给能力 / `supply-capacity`|1 / 无|G14；需求分层和实际能力变更联动|
|客户与服务|客户档案 / `customers`|4 / 无|G01/G02；客户360及受托办理|
|客户与服务|地址与偏好 / `addresses`|2 / 无|G02/G03；地址簿更正与订单改址不同|
|客户与服务|个人周计划 / `plans`|1 / 无|G01/G02/G04；备注不能代办安排变更|
|客户与服务|客户服务事项 / `service-cases`|3 / 有|G01/G02/G12；服务案件与源业务收尾分开|
|客户与服务|团长与活动关系 / `leaders`|2 / 有|G15；资格关系已有，活动/佣金范围待决|
|客户与服务|同意与隐私处理 / `privacy`|3 / 无|G12/G18；合并/注销传播及在途义务|
|客户与服务|个人菜卡与餐次偏好 / `personal-cards`|2 / 无|G02/G15；用户私有内容受托修复|
|客户与服务|客户用途与服务限制 / `restrictions`|3 / 无|G18；用途独立控制和受限服务|
|渠道协作|渠道授权 / `channel-accounts`|3 / 有|G06/G12/G18；退出在途核验与受限恢复|
|渠道协作|外部对象映射 / `bindings`|1 / 有|G13/G18；账户作用域和真实目标校验|
|渠道协作|外部订单导入 / `imports`|3 / 无|G06/G13；新订单落点/原观察身份/迟到证据|
|渠道协作|回传与未知结果 / `outbound`|2 / 无|G06/G12；回传仍未知/失败/矛盾证据路径|
|渠道协作|渠道账单观察 / `statements`|1 / 无|G06/G07；交给资金核验须精确案件回执|
|财务核算|经济来源 / `sources`|2 / 无|G07/G13；待过账到真实分录缺协调关联|
|财务核算|分录与更正 / `journals`|3 / 无|G07/G18；局部平衡复核已有，不能证明资金账闭合|
|财务核算|会计期间 / `periods`|4 / 无|政策待决；重开待授权无办理者/后续入口，不可伪装已开放|
|财务核算|科目与核算规则 / `posting-rules`|3 / 有|G07/G18；规则版本与真实经济源消费关联|
|财务核算|总账与试算 / `trial-balance`|1 / 无|G07/G13；汇总差异回源修正而非文本核对|
|财务核算|核算主体与账簿 / `accounting-scopes`|2 / 有|G07/G18；核算范围/角色与原款主体一致|
|财务核算|期初与迁移核对 / `opening-balances`|2 / 无|G07/G18；实际迁移来源/差异及切换恢复待专项|
|经营分析|经营看板 / `reports`|1 / 无|G07/G09；经营口径、异常钻取、质量核对中无源联动|
|经营分析|指标口径 / `metrics`|3 / 有|G07/G09；计划、实收、消费和净额区分|
|经营分析|数据质量 / `data-quality`|3 / 无|G12/G13；回源修复和验证而非声明关闭|
|经营分析|重算与结果发布 / `rebuilds`|2 / 无|G09/G12；重算失败和旧有效结果、范围验证|
|经营分析|受控导出 / `exports`|2 / 有|G18；用途、实际对象范围及下载再鉴权|
|组织与权限|员工账号 / `accounts`|4 / 有|G12/G18；真实员工身份与离职义务交接|
|组织与权限|组织与岗位 / `org`|3 / 有|G18；岗位任职与实际权限消费|
|组织与权限|角色与动作权限 / `roles`|4 / 有|G18；角色提案未成为执行权限矩阵|
|组织与权限|服务区域与数据范围 / `scopes`|2 / 有|G08/G18；服务覆盖与数据访问不同、历史承诺保留|
|组织与权限|会话与外部身份 / `sessions`|1 / 无|G02/G18；账号不可用协助与撤权恢复|
|组织与权限|服务主体 / `service-principals`|2 / 有|G06/G18；受限查证义务与新动作权限隔离|
|组织与权限|导航与能力目录 / `menus`|2 / 有|G18；菜单可见不等于动作授权|
|组织与权限|岗位任职与角色指派 / `assignments`|3 / 有|G12/G18；实名接收与有时限交接|
|组织与权限|有效动作与授权解释 / `authorization`|0 / 无|G18；实际拒绝/恢复解释及操作时鉴权|
|系统与协同|待办与工作交接 / `handoffs`|4 / 无|G12；源事实核验及无人接手/逾期升级|
|系统与协同|异常与恢复 / `exceptions`|3 / 有|G06/G09/G12；关闭不能掩盖源未恢复|
|系统与协同|通知与回执 / `notifications`|1 / 有|G16；授权/送达/未读、目标与版本|
|系统与协同|文件与证据 / `assets`|1 / 有|G10/G18；真实上传、证据可用与业务充分性分离|
|系统与协同|作业调度 / `jobs`|3 / 有|G09；持久补扫、执行实例、业务效果核验|
|系统与协同|业务字典 / `dictionaries`|3 / 有|G18；标签不改状态迁移及发布影响|
|系统与协同|系统参数 / `configuration`|3 / 有|G08/G18；技术参数与经营政策边界及有效版本|
|系统与协同|操作与安全审计 / `audit`|0 / 无|G02/G18；受托/拒绝/前后事实/因果链|
|系统与协同|服务观测 / `monitor`|1 / 无|G09；技术健康之外的业务结果队列|
|系统与协同|接口与能力目录 / `api-directory`|0 / 无|正式合同未定义；不能视为操作入口已接实际服务|