# 后台设计对当前鲜配架构的符合性审查

> 后续处置（2026-09-29）：按用户确认，本轮仅修正设计与架构规划，不新增REQ或实施原型。BA-01～BA-11的设计响应已整理至[业务机制与异常处理](../../design/prototypes/admin-console/BUSINESS-SUPPORT.md)，并修订模块说明、跨域故事及评审入口。状态为“设计已修订；原型与验证待同步”，不关闭下述代码发现。本文原审查事实保留。

> 2026-09-29 · 主会话定向设计审查。只新增本报告，未修改后台设计、原型、架构或浏览器存储；不是生产测试或全量验收。
> 基准：[确认机制](../../architecture/05-domain/CONFIRMATION-POLICY.md)、[交易协议](../../architecture/08-domain-model/TRANSACTION-INTEGRITY.md)、[未决事项](../../architecture/DECISIONS.md)、[事实源索引](../../architecture/SOURCE-AUTHORITY.md)。

## 1. 结论

全局经营管理＋单客户下钻的结构可以保留；两层调用相同业务能力的方向符合事实唯一性。但当前动作定义、状态处理和故事仍包含旧机制，不能作为这套架构的完整办理方案。主要问题不是缺菜单，而是已有动作能得出架构不允许的结果，或没有达到业务终点的后续路径。

本次读取MODULE-DESIGN、WORKSPACES、CROSS-FLOWS和最新全局管理审查，检查当前workbench的design-source.py、catalog.json、model.js、app.js及相关工作区接入。原有103路由或82功能页的覆盖不作为本轮业务机制通过的证据。本次没有重新执行浏览器视觉、全路由或全部动作测试。

## 2. 发现与关闭条件

P1表示在宣称后台符合当前鲜配机制前必须修正；不是声称生产已发生事故。P2为设计来源与表达一致性问题。

