P1 已完成。本页给出 P2-P8 的依赖关系(DAG)、关键路径、以及"多 agent 并行"在同一仓工程里的真实可并行边界。设计见 pay v2 设计,P1 见 P1 计划。
| 阶段 | 内容 | 依赖 | 可并行? |
|---|---|---|---|
| P2 | Provider 抽象 + 一次性收款管线(create/verify_callback/query)+ webhook v2 event_type + 幂等/金额核对 | P1 | 关键路径,单独做 |
| P3 | 首批渠道 adapter:crypto 自托管 / 支付宝 / Stripe | P2(Provider 接口) | ∥ P5 · 三个 adapter 之间也可并行(worktree) |
| P5 | 多账户路由策略(round_robin/weighted/limit_aware/地址池) | P1(账户注册表)+ P2(create 选账户) | ∥ P3(渠道无关,不同区域) |
| P4 | 退款 POST /refunds + 三向(业务/crypto人工/平台通知) | P2(事件)+ P3(渠道 refund) | ∥ P6 |
| P6 | 对账 job(每 provider query,渠道流水 vs 本地订单) | P2(query)+ P3(渠道) | ∥ P4 |
| P7 | codes 共享库(A 嵌入各产品:码模型/状态机/生成/防双花兑换/批次/审计+叠加算法) | 无(独立模块) | 全程并行 · worktree 隔离 |
| P8 | 订阅/recurring(4 类 kind)+ 拒付 chargeback | P2(事件)+ P3(渠道) | later,优先级低 |
| 波次 | 可同时推进 |
|---|---|
| Wave 0 | P7(独立,立即并行) |
| Wave 1 | P2(关键路径,单独) |
| Wave 2 | P3 ∥ P5(P3 内三 adapter 亦可再并行) |
| Wave 3 | P4 ∥ P6 |
| Wave 4 | P8(可延后) |
关键路径 = P2 → P3 → P4/P6(串行);P7 全程旁路并行;P5 挂在 P2 后、与 P3 并行。
| 约束 | 说明 |
|---|---|
| 先计划后实现 | P2-P8 目前只是路线图条目,每阶段要先写详细计划(像 P1 那样 TDD bite-sized)才能派实现 subagent。且下游计划依赖上游接口定稿(P3 计划要等 P2 的 Provider 接口定了才能写准)。 |
| 同仓并行会冲突 | SDD 铁律:同一仓不并行派实现 subagent(改文件/git 冲突)。要并行必须各开 git worktree 隔离,最后合并。 |
| 真正安全的并行 | P7(独立模块,零重叠)——立即可并行,收益最大。P3∥P5、P4∥P6 需 worktree 隔离 + 清晰文件边界。 |
| 关键路径本质串行 | P2→P3→P4/P6 有硬依赖,不能并行;并行只能压缩旁路(P7/P5)的墙上时间。 |
→ 现实策略:P7 立即并行起跑;关键路径逐阶段"写计划→SDD 执行";P5 在 P2 后与 P3 并行(worktree)。这是多会话、较大 token 的工程。