{
  "source_path": "work_store/VWCG-1119-consume-limit-account-scope/source-evidence.md",
  "status": "historical-conflict-snapshot-not-an-active-contract",
  "original_sha256": "09703e3efee8138a05d89122e63540c914b52bf01128d82884a9f0b6b8e4e9a4",
  "original_text": "# VWCG-1119 来源与证据\n\n## 1. 云效主需求（A 级）\n\n- 工作项：`VWCG-1119`\n- 标题：消费限制支持按受限账户设置范围或次数限制\n- 状态：待处理\n- 负责人：孙倩倩\n- 读取方式：云效 OpenAPI，只读\n- 读取日期：2026-07-29\n- 评论：0\n\n当前 PRD 明确要求：\n\n- 新增/编辑页在“应用场景”之后、“消费限制类型”之前增加“受限账户”。\n- 必填多选：个人账户、餐补账户、赠送账户。\n- 提示文案：`所选账户受范围或次数的限制。`\n- 保持现有范围限制、次数限制不变。\n- 所选账户受规则约束，未选账户不受本条规则影响。\n- 赠送账户未上线时可预留或置灰。\n- 本期不增加适用对象、身份、指定人员、金额限制或规则组合。\n\n<<<<<<< HEAD\n=======\n### 1.1 用户补充口径（A 级，优先于方案推断）\n\n2026-07-29 用户进一步明确：\n\n- “受限账户”需要判断账户有没有钱。\n- `store` 消费机订单必须覆盖 MQTT 和 API。\n- 小程序端点餐也必须判断。\n- 历史规则没有受限账户字段，必须默认个人账户和餐补账户。\n\n据此，本文不再采用 V1.0 中“先推演最终扣款账户，再按实际扣款账户分别计次”的设计，而改为“受限账户可用余额门禁 + 现有订单次数统计”。这是对技术语义的修正，不是扩展功能。\n\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n内嵌原型已人工回读，显示：\n\n- 个人账户、餐补账户默认勾选。\n- 赠送账户未勾选。\n- 现有范围限制、次数限制表单保持原样。\n\n## 2. 历史产品设计（B 级背景证据）\n\n来源：\n\n- `origin/master:work_store/account-type-consume-limit-20260713/requirement-product-design.md`\n- `origin/master:work_store/account-type-consume-limit-20260713/account-consume-limit-current-style-prototype.html`\n\n历史方案包含指定人员、身份、金额限制、每个账户独立范围/次数/金额等扩展能力，明显大于当前云效 PRD。本文只把它作为问题背景，不纳入本期开发范围。\n\n<<<<<<< HEAD\n## 3. `store` 正式基线（A 级代码证据）\n=======\n## 3. `store` 代码证据（A 级）\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n\n- `origin/master`：`0382055c2`，标签 `V2.40.34`\n- 消费限制前端：\n  - `public/static/src/view/marketingCenter/consumeLimitMgr.vue`\n  - `public/static/src/view/marketingCenter/addConsumeLimit.vue`\n  - `public/static/src/api/marketing/consumeLimit.js`\n- 消费限制后端：\n  - `application/api/controller/ConsumeLimit.php`\n  - `application/api/validate/ConsumeLimit.php`\n  - `application/api/service/ConsumeLimit.php`\n- 支付校验：\n  - `application/api/service/Consume.php`\n<<<<<<< HEAD\n=======\n  - `application/api/controller/Consume.php`\n  - `application/cron/command/MqttServer.php`\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n- 初始表结构：\n  - `db/v2/v2.0.6.sql`\n\n已确认现状：\n\n- 现有数据表只有规则主表、部门、应用场景、范围和拦截日志，没有账户关联表。\n- 新增/编辑接口当前只接收部门、场景、限制类型、范围、次数、状态和备注。\n- 支付校验发生在营销价格计算和账户扣款拆分之前。\n- 范围限制当前语义为“配置的档口+餐次禁止消费”。\n- 次数限制当前按人员的全部成功订单计数，没有区分现金、餐补或赠送支付。\n<<<<<<< HEAD\n- 在线支付有两条调用路径；`order_type=2` 离线补传会跳过限制校验。\n- `ConsumeLimit` 控制器只声明 `checkLogin`，数据权限由控制器内的部门/餐厅权限逻辑补充。\n\n## 4. 赠送账户依赖（A/B 级）\n\n- 当前工作区分支：`codex/VWCG-1121-pc-account-settings-20260727`\n- 提交：`472fed605 #VWCG-1121`\n=======\n- HTTP API 入口 `application/api/controller/Consume.php::orderPay()` 和 MQTT 入口 `application/cron/command/MqttServer.php` 最终都调用 `Consume::orderPayAsync()`。\n- `Consume::orderPayAsync()` 内仍有 Redis 快照与数据库回退两条支付路径，两条都必须调用同一个限制评估器。\n- 在线支付当前有两处限制调用；`order_type=2` 离线补传会跳过限制校验。\n- `ConsumeLimit` 控制器只声明 `checkLogin`，数据权限由控制器内的部门/餐厅权限逻辑补充。\n\n## 4. 小程序订餐代码证据（A 级）\n\n小程序订餐由相邻仓库 `ai_api` 承载，不在 `store` 内创建：\n\n- 提交订单：`app/api/controller/MealCheckout.php::submit()`\n- 订单计算与落库：`app/api/service/meal/Checkout.php`\n- 直接扣款：`app/api/controller/MealCheckout.php::directPay()` → `app/api/service/meal/DirectPay.php`\n- 支付编排：`app/api/service/cashier/MealPayment.php`\n- 支付成功兜底：`app/api/service/meal/PaySuccess.php`\n- 账户余额：`app/common/service/account/AccountSettlementService.php::getAvailableBalance()`\n\n`store` 只通过 `OrderSourceEnum::ORDERFOOD = 4` 识别订餐订单，未发现负责小程序订餐提交的入口。因此只改 `store` 不能完成“小程序端点餐判断”，需要 `store + ai_api` 联动。\n\n## 5. 赠送账户依赖（A/B 级）\n\n- `store` 当前工作区分支：`codex/VWCG-1121-pc-account-settings-20260727`\n- `store` 核对提交：`ec3ee5447`\n- `ai_api` 当前工作区分支：`develop_cqhw_0721`\n- `ai_api` 核对提交：`72c341fc #VWCG-1121`\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n- 云效 `VWCG-1121` 状态：待处理\n- 正式 `master` 尚未包含该提交。\n\n该分支已引入：\n\n- `application/common/service/account/AccountSettlementService.php`\n- `application/common/service/account/GiftAccountPolicy.php`\n- `ydy_meal_order.gift` 及账户结算相关字段\n- 餐补、个人现金、赠送账户的可配置扣款顺序\n\n<<<<<<< HEAD\n结论：云效正文明确要求“受限账户”包含个人、餐补和赠送三个多选项。当前分支已经包含赠送余额、扣款、退款和订单字段能力，因此“能力未上线时可置灰”的条件不成立；本期应启用 `gift`，但不增加独立赠送金额或独立规则配置。\n\n## 5. 证据等级与限制\n=======\n结论：正式基线不能把赠送账户视为已上线能力；当前开发分支已经有 `gift_balance` 与统一结算服务。推荐个人/餐补先落地，`VWCG-1121` 合并、迁移和全链路验证后再开放赠送账户。\n\n## 6. 证据等级与限制\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n\n| 结论 | 等级 | 说明 |\n| --- | --- | --- |\n| 当前 PRD 的范围和验收要求 | A | 云效工作项原文与内嵌原型 |\n| 当前代码和表结构 | A | 本地仓库与 `origin/master` 直接证据 |\n| 赠送账户尚未成为正式基线 | A | `master` 差异、工作分支和云效状态 |\n| 历史复杂方案 | B | 控制项目中已提交的产品设计资料 |\n<<<<<<< HEAD\n| 计次口径、账户受限后是否换账户 | D | PRD 未完整定义，需产品确认 |\n\n## 6. 本次未执行\n\n- 未修改云效工作项、评论、状态或工时。\n- 未修改 `store` 业务代码、SQL 或测试。\n- 未运行 PHPUnit、前端构建或真实支付联调，因为本轮交付仅为技术设计。\n=======\n| 规则按余额生效而非按实际扣款账户生效 | A | 用户直接补充 |\n| 历史规则默认个人+餐补 | A | 用户直接补充 |\n| 多选账户是“任一有钱”还是“全部有钱” | D | 用户未明确，本文建议“任一有钱” |\n| “个人账户有钱”是否包含透支额度 | D | 用户未明确，本文建议不包含透支 |\n\n## 7. 本次未执行\n\n- 未修改云效工作项、评论、状态或工时。\n- 未修改 `store` 业务代码、SQL 或测试。\n- 未运行 PHPUnit、前端构建或真实支付联调，因为本轮只修订技术设计。\n>>>>>>> 5d05833ef476571c794ef3016336bc136526872c\n- 控制项目存在其他任务的未提交改动，本次只新增独立的 `VWCG-1119` 目录。\n",
  "blocks": [
    {
      "line": 23,
      "variant_a": "",
      "variant_b": "### 1.1 用户补充口径（A 级，优先于方案推断）\n\n2026-07-29 用户进一步明确：\n\n- “受限账户”需要判断账户有没有钱。\n- `store` 消费机订单必须覆盖 MQTT 和 API。\n- 小程序端点餐也必须判断。\n- 历史规则没有受限账户字段，必须默认个人账户和餐补账户。\n\n据此，本文不再采用 V1.0 中“先推演最终扣款账户，再按实际扣款账户分别计次”的设计，而改为“受限账户可用余额门禁 + 现有订单次数统计”。这是对技术语义的修正，不是扩展功能。\n\n"
    },
    {
      "line": 52,
      "variant_a": "## 3. `store` 正式基线（A 级代码证据）\n",
      "variant_b": "## 3. `store` 代码证据（A 级）\n"
    },
    {
      "line": 69,
      "variant_a": "",
      "variant_b": "  - `application/api/controller/Consume.php`\n  - `application/cron/command/MqttServer.php`\n"
    },
    {
      "line": 84,
      "variant_a": "- 在线支付有两条调用路径；`order_type=2` 离线补传会跳过限制校验。\n- `ConsumeLimit` 控制器只声明 `checkLogin`，数据权限由控制器内的部门/餐厅权限逻辑补充。\n\n## 4. 赠送账户依赖（A/B 级）\n\n- 当前工作区分支：`codex/VWCG-1121-pc-account-settings-20260727`\n- 提交：`472fed605 #VWCG-1121`\n",
      "variant_b": "- HTTP API 入口 `application/api/controller/Consume.php::orderPay()` 和 MQTT 入口 `application/cron/command/MqttServer.php` 最终都调用 `Consume::orderPayAsync()`。\n- `Consume::orderPayAsync()` 内仍有 Redis 快照与数据库回退两条支付路径，两条都必须调用同一个限制评估器。\n- 在线支付当前有两处限制调用；`order_type=2` 离线补传会跳过限制校验。\n- `ConsumeLimit` 控制器只声明 `checkLogin`，数据权限由控制器内的部门/餐厅权限逻辑补充。\n\n## 4. 小程序订餐代码证据（A 级）\n\n小程序订餐由相邻仓库 `ai_api` 承载，不在 `store` 内创建：\n\n- 提交订单：`app/api/controller/MealCheckout.php::submit()`\n- 订单计算与落库：`app/api/service/meal/Checkout.php`\n- 直接扣款：`app/api/controller/MealCheckout.php::directPay()` → `app/api/service/meal/DirectPay.php`\n- 支付编排：`app/api/service/cashier/MealPayment.php`\n- 支付成功兜底：`app/api/service/meal/PaySuccess.php`\n- 账户余额：`app/common/service/account/AccountSettlementService.php::getAvailableBalance()`\n\n`store` 只通过 `OrderSourceEnum::ORDERFOOD = 4` 识别订餐订单，未发现负责小程序订餐提交的入口。因此只改 `store` 不能完成“小程序端点餐判断”，需要 `store + ai_api` 联动。\n\n## 5. 赠送账户依赖（A/B 级）\n\n- `store` 当前工作区分支：`codex/VWCG-1121-pc-account-settings-20260727`\n- `store` 核对提交：`ec3ee5447`\n- `ai_api` 当前工作区分支：`develop_cqhw_0721`\n- `ai_api` 核对提交：`72c341fc #VWCG-1121`\n"
    },
    {
      "line": 128,
      "variant_a": "结论：云效正文明确要求“受限账户”包含个人、餐补和赠送三个多选项。当前分支已经包含赠送余额、扣款、退款和订单字段能力，因此“能力未上线时可置灰”的条件不成立；本期应启用 `gift`，但不增加独立赠送金额或独立规则配置。\n\n## 5. 证据等级与限制\n",
      "variant_b": "结论：正式基线不能把赠送账户视为已上线能力；当前开发分支已经有 `gift_balance` 与统一结算服务。推荐个人/餐补先落地，`VWCG-1121` 合并、迁移和全链路验证后再开放赠送账户。\n\n## 6. 证据等级与限制\n"
    },
    {
      "line": 144,
      "variant_a": "| 计次口径、账户受限后是否换账户 | D | PRD 未完整定义，需产品确认 |\n\n## 6. 本次未执行\n\n- 未修改云效工作项、评论、状态或工时。\n- 未修改 `store` 业务代码、SQL 或测试。\n- 未运行 PHPUnit、前端构建或真实支付联调，因为本轮交付仅为技术设计。\n",
      "variant_b": "| 规则按余额生效而非按实际扣款账户生效 | A | 用户直接补充 |\n| 历史规则默认个人+餐补 | A | 用户直接补充 |\n| 多选账户是“任一有钱”还是“全部有钱” | D | 用户未明确，本文建议“任一有钱” |\n| “个人账户有钱”是否包含透支额度 | D | 用户未明确，本文建议不包含透支 |\n\n## 7. 本次未执行\n\n- 未修改云效工作项、评论、状态或工时。\n- 未修改 `store` 业务代码、SQL 或测试。\n- 未运行 PHPUnit、前端构建或真实支付联调，因为本轮只修订技术设计。\n"
    }
  ]
}