| ID / 级别 | 证据与问题 | 应采用的设计 / 关闭证据 |
| --- | --- | --- |
| BA-01 / P1 | [design-source.py:79](../../design/prototypes/admin-console/workbench/design-source.py:79)允许同一确认记录从本次不送恢复为待客户确认，再到已确认。内存复现CONFIRMATIONS-003整条路径，未创建新安排 | 超时旧安排保持终态；重新购买/安排用新身份、原单关联及当前窗口校验。全局与客户入口均拒绝复活 |
| BA-02 / P1 | [model.js:25](../../design/prototypes/admin-console/workbench/model.js:25)以表单选择“演示窗口已结束”作为截止门禁；skip只改本地确认且订单保持原状。动作没有配送日期、绝对截止、时区或政策快照裁决 | 展示系统自动到期、停止证据、订单取消及补扫进度，16:00只处理未确认。人工用于异常核验，不成为常规取消开关；覆盖等边界、补扫、已确认保护 |
| BA-03 / P1 | [design-source.py:86](../../design/prototypes/admin-console/workbench/design-source.py:86)的accepted动作仅核验用户填写的确认记录/齐全选项，未验证付款核验、商业接受、截止与时段资格 | 付款后可提前多日确认、无需重复确认；后台查询源确认结果。代办在D-06授权合同成立前不能仅凭员工说明造授权；拒绝截止后确认及未付放行 |
| BA-04 / P1 | [CROSS-FLOWS CF-02](../../design/prototypes/admin-console/CROSS-FLOWS.md#cf-02--客户临近确认的费用)仍把16:00、16:01、17点等当日确认列为可处理路径。[app.js:42](../../design/prototypes/admin-console/workbench/app.js:42)默认16:00→18:00显示免费 | 费用计算器明确“费用数学结果不表示可承接”；先验证确认窗口、时段和准备时间。默认政策下16:00整点已不接受，但已有提前确认的18:00配送仍正常。保留费用档位待决，不把¥3/6/9变成批准规则 |
| BA-05 / P1 | [design-source.py:113](../../design/prototypes/admin-console/workbench/design-source.py:113)以留存为专门状态路径；[model.js:77](../../design/prototypes/admin-console/workbench/model.js:77)停送后直接把食材资金摘要写为留存待核 | 改为中性的原款分配/待处置事实，不由Demand推定Commerce留存结果；D-05未决期间同时不启用默认即时退、余额或整批后退。取消与退款/资金处置进度分开 |
| BA-06 / P1 | [design-source.py:31](../../design/prototypes/admin-console/workbench/design-source.py:31)仍以本周餐桌作为订单样例，实际模型只用通用字符串字段和关联；WORKSPACES要求购买批次、独立订单、后继关系，但未落实到完整办理对象 | 明确购买批次→按配送日/地址拆单→每单确认→组合配送的关系；同日新单不能继承旧授权，取消一天不影响其他日。本周标题本身不证明跨日订单错误，缺的是可核验的结构与场景 |
| BA-07 / P1 | [design-source.py:35](../../design/prototypes/admin-console/workbench/design-source.py:35)取消经check进入待人工处置，当前动作无出口；内存复现。替代页主要登记方案与同意，未形成停止旧单、后继新单和原款差额链 | Cancellation/Replacement按持久步骤跟进原请求，展示前驱停止、终态、新单、差额及新确认。开工先赢拒绝普通替换；新单失败不恢复旧单；不能以待人工处置结束设计 |
| BA-08 / P1 | [design-source.py:216](../../design/prototypes/admin-console/workbench/design-source.py:216)有称重观察和接受，但未关联到订单行计价重量、冻结单价、应收/预付差额与结算依据 | 建立实际称重→采用证据→Commerce行级金额核算→政策内资金处置的链条。超重、舍入、优惠等D-04未定，不能编造计算默认值；缺规则保持待核算而不是手填成功 |
| BA-09 / P1 | [model.js:83](../../design/prototypes/admin-console/workbench/model.js:83)resolvePending只要求一段非空凭据文字，随后直接设为原目标状态。内存复现退款结果待核验→退款已验证 | 至少在原型表达成功、确定失败、仍未知、相反证据四类核验结果，以及原目标/金额/渠道依据。UNKNOWN不释放额度，不用备注代替验证，不把演示按钮当事实证明 |
| BA-10 / P1 | [design-source.py:457](../../design/prototypes/admin-console/workbench/design-source.py:457)现有jobs是提醒、退款重试和重建；[configuration](../../design/prototypes/admin-console/workbench/design-source.py:470)是技术参数。未发现Demand确认截止政策版本、旧安排影响核对和自动取消补扫的专门能力 | 在Demand定义政策编辑/校验/生效范围、截止快照、已确认保护；Platform仅承载执行监控。展示逾期未取消、停止回执未齐、取消资金未收敛等责任，不通过改系统参数复活旧单 |
| BA-11 / P2 | [MODULE-DESIGN:7](../../design/prototypes/admin-console/MODULE-DESIGN.md:7)仍并列Study29为业务解释源；第17行称Workspace未实现，而README、WORKSPACES及当前代码已接入。CROSS-FLOWS另有PD台账，确认截止仍写待定 | 设计说明指向当前架构主讲，PD仅映射D项，不独立定案；当前结构和历史方案分开。生成源、catalog、stories/flows/cases同时更新，不能只改展示标签 |

还应补充“未正常履约·配送时间确认超时”的原因区分，当前确认摘要仍是“未确认·本次不送”。该项随BA-02处理，不能只换文字却保留旧状态路径。

## 3. 实际复现与证据边界

通过Node直接导入当前model.js，并读取catalog.json调用seed/perform/resolvePending；数据只在内存，不写localStorage、不调用后台服务、不执行真实收退款。app.js实际导入这些函数，故不是只针对不被使用的旧site代码检查。

| 探针 | 观察结果 |
| --- | --- |
| 对CONFIRMATIONS-003依次restore、accepted | 同一ID：本次不送→待客户确认→已确认；订单记录不变 |
| 对CONFIRMATIONS-001执行skip，选择演示窗口已结束 | 确认变成本次不送、资金摘要变成留存待核；订单记录不变 |
| 读取确认动作及seed结构 | accepted只含consent、expectedTime、receipts、evidence；门禁为receipts；无该安排的截止快照或时间裁决输入 |
| ORDERS-002取消后核对协调回执 | 进入待人工处置；该状态可用动作数为0 |
| fee(18:00,16:00) / fee(18:00,16:01) | 分别返回0元/120分钟、3元/119分钟。数学试算本身未收费；问题在故事/界面缺承接资格的前置说明与判断 |
| 将退款核验动作置UNKNOWN，再以任意非空说明resolvePending | 从结果待核验直接变退款已验证，无确定失败/仍未知的选择 |

输入SHA-256：

```text
model.js         798848806d95a917292e7df9a44972537fb62e1ede9967d7d517a75c2924ac38
catalog.json     9a4858ecf36529cb1213381ad5fa1cbf94cfb8be487084b78ca4c1a4c231ddb8
design-source.py bdc0f755dbba2219431f127f9e0c13d6d911d2f113e60e5478c1029c95fbc2f1
app.js           5185adba0ffe57aef2c4aa4b713a2ef7c1d1ed0a642056589df24c91747a13e2
```

当前后台仍在并行迭代；以上结论适用于这些输入。没有凭内存探针推断真实后端存在同样漏洞，也没有将代码检索未命中当作外部系统不存在的证明。

## 4. 建议整改顺序

1. **先纠正允许与禁止的动作**：禁止复活、区分确认/商业接受/资金事实、加入确认窗口与已确认保护、停止把留存或任意核验当成功。
2. **再补正常与异常的完整路径**：自动取消及补扫、取消/换菜后继链、重量结算与资金未决处理。
3. **最后统一两层展示和材料**：全局盘面看待确认/已确认/到期异常，客户层看同一对象及原因；同步政策版本、生成源、故事与场景断言。

保留当前视觉与全局＋客户结构，不新建个人工作台或让客服每日手动取消。架构已决定的时间与拆单规则可先落实；退款去向和超重费用未定，不阻止把未知表达清楚，但阻止将其当可执行政策完成验收。

本轮只审查并记录，不将建议自动实施。每个P1关闭时须从全局和客户入口验证同一源结果，以及拒绝、并发、未知和部分完成路径；不能用路由数量、菜单齐全或单一正常场景代替。