diff --git a/docs/index.html b/docs/index.html index 32e17a4..0b7f1f4 100644 --- a/docs/index.html +++ b/docs/index.html @@ -57,6 +57,11 @@
阅读版；执行真相源 docs/superpowers/plans/2026-07-10-pay-v2-p1-core-model.md（含 checkbox）。pay v2 设计的首个落地阶段(8 阶段之 P1)。4 个 TDD 任务:money 包(int64 最小单位+币种)→ Order/Attempt/Account/Refund 模型+状态机+:memory: 测试约定 → OrderStore(幂等标付/取消/列表,条件UPDATE+RowsAffected)→ 账户配置注册表(凭证走 env)。沿用 GORM AutoMigrate/glebarez sqlite 惯例;金额从 string 元改 int64。P2-P8(Provider/收款管线/渠道 adapter/退款/路由/对账/codes 库/订阅)各自成计划、落地前细化。
P1 · 2026-07-10 · Go(Gin+GORM+sqlite) · 待执行
+ +
pay v2 · P2-P8 依赖 DAG 与并行执行
+
P1 已完成。P2-P8 的依赖关系图(SVG DAG)+ 关键路径 P2→P3→P4/P6 + 波次(P7 全程并行/P5∥P3/P4∥P6)+ 同仓并行的真实边界(先计划后实现、worktree 隔离防冲突)。
+
roadmap · 2026-07-10 · 8 阶段依赖分析
+

运行与联调步骤见仓库根 README.md

🔧 排障 Runbook

diff --git a/docs/pay-v2-roadmap-dag.html b/docs/pay-v2-roadmap-dag.html new file mode 100644 index 0000000..d21dc0f --- /dev/null +++ b/docs/pay-v2-roadmap-dag.html @@ -0,0 +1,136 @@ + + + + + +pay v2 · P2-P8 依赖 DAG 与并行执行 + + + +
+← 返回文档索引 +

pay v2 · P2-P8 依赖 DAG 与并行执行

+

P1 已完成。本页给出 P2-P8 的依赖关系(DAG)、关键路径、以及"多 agent 并行"在同一仓工程里的真实可并行边界。设计见 pay v2 设计,P1 见 P1 计划。

+ +

依赖 DAG

+
+ + + + + + + + + + + + + + + + + + + + + + + P1 数据模型✅ 已完成 + + + P2 Provider 抽象收款管线+webhook v2关键路径起点 + + + P3 渠道 adaptercrypto/支付宝/Stripe + + + P5 多账户路由∥ P3(不同区域) + + + P4 退款POST /refunds 三向 + + + P6 对账 jobquery 兜底 + + + P8 订阅/拒付later,优先级低 + + + + P7 codes 共享库(A 嵌入各产品) + 独立 Go 模块 · 零依赖 pay 收款管线 + ▶ 全程可并行(worktree 隔离,与 P2-P6 同步推进) + +
+ +

依赖表 + 可并行性

+ + + + + + + + + + + +
阶段内容依赖可并行?
P2Provider 抽象 + 一次性收款管线(create/verify_callback/query)+ webhook v2 event_type + 幂等/金额核对P1关键路径,单独做
P3首批渠道 adapter:crypto 自托管 / 支付宝 / StripeP2(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
P7codes 共享库(A 嵌入各产品:码模型/状态机/生成/防双花兑换/批次/审计+叠加算法)无(独立模块)全程并行 · worktree 隔离
P8订阅/recurring(4 类 kind)+ 拒付 chargebackP2(事件)+ P3(渠道)later,优先级低
+ +

关键路径 & 波次

+ + + + + + + + + +
波次可同时推进
Wave 0P7(独立,立即并行)
Wave 1P2(关键路径,单独)
Wave 2P3 ∥ P5(P3 内三 adapter 亦可再并行)
Wave 3P4 ∥ P6
Wave 4P8(可延后)
+

关键路径 = 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 的工程。

+
+ +