PRODUCT SPACE

CoDelphi ⌁ gzhanlei/codelphi · main ↗

CoDelphi 把 GitHub 仓库变成一份可追溯的产品规格。 连接仓库后,AI 自动提取功能清单与用户场景,每次 push 自动总结行为变化——每一条结论都附带可点击的源码证据,而不是凭空生成的摘要。

最近一次分析:succeeded

分析完整性:部分完整——合并完整性部分(合并层有截断/冲突/护栏检出);核验部分(存在一致性冲突或影子对比不一致)。分析成功不等于完整,完整不等于正确;结论采纳前应经人工核实。

源码装配覆盖率(按文件字节)12.7%(已装配实现文件 196/492 个,6 趟提取);本规格未覆盖全部实现面(提取趟数触顶),未覆盖部分不产生结论。。运行时开关与数据依赖行为静态提取不可见(边界说明);发现缺口请在左侧功能树进入功能页,用「编辑/新增场景」人工补充并标记核实。

支付订单与退款

建单四段边界(本地 pending 复用 30 分钟内同参数单 → 远端建单 → 回写 → prepay 回写),查单超 20 秒未收 webhook 时向 Chandler 对账;退款按剩余天数/SAU 折算,明确 4xx 记 refund_failed,超时停 refund_submitted 由 sweep/webhook 推进确认并回收钱包。

代码生成稳定链接 支付订单与退款
未核实
实现分布 · 2 个文件
边界情况EC-1生成未核实
情境
30 分钟内存在同账户同参数 pending 单
操作
createPaymentOrder 执行
结果
复用原订单号并更新渠道,不新建订单
边界情况EC-2生成未核实
情境
退款确认时钱包仍有预留未结清
操作
reclaimWalletIfSettled 执行
结果
保持 reclaiming 状态返回 false,等下一轮重试
错误路径ER-1生成未核实
情境
订单状态不是 paid/fulfilled 或已退款
操作
requestRefund 执行
结果
抛出 billing_state_conflict 表示不可退款
错误路径ER-2生成未核实
情境
退款金额非正整数或超过订单金额
操作
requestRefund 执行
结果
抛出 billing_state_conflict 拒绝退款
正常路径HP-1生成未核实
情境
用户选择订阅或超额包并发起支付
操作
createPaymentOrder 执行
结果
写入本地 pending 单、以本地商户单号为幂等键远端建单并回写平台单号与 prepay 参数
正常路径HP-2生成未核实
情境
订单已支付且平台回调 paid
操作
markPaidAndFulfill 执行
结果
订单置为 paid 并调用履约函数发放权益
正常路径HP-3生成未核实
情境
管理员对已支付订单发起退款
操作
requestRefund 执行
结果
订单置 refund_pending 后提交 Chandler,成功或超时置 refund_submitted,明确 4xx 置 refund_failed