优惠适用条件核对

核对既定优惠与购物清单，输出条件状态、计算依据和应付草稿

根据用户给定事实核对最多 10 条优惠与 20 条购物行（同一已知币种）。交付：条件状态表、每一步金额依据与仅在规则完整时给出的应付草稿。

输入

提供 JSON，含 currency、cart、promotions；每条购物行都要有 SKU、单价和正整数数量。优惠应包含有效期/timezone、threshold_basis、threshold、threshold_includes_shipping、eligible_skus、优惠类型和金额或折扣。threshold_includes_shipping 为 true 时还需提供 shipping_fee。多券还应给出 stacking_order；当前时刻为 current_time。折扣和“优惠后商品额”门槛只按该规则的适用 SKU 计算。

百分比优惠使用 percent 表示应付比例（90 表示应付 90%，即 9 折；10 表示应付 10%，即减免 90%），避免把中文“9 折”误作 90% 减免。必须提供商家确认的 rounding_mode: "total_half_up_2"，该模式表示先对适用金额合计计算优惠，再按四舍五入保留两位小数；缺少舍入方式时，优惠额和应付草稿保持待确认。若舍入后的减免高于适用商品余额，金额处理规则未提供时也保持待确认，不产生负余额或程序错误。多行固定或百分比优惠影响后续优惠的部分 SKU、且后续优惠仍可能生效并改变余额时，需要明确 allocation_rule: "cart_order"（按购物车行顺序依次扣减）；后续优惠确定不适用（例如其优惠前门槛已不足）、确定没有减免（固定减免为 0、percent 为 100），或中间一项已确定清空相关适用 SKU 余额时，不要求无关分摊规则。缺少必要分摊规则时，优惠和应付草稿保持待确认，且行级扣减显示待确认；不会把购物车顺序当作平台规则。任一购物行余额待确认时，整单应付小计也待确认，即使其他 SKU 的优惠条件可以单独计算。

规则

• 只核对输入中的优惠；不查询实时价格、领券、下单或自行认定平台规则。
• 购物车没有命中优惠适用 SKU 时，将优惠判为“不可用”，门槛为 0 也不能改变 SKU 不匹配结论。确定不可用的优惠即使缺少有效期，也不会把应付草稿误改成待确认。固定或百分比优惠覆盖多条商品行且会影响后续部分 SKU 时，只有提供商家确认的分摊规则才继续计算；已确定不适用的后续优惠不要求额外分摊。
• 金额输入保留原始十进制精度；百分比舍入仅按用户确认的 rounding_mode 执行。固定优惠额超过当前适用商品余额时，不会截断为余额，而是标为“待确认”，直到商家给出余额不足的处理规则。反向有效期（开始晚于结束）标为待确认。percent、舍入与分摊方式都不代表任何平台的通用规则。
• 时间、叠加顺序、运费是否计入门槛或门槛口径不明确时，将相关结论标为“待确认”。即使门槛不含运费，缺少运费金额也必须把运费与应付草稿标为“待确认”，不能按免运费处理。
• 前一项优惠状态为“待确认”时，只把不确定性传给与其适用 SKU 重叠的后续优惠。受影响 SKU 的当前余额、固定金额余额检查、优惠额和应付小计继续标为“待确认”；“优惠后商品额”门槛则使用确定下界核对：商品额下界为 0，若确认计入运费则再加已知运费。因此门槛为 0，或门槛不高于已知计入运费时，门槛条件仍为“可用”；高于该下界才标为“待确认”。其他 SKU 仍按其已知金额单独核对。后续优惠若已确定不可用，优惠额与行级扣减为 0，不继承无关的不确定状态。
• 每个计算步骤输出适用 SKU、当步余额、计算公式、舍入说明与购物行扣减；前序状态影响金额时需标明对应 SKU 与待确认原因，不得把未扣减的原始购物车金额写成已知的当前余额。
• 不宣称最优价。应付草稿只应用“可用”的明确规则。

本地运行

bash

python3 scripts/check_eligibility.py < fixtures/success.json
python3 scripts/self_test.py

示例输入与实际参考交付见：成功输入 → 成功交付，以及缺料输入 → 缺料交付。