审核队列 · 1,415 条待审
出处硬校验：锚点须在 K0 命中；手填出处强制 inferred。批量通过：规则类直接入 rules.yaml（一个 commit）； 定义类需人工归簇请单张过。
建模纪律 · 知识分类骨架（11 类）—— 判不准时点开对锚点
没通过实体四条的，不是扔掉，是归位。每类锚在不同的数据形态上——锚不对就是归错了。
速判：占一张实体表 → 实体；按时间追加流水 → 事件；某实体会流转的取值 → 状态维；静态描述值 → 属性； 一组可选值 → 枚举；连两个实体 → 关系；多事件编排 → 流程；「如果…就…」→ 规则；施加的操作 → 动作；算出来的量 → 指标。 全文见仓库 建模纪律.md「纪律 2」。
分期可选档位不由前端固定为 1/3/6/12，而是由后端 coreTransTryLoan 返回的 LOAN_LIST 驱动渲染（mock 实际含 18/24/36 等档）。
"分期可选档位不由前端固定为 `1/3/6/12`，而是由后端 `coreTransTryLoan` 返回的 `LOAN_LIST` 驱动渲染"
当 query.scene 等于 PAY_LATER_PAY 时，分发到消费付款入口，落地 service/payment/Index.vue。
"`query.scene === PAY_LATER_PAY`（消费付款入口，落地 `service/payment/Index.vue`）"
scene=ALLO_PAY 被映射到路由名 SERVICE_PAYMENT，但该路由名从未注册，故 ALLO_PAY 会导航到不存在的路由。
"`scene=ALLO_PAY` 在本仓**无已注册落地页**——`App.vue:363-364` 把 ALLO_PAY 映射到路由名 `SERVICE_PAYMENT`，而该路由名从未在任何 router 注册（router 只注册了 `PAY_LATER_SERVICE_PAYMENT`），故 ALLO_PAY "
消费付款的试算接口为 coreTransTryLoan，消费场景 LOAN_CODE 取值 9012。
"**试算接口**：`coreTransTryLoan`，消费场景 `LOAN_CODE=9012`"
账户准入校验 checkAccountBeforeWithdrawAndPay：邮箱未验证、blockCode 冻结、逾期等情形会拦截支付/取现。
"**账户准入**：`checkAccountBeforeWithdrawAndPay()`（`utils/view.js:389`）——邮箱未验证 / blockCode 冻结 / 逾期等会拦截"
账户准入校验仅由首页内发起的支付/取现入口调用；商户深链直达 payment/Index.vue 不经过该校验，绕过守卫。
"该校验仅由**首页内发起的支付/取现入口**调用（`home/Home.vue:1275`、`home/HomeV2.vue:898`、`home/AppGuidedTour.vue:169`）；商户深链直达的 `payment/Index.vue` 不经过它（`App.vue:366-367` 直接跳 `paymen"
付款结果：成功进入 COMMON_RESULT 页并触发外部回调；失败则给出错误提示可重试。
"**结果**：成功 → `COMMON_RESULT` 页 + 外部回调；失败 → 错误提示可重试"
付款页提供积分抵扣开关 use_allo_points，开与关分别走两套分期试算，是否用积分会影响分期试算结果。
"**积分抵扣开关 `use_allo_points`**：付款页提供积分抵扣开关，开/关分别走两套分期试算（`payment/Index.vue:9-12,148-216`）。是否用积分会影响分期试算结果"
付款页提交走组合支付接口 coreTransPayUnionPay，返回三态结果。
"**提交=组合支付 `coreTransPayUnionPay`**：提交走组合支付接口，含三态结果（`Index.vue:230-342`）"
使用 PL 的支付必过支付反欺诈引擎；引擎判定可疑时接口返回 0004（NEED_FACE）加 faceScanAppNo，触发 COMMON_FACE 刷脸验证，通过后回到结果轮询。
"使用 PL 的支付**必过支付反欺诈引擎**，引擎判定可疑时接口返回 `0004`（NEED_FACE）+ `faceScanAppNo` → 触发 `COMMON_FACE` 刷脸验证，通过后续回结果轮询"
组合支付返回 PENDING 时进入轮询，按轮询结果落定为成功或失败。
"**PENDING 轮询**：返回 PENDING 时进入轮询，按轮询结果落定成功/失败"
QRIS 主扫固定金额（动态码）形态：商户按订单生成动态二维码，金额随码带出，用户扫码后不可改金额，直接进支付确认。
"**固定金额**（动态码） | 商户按订单生成动态二维码，金额随码带出，用户扫码后**不可改金额**，直接进支付确认"
QRIS 主扫用户输入金额（静态码）形态：商户张贴静态收款码，用户扫码后自行输入支付金额再确认。
"**用户输入金额**（静态码） | 商户张贴静态收款码，用户扫码后**自行输入支付金额**再确认"
QRIS 主扫两种形态进入支付确认后共用同一套 PL 选项、分期与低价展示逻辑，低价感知各条对两种形态均适用。
"两种形态进入支付确认后共用同一套 PL 选项/分期/低价展示逻辑（下方"低价感知"各条对两种形态均适用）"
第三种交互为被扫（CPM 付款码）：用户出示付款码由商户扫。
"另有第三种交互 = **被扫（CPM 付款码）**：用户出示付款码由商户扫"
QRIS 支付限额来自监管规定，对两种主扫形态与被扫一体适用，产品/营销不可配置调整。
"QRIS 支付限额来自**监管规定**，对两种主扫形态与被扫一体适用，产品/营销不可配置调整"
QRIS 单笔（Per Trx）限额为 Rp 10.000.000。
"**单笔（Per Trx）** | Rp 10.000.000"
QRIS 单日（Per Day）限额为 Rp 100.000.000。
"**单日（Per Day）** | Rp 100.000.000"
生成 QRIS 码有金额上限、超上限不可生成，其校验来源是监管红线，不是可调的运营参数。
"这解释了「生成 QRIS 码有金额上限、超上限不可生成」（《QRIS被扫流程优化0428》）的校验来源——**监管红线，不是可调的运营参数**"
用户选择钱包支付时判断 PL 是否有低价权益，有则展示 0% interest 标识。
"**0% interest 展示条件**：用户选择钱包支付时，判断 PL 是否有低价权益，**有则展示 0% interest** 标识"
读取试算接口，若用户有 0 利率权益，则在 PL 选项处展示当前 0 利率的剩余可用额度及其适用期数。
"读取试算接口，若用户有 0 利率权益，则在 PL 选项处展示用户当前 **0 利率的剩余可用额度** 及其适用期数"
选择 PL 选项时默认只展示前两个期数选项，点击展开更多才出现全部期数；如果只有两个期数则不展示展开/隐藏按钮。
"**期数默认收起**：选择 PL 选项时，**默认只展示前两个期数选项**，点击"展开更多"时再出现全部期数；如果只有两个期数则不展示展开/隐藏按钮"
limit up 会员在有效期内，展示会员的还款提额比例，取值基于 Market code 第 3~4 位（前端直读整数，如 06=6%）。
"在有效期内 → 展示会员的还款提额比例，取值**基于 Market code 第 3~4 位**（前端直读整数，`06`=6%"
会员失效时保留原查询机制，读取营销系统配置的提额比例。
"会员失效 → 保留原查询机制，读取营销系统配置的比例"
支付结果页弹窗按是否有效会员用对应比例计算后，展示按时还款后可提额的额度金额。
"**支付结果页弹窗**同样按"是否有效会员"用对应比例计算后，展示"按时还款后可提额的额度金额""
用户勾选立减权益支付但最终订单金额超过权益门槛无法使用权益时，以 toast 提示告知用户，5 秒后消失，toast 文案可配置。
"**立减权益超门槛 toast**：用户勾选了立减权益支付，但最终订单金额**超过权益门槛**导致无法使用权益时，以 toast 提示告知用户（**5 秒后消失**），**toast 文案可配置**"
CPM 的 PL 期数选项按从小到大排序。
"**CPM 期数排序**：CPM 的 PL 期数选项按**从小到大**排序（原为从大到小）"
CPM 支付完成后进入 CPM 专属支付成功页。
"**CPM 支付成功页**：CPM 支付完成后进入 CPM 专属支付成功页"
立减权益在 Indomaret/CPM 场景以优惠券（coupon）形式应用，记账上立减部分计入 Payment Discount CPM Expense（如购买 5.4K 商品立减 3.4K，PL 实际放款 2K）。
"立减权益在 Indomaret/CPM 场景以**优惠券（coupon）**形式应用，记账上立减部分计入 `Payment Discount CPM Expense`（如购买 5.4K 商品立减 3.4K，PL 实际放款 2K）"
支用交易在后端按产品线经过不同的决策引擎组合，引擎本体全部在后端，前端只能看到"放行/挑战"结果
"支用交易在后端按产品线过不同的**决策引擎组合**，引擎本体全部在后端，前端只见"放行/挑战"结果"