java/talent-card.git

			@@ -32,3 +32,4 @@
			- 2026-09-17 代码侧交付。冷却实现取"一个 UPDATE 兼做判定与占位"：`update ... set capability_sync_until = now() + interval 5 minute where id = ? and (capability_sync_until is null or capability_sync_until < now())`，更新到行的那次才去查通道，并发点击直接拿当前快照。5 分钟按仓库既有 5 分钟租约写死在服务里（`MERCHANT_VERIFY_COOLDOWN_MINUTES`），没新开配置项——`stale-hours` 是运维口径，这个只是防连点。`merchantVerify` 刻意不加 `@Transactional`：冷却窗口必须在通道查询之前落库，且通道查询不能夹在持有该行锁的事务里（这条在类注释里已写死）。未核实的异常路径（`!providerVerificationRequired() \|\| !huifuPaymentProperties.isEnabled()`）直接返回当前快照、不查通道，与 `refreshQuietly` 的守卫一致。测试见 `MerchantPaymentReadinessMerchantViewTests` 的四个冷却用例（含"失败也节流"与"冷却过期后可再查"）。
			- 2026-09-17 复审修复（Spec 6）。原实现里"通道校验关掉/汇付未启用"那条早退分支不返回 `refreshed`，而 D9 说手动核实一定带它；客户端把缺失当 `false`，于是在那种配置下也会弹"刚核实过"。现在 `refreshed` 由唯一的返回点统一带上（`boolean refreshed = … && acquireVerifyWindow(...)`，早退已删除），结构上不可能再缺；前端文案也改成如实的"未重新查询通道，显示最近一次结果"。另把冷却的抢窗口逻辑提成 `acquireVerifyWindow`。测试补了 `retryAfterSeconds` 的断言。
			- 2026-09-17 真机上报 `Unknown column 'capability_sync_until' in 'field list'`（点击「收款能力」即 500）。根因不在判断逻辑：开发库 `talent_card` 的 Flyway 是关的，新列靠启动时 `MerchantOnboardingSchemaInitializer` 补，而那条 `alter table` 没成功（初始化等 DDL 元数据锁的上限是 5 秒，等不到就记 error 放行——这是它在注释里写明的取舍）。已按 V148 同样的 DDL 在开发库手工补列，补完无需重启（列是每次请求现查的）。顺带修掉一处真实脆弱点：`capabilityCooldownSeconds` 原来是本文件里唯一"点名列"的查询，缺列时整条 SQL 报错、把商户页打成 500；现在改成用申请行上已经读到的 `capability_sync_until` 自己算剩余秒数（少一条 select，缺列只是少一个字段 → 按"没有冷却"处理，页面照常显示判定）。时区显式取 `Asia/Shanghai`，与库里 datetime 的解释方式一致。`verifiedAt`／`nextVerifyAt` 的对外字符串格式未变（仍是 `String.valueOf(LocalDateTime)`）。
			- 2026-09-17 环境事实补记（排查上面那条时查到的，以后会再遇到）：开发库与测试库不是同一个实例，版本也不同——开发库是局域网 `192.168.110.13:3306/talent_card`（MySQL 5.7.44，Flyway 关着，列只能靠初始化补），测试库是本机 `127.0.0.1:8134/talent_card_test`（MySQL 8.0.36，Flyway 打开）。所以 `V148` 原先只在 8.0 上跑过；已把 V148 的语句体在 5.7 的开发库上实跑一遍（列已存在 → 幂等空转，语法与幂等性都没问题）。本机 8134 上另有 `talent_card`／`talent_card_dryrun`／`talent_card_verify1` 三个库也缺这一列，它们不是当前 `application.yml` 指向的开发库，未处理。

			@@ -32,3 +32,4 @@
			- 2026-09-17 代码侧交付。冷却实现取"一个 UPDATE 兼做判定与占位"：`update ... set capability_sync_until = now() + interval 5 minute where id = ? and (capability_sync_until is null or capability_sync_until < now())`，更新到行的那次才去查通道，并发点击直接拿当前快照。5 分钟按仓库既有 5 分钟租约写死在服务里（`MERCHANT_VERIFY_COOLDOWN_MINUTES`），没新开配置项——`stale-hours` 是运维口径，这个只是防连点。`merchantVerify` 刻意不加 `@Transactional`：冷却窗口必须在通道查询之前落库，且通道查询不能夹在持有该行锁的事务里（这条在类注释里已写死）。未核实的异常路径（`!providerVerificationRequired() \|\| !huifuPaymentProperties.isEnabled()`）直接返回当前快照、不查通道，与 `refreshQuietly` 的守卫一致。测试见 `MerchantPaymentReadinessMerchantViewTests` 的四个冷却用例（含"失败也节流"与"冷却过期后可再查"）。
			- 2026-09-17 复审修复（Spec 6）。原实现里"通道校验关掉/汇付未启用"那条早退分支不返回 `refreshed`，而 D9 说手动核实一定带它；客户端把缺失当 `false`，于是在那种配置下也会弹"刚核实过"。现在 `refreshed` 由唯一的返回点统一带上（`boolean refreshed = … && acquireVerifyWindow(...)`，早退已删除），结构上不可能再缺；前端文案也改成如实的"未重新查询通道，显示最近一次结果"。另把冷却的抢窗口逻辑提成 `acquireVerifyWindow`。测试补了 `retryAfterSeconds` 的断言。
			- 2026-09-17 真机上报 `Unknown column 'capability_sync_until' in 'field list'`（点击「收款能力」即 500）。根因不在判断逻辑：开发库 `talent_card` 的 Flyway 是关的，新列靠启动时 `MerchantOnboardingSchemaInitializer` 补，而那条 `alter table` 没成功（初始化等 DDL 元数据锁的上限是 5 秒，等不到就记 error 放行——这是它在注释里写明的取舍）。已按 V148 同样的 DDL 在开发库手工补列，补完无需重启（列是每次请求现查的）。顺带修掉一处真实脆弱点：`capabilityCooldownSeconds` 原来是本文件里唯一"点名列"的查询，缺列时整条 SQL 报错、把商户页打成 500；现在改成用申请行上已经读到的 `capability_sync_until` 自己算剩余秒数（少一条 select，缺列只是少一个字段 → 按"没有冷却"处理，页面照常显示判定）。时区显式取 `Asia/Shanghai`，与库里 datetime 的解释方式一致。`verifiedAt`／`nextVerifyAt` 的对外字符串格式未变（仍是 `String.valueOf(LocalDateTime)`）。
			- 2026-09-17 环境事实补记（排查上面那条时查到的，以后会再遇到）：开发库与测试库不是同一个实例，版本也不同——开发库是局域网 `192.168.110.13:3306/talent_card`（MySQL 5.7.44，Flyway 关着，列只能靠初始化补），测试库是本机 `127.0.0.1:8134/talent_card_test`（MySQL 8.0.36，Flyway 打开）。所以 `V148` 原先只在 8.0 上跑过；已把 V148 的语句体在 5.7 的开发库上实跑一遍（列已存在 → 幂等空转，语法与幂等性都没问题）。本机 8134 上另有 `talent_card`／`talent_card_dryrun`／`talent_card_verify1` 三个库也缺这一列，它们不是当前 `application.yml` 指向的开发库，未处理。