fix: 微信配置

openspec/changes/add-payment-configuration-management/design.md

@@ -0,0 +1,68 @@
+# Design: 支付配置管理能力对齐 MVP 文档
+
+## Context
+
+`docs/mvp/支付配置.md` 已经给出了后台支付配置的接口文档，包括：
+
+- 支付配置列表查询
+- 支付配置创建
+- 支付配置详情
+- 支付配置更新
+- 当前生效配置查询
+
+但当前仓库没有对应的 OpenSpec 能力说明，现有前端代码也仍沿用 `wechat-config` 命名，容易把“微信配置页面”误读成“仅支持微信支付的页面”。
+
+同时，MVP 文档里存在一个需要明确记录的歧义：
+
+- `provider_type` 只列出了 `wechat`、`wechat_v2`、`fuiou`
+- 字段模型中又出现了完整的 `ali_*` 支付宝字段组
+
+如果不先明确这层假设，后续实现时很容易在 `provider_type` 是否应支持 `alipay` 上出现分叉。
+
+## Goals / Non-Goals
+
+- Goals:
+  - 为支付配置能力建立统一的 OpenSpec 能力边界
+  - 把列表、创建、详情、更新和当前生效配置查询的契约写清楚
+  - 明确敏感字段脱敏和“已配置/未配置”状态展示语义
+- Non-Goals:
+  - 不在本次 spec 中补充文档未描述的删除接口
+  - 不在本次 spec 中补充文档未描述的激活/停用写接口
+  - 不擅自把 `provider_type` 扩展为文档未枚举的值
+
+## Decisions
+
+- Decision: 能力名称使用 `payment-configuration-management`，而不是沿用页面路径中的 `wechat-config`
+  - Rationale: 该能力已经覆盖微信、小程序、公众号、支付宝和富友相关字段，业务边界明显大于“微信配置”。
+
+- Decision: `provider_type` 在本次 spec 中严格按文档限定为 `wechat`、`wechat_v2`、`fuiou`
+  - Rationale: 这是文档明确枚举出的渠道主类型，spec 不应凭猜测新增 `alipay`。
+
+- Decision: `ali_*` 字段在本次 spec 中被视为支付配置对象支持的可选扩展字段，但不单独引入新的 `provider_type`
+  - Rationale: 文档已经明确给出这些字段；在没有更正枚举之前，先把它们作为统一字段模型的一部分记录下来。
+
+- Decision: 所有读取响应中的敏感信息都必须采用脱敏或配置状态标记，不能返回明文密钥
+  - Rationale: 文档的详情和当前生效配置示例已经给出了 `***`、`已配置`、`未配置` 这类语义。
+
+- Decision: 更新接口采用部分更新语义，只要求提交实际需要修改的字段
+  - Rationale: 文档明确说明更新请求“仅传需要修改的字段”，spec 需要保留这个约束。
+
+## Risks / Trade-offs
+
+- 风险: 当前前端类型定义尚未覆盖 `ali_*` 字段，按 spec 对齐后会触发类型和页面联动修改。
+  - Mitigation: 实施时先调整 `src/types/api/wechatConfig.ts`，再逐步修改列表、表单和详情展示。
+
+- 风险: 文档没有给出“如何切换当前生效配置”的写接口，只有 `is_active` 状态和 `/active` 查询接口。
+  - Mitigation: 本次 spec 仅约束读取和编辑契约，不推断未文档化的激活写流程。
+
+## Migration Plan
+
+1. 先补齐支付配置类型定义和 API 契约。
+2. 再对齐设置页列表、创建/编辑表单和详情页展示。
+3. 最后核对首页“当前生效支付配置”展示组件是否遵循相同的脱敏语义。
+4. 通过文档示例验证列表、详情、更新和当前生效配置的典型返回结构。
+
+## Open Questions
+
+- `provider_type` 是否最终应该补充 `alipay`，使其与 `ali_*` 字段组形成一致的一对一渠道语义？
+- 删除、激活、停用接口是否属于正式 MVP 范围，是否需要在后续文档和 spec 中补齐？