| | |
|---|
| | | |
|---|
| | | Blocked by: None |
|---|
| | | |
|---|
| | | Status: 代码侧交付完成，待页面级人工验收 |
|---|
| | | Status: ready-for-human —— 代码侧交付完成，待两端页面人工验收 |
|---|
| | | |
|---|
| | | - [x] 未进件／待审核／已驳回的商户也能调用：判定为不可收款并给出对应原因（复用既有原因链，不新造文案）。 |
|---|
| | | - [x] 已 approved 且快照正常的商户返回 `ready=true`，`verifiedAt` 为 `capability_verified_at`。 |
|---|
| | |
|---|
| | | |
|---|
| | | - 2026-09-17 由本会话 grilling 的 D2／D9／Q10 决策立项（见 [spec](../spec.md)）。手动核实是独立的一票（03），本票只做只读。 |
|---|
| | | - 2026-09-17 代码侧交付。比 spec 的 D9 多返回两个派生字段：`verifyAvailable`（冷却窗口是否已放开，页面据此禁用「立即核实」）与 `nextVerifyAt`。加它们是因为让客户端去解析数据库时间戳字符串判断冷却不可靠，而这两个值同样是从快照派生的、不含通道原始值，D9 已相应更新。落点按既有约定放在 `MerchantSettlementService`（复用 `store(principal)` 门店校验）再委托给 `MerchantPaymentReadinessService.merchantView`；控制器只加两个端点，没有给控制器引入新依赖。测试见 `MerchantPaymentReadinessMerchantViewTests` 的 `merchantViewNeverQueriesTheProvider`（用 mock 调用次数证明只读）、`merchantViewReusesTheGateMessage`（拿闸门抛出的原话比对）、`merchantViewBlocksWithoutAnApprovedApplication`。 |
|---|
| | | - 2026-09-17 复审修复（Standards 5）。再加一个派生字段 **`retryAfterSeconds`**：冷却剩余秒数由服务端算（`coalesce(greatest(0, timestampdiff(second, now(), capability_sync_until)), 0)`），客户端拿它做倒计时就地恢复按钮，不必解析时间戳。它同时替掉了原来那个"另查一次窗口是否放开"的 select——读侧只有一个 `capabilityCooldownSeconds`，写侧只有一个 `acquireVerifyWindow`，"冷却判据写两遍"的问题随之消失。`verifyAvailable` 现在由 `retryAfterSeconds == 0` 推出，两条口径不会再分家。D9 已相应更新。 |
|---|
