kate522
7b55cfb190
feat(payment): rebuild order details and asset records
2026-10-05 16:42:25 +08:00
kate522
f3fd38dfd2
fix(checkin): mirror reference experience displays in details modal
...
Checkin already grants matching experience via Level::on_checkin;
surface it like the reference: purple integral badge in the daily
reward card, 经验值+N in the signed-today block and purple mini
badges in the 7-day ladder (gated by the level system switch).
2026-09-19 15:21:52 +08:00
kate522
4653128a18
feat(checkin): open reference-parity details modal from signed buttons
...
- Rebuild checkin details modal HTML 1:1 with reference theme:
colorful header c-blue, user card (points/level), daily reward
card and 7-day continuous mini cards
- Signed entry buttons (header dropdown, user-card badge, user
center) become clickable checkin-details-link modal triggers
instead of disabled buttons
- Swap data-signin-btn to details link in place after successful
signin (reference .initiate-checkin replacement behavior)
- Add aksrt-checkin-details-modal runtime shell (modal-mini 400px)
- Remove dead code: legacy lite modal, admin-ajax details handler,
/signin/history route, signin calendar; rebuild public bundles
- Update contract tests to the new checkin modal contract
2026-09-19 14:49:58 +08:00
kate522
0d617d88c9
fix(pay): 余额充值预设档位不再被 custom_price 参数校验拦截
...
选中任一预设充值档位点「立即支付」，必然弹「无效参数：custom_price」。这是 WP
REST 的参数校验层拦截，请求根本没进业务回调。
原因是 WP REST 的 default 只在「键完全缺失」时生效，键存在但值为空串时 default
不参与，空串会直接送进 pattern 校验：
'custom_price' => ['type' => 'string', 'default' => '0', 'pattern' => '^(0|[1-9]\d*)(?:\.\d{1,2})?$']
而前端提交时无条件带上该字段（custom_price: custom），选预设档位时 custom 恒为
''。更隐蔽的变体：后台关掉「自定义充值金额」后模板不再渲染该输入框，customEl 为
null、custom 仍是 ''，也就是只放开预设档位的配置下 100% 复现。
该字段只在 package=custom 时被消费，而金额格式与区间的业务裁决早已完整存在于
create_charge_order()（AssetAmount::balance 严格正则 + 溢出检查，再按 custom_limit
校验区间并返回本地化错误）。参数声明上的 pattern 是同一规则的第二份实现，两套口径
不同步即是本次缺陷来源。故本次按「单一口径」收口，不再采用「放宽 pattern + 回调归一化
空串 + 前端改送 '0'」的三处并行写法：
- BalanceServiceRest：custom_price 参数去掉 pattern、default 改为 ''、显式声明
sanitize_callback；rest_charge_create 改为经声明式 args 用 $request->get_param()
取值，不再手工重读 JSON 体
- credits.js：selectProduct 选中预设档位时清空自定义金额输入（否则框内残留数字会在
提交时把 package 顶回 custom，静默覆盖用户刚点的档位）；customInput 声明上移，去掉
「先调用后赋值」的时序依赖
- balance-charge-modal.test.cjs：新增 2 项契约测试 / 6 条断言
清理的死代码：
- rest_charge_create 中手工 get_json_params() 并复刻 sanitize_text_field/sanitize_key
的一段：与声明的 sanitize_callback 重复，使那些声明形同虚设（实为第二套取值路径）
- credits.js 提交处理器内重复读取 payment_method 的死分支（处理器开头已读取，中间无
任何代码改动它）
放宽仅限「空串 / 键缺失」这一种情形：package=custom 而金额为空、非法或越界仍一律
400，007、abc、1e3、1.234、负数等仍被 AssetAmount::balance() 拒绝，失败方向仍是收紧。
行为变化（需知悉）：
- 金额裁决权归 AssetAmount::balance()，其内部 trim() 使带首尾空格的金额被修剪后接受，
此前被参数层 pattern 直接拒绝。这是「单一裁决者」的必然结果。
- 点选预设档位会清空自定义金额输入框，是修复该档位被静默覆盖的必要行为。
验证：node --test 全量 372 项 / 372 通过（原 370 项，新增 2 项）；PHPUnit 44 项 /
106 断言通过；改动 PHP 文件 php -l 通过。变异验证：把 6 条关键断言跑在修复前的文件
内容上，6/6 转红，证明回归测试拦得住此缺陷。未做视觉验收，弹窗标记与 CSS 未改动。
2026-09-19 11:34:12 +08:00
kate522
ce21cc2b9b
revert fa476af70e
...
revert refactor(pay): 充值商品以充值金额为唯一真值，移除销售金额与折扣
充值商品行此前是双值模型：price 充值金额决定到账、pay_price 销售金额决定支付，
pay_price 为 0 时回落到 price，否则即「付更少拿更多」的折扣。该模型把三处耦合在
一起——后台 schema 暴露销售金额输入、线格式首段携带支付额、下单时计价与到账分离。
只改其中一处就会出现「后台不再可配但前端仍在展示折扣」或「展示已合并但下单仍按
旧价扣款」的静默不一致，故本次三层一并收口，充值金额即实际支付金额。
后台 schema 有两份且必须同步：SPA 侧 recharge.js 负责渲染表单，PHP 侧 SchemaPayment
负责默认值与清洗。只改一份会让界面不再可配而默认值仍在写 pay_price。
线格式三段 "支付|到账|标题" 保持不动，仅为兼容历史已存的字符串配置：支付段不再读取
任何配置来源，恒等于充值金额，故历史配置里的折扣价会被忽略。旧数据无需迁移，pay_price
键留在库中只是不再被读取，从重建后的后台保存一次即自然消失。
行为变化（需知悉）：
- 已配置折扣的站点，其用户将按充值金额全额支付，即对这些用户是涨价。这是「不做优惠
和促销」的必然结果。
- parse_packages 的校验口径随之变松：有效性只由到账段决定，故 "abc|10|x" 这类首段
非法、到账段合法的行会被解析为 10 元档，而旧实现两段都作金额校验、会丢弃。理由是
支付段已不表达任何含义，因一个无用字段是垃圾就丢弃一条本来有效的档位只会让运营困惑。
既有数据不受影响——旧格式化器写出的首段恒为数字，只有手改出的脏数据才可能命中。
该取舍已写入方法文档。
- recharge.js / SchemaPayment：删除 pay_price 字段与三档默认值中的该键，help 去掉
「同时支持设置折扣」
- PaymentRuntime::format_product_lines：不再读取 pay_price，支付段由充值金额充当
- BalanceServiceCharge::parse_packages：不再产出 pay_price 键，金额唯一来源为到账段
- BalanceServiceCharge::create_charge_order：支付额与到账额同源于 price
- credits-wallet.php：移除销售金额行、「省X」折扣徽标及仅服务折扣的差额计算
- BalanceServiceRest：仅注释改写，说明积分路径的 pay_price 是售价而非折扣
- 新增 tests/widget-system/recharge-product-price-contract.test.cjs：5 条跨层契约
范围边界：积分商品 pay_points_product 的 pay_price 是「积分|支付|标签」里的实际售价，
本身不含折扣语义，保留不动。契约测试以正向断言固定该边界，避免日后被误当作同类问题
一并删掉。
验证：新增契约测试 5 项通过；node --test 全量 375 项 / 375 通过（原 370 项）；PHPUnit
44 项 / 106 断言通过；改动的 PHP 文件 php -l 全部通过。变异验证：把 create_charge_order
改回按 pay_price 计价、把 pay_price 重新注入模板，对应断言分别转红，证明回归测试拦得
住回退。另以反射调用真实代码做端到端执行验证 11 项全过，覆盖结构化数组 -> 线格式 ->
商品数组全链路、数组内残存 pay_price 被忽略、历史折扣字符串（98|100|旧折扣档 取 100）、
到账段为 0 或非法时跳过等边界。
部署提示：assets/admin/build 为部署时构建、未入库，后台表单的改动需在目标机执行
cd assets/admin && npm ci && npm run build 后才会生效。前端 credits.js 走 filemtime
版本号，无需手工清缓存。
2026-09-19 03:25:12 +00:00
kate522
633ab7abe3
revert c1a0eade38
...
revert fix(pay): 余额充值选中预设档位不再因空 custom_price 被 REST 拒绝
选中任一所预设充值档位点「立即支付」，必然弹「无效参数：custom_price」。这是
WP REST 的参数校验层拦截，请求根本没进业务回调。
原因是 WP REST 的 default 只在「键完全缺失」时生效，键存在但值为空串时 default
不参与，空串会直接送进 pattern 校验：
'custom_price' => ['default' => '0', 'pattern' => '^(0|[1-9]\d*)(?:\.\d{1,2})?$']
而前端提交时无条件带上该字段（custom_price: custom），选预设档位时 custom 恒为
''，于是必然校验失败。另一个更隐蔽的变体：后台若关掉「自定义充值金额」，模板里
根本不渲染该输入框，customEl 为 null，custom 仍是 ''，同样报错——也就是说这个
缺陷在只放开预设档位的配置下 100% 复现。
同文件的积分兑换路径（/pay/balance/points-exchange）早已写成
custom: validCustom ? custom : '0'，余额充值这条只是漏了同样的处理。
- BalanceServiceRest：custom_price 的 pattern 改为整体可选分组
^(?:(?:0|[1-9]\d*)(?:\.\d{1,2})?)?$，显式放行空串；rest_charge_create 把空串
归一化为 '0'，与参数声明的 default 语义对齐，避免 AssetAmount::balance() 拿到
空串后抛 balance_decimal_invalid
- credits.js：非自定义金额时显式送 '0'，与积分兑换路径写法一致
- 契约测试补 4 条断言：模式可选、允许空串、回调归一化、前端送 '0'
两层都改是有意的：JS 会被浏览器与 CDN 缓存，旧缓存仍会发空串，后端放行兜住；
后端放行则保证任何客户端都不再被这个字段卡住。放宽仅针对空串，金额格式校验
不放松——007、abc、-1、1e3、1.234 与带首尾空格的值仍一律拒绝。
验证：新 pattern 逐例实测，''、0、1、9.99、9999.99 放行，007、abc、-1、1e3、
1.234、带空格全部拒绝；变异验证把 pattern 改回旧写法后该用例立刻转红，证明回归
测试确实拦得住此缺陷；node --test 全量 370 项 / 370 通过；PHPUnit 44 项 / 106
断言通过。断言未直接比对含反斜杠的整串——JS 字面量与 PHP 单引号串的反斜杠层数
不同会静默比对失败，故拆为不含反斜杠的片段。
2026-09-18 17:44:25 +00:00
kate522
fa476af70e
refactor(pay): 充值商品以充值金额为唯一真值，移除销售金额与折扣
...
充值商品行此前是双值模型：price 充值金额决定到账、pay_price 销售金额决定支付，
pay_price 为 0 时回落到 price，否则即「付更少拿更多」的折扣。该模型把三处耦合在
一起——后台 schema 暴露销售金额输入、线格式首段携带支付额、下单时计价与到账分离。
只改其中一处就会出现「后台不再可配但前端仍在展示折扣」或「展示已合并但下单仍按
旧价扣款」的静默不一致，故本次三层一并收口，充值金额即实际支付金额。
后台 schema 有两份且必须同步：SPA 侧 recharge.js 负责渲染表单，PHP 侧 SchemaPayment
负责默认值与清洗。只改一份会让界面不再可配而默认值仍在写 pay_price。
线格式三段 "支付|到账|标题" 保持不动，仅为兼容历史已存的字符串配置：支付段不再读取
任何配置来源，恒等于充值金额，故历史配置里的折扣价会被忽略。旧数据无需迁移，pay_price
键留在库中只是不再被读取，从重建后的后台保存一次即自然消失。
行为变化（需知悉）：
- 已配置折扣的站点，其用户将按充值金额全额支付，即对这些用户是涨价。这是「不做优惠
和促销」的必然结果。
- parse_packages 的校验口径随之变松：有效性只由到账段决定，故 "abc|10|x" 这类首段
非法、到账段合法的行会被解析为 10 元档，而旧实现两段都作金额校验、会丢弃。理由是
支付段已不表达任何含义，因一个无用字段是垃圾就丢弃一条本来有效的档位只会让运营困惑。
既有数据不受影响——旧格式化器写出的首段恒为数字，只有手改出的脏数据才可能命中。
该取舍已写入方法文档。
- recharge.js / SchemaPayment：删除 pay_price 字段与三档默认值中的该键，help 去掉
「同时支持设置折扣」
- PaymentRuntime::format_product_lines：不再读取 pay_price，支付段由充值金额充当
- BalanceServiceCharge::parse_packages：不再产出 pay_price 键，金额唯一来源为到账段
- BalanceServiceCharge::create_charge_order：支付额与到账额同源于 price
- credits-wallet.php：移除销售金额行、「省X」折扣徽标及仅服务折扣的差额计算
- BalanceServiceRest：仅注释改写，说明积分路径的 pay_price 是售价而非折扣
- 新增 tests/widget-system/recharge-product-price-contract.test.cjs：5 条跨层契约
范围边界：积分商品 pay_points_product 的 pay_price 是「积分|支付|标签」里的实际售价，
本身不含折扣语义，保留不动。契约测试以正向断言固定该边界，避免日后被误当作同类问题
一并删掉。
验证：新增契约测试 5 项通过；node --test 全量 375 项 / 375 通过（原 370 项）；PHPUnit
44 项 / 106 断言通过；改动的 PHP 文件 php -l 全部通过。变异验证：把 create_charge_order
改回按 pay_price 计价、把 pay_price 重新注入模板，对应断言分别转红，证明回归测试拦得
住回退。另以反射调用真实代码做端到端执行验证 11 项全过，覆盖结构化数组 -> 线格式 ->
商品数组全链路、数组内残存 pay_price 被忽略、历史折扣字符串（98|100|旧折扣档 取 100）、
到账段为 0 或非法时跳过等边界。
部署提示：assets/admin/build 为部署时构建、未入库，后台表单的改动需在目标机执行
cd assets/admin && npm ci && npm run build 后才会生效。前端 credits.js 走 filemtime
版本号，无需手工清缓存。
2026-09-18 23:56:31 +08:00
kate522
c1a0eade38
fix(pay): 余额充值选中预设档位不再因空 custom_price 被 REST 拒绝
...
选中任一所预设充值档位点「立即支付」，必然弹「无效参数：custom_price」。这是
WP REST 的参数校验层拦截，请求根本没进业务回调。
原因是 WP REST 的 default 只在「键完全缺失」时生效，键存在但值为空串时 default
不参与，空串会直接送进 pattern 校验：
'custom_price' => ['default' => '0', 'pattern' => '^(0|[1-9]\d*)(?:\.\d{1,2})?$']
而前端提交时无条件带上该字段（custom_price: custom），选预设档位时 custom 恒为
''，于是必然校验失败。另一个更隐蔽的变体：后台若关掉「自定义充值金额」，模板里
根本不渲染该输入框，customEl 为 null，custom 仍是 ''，同样报错——也就是说这个
缺陷在只放开预设档位的配置下 100% 复现。
同文件的积分兑换路径（/pay/balance/points-exchange）早已写成
custom: validCustom ? custom : '0'，余额充值这条只是漏了同样的处理。
- BalanceServiceRest：custom_price 的 pattern 改为整体可选分组
^(?:(?:0|[1-9]\d*)(?:\.\d{1,2})?)?$，显式放行空串；rest_charge_create 把空串
归一化为 '0'，与参数声明的 default 语义对齐，避免 AssetAmount::balance() 拿到
空串后抛 balance_decimal_invalid
- credits.js：非自定义金额时显式送 '0'，与积分兑换路径写法一致
- 契约测试补 4 条断言：模式可选、允许空串、回调归一化、前端送 '0'
两层都改是有意的：JS 会被浏览器与 CDN 缓存，旧缓存仍会发空串，后端放行兜住；
后端放行则保证任何客户端都不再被这个字段卡住。放宽仅针对空串，金额格式校验
不放松——007、abc、-1、1e3、1.234 与带首尾空格的值仍一律拒绝。
验证：新 pattern 逐例实测，''、0、1、9.99、9999.99 放行，007、abc、-1、1e3、
1.234、带空格全部拒绝；变异验证把 pattern 改回旧写法后该用例立刻转红，证明回归
测试确实拦得住此缺陷；node --test 全量 370 项 / 370 通过；PHPUnit 44 项 / 106
断言通过。断言未直接比对含反斜杠的整串——JS 字面量与 PHP 单引号串的反斜杠层数
不同会静默比对失败，故拆为不含反斜杠的片段。
2026-09-18 23:41:27 +08:00
kate522
d2447f8aa6
fix(pay): 修复后台收款接口显示顺序不可用并接入收银台排序
...
后台「收款接口 → 收款接口显示顺序」有三处缺陷叠加：
1) sortable 渲染组件读取 item.label，而 schema 写的是 title，导致 6 行
只剩上下箭头；
2) SchemaProvider 的 sortable 分支遍历 items 定义重建数组，而该字段的
键顺序本身就是配置值，用户排序被静默改回 schema 静态顺序；
3) 真正构建收银台支付方式列表的 aksrt_list_cash_payment_methods() 使用
硬编码顺序，Gateway::get_available()/apply_sdk_order() 那套排序逻辑
无任何调用方，配置对前台毫无影响。
改为：schema 项统一使用 label（JS 与 PHP 两处对齐）；sortable 持久化按
提交键顺序重建，items 定义仅作白名单；新增唯一排序实现
aksrt_sort_payment_methods()（语义对齐参考主题 zibpay_get_payment_methods
+ pay_sdk_order 键顺序），并接入内容收银台、余额充值、购买积分与会员
购买四个入口。卡密输入盒改为按渠道存在与否判断，不再假定卡密固定在末位。
清理死代码：无调用方的 Gateway::get_available/apply_sdk_order/
get_status_summary、VipServicePackages 中不可达的支付方式列表回退分支、
零引用的 settings-defaults 模块及 schema/index.js 未使用的导出、支付
sortable 的 fields 死元数据、无拖拽实现却声明的 cursor:move。
未配置 pay_sdk_order 时顺序保持不变；未写数据迁移。
验证：php -l 8 个改动文件全部通过；新增 pay-sdk-order-contract 契约测试
（6 项）；node --test tests/widget-system/*.test.cjs 301 项全部通过；
后台 SPA 已重新构建。
2026-09-18 19:01:19 +08:00
kate522
b88eab0bfe
feat(pay): 卡密兑换入口收敛到三个购买弹窗并对齐参考主题
...
- 移除余额卡片独立「卡密兑换」通用弹窗，兑换入口分布到充值/积分/会员三个弹窗的支付方式中
- 充值弹窗补齐卡密 logo 与仅卡密时的金额选择隐藏逻辑
- 积分购买弹窗 1:1 复刻参考主题 points-pay modal（商品档位/自定义/支付方式/立即支付），REST 改为 product+custom 契约
- 会员弹窗注入卡密渠道：视图模型透传 card_pass，前端渲染卡密盒并直兑 /pay/card-pass/redeem type=vip
- 后台卡密兑换拆分为余额/积分/会员三个独立开关，VIP 段旧会员卡密组清理
- REST type 改为必填（balance/vip/credits），三类型独立闸门
- 测试重写为 card-pass-modal-redeem 契约，321 项全部通过
2026-09-18 12:25:18 +08:00
kate522
ff4ec1eb43
feat(captcha): 打通人机验证 11 个场景的前后端完整链路
...
- 统一验证入口 aksrt_require_captcha()，返回 true|WP_Error，启用场景配置缺失时 fail-closed 拒绝
- 前端公共 API 重构为 window.AKSRTCaptcha（verify/collect/reset/run），单飞锁防并发重复验证，一次性 proof 绑定浏览器 cookie+场景+服务商+主机名
- challenge/exchange REST 端点：challenge 原子占用防票据放大厂商调用，增加频率限制
- 新增 OAuth bind pass：服务端签发 5 分钟一次性令牌，绑定用户+服务商+浏览器，微信扫码延迟消费
- 覆盖场景：评论、登录、注册、绑定第三方、绑定手机、找回密码、修改密码、更改邮箱、资料下载、签到、前台投稿
- 移除 Service 层重复验证与 _auth_code_verified/_defer_login 等客户端可伪造标志，删除下载共享 pass 死代码
- 修复腾讯 TC3 签名 scope、Cloudflare action/cdata/hostname 严格校验、阿里云验签错误码映射
- 后台 Schema 保存对 secret 字段做掩码/保留合并；导入导出过滤 aksrt_captcha_config
- 重建 public bundle 与 admin SPA；新增 captcha 运行时/安全/业务契约测试与 harness
2026-09-02 13:03:24 +08:00
kate522
f5c60cd425
进行了一些小优化
2026-08-24 18:08:06 +08:00
kate522
85a124b886
修复支付状态问题
2026-08-24 17:21:06 +08:00
kate522
406fb8d6a6
修复两个问题
2026-08-24 16:52:26 +08:00
kate522
58f3f42bf8
修复两个问题
2026-08-24 16:38:03 +08:00
kate522
5cae5b5c93
积分与余额账务系统硬切重构
2026-08-24 15:59:11 +08:00
kate522
9375b1c30c
refactor(assets): vendor 资产迁入标准目录并全仓去除 zibll 标识
...
- assets/vendor 全量迁移: fontawesome5→assets/fontawesome5, css→assets/css,
js→assets/js/runtime(避开 14 个同名自有文件), img 合并去重→assets/img,
fonts→assets/fonts; 删除 assets/vendor
- libs 五个与 widgets/third-party 字节相同的库不重复入库, loader paths 改指向
- 运行时切换: _win.uri=assets 根, loader baseUrl=/js/runtime, enlighter 注入
路径同步; PHP 7 个引用文件切换并改名 $zibll_*→$runtime_*
- 去品牌: Qinver 头注释/品牌 console.log/演示链接清除, 默认文案中性化
- 功能标识符改名: zib__→aksrt__, zib_ajax→aksrt_ajax, window.zib→
window.aksrtLegacy, zibllblock/*→aksrtblock/*, .zib-widget→.aksrt-panel,
.zib-slider→.aksrt-slider, zib_menu_options meta 键等
- 自有 CSS 改名: legacy-utilities/compat-vars/footer shell
- admin SPA 重建; 契约测试同步(路径/断言/文件更名)
- 例外保留: tests/visual 对照环境与 fixtures 前缀(外部 Zibll 产品引用)
验证: php -l 133 个改动文件通过; runtime 86 个 JS node --check 通过;
契约测试 68/70(2 个失败经 stash 对照确认为存量问题)
2026-08-22 16:16:30 +08:00
kate522
d69334b37d
修复导航栏用户卡片浮层的签到按钮
2026-08-20 14:43:18 +08:00
kate522
a0b84977a2
feat(navigation): hard-switch to Zibll navigation and Font Awesome 5
2026-08-18 20:46:21 +08:00
kate522
6c6c462df8
refactor: remove forum and topic feature chains
2026-08-17 14:52:19 +08:00
kate522
b501cf4611
feat: unify invite flow with referral ref
2026-08-17 13:49:59 +08:00
kate522
929603b9e2
feat: adjust affiliate commissions and withdrawal strategy
2026-08-16 23:11:01 +08:00
kate522
ff730ab593
feat: unify referral promotion tabs and compact earnings UI
2026-08-16 20:40:21 +08:00
kate522
1247f9bf4e
feat(credits): exchange balance for points
...
Replace the legacy points-to-balance and external points purchase flows
with direct integer balance-to-points exchange. Enforce exchange and
points-transfer limits and capability checks across the UI and REST API.
2026-08-13 15:20:06 +08:00
kate522
dacd0095bf
feat(users): normalize center routes and withdrawal limits
2026-08-12 19:44:47 +08:00
kate522
69dd3b66ab
fix(orders): enforce configured expiry
...
Apply the configured order lifetime to all checkout flows and close unpaid orders once their expiry is reached.
2026-08-12 17:49:54 +08:00
kate522
39c92017d9
feat(user-center): merge promotion rewards into revenue
2026-08-05 23:43:16 +08:00
kate522 and Claude Fable 5
34150f3358
refactor(modal): remove legacy compatibility paths
...
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com >
2026-08-05 00:06:37 +08:00
kate522
49c12b761f
feat(users): merge promotion into revenue center
2026-08-03 15:38:17 +08:00
kate522
8c5b1555c9
refactor: flatten src/AKSRT → src (drop theme-identifier dir)
...
Move all domain folders from src/AKSRT/{Domain} to src/{Domain}; remap
Composer PSR-4 "AKSRT\\": "src/"; update audit script + README + ADR
paths; remove dead tools/build-psr4-map.php (scanned deleted inc/classes).
2026-08-02 22:06:06 +08:00
kate522